Claude Haiku 4.5

Anthropic publishes no config.json for Claude models - there is no architecture file to read. num_kv_heads, head_dim, gqa_ratio and kv_cache_bytes_per_token are therefore UNRESOLVABLE-from-primary-source, not overlooked. Anthropic has never disclosed the KV geometry of any Claude model, so any figure in this record set would be third-party inference. Left null deliberately. ARCHITECTURE UNDISCLOSED; all structural fields null and not estimated. DOCUMENTED: 200K-token context (not 1M like Opus and Sonnet 5.5); 64K max output; extended thinking rather than adaptive; reasoning effort not supported; knowledge cutoff Feb 2025; $1 input / $5 output per MTok; cache write $1.25/MTok (5m) and $2/MTok (1h); cache hits $0.10/MTok. The 200K context against a 64K output cap is the notable shape here: this model is output-bound, not context-bound, which inverts the usual long-context serving constraint. 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; Anthropic publishes a 200k context but not a scaling method, so 'suspected native, not confirmed'.