Here is the whole thing in two sentences. To spend less on easy work, Anthropic gives you one model — Opus 5 — and a request-time effort dial you turn down; OpenAI gives you three separate models — Luna, Terra, Sol — and asks you to pick the cheap one. Same goal, opposite architecture, and the gap between "turn a knob" and "choose from a menu" quietly reshapes how you cache, how you evaluate, and how you route.

A dial changes tokens; a menu changes the price of a token#

This is the distinction almost everyone skips, and it's the one that pays.

Opus 5 has a single list price — $5 per million input tokens, $25 output, 1M context, thinking on by default. The output_config.effort field — low, medium, high (the default), xhigh, max — does not touch that price. What it changes is how many tokens you spend: at low effort the model thinks less, makes fewer tool calls, and drops the preamble. You pay the same rate for meaningfully less work.

GPT-5.6 is the inverse. After the July 30 price cuts, Luna is $0.20/$1.20, Terra $2/$12, Sol $5/$30 — three models, one generation, a 25× spread from Luna's input to Sol's. Picking Luna over Sol doesn't make the model do less work; it makes each token of the same work cost a fraction as much. The menu changes unit price; the dial changes token count.

The effort dial economizes token volume at a fixed price. The tier menu cuts the unit price at a roughly fixed token count. They are different levers — and the deepest savings come from pulling both.

Where a vendor gives you both — a cheaper model and a lower effort setting — you get a multiplicative discount, not an additive one. That's the real optimization ceiling, and most teams never reach it because they treat "use less" as a single switch.

Three places the paradigm actually bites#

Prompt caching. Both architectures punish switching, differently. On Opus 5, effort shapes the rendered prompt, so changing it mid-conversation invalidates your cached prefixes — pick one effort level per cached session and hold it constant. On GPT-5.6, each tier is a distinct model with its own cache namespace, so a long context you cached against Terra doesn't carry if you downgrade a follow-up to Luna. The lesson is the same: switch at workload boundaries, never mid-thread.

Evals. The dial is one-dimensional. You evaluate one model at several effort levels; the capability ceiling is constant, so a quality drop at low effort is a smooth cost-for-quality trade you can plot on a single curve. The menu is three-dimensional. Luna, Terra, and Sol are genuinely different models that can fail in qualitatively different ways — not "a little worse," but wrong in a new place. Routing the menu correctly means benching each tier per task type. Budget one effort sweep for the dial; budget three eval passes for the menu.

Routing. On the dial, routing is picking an integer per workload — the model string never changes, so your provider abstraction stays trivial. On the menu, routing is picking a model string, which is the same muscle you already use to add a third vendor. Neither is harder in principle; they just live in different parts of your stack.

The default trap, and it's different for each#

Opus 5 ships with high as the default — the expensive setting. You save by turning it down, and Anthropic's own guidance is to use low and medium liberally wherever your evals show quality holds. GPT-5.6 has no default tier at all; the trap is the reflex of reaching for Sol because it's the flagship. One paradigm overcharges you by inertia, the other by ego. Both are fixed the same way: make model choice a per-task value, not a global constant.

What to actually do#

If you're on Claude, hold claude-opus-5 everywhere and sweep effort per workload — low for classification, extraction, and subagent fan-out; medium for everyday tool-heavy tasks; high and up only where the eval justifies it. Keep effort constant inside any cached session.

If you're on OpenAI, route per call to the cheapest tier that clears the bar — Luna for high-volume well-defined work, Terra for most features, Sol for the hard low-volume calls — and accept the cost of three eval passes and separate caches.

If you're routing across both — which, in a price war measured per task, more teams should be — the unifying move is the one that was always right: put model choice behind a thin interface, define a quality bar per task, and let cost break ties between the options that pass. An effort level and a tier are the same decision wearing two costumes. Stop defaulting everything to the flagship setting, whichever shape your vendor sells it in.