Honor client-resolved service tier defaults by shijie-oai · Pull Request #23537 · openai/codex

shijie-oai · 2026-05-19T19:36:56Z

Why

Model catalog responses can now advertise a nullable default_service_tier for each model. Codex needs to preserve three distinct states all the way from config/app-server inputs to inference:

no explicit service tier, so the client may apply the current model catalog default when FastMode is enabled
explicit default, meaning the user intentionally wants standard routing
explicit catalog tier ids such as priority, flex, or future tiers

Keeping those states distinct prevents the UI from showing one tier while core sends another, especially after model switches or app-server thread/start / turn/start updates.

What Changed

Plumbed default_service_tier through model catalog protocol types, app-server model responses, generated schemas, model cache fixtures, and provider/model-manager conversions.
Added the request-only default service tier sentinel and normalized legacy config spelling so fast in config.toml still materializes as the runtime/request id priority.
Moved catalog default resolution to the TUI/client side, including recomputing the effective service tier when model/FastMode-dependent surfaces change.
Updated app-server thread lifecycle config construction so serviceTier: null preserves explicit standard-routing intent by mapping to default instead of internal None.
Kept core responsible for validating explicit tiers against the current model and stripping default before /v1/responses, without applying catalog defaults itself.

Validation

CARGO_INCREMENTAL=0 cargo build -p codex-cli
CARGO_INCREMENTAL=0 cargo test -p codex-app-server model_list
cargo test -p codex-tui service_tier
cargo test -p codex-protocol service_tier_for_request
cargo test -p codex-core get_service_tier
RUST_MIN_STACK=8388608 CARGO_INCREMENTAL=0 cargo test -p codex-core service_tier

shijie-oai · 2026-05-19T20:46:11Z

-    /// Toggle the opt-out marker for Codex-managed fast defaults.
-    SetNoticeFastDefaultOptOut(bool),


We are deprecating this notice

shijie-oai · 2026-05-19T23:41:43Z

+        default_input_modalities(),
+    );
+    model.service_tiers = vec![ModelServiceTier {
+        id: ServiceTier::Fast.request_value().to_string(),


Capturing the service-tier fixture note here: ServiceTier::Fast is still a legacy compatibility variant, but ServiceTier::Fast.request_value() resolves to the actual catalog/request id (priority). We discussed spelling priority directly in catalog-shaped tests, but decided not to make that cleanup right now; the important invariant is that the generated id/default value remains priority, not literal fast.

shijie-oai · 2026-05-20T01:15:24Z

+    }
+}
+
+pub(crate) fn service_tier_update_for_core(


Open for better name - the effective_service_tier indicates what the user choice is and service_tier_update_for_core is what we actually provide to core for inferencing.

sayan-oai · 2026-05-20T05:05:13Z

+    if !fast_mode_enabled {
+        return None;


codex:

This early return seems too broad. It drops every configured tier when FastMode is disabled, including explicit flex, even though config parsing and existing tests still treat flex as a valid independent service tier. Should this only suppress managed/catalog Fast defaults, while preserving explicit supported tiers?

I think if fast_mode is off, we should respect it no matter what service_tier is populated with.

isn't this a feature flag that is always true?

technically no - I think enterprise are using this to turn off the fast mode in general - we will do another pass to clean that up. I can work with you guys to figure that path forward.

sayan-oai · 2026-05-20T05:08:57Z

+        return None;
+    }
+
+    let effective = effective_service_tier(config, model, models);


codex:

This makes catalog-default resolution a TUI-side responsibility. AppServerSession benefits from it, but direct app-server callers that omit serviceTier still reach core with no resolved default. Should this live below the client layer so backend default_service_tier semantics apply consistently across all entrypoints?

but you mentioned offline that we are ok offloading this responsibility to clients like TUI and app and not doing it in core? double checking

Ya I think that was a choice we made to intentionally have the responsibility sit with the client.

shijie-oai · 2026-05-20T15:15:44Z

@aibrahim-oai Can you give this a read too? want to make sure you also understand the mechnism behind what we talked about.

aibrahim-oai · 2026-05-20T16:19:47Z

 #[serde(rename_all = "lowercase")]
 #[strum(serialize_all = "lowercase")]
 pub enum ServiceTier {
+    Default,


This one is deprecated, do we actually need to add default to it?

Good point - let me get rid of this and will add a comment about deprecation here.

shijie-oai commented May 19, 2026

View reviewed changes

shijie-oai added the code-reviewed label May 20, 2026

shijie-oai commented May 20, 2026

View reviewed changes

shijie-oai marked this pull request as ready for review May 20, 2026 04:27

shijie-oai requested a review from a team as a code owner May 20, 2026 04:27

shijie-oai force-pushed the shijie/better-service-tier-2 branch from a7a2e86 to ed7aa15 Compare May 20, 2026 04:29

sayan-oai reviewed May 20, 2026

View reviewed changes

sayan-oai approved these changes May 20, 2026

View reviewed changes

shijie-oai requested a review from aibrahim-oai May 20, 2026 15:15

aibrahim-oai reviewed May 20, 2026

View reviewed changes

Comment thread codex-rs/core/src/config/edit.rs Outdated

aibrahim-oai reviewed May 20, 2026

View reviewed changes

Comment thread codex-rs/core/src/config/mod.rs Outdated

shijie-oai force-pushed the shijie/better-service-tier-2 branch 2 times, most recently from 4babfe4 to a77ebfa Compare May 20, 2026 20:18

aibrahim-oai approved these changes May 20, 2026

View reviewed changes

shijie-oai added 2 commits May 20, 2026 15:03

Honor client-resolved service tier defaults

574981b

Clarify default service tier sentinel

c9d92b4

shijie-oai force-pushed the shijie/better-service-tier-2 branch from a77ebfa to c9d92b4 Compare May 20, 2026 22:21

codex: fix CI failure on PR #23537

6c2aa9a

shijie-oai merged commit 370b13a into main May 20, 2026
31 checks passed

shijie-oai deleted the shijie/better-service-tier-2 branch May 20, 2026 22:57

github-actions Bot locked and limited conversation to collaborators May 20, 2026

		/// Toggle the opt-out marker for Codex-managed fast defaults.
		SetNoticeFastDefaultOptOut(bool),

Conversation

shijie-oai commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why

What Changed

Validation

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shijie-oai May 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shijie-oai commented May 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

shijie-oai commented May 19, 2026 •

edited

Loading

shijie-oai May 20, 2026 •

edited

Loading