Cortex brings Cortex, Codex, Microsoft Copilot, Claude, Gemini, and OpenCode into one consistent experience across the browser, IDE, extensions, mobile, and CLI, without making teams rebuild how they work around every provider.
Enterprise AI has entered a new phase.
The question is no longer whether a team will use AI. It is how many AI systems the team will use, where those systems will operate, who will control access, how work will continue across them, and whether the result will remain understandable after the first impressive answer.
Different AI hosts bring different strengths. One may be a strong fit for a coding task. Another may suit a difficult investigation. A team may already have an approved provider relationship, a personal credential, an enterprise entitlement, or an open-source runtime connected to its preferred model. New models and agent experiences arrive quickly, and no organization wants its workflow strategy to become obsolete every time the market changes.
But choice has created a new kind of fragmentation.
Users move among separate interfaces, accounts, permissions, histories, tool conventions, approval models, and billing relationships. Context is copied from one experience to another. Security teams must review multiple execution paths. Administrators struggle to understand where credentials live and which system acted. Developers learn provider-specific behavior instead of staying focused on the work. Valuable conversations become isolated islands.
The result is a paradox: organizations gain access to more intelligence while losing continuity, consistency, and control.
Cortex Host Protocol is designed to change that.
It gives users a consistent Cortex experience across six host choices: Cortex, Codex, Microsoft Copilot, Claude, Gemini, and OpenCode. The selected host can change for a new session, but the surrounding experience does not have to be reinvented. Cortex Connect, protected credentials, governed execution, durable continuity, and reviewable output remain part of one coherent product model.
This is not a page full of model names. It is a governed host layer for getting work done.
The provider should change, not the way people work
Most multi-provider experiences begin with a selector and stop there.
That is useful, but it addresses only the smallest part of the problem. Selecting a provider does not by itself answer the questions that matter in real work:
- Which credential is being used, and who owns the resulting cost?
- What context is available to the host?
- What is the host allowed to do?
- Which actions require approval?
- What happens if the connection drops or the user changes devices?
- Can the session be resumed without silently changing providers or identities?
- Can the organization apply limits, disable a provider, or revoke access?
- Does the final result remain connected to checks and evidence?
Cortex Host Protocol treats those questions as part of the experience, not as cleanup work left to every client or provider integration.
Users can choose the host that fits a new session while continuing to work through familiar Cortex surfaces. Cortex remains the default experience. External hosts become additional paths through the same governed layer rather than separate products that users must assemble themselves.
For an employee, that means less time deciding which application to open and less effort rebuilding context. For an enterprise, it means provider choice can be introduced without surrendering the policies, boundaries, and evidence required for responsible use.
The difference is simple but consequential: choice becomes a platform capability instead of a collection of exceptions.
Six hosts, each with a clear role
Cortex Host Protocol brings together six host choices while preserving the identity of each one.
Cortex is the native, default host. It brings the broader Cortex architecture into the session, including the intelligence, routing, safety, validation, continuity, and enterprise capabilities developed across the platform. It is the natural starting point when users want the complete Cortex experience.
Codex from OpenAI gives users an OpenAI-powered coding-agent path through Cortex. Organizations can support it with an approved credential and policy rather than requiring developers to create an unrelated workflow around a separate interface.
Copilot from Microsoft supports teams whose development practices and entitlements already include Copilot. Cortex provides a consistent place to select and use that host while keeping the session inside the same broader experience.
Claude from Anthropic gives users another strong host option for coding, analysis, and complex technical work, subject to the credentials and policies available to them.
Gemini from Google adds a Google-hosted path for teams and users whose preferred or approved provider environment includes Gemini.
OpenCode from Anomaly provides an open-source host option that can connect to a configured upstream model. Open source does not automatically mean free inference: the credential or compute behind the selected model still determines who pays. What OpenCode adds is flexibility in the host layer, including a path for organizations that value an open runtime.
The objective is not to claim that every host is identical. They are not, and reducing them to a lowest common denominator would erase much of the reason to offer choice.
Instead, Cortex creates a reviewed contract around the capabilities that can be offered consistently and safely. Provider-specific behavior remains behind that boundary. The user sees the host identity, the available experience, and the relevant limitations without being forced to understand each provider’s internal protocol.
This gives Cortex room to expand as the ecosystem changes. A new model release does not need to create a new navigation system, credential workflow, or client architecture. Providers and underlying models can evolve while the user experience remains stable.
Fast, Balanced, and Deep, not a catalog that expires every week
AI model catalogs are growing faster than most users can reasonably follow.
Names change. Versions multiply. Preview models appear. Pricing moves. Context limits expand. A model that looks like the obvious default one month may be replaced the next. Exposing every option can look powerful, but it pushes provider operations onto the user and creates an interface that becomes outdated almost immediately.
Cortex takes a more durable approach.
Users express the experience they want through Fast, Balanced, and Deep:
- Fast prioritizes responsiveness for direct questions, quick explanations, lightweight transformations, and focused tasks.
- Balanced is the practical default for everyday coding, research, analysis, and normal workflow decisions.
- Deep gives difficult investigations, architecture work, and demanding objectives more room for reasoning.
Those choices stay understandable even as providers introduce new models. Cortex can align reviewed models with each mode based on capability, availability, cost, and organizational policy. Users do not need to become model-release managers to make a sensible decision.
This also creates a stronger enterprise control point. An organization can define which providers and modes are available while preserving a simple choice for employees. Cost and capacity policies can evolve behind the scenes without repeatedly retraining the workforce or redesigning every client.
The host answers who should run this session. The response mode answers how much effort should this task receive. Together, they offer meaningful control without turning every prompt into a configuration exercise.
Protected credentials and clear billing ownership
Provider choice becomes risky when credential handling is improvised.
Cortex Host Protocol separates the user experience from the secret itself. Credentials remain protected within the Cortex account and policy boundary rather than being copied into chat messages, exposed to every client, or passed around as part of session content.
The experience can support two practical enterprise patterns.
With a personal credential, a user connects an approved provider account or API key. Cortex can then show that the session is using the user’s credential. The resulting provider usage belongs to that account and follows the applicable provider terms, entitlement, and billing relationship.
With Cortex-managed access, an organization can make approved provider capacity available under a centrally managed policy. Users do not choose whether a hidden fallback credential should be used. Cortex and the organization define when managed access is available, to whom, and within which limits.
If neither is available, Cortex can tell the user that a personal credential is required. That is materially better than silently falling back to another account, unexpectedly billing the organization, or allowing a session to begin without a clear identity.
This makes billing source visible without making billing architecture the user’s problem:
- Using your credential means the selected host is connected to the user’s approved provider account.
- Provided by Cortex means the organization has made managed access available under its policy.
- Personal credential required means the user must connect an eligible account before that host can be used.
Clarity matters. Teams should know whether an external provider is charging a personal account, an enterprise entitlement, a Cortex-managed account, or an upstream model selected through OpenCode.
It also makes revocation meaningful. When a credential is removed, expires, or no longer satisfies policy, the external host should stop being available rather than quietly switching to a different payer.
Governance that travels with the session
The biggest enterprise risk in a multi-provider strategy is not the presence of multiple providers. It is inconsistent authority.
One host may support broad tools. Another may offer its own approval model. A third may discover local configuration or extensions. A fourth may be connected to external services. If every provider is allowed to define the operating boundary, the organization does not have one AI policy, it has a collection of partially overlapping policies that users are expected to understand.
Cortex Host Protocol puts the governing boundary around the host session.
Provider access is explicitly enabled. Credentials are scoped to the user and organization. Workspaces are constrained. Sandboxing and permission rules are applied according to the surface. Consequential actions can require approval. Usage limits and timeouts bound exposure. Unsupported capabilities fail closed rather than being inferred. A provider can be disabled quickly if operational or security conditions change.
The policy can also reflect the client.
An IDE or CLI may support approved workspace activity because the user is working directly with a project and the client can present the necessary controls. Discover, browser extensions, and mobile can use a more restrictive read-only experience where that is the appropriate V1 boundary. The host choice is consistent, but access does not become broader merely because the same provider name appears in another surface.
This is governance with context. It protects the user without pretending that every device and workflow should have identical authority.
The outcome is not unrestricted agent execution. It is useful provider choice inside a boundary the organization can explain.
Durable sessions prevent provider choice from becoming provider confusion
A session should not silently become a different session halfway through the work.
When a user selects an external host, Cortex binds the new session to that choice and the associated credential context. Reconnecting resumes the same relationship. Starting a new chat creates a clear opportunity to choose another host. Changing providers is deliberate rather than an invisible mid-conversation substitution.
That behavior protects both user trust and operational integrity.
Different hosts can interpret context differently, use different capabilities, and produce different billing or audit implications. Silently switching from one to another after work has begun would make the transcript difficult to understand and the outcome harder to defend.
Cortex instead keeps the session’s host identity stable and preserves ordered progress for recovery and continuity. A disconnect should not require the user to reconstruct the conversation. A retry should not casually repeat a consequential action. A resumed session should not attach itself to a different account merely because another credential is available.
This extends the long-horizon direction introduced in Cortex brings Continuous, Coordinated Work. Continuity is not only about keeping a workflow alive. It is also about preserving the identity, authority, decisions, progress, and evidence that give the work meaning.
One choice across the places people already work
Provider fragmentation becomes especially expensive when each client implements it differently.
Cortex Host Protocol is designed for the Cortex surfaces people already use:
- Cortex Discover for browser-native research, selected page context, enterprise applications, and governed web work.
- IDE extensions for development inside Visual Studio Code and integrated browser workflows.
- Browser extensions for assistance across the major browsers already used by teams.
- Mobile apps for access, review, and continuity away from the desk.
- Cortex CLI for interactive terminal work and automation.
Cortex Connect holds the experience together. Users sign in once to Cortex, choose an available host for a new session, select Fast, Balanced, or Deep, and continue from the surface that fits the task.
The clients do not need to store external provider secrets. They do not need to become independent orchestration products. They do not need separate implementations of provider session semantics. Cortex remains the consistent connection and control layer.
This builds on the broader product direction described in Cortex Extends Enterprise AI Across Time and Tools. Cortex is moving useful work across environments without losing the objective. Host Protocol adds another dimension to that continuity: the intelligence host can vary while the product experience remains connected.
It also complements the work behind Cortex Discover. Recent performance results showed Discover ranking first in memory and CPU efficiency in a six-browser study while maintaining near-identical measured throughput and rendering versus Chrome. The point of that work is not efficiency in isolation. It is to leave more room for the applications, development tools, and AI-assisted work happening around the browser. Cortex Discover Advances Resource Efficient Agentic AI describes that product direction in detail.
Together, the ideas reinforce one another: more choice should not mean more overhead, more fragmentation, or more context switching.
Cortex capabilities remain available when the work grows
Choosing an external host does not erase the broader Cortex platform.
A session may begin as a focused coding question and later become part of something larger. The result may need verification. A successful process may become repeatable. A repository change may need an isolated worktree. A recurring objective may benefit from automation. A changing source may need Pulse. A team may want evidence connected to the output rather than buried in a conversation.
Cortex Host Protocol gives users provider choice at the host layer while preserving a path into the capabilities that surround meaningful work.
That includes the continuity concepts introduced across Cortex:
- Cortex Pulse can keep approved goals and changing work in view.
- Workflow Recipes and Automations can turn reviewed work into a repeatable capability.
- Managed worktrees can isolate parallel engineering efforts and preserve reviewability.
- Cortex Cloud can provide durable managed execution where policy permits.
- Cortex Discover can bring current browser context and governed web work into the objective.
- Evidence and validation can connect completion to what was actually checked.
Not every host session needs every Cortex capability. The important point is that the user does not have to abandon the Cortex experience to reach a different provider, then manually rebuild the path back when the work becomes larger.
Provider choice becomes an entry point, not an exit.
What this changes for developers
For developers, the immediate benefit is freedom without workflow churn.
A developer can start a new IDE session with Cortex, Codex, Copilot, Claude, Gemini, or OpenCode according to the task and the accounts available to them. The selection is visible. The session remains pinned. Fast, Balanced, and Deep preserve a familiar effort choice. Credentials stay out of the editor. Output streams through the same chat experience. Supported approvals remain explicit.
That reduces the need to maintain several parallel assistant setups or wonder which account is active. It also gives teams a clearer path to evaluate providers in real work without turning every evaluation into a separate deployment project.
For engineering leaders, Host Protocol makes provider diversity easier to manage. Teams can adopt more than one approved host while maintaining a shared operating model. Provider access can be introduced gradually, observed, limited, or disabled without redesigning the development workflow.
The long-term advantage is portability at the experience layer. Teams can benefit from a fast-moving ecosystem without allowing every market shift to dictate their internal process.
What this changes for enterprise teams
For an enterprise, the value is larger than convenience.
Host Protocol creates a practical separation between the provider that supplies the agent runtime and the enterprise layer that governs how the session enters daily work.
That separation allows organizations to pursue several goals at once:
Preserve optionality. Teams can use multiple approved hosts instead of making every workflow dependent on a single provider roadmap.
Respect existing investments. A company with Microsoft Copilot entitlements, approved OpenAI or Anthropic access, Google infrastructure, or an OpenCode strategy can bring those relationships into a consistent Cortex experience.
Control cost exposure. Personal and Cortex-managed credentials remain distinct. Conservative limits, bounded concurrency, timeouts, model policies, and provider controls help reduce the risk of unbounded usage.
Reduce credential sprawl. Clients do not each become another place to store provider secrets.
Keep authority understandable. Workspace access, read-only surfaces, approvals, and available capabilities can be defined by policy rather than inferred from a provider default.
Improve auditability. Host identity, session continuity, output, and relevant evidence remain part of a consistent product experience.
Adopt incrementally. An organization can begin with a provider and client cohort, validate the experience, and expand deliberately.
This is the difference between supporting multiple AI vendors and operating a multi-provider AI capability.
From model sprawl to a governed market of intelligence
The AI market will keep moving.
Providers will release new models. Coding hosts will add capabilities. Open-source runtimes will mature. Enterprises will renegotiate vendor relationships. Some teams will prefer a managed default. Others will bring credentials tied to accounts they already use. No static product menu can make that ecosystem stand still.
Cortex Host Protocol is designed around a more durable idea: the market can change without forcing the user experience to fragment.
Cortex provides the consistent layer, identity, protected credentials, clear host selection, understandable effort modes, governed execution, durable continuity, and reviewable output. Providers contribute differentiated intelligence and host capabilities within that structure.
The result is more than six logos in a selector.
It is a way for users to choose the intelligence that fits the work while keeping the experience they already understand. It is a way for developers to benefit from provider innovation without repeatedly rebuilding their environment. It is a way for enterprises to expand AI choice without multiplying unmanaged paths into sensitive work.
Most importantly, it keeps attention where it belongs: not on configuring the AI market, but on completing the objective.
Six providers. One Cortex experience.
Cortex has been evolving from an assistant for individual moments into an Enterprise AI Control Layer that can remain connected to work across time, tools, teams, and review points.
Host Protocol advances that direction by adding governed choice.
Users can begin with Cortex by default or select Codex, Microsoft Copilot, Claude, Gemini, or OpenCode for a new session. They can work from the browser, IDE, extension, mobile app, or CLI. They can choose Fast, Balanced, or Deep without chasing model names. Their credential source remains clear. Their session keeps its identity. Their organization retains control over availability, authority, and limits. Their output can stay connected to the broader Cortex capabilities that move work toward a reviewed result.
The provider can change.
The standard for a trusted experience should not.
That is Cortex Host Protocol: six providers, one governed experience, and a more future-proof path for Enterprise AI.
Explore the broader Pervaziv AI product portfolio or get started with Cortex.
Third Party Products and Trademarks: OpenAI, Codex, Microsoft, Copilot, Anthropic, Claude, Google, Gemini, OpenCode, and other third party names and trademarks are the property of their respective owners. References indicate supported interoperability or access and do not imply affiliation, sponsorship, endorsement, or approval of Pervaziv AI or Cortex. Third party services are subject to their respective terms, availability, and applicable fees.
