For context: the previous Opus model maxed out at 200K tokens. That's roughly 500 pages. Opus 4.6 pushes that to 1M tokens, or about 1,500 pages of text, 30,000 lines of code, or over an hour of video in a single prompt.

Why does this matter if you're building products? Because agents need context to make good decisions. The more context an agent can hold, the fewer mistakes it makes, the less you need to break problems into tiny pieces, and the less human babysitting is required. A 5x increase in context means agents can now work on entire codebases and full project scopes without losing track of what they're doing.

One important caveat: the 1M window is currently in beta. It's only available through the API and Claude Code (the command-line developer tool), not in the regular chat interface. You also need to be at usage tier 4 or have custom rate limits. If you're on a Pro subscription using claude.ai, you're still working with 200K tokens.

The real story: agent teams

Buried under the Opus 4.6 headlines is an experimental feature in Claude Code that deserves more attention: agent teams.

To understand why this matters, you need to know how Claude's agents worked before this.

Previously, Claude Code could spawn "subagents." These were helper agents assigned a specific task by the main agent. They did their work, reported back, and that was it. No communication between subagents. No collaboration. Just isolated task execution.

Agent teams work differently. Instead of silent workers reporting to a boss, you now get a coordinated team. A lead agent breaks down the work, spawns teammates, and those teammates can message each other directly, share findings, challenge each other's conclusions, and self-coordinate through a shared task list.

Think of the difference this way: subagents are like sending five people into separate rooms to each write a chapter of a book. Agent teams are like putting those five people around the same table where they can discuss, debate, and build on each other's work.

What this actually enables

The strongest use cases right now fall into a few categories:

Parallel investigation. Instead of one agent testing one hypothesis at a time, you can have multiple agents test competing theories simultaneously. One team member finds a potential root cause, another actively tries to disprove it. The theory that survives multiple agents trying to break it is far more likely to be correct.

Multi-layer development. Frontend, backend, and testing can each be owned by a different agent, working in parallel, aware of what the others are doing. Changes that span multiple layers of a product get built faster because agents aren't waiting in a queue.

Review and quality control. Three agents reviewing the same code through different lenses (security, performance, test coverage) will catch more issues than one agent doing three sequential passes. Each reviewer stays focused on their domain instead of context-switching.

The cost reality

Here's the part most people skip: agent teams are expensive.

Each teammate is a full Claude Code instance with its own context window. If you spawn a team of four agents, you're burning roughly four times the tokens you would with a single agent working sequentially.

This is almost certainly why agent teams are still labeled as experimental. The intelligence gain is real, but so is the bill.

The math works out when:

• The task is complex enough that parallel execution saves meaningful time

• The cost of developer hours saved exceeds the token cost

• Quality matters more than cost (debugging production issues, security reviews)

The math does not work out when:

• Tasks are sequential by nature and can't be parallelized

• Multiple agents would be editing the same files (this causes conflicts)

• The work is simple enough that one agent handles it fine

This introduces a new skill for teams building with AI: writing instructions that are precise enough to justify the cost of multiple agents working simultaneously. Vague prompts waste tokens across every agent in the team, not just one.