[BUG] v2.1.219 default Opus model on Bedrock (Opus 5) is budgeted at 200K — catalog omits native_1m_3p; Bedrock verified serving 271K bare

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code v2.1.219 makes us.anthropic.claude-opus-5 the default Opus model on Bedrock and describes Opus 5 as a 1M-context model. On direct Bedrock (CLAUDE_CODE_USE_BEDROCK=1, no gateway, fresh config dir), the bare model is internally budgeted at 200K:

• us.anthropic.claude-opus-5 → 200K
• us.anthropic.claude-opus-5[1m] → 1M
• us.anthropic.claude-sonnet-5 → 967K (control)
• ANTHROPIC_MODEL=opus (the alias) → us.anthropic.claude-opus-5 → 200K
• no model configured at all (the out-of-the-box default path) → us.anthropic.claude-opus-5 → 200K (confirmed, v2.1.219)

The shipped catalog marks Opus 4.7/4.8/5 and Fable 5 as window: 1e6, native_1m: true, but only claude-sonnet-5 carries the per-provider attestation native_1m_3p:{bedrock:true,vertex:true,foundry:true}. The partner-provider window resolver requires that field and otherwise falls back to a hardcoded 200,000 (details in Additional Information). native_1m_3p appears as data exactly once in the whole 257 MB binary — on the Sonnet 5 entry.

This affects more than /context: the same resolved window drives auto-compaction (begins at 167K), local prompt blocking (a ≈539K-token prompt is rejected client-side on bare Opus 5, while the identical prompt via the [1m] path goes through to Bedrock and processes fine), and the skill-listing budget (5× under-allocated). There is no warning in any of these states.

The backend serves the full window today — verified with Claude Code out of the loop. On 2026-07-24 we sent a ~271K-token single-message payload via raw aws bedrock-runtime invoke-model — no anthropic_beta key anywhere in the request body — from an enterprise AWS account, us-east-1, us. cross-region inference profiles:

| Model (bare, NO beta) | usage.input_tokens | stop_reason | Message id |
|---|---|---|---|
| us.anthropic.claude-opus-5 | 271,000 | end_turn ("ok") | msg_bdrk_f7xht2ye4ko7xbwfvyxj7zllbdezt3t6ji3qszh3tho65x62pfpa |
| us.anthropic.claude-fable-5 | 270,998 | refusal (safety classifier on degenerate filler; prompt fully accepted and token-counted, no context-length error) | msg_bdrk_6tkqeolweajiwiagndonladasu2nkd3fuubloegt2mxxla6ouj6a |
| us.anthropic.claude-sonnet-5 (attested control) | 270,998 | end_turn ("ok") | msg_bdrk_33z54y4bc6pbzf2q4zjgaxpdhsxg7lgmx3z5cpwwtb7gltf6kklq |

Raw response JSONs and the payload generator: https://gist.github.com/ari1974/0a25b94755f88d476ff3f9b53e1e113c

So the missing attestation is stale catalog data, not accurate conservative data — Bedrock does not require the context-1m beta for these models (confirmed for us. profiles in us-east-1; other regions/prefixes unverified).

Three-way documentation contradiction (all retrieved 2026-07-24):

| Source | What it says |
|---|---|
| Anthropic platform docs (context-windows, migration guide, pricing) + AWS Bedrock model cards for Opus 4.7/4.8/5 and Fable 5 | 1M is the default window on Bedrock/Vertex/Foundry ("For every model with a 1M-token context window, 1M is the default" — on "the Claude API, Amazon Bedrock, Google Cloud, and Microsoft Foundry"), no beta header, standard pricing; AWS cards list "Context window: 1M tokens" with no context flag, and the Bedrock Messages-request 1M beta-compatibility row names only the opt-in-era models ("Compatible with Claude Sonnet 4, Claude Sonnet 4.6, and Claude Opus 4.6") — none of the four affected models |
| code.claude.com/docs/en/model-config | On Bedrock/Google Agent Platform/Foundry, a model ID without [1m] "uses 200K context"; Sonnet 5 is the sole exception that always runs 1M |
| Shipped v2.1.219 catalog | attests native 1M-on-partner only for claude-sonnet-5 |

The client behavior matches the middle row and contradicts the platform capability contract — and the live E1 probe above shows the platform contract is what Bedrock actually implements.

What Should Happen?

Bare us.anthropic.claude-opus-5 (and claude-opus-4-7, claude-opus-4-8, claude-fable-5) on Bedrock should be budgeted at the window the provider actually serves — 1M per Anthropic's platform docs, AWS's model cards, and the live probe above — exactly as claude-sonnet-5 already is.

At an absolute minimum: when a native_1m model is resolved below its declared context.window, show a visible warning (the binary already warns for the inverse mistake — requesting 1M where it isn't served, e.g. Sonnet 4.5 on Vertex — but is silent in this direction, which is what made this undiagnosable from the product).

Error Messages/Logs

# /context, bare us.anthropic.claude-opus-5, direct Bedrock, v2.1.219 (Skills table omitted):

## Context Usage

**Model:** us.anthropic.claude-opus-5
**Tokens:** 16.5k / 200k (8%)

### Estimated usage by category

| Category | Tokens | Percentage |
|----------|--------|------------|
| System prompt | 3.1k | 1.6% |
| System tools | 11.9k | 5.9% |
| System tools (deferred) | 8.3k | 4.2% |
| Skills | 1.5k | 0.7% |
| Messages | 9 | 0.0% |
| Free space | 150.5k | 75.3% |
| Autocompact buffer | 33k | 16.5% |

# ~539K-token prompt (1.04 MB payload), same config — rejected without any API request:

Prompt is too long

Steps to Reproduce

Client side (the bug):

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1                 # or your Bedrock region
export CLAUDE_CONFIG_DIR=/tmp/ctxprobe/cfg  # isolate from your real config

ANTHROPIC_MODEL=us.anthropic.claude-opus-5      claude -p '/context'   # → 200k   ← the bug
ANTHROPIC_MODEL=us.anthropic.claude-opus-5[1m]  claude -p '/context'   # → 1m
ANTHROPIC_MODEL=us.anthropic.claude-sonnet-5    claude -p '/context'   # → 967k   ← control
ANTHROPIC_MODEL=opus                            claude -p '/context'   # alias path → 200k
env -u ANTHROPIC_MODEL                          claude -p '/context'   # TRUE default path → 200k

The default-path run (no model env var of any kind) reports **Model:** us.anthropic.claude-opus-5 · **Tokens:** 12.7k / 200k (6%) — the out-of-the-box configuration is the bug configuration.

Same model, same provider, same backend; the only difference is a client-side string suffix. The Sonnet 5 control isolates the mechanism: the one model carrying native_1m_3p is the one model that gets its window.

Backend proof (no Claude Code involved): send >200K bare, with no beta key in the body:

# payload: single user message, 993,600 chars of repeated English filler
# + "Reply with the single word: ok", max_tokens: 8,
# anthropic_version: bedrock-2023-05-31 — and NO anthropic_beta key.
# Generator script (e1_bedrock_probe.py) in the gist; equivalent one-shot:
python3 e1_bedrock_probe.py --profile <your-profile> --yes
# → {"result": "ACCEPTED", ..., "usage": {"input_tokens": 271000, ...}}   HTTP 200

Observed 2026-07-24 on all three models (table above). Interpretation guard is built into the script: a measured input_tokens ≤ 200_000 is not probative; ours measured 271,000 / 270,998 / 270,998.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

None known for this path. On Bedrock the default alias has resolved to an unattested 1M-native model since v2.1.207; pinned bare IDs have been affected since those catalog entries shipped. (First-party equivalent was fixed in v2.1.117.)

Claude Code Version

2.1.219 (BUILD_TIME: 2026-07-24T03:24:19Z, GIT_SHA: 7006c4c3acac98e554d3997baeda6a7fa4d1ff7c)

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Root cause (code-verified, independently reproduced by three separate analyses of the v2.1.219 binary)

The baked-in model catalog (self-described "hand-maintained … source of truth") declares for the affected models:

claude-sonnet-5 : {window:1e6, native_1m, native_1m_3p:{bedrock,vertex,foundry}, supports_1m_beta}
claude-opus-4-7 : {window:1e6, native_1m, supports_1m_beta, supports_1m_suffix}   ← no native_1m_3p
claude-opus-4-8 : {window:1e6, native_1m, supports_1m_beta, supports_1m_suffix}   ← no native_1m_3p
claude-opus-5   : {window:1e6, native_1m, supports_1m_beta, supports_1m_suffix}   ← no native_1m_3p
claude-fable-5  : {window:1e6, native_1m, supports_1m_beta}                       ← no native_1m_3p

The window resolver (minified names build-specific; logic verbatim):

function MRg(e, t){                       // per-provider attestation gate
  let r = t?.native_1m_3p
  switch (e) {
    case "bedrock": case "vertex": case "foundry": return r?.[e] === true
    case "gateway": return r?.bedrock === true && r?.vertex === true && r?.foundry === true
    default: return false
  }
}
function hZc(e, t){
  if (Wb(e)) return 1e6                   // [1m] suffix (bare regex, pre-provider)
  if (t?.includes(Cye.header) && tG(e)) return 1e6
  if (DH(e)) return 1e6                   // native-1M on this provider → MRg() for bedrock/vertex/foundry
  /* … */
  return her                              // her = 200000 — hardcoded fallback
}

On Bedrock, provider resolution is correct (bedrock); the gate is reached and returns false purely because the data is absent. Notes:

• The remote-override escape hatch is dead code in this build: function dZc(){return!1} hard-disables the model-capabilities.json refresh, and the resolver reads native_1m_3p only from the baked-in catalog — a fix requires a client release (code-verified).
• CLAUDE_CODE_MAX_CONTEXT_TOKENS is inert for claude-* models on the normal path (guarded by !startsWith("claude-")), with no diagnostic (confirmed, probe row 9; #58710 hit the same dead end). It becomes live only in combination with DISABLE_COMPACT (a separate reader checks that pair first), which trades the wrong window for no auto-compaction at all — not a workaround (code-verified; not live-tested).
• The [1m] workaround is not a neutral accounting override: it also sends anthropic_beta: context-1m-2025-08-07 to Bedrock (code-verified). Meanwhile the attested Sonnet 5 native path sends no beta — and E1 above confirms none is needed.
• The launch-day catalog edit is telling: the same v2.1.219 catalog update that pointed aliases.opus.per_provider.bedrock at claude-opus-5 (making it the default for every Bedrock user, same-day with its Bedrock launch) left native_1m_3p absent from the same entry. The alias map is clearly hand-curated per-provider (foundry still points at claude-opus-4-6); the attestation is the field that doesn't get backfilled — for models AWS has documented at 1M for 6–8 weeks (Fable 5 since 2026-06-09, Opus 4.8 since 2026-05-28).

Impact (default path, no special config)

1. Premature auto-compaction — threshold derives from the resolved window; compaction begins discarding history at 167K (the resolved 200K minus the 33K buffer /context reports) — roughly 17% of the window the model actually has. This (constant compaction on a 1M model) was the originally observed symptom. code-verified + confirmed.
2. Client-side denial of prompts the backend accepts — the ≈539K Prompt is too long block above (the identical payload via [1m] processed fine on Bedrock). Capability denial, not cosmetics. confirmed end-to-end (client-synthesized rejection with no HTTP request + E1 backend acceptance).
3. Skill-listing budget under-allocated 5× — computed as window × 4 × skillListingBudgetFraction from the same resolver. code-verified.

Conditional appendix — tool-search threshold (only if ENABLE_TOOL_SEARCH=auto[:N] is explicitly set): in auto mode the MCP-tool deferral threshold is a percentage of the resolved window, so 200K vs 1M means 20K vs 100K — 5× too small, and #80167 measured the downstream cost of over-deferral on a sibling misconfiguration. On the default path (ENABLE_TOOL_SEARCH unset) the mode selector returns "tst" and defers unconditionally without consulting the window (code-verified by three independent extractions, corroborated live: every probe session deferred 8.3K of tool schemas despite that being below even the wrong-window 20K threshold, and debug-log greps show zero auto_* decision events), so fixing this bug does not change default-path tool deferral on Bedrock — that is a separate concern (#51064, #80167), not an expected benefit of this fix. On Vertex the default path disables tool search entirely (s3() returns false there), making the threshold doubly inapplicable. Stated to preempt over-reading in both directions.

The Prompt is too long block, in detail

A 1.04 MB prompt (the Error output above) is rejected on bare Opus 5; the identical payload with the [1m] suffix was accepted and processed by Bedrock (msg_bdrk_kwx7zliaghu3zr4ciffnmyuxnkbgjuerkipnwgllhuoh3egxgfxa, cache_creation_input_tokens: 538,970 — ≈539K real tokens, 2.7× the budget the bare path enforces). A 360 KB prompt on the bare path is allowed through and Bedrock measures it at ≈199K real tokens. The block is decided client-side on a chars÷3 estimate against a 177K threshold (200K window − 20K output reserve − 3K), so which prompts get denied tracks payload bytes, not the tokens the model would actually see (code-verified).

The rejection is synthesized client-side with no API request issued (confirmed): the preflight check computes level==="blocked" from the resolved window and emits telemetry tengu_ptl_surfaced_to_user / reason:"blocking_limit" (code-verified), and the retained session transcript for the rejected run shows "model":"<synthetic>", a plain-UUID message id instead of a msg_bdrk_* request id, all-zero usage, and the error arriving 24 ms after the user message — physically impossible for a 1 MB upload plus a Bedrock round trip.

Population

Bedrock and Google Agent Platform users on the default opus alias (an affected model since v2.1.207) or pinned bare IDs of the four affected models. Foundry only for users pinning affected models (its opus alias currently points at Opus 4.6). Anthropic-side telemetry can size this directly (e.g. tengu_ptl_surfaced_to_user with reason:"blocking_limit" on these model IDs).

Suggested fix shape

1. Catalog data: add native_1m_3p: {bedrock: true, vertex: true} to claude-opus-4-7, claude-opus-4-8, claude-opus-5, claude-fable-5; set foundry per Anthropic's actual rollout state there (platform docs say β). E1 confirms attestation-only is safe on Bedrock (no auto-beta needed); Vertex/Foundry server behavior should be validated the same way before shipping those flags (unverified by live test here; platform docs say Vertex ✅).
2. Keep the conservative 200K fallback for unattested provider/model pairs — the gate itself is reasonable; the data is stale. (Deliberately not asking for a generic context.window fallback: that would nullify the per-provider gate and convert soft failures into server-side 400s on providers that genuinely serve 200K.)
3. Downgrade warning: when a native_1m model resolves below its declared window, say so once, visibly — the symmetric counterpart of the existing Vertex 1M-rejection warning. This is what makes the bug class self-announcing at the next launch.
4. Catalog invariant tests: for every native_1m entry with a provider id, resolution on that provider must yield either the declared window or an explicit lower window + visible reason.
5. Atomic docs fix: code.claude.com/docs/en/model-config (and the Bedrock page) currently document the 200K behavior while platform docs/AWS cards document native 1M — whichever rule is intended, publish one consistent contract covering native-vs-opt-in, whether [1m] sends a beta, per-provider differences, and cost.
6. Decide the legacy-beta policy: [1m] on a native-1M model currently still sends context-1m-2025-08-07 (observed harmless surplus). Keep it deliberately or normalize it away — but decide, don't drift; suffix handling has already caused adjacent breakage (#79750, #76999, #49781).

Regression context

Class-precedent regression. v2.1.117's changelog records fixing the identical symptom for first-party Opus 4.7: "Fixed Opus 4.7 sessions showing inflated /context percentages and autocompacting too early — Claude Code was computing against a 200K context window instead of Opus 4.7's native 1M." The same class of staleness has now shipped on the partner-provider dimension. Per the model-config docs' version history, the Bedrock/Google Agent Platform opus alias has pointed at an affected model (Opus 4.8, then Opus 5) since v2.1.207 — the default-path exposure is ~12+ releases old, not launch-day lag. v2.1.217 also fixed an adjacent Bedrock/window bug (auto-compact never triggering for Opus 4.8 on Bedrock) without touching the attestation.

Why this is not a duplicate (nearest neighbors, checked in full)

• #77247 — gateway users get 200K because provider resolves wrongly (gateway→firstParty) and the gate is never reached. Here provider resolves correctly to bedrock and the gate returns false on missing data. Proof they're distinct: on this setup Sonnet 5 gets 967K (under #77247's bug it would also be 200K), and #77247's fix alone would leave bare Opus 5 at 200K. Notably its test matrix records claude-opus-4-8 → 200k annotated "catalog-correct: no native_1m_3p" — this report argues that row is the bug, and E1 shows the backend agrees.
• #77125 — right models (Fable /context 200K), no provider framing; proposes a Models-API lookup; misses the native_1m_3p gate and the default-Opus-5-on-Bedrock path.
• #80167 — Foundry + Sonnet 5: provider-resolution root cause (Sonnet 5 has foundry:true); cited here only for the deferral mechanism in the conditional appendix.
• #73646 — same symptom, different mechanism (first-party 429 credits clamp).
• #58710 / #35214 — the precedent class: registry-stale 200K for Sonnet 4.6/Opus 4.6; led to the v2.1.117 fix; #58710 was bot-closed for inactivity.
• #74562 — sonnet[1m]/fable[1m] alias handling, not window resolution.
• #32673 (+ dup #35545) — closed NOT_PLANNED by the inactivity bot: "Bedrock: 1M context should auto-enable for capable models," Opus-4.6-era. Documents the same user pain and the historical beta-required behavior this machinery came from; the native-1M generation (this report) no longer needs the flag per E1. At least the fourth independent rediscovery of this bug class.
• #76751 — Fable statusline display on first-party; enforcement there stays 1M — the opposite of this bug.
• #51064 — Bedrock deferred-tools cost report; no catalog root cause; belongs to the separate default-deferral concern above.
• #34158 — Opus 4.6 hard-blocked ~200K on first-party plan path; enforcement precedent, different path.
• #73149 — Sonnet 5 false context-limit errors; triage neighbor, different mechanism.
• #81039 (new, 2026-07-25) — Desktop app dispatches bare claude-opus-5 instead of [1m] on first-party OAuth; different surface and provider, no partner-catalog involvement — but note it shows the 200K-vs-1M variant split confusing users on a third surface.
• #81025 (new, 2026-07-25) — first-party enterprise OAuth defaulting to claude-opus-5[1m] without entitlement — the inverse failure (client requests 1M the org can't have); entitlement/validation, not the partner window resolver.

Remaining unverified items (stated for honesty)

• Bedrock behavior on non-us. prefixes (eu./jp./au./global.) and GovCloud: unverified (AWS cards suggest region-availability is binary — served with full window or not served).
• Vertex and Foundry backend behavior >200K bare: unverified by live test (client behavior code-verified identical; platform docs say Vertex GA / Foundry β).
• Bedrock pricing above 200K: first-party docs say no long-context premium; Bedrock pricing page not checked (immaterial to the bug).
• Current documentation may also imply stale partner metadata for Opus 4.6 and Sonnet 4.6, whose distinct opt-in-era catalog shape (window: 200000 + beta flags) is not investigated here — out of scope.
• Workaround note: ANTHROPIC_MODEL='us.anthropic.claude-opus-5[1m]' restores the main-loop window (confirmed), but ANTHROPIC_DEFAULT_OPUS_MODEL is additionally required: the opus alias, opusplan, and any subagent that doesn't explicitly inherit or pin a model resolve through a separate reader of that variable (ST()), falling back to the bare catalog alias → 200K — even when the parent session's model is suffixed (code-verified; the parent model is consulted only under an explicitly-null teammateDefaultModel setting, while a set CLAUDE_CODE_SUBAGENT_MODEL or a configured non-null teammateDefaultModel bypasses this resolution entirely). The suffix workaround should not be enshrined as the fix (fix-shape item 6).

Evidence provenance

Static analysis: three independent extractions of the v2.1.219 binary (original report + two adversarial reviews) agreeing byte-for-byte on the catalog and resolver, plus a follow-up author pass re-deriving the disputed functions. Live client probes: an 11-row matrix (9 /context resolutions + 2 large-prompt rows), direct Bedrock, fresh config dir; the raw session transcripts for all probe rows were retained and re-audited after the fact — twice, by separate review passes — which upgraded the client-side-rejection claim to confirmed and corrected two token counts (the accepted large prompt measured ≈199K real input tokens on the backend, the blocked one ≈539K — the originally reported ~90K/~260K were chars÷4 estimates over text that tokenized at ~2 chars/token; both corrections strengthen the result). Live backend probes (E1): raw invoke-model, 2026-07-24, no Claude Code involvement — raw JSONs in https://gist.github.com/ari1974/0a25b94755f88d476ff3f9b53e1e113c. Docs: all quotes retrieved 2026-07-24.