← Blog
#Claude#LLM#AI Agents#Cost Optimization#Migration

Claude Sonnet 5: Running Agents Cheaply Without Dropping Frontier Quality

webhani·

The "cheap frontier" positioning

Anthropic released Claude Sonnet 5 on June 30. The headline isn't raw capability — it's the balance between price and agentic behavior. Introductory pricing sits at $2 per million input tokens and $10 per million output tokens (through the end of August 2026, then $3 / $15). Tasks that a few months ago demanded an Opus-class model can now run autonomously at this tier. That shift is the real story.

At webhani we operate several agent platforms for clients, and the recurring problem is never "how smart is a single inference" — it's "what does the whole thing cost after you run the loop dozens of times." An agent calls a tool, reads the result, decides the next action, and repeats. The more iterations a workload demands, the more the per-token price flows straight into your margin. Sonnet 5 matters because it lands at a point that meaningfully lowers that iteration cost.

What actually changed

Anthropic frames Sonnet 5 as the most agentic Sonnet yet. It's better at using tools like browsers and terminals and at running multi-step tasks without constant human intervention. The feedback we hear most often is that it "finishes tasks" — where earlier models would stall partway, Sonnet 5 tends to re-plan and carry the work through to completion.

On the technical side, the points worth remembering:

  • 1M-token context by default — helpful for large codebases and log analysis
  • Up to 128k tokens of output — long artifacts in a single response
  • Adaptive thinking — reasoning depth scales with problem difficulty
  • A new tokenizer — and this is where the trap lives

The new tokenizer is a hidden cost

The detail people overlook: Sonnet 5 ships with a new tokenizer. The same input text consumes roughly 30% more tokens than it did on Sonnet 4.6. In other words, the per-token price dropped, but the token count went up.

That means you can't carry your old cost estimates straight over. If you look only at the sticker price and conclude "switching from Opus will be cheaper," you may find your bill higher than expected. A real estimate has to multiply the price delta by the token-inflation factor.

// Migration estimate: fold in the token-inflation rate, not just the price
interface ModelCost {
  name: string;
  inputPerM: number; // $ per million tokens
  outputPerM: number;
  tokenMultiplier: number; // consumption relative to the old tokenizer
}
 
const sonnet46: ModelCost = {
  name: "Sonnet 4.6",
  inputPerM: 3,
  outputPerM: 15,
  tokenMultiplier: 1.0,
};
 
const sonnet5: ModelCost = {
  name: "Sonnet 5 (standard price)",
  inputPerM: 3,
  outputPerM: 15,
  tokenMultiplier: 1.3, // ~30% more tokens
};
 
function estimateCost(
  model: ModelCost,
  inputTokens: number,
  outputTokens: number
): number {
  const adjustedInput = inputTokens * model.tokenMultiplier;
  const adjustedOutput = outputTokens * model.tokenMultiplier;
  return (
    (adjustedInput / 1_000_000) * model.inputPerM +
    (adjustedOutput / 1_000_000) * model.outputPerM
  );
}
 
// One agent loop
const inputTokens = 40_000;
const outputTokens = 2_000;
 
console.log(estimateCost(sonnet46, inputTokens, outputTokens));
console.log(estimateCost(sonnet5, inputTokens, outputTokens));
// Same unit price, yet Sonnet 5 costs more purely from token inflation

There's a second consequence: when the tokenizer changes, so does the effective capacity of the context window. A 1M-token budget sounds generous, but if the same document now occupies more tokens, the amount of real information you can pack in shrinks. If your design routinely handles long documents, it's worth revisiting your chunk-splitting thresholds with this in mind.

Patterns that pay off in agent operations

Control adaptive-thinking effort. Running deep reasoning on trivial tasks inflates output tokens and cost. Set reasoning depth by task difficulty and keep it shallow for simple classification or format conversion.

Prompt caching. Agents send the same system prompt and tool definitions on every turn. Cache that fixed prefix and you cut input cost dramatically from the second call onward — the more iterations an agent runs, the bigger the win.

Tiering still works. Sonnet 5 being cheaper doesn't mean you route everything through it. A three-tier setup — Haiku for routine sub-tasks, Sonnet 5 for the hard parts, Fable 5 only for the problems nothing else cracks — remains effective. The accurate read is that Sonnet 5 thickened the middle tier.

Make the token budget visible. Before pushing an agent to production, measure average token consumption per task. Because the new tokenizer invalidates your old measurements, always re-measure after migrating.

A migration checklist

Whether we recommend a client move to Sonnet 5 comes down to:

  • The agent runs many loops, so per-token price maps directly to margin
  • The workload suffers from "tasks that stall," and a higher completion rate is worth money
  • There's a process in place to re-measure token consumption post-migration and absorb any increase

Conversely, for workloads dominated by short one-shot generations with little iteration, the upside is limited. Cheaper per-token pricing rewards high iteration counts most.

Takeaway

The essence of Claude Sonnet 5 isn't that it got smarter — it's that it landed at a price point where you can run agents cheaply. But the new tokenizer inflates token counts, so judging a migration on sticker price alone is risky. Multiply the price delta by the token-inflation rate, then re-measure real cost after switching. Follow that sequence and Sonnet 5 becomes a genuine way to lower the operating cost of an agent platform. At webhani we've built this verification process into our standard client workflow.

← Back to Blog