Unified Model Routing Architecture

What it is

The card discloses that GPT-5 is not a single static model but a routing system that selects among gpt-5-main, gpt-5-thinking, and gpt-5-thinking-nano based on task type, with capability depth and reasoning mode varying by sub-model and access configuration.

Why it matters (compliance & governance perspective)

This provision establishes that the capabilities users and operators access under the GPT-5 designation may vary depending on routing decisions made by the system, which has implications for reproducibility, benchmarking, and regulatory conformity assessments that assume stable model behavior.

Consumer impact (what this means for users)

Under this architecture, the specific sub-model serving a given request is determined by the routing system rather than by direct user selection, meaning that the reasoning depth and capability profile of responses may vary across sessions or access tiers without explicit user visibility.

Institutional analysis (Compliance & governance intelligence)

1) REGULATORY LANDSCAPE: The routing architecture disclosure engages the EU AI Act's transparency requirements for GPAI models, which may require that deployers disclose when AI-generated content is produced and which model configuration is in use. The FTC's guidance on AI transparency may also be relevant if the routing system produces materially different outputs under the same product branding without adequate user disclosure. 2) GOVERNANCE EXPOSURE: Medium. The dynamic routing design means that compliance assessments, bias evaluations, and capability audits conducted on one sub-model may not fully represent the behavior of the deployed system in production, creating a gap between static evaluation documentation and live deployment behavior. 3) JURISDICTION FLAGS: EU deployers are subject to GPAI transparency obligations that may require disclosure of which model version or configuration produced a given output. U.S. federal agencies piloting GPT-5 under AI governance executive orders may face additional documentation requirements if the routing system is not deterministic. 4) CONTRACT AND VENDOR IMPLICATIONS: API consumers and enterprise licensees should assess whether their vendor agreements specify which sub-model handles their requests, whether routing decisions are logged and auditable, and whether changes to routing logic constitute a material modification requiring notice. 5) COMPLIANCE CONSIDERATIONS: Compliance teams should request documentation from OpenAI clarifying how routing decisions are made, whether routing logs are available for audit, and whether the safety evaluations disclosed in the system card apply equally to all sub-models in the routing pool.

Applicable agencies

Provision details

Other risks in this policy

• Preparedness Framework Risk Rating: Medium high
• Operator-Level System Prompt Controls medium
• External Red-Teaming and Third-Party Safety Evaluation low
• Refusal Training and Output Mitigation Measures medium
• CBRN Capability Disclosure high
• Model Autonomy Risk Category high