GPT-4.1

OpenAI publishes no config.json for GPT-4.1 - no architecture file exists to read. num_kv_heads, head_dim, gqa_ratio and kv_cache_bytes_per_token are UNRESOLVABLE-from-primary-source and are left null deliberately. Same for context_scaling: with no rope config there is no way to tell whether the 1047576 window is native or extended. ARCHITECTURE UNDISCLOSED. OpenAI publishes no parameter count, layer count, head geometry, or attention type for GPT-4.1 or GPT-4.5. All structural fields are null and none are estimated. DOCUMENTED: 1,047,576-token context window; 32,768 max output tokens; Jun 01 2024 knowledge cutoff; text and image input, text output (no audio, no video); $2.00 input / $0.50 cached input / $8.00 output per 1M tokens. THE CACHE IS THE DOCUMENTED SERVING LEVER, and OpenAI's shape is the opposite of Anthropic's: a flat 0.25x multiplier on cached input with no TTL tiers, no breakpoints, and no minimum-prefix rules. That means OpenAI prompt caching is automatic and prefix-stable with no operator-managed cache lifetime, whereas Anthropic requires explicit cache_control breakpoints and offers a choice of 5-minute or 1-hour TTL at different prices. Comparing cache economics between the two vendors requires accounting for this asymmetry, not just the per-token rates. Also documented as supported: fine-tuning, predicted outputs, structured outputs, and batch. No GPT-4.5 page was retrievable, so GPT-4.5 is deliberately NOT recorded rather than recorded from memory. 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; context 1047576 published, no scaling method disclosed.