o3

OpenAI publishes no config.json for o3 - no architecture file exists to read. The KV-geometry fields and context_scaling are UNRESOLVABLE-from-primary-source and left null deliberately. ARCHITECTURE UNDISCLOSED. No parameter count, layer count, head geometry, MoE configuration, or attention type is published for o3. All structural fields are null; none estimated. In particular there is NO public evidence that o3 is a mixture-of-experts model, so architecture is recorded as 'other' rather than guessed as 'dense' or 'moe'. DOCUMENTED: 200,000-token context window; 100,000 max output tokens (unusually large); Jun 01 2024 knowledge cutoff; $2.00 input / $0.50 cached input / $8.00 output per 1M tokens. WHAT A SERVING OPERATOR CAN ACTUALLY USE FROM THIS: the reasoning-effort interface (low/medium/high) is a documented latency-versus-quality knob, and combined with the 100K max output the cost model for reasoning models is dominated by generated reasoning tokens rather than prompt length. That is a cost-shape fact, not an architecture fact, and it is the part worth carrying forward. o4-mini is deliberately not recorded as a separate entry: its documented geometry is identical in kind (200K context, 100K output, undisclosed architecture) and its only differentiator is price ($1.10/$0.275/$4.40 per MTok), which belongs in a pricing record rather than a model-architecture record. 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; 200k context published, no scaling method disclosed.