Ultrafast mode for Astra on Codex?

[MoralStrike]

Hi,

Astra has an Ultrafast mode (on Pro anyway).
Good to use when you know a reset is coming.

Is it in Omniroute?

I've only found this in the latest version:

---

---

and it doesn't work for Astra.

1. Is Ultrafast planned?
2. Why is priority tier for 5.6 models only?

Thanks

[diegosouzapw]

@MoralStrike Thanks for the screenshot. On the two questions:

1. "Ultrafast": I don't find that name anywhere in OmniRoute. What we support for Codex is the service_tier request field with the values default, priority (shown as "Fast") and flex. I haven't verified how OpenAI exposes an "Ultrafast" mode, so I can't say whether it maps to a tier we could send.
2. "Priority tier for 5.6 models only": that list isn't a limit of the feature. In v3.8.51 the built-in default list already includes gpt-6-astra, gpt-6-sol and gpt-6-luna besides the 5.6 and 5.5 ones (since fix(sse): include GPT-6 in default Codex service tiers #14986). Your screenshot shows only 4 models, which means your saved Fast Tier settings carry an older list that overrides the default. The checklist in Settings also only offers a fixed set of 4 names (the 5.6 models and 5.5), so you can't tick Astra there. That's a gap on our side, tracked in fix: Codex Fast Tier checklist cannot show or select GPT-6 defaults #16486.

Workaround until it's fixed: Providers → Codex → your connection → the per-connection "Codex service tier" setting. It takes precedence over the global list, and I'd expect it to apply to Astra (I haven't tested that on a live Codex account).

[MoralStrike]

@diegosouzapw

Thanks for the reply.

Ultrafast is different from the older priority tier, I believe. IIRC the priority tier was giving only a ~1.5x speed boost on older models. Ultrafast can be up to 8x faster (but also 2.5x more expensive).

Here are the docs:

https://developers.openai.com/api/docs/guides/ultrafast-mode

Notice service_tier="ultrafast"
which is different from service_tier="priority"

When connecting directly without a router gateway, I believe it's exposed as a lightning icon in the GUI:

[MoralStrike]

Their press release:

https://x.com/OpenAIDevs/status/2104996045482778973

[diegosouzapw]

@MoralStrike Thanks for the link. I can't open X from here, so I can't read the announcement. If you paste the text that describes Ultrafast (the part about how it's requested: a model name, a parameter, or a setting), I can check whether OmniRoute can send it. For now the only related thing we send is the service_tier field (default, priority, flex), tracked for the checklist gap in #16486.

[MoralStrike]

@diegosouzapw

Thanks for the reply.
Have you had a chance to take a look at the docs I linked to above:

https://developers.openai.com/api/docs/guides/ultrafast-mode

It has code examples. Is that helpful?

[diegosouzapw]

@MoralStrike Yes, that's helpful, thank you. I read the page (as text). It says Ultrafast is a service_tier value, ultrafast, available for gpt-6-astra and gpt-6.1-sol, with separate rate limits and a higher cost, and it recommends WebSockets.

What OmniRoute does today, from reading the code (I haven't tested it): the dashboard settings only offer default, priority (Fast) and flex, so you can't pick Ultrafast there. A service_tier your client sends in the request body is forwarded as-is when nothing else overrides it, so a client that sends ultrafast itself might get through. Whether the ChatGPT-OAuth Codex backend accepts it, and not just the API-key one, I don't know.

I've opened #16678 to add it as a real option, to be validated on a real account before we say it works. The "5.6 only" checklist problem is #16486.

[pacocartones]

Adding what I found reading the code for #16678, because ultrafast is handled differently in two places, and the maintainer's note that a client-sent value is "forwarded as-is" is true for only one of them. This is all from reading release/v3.8.52 (7f1be3bbf0); I haven't tried it on a live Codex account.

1. The request is forwarded. In open-sse/executors/codex.ts:1259-1262 the tier sent upstream is the per-key forced tier, else normalizeServiceTierValue(body.service_tier). That function (codex.ts:313) lowercases the string and returns it, with only fast rewritten, so "ultrafast" reaches the Codex backend unchanged and the per-connection default is not applied.

2. The accounting does not know the value. Before the executor, handleChatCore computes the effective tier with resolveEffectiveServiceTier (open-sse/handlers/chatCore/serviceTier.ts:27-41), which uses normalizeCodexServiceTier (src/lib/providers/requestDefaults.ts:60-68). That type is "default" | "priority" | "flex", and the function returns undefined for anything else, ultrafast included. The result falls back to the connection default or "standard". That tier is what calculateCost receives (nonStreamingResponse.ts:774, streamingCost.ts), and getCodexFastCostMultiplier (src/lib/usage/costCalculator.ts:85-125) returns 1 for any tier that isn't flex, priority or fast. So a request that really went out as ultrafast would be recorded and priced as a standard one, while the thread says Ultrafast costs more. The same normalizer reads the tier the upstream reports back (resolveReportedServiceTier), so the response side has the same blind spot.

3. A rejection may change later requests. If the ChatGPT-OAuth backend turns ultrafast down with a 400 that names the field, open-sse/executors/base/fieldDowngradeRecovery.ts deletes it and retries. With auto-learn on (isAutoLearnGloballyEnabled() or the provider's autoLearn), an "unsupported parameter" style error also adds the field to the provider's blocklist (addParamToBlocklist), and open-sse/translator/paramSupport.ts reads that config when it prepares requests, so the field can stop being sent on later requests for that model (I haven't checked that every Codex route goes through it). service_tier is only protected from this when a per-key forced tier exists (base.ts:1619), not when the client supplies it. I haven't triggered this, so it only matters if that backend answers that way.

So for #16678 I'd expect the change to touch more than the settings list: CodexServiceTier and normalizeCodexServiceTier, an entry in the cost multiplier table (the value should come from OpenAI's published price, which I haven't looked up), and a decision on whether a client-sent service_tier should be protected from the field-downgrade retry.

[MoralStrike]

What OmniRoute does today, from reading the code (I haven't tested it): the dashboard settings only offer default, priority (Fast) and flex, so you can't pick Ultrafast there. A service_tier your client sends in the request body is forwarded as-is when nothing else overrides it, so a client that sends ultrafast itself might get through. Whether the ChatGPT-OAuth Codex backend accepts it, and not just the API-key one, I don't know.

@diegosouzapw

The ultrafast UI does not show up in the VS Code extension when used via Omniroute for some reason. So, having it "forwarded as-is" seems to be impossible with Omniroute.

It might be a catalogue thing, not sure.

[diegosouzapw]

@MoralStrike Thanks, that's an important detail: if the VS Code extension never shows Ultrafast through OmniRoute, then the extension is probably deciding from the model catalog it gets from us, not from what we'd forward. I haven't checked what our model list says about service tiers for the Codex models, so I can't say yet; I've added your observation to #16678.

And thank you @pacocartones: your trace of #16678 is right and I was too loose before. The tier a client sends in the body is forwarded by the executor, but the earlier step that computes the "effective" tier only knows default, priority and flex, so ultrafast isn't recognized there (that affects accounting, not the request). I haven't run it on a live account either.

[MoralStrike]

@diegosouzapw

Digging through the Codex harness' code:

https://github.com/search?q=repo%3Aopenai%2Fcodex+ultrafast&type=code

It's seems more clear that Fast and Ultrafast are separate tiers.

Found this:

https://github.com/openai/codex/blob/859bbc87fc80c18a72e08b181e301ddb4f8dabea/codex-rs/app-server/README.md?plain=1#L285

Managed model provider requirements

configRequirements/read reports supportsIndependentSpeedModes: true when
features.fast_mode and features.ultrafast_mode independently control Fast and
Ultra Fast. Older servers omit this field and use Fast mode as a shared speed
gate. Missing individual feature requirements impose no additional restriction;
the model catalog still determines which service tiers a model supports.

This is the doc for the Agent SDK. So, catalog does indeed seems to be at least one of the blockers.

[pacocartones]

On the catalog question: for the VS Code endpoint, OmniRoute builds the speed options itself, and ultrafast is not one of them. From release/v3.8.52 (3c3edb9ef3):

• src/lib/vscode/serviceTierVariants.ts:5-6: the tier variants are a closed list, SERVICE_TIER_VARIANT_PATTERN = /__tier_(priority|flex)$/i and SUPPORTED_VSCODE_SERVICE_TIERS = ["priority", "flex"].
• expandVscodeServiceTierModels (:103-135) publishes each eligible Codex model three times: the base id, <model>__tier_priority (shown as "Fast", :137-145) and <model>__tier_flex. The /v1/vscode/[token]/models, api/tags and api/show routes all list models through it.
• Eligibility (:65-92) is codex/cx models in CODEX_FAST_TIER_DEFAULT_SUPPORTED_MODELS (src/lib/providers/codexFastTier.ts:16-25), which already includes gpt-6-astra and gpt-6.1-sol. So Astra does get a Fast and a Flex variant there, just no Ultrafast one.
• When a variant is chosen, resolveVscodeServiceTierRequest (:147-174) strips the suffix and sets service_tier to priority or flex, but only if the request has no service_tier of its own.
• normalizeServiceTierId (src/shared/utils/serviceTierLabels.ts:19-24) maps anything other than priority/fast/flex to standard. Adding ultrafast to the two lists above would not be enough on its own: this function and the ServiceTierId type would need it too.

So if your extension talks to OmniRoute through the /v1/vscode/<token>/… routes, it can only ever offer Default, Fast and Flex, whatever the upstream catalog says. That would match what you describe. A client that sends service_tier: "ultrafast" in the body itself would still be forwarded, as the maintainer noted above, unless the API key forces a tier (open-sse/executors/codex.ts:1342-1343). I haven't run this against a live Codex account; it's from reading the code. Since #16678 (open) is the request to support ultrafast, the VS Code variant list is probably one more place it would need to touch.