v6.17.0

https://www.npmjs.com/package/oc-codex-multi-auth/v/6.17.0

npx oc-codex-multi-auth@6.17.0 install

Added

GPT-6 Astra (#246). OpenAI released it on 2026-09-03; it routes through the same layers the GPT-5.6 tiers already use.

opencode run "Plan the refactor" --model=openai/gpt-6-astra --variant=high

id	efforts	context / output	shipped in templates
gpt-6-astra	low, medium, high, xhigh, max, ultra	1,050,000 / 128,000	yes
gpt-daybreak-blue-latest	low … ultra	catalog-defined	no, Daybreak-gated
gpt-daybreak-red-latest	low … ultra	catalog-defined	no, Daybreak-gated
gpt-5.6-cyber	low … ultra	catalog-defined	no, Daybreak-gated

Astra is opt-in: neither the gpt-5 alias nor the plugin default resolves to it. It reached a limited set of organizations before Plus/Pro/Business/Enterprise, so an account outside the rollout degrades automatically:

gpt-6-astra → gpt-5.6-sol → gpt-5.6-terra → gpt-5.6-luna → gpt-5.5 → gpt-5.2

Disable with CODEX_AUTH_DISABLE_GPT6_AUTO_FALLBACK=1.

Bare gpt-6 is a plugin-side alias; OpenAI publishes no such id. gpt-6-astra-pro is not a routable Codex id, so it collapses onto gpt-6-astra rather than emitting an unknown slug, the same treatment gpt-5.5-pro gets.

The Daybreak cyber tiers are routed but not shipped (#246). All three need Daybreak program approval, and Blue and Red are visibility: "hide" in the Codex catalog. Listing them in every model picker would cause the avoidable startup failures the templates already keep gpt-5.3-codex-spark out for, so an entitled user adds the id by hand and it works. None of them has a fallback chain, deliberately: degrading a cyber-specialty request onto a general model would answer a security-research prompt with a model nobody asked for, so an unentitled account fails loudly instead.

gpt-5.6-cyber belongs to the 5.6 generation, not GPT-6, and is matched ahead of the bare gpt-5.6 alias, which would otherwise have claimed it and answered from Sol.

One flag worth knowing about. Astra's request shape is responses-lite by default, and unlike every other lite model that is inferred rather than read: the public Codex catalog has carried no gpt-6-astra entry since its 2026-08-20 refresh. Every catalog model from 5.6 onward is use_responses_lite: true with tool_mode: "code_mode_only", which is the basis for the default. Override with CODEX_AUTH_ASTRA_RESPONSES_LITE=0 for the classic shape. Astra is registered as a catalog slug regardless, so it picks up real catalog instructions on the first Codex release that publishes them.

Fixed

Every default fallback tail degraded onto models Codex had retired (#246). gpt-5.4 and gpt-5.4-mini were withdrawn on 2026-08-31; the catalog marks both visibility: "hide" with an upgrade directive naming their replacements, and gpt-5.4-nano has no catalog entry at all. Every tail ended in those three:

before:  gpt-5.5     → gpt-5.4 → gpt-5.4-mini → gpt-5.4-nano
after:   gpt-5.5     → gpt-5.6-terra → gpt-5.6-luna → gpt-5.2
after:   gpt-5-codex → gpt-5.6-terra → gpt-5.5 → gpt-5.2

So an entitlement failure on gpt-5.5 or gpt-5-codex spent its whole attempt budget on withdrawn ids and hard-failed without ever trying a live model. Warming was worse: it starts at gpt-5.5, so all three of its hops were the retired ones. Each retired id now leads with the successor its own catalog entry names, and gpt-5.4-nano gains a chain of its own, having previously been a terminal failure for anyone who selected it.

gpt-5.4-mini stays a shipped base, because removing it would break saved configs that name it. Selecting it costs one round trip before it upgrades to gpt-5.6-luna.

A capitalized reasoning effort bypassed every clamp (#247). reasoningEffort is read straight off opencode.json, where its TypeScript union constrains nothing at runtime, and every clamp compares against lowercase literals:

input	before	after
gpt-6-astra + "ULTRA"	ULTRA	max
gpt-6-astra + "NONE"	NONE	low
gpt-5-codex + "MINIMAL"	MINIMAL	low
gpt-5.1 + "MAX"	MAX	high

ultra is a Codex client-side tier and must never reach the backend. The lowercase spellings of all four already clamped correctly, so this was purely the casing; it affected every family, including gpt-5.1 and gpt-5.2.

An unrecognized reasoning effort shipped verbatim (#247), so a typo produced a backend 400 rather than a working request. gpt-5-codex-mini never had this problem because its branch ends in a catch-all; no other family had one. Unknown tokens now fall back to that family's default effort and log a warning.

Internal

The documentation count check derived nothing: it asserted the literal strings 12 base OAuth models and 53 explicit selector entries against the installer, so growing the templates left it green while the installer advertised counts the templates no longer had. It now derives every count from the two config JSONs and checks each count quoted anywhere in current documentation against them.