Claude Opus 5.5

Anthropic publishes no config.json for Claude models - no architecture file exists to read. The four KV-geometry fields are UNRESOLVABLE-from-primary-source and are left null deliberately rather than filled from third-party estimates. ARCHITECTURE IS UNDISCLOSED. Anthropic publishes no parameter count, layer count, head count, head dimension, or attention type for any Claude model. Every structural field in this record is null because there is no primary source for it, not because it was omitted carelessly. I am NOT estimating any of them: a Claude KV-per-token figure would require num_layers, num_kv_heads and head_dim, and inventing any of those would produce a confident wrong number, which is the specific failure this repo exists to prevent. WHAT IS DOCUMENTED AND THEREFORE RECORDED: 1M-token context window; 128K max output tokens; adaptive thinking that is always on; default reasoning effort medium; knowledge cutoff Jun 2026; pricing $4 input / $20 output per MTok; cache writes at $5/MTok (5-minute TTL) and $8/MTok (1-hour TTL); cache hits and refreshes at $0.20/MTok, which is 0.05x base input for this model specifically. WHY THE CACHE BEHAVIOUR IS THE SERVING-RELEVANT PART: per Anthropic's caching doc the default cache lifetime is 5 minutes, refreshed at no charge each time the cached prefix is read, and the lifetime is measured from the START of the request that writes or reads the entry, not from the end of its response. A 4-minute streaming response therefore leaves only about 1 minute for a follow-up request to hit the same prefix. Cached prefixes cannot be manually cleared and expire after at least 5 minutes of inactivity. Maximum 4 breakpoints per request; automatic caching consumes one of the 4 slots. Caches are isolated per workspace within an organization on the Claude API and per organization on Bedrock and Google Cloud. For a serving operator the practical consequence is that long-context agentic workloads should either structure prompts around a stable prefix placed before any varying content, or pay for the 1-hour TTL at 2x base input. A breakpoint placed after per-request content (timestamps, user input) writes a fresh entry every time and never hits. confidence 0.3 is deliberate and reflects only the fields that ARE published. The nulls are correct as nulls, not gaps. SERVICEABILITY JOIN (added 2026-10-03; the architecture x engine matrix this record was missing, with a citation per cell in docs/13-model-compatibility.md): FAMILY=undisclosed. NO KERNEL CLASS CAN BE DERIVED FOR THIS CHECKPOINT, and that is the finding rather than a gap in the table. architecture is 'other' in this record because the vendor publishes no parameter count, no layer count, no head geometry and no attention type; every structural field is null and none is estimated. The correct cell in docs/13-model-compatibility.md is therefore UNKNOWN for every engine column, and it is unknown for a stronger reason than silence elsewhere in this document: a closed model is not served by any engine in data/engines/ at all. Every engine record here is an open-source runtime that loads a checkpoint from a hub or a local path; a closed API model is reached over HTTP and its architecture is whatever the operator cannot see. So the decision-relevant content of this record is not an engine join but the documented cost shape, which the record already carries: context window, max output, cache-write and cache-hit pricing, and reasoning-effort controls. ONE THING THE JOIN DOES ESTABLISH, and it is a real constraint: for an API-served model the engine-side kernel question is not merely unknown, it is MOOT. There is no local KV cache, no paged-attention block manager, no sliding-window layer accounting and no MLA latent to store, because none of that runs on the operator's hardware. Any comparison of the models in this document against this one is a comparison of price and context, not of kernels. Do not fill these cells by analogy with the neighbouring open-weight records. CONTEXT_SCALING_METHOD (none-verified): closed weights, no public config.json; 1M context published, scaling method not documented.