What Opus 5's Autonomous Performance Means for Enterprise Teams

Last month, Andrej Karpathy ran an experiment worth paying attention to. He gave Opus 5 the opening paragraph of The Lord of the Rings, a 1M token budget — roughly $10 — and a prompt asking for a three.js rendering of the story. The model ran for approximately two hours. It returned 5,500 lines of code that procedurally rendered the scene.

The point isn’t the Lord of the Rings. The point is that a model running autonomously, with sufficient context budget and a clear objective, can produce production-scale code output over a multi-hour session without a human in the loop. That’s a qualitatively different capability than what most enterprise teams are building their AI strategies around.

xychart-beta
title "Opus 5 Context Window vs. Typical Enterprise Use"
x-axis ["Document QA", "Contract Review", "Code Refactor", "Full Codebase Audit", "Karpathy Experiment"]
y-axis "Tokens used (thousands)" 0 --> 1100
bar [8, 45, 120, 380, 1000]

What Two Hours of Autonomous Work Actually Means

Most enterprise AI deployments treat the model as a fast responder — give it a prompt, get back a completion, move on. That’s a reasonable starting point. It’s also a significant underutilization of what current models can do.

Opus 5’s extended autonomous performance isn’t just a quantitative improvement. It changes the category of tasks that AI can handle. A model that can hold 1M tokens in context and work autonomously for hours can refactor an entire codebase against a new API contract. It can review every contract in a legal repository against a new regulatory requirement. It can analyze a full year of transaction records for anomalies that pattern-match to a specific fraud type.

These are not the tasks enterprise teams are currently deploying AI for. The bottleneck isn’t the model. It’s the infrastructure and organizational readiness to hand the model what it needs.

Why Most Enterprise Teams Can’t Access These Capabilities

The constraint isn’t model access. Any enterprise team can call the Opus 5 API. The constraint is whether the data those models need is structured, accessible, and clean enough to load into context at scale.

I spent time with First American Financial — the world’s largest title insurance company, with 770 applications and 900 engineers managing a 4TB SQL Server database containing 100 million US property records. The scale of what that organization managed was extraordinary. The challenge was not that the technology leadership lacked ambition or capability. It was that the systems had accumulated over decades of acquisitions, and the data was distributed across hundreds of applications with inconsistent schemas, undocumented integration contracts, and no unified access layer.

In that environment, loading a meaningful cross-system data set into a model context requires solving the data access and normalization problem first. The model can handle 1M tokens. Getting the right 1M tokens out of 80 acquired companies’ worth of infrastructure is a different project.

Most mid-market enterprise teams are not managing the scale of First American, but they face the same pattern at smaller scale: data spread across a handful of disconnected systems, inconsistent formatting, and no retrieval infrastructure that would make feeding a large model clean, relevant context a routine operation.

The Infrastructure Problem That Long-Context Models Make Visible

Karpathy’s experiment works because the input — a single paragraph of fiction — is clean, complete, and trivially portable. Enterprise tasks don’t have that property. The tasks that would benefit most from Opus 5’s extended context capability are the ones where the data is the hardest problem.

This is useful to understand, because it means the organizations that invest in data infrastructure now — clean access layers, normalized schemas, documented APIs, retrieval systems that can surface relevant records from large repositories — will be the ones that can extract disproportionate value from long-context model capabilities as they mature. The infrastructure investment is not contingent on knowing which model will dominate in two years. It is the prerequisite for using any capable model well.

The companies that will take advantage of a model that can work autonomously for two hours on a complex task are the ones that can hand the model a clean, well-structured problem. That’s a data and architecture problem, not a model selection problem.

What You Should Actually Be Doing Right Now

Two concrete steps, in order.

First, map the data your highest-value AI use cases require and identify where the access and quality gaps are. Don’t start with model selection. Start with whether you can give the model what it needs. That assessment takes a few weeks and shapes every subsequent decision.

Second, if you’re already running AI on shorter-context tasks, evaluate whether moving to longer-context approaches would change the quality or scope of the output. Code review tasks that currently run file by file may produce better results reviewed at the module or repository level. Contract analysis that currently runs document by document may surface patterns only visible across a full document set.

The capability is real. The question is whether your infrastructure is ready to use it.

Frequently Asked Questions

What does the 1M token context window in Opus 5 actually enable for enterprise teams?

A 1M token context window means the model can hold an entire codebase, a full legal document set, or a year of transaction records in a single context. That changes what's possible in tasks that require synthesizing large amounts of information — code refactoring across hundreds of files, contract analysis across a full document repository, or anomaly detection across a year of financial transactions. The constraint for most enterprise teams is not the model's capability — it's whether the data is accessible, organized, and clean enough to put into that context window. The model can handle the volume; most enterprise data architectures can't yet hand it over cleanly.

How should enterprise teams evaluate which Anthropic model to use for their use case?

Start with task complexity and context requirements. For high-volume, low-complexity tasks — document classification, email triage, content extraction — Haiku 4.5 processes faster and at a fraction of the cost. For tasks that require extended reasoning across large contexts — code review at scale, complex analysis, multi-step decision support — Opus 5 is the appropriate choice even at higher cost, because the output quality difference is real and measurable. The mistake most teams make is defaulting to the most capable model for everything, which inflates costs unnecessarily, or defaulting to the cheapest model, which produces results that don't hold up in production.

What infrastructure changes do enterprise teams need to make to take advantage of Opus 5's long-context capabilities?

Three things. First, data access: the documents, codebases, or transaction records the model needs must be accessible in a form that can be cleanly loaded into context. Most enterprise data is fragmented across systems, inconsistently formatted, or behind access controls that complicate machine access. Second, retrieval architecture: for repositories that exceed even a 1M token window, teams need a retrieval layer that surfaces the most relevant sections rather than loading everything. Third, evaluation frameworks: long-context tasks produce outputs that are harder to evaluate automatically than short-context tasks, so teams need human review pipelines or model-as-judge approaches that can assess quality at the scale they're running.