@tormentalabs/claude-code-wire-compat 0.1.0-rc.17 → 0.1.0

package/CHANGELOG.md

@@ -2,7 +2,41 @@
 
 All notable changes to this project will be documented in this file.
 
-## [0.1.0-rc.17] - Unreleased
+## [0.1.0] - 2026-07-28
+
+First stable release.
+
+There is NO runtime code change relative to `0.1.0-rc.17`:
+`git diff --stat 5c6881b d7e2901 -- src package.json` is empty, so `dist/` is
+byte-identical to the `0.1.0-rc.17` build. Everything this release contains is
+described in the release candidate entries below; they are not repeated here.
+The packed content differs from `0.1.0-rc.17` by `README.md` and by the added
+TypeScript sources described below — the executed code is unchanged, which
+`npm run test:pack` confirms by an unchanged consumer digest.
+
+### Added
+
+- **The tarball now ships the TypeScript sources.** `src` is added to the
+  `files` allowlist. The build emits 40 `.js.map` and `.d.ts.map` files that
+  reference `../src/*.ts` and carry no `sourcesContent`, so every source map in
+  the published package resolved to nothing in a consumer's debugger. Shipping
+  the sources is also the coherent option for a GPL-3.0-or-later package whose
+  `NOTICE` already offers corresponding source: the offer and the tarball now
+  agree. Only `.ts` files are packed under `src/`, pinned exactly by
+  `test/pack/pack-policy.test.ts`; the allowlist itself is pinned by
+  `test/governance/release-policy.test.ts` and
+  `test/governance/package-policy.test.ts`.
+- The ported protocol-documentation corpus and `docs/ATTRIBUTION.md` are now in
+  the repository. Neither is packed into the tarball.
+
+### Changed
+
+- `README.md` no longer describes the package as a bootstrap release candidate
+  whose request-building behavior arrives later. That statement was false — the
+  package builds and parses requests — and it was the text rendered on the
+  npmjs.com package page.
+
+## [0.1.0-rc.17] - 2026-07-28
 
 ### Added
 
@@ -99,7 +133,7 @@ All notable changes to this project will be documented in this file.
   together. The build path now subtracts one slot per canonical block that
   actually survived.
 
-## [0.1.0-rc.16] - Unreleased
+## [0.1.0-rc.16] - 2026-07-28
 
 ### Added
 

package/README.md

@@ -4,7 +4,7 @@ Claude Wire Compat
 
 An ESM-only, runtime-neutral TypeScript package for constructing a pinned Claude Code Messages wire contract.
 
-> **Status:** bootstrap release candidate. Runtime request-building behavior is intentionally introduced in later releases.
+> **Status:** stable. `buildClaudeCodeRequest` and `parseBuiltClaudeCodeRequest` build and read back the pinned wire contract. The package performs no I/O: credentials, transport, persistence, refresh coordination, and retries remain the consumer's responsibility.
 
 ## Package
 
@@ -18,6 +18,58 @@ The package targets Node.js 20 or newer and is designed to remain portable to Bu
 
 The only accepted `profile` value is the exported `CLAUDE_CODE_2_1_195_PROFILE` singleton. Any other object, even a structurally identical clone, is rejected with `ClaudeCodeWireError` code `INVALID_INPUT`. This deliberate fail-closed behaviour prevents callers from substituting an unpinned protocol profile.
 
+## Protocol documentation
+
+The wire contract this package pins was reverse engineered before it was
+implemented. That research is preserved under [`docs/protocol/`](./docs/protocol)
+so a future maintainer can re-derive the contract when Claude Code ships a new
+version. It is ported verbatim from
+[opencode-anthropic-fix](https://github.com/marco-jardim/opencode-anthropic-fix)
+at commit `466d500` under GPL-3.0-or-later; every file carries a provenance
+header and is listed in [docs/ATTRIBUTION.md](./docs/ATTRIBUTION.md).
+
+**These documents describe the upstream plugin and Claude Code itself, not this
+package's API.** The normative mapping from those findings to this package's
+contract is [docs/source-trace.md](./docs/source-trace.md).
+
+Protocol knowledge corpus:
+
+- [Reverse engineering](./docs/protocol/reverse-engineering.md) — the full
+  authentication and API reverse-engineering record.
+- [HTTP headers and system prompt](./docs/protocol/http-headers-and-system-prompt.md)
+  — header composition and system-prompt mimicry.
+- [Fingerprint extraction](./docs/protocol/fingerprint-extraction.md) — how the
+  client fingerprint and metadata are derived.
+- [Message flow](./docs/protocol/message-flow.md) — end-to-end request and
+  response flow.
+- [Tool use examples](./docs/protocol/tool-use-examples.md) — tool_use and
+  tool_result pairing in practice.
+- [Code comparison reference](./docs/protocol/code-comparison-reference.md) —
+  side-by-side comparison against the genuine client.
+- [Divergence analysis](./docs/protocol/divergence-analysis.md) — every observed
+  divergence from the genuine client.
+- [Divergence executive summary](./docs/protocol/divergence-executive-summary.md)
+  — the condensed version of that analysis.
+- [Quick reference](./docs/protocol/quick-reference.md) — condensed lookup of
+  headers, betas, and switches.
+- [System-prompt search results](./docs/protocol/system-prompt-search-results.md)
+  — where each system-prompt fragment was found in the analysed build.
+- [Cache transparency](./docs/protocol/cache-transparency.md) — anti-verbosity
+  and prompt-cache observability.
+- [Beta decision table](./docs/protocol/beta-decision-table.md) — which beta
+  identifiers are sent under which conditions.
+
+Per-version wire analyses — [why they exist and when a new one is
+required](./docs/protocol/versions/README.md):
+
+- [Claude Code 2.1.119](./docs/protocol/versions/claude-code-2.1.119-analysis.md)
+- [Claude Code 2.1.133](./docs/protocol/versions/claude-code-2.1.133-analysis.md)
+- [Claude Code 2.1.143](./docs/protocol/versions/claude-code-2.1.143-analysis.md)
+- [Claude Code 2.1.150](./docs/protocol/versions/claude-code-2.1.150-analysis.md)
+- [Claude Code 2.1.159](./docs/protocol/versions/claude-code-2.1.159-analysis.md)
+- [Claude Code 2.1.195](./docs/protocol/versions/claude-code-2.1.195-analysis.md)
+  — the release this package's profile pins.
+
 ## Development
 
 ```sh

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tormentalabs/claude-code-wire-compat",
-  "version": "0.1.0-rc.17",
+  "version": "0.1.0",
   "description": "Runtime-neutral Claude Code Messages wire compatibility primitives",
   "type": "module",
   "private": false,
@@ -19,6 +19,7 @@
   },
   "files": [
     "dist",
+    "src",
     "README.md",
     "LICENSE",
     "NOTICE",

package/src/anti-verbosity.ts

@@ -0,0 +1,219 @@
+// SPDX-License-Identifier: GPL-3.0-or-later
+
+import type {
+  AntiVerbosityPolicy,
+  AntiVerbositySection,
+  ClaudeCodeProtocolProfile,
+} from "./contracts.js";
+import { ClaudeCodeWireError } from "./contracts.js";
+import { normalizeModelId } from "./model-identity.js";
+import { CLAUDE_CODE_2_1_195_PROFILE } from "./profiles/claude-code-2.1.195.js";
+
+/**
+ * The genuine client's anti-verbosity system-prompt section, and the three-way
+ * selector that chooses between its variants.
+ *
+ * Upstream this is `ytm(e)` at byte offset 238083640 of the
+ * pinned client build. The four strings below were not transcribed by hand: they
+ * were produced by executing the client's own template literals against stubbed
+ * predicates. The forensic dump tooling collapses non-printable runs and so
+ * cannot be trusted for whitespace inside a template literal; the branch-3
+ * heading in particular is followed by a newline, not a space, which a
+ * dump-based reading got wrong.
+ *
+ * The package EXPOSES this text and never injects it. `buildClaudeCodeRequest`
+ * does not consult this module. The genuine client assembles a large system
+ * prompt from many sections and this package models only the protocol envelope,
+ * so silently adding one section would produce a body matching neither the
+ * client nor the caller's intent. This is the same boundary already settled for
+ * `defaultEffort` and for cache-breakpoint placement: expose, let the caller
+ * decide.
+ */
+
+/** Mirrors upstream defaults: a stock first-party install reports both false. */
+export const DEFAULT_ANTI_VERBOSITY_POLICY: AntiVerbosityPolicy = Object.freeze(
+  {
+    briefModeEnabled: false,
+    pewterOwlToolEnabled: false,
+  },
+);
+
+/**
+ * Branch 1 with upstream `htm` true, which is the default because `htm` is
+ * `!(isBriefEnabled() || pewterOwlTool())`. Carries the extra paragraph about
+ * text written between tool calls.
+ */
+export const COMMUNICATING_WITH_THE_USER_FULL =
+  "# Communicating with the user\n" +
+  "\n" +
+  "Your text output is what the user reads; they usually can't see your thinking or the raw tool results. Write it for a teammate who stepped away and is catching up, not for a log file: they don't know the codenames or shorthand you created along the way, and they didn't watch your process unfold. Before your first tool call, say in a sentence what you're about to do; while working, give brief updates when you find something load-bearing or change direction.\n" +
+  "\n" +
+  "Text you write between tool calls may not be shown to the user. Everything the user needs from this turn — answers, summaries, findings, conclusions, deliverables — must be in the final text message of your turn, with no tool calls after it. Keep text between tool calls to brief status notes. If something important appeared only mid-turn or in your thinking, restate it in that final message.\n" +
+  "\n" +
+  'Lead with the outcome. Your first sentence after finishing should answer "what happened" or "what did you find" — the thing the user would ask for if they said "just give me the TLDR." Supporting detail and reasoning come after, for readers who want them.\n' +
+  "\n" +
+  "Being readable and being concise are different things, and readable matters more. If the user has to reread your summary or ask you to explain, any time saved by brevity is gone. The way to keep output short is to be selective about what you include (drop details that don't change what the reader would do next), not to compress the writing into fragments, abbreviations, arrow chains like `A → B → fails`, or jargon. What you do include, write in complete sentences with the technical terms spelled out. Don't make the reader cross-reference labels or numbering you invented earlier; say what you mean in place.\n" +
+  "\n" +
+  "Match the response to the question: a simple question gets a direct answer in prose, not headers and sections. Use tables only for short enumerable facts, with explanations in the surrounding prose rather than the cells. Calibrate to the user — a bit tighter for an expert, more explanatory for someone newer.\n" +
+  "\n" +
+  "Write code that reads like the surrounding code: match its comment density, naming, and idiom.\n" +
+  "Only write a code comment to state a constraint the code itself can't show — never to say where it came from, what the next line does, or why your change is correct; that's you talking to the reviewer, not the next reader, and it's noise the moment the PR merges.";
+
+/** Branch 1 with upstream `htm` false: brief mode or the pewter-owl tool is on. */
+export const COMMUNICATING_WITH_THE_USER_CONDENSED =
+  "# Communicating with the user\n" +
+  "\n" +
+  "Your text output is what the user reads between tool calls; they usually can't see your thinking or the raw tool results. Write it for a teammate who stepped away and is catching up, not for a log file: they don't know the codenames or shorthand you created along the way, and they didn't watch your process unfold. Before your first tool call, say in a sentence what you're about to do; while working, give brief updates when you find something load-bearing or change direction.\n" +
+  "\n" +
+  'Lead with the outcome. Your first sentence after finishing should answer "what happened" or "what did you find" — the thing the user would ask for if they said "just give me the TLDR." Supporting detail and reasoning come after, for readers who want them.\n' +
+  "\n" +
+  "Being readable and being concise are different things, and readable matters more. If the user has to reread your summary or ask you to explain, any time saved by brevity is gone. The way to keep output short is to be selective about what you include (drop details that don't change what the reader would do next), not to compress the writing into fragments, abbreviations, arrow chains like `A → B → fails`, or jargon. What you do include, write in complete sentences with the technical terms spelled out. Don't make the reader cross-reference labels or numbering you invented earlier; say what you mean in place.\n" +
+  "\n" +
+  "Match the response to the question: a simple question gets a direct answer in prose, not headers and sections. Use tables only for short enumerable facts, with explanations in the surrounding prose rather than the cells. Calibrate to the user — a bit tighter for an expert, more explanatory for someone newer.\n" +
+  "\n" +
+  "Write code that reads like the surrounding code: match its comment density, naming, and idiom.\n" +
+  "Only write a code comment to state a constraint the code itself can't show — never to say where it came from, what the next line does, or why your change is correct; that's you talking to the reviewer, not the next reader, and it's noise the moment the PR merges.";
+
+/** Branch 2, upstream `ph(e)` true. A single sentence. */
+export const LEAN_SECTION =
+  "Write code that reads like the surrounding code: match its comment density, naming, and idiom.";
+
+/** Branch 3, the fallthrough. */
+export const TEXT_OUTPUT_SECTION =
+  "# Text output (does not apply to tool calls)\n" +
+  "Assume users can't see most tool calls or thinking — only your text output. Before your first tool call, state in one sentence what you're about to do. While working, give short updates at key moments: when you find something, when you change direction, or when you hit a blocker. Brief is good — silent is not. One sentence per update is almost always enough.\n" +
+  "\n" +
+  "Don't narrate your internal deliberation. User-facing text should be relevant communication to the user, not a running commentary on your thought process. State results and decisions directly, and focus user-facing text on relevant updates for the user.\n" +
+  "\n" +
+  "When you do write updates, write so the reader can pick up cold: complete sentences, no unexplained jargon or shorthand from earlier in the session. But keep it tight — a clear sentence is better than a clear paragraph.\n" +
+  "\n" +
+  "End-of-turn summary: one or two sentences. What changed and what's next. Nothing else.\n" +
+  "\n" +
+  "Match responses to the task: a simple question gets a direct answer, not headers and sections.\n" +
+  "\n" +
+  "In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max. Don't create planning, decision, or analysis documents unless the user asks for them — work from conversation context, not intermediate files.";
+
+/**
+ * SHA-256 of each constant as executed from the genuine client. A test pins
+ * these so any edit to the text above fails loudly rather than silently
+ * shipping a divergent prompt.
+ */
+export const ANTI_VERBOSITY_DIGESTS = Object.freeze({
+  communicatingWithTheUserFull:
+    "41a8a87303e6f6f8224906daf9741fd6be495b79400854d92078991d15e9c56c",
+  communicatingWithTheUserCondensed:
+    "7028dc6d1492b7616b9b5f2f58416c09a0db5cd671f1032fbaeb9120ad51437b",
+  lean: "ee43af37398581e92bde06d341c98c7b7a9ff6c56023c2bc17b9feaf2d6e31ea",
+  textOutput:
+    "c184a5d4b4b6a0fc374a37c69f72937abf38bcccaa2d0cce0427968fcda3ccc7",
+});
+
+/** Upstream `i_e`, deliberately applied to the RAW caller string. */
+const EAP_PATTERN = /-eap($|\[)/iu;
+
+function catalogueCapability(
+  normalizedId: string,
+  capability: string,
+  profile: ClaudeCodeProtocolProfile,
+): boolean {
+  if (!Object.hasOwn(profile.supportedModels, normalizedId)) return false;
+  return (
+    profile.supportedModels[normalizedId]?.capabilities.includes(capability) ===
+    true
+  );
+}
+
+/**
+ * Upstream `Mte`. This is one of the few places where the catalogue capability
+ * array is genuinely load-bearing: unlike the nine model-capability predicates,
+ * `Mte` has no provider fallback, so the membership test decides the result.
+ */
+function hasFableMitigations(
+  normalizedId: string,
+  profile: ClaudeCodeProtocolProfile,
+): boolean {
+  return (
+    catalogueCapability(normalizedId, "fable_5_mitigations", profile) ||
+    normalizedId === "claude-mythos-5"
+  );
+}
+
+/**
+ * Upstream `Kkd`. Its trailing `return !td()` is false on the first-party
+ * provider this profile pins, so an unrecognised identifier falls through to
+ * the lean branch rather than the text-output branch.
+ *
+ * Upstream also carries `|| t === "claude-mythos-5"` beside the
+ * `lean_prompt` test. It is omitted here because it is unreachable: the only
+ * caller tests `hasFableMitigations` first, which already claims mythos-5 for
+ * the communicating-with-the-user branch. Upstream shares `Kkd` with other
+ * call sites and so still needs it. Restore it if this helper ever gains a
+ * second caller.
+ */
+function usesTextOutputSection(
+  rawModel: string,
+  profile: ClaudeCodeProtocolProfile,
+): boolean {
+  if (EAP_PATTERN.test(rawModel)) return false;
+  const id = normalizeModelId(rawModel);
+  if (catalogueCapability(id, "lean_prompt", profile)) return false;
+  return (
+    id.includes("claude-3-") ||
+    id.includes("haiku") ||
+    id.includes("sonnet") ||
+    id === "claude-opus-4-0" ||
+    id === "claude-opus-4-1" ||
+    id === "claude-opus-4-5" ||
+    id === "claude-opus-4-6" ||
+    id === "claude-opus-4-7"
+  );
+}
+
+/**
+ * Reports which branch of upstream `ytm` a model selects.
+ *
+ * Upstream `gtm` is `return !1`, so branch 1 is gated on `Mte` alone. Note
+ * that `ytm` passes the NORMALISED id to `Mte` but the RAW caller string to
+ * `ph`, because `ph` reaches `i_e`, which must see an unnormalised
+ * `-eap` suffix. That asymmetry is reproduced here.
+ */
+export function selectAntiVerbositySection(
+  rawModel: string,
+  profile: ClaudeCodeProtocolProfile = CLAUDE_CODE_2_1_195_PROFILE,
+): AntiVerbositySection {
+  if (typeof rawModel !== "string" || rawModel.length === 0) {
+    throw new ClaudeCodeWireError("INVALID_INPUT");
+  }
+  if (hasFableMitigations(normalizeModelId(rawModel), profile)) {
+    return "communicating-with-the-user";
+  }
+  return usesTextOutputSection(rawModel, profile) ? "text-output" : "lean";
+}
+
+/** Returns the exact section text the genuine client would emit for a model. */
+export function antiVerbosityText(
+  rawModel: string,
+  policy: AntiVerbosityPolicy = DEFAULT_ANTI_VERBOSITY_POLICY,
+  profile: ClaudeCodeProtocolProfile = CLAUDE_CODE_2_1_195_PROFILE,
+): string {
+  // Validated eagerly, and for every section rather than only the one that
+  // reads it, so a malformed policy fails the same way regardless of which
+  // model it is paired with. `selectAntiVerbositySection` validates its own
+  // argument the same way despite the declared types, because callers reach
+  // this module across an untyped boundary.
+  const candidate: unknown = policy;
+  if (candidate === null || typeof candidate !== "object") {
+    throw new ClaudeCodeWireError("INVALID_INPUT");
+  }
+  const brief: unknown = Reflect.get(candidate, "briefModeEnabled");
+  const pewterOwl: unknown = Reflect.get(candidate, "pewterOwlToolEnabled");
+  if (typeof brief !== "boolean" || typeof pewterOwl !== "boolean") {
+    throw new ClaudeCodeWireError("INVALID_INPUT");
+  }
+  const section = selectAntiVerbositySection(rawModel, profile);
+  if (section === "lean") return LEAN_SECTION;
+  if (section === "text-output") return TEXT_OUTPUT_SECTION;
+  return brief || pewterOwl
+    ? COMMUNICATING_WITH_THE_USER_CONDENSED
+    : COMMUNICATING_WITH_THE_USER_FULL;
+}

package/src/beta-registry.ts

@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-3.0-or-later
+
+interface BetaRegistryEntry {
+  readonly featureKey: string;
+  readonly header: string;
+}
+
+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, upstream `Udd`. */
+export const BETA_REGISTRY = deepFreeze({
+  CLAUDE_CODE: { featureKey: "claude_code", header: "claude-code-20250219" }, // Y2e
+  OAUTH_AUTH: { featureKey: "oauth_auth", header: "oauth-2025-04-20" }, // qIe
+  INTERLEAVED_THINKING: {
+    featureKey: "interleaved_thinking",
+    header: "interleaved-thinking-2025-05-14",
+  }, // Gnt
+  LONG_CONTEXT: { featureKey: "long_context", header: "context-1m-2025-08-07" }, // FY
+  CONTEXT_MANAGEMENT: {
+    featureKey: "context_management",
+    header: "context-management-2025-06-27",
+  }, // X2e
+  STRUCTURED_OUTPUTS: {
+    featureKey: "structured_outputs",
+    header: "structured-outputs-2025-12-15",
+  }, // lte
+  WEB_SEARCH: { featureKey: "web_search", header: "web-search-2025-03-05" }, // IPt
+  ADVANCED_TOOL_USE: {
+    featureKey: "tool_search",
+    header: "advanced-tool-use-2025-11-20",
+  }, // p2r
+  TOOL_SEARCH: {
+    featureKey: "tool_search",
+    header: "tool-search-tool-2025-10-19",
+  }, // xPt
+  EFFORT: { featureKey: "effort", header: "effort-2025-11-24" }, // Wnt
+  TASK_BUDGETS: {
+    featureKey: "task_budgets",
+    header: "task-budgets-2026-03-13",
+  }, // lAn
+  PROMPT_CACHING_SCOPE: {
+    featureKey: "prompt_caching_scope",
+    header: "prompt-caching-scope-2026-01-05",
+  }, // qnt
+  EXTENDED_CACHE_TTL: {
+    featureKey: "extended_cache_ttl",
+    header: "extended-cache-ttl-2025-04-11",
+  }, // J2e
+  SPEED: { featureKey: "speed", header: "fast-mode-2026-02-01" }, // Vnt
+  REDACT_THINKING: {
+    featureKey: "redact_thinking",
+    header: "redact-thinking-2026-02-12",
+  }, // kPt
+  THINKING_TOKEN_COUNT: {
+    featureKey: "thinking_token_count",
+    header: "thinking-token-count-2026-05-13",
+  }, // cAn
+  NARRATION_SUMMARIES: {
+    featureKey: "narration_summaries",
+    header: "summarize-connector-text-2026-03-13",
+  }, // RPt
+  AFK_MODE: { featureKey: "afk_mode", header: "afk-mode-2026-01-31" }, // T0
+  ADVISOR_TOOL: {
+    featureKey: "advisor_tool",
+    header: "advisor-tool-2026-03-01",
+  }, // f2r
+  CACHE_DIAGNOSIS: {
+    featureKey: "cache_diagnosis",
+    header: "cache-diagnosis-2026-04-07",
+  }, // fye
+  CONTEXT_HINT: {
+    featureKey: "context_hint",
+    header: "context-hint-2026-04-09",
+  }, // m2r
+  MCP_SERVERS: {
+    featureKey: "mcp_servers",
+    header: "mcp-servers-2025-12-04",
+  }, // g2r
+  FILES_API: { featureKey: "files_api", header: "files-api-2025-04-14" }, // h2r
+  ENVIRONMENTS: {
+    featureKey: "environments",
+    header: "environments-2025-11-01",
+  }, // y2r
+  CCR_BYOC: { featureKey: "ccr_byoc", header: "ccr-byoc-2025-07-29" }, // _2r
+  MID_CONVERSATION_SYSTEM: {
+    featureKey: "mid_conversation_system",
+    header: "mid-conversation-system-2026-04-07",
+  }, // jY
+  SERVER_SIDE_FALLBACK: {
+    featureKey: "server_side_fallback",
+    header: "server-side-fallback-2026-06-01",
+  }, // r1
+  FALLBACK_CREDIT: {
+    featureKey: "fallback_credit",
+    header: "fallback-credit-2026-06-01",
+  }, // o1
+} satisfies Record<string, BetaRegistryEntry>);
+
+// Reserved for later work packages; upstream `Pvi` third-party filtering.
+export const THIRD_PARTY_ALLOWED_BETAS: ReadonlySet<string> = Object.freeze(
+  new Set([
+    BETA_REGISTRY.CLAUDE_CODE.header,
+    BETA_REGISTRY.INTERLEAVED_THINKING.header,
+    BETA_REGISTRY.LONG_CONTEXT.header,
+    BETA_REGISTRY.CONTEXT_MANAGEMENT.header,
+    BETA_REGISTRY.STRUCTURED_OUTPUTS.header,
+    BETA_REGISTRY.WEB_SEARCH.header,
+    BETA_REGISTRY.EFFORT.header,
+    BETA_REGISTRY.TOOL_SEARCH.header,
+    BETA_REGISTRY.AFK_MODE.header,
+    BETA_REGISTRY.FALLBACK_CREDIT.header,
+  ]),
+);
+
+// Reserved for later work packages; upstream `S2r` provider filtering.
+export const BEDROCK_UNSUPPORTED_BETAS: ReadonlySet<string> = Object.freeze(
+  new Set([
+    BETA_REGISTRY.INTERLEAVED_THINKING.header,
+    BETA_REGISTRY.LONG_CONTEXT.header,
+    BETA_REGISTRY.TOOL_SEARCH.header,
+  ]),
+);
+
+// Reserved for later work packages; upstream `E2r` count-tokens selection.
+export const COUNT_TOKENS_BETAS: ReadonlySet<string> = Object.freeze(
+  new Set([
+    BETA_REGISTRY.CLAUDE_CODE.header,
+    BETA_REGISTRY.INTERLEAVED_THINKING.header,
+    BETA_REGISTRY.CONTEXT_MANAGEMENT.header,
+    BETA_REGISTRY.OAUTH_AUTH.header,
+  ]),
+);