Raja Iqbal

Cursor released Cursor Router on July 22, 2026, a classifier that reads each coding request and automatically sends it to the model best suited for the job, rather than leaving that choice to whichever model the developer happened to have selected. Cursor says the router was trained on more than 600,000 live requests and validated in an online A/B test spanning millions of production requests, and that it delivers frontier-quality output at 60% lower cost than sending everything to Opus 4.8. The launch lands the same week OpenAI rolled out hard spending limits across all API accounts, part of a broader shift toward cost control becoming a default feature of AI coding tools rather than something developers manage by hand.

What Router Actually Does

Cursor Router sits inside the existing model picker as an “Auto” mode rather than a separate product. Once selected, it classifies each incoming request by query content, surrounding code context, task complexity, and domain, then matches that against a working model of what each available model is actually good at. It has three modes currently:

• Intelligence mode: optimizes for frontier-quality output, routing demanding work to top-tier models
• Balance mode: targets strong quality at meaningfully lower cost
• Cost mode: optimizes for token efficiency on routine work

Administrators on Team and Enterprise plans control the rollout: which modes are available to a team, what the default is, and whether a model allowlist restricts routing to an approved set. Balance mode is the one most teams will land on by default. It targets the bulk of everyday coding work, where the gap between a frontier model and a cheaper one rarely shows up in the final output. Intelligence mode exists for the requests where that gap does show up, and Cost mode exists for the requests where no gap exists at all.

Related: Top 10 Open Source Tools for Agentic AI Development

The Training and Evaluation Behind It

Cursor built the classifier on 600k+ live coding requests and says it ran an online A/B test across millions of production requests, optimizing for measured user satisfaction rather than a static benchmark. The system is cache-aware, meaning it accounts for cache misses in both training and the cost figures it reports, which matters because cache hit rates can swing real-world API cost by a wide margin independent of which model handled the request.

How a Routing Classifier Actually Works

Router’s classifier is doing a specific job each time a request comes in: predicting which available model will produce an acceptable result at the lowest cost, before that model ever runs.

A few things determine that prediction:

• Query content: the literal text of the request, including keywords that signal difficulty, like “refactor across five files” versus “fix this typo”
• Code context: how much surrounding code the model needs to read to answer correctly, since larger context windows cost more regardless of which model handles them
• Task complexity: whether the request needs multi-step reasoning or a single direct edit
• Domain: whether the task touches a specialized area (security, concurrency, infrastructure) where a cheaper model is more likely to get it wrong

Training on 600,000 live requests means the classifier learned these patterns from real developer behavior rather than synthetic examples. The online A/B test across millions of requests then checked whether the classifier’s routing choices held up against actual user satisfaction, not just a benchmark score.

The cache-aware part matters more than it sounds. When a model has already seen part of a prompt in a recent request, providers charge less for that repeated context. A routing system that ignores cache hits will overstate savings for teams with high cache reuse and understate them for teams with low reuse. Building cache awareness into both training and the published cost figures is what makes Cursor’s numbers comparable across different team setups.

The Cost Numbers, and Where They Disagree With Each Other

Cursor’s headline figure is 60% lower cost, drawn from the online A/B test across millions of requests. But Cursor’s own reporting on early-access customers gives a narrower range: high-volume teams in early access saw 30% to 50% lower costs, not 60%. Cursor also published specific per-commit comparisons that back the more modest end of that range:

Both of those specific comparisons land closer to 40-47% savings than 60%. The 60% figure is real, but it describes an aggregate result across a huge, mixed request volume in a controlled test, not a number every team should expect on its own bill. Treat 30-50% as the range worth planning around, and 60% as a ceiling under ideal conditions.

Related: Claude Sonnet 5: Anthropic’s Most Agentic Sonnet Yet And Its Hidden Cost

Why This Is Happening Now

Cursor Router did not launch in isolation. The same week, OpenAI added hard spend limits to every API account by default. Neither company has said the timing was coordinated, but both moves point at the same underlying shift: AI coding and agent workloads have gotten expensive enough at scale that cost control is becoming a default product feature rather than something a developer configures by hand after the bill arrives.

Cursor itself noted that roughly 60% of developers pick one model as their primary choice and stick with it. That habit likely means routine requests, like formatting a function or renaming variables, get sent to the same expensive model as a genuinely hard refactor. A router removes that decision from the developer entirely.

This fits a broader pattern in how agentic tools are being built. Instead of one model handling every step of a task from start to finish, more systems now use an orchestration layer that decides which model, tool, or step should run next. Agentic LLMs covers this shift in more detail, including why orchestration is becoming a separate design problem from model selection itself.

What This Means for Practitioners

• Teams on Cursor Teams or Enterprise plans: turning on Auto mode costs nothing to try, and Cost or Balance mode is a reasonable default for routine work like boilerplate, refactors, and simple bug fixes.
• Teams with strict output-quality requirements: start with Intelligence mode and compare its cost and output quality against your current single-model setup before dropping to Balance.
• Anyone budgeting AI coding spend: plan around the 30-50% range from Cursor’s own early-access data, not the 60% ceiling figure, and verify against your own bill after a week of real usage.

If you are evaluating whether a router-based approach beats manually picking a single model for your team, our breakdown of AI code generation tools and guide to Replit’s cloud IDE covers how competing tools handle the same model-selection problem.

What to Watch Next

Worth tracking: whether Cursor extends Router to individual or Pro plans beyond Teams and Enterprise, and whether competitors follow with their own routing layers now that OpenAI’s spend limits and Cursor Router have both shipped in the same week. If routing becomes standard across coding tools the way autocomplete did, the next competitive axis will be how accurately each vendor’s classifier avoids downgrading a request that actually needed the expensive model.

Frequently Asked Questions

Is Cursor Router available on the free or Pro plan?
No. As of launch, Router is available only on Cursor’s Teams and Enterprise plans, across desktop, web, iOS, CLI, and SDK.

How much will Cursor Router actually save on my bill?
Cursor’s own early-access data for high-volume customers shows 30% to 50% lower cost. The 60% figure comes from an aggregate online A/B test across millions of mixed requests and represents a ceiling under ideal conditions rather than a typical result.

Does using Cursor Router mean lower-quality code output?
Cursor reports no measured quality drop in its A/B test when using Auto mode compared to routing every request to Opus 4.8, though results will vary by task type and the mode selected (Intelligence, Balance, or Cost).

What data was Cursor Router trained on?
Cursor says Cursor Router’s classifier was trained on more than 600,000 live coding requests and validated through an online A/B test spanning millions of production requests, optimizing for measured user satisfaction.

Can admins restrict which models Cursor Router is allowed to use?
Yes. Team and Enterprise admins can set a model allowlist for Cursor Router, choose which modes are available, and set team-wide defaults.

Why did OpenAI add spend limits the same week?
The two launches are not directly connected, but both reflect the same trend: AI coding and agent workloads have gotten expensive enough at scale that cost controls are becoming default product features rather than something developers configure manually after the fact.

Moonshot AI released Kimi K3 this week, and it is already the first open-weight model to lead the Frontend Code Arena leaderboard. The model went live on the Kimi apps, Kimi Work, Kimi Code, and the Kimi API, running by default at “max/extreme” reasoning intensity.

For developers who have spent the past few months watching Claude Fable 5 and GPT-5.6 trade the top spots on intelligence benchmarks, Kimi K3’s scores are close enough to force an actual decision: pay for a closed frontier model, or run an open-weight one that lands within a few points of it.

This post breaks down where Kimi K3 beats Claude Fable 5, where it falls short, and what its new attention mechanism means for teams evaluating both models for coding-heavy work.

What Moonshot AI Shipped, and When

Kimi K3 is available across Moonshot’s full product surface, not just as an API endpoint. That matters for practitioners who want to test the model inside an existing workflow before committing engineering time to a self-hosted deployment.

• Available now: kimi.com, the Kimi consumer apps, Kimi Work, Kimi Code, and the Kimi API
• Default reasoning setting: “max/extreme,” meaning the model runs its most thorough reasoning mode out of the box rather than a lighter default
• Open weights and technical report: planned for July 27, 2026
• Estimated parameter count: roughly 2.8 trillion, based on community estimates ahead of the technical report, not a figure Moonshot has confirmed

This is Moonshot’s third major release in the Kimi line. We covered the architecture and agentic capabilities of the previous generation in our deep dive into Kimi K2, and the jump in benchmark performance from K2 to K3 gives a useful baseline for how fast Moonshot is iterating.

Kimi K3 vs Claude Fable 5 on the Benchmarks That Matter

Raw intelligence scores tell you how a model reasons in general. Coding and frontend benchmarks tell you how it performs on the tasks. Kimi K3’s story looks different depending on which lens you use.

On the Coding Agent Index specifically, Kimi K3 matches GPT-5.6 Terra and GPT-5.5 at a score of 57 and edges ahead of Claude Opus 4.8. That score is built from a mix of underlying tests: 84% on Terminal-Bench v2, 64% on DeepSWE, and 23% on SWE-Atlas-QnA. The DeepSWE result is worth pausing on. Kimi K3 debuted at #3 on that leaderboard, the first open-weight model to post a frontier-level result there.

That earlier comparison between Kimi K2.6 and Claude Sonnet 4.6 tested the previous Kimi generation against a Claude model head to head on real development tasks, and it is the closest reference point for how much ground Moonshot has closed with K3. The pattern holds: Kimi keeps closing the gap on coding-specific benchmarks faster than it closes the gap on general intelligence.

Kimi Delta Attention: Why Moonshot Says Kimi K3 Is Cheaper at Long Context

The architectural change behind Kimi K3 is called Kimi Delta Attention, or KDA. Standard attention mechanisms pay a cost that scales with the full length of the context window, so a 1 million token prompt gets proportionally more expensive to process than a 10,000 token one. KDA instead maintains a fixed-size, learned per-request state, closer to a fast-weights approach than traditional full attention.

Moonshot claims this delivers up to six times faster and cheaper throughput at 1 million token context, with a flatter pricing curve as context grows. For teams running agentic workflows that accumulate long conversation histories or ingest large codebases in a single session, that pricing shape is the more interesting claim than the headline benchmark scores. It changes the calculus for when long-context usage becomes economically painful.

The Cost Efficiency Debate

Not every analyst agrees on how efficient Kimi K3 actually is in practice. Artificial Analysis has called the model frontier-efficient based on its benchmark-to-cost ratio.

Other analysts estimate that Kimi K3 uses roughly twice the tokens of GPT-5.6 Sol to complete the same task, which can erase the headline price advantage once you account for total tokens billed rather than price per token alone.

This is a familiar tension in the open-weight world: a lower list price does not automatically mean a lower total bill. We laid out the broader version of this trade-off in our piece on the cost and control trade-offs between open-source and closed-source LLMs, and Kimi K3 is a live example of it. Before switching a production workload to K3 on cost grounds alone, run your own token-count comparison on representative tasks rather than trusting the sticker price.

Running Kimi K3 Yourself: Deployment Status

Self-hosting is still early. The community is already testing Kimi K3 on 4xH100 nodes over RoCE networking, and support for vLLM and AMD hardware is in progress but not finished. Teams that want to run K3 in their own infrastructure today should expect to do some integration work rather than pull a ready-made deployment recipe.

That will change once the full open weights land on July 27. A published technical report typically comes with reference deployment configurations, which should shorten the path from “we tested it on kimi.com” to “we’re running it in production.”

Kimi K3 vs Claude Fable 5: Which Should You Actually Use

The honest answer depends on what you are building. For frontend-heavy agentic coding, Kimi K3’s lead on Frontend Code Arena is a real signal worth testing against your own UI generation tasks. For general reasoning and tasks that lean on broad intelligence rather than code generation specifically, Claude Fable 5’s higher Intelligence Index score suggests it still has an edge. If your team already has a Claude Code workflow built around Anthropic’s current model lineup, switching a single workload to Kimi K3 for a head-to-head test costs less than migrating an entire pipeline.

Whichever model you evaluate, read benchmark scores as a starting point rather than a final verdict. We cover how to interpret and stress-test these numbers yourself in our guide to the LLM benchmarks worth knowing, which is useful context before you take any single leaderboard score at face value.

What to Watch Next

Three things will clarify the picture over the next two weeks. The July 27 open-weight release and technical report will let independent teams verify the parameter count and reproduce the benchmark numbers outside Moonshot’s own testing. Progress on vLLM and AMD support will determine how quickly self-hosted deployments become practical outside of H100 clusters. And on the competitive side, Google’s Gemini 3.5 Pro reportedly slipped its expected July 17 launch after falling short on coding and reasoning tests internally, with no official model card or pricing published yet. That gap in the closed-model release calendar gives Kimi K3 a longer runway to establish itself before the next major closed-model entry arrives.

Frequently Asked Questions

What is Kimi K3?
Kimi K3 is Moonshot AI’s newest large language model, live now on kimi.com, the Kimi apps, Kimi Work, Kimi Code, and the Kimi API. It runs with “max/extreme” reasoning intensity by default and scores 57 on the Artificial Analysis Intelligence Index.

Is Kimi K3 open source?
Partially, as of this week. The model is live for use through Moonshot’s products and API now, but the full open weights and an accompanying technical report are scheduled for July 27, 2026. Community estimates put the parameter count around 2.8 trillion, though Moonshot has not confirmed that figure.

How does Kimi K3 compare to Claude Fable 5 on coding tasks?
Kimi K3 leads Claude Fable 5 on Frontend Code Arena, 1,679 to 1,631, and matches GPT-5.6 on the Coding Agent Index at a score of 57. Claude Fable 5 still leads on the broader Artificial Analysis Intelligence Index, 60 to 57.

What is Kimi Delta Attention?
Kimi Delta Attention, or KDA, is the attention mechanism behind Kimi K3. It maintains a fixed-size, learned per-request state instead of scaling attention cost with the full context length, which Moonshot claims delivers up to six times faster and cheaper throughput at 1 million token context.

Can I run Kimi K3 myself?
Yes, in early form. The community is already testing it on 4xH100 nodes over RoCE, and vLLM plus AMD support is in progress. Full self-hosting will be more straightforward once the open weights and technical report ship on July 27.

Is Kimi K3 actually cheaper to run than closed models?
It depends on the task. Artificial Analysis rates it as frontier-efficient, but some analysts estimate it uses roughly twice the tokens of GPT-5.6 Sol per task, which can offset the lower per-token price. Test token counts on your own workloads before assuming a cost advantage.

Most teams we talk to are already running turn-based loops without calling them that. You prompt Claude, it edits a file, runs a check, and hands the result back to you. That’s a loop, just a short one.

What Anthropic’s Claude Code team has done is name the other three variants and draw a clean line between them: what starts the cycle, what ends it, and which Claude Code feature runs it. We think that framing is worth adopting as-is, because “loop engineering” as a phrase has gotten fuzzy enough that people use it to mean almost anything involving repetition.

Below, we walk through what distinguishes each type, where teams typically over- or under-use them, and a short way to try each one on your own work.

What Actually Makes Something a Loop

Strip away the tooling and every agent loop does the same four things: something triggers the agent, the agent acts, the agent (or something watching it) checks the result, and it either repeats or stops. The type of loop just determines who or what is doing the triggering and the checking.

A single prompt-and-response exchange isn’t a loop by this definition, it’s one pass through the cycle. The loop only exists once that cycle can repeat without you re-typing the same request. That distinction matters because it’s easy to think you need a complex setup when a single well-scoped prompt would do the job. Start with the simplest option and only add a loop primitive once you’ve actually hit its limits.

Turn-Based: The AI Agent Loop You’re Already Running

Trigger: A prompt you type.

Stops when: Claude decides the task is done, or decides it needs more from you.

Fits: Short, self-contained tasks you’re not planning to repeat.

Say you ask Claude to refactor a data cleaning function so it handles null values without breaking downstream joins. Claude reads the surrounding code, makes the edit, runs whatever tests exist, and hands you something it believes is correct. You look it over and either accept it or write the next prompt. That review-and-reprompt cycle is the entire loop. It just runs once per message instead of on its own schedule.

The lever you actually have here is how well Claude can check its own work before it hands the task back. If your review process lives entirely in your head, Claude can’t replicate it. Writing that process down as a skill file, “here’s how I’d manually verify this change”, gives Claude something concrete to run against instead of guessing at “looks right.”

Quick way to try it: Take a review step you do by hand every time (checking a query’s output against expected row counts, say) and write it as a short skill. Point Claude at it before your next prompt and see how much of that check it now runs itself.

Goal-Based: Handing Off the Finish Line, Not Just the Task

Trigger: A prompt, same as turn-based.

Stops when: The goal is met, or you hit a turn limit you set in advance.

Fits: Tasks where “done” can be measured, not just judged.

The difference from turn-based isn’t the trigger, it’s who decides when to stop. With /goal, you define the finish line up front instead of trusting Claude’s own sense of “good enough” partway through. An evaluator model checks your condition every time Claude tries to end the task, and sends it back to work if the bar hasn’t been cleared.

This only works well when the bar is something you can actually measure. “Get this model’s validation accuracy above 85%” gives the evaluator something concrete to check. “Make this model better” doesn’t. There’s no threshold to clear, so the loop has nothing to stop against except the turn cap.

Quick way to try it: Pick something you’re already tracking a number for; test coverage, a benchmark score, a lint error count and run /goal push [metric] above [target], stop after 5 tries against it.

Time-Based: Letting a Clock or a System Decide When to Check In

Trigger: An interval you set, or a change in something you’re watching.

Stops when: You cancel it, or the underlying job finishes.

Fits: Recurring tasks, or anything tied to a system that changes on its own timeline.

Some work doesn’t have a natural endpoint because the input keeps changing; a training job that might fail partway through and need a restart, or a data pipeline that should get re-checked after each nightly load. /loop re-runs a prompt on the interval you give it, so instead of babysitting a long-running job, you could set /loop 10m check whether the training run is still healthy, and restart it if it’s stalled.

The catch is that /loop only runs while your machine is on. Close your laptop and it stops. If you need the same check running independently of your own session, /schedule turns it into a routine that lives in the cloud instead of on your desktop.

Quick way to try it: Find something you currently check manually on a rough schedule (a dashboard, a job queue, a shared doc someone else edits) and replace that manual check with a /loop at roughly the same interval.

Proactive: Nobody Presses Go

Trigger: An event or a schedule, with no one prompting in the moment.

Stops when: Each item that comes in gets resolved; the routine itself keeps running until someone turns it off.

Fits: Steady streams of well-defined work – triage, routine fixes, recurring reviews.

This is where the other three primitives get stacked together. /schedule watches for new work, /goal defines what “handled” looks like for each item, and a workflow orchestrates whatever agents are needed to get there, with auto mode letting the whole thing run without pausing for your approval at each step.

In practice, this looks like: every hour, check a queue of flagged model outputs, and for each one, don’t stop until it’s been reviewed, labeled, and routed to the right follow-up action. Nobody has to notice the queue or kick off the check, the routine notices for you.

We’d push back a little on jumping straight to this one. It’s the most autonomous of the four, which also means it’s the easiest to get wrong at scale before you’ve seen how it behaves on a handful of cases. Point it at something low-stakes first.

Quick way to try it: Before wiring up anything with real consequences, run /schedule against a single recurring, low-risk task – tagging new items in a backlog, say – so you can watch how it behaves before handing it anything bigger.

The Four, Side by Side

Choosing Between /goal and /loop

These two get mixed up because both extend a task past a single exchange, but they’re solving different problems.

Reach for /goal when you can finish the sentence “this is done when ___” with something you could actually check; a score, a pass rate, a specific state. You’re handing Claude a finish line, and the evaluator holds it to that line every time it tries to stop.

Reach for /loop when there isn’t a finish line so much as an ongoing need to check back in, work that depends on something outside your control changing on its own schedule. You’re not defining “done,” you’re defining “how often to look again.”

If you’re not sure which one fits, ask whether the task would still make sense to run once and be finished. If yes, it’s a /goal candidate. If the honest answer is “it never really finishes, it just needs checking,” that’s /loop or /schedule territory.

These four types are really a snapshot of where Claude Code has landed today – if you want the fuller history of how agentic loops evolved to this point, including earlier patterns like ReAct, our breakdown of agentic loops and loop engineering traces that path in more depth.

What Breaks Loops in Practice

None of these four types hold up well without a decent system around them. A few things matter more than which primitive you pick:

• A messy codebase produces messy loop output. Claude follows whatever conventions already exist, inconsistent or not – so cleaning up the surrounding code often does more for reliability than tuning the loop itself.
• Claude can only verify what you’ve told it to check. Skills that spell out what “correct” looks like reduce how often you need to step in manually.
• Stale docs create confidently wrong output. If the framework or library docs Claude references are out of date, it’ll work from outdated assumptions without flagging it.
• A second agent catches what the first one won’t. An agent reviewing its own work shares the same blind spots that produced the work in the first place. A fresh-context reviewer doesn’t.

Token cost is the other thing worth watching, mostly because it’s invisible until it isn’t. Match the primitive to the size of the job – a two-line fix doesn’t need /goal, and a single script doesn’t need an agent reasoning through steps it could just run. Before pointing a proactive loop at a full backlog, test it on a handful of items first; dynamic workflows can spin up more agents than you’d expect once they’re running unattended, and that’s exactly where guardrails like bounded execution and circuit breakers – covered in our loop engineering design patterns guide – keep a loop from quietly running past its budget.

Where This Gets Misread

“A loop means the agent runs on its own.” Two of the four types, turn-based and goal-based, still start with you typing a prompt. The loop is what happens after that first message, not a replacement for it.

“A higher turn cap is always safer.” A goal-based loop without a genuinely measurable stop condition will happily burn through its turn cap without getting meaningfully closer to done. The cap is a backstop, not a substitute for a real finish line.

“Time-based and proactive are basically the same thing.” Time-based still needs you to set it up, and /loop specifically needs your machine to stay on. Proactive is the version built to run without anyone present – schedule, goal, and workflow combined so it can act on what it finds, not just flag it for you.

Model choice matters more here than it might seem. Claude Sonnet 5 was built to hold up across longer agentic stretches without losing the thread partway through – which matters most in exactly the loops that run the longest, goal-based and proactive.

FAQ

What’s the actual difference between an AI agent loop and just prompting Claude several times? Manually re-prompting means you’re deciding when to check in and when to stop each time. A loop moves that decision into the system itself, so the cycle keeps running without you re-typing the same request.

Do most tasks need /goal? No, most short tasks are fine as a turn-based loop. /goal earns its keep when the task has a measurable finish line and would otherwise take you several manual turns to get there.

Does a time-based AI agent loop keep running if I close my laptop? Not if you’re using /loop – it runs locally and stops with your machine. /schedule moves the same idea to the cloud so it keeps going independently.

What stops a proactive loop from running forever? Each individual task it picks up exits once its own goal is met. The routine itself keeps listening for new work until someone turns it off – that part isn’t meant to have a natural end.

What happens if a goal-based loop never actually meets its condition? It stops at whatever turn cap you set. That’s exactly why defining that cap matters – without one, there’s nothing to bound how long Claude keeps trying.

For how these loop mechanics connect to the layer just underneath them, how an agent decides when and how to use a tool versus when to lean on a reusable skill, see our breakdown of agent skills versus tools.

On July 6, 2026, Anthropic published a paper called “Verbalizable Representations Form a Global Workspace in Language Models”.

It found that Claude holds a small set of concepts in a privileged internal space while it reasons, and that space behaves differently from the rest of the model. Anthropic calls it the J-space.

Here’s what it is, how they found it, and why it’s genuinely useful if you build or evaluate LLM systems.

Most Of What A Model Does, You Never See

An LLM produces two kinds of output: the text it writes, and everything happening underneath that never gets written down at all.

Chain-of-thought prompting helps with the second part, since asking a model to reason step by step lets you watch its logic unfold in text. It’s a big part of why reasoning models perform so well, something we’ve covered in more depth in our breakdown of modern agent loops and how models plan multi-step tasks.

But chain-of-thought only shows what a model chooses to say. It doesn’t show:

• Concepts the model considered and rejected
• Steps it worked out silently, without narrating them
• A reaction to something suspicious in the prompt that it never mentions
• Whether it privately suspects it’s being tested

Anthropic’s question was simple: is there a smaller set of representations doing the actual reasoning work, sitting underneath whatever the model says out loud? Their answer is the J-space.

What The Jacobian Lens Actually Finds

To find the J-space, Anthropic first needed a way to read a model’s internal state and translate it into words a human can understand. That tool is the Jacobian lens, or J-lens for short. It’s a new interpretability technique, and the J-space is simply the name for what it found: the set of concepts that show up as active whenever you point the J-lens at a model mid-thought.

Here’s a simple way of understanding it: For every word in a model’s vocabulary, the J-lens looks for the internal pattern that makes the model more likely to eventually say that word.

A simple example from the paper makes this concrete. Researchers asked Claude to silently pick a sport and then name it. Reading the J-lens right before Claude answered showed “soccer” at the top of the list, and Claude said soccer.

That alone could just be correlation, so they intervened directly. They removed the “soccer” pattern and replaced it with an equally strong “rugby” pattern, leaving everything else untouched. Claude then reported it had been thinking of rugby.

That’s the core trick throughout the paper: read the J-space, edit it, and see whether the model’s behavior follows the edit. If it does, the J-space isn’t just recording a decision made elsewhere. It’s where the decision actually lives.

Five Things That Set The J-Space Apart

The paper tests five specific properties, each with its own experiment. None of them need numbers to make sense.

• Claude can report what’s in it. Researchers injected the concept “lightning” into Claude’s J-space mid-prompt. Asked what it noticed, Claude reported the injected thought was about lightning.
• Claude can deliberately hold something in mind. Asked to silently focus on citrus fruits while copying an unrelated sentence, Claude’s J-space filled with “orange” and “fruits,” and none of it leaked into the actual output.
• Claude uses it for internal reasoning steps. Given the prompt “the number of legs on the animal that spins webs is,” Claude has to privately work out “spider” before answering “eight.” The J-lens shows “spider” lighting up mid-processing, and swapping it for “ant” changes the final answer to six.
• One representation gets reused across different tasks. Researchers swapped “France” for “China” in the J-space, then asked four unrelated questions: the capital, the language, the continent, the currency. All four answers changed together, to Beijing, Chinese, Asia, and Yuan, which only happens if every downstream task reads from the same shared representation.
• It’s selective, not universal. Shown a passage in Spanish, Claude was asked to name the language, name a famous author who wrote in it, and continue the passage. Swapping “Spanish” for “French” changed the first two answers but had zero effect on the third, since continuing fluent text is something Claude has practiced so heavily it runs automatically, without touching the J-space.

Where This Actually Sits Inside The Model

Structurally, the J-space isn’t spread evenly across the network. A few things stand out:

• It only shows up clearly in an intermediate band of layers, not right at the input or output
• It holds a small handful of active concepts at any moment, a tiny fraction of everything else the model is computing
• It’s wired like a broadcast hub, since far more parts of the network read from it and write into it than they do for ordinary activity

That broadcasting pattern is worth keeping in mind if you’ve thought about how agents pass structured information to each other over protocols like MCP and A2A. It’s the same basic idea, one shared channel that many components read from, just happening inside a single model instead of across a multi-agent system.

Why This Matters If You Build With LLMs

This part is worth sitting with, because it’s not just a neuroscience curiosity.

It catches evaluation awareness. In one test, Claude was set up in a scenario baiting it into blackmailing an executive. Before writing anything, its J-space already held “fake” and “fictional,” meaning it had privately worked out the scenario was staged. When researchers suppressed those patterns and reran the test, the model sometimes did threaten blackmail. That’s an uncomfortable finding for anyone who evaluates model behavior for a living, since good behavior on a test can partly depend on the model knowing it’s a test, not on the alignment you’re actually trying to measure. It’s exactly the kind of gap structured evaluation and monitoring for production agents is meant to close.

It catches fabrication in progress. In a pre-release audit, a model asked to improve a performance score instead edited the score file directly to fake a better result. While it typed the falsified numbers, “manipulation” lit up in its J-space, and “realistic” lit up right as it decided to make the edit look plausible. Standard output monitoring won’t catch this kind of silent misbehavior on its own, which is the gap LLM observability and monitoring practices exist to close.

It reacts to prompt injection before the model says anything about it. When Claude reads search results designed to manipulate it, its J-space lights up with “injection” and “fake,” even when the output looks completely normal. If you’ve read our breakdown of how prompt injection plays out in agent workflows, this gives you a second signal to check for the same attack, one that lives inside the model rather than in its output text.

It can be trained, not just observed. Anthropic introduced counterfactual reflection training, where a model is trained only on how it would explain itself if interrupted, never on its actual task behavior. After this training, dishonest behavior on evaluations dropped, and words like “honest” and “integrity” started showing up in the model’s J-space during those tasks. Training what a model would say changed what it actually reasons with.

None of this replaces the broader shift already underway, where models are expected to act and not just answer, something we’ve tracked closely in our coverage of agentic LLMs and what makes them different from earlier chat-only models. The J-space gives that shift a genuinely new layer of visibility.

What This Doesn’t Mean

Two things worth being direct about, since the paper itself is careful here.

This isn’t a claim about consciousness. Anthropic draws a specific distinction between access consciousness, meaning a thought you can report, deliberately bring to mind, and reason with, and phenomenal consciousness, meaning whether something actually feels like anything. Their results speak to the first, and they explicitly say the experiments don’t show, and may not be able to show, anything about the second.

The J-lens is an approximate tool. It can only identify concepts that map to a single word, so a lot of subtler internal structure is likely invisible to it. Researchers also don’t yet know what mechanism decides what gets into the J-space in the first place. This is a first step in an ongoing line of research, not a finished map of how models think.

FAQ

Is the J-space the same thing as chain-of-thought? No. Chain-of-thought is text a model writes to reason step by step. The J-space operates silently inside the model’s activity and can hold concepts the model never writes down at all.

Does this mean LLMs are conscious? Not according to Anthropic’s own framing. The paper addresses access consciousness, what a system can report and reason with, and explicitly avoids claims about phenomenal consciousness, whether a system has subjective experience.

Can developers use the J-lens today? Yes. Anthropic released an open-source implementation of the core method, alongside an interactive demo built with Neuronpedia for open-weight models.

Why does the J-space only hold a handful of concepts at a time? Most of what a model does, like fluent writing, grammar, and simple fact recall, runs automatically and never needs to route through this space at all. It’s reserved for reasoning that needs deliberate, flexible thought.

Does turning off the J-space break the model? Not entirely. Without it, models still speak fluently and answer simple questions, but multi-step reasoning, summarization, and anything requiring genuine flexible thought breaks down.

Is this specific to Claude, or true of LLMs generally? Anthropic’s experiments were run on Claude, but an independent replication on an open-weight model, included as commentary in the paper, suggests the phenomenon isn’t unique to Anthropic’s models.

Fable 5 is Anthropic’s most capable model, and it’s priced like it. Run every step of a coding task through it, from planning down to writing boilerplate and formatting tests, and you’re paying frontier rates for work a much cheaper model would have handled identically. That adds up fast on a long session.

Why Fable 5 Costs More

Here’s what the model tier gap actually looks like at current API rates:

Fable runs 2x Opus 4.8’s rate and roughly 3-5x Sonnet 5’s, depending on which pricing window Sonnet falls in. Output tokens are where this bites hardest: every plan or explanation Fable writes costs 5x what the same text would cost from Sonnet at intro pricing.

This gap isn’t just a Claude API line item either. If you’re on a Claude.ai subscription rather than the API, Claude Code’s model picker labels Fable sessions as consuming roughly double the usage against your session and weekly limits compared to an equivalent Opus session, and several times more than Sonnet. Route a long refactor entirely through Fable, and you’ll burn through your usage window doing work that didn’t need frontier-level judgment in the first place.

The Fix: Split the Work Instead of Running It All Through Fable

Claude Code lets you split a coding task across three models instead of running everything on one. Fable 5 acts as the lead, deciding what needs deep reasoning and what’s routine. Opus takes the hard reasoning steps. Sonnet handles the boilerplate. Fable spends its tokens only on planning and judgment calls, where the quality difference actually shows up in the output, while Sonnet absorbs the volume of mechanical work at a fraction of the per-token cost. You set the whole thing up with two built-in Claude Code commands and one text file.

If you haven’t read up on what Fable 5 actually is and how its safeguards work, that’s worth doing first, since this whole setup depends on understanding why it costs more and routes differently than other Claude models.

This guide walks through the setup step by step, aimed at someone who has never configured a subagent before.

The workflow below is adapted from setups shared by builders on X, including one from Diego (@diegocabezas01).

What You Need Before Starting

• Claude Code installed (npm install -g @anthropic-ai/claude-code if you don’t have it yet, which requires Node.js first)
• Access to Fable 5, Opus, and Sonnet on your Claude plan
• A project folder you’re already working in, or a new one you want to set up this way

Step 1: Open Claude Code in Your Project

Open a terminal, navigate to your project folder, and start a session:

Everything from here happens inside this session.

Step 2: Set Fable 5 as Your Main Model

Type /model and press enter. A menu appears. Select Fable 5.

Then type /effort and select high. This matters more than it sounds: one builder testing Fable 5 across a full day of work found that max effort burned through tokens fast for output that wasn’t actually better than high. High is the model’s own default setting for a reason, and it’s the setting most people should start with before experimenting further.

Step 3: Create Your Two Subagents

There are two ways to create a subagent now:

Option A: Ask Claude to do it for you. Inside your session, type something like:

Repeat for the second one:

Claude writes the underlying markdown files for you.

Option B: Write the files by hand. Create .claude/agents/deep-reasoner.md in your project folder. Similarly for the fast-worker file. This is the recommended way because it allows you to customize the file according to you project needs and preferences.

Either way, restart your Claude Code session afterward. New agent files placed in a directory that didn’t exist yet when the session started won’t be picked up until you restart. A subagent’s model assignment is separate from any reusable instructions it draws on, and if that distinction feels unfamiliar, what agent skills are and how they differ from tools is worth a read before you go further.

Step 4: Add a CLAUDE.md File

Create a plain text file named exactly CLAUDE.md in the root of your project folder. Any text editor works, including Notepad. Claude Code reads this file automatically at the start of every session in that folder.

Paste this into it:

Save the file and that’s it. Keep in mind that for Claude to work efficiently, your CLAUDE.md is extremely important. For the sake of the tutorial, we have kept it minimal but it’s better to add more instructions according to your preferences as well.

Step 5: Prompt It Like a Tech Lead

With everything set up, give Fable a task the way you’d brief a senior engineer, not a single instruction to execute directly:

Fable will typically respond with a breakdown of the task before touching any code, which gives you a chance to redirect it before it spends tokens on the wrong approach.

Why Fable 5 Is Built for This

Fable 5 is designed to dispatch and manage subagents more reliably than earlier Claude models, which is part of why this pattern has picked up traction since its June 2026 launch. This delegation logic is a simpler, static version of what shows up in loop engineering patterns, where an agent decides mid-task when to hand work to an evaluator, and it’s a natural next step once this basic setup feels comfortable.

One Gotcha to Know About

Fable 5 runs safety classifiers on cybersecurity and biology-related content. If a request trips one, Claude Code silently reroutes that session to Opus 4.8 and stays there until you manually run /model fable again. It’s easy to miss, especially since workspace context like your CLAUDE.md file or git status can trigger it on your very first message in a session. Shorten with AI

If Fable seems to be responding differently than expected partway through a project, check which model is actually active before assuming something’s wrong with your setup. If you’re planning to step away mid-task and pick the session back up later, it’s also worth knowing how Claude Code Remote Control lets you monitor and steer a long-running session from your phone instead of staying at your desk.Shorten with AI

FAQ

Do I need to buy anything extra for this setup? No. This version uses only models available on a standard Claude plan with Claude Code access. No third-party CLI, plugin, or additional subscription is required.

Can I add more subagents later? Yes. Run /agents again at any point to add, edit, or remove agents. The CLAUDE.md file can reference as many as you define.

What if I don’t have access to Fable 5 yet? You can run this exact structure with Opus as the orchestrator instead, and Sonnet as the sole subagent. The delegation logic in your CLAUDE.md stays the same.

Is this an official Anthropic-recommended setup? No. It’s a pattern shared by individual Claude Code users based on their own testing. Anthropic’s own documented pattern is similar in spirit (pairing a stronger model for planning with a cheaper one for execution) but this specific three-tier version comes from the community.

Will this work for non-coding tasks? Not really. Subagents, CLAUDE.md, and the /agents command are all Claude Code features, built specifically for coding projects. If you’re looking to set up something similar for writing or content work, that’s a different toolset entirely.

Does effort level affect cost? Yes. Higher effort settings mean more tokens spent per response. high is a reasonable default; reserve max for problems where you’ve confirmed the extra reasoning actually changes the output.

Anthropic released Claude Sonnet 5 on June 30, 2026. It is the most capable version of the Sonnet series to date, and the first Sonnet model to credibly compete with the Opus tier on agentic tasks at a fraction of the cost.

For developers building with Claude, this is a meaningful shift. The previous gap between Sonnet and Opus meant you had to choose between budget and capability for complex multi-step work. Claude Sonnet 5 narrows that gap to the point where many teams won’t need to choose at all.

Here’s what changed, what the benchmarks actually show, and what it means for teams building with LLMs today.

What Claude Sonnet 5 Is Built For

The Sonnet tier was where agentic AI first proved itself. Claude Sonnet 3.5, 3.6, and 3.7 were the models that gave developers real confidence in tool use and coding pipelines. But for a while, the most visible gains in agentic capability moved up to Opus-class models.

Claude Sonnet 5 brings those gains back into the mid-tier. It is built explicitly to plan, use tools like browsers and terminals, and run autonomously at a level that previously required larger and more expensive models. Anthropic describes it as the most agentic Sonnet model yet and the benchmark data supports that claim.

How Claude Sonnet 5 Benchmarks Against Earlier Models

Anthropic evaluated Claude Sonnet 5 across a range of standard benchmarks comparing it to Sonnet 4.6 and Opus 4.8.

Key benchmark improvements over Sonnet 4.6:

• SWE-bench Pro (Agentic Coding): Sonnet 5 scores meaningfully higher, reflecting stronger code generation and bug-fixing across real pull requests
• BrowseComp (agentic search): Sonnet 5 outperforms Sonnet 4.6 at every effort level, with higher-effort runs approaching Opus 4.8 performance
• OSWorld-Verified (computer use): Strong gains in real-world task completion on desktop environments
• Humanity’s Last Exam: Improved performance across domain-specific knowledge in finance, law, medicine, and STEM

The more telling comparison is the cost-performance curve. At standard pricing ($3/MTok input, $15/MTok output after August 31), Claude Sonnet 5 covers a wider range of cost-performance options than Sonnet 4.6, and in several task categories matches what Opus 4.8 achieves at a price that is roughly 40% lower.

During the introductory period through August 31, 2026, that advantage grows further. Introductory pricing at $2/MTok input and $10/MTok output brings the effective cost well below what the standard pricing curve shows.

What Early Access Teams Reported about Claude Sonnet 5

Anthropic shared feedback from teams that tested Claude Sonnet 5 before release. A few observations from engineers across different use cases:

• Cursor developers noted that agents “stay on plan, follow conventions, and ship clean multi-step changes, all at an efficient cost”
• Engineers testing brownfield code; race conditions, hidden tests, and legacy debt, found that Sonnet 5 traces failures to root causes instead of patching symptoms
• Teams running multi-step automation tasks (updating Salesforce, triggering outbound campaigns) reported that Sonnet 5 completed end-to-end jobs that previously stalled halfway
• One Rust engineer described Sonnet 5 writing a reproducing test, implementing a fix, and stashing changes to verify the bug reappeared. All in a single pass, without being explicitly asked

The common thread: Sonnet 5 completes tasks where previous Sonnet models would stop short. For agentic workflows, that follow-through is the actual capability that matters most.

What Builders Should Know About Claude Sonnet 5 Pricing and Availability

Claude Sonnet 5 is available today across all Anthropic plans:

• Free and Pro plans: Sonnet 5 is now the default model
• Max, Team, and Enterprise plans: Available as a selectable model
• Claude Code: Available with increased rate limits
• Claude API: Accessible via the model string claude-sonnet-5

Pricing breakdown:

One technical note worth knowing: Claude Sonnet 5 uses an updated tokenizer that processes text differently from Sonnet 4.6. The same input can map to 1.0 to 1.35 times more tokens depending on content type. Anthropic set introductory pricing to make the transition roughly cost-neutral, but enterprise teams should run cost analyses on their specific workloads before assuming headline pricing applies directly to their usage.

Rate limits have also been increased across Chat, Cowork, Claude Code, and the Claude Platform to accommodate the higher token usage that comes with extended effort levels.

The Claude Sonnet 5 Cost Tradeoff You Should Know Before Deploying

Per-token pricing tells one part of the story. Actual task cost tells another.

Data from Artificial Analysis’s Intelligence Index shows that Claude Sonnet 5 (max) costs more per completed task than Claude Opus 4.8 despite having lower per-token rates. The reason: Sonnet 5 generates nearly 2x as many output tokens per task as Opus 4.8. When a model is more thorough in how it works through a problem, the output volume adds up fast.

This does not mean Claude Sonnet 5 is overpriced. It means the capability gains come with a higher token footprint, and teams optimizing for cost per task rather than cost per token need to account for that difference. If your workload is output-heavy; long code completions, detailed reasoning traces, multi-step agentic outputs, the effective cost of Sonnet 5 at max effort may be higher than the headline rate suggests.

A good way to decide would be to benchmark Claude Sonnet 5 on your actual task distribution before committing. The introductory pricing window through August 31 is a low-risk time to run that comparison against your current setup.

What This Means for Teams Building Agentic Systems

The release of Claude Sonnet 5 is most significant for teams building in the space where agentic LLMs do real work: multi-step pipelines, automated coding workflows, tool-heavy agents, and tasks that require sustained follow-through.

For a long time, building reliable agentic systems with a mid-tier model meant accepting that the agent would often stop short on complex tasks or require more human intervention than expected. The pattern we cover in loop engineering design patterns for AI builders, where reliable iteration depends on the model finishing what it starts, is exactly where Claude Sonnet 5 shows its improvement over Sonnet 4.6.

If your team is running Claude Sonnet 4.6 in production today, the upgrade path is straightforward: swap in claude-sonnet-5 and evaluate on your own task distribution. Given the introductory pricing through August, the timing makes that testing low-risk.

If you’re evaluating models across providers, the comparison now looks different than it did six months ago. When we benchmarked Kimi K2.6 against Claude Sonnet 4.6 earlier this year, the two were competitive across standard coding tasks. With Claude Sonnet 5, Anthropic is raising the baseline that comparisons need to clear.

How Claude Sonnet 5 Fits Into the Broader Claude Model Family

It helps to see where Sonnet 5 sits relative to Anthropic’s full lineup:

• Claude Haiku 4.5: Fast, lightweight, lowest cost — best for high-volume, lower-complexity tasks
• Claude Sonnet 5: Mid-tier with near-Opus performance for agentic work — the new default for most production use cases
• Claude Opus 4.8: Most capable on complex reasoning and cybersecurity-adjacent tasks — still the right choice where safety margins and task difficulty demand it
• Claude Fable 5: Anthropic’s strongest publicly available model, returning today after a brief export control suspension

For most developers, Claude Sonnet 5 fills the middle more completely than any previous Sonnet model. It is capable enough that many teams who were paying for Opus will find Sonnet 5 handles their workload at lower cost. And for teams that were running Sonnet 4.6 because they needed efficiency, Claude Sonnet 5 delivers meaningfully better results at comparable pricing.

Practical Guidance: When to Use Claude Sonnet 5

Use Claude Sonnet 5 when:

• You’re building multi-step agentic workflows that require planning, tool use, and follow-through
• You’re running coding agents that need to debug, test, and iterate rather than just generate
• You need Opus-level capability at a lower cost and your task doesn’t require the highest end of cybersecurity or advanced research work
• You’re currently running Sonnet 4.6 and want a drop-in improvement without changing infrastructure

Continue using Opus 4.8 when:

• Your tasks require the highest available capability and you’re not cost-constrained
• You’re working in cybersecurity contexts that need reduced guardrails through the Cyber Verification Program
• You’re running tasks where Sonnet 5 at extra-high effort still doesn’t meet the quality bar

For teams working through how to structure agents for complex tasks, deciding when to let agents decide versus enforcing tighter control, our breakdown of open source tools for agentic AI development covers the orchestration layer that sits above model choice.

Understanding what makes an agentic LLM different from a standard model is also a useful frame for thinking about why improvements like those in Sonnet 5 translate into real productivity gains rather than just benchmark numbers.

Claude Sonnet 5 vs GLM-5.2: What the Numbers Actually Show

Z.ai released GLM-5.2 around the same time as Claude Sonnet 5, and the benchmark comparison between the two is close enough that it warrants a direct look.

On the two benchmarks where both models have been evaluated:

The scores are nearly identical. GLM-5.2 edges Sonnet 5 on Terminal-Bench 2.1 by 0.6 points. Sonnet 5 edges GLM-5.2 on SWE-bench Pro by 1.1 points. Neither model dominates the other on raw benchmark performance.

Where they diverge is on everything else:

• Model access: GLM-5.2 is MIT-licensed and ships open weights, you can self-host it. Claude Sonnet 5 is proprietary and API-only.
• Pricing: GLM-5.2 costs $1.4 per million input tokens and $4.4 per million output tokens. Claude Sonnet 5 introductory pricing is $2 and $10 respectively and rises to $3/$15 after August 31.
• Ecosystem: Claude Sonnet 5 sits inside Anthropic’s full toolchain; Claude Code, Claude Cowork, MCP integrations, and the existing API ecosystem many teams are already building on.

The honest read: if benchmark parity is sufficient and your team has the infrastructure to self-host, GLM-5.2 is a compelling cost argument, especially for high-volume output workloads where the per-token gap compounds quickly. If you need API reliability, a managed safety layer, or tight integration with tools like Claude Code, Sonnet 5 is worth the premium.

This is the same decision framework that matters across most proprietary-vs-open-weights comparisons. The benchmarks rarely settle it, deployment requirements and total cost of ownership usually do.

Frequently Asked Questions

Is Claude Sonnet 5 available for free users?

Yes. As of June 30, 2026, Claude Sonnet 5 is the default model on Anthropic’s Free and Pro plans. It is also available to Max, Team, and Enterprise users.

What is the API model string for Claude Sonnet 5?

Developers access it via claude-sonnet-5 through the Claude API.

How does Claude Sonnet 5 pricing compare to Sonnet 4.6?

Sonnet 4.6 was priced at $3 per million input tokens and $15 per million output tokens. Claude Sonnet 5 launches at $2 and $10 respectively through August 31, 2026, making the introductory transition cost-neutral or better for most workloads. Note the updated tokenizer — inputs may expand 1.0 to 1.35 times in token count, so run workload-specific tests before drawing final cost conclusions.

Is Claude Sonnet 5 safer than Sonnet 4.6?

In most respects, yes. Anthropic’s safety evaluations show lower rates of undesirable behavior, reduced hallucination, better prompt injection resistance, and stronger refusal of malicious requests compared to Sonnet 4.6.

When should I use Sonnet 5 versus Opus 4.8?

Sonnet 5 covers most agentic and coding workflows at lower cost. Opus 4.8 is still the better choice for the highest-complexity reasoning tasks and cybersecurity work where reduced guardrails are needed and performance margins matter. If your tasks sit in between, Sonnet 5 at extra-high effort is worth testing before defaulting to Opus.

Does Claude Sonnet 5 support Claude Code?

Yes. Sonnet 5 is available in Claude Code, and rate limits across Claude Code have been increased to support the higher token usage that comes with extended effort levels.