Expanded coding context, stronger understanding across files, and capacity that adapts to the work.
A software change rarely lives in one file. A request may begin with a requirement, depend on an interface in another package, behave differently under a configuration setting, and be judged by tests written years earlier. The code change may be small. Understanding the change is not.
Cortex Code 2.0 gives the coding capability in Cortex more room to work with that connected evidence. Its qualified context range expands from approximately 128K to approximately 256K tokens. This allows substantially more source code, tests, requirements, configuration, and diagnostic material to inform a single task.
The release also preserves a practical distinction between routine and complex work. Developers can continue to ask focused coding questions without managing context settings, while larger tasks can benefit from extended capacity when they require it.
Cortex Code 2.0 was evaluated across its expanded operating range and through the live Cortex product experience. The release results show meaningful long-context capability alongside retention of everyday coding quality.
A stronger coding capability within the Cortex Ensemble
The Cortex AI Model Ensemble brings specialized capabilities together for software engineering and enterprise work. Coding, planning, analysis, verification, routing, and privacy each have distinct responsibilities. Later releases expanded the ensemble, including the Cortex Confidential model for protected workflows.
Cortex Code provides the software engineering intelligence in that system. It examines code and related evidence, explains behavior, and produces coding outputs that can be reviewed and validated within the broader workflow.
Cortex Code 2.0 expands that coding capability. Cortex applies the appropriate context capacity for the task, keeping routine coding responsive while providing extended capacity when a larger connected body of software evidence is needed.
This is an advance in the coding experience within the established ensemble. The other specialists retain their roles: a stronger coding capability gives planning, analysis, and verification more complete technical work to build on and assess.
What changed from Cortex Code 1.0
Cortex Code 1.0 established a foundation for private coding assistance and software work across multiple files. Cortex Code 2.0 extends the amount of connected evidence that can inform that work.
| Capability | Cortex Code 1.0 | Cortex Code 2.0 |
|---|---|---|
| Qualified context range | Approximately 128K tokens | Approximately 256K tokens |
| Relative context capacity | 1× | Approximately 2× |
| Connected software evidence | Within the earlier range | More code, tests, configuration, and requirements considered together |
| Routine coding | Established baseline | Quality retained in the release evaluation |
| Large-context coding | Limited by the earlier range | Evaluated across the expanded range |
The additional context is useful because real engineering questions involve relationships. A change in one component can affect callers, shared contracts, tests, configuration, and documentation elsewhere.
A larger window does not mean every file should be included in every request. Relevant evidence still matters more than sheer volume. The improvement is that a task requiring a substantial connected body of evidence has more room to preserve it.
A practical example
Suppose a team is upgrading a shared library. The migration affects an interface, several implementations, configuration defaults, and tests. The team also has to preserve behavior for existing callers.
Handling each file in isolation can obscure the relationship between the migration requirement and its downstream effects. Cortex Code 2.0 can consider more of that change surface together. Developers can then assess a proposed change against a fuller view of the current system.
That same advantage applies to debugging, refactoring, and feature work. More of the relevant software can remain in view while Cortex reasons about what should change and what must continue to work.
Measured qualification results
Cortex Code 2.0 passed its integrated release qualification for the expanded context range. The evaluation also checked that the additional capacity did not reduce quality on the matched suite of ordinary coding tasks.
| Release measure | Result |
|---|---|
| Qualified context range | Approximately 256K tokens |
| Increase over the earlier qualified range | Approximately 2× |
| Aggregate result on the long-context qualification suite | 90.3% pass rate |
| Evaluated context ranges meeting release criteria | All |
| Standard-task retention suite | 100% pass rate |
| Regression against its matched standard-task baseline | 0 percentage points |
| Live Cortex product-path qualification | Passed |
These figures describe controlled release evaluations. They are not a promised success rate for every codebase or request.
The long-context and standard-task results answer different questions. The long-context result measures the new operating range. The standard-task result checks whether adding that capability affected the everyday coding experience. Both matter for a useful release.
The results also make an important distinction between accepting a long request and working effectively with it. A large advertised input limit has limited value if the coding model cannot use the relevant evidence within it. Cortex Code 2.0 was qualified on coding outcomes across its operating range, rather than on capacity alone.
Where expanded context helps customers
Long context has the most value when a task depends on several related sources of evidence.
| Customer task | Evidence that benefits from being considered together |
|---|---|
| Multi-component feature | Requirements, interfaces, implementations, and tests |
| Difficult defect | Symptoms, logs, callers, configuration, and expected behavior |
| Large refactor | Architectural intent and dependent components |
| Migration or upgrade | New requirements, compatibility constraints, and affected code |
| Behavior investigation | Configuration, runtime behavior, and relevant tests |
| Change review | Proposed edits, surrounding contracts, and validation evidence |
Consider a defect reported in one service. Its cause may lie in a configuration override, a shared utility, or a downstream component. A narrow view of the code can produce a plausible explanation that misses the actual relationship. A broader, relevant view gives Cortex a better basis for investigation.
A migration presents a different challenge. The question is rarely only “How does the new API work?” It is also “Where do we use the old behavior, which consumers depend on it, and what must remain compatible?” Keeping those materials together can improve the continuity of the resulting plan and implementation.
Large refactors similarly depend on preserving intent. If an abstraction is changed across packages, the model needs to understand the contract and the components that rely on it. Cortex Code 2.0 provides more capacity for that connected view.
Automatic right-sized performance
Most coding requests do not require the largest available context.
A developer may need an explanation of a function, a focused test update, or a localized fix. Those tasks should remain responsive. A larger request involving many related files may require additional capacity.
Cortex Code 2.0 supports both kinds of work through one coding experience. Developers provide the relevant material and the system applies an appropriate operating range.
This helps teams use expanded context where it brings value without making every routine interaction carry the cost of a large-context request. It also reduces the need for developers to decide which model setting fits each task before they can begin.
Efficient capacity use for everyday and complex work
Extended context has a resource cost, even when the underlying model is similar. Cortex Code 2.0 treats that capacity as something to apply when the task warrants it.
KV-cache VRAM is memory used to retain context during inference. For comparable configurations, a 128K context runner needs roughly half the maximum context-cache capacity of a 256K runner. Actual memory use depends on request length, concurrency, and serving conditions, but the general tradeoff matters: smaller requests leave more capacity available for other work.
| Operational consideration | Benefit of right-sized capacity |
|---|---|
| KV-cache VRAM | Smaller context profiles can reserve less memory |
| Concurrency | Lower memory use can permit more simultaneous standard requests |
| Infrastructure cost | Routine work can use less expensive capacity where available |
| Cold-start and allocation overhead | Smaller profiles can initialize and reserve resources more quickly |
| Capacity isolation | Large requests can be managed without crowding out everyday coding traffic |
The customer experience is simpler than the resource discussion: focused tasks remain practical, and complex tasks can receive more room to work with connected evidence.
Predictable availability
Extended capacity is a specialized service capability. Like any service, it may occasionally be unavailable.
Cortex Code 2.0 has defined handling for those conditions. Where a request can be served appropriately through another qualified path, Cortex can continue the work and make the outcome visible. Where it cannot, the product returns a clear failure rather than presenting incomplete work as though the full request had been processed.
This matters for engineering teams because an ambiguous answer can be worse than a visible interruption. Developers need to know whether their request was completed with the intended evidence and when they should retry or provide a more focused task.
Availability handling also respects the privacy requirements of the workflow. A service interruption does not change the permissions or protections attached to customer material.
Ten advances in the customer experience
The changes in Cortex Code 2.0 can be viewed through the work customers are trying to complete.
| Advance | Customer value |
|---|---|
| Repository-scale coding context | Work with substantially larger, relevant portions of a codebase in one task |
| Better multi-file understanding | Connect interfaces, implementations, tests, configuration, and documentation |
| More capable large refactors | Preserve architectural intent across packages and dependent components |
| Safer migrations and upgrades | Keep migration requirements, compatibility constraints, and affected code together |
| Configuration-to-code traceability | Follow how settings and contracts influence behavior across components |
| Longer requirement continuity | Retain instructions, decisions, and constraints throughout complex work |
| Reliable everyday coding | Preserve quality and responsiveness for smaller tasks |
| Automatic right-sized performance | Provide additional capacity when complexity warrants it |
| Resilient model availability | Handle interruptions predictably and communicate the outcome |
| Enterprise-ready governance | Preserve privacy controls, operational visibility, qualification, and rollback options |
These are connected benefits, rather than ten separate product systems. More context creates room for multi-file understanding. That understanding supports refactoring, migrations, and tracing. Capacity selection keeps the improvement practical for everyday use. Qualification and operational controls make it suitable for teams that need a dependable development tool.
Better multi-file understanding
Software behavior often emerges from the connection between files. An interface may promise one thing while an implementation, test, or configuration setting reveals an important exception.
Cortex Code 2.0 can consider more of those sources together. The benefit is especially relevant when a task spans different components or when the answer depends on reconciling requirements with existing behavior.
More capable refactors and migrations
A refactor changes structure while aiming to preserve behavior. A migration changes dependencies or contracts while aiming to preserve compatibility where required. Both tasks depend on understanding effects beyond the file being edited.
Expanded context gives Cortex more room for the intended design, affected code, and validation evidence. Developers still review and test the outcome, but they can start from a more connected analysis of the work.
Longer requirement continuity
Complex requests often include constraints such as “preserve the public interface,” “do not change the database schema,” or “support the existing deployment configuration.” Those instructions need to remain relevant after the model has examined substantial code and diagnostics.
Cortex Code 2.0’s larger qualified range helps keep requirements alongside the evidence needed to act on them. Clear requirements remain essential; the improvement is that they can accompany a larger body of technical material through the task.
Enterprise operation within the ensemble
Cortex Code 2.0 remains part of a broader engineering workflow. It contributes coding intelligence; other Cortex capabilities continue to plan work, investigate evidence, verify results, and apply the controls appropriate to the customer’s environment.
This separation is useful when the coding task becomes larger. A broader context can improve the coding output, while verification and execution controls continue to provide independent checks. The model’s ability to consider more evidence does not give it additional authority over tools, permissions, or release decisions.
For enterprise teams, operational readiness also means being able to assess a release and manage its availability. Cortex Code 2.0 was qualified through the live product experience, and the extended capability can be operated within the organization’s configured privacy requirements.
Private or confidential workflows retain their required protections when coding capacity changes. The amount of context a model can consider does not determine where customer information is permitted to go.
What the results establish and their limits
The qualification results support the expanded context claim and show retention of quality on the matched standard-task suite. They do not show that every task improves when more material is added.
Good context remains selective. A large collection of unrelated files can make a request harder to understand. Missing tests or ambiguous requirements cannot be solved by a larger window alone. Generated changes still need the validation appropriate to the software and the organization.
The 90.3% aggregate result describes Cortex’s controlled long-context qualification. It should not be compared directly with the 100% standard-task result because the suites measure different work. Nor should either number be presented as a universal customer success rate.
Cortex Code 2.0’s value is more concrete: it gives the coding specialist a substantially larger qualified range, demonstrates useful results across that range, and retains the established experience for ordinary coding work.
The next step for Cortex coding
Cortex Code 1.0 established the coding foundation within the Cortex AI Model Ensemble. Cortex Code 2.0 expands how much connected software evidence that capability can consider and makes the expanded capacity practical in the product.
For customers, the release means more room for the relationships that make engineering work difficult: requirements and implementation, interfaces and consumers, configuration and behavior, changes and tests.
The approximately 256K qualified range is a meaningful advance. Its value comes from how Cortex uses it: applying capacity to the task, preserving everyday coding quality, and delivering the result within an established ensemble of specialized capabilities.
Cortex Code 2.0 helps teams bring more of a complex software problem into view while keeping the coding experience responsive, measurable, and predictable.
