The meter moved. It did not disappear.

Generation runs once and produces the thing you wanted. Verification is optional, repeatable, and invisible when it succeeds. Under per-token billing, every additional check is a marginal cost with no visible payoff, and marginal costs with no visible payoff are where budget pressure settles. That is an argument about incentives, not a survey of the industry; we have no interview data and will not pretend to. What we can report is our own ledger. When we audited our pipeline this quarter, the checks we were not running clustered exactly where the incentive analysis predicts: the second opinion, the adversarial re-read, the eval suite that ran before releases instead of on every commit. Nobody had decided that in a meeting. It had settled there.

The absolute numbers frame the decision. Claude Fable 5 is priced at 10 dollars per million input tokens and 50 per million output on the API. Claude Opus 5, announced 24 July 2026, is 5 and 25. The overhead is smaller and easier to forget: on Opus 5, a tool-equipped request carries 286 tokens of tool-use system prompt at tool_choice auto or none, 406 at any or tool, and another 325 input tokens if the bash tool is attached. Claude Managed Agents bills 0.08 dollars per session-hour on top of Opus 5 token rates. The bill was never only tokens, and a fan-out of small verification calls pays the fixed overhead on each one.

Four practices sit closest to that margin. Redundant verification: the same check through two independent paths. Second opinions: a different model, with a different training cutoff and different failure modes, reviewing the same artefact. Adversarial self-review: the system instructed to attack its own output rather than summarise it. Continuous evaluation: the suite on every commit rather than before a launch. Each is cheap in isolation. Each is expensive as a default, on every change, indefinitely, which is why each is the natural first thing to quietly not do.

Effective 20 July 2026, Anthropic included Claude Fable 5 at no extra cost on Max plans, premium Team seats, and premium seat-based Enterprise seats. The help centre states the allocation plainly: up to 50 percent of weekly usage limits may go to Fable 5 at no extra cost. It is not universal. Pro and standard Team seats are excluded; on those plans Fable 5 is not included in the plan's usage limits and is paid for with usage credits. The inclusion names premium seat-based Enterprise seats specifically, not standard ones. On the transition credit, the sources disagree: the official @claudeai account, quoted by Simon Willison on 18 July 2026, said excluded users would receive a one-time 100 dollar credit, and PCWorld reported the same figure; Anthropic's help centre says only that there is a one-time credit and states no amount.

The change is dated, not promised. The help centre article gives a start date, 20 July 2026, and no end date, and it does not use the word permanent. Several outlets read the absence of an end date as permanence; that is their inference, not the company's text. A team planning capacity on a commitment when it holds only a start date is making a forecasting error. For scale: Max starts at 100 dollars per month, Team Premium is 100 dollars per seat annual or 125 monthly, Pro is 17 annual or 20 monthly, Team Standard is 20 or 25. The inclusion tracks the expensive seats. It also did not replace nothing: a prior free-access promotion ran until 19 July 2026 at 11:59:59 PM PT, after which Fable 5 remained available under the new terms.

Now the mechanics. The 50 percent figure is a ceiling on a share, not an addition. The help centre is explicit that use of other models draws from the same usage limits and that you can never exceed the weekly limit. The pool is shared: everything else that seat does spends from the same allowance. The change gives you permission to put half the pool through the stronger lane; it does not give you a bigger pool. The article describes the 20 July change and says nothing about Claude Opus 5, and we found no published statement on how the model that became the Max default four days later interacts with the allowance. On the general wording it draws from the same pool, but that is our reading, not a documented one.

Two more gaps. First, no plan tier has published weekly limit values in any unit we could find: not messages, not tokens, not hours. You cannot budget against a number nobody published; you can only measure your own exhaustion. The-decoder reported that the 50 percent applies to limits already reduced by roughly a third when the bonus phase ended; we could not verify that against a primary source and flag it as their reporting. Second, there is no low-intensity Fable 5 request to fall back on. Adaptive thinking is always on; the disabled thinking type is unsupported and raw chain-of-thought is never returned. And if your token intuitions were formed on older models, recalibrate: Fable 5 uses the tokenizer introduced with Claude Opus 4.7, and Anthropic's documentation notes that compared to models before Opus 4.7, the same text produces roughly 30 percent more tokens.

On 24 July 2026 Anthropic announced Claude Opus 5 at 5 dollars per million input tokens and 25 per million output. That is half Fable 5's rate and the same price as its predecessor Opus 4.8, so it is a capability change, not a price cut. Anthropic positions it as coming close to Fable 5's frontier intelligence at half the price and recommends it as the default starting model; it became the default on Claude Max and the strongest model available on Claude Pro. The hierarchy is unchanged at the top: Fable 5 remains, per Anthropic's own documentation, their most capable widely released model, and Opus 5 remains behind Claude Mythos 5 on cybersecurity and biology work.

On capability, be careful what you repeat. Both launches present their benchmark results as charts rather than text tables, and we could not extract a single absolute figure for either model from any source we checked. What exists is Anthropic's own comparative wording: that Opus 5 surpasses all other models on Frontier-Bench v0.1, comes within 0.5 percent of Fable 5's peak CursorBench 3.2 score at half the cost, and surpasses Fable 5's best OSWorld 2.0 result at just over a third of the cost. Those are the vendor's claims about relative position. A comparison you cannot reproduce is a claim, not a measurement, and we cite it as one.

The metered lane also carries controls the plan surface does not document. Effort is set through output_config with five levels, low through max, defaulting to high on the Claude API and in Claude Code; thinking cannot be disabled at xhigh or max, and Anthropic's docs note that on Opus 5, changing effort does not reliably shorten the visible response, so prompt for length instead. Prompt caching prices the redundancy directly: cache hits and refreshes at 0.50 dollars per million input tokens against a 5 dollar base, five-minute cache writes at 6.25, one-hour writes at 10. The Batch API halves the rate again to 2.50 and 12.50. Long context bills at standard rates with no surcharge above 200k tokens on Claude 4.6 and later, and automatic fallbacks shipped as an API beta alongside the launch. We found nothing documenting an equivalent set of dials on subscription seats.

Hold the week in one frame. On 20 July, strong-model verification became a quota draw on expensive seats. On 24 July, a metered model arrived at half the frontier rate with caching, batch, and effort controls. Any verification practice hard-wired to one lane's price sheet needed re-deciding within the week. A practice built on a rubric, a deterministic gate, and a swappable lane needed a config change.

Before a pull request opens in our pipeline, a change passes a deterministic verifier and a multi-model review panel. The verifier is the gate: build, type check, tests, lint, migration checks, and the project's own assertions. It is the only thing permitted to fail a change. The panel is advisory. Several model lanes review the same diff against the same rubric with the same repository context, and they write findings. They do not merge, they do not approve, and they cannot mark their own acceptance criteria as verified.

The signal we route on is disagreement. Where the panel converges, a human skims. Where it splits, a human reads carefully. That is a working rule, not a validated finding: we have not measured whether splits predict defects better than any single reviewer's severity ranking, and until we publish those run records, treat the heuristic as our bet rather than our receipt. The honest version of the economics is similar. A panel is only worth running if redundancy is cheap, and cheap has two paths: a subscription lane whose capacity is unpublished, or a metered lane priced for exactly this shape of work. Within one model lane, a panel is unusually cache-friendly, because every reviewer reads the same context and differs only in rubric. Fable 5 retains the 90 percent input token discount for prompt caching; Opus 5's cache-hit rate is a tenth of its base input price. Whether a cache entry can be shared across different models is not documented, so budget each lane's context write separately, and remember that every reviewer pays its own output tokens regardless.

One counterargument deserves the floor: tokens may not be your binding constraint. Every reviewer you add produces findings a human must triage, and false positives spend the scarcest resource in a small team, which is attention. Our mitigations are caps and buckets: a ceiling on reviewers per run, findings required to carry a file, a line, and a concrete failure scenario, and anything without a reproduction path diverted to a low-signal bucket a human can ignore. If the panel makes review slower without catching a defect class your gate misses, the panel is theatre. Measure that, not the token bill.

Two operational cautions from running this. Staleness: Fable 5's reliable knowledge cutoff is January 2026, Opus 5's is May 2026, and a reviewer months behind on a library's API will confidently flag correct code as wrong. Choose reviewing lanes on what they know, not only on what they cost. Refusals: Fable 5 ships safety classifiers that can decline a request, and a refusal arrives as an HTTP 200 with stop_reason set to refusal; requests refused before output are not billed. A harness that treats HTTP 200 as success will record a refusal as a passing review. Assert on stop_reason, and count a refusal as a non-review that visibly reduces coverage.

A seat subscription is not an API service level agreement, and the record of this particular model makes the difference concrete. Between 9 June and 20 July 2026, Anthropic revised Fable 5's plan access at least four times: a free window from 9 to 22 June, a switch to usage credits on 7 July, an extension on 12 July, and the inclusion change on 20 July. Anthropic said why: demand for Fable had been challenging to predict, which is why access was extended several times as additional capacity was secured. Read that as an engineering fact. The terms of the lane are downstream of capacity, and capacity is not a commitment you hold.

Availability has a harder precedent than terms drift. Fable 5 was forced offline on 12 June 2026 by a United States export-control directive. Controls were lifted and the model returned globally on 1 July 2026. Nineteen days, during which no retry policy, no fallback configuration, and no amount of budget on your side would have restored that specific model. It was not a rate limit or an outage. It was regulation, and a dependency map that has never considered a regulatory removal has a blind spot the size of June 2026.

One constraint travels with the model rather than the plan. Fable 5 is designated a Covered Model with 30-day data retention and is not available under a zero data retention agreement. If a client contract requires ZDR, Fable 5 is off the table for that engagement on every lane, subscription or API. That has nothing to do with pricing and will not surface in any cost review, which is exactly why it belongs in the routing rule rather than in someone's memory.

The rule we use has four conditions, and work must satisfy all four to live on a subscription lane. Advisory: nothing merges or ships on its say-so. Retryable: a failed run can simply run again later. Asynchronous: nobody is holding a latency budget against it. Human-gated: a person accepts or rejects the output before it has any effect. The conditions attach to how work is run, not to what it is called. A pull request review panel run as ours is, pre-merge but advisory and human-gated, qualifies; the same panel wired to block merges does not, and a review a customer is waiting on does not either. Eval generation, spec critique, red-teaming, migration planning, and documentation drafts usually qualify as we run them, but check the conditions, not the category.

The other side of the line is anything a client's user waits on, anything covered by a support commitment, anything with a customer-visible failure mode, and anything governed by a data-processing term the subscription does not carry. Those stay on the API, where the controls are documented and contractual: pinned model identifiers, claude-opus-5 being a dateless string but a pinned snapshot rather than a moving alias; automatic fallbacks, shipped as an API beta; batch pricing for work that tolerates latency; and a cost that lands on an invoice where a finance function can see and challenge it.

The failure mode to watch is not a bad decision at the boundary. It is an undeclared dependency drifting across it. A panel that starts as a helpful habit becomes expected within a quarter, and then a seat subscription with unpublished limits and terms that moved four times in six weeks is sitting on your delivery path with nobody having written that down. The fix is unglamorous: declare the lane in the same place you declare your CI provider, give it a documented spillover to a metered lane with a pinned model, and force the spillover to fire on a schedule so you know it works.

Which lane should host the panel by default? We are not going to pretend this article settles it. The subscription lane's marginal price is zero but its capacity is unpublished and its terms are five days old. The metered lane has published prices, caching, batch, and effort controls, and Opus 5 moved its economics substantially on 24 July. The comparison depends on your diff sizes, your cache hit rates, and your run volume, none of which we can know for you. What we can say is that the four-condition rule and the spillover survive either answer, and a practice that needs re-litigating every time a price sheet moves was never a practice.

Start with the ledger. Write down every verification step your pipeline does not run, and next to each one the reason. Some reasons will be engineering judgement. Some will be a cost estimate from a different price sheet that nobody has revisited. Recompute every too-expensive entry against the rates in this article before accepting it, because those rates changed twice in the week before publication. That list, not a benchmark chart, tells you what a cheap verification lane is worth to your team.

Then build in the right order. The deterministic verifier comes first; it is what makes an advisory panel safe to run at all, because a panel that can block a merge without a reproducible criterion makes delivery slower and no more correct. Once the gate is the only thing that can fail a change, add reviewers, cap them, and treat their disagreement as a routing signal for human attention while you collect the run records that will tell you whether the signal is real.

Treat the quota as a budget you have to discover. The weekly limits are not published, so learn them from your own side: log what you route through the lane, log when it exhausts, project exhaustion from observed burn, and decide in advance what degrades when the allowance runs out. The degradation should be a declared spillover to a metered lane with a pinned model, visible in the run record, never a silent drop to a single reviewer that nobody notices until a defect ships.

And date everything. The terms described here took effect on 20 July 2026 and were five days old when this was written; they had already changed at least four times in six weeks, and the model landscape moved again on 24 July. Re-verify against the primary sources below before any plan depends on a claim in this article. We hold our own writing to the same rule we hold a model's findings to: a claim without a checkable source is a liability, whoever produced it.