A side-by-side look at pricing, context windows, and tiering across the three frontier model families as of August 2026 — and why the spec sheet undersells how differently they actually behave in agent loops.
As of August 2026, there are three viable frontier model families for anyone building agentic software, and each one has quietly restructured its lineup in the last few months. Anthropic split Claude into a clean three-rung ladder. OpenAI, true to form, now ships GPT-5.6 as three internally-named tiers with their own pricing curves. Google keeps iterating Gemini 3.1 Pro's context economics almost monthly. None of this is marketing noise you can ignore — it changes which model is actually cheapest for your workload, and the answer depends on token shape, not just sticker price.
Here's where things stand, pulled from current published pricing:
| Model | Context window | Input $/1M | Output $/1M | Long-context surcharge | Positioning |
|---|---|---|---|---|---|
| Claude Sonnet 5 | 1M tokens | $2 (intro, through Aug 31) → $3 | $10 (intro) → $15 | None — flat rate to 1M | Default agentic/coding workhorse |
| Claude Opus 5 | 1M tokens | $5 | $25 | None — flat rate to 1M | Hardest reasoning, long-running agents |
| GPT-5.6 Sol | 1.05M tokens | $5 | $30 | 2x input / 1.5x output above ~272K | Flagship reasoning |
| GPT-5.6 Terra | 1.05M tokens | $2 | $12 | 2x input / 1.5x output above ~272K | Mid-tier, cost-balanced |
| GPT-5.6 Luna | 1.05M tokens | $0.20 | $1.20 | 2x input / 1.5x output above ~272K | High-volume, low-latency |
| Gemini 3.1 Pro | 1M tokens (2M reported in some deployments) | $2 (≤200K) → $4 | $12 (≤200K) → $18 | 2x input / 1.5x output above 200K | Native multimodal, long-context agentic work |
Pricing shifts fast enough in this market that any table is a snapshot, not a contract — check the vendor's live pricing page before you budget against these numbers. But the structure underneath is more durable than the digits, and that structure is the actual story.
OpenAI's Sol/Terra/Luna split and Anthropic's Opus/Sonnet/Fable ladder look similar on paper — cheap-fast, balanced, and expensive-smart — but they're solving different problems. Anthropic's tiers are genuinely different model sizes with different reasoning ceilings; you pick Opus 5 because Sonnet 5 gets a task wrong often enough that the 2.5x price premium pays for itself in fewer retries. OpenAI's three GPT-5.6 tiers are closer to the same underlying capability class tuned for different cost/latency points, which means the calculus for picking between Terra and Sol is less "can it solve this" and more "how much do I want to pay for the same answer arriving faster or with fewer edge-case failures."
This matters in practice because teams often port a prompt-and-eval harness built against one vendor's mid-tier model to a different vendor's mid-tier model and expect equivalent behavior. It doesn't transfer cleanly. A prompt tuned against GPT-5.6 Terra's tool-calling format can underperform on Claude Sonnet 5 not because Sonnet 5 is weaker, but because Anthropic's tool-use training data and system-prompt conventions differ enough that identical instructions get parsed differently. If you're evaluating across vendors, budget time for per-vendor prompt tuning — treating the model as a drop-in swap is the single most common cause of "the new model regressed" bug reports that turn out not to be regressions at all.
The headline input/output prices are almost a distraction next to the long-context surcharge structure, because agentic workloads — an agent that's read half a codebase into context, or a RAG pipeline stuffing retrieved documents into the prompt — blow past the surcharge threshold constantly.
Anthropic's decision to hold Sonnet 5 and Opus 5 at a flat per-token rate all the way to 1M tokens is the more agent-friendly economics of the three. A 900K-token request costs the same per token as a 9K-token one. OpenAI and Google both apply roughly a 2x input-token multiplier once you cross ~200-272K tokens, which means a long-running coding agent that keeps its full repo context resident — a completely normal pattern for anything doing multi-file refactors — pays double on every turn after that point, not just once.
Do the arithmetic before you pick a model for a long-context agent: at Gemini 3.1 Pro's $4/1M above-threshold input rate, a workflow that runs 50 turns a day with 300K tokens of resident context costs meaningfully more per month than the same workflow on Sonnet 5's flat $3/1M. The gap compounds because most of those resident tokens are cache-eligible context you're re-sending every turn, not fresh generation — and cache discounts (where offered) are a percentage of a price that's already doubled.
Published agentic-coding benchmarks report pass rates, and pass rates converge across the frontier tier faster than people expect — Opus 5, GPT-5.6 Sol, and Gemini 3.1 Pro are all credible choices for "write a correct patch for this bug." The differentiator that doesn't show up in a leaderboard is what happens on the runs that fail.
A model that fails loud — refuses, asks a clarifying question, or returns a patch that doesn't compile — is cheap to handle: your harness catches it and retries or escalates. A model that fails quiet — returns a plausible-looking patch that passes a shallow test but breaks an edge case, or calls a tool with subtly wrong arguments that still parse as valid JSON — is expensive, because nothing in your pipeline flags it. This is orthogonal to raw capability. It's a training and calibration property, and it varies by vendor and even by minor version within a vendor's lineup. If you're building anything that acts on model output without a human in the loop — merging a PR, sending an email, executing a trade instruction — the failure-mode question matters more than the benchmark score, and the only way to learn it is running your own eval suite against your own task distribution, not trusting a public leaderboard.
All three families now support structured tool calling well enough for basic single-tool-per-turn workflows. Where they diverge is multi-tool agent loops — the pattern where a model needs to chain several tool calls, hold intermediate state across a dozen turns, and recover gracefully when a tool call errors. This is exactly the shape of workload the Model Context Protocol (MCP) was designed to standardize on the tool-definition side, and it's worth noting that standardizing the interface doesn't standardize the behavior behind it — the same MCP tool definition, wired into the same server, will still get called with more precision by one model than another, and will get retried more sensibly by one model than another when the first call errors.
If you're evaluating models specifically for an agent that needs to hold a long tool-calling chain together, test with your actual tool schemas, not a toy example. A model can look flawless calling a two-parameter search tool and fall apart coordinating five tools with overlapping parameter names — that's a distinct failure mode from either raw reasoning or long-context handling, and none of the three vendors' marketing materials will tell you which of their tiers handles it best for your specific tool surface.
Skip the temptation to pick one model family as a blanket default. A more durable approach:
The honest takeaway is that frontier-tier capability has converged enough that the deciding factor for most teams isn't "which model is smartest" — it's which pricing structure matches your actual token shape, and which failure mode you can afford to build error-handling around. Model selection is a systems-design decision now, not a leaderboard lookup.