Request-level pricing modifiers for Anthropic (fast mode, batch, priority, data residency)

[frederick-douglas-pearce]

Request-level pricing modifiers for Anthropic (fast mode, batch, priority, data residency)

A coverage audit of Anthropic's pricing surfaced several request-level modifiers that change the effective rate but aren't currently modeled for Anthropic. Filing one consolidated issue (separate from the cache-TTL #295 and web-search #202 threads).

Each is signaled by a field already present in Anthropic's usage object:

Modifier	Effect	usage signal	Values
Fast mode	premium flat rates (Opus 4.6/4.7 = $30 in / $150 out; Opus 4.8 = $10/$50), across full context window	usage.speed	standard | fast
Batch API	0.5× input & output	usage.service_tier	standard | batch
Priority tier	commitment pricing	usage.service_tier	standard | priority
Data residency (US)	1.1× on all token categories (Opus 4.6 / Sonnet 4.6+)	usage.inference_geo	global(default) | us

Stacking, per Anthropic's pricing page: fast mode applies across the full window and stacks with prompt-caching multipliers and data residency, but not with batch; batch + caching combine; data residency 1.1× applies to input / output / cache-write / cache-read.

The batch/priority pair is the Anthropic side of the same "request tier changes the rate" mechanism already requested for OpenAI in #115 — so a shared, condition-keyed price-variant mechanism (matching on a usage field rather than only date/time) would likely cover both providers at once.

Questions for maintainers:

1. Is modeling these as request-condition-keyed price variants the direction you'd want, or is there a preferred shape?
2. Would you accept a PR adding these for Anthropic once the shape is agreed?

Happy to contribute — we have verified rate tables and real usage samples for all four.

[chrisreeves-bumbl]

Related to #390
Both Gemini and OpenAI also have service tier pricing

[pydanty]

• Relationship resolved
• Existing-work coverage resolved
• Investigation inputs sufficient
• Supported production reachability established
• Contract and historical intent reconciled
• User/project relevance established
• Immediate relief assessed
• Long-term change is net-positive
• Change boundary and invasiveness understood (not established)
• Success criteria and integration-level regression tests defined (not applicable)

Decision: maintainer discussion

Confirmed capability gap, valid feature request routed to maintainer discussion — exactly the vehicle the repository's own gate requires. Runtime-verified on both packages: an Anthropic usage object carrying service_tier/speed/inference_geo prices at standard rates ($30.00 for claude-opus-4-6 vs $15 batch / $33 residency / $180 fast), all three fields silently dropped, zero warnings, on fields Anthropic emits in production. Current behavior violates no current contract (published v2 schema and units.yml have no condition keys; a checked-in JS test pins the service_tier drop; README promises no modifier coverage), so this is an extension, not a correction. Direction is settled by maintainer action: Kludex's unmerged #547 ("Closes part of #429") implements the condition-keyed price_variants mechanism + batch rows; alexmojaki hardened its semantics. The boundary remains maintainer-gated: fast mode's flat per-request rates fit no existing unit (v3-adjacent; the v2 schema is byte-frozen by CI), priority tier is a documented closing legacy commitment (model or explicitly decline), residual rows are sequenced behind #547's shape, and #547's review must settle additive-v2 vs v3 landing. These are decisions, not missing facts.

Why it matters: The gap silently mis-prices an entire request class on a Tier-1 provider — batch 2x, residency 1.1x — using two fields Anthropic emits by default, and the wrong number flows into every pydantic-ai/logfire cost display with no error signal. The condition-keyed variant primitive amortizes to #115 (OpenAI flex/priority) and #390 (provider-agnostic batch), so the request will recur until it exists. Decisions maintainers owe this thread: fast-mode flat-rate representation (new unit, v3-adjacent), priority-tier decline vs model, and sequencing of the residual Anthropic rows behind #547. Scored at the top of the feature-request-needing-schema-decision band (1-4): verified mis-pricing reach and a live maintainer thread justify the top; the deliberately gated schema/unit decision keeps it out of the data-fix bands.

Evidence: Runtime-verified on both packages (playground https://play.pydantic.work/p/2Fcl77Xm): a claude-opus-4-6 usage object carrying service_tier/speed/inference_geo returns standard $30.00 (vs $15 batch / $33 residency / $180 fast), all three fields silently dropped, zero warnings — inputs Anthropic's docs confirm are production-emitted (two by default). Contract phase: current behavior matches every current-contract layer (v2 schema + units.yml have no condition keys; checked-in JS test pins the service_tier drop; README disclaimer), so #429 is an extension, not a correction. History: maintainer four-PR thread #445→#447→#448→#547; #547 ("Closes part of #429", open/unmerged as of 2026-08-26) implements condition-keyed price_variants with price_context as sole entry point plus batch rows for ~91 models; alexmojaki's review set resolution semantics and rejected silent-degradation shorthand. Boundary: main carries zero of the mechanism; fast-mode flat per-request rates are unrepresentable without a new (v3-adjacent) unit; Anthropic docs scope fast mode to Opus 5/4.8 (beta-gated), contradicting the issue's 4.6/4.7/4.8 table; priority tier is a closing legacy commitment; additive-v2 vs v3 landing is #547's open review question. No team-lead (DouweM) statement exists; direction rests on a two-maintainer thread.

Playground: https://play.pydantic.work/p/2Fcl77Xm