Sonnet Plus a Code Graph vs Opus Alone

Every AI coding bill carries the same quiet assumption: harder problem, bigger model. When an agent flails on a large codebase, the fix on offer is an upgrade to the flagship, and the flagship charges accordingly. The claim this post makes runs the other way: for most day-to-day engineering work, Claude Sonnet with a code graph behind it does better work than Claude Opus without one, at well under half the session cost. The pricing, the mechanism, and the arithmetic are below, and every number is checkable against your own workload.

What the price sheet says

Anthropic's published model catalog puts Claude Opus 5 at $5 per million input tokens and $25 per million output tokens. Claude Sonnet 5 lists at $3 and $15, with introductory pricing of $2 and $10 through August 31, 2026 (pricing page). At list, Sonnet is 40% cheaper on both sides of the ledger. Under the introductory rate it is 60% cheaper.

Prompt caching scales off the same base rates on both models, with cache reads billed at roughly a tenth of the input price, so caching lowers both bills while preserving the ratio between them. Whatever your cache hit rate, an Opus session costs about 1.7x the identical Sonnet session. The interesting question is whether the sessions stay identical, and that is where the graph comes in.

Agent sessions bill like meetings

An agent conversation is a loop: the model calls a tool, the harness appends the result, and the whole transcript goes back over the wire for the next turn. Every file the agent opened in turn three is still being paid for in turn thirty. Input tokens dominate the bill for exactly this reason; on a long session, the output is a rounding error next to the accumulated context being re-sent.

That structure decides where the money goes. A session's cost is roughly the average transcript size, times the number of turns, times the input rate. The model choice moves the rate. Everything else, the transcript size and the turn count, is decided by how the agent acquires context. An agent that greps, opens a 400-line file, discovers it was the wrong one, and opens two more has permanently widened its own transcript, and it keeps paying for that detour on every turn that follows.

Most agent failures are context failures

The case for the bigger model is that it reasons better, and that is true. Reasoning quality is rarely what sinks an agent on a production codebase, though. What sinks it is editing a function without knowing about the fourth caller, confidently importing an API that does not exist, or burning fifteen turns locating code a maintainer would have found in one. We walked through these failure modes in why AI coding agents fail on large codebases; the short version is that the ceiling is set by what the model can see, and no amount of model capability recovers information that never entered the context window.

There is public data on the size of that lever. A Google Research study on enterprise code migration held the task constant and swapped only the retrieval layer, standard vector RAG against graph-aware retrieval. API hallucination dropped from 56.4% to 16.2%, and dependency-resolution quality nearly doubled, from 34.8% to 65.9% (Beyond Vector Similarity). Three and a half times fewer hallucinated APIs, and the swing came entirely from context, with the model held constant. That is the dial the upgrade path ignores.

What a graph hands a smaller model

A code graph stores the structure a text search cannot see: nodes for symbols, edges for calls, imports, and implementations. Exposed over MCP, it turns the expensive gathering phase into single tool calls. Where is this defined: one find_node call returns the file, the line bounds, and the signature. Who consumes it: one callers query returns the resolved call sites, with comments and lookalike strings excluded. What breaks if the signature changes: one blast-radius query walks the edges transitively and returns the full impact set, the question we unpacked in what breaks when you change a function.

Each answer arrives as a compact envelope instead of a stack of file dumps. The transcript stays narrow, the turn count stays low, and the ambiguity a flagship model is supposed to power through never enters the session. That last part is the capability argument, separate from the cost one. Opus outruns Sonnet on long chains of uncertain reasoning. Feed the agent resolved facts and the chains get short: the task collapses from guessing a way through an unfamiliar codebase to applying a precise edit at known coordinates. Anthropic markets Sonnet 5 as the best combination of speed and intelligence, and short-horizon precision work is exactly that profile. The speed half compounds, too: the faster model with the shorter loop hands you a finished edit while the flagship session is still reading files.

The session math

Here is the arithmetic on a concrete shape of task: rename a service method and update every caller, on a repository big enough that nobody holds it in their head. The session numbers are stated assumptions, so swap in your own; the prices are Anthropic's list prices from the table above.

Assume the exploration-driven session takes 30 turns at an average of 60,000 transcript tokens per turn, which is 1.8M billed input tokens, plus 60,000 output tokens across edits and explanations. Assume the graph-backed session resolves the callers up front and finishes in 18 turns averaging 35,000 tokens, 630,000 input tokens total, with 45,000 output.

The middle row is the boring part: same session, cheaper meter, 40% saved. The bottom row is the argument of this post. The graph changes the quantity while the model changes the rate: fewer turns, a narrower transcript, and every remaining token billed at the Sonnet price. Against the Opus-alone session that is roughly a 75% reduction, and under Sonnet's introductory pricing the same session lands near $1.70. With prompt caching on, every row shrinks by a similar factor and the ratios hold.

Multiply by a team. Twenty engineers running five sessions like this per day is a difference of about $790 every day between the first row and the third, on assumptions you should absolutely re-derive from your own usage dashboard.

Where Opus still earns the premium

None of this retires the flagship. Genuinely ambiguous work still benefits from the strongest reasoning available: a multi-day refactor with shifting requirements, an architectural decision with sparse precedent, a long autonomous run where the agent holds a plan across hours. When the stakes carry that weight, the premium is cheap. The argument is about the default. The everyday loop of find, trace, edit, verify makes up most of what an engineering team asks an agent to do, and that loop is exactly the shape the graph compresses. Route the everyday loop to Sonnet with the graph behind it, keep Opus for the work that is hard because the thinking is hard, and the blended bill drops without the output quality following it down.

The cheapest token is the one the agent never has to send, and the strongest model is the one holding the right context. Symvanta serves the code graph over MCP to whatever client your team already runs, Claude Code, Cursor, and the rest of the integrations list, so dropping the default model a tier is a config change and the graph follows the agent everywhere. Run the arithmetic against your own repository: book a 15-minute demo.