@tormentalabs/claude-code-wire-compat 0.1.0 → 0.2.0

package/src/headers.ts

@@ -7,6 +7,7 @@ import type {
 } from "./contracts.js";
 import { ClaudeCodeWireError } from "./contracts.js";
 import { CLAUDE_CODE_2_1_195_PROFILE } from "./profiles/claude-code-2.1.195.js";
+import { CLAUDE_CODE_2_1_233_PROFILE } from "./profiles/claude-code-2.1.233.js";
 
 const HEADER_NAMES = Object.freeze({
   anthropicBeta: "anthropic-beta",
@@ -160,11 +161,16 @@ function parseExtraHeaderPolicy(value: unknown): ClaudeCodeExtraHeaderPolicy {
   return value;
 }
 
+/**
+ * Accepts a pinned profile by REFERENCE, never by shape, and returns the
+ * singleton itself so nothing downstream can be handed a look-alike. Adding
+ * the second pinned profile widens the accepted set by exactly one object;
+ * anything else, including a structural clone, still fails closed.
+ */
 function parseProfile(value: unknown): ClaudeCodeProtocolProfile {
-  if (value !== CLAUDE_CODE_2_1_195_PROFILE) {
-    throw new ClaudeCodeWireError("INVALID_INPUT");
-  }
-  return CLAUDE_CODE_2_1_195_PROFILE;
+  if (value === CLAUDE_CODE_2_1_195_PROFILE) return CLAUDE_CODE_2_1_195_PROFILE;
+  if (value === CLAUDE_CODE_2_1_233_PROFILE) return CLAUDE_CODE_2_1_233_PROFILE;
+  throw new ClaudeCodeWireError("INVALID_INPUT");
 }
 
 function parseApp(value: unknown): "cli" | "cli-bg" {

package/src/index.ts

@@ -60,3 +60,4 @@ export {
 } from "./build-request.js";
 
 export { CLAUDE_CODE_2_1_195_PROFILE } from "./profiles/claude-code-2.1.195.js";
+export { CLAUDE_CODE_2_1_233_PROFILE } from "./profiles/claude-code-2.1.233.js";

package/src/model-capabilities.ts

@@ -1,17 +1,46 @@
 // SPDX-License-Identifier: GPL-3.0-or-later
 
-import type { ClaudeCodeCapabilities } from "./contracts.js";
+import type {
+  ClaudeCodeCapabilities,
+  ClaudeCodeCatalogueEntry,
+  ClaudeCodeProtocolProfile,
+} from "./contracts.js";
+import { profileBehaviors } from "./profile-behaviors.js";
+import { CLAUDE_CODE_2_1_195_PROFILE } from "./profiles/claude-code-2.1.195.js";
 
 /*
  * Capability derivation, ported from the genuine client's nine capability
  * predicates.
  *
- * THE LOAD-BEARING FACT, stated up front because it is surprising:
+ * READ THIS FIRST -- there are two derivation paths and they are not
+ * interchangeable:
+ *
+ *   1. Catalogue path (`deriveCapabilitiesFromCatalogue`), taken for every id
+ *      present in the 2.1.195 catalogue. Six of the nine capabilities have a
+ *      verbatim upstream string in `ClaudeCodeCatalogueEntry.capabilities`
+ *      (`effort`, `max_effort`, `xhigh_effort`, `adaptive_thinking`,
+ *      `context_management`, `rejects_disabled_thinking`) and are read from
+ *      there. The other three (`thinking`, `interleavedThinking`,
+ *      `temperature`) have NO catalogue string in any client version and stay
+ *      predicate-derived.
+ *   2. Predicate fallback (`deriveCapabilitiesFromPredicates`), taken for ids
+ *      with no catalogue entry -- `claude-mythos-5` (absent by product
+ *      decision D-1), ids from a newer client, and anything that escaped
+ *      normalization. Those fall through every exclusion list and resolve
+ *      maximally permissive, `temperature` excepted because its predicate is
+ *      an allowlist.
+ *
+ * The two paths agree on every catalogue cell but one; see the demarcated
+ * C1 block in `deriveCapabilities`. `test/validation/capability-equivalence
+ * .test.ts` pins the agreement cell by cell and pins that one divergence from
+ * both sides, so neither path can drift silently.
+ *
+ * THE LOAD-BEARING FACT about the predicates, stated up front because it is
+ * surprising:
  *
  *   On the first-party provider -- the only provider this package targets --
  *   every one of these nine predicates reduces to a pure function of the
- *   normalized model id. The catalogue's `capabilities` string array does not
- *   participate in capability derivation at all.
+ *   normalized model id.
  *
  * Why. Upstream, each predicate has the shape
  *
@@ -42,13 +71,18 @@ import type { ClaudeCodeCapabilities } from "./contracts.js";
  *
  * WARNING TO FUTURE READERS. Two things follow that look like bugs and are not:
  *
- *   1. No membership test was lost. Do NOT "restore" a `JB`-equivalent check
- *      here. Adding one back cannot change any result, but it reintroduces
- *      dead branches that cannot be covered or mutation-killed.
- *   2. The catalogue `capabilities` arrays are retained in the profile as
- *      faithful transcribed evidence AND are consumed elsewhere --
- *      `mid_conv_system`, `lean_prompt` and `fast_mode` are read by later
- *      work packages. Do NOT delete them because this module ignores them.
+ *   1. The individual predicates below still carry no `JB`-equivalent
+ *      membership test, and must not grow one. Catalogue membership is
+ *      consulted in exactly one place -- `deriveCapabilitiesFromCatalogue` --
+ *      so the fallback path stays a pure function of the id and the
+ *      equivalence between the two paths stays testable. A membership check
+ *      inside a predicate would be a dead branch on the catalogue path and an
+ *      unreachable one on the fallback path.
+ *   2. The catalogue `capabilities` arrays carry strings this module does not
+ *      map to a `ClaudeCodeCapabilities` field -- `fast_mode`, `lean_prompt`,
+ *      `fable_5_mitigations` and `mid_conv_system`. They are faithful
+ *      transcribed evidence and are consumed elsewhere. Do NOT delete them
+ *      because this module ignores them.
  *
  * `claude-mythos-5` has no catalogue entry by product decision D-1. Upstream
  * special-cases it by name in `Kw`, `Hke`, `Yte` and `Uot`; this port subsumes
@@ -195,6 +229,12 @@ export function supportsContextManagement(normalizedId: string): boolean {
  *
  * Elided: the unconditionally true `ZO` provider gate.
  * This beta-only gate is intentionally absent from `ClaudeCodeCapabilities`.
+ *
+ * Stays predicate-derived and takes no part in the catalogue path: no
+ * `structured_outputs` string exists in any catalogue entry, so there is
+ * nothing to read. Deliberately takes no profile parameter -- upstream does
+ * not gate this beta on the catalogue in any modelled version, so making it
+ * profile-aware would invent behaviour rather than port it.
  */
 export function supportsStructuredOutputs(normalizedId: string): boolean {
   return !(
@@ -212,8 +252,26 @@ export function supportsStructuredOutputs(normalizedId: string): boolean {
  * differs from `rejectsDisabledThinking` by one member: that predicate also
  * excludes `claude-opus-4-8`. Do not merge them.
  * This beta-only gate is intentionally absent from `ClaudeCodeCapabilities`.
+ *
+ * Catalogue-first WHEN a profile is supplied and that profile catalogues the
+ * id: `mid_conv_system` exists as a catalogue string, and from 2.1.222+ the
+ * catalogue is what upstream reads. The switch is behaviour-preserving for
+ * 2.1.195, which is the point of the equivalence pinning in
+ * `test/validation/capability-equivalence.test.ts`: in the 2.1.195 catalogue
+ * exactly `claude-opus-4-8` and `claude-fable-5` carry the string, and those
+ * are exactly the two ids the exclusion list below admits.
+ *
+ * Without a profile -- or for an id the profile does not catalogue, such as
+ * `claude-mythos-5` under 2.1.195 -- the predicate remains authoritative.
  */
-export function supportsMidConversationSystem(normalizedId: string): boolean {
+export function supportsMidConversationSystem(
+  normalizedId: string,
+  profile?: ClaudeCodeProtocolProfile,
+): boolean {
+  const entry = profile?.supportedModels[normalizedId];
+  if (entry !== undefined) {
+    return entry.capabilities.includes("mid_conv_system");
+  }
   return !(
     normalizedId.includes("claude-3-") ||
     normalizedId === "claude-opus-4-0" ||
@@ -278,7 +336,66 @@ export function rejectsDisabledThinking(normalizedId: string): boolean {
   return true;
 }
 
-export function deriveCapabilities(
+/**
+ * The six `ClaudeCodeCapabilities` fields the catalogue represents, paired
+ * with their verbatim upstream capability string. The three omitted fields --
+ * `thinking`, `interleavedThinking`, `temperature` -- have no catalogue
+ * string in any client version and are derived from their predicates on both
+ * paths.
+ */
+const CATALOGUE_BACKED_CAPABILITIES = {
+  effort: "effort",
+  maxEffort: "max_effort",
+  xhighEffort: "xhigh_effort",
+  adaptiveThinking: "adaptive_thinking",
+  contextManagement: "context_management",
+  rejectsDisabledThinking: "rejects_disabled_thinking",
+} as const;
+
+/**
+ * Pure catalogue -> capabilities mapping. Reads nothing but `entry` for the
+ * six catalogue-backed fields; `normalizedId` is used only for the three
+ * fields the catalogue does not represent.
+ *
+ * This function applies no exceptions and no id special cases. The one cell
+ * where the 2.1.195 catalogue disagrees with the wire is corrected by the
+ * caller, so that this mapping stays a faithful reading of the data and the
+ * correction stays visible at exactly one site.
+ */
+export function deriveCapabilitiesFromCatalogue(
+  entry: ClaudeCodeCatalogueEntry,
+  normalizedId: string,
+): ClaudeCodeCapabilities {
+  const has = (capability: string): boolean =>
+    entry.capabilities.includes(capability);
+
+  return Object.freeze({
+    thinking: supportsThinking(normalizedId),
+    adaptiveThinking: has(CATALOGUE_BACKED_CAPABILITIES.adaptiveThinking),
+    interleavedThinking: supportsInterleavedThinking(normalizedId),
+    effort: has(CATALOGUE_BACKED_CAPABILITIES.effort),
+    maxEffort: has(CATALOGUE_BACKED_CAPABILITIES.maxEffort),
+    xhighEffort: has(CATALOGUE_BACKED_CAPABILITIES.xhighEffort),
+    contextManagement: has(CATALOGUE_BACKED_CAPABILITIES.contextManagement),
+    temperature: supportsTemperature(normalizedId),
+    rejectsDisabledThinking: has(
+      CATALOGUE_BACKED_CAPABILITIES.rejectsDisabledThinking,
+    ),
+  });
+}
+
+/**
+ * Fallback for ids with no catalogue entry. Every field comes from its
+ * predicate, which is the pre-catalogue behaviour of this module, preserved
+ * byte for byte in result: unknown ids fall through every exclusion list and
+ * resolve maximally permissive, `temperature` excepted (allowlist polarity).
+ *
+ * `claude-mythos-5` reaches this path -- it has no catalogue entry by product
+ * decision D-1 -- and upstream special-cases it by name in `Kw`, `Hke`, `Yte`
+ * and `Uot`. Those clauses are subsumed here by the first-party fallback,
+ * which yields an identical result.
+ */
+function deriveCapabilitiesFromPredicates(
   normalizedId: string,
 ): ClaudeCodeCapabilities {
   return Object.freeze({
@@ -293,3 +410,44 @@ export function deriveCapabilities(
     rejectsDisabledThinking: rejectsDisabledThinking(normalizedId),
   });
 }
+
+export function deriveCapabilities(
+  normalizedId: string,
+  profile: ClaudeCodeProtocolProfile = CLAUDE_CODE_2_1_195_PROFILE,
+): ClaudeCodeCapabilities {
+  const entry = profile.supportedModels[normalizedId];
+  if (entry === undefined) {
+    return deriveCapabilitiesFromPredicates(normalizedId);
+  }
+
+  const capabilities = deriveCapabilitiesFromCatalogue(entry, normalizedId);
+
+  /*
+   * DEMARCATED EXCEPTION -- docs/plans/BLOCKERS.md, finding C1.
+   *
+   * Exactly one cell of the 2.1.195 catalogue disagrees with the binary that
+   * shipped it: `claude-opus-4-5` omits `effort` from its `capabilities`
+   * array, but 2.1.195 derives capabilities from predicate code and `Kw`
+   * (`supportsEffort`) does not exclude `claude-opus-4-5`. The predicate is
+   * therefore wire-authoritative for this profile, and the golden fixtures
+   * and packed-consumer digests prove `effort: true` is what 2.1.195 sends.
+   *
+   * Scope. This exception belongs to the 2.1.195 profile only, and the
+   * behaviour guard below enforces that mechanically. Upstream 2.1.222+
+   * switches derivation to the catalogue, which makes `effort: false`
+   * genuine there: for those profiles the catalogue IS the truth, so a
+   * profile ported from them does NOT inherit this block. Which profiles are
+   * on which side is `profile-behaviors.ts`'s question, not this module's.
+   */
+  if (
+    profileBehaviors(profile).opus45EffortException &&
+    normalizedId === "claude-opus-4-5"
+  ) {
+    return Object.freeze({
+      ...capabilities,
+      effort: supportsEffort(normalizedId),
+    });
+  }
+
+  return capabilities;
+}

package/src/models.ts

@@ -37,10 +37,14 @@ export function resolveModel(
   return Object.freeze({
     id,
     wireId,
-    // The catalogue supplies the family. It does NOT supply capabilities:
-    // on first party every capability is a pure function of the normalized
-    // id. See the header of `model-capabilities.ts` for why.
+    // The catalogue supplies the family here, and -- since T1.1.2 -- also
+    // supplies the six catalogue-backed capabilities. Both now honour THIS
+    // profile: `deriveCapabilities` takes the active profile, so a request
+    // built against a non-pinned profile derives from that profile's
+    // catalogue rather than from 2.1.195's. Ids with no catalogue entry fall
+    // back to the ported predicates, which are pure functions of the
+    // normalized id. See the header of `model-capabilities.ts`.
     family: entry?.family ?? modelFamilyOf(id),
-    capabilities: deriveCapabilities(id),
+    capabilities: deriveCapabilities(id, profile),
   });
 }

package/src/profile-behaviors.ts

@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-3.0-or-later
+
+import type { ClaudeCodeProtocolProfile } from "./contracts.js";
+import { CLAUDE_CODE_2_1_195_PROFILE } from "./profiles/claude-code-2.1.195.js";
+
+/**
+ * Per-profile behaviour dispatch.
+ *
+ * Three modules — `thinking.ts`, `fingerprint.ts` and `model-capabilities.ts` —
+ * each need to know whether the profile they were handed behaves like upstream
+ * 2.1.195 or like upstream 2.1.222+. Each grew its own
+ * `profile.id === CLAUDE_CODE_2_1_195_PROFILE.id` comparison as its feature
+ * landed, and three copies of one question is three places to forget when a
+ * fourth profile arrives. This module is the single place that asks it.
+ *
+ * The flags are named for the BEHAVIOUR they gate, never for a version. A call
+ * site reading `profileBehaviors(profile).billingChainSegments` says what it is
+ * deciding; a call site reading `profile.id !== …195….id` says only which
+ * client it is not, and leaves the reader to reconstruct why that matters.
+ * `test/governance/version-dispatch.test.ts` fails the build if a fourth copy
+ * of the comparison appears in `src/`.
+ *
+ * `ClaudeCodeProfileBehaviors` deliberately stays here rather than moving to
+ * `contracts.ts`. It is not part of the wire contract and is not exported from
+ * `index.ts`: it is an internal derivation over a profile, and putting it in
+ * the contract module would imply consumers can supply one, which they cannot.
+ * Behaviour is derived from the profile, never declared alongside it.
+ */
+export interface ClaudeCodeProfileBehaviors {
+  /**
+   * Whether a caller's own `max_tokens` of 4096 or more raises the model's
+   * `upperLimit` and lowers its `default` to fit under it.
+   *
+   * Consumed by `modelOutputTokenLimits` in `thinking.ts`, whose one
+   * wire-visible effect is the seed of the default thinking budget.
+   */
+  readonly requestDerivedTokenCeiling: boolean;
+
+  /**
+   * Whether the billing block may carry the `cc_prev_req` and `cc_prompt_id`
+   * conversation-chaining segments.
+   *
+   * Consumed by `createBillingBlock` in `fingerprint.ts`. False means the
+   * segments are dropped silently even when the caller supplies both, which is
+   * what a client with no parameter for them does.
+   */
+  readonly billingChainSegments: boolean;
+
+  /**
+   * Whether `claude-opus-4-5` takes its `effort` capability from the predicate
+   * rather than from the catalogue.
+   *
+   * Consumed by `deriveCapabilities` in `model-capabilities.ts`. See
+   * `docs/plans/BLOCKERS.md`, finding C1: this is the one cell where the
+   * 2.1.195 catalogue disagrees with the binary that shipped it, and the
+   * predicate is wire-authoritative for that profile alone.
+   */
+  readonly opus45EffortException: boolean;
+}
+
+/**
+ * Upstream 2.1.195: derivation is predicate-driven, the request builder has no
+ * request-derived token ceiling, and the billing block has no parameter for
+ * conversation chaining.
+ */
+const LEGACY_BEHAVIORS: ClaudeCodeProfileBehaviors = Object.freeze({
+  requestDerivedTokenCeiling: false,
+  billingChainSegments: false,
+  opus45EffortException: true,
+});
+
+/**
+ * Upstream 2.1.222 and later: derivation is catalogue-first, so the
+ * `claude-opus-4-5` exception does not apply, and both of the newer request
+ * behaviours are present.
+ */
+const MODERN_BEHAVIORS: ClaudeCodeProfileBehaviors = Object.freeze({
+  requestDerivedTokenCeiling: true,
+  billingChainSegments: true,
+  opus45EffortException: false,
+});
+
+/**
+ * Resolves the behaviour set a profile follows.
+ *
+ * Pure and total: every profile answers, and the answer depends on nothing but
+ * the profile's identity.
+ */
+export function profileBehaviors(
+  profile: ClaudeCodeProtocolProfile,
+): ClaudeCodeProfileBehaviors {
+  /*
+   * ---- Demarcated: the ONLY per-version identity comparison in `src/`. ----
+   *
+   * The split is 2.1.195 versus 2.1.222+, and it is structural rather than a
+   * capability flag: these are differences in what the upstream builder is
+   * written to do, not values it reads from a catalogue. 2.1.195 is the one
+   * profile ported from the older builder, so it is the one named here.
+   *
+   * The default is deliberately the MODERN side. A profile ported from a
+   * client newer than 2.1.233 inherits the current behaviour and needs no edit
+   * here; only a profile ported from a client OLDER than 2.1.222 would, and
+   * adding one is a decision that should require touching this module. Written
+   * the other way round — naming the modern profiles and defaulting to legacy
+   * — every new profile would silently regress to 2.1.195 semantics.
+   *
+   * `test/governance/version-dispatch.test.ts` asserts this comparison is
+   * here, and that it is nowhere else.
+   */
+  if (profile.id === CLAUDE_CODE_2_1_195_PROFILE.id) {
+    return LEGACY_BEHAVIORS;
+  }
+  return MODERN_BEHAVIORS;
+}

package/src/profiles/beta-registry-2.1.233.ts

@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: GPL-3.0-or-later
+
+interface BetaRegistryEntry {
+  readonly featureKey: string;
+  readonly header: string;
+}
+
+/*
+ * `deepFreeze` is duplicated from `src/beta-registry.ts` rather than imported.
+ * A shared helper module would make the two registries import-coupled for four
+ * lines of code, and the 2.1.195 registry already carries its own copy; keeping
+ * each registry a leaf keeps a version bump from rippling.
+ */
+function deepFreeze<T>(value: T): T {
+  if (value !== null && typeof value === "object") {
+    for (const key of Reflect.ownKeys(value)) {
+      deepFreeze(Reflect.get(value, key));
+    }
+    Object.freeze(value);
+  }
+  return value;
+}
+
+/**
+ * Genuine-client beta registry as of 2.1.233, upstream `Fb_` (byte offset
+ * 287505865).
+ *
+ * KEY ORDER IS LOAD-BEARING. Upstream neither sorts this object nor keeps a
+ * canonical list elsewhere, and `src/betas.ts` emits headers in the order its
+ * push sites fire, not in registry order -- but the registry order is the
+ * transcription of record and the only thing that makes a diff against a future
+ * build meaningful. Do not reorder for tidiness, alphabetisation, or grouping.
+ */
+export const BETA_REGISTRY_2_1_233 = deepFreeze({
+  CLAUDE_CODE: { featureKey: "claude_code", header: "claude-code-20250219" },
+  OAUTH_AUTH: { featureKey: "oauth_auth", header: "oauth-2025-04-20" },
+  INTERLEAVED_THINKING: {
+    featureKey: "interleaved_thinking",
+    header: "interleaved-thinking-2025-05-14",
+  },
+  LONG_CONTEXT: { featureKey: "long_context", header: "context-1m-2025-08-07" },
+  CONTEXT_MANAGEMENT: {
+    featureKey: "context_management",
+    header: "context-management-2025-06-27",
+  },
+  STRUCTURED_OUTPUTS: {
+    featureKey: "structured_outputs",
+    header: "structured-outputs-2025-12-15",
+  },
+  WEB_SEARCH: { featureKey: "web_search", header: "web-search-2025-03-05" },
+  ADVANCED_TOOL_USE: {
+    featureKey: "tool_search",
+    header: "advanced-tool-use-2025-11-20",
+  },
+  TOOL_SEARCH: {
+    featureKey: "tool_search",
+    header: "tool-search-tool-2025-10-19",
+  },
+  EFFORT: { featureKey: "effort", header: "effort-2025-11-24" },
+  TASK_BUDGETS: {
+    featureKey: "task_budgets",
+    header: "task-budgets-2026-03-13",
+  },
+  PROMPT_CACHING_SCOPE: {
+    featureKey: "prompt_caching_scope",
+    header: "prompt-caching-scope-2026-01-05",
+  },
+  PROMPT_CACHING_EVICT: {
+    featureKey: "prompt_caching_evict",
+    header: "prompt-caching-evict-2026-05-12",
+  },
+  EXTENDED_CACHE_TTL: {
+    featureKey: "extended_cache_ttl",
+    header: "extended-cache-ttl-2025-04-11",
+  },
+  SPEED: { featureKey: "speed", header: "fast-mode-2026-02-01" },
+  REDACT_THINKING: {
+    featureKey: "redact_thinking",
+    header: "redact-thinking-2026-02-12",
+  },
+  THINKING_TOKEN_COUNT: {
+    featureKey: "thinking_token_count",
+    header: "thinking-token-count-2026-05-13",
+  },
+  AFK_MODE: { featureKey: "afk_mode", header: "afk-mode-2026-01-31" },
+  ADVISOR_TOOL: {
+    featureKey: "advisor_tool",
+    header: "advisor-tool-2026-03-01",
+  },
+  CACHE_DIAGNOSIS: {
+    featureKey: "cache_diagnosis",
+    header: "cache-diagnosis-2026-04-07",
+  },
+  CONTEXT_HINT: {
+    featureKey: "context_hint",
+    header: "context-hint-2026-04-09",
+  },
+  MCP_SERVERS: {
+    featureKey: "mcp_servers",
+    header: "mcp-servers-2025-12-04",
+  },
+  FILES_API: { featureKey: "files_api", header: "files-api-2025-04-14" },
+  ENVIRONMENTS: {
+    featureKey: "environments",
+    header: "environments-2025-11-01",
+  },
+  CCR_BYOC: { featureKey: "ccr_byoc", header: "ccr-byoc-2025-07-29" },
+  MID_CONVERSATION_SYSTEM: {
+    featureKey: "mid_conversation_system",
+    header: "mid-conversation-system-2026-04-07",
+  },
+  PER_MESSAGE_EFFORT: {
+    featureKey: "per_message_effort",
+    header: "per-turn-control-2026-07-01",
+  },
+  SERVER_SIDE_FALLBACK: {
+    featureKey: "server_side_fallback",
+    header: "server-side-fallback-2026-06-01",
+  },
+  SERVER_SIDE_FALLBACK_CATEGORY: {
+    featureKey: "server_side_fallback_category",
+    header: "server-side-fallback-2026-07-01",
+  },
+  FALLBACK_CREDIT: {
+    featureKey: "fallback_credit",
+    header: "fallback-credit-2026-06-01",
+  },
+  /*
+   * NARRATION_SUMMARIES BELONGS HERE AND IS DELIBERATELY ABSENT.
+   *
+   * 2.1.195 carried `NARRATION_SUMMARIES` (`narration_summaries` /
+   * `summarize-connector-text-2026-03-13`, upstream `RPt`) at exactly this
+   * position, between `FALLBACK_CREDIT` and `AUTO_MODE_CLASSIFIER`. Upstream
+   * removed it in 2.1.222+: the frozen array in the 2.1.233 build has a null
+   * slot here and the header string appears nowhere in the binary.
+   *
+   * This is a REMOVAL, not a transcription gap. Re-adding the entry would
+   * reintroduce a header the genuine client no longer sends and would break the
+   * wire-compatibility claim on the first request. `src/betas.ts` treats the
+   * narration push site as conditional on the entry's presence precisely so
+   * this absence needs no special-casing anywhere else. Do not "fix" it.
+   */
+  AUTO_MODE_CLASSIFIER: {
+    featureKey: "auto_mode_classifier",
+    header: "auto-mode-classifier-2026-07-16",
+  },
+} satisfies Record<string, BetaRegistryEntry>);
+
+/*
+ * Third-party filtering as of 2.1.233, upstream `X5p` (consumed by `J4u`).
+ *
+ * Delta against the 2.1.195 set (`Pvi`): `mid-conversation-system-2026-04-07`
+ * was ADDED; nothing was removed. Eleven headers, extracted from the 2.1.233
+ * build rather than assumed to have carried over.
+ */
+export const THIRD_PARTY_ALLOWED_BETAS_2_1_233: ReadonlySet<string> =
+  Object.freeze(
+    new Set([
+      BETA_REGISTRY_2_1_233.CLAUDE_CODE.header,
+      BETA_REGISTRY_2_1_233.INTERLEAVED_THINKING.header,
+      BETA_REGISTRY_2_1_233.LONG_CONTEXT.header,
+      BETA_REGISTRY_2_1_233.CONTEXT_MANAGEMENT.header,
+      BETA_REGISTRY_2_1_233.STRUCTURED_OUTPUTS.header,
+      BETA_REGISTRY_2_1_233.WEB_SEARCH.header,
+      BETA_REGISTRY_2_1_233.EFFORT.header,
+      BETA_REGISTRY_2_1_233.TOOL_SEARCH.header,
+      BETA_REGISTRY_2_1_233.AFK_MODE.header,
+      BETA_REGISTRY_2_1_233.FALLBACK_CREDIT.header,
+      BETA_REGISTRY_2_1_233.MID_CONVERSATION_SYSTEM.header,
+    ]),
+  );
+
+/*
+ * Provider filtering as of 2.1.233, upstream `pts` (consumed by `y1s`).
+ * Extracted, not assumed: the set is byte-identical to the 2.1.195 one (`S2r`).
+ *
+ * Static reference data with no call site in `src/`, exactly like its 2.1.195
+ * counterpart. See `test/governance/provider-scope.test.ts`.
+ */
+export const BEDROCK_UNSUPPORTED_BETAS_2_1_233: ReadonlySet<string> =
+  Object.freeze(
+    new Set([
+      BETA_REGISTRY_2_1_233.INTERLEAVED_THINKING.header,
+      BETA_REGISTRY_2_1_233.LONG_CONTEXT.header,
+      BETA_REGISTRY_2_1_233.TOOL_SEARCH.header,
+    ]),
+  );
+
+/*
+ * Count-tokens selection as of 2.1.233, upstream `fts` (consumed by `_1s`).
+ * Extracted, not assumed: identical to the 2.1.195 set (`E2r`).
+ */
+export const COUNT_TOKENS_BETAS_2_1_233: ReadonlySet<string> = Object.freeze(
+  new Set([
+    BETA_REGISTRY_2_1_233.CLAUDE_CODE.header,
+    BETA_REGISTRY_2_1_233.INTERLEAVED_THINKING.header,
+    BETA_REGISTRY_2_1_233.CONTEXT_MANAGEMENT.header,
+    BETA_REGISTRY_2_1_233.OAUTH_AUTH.header,
+  ]),
+);