Skip to content

fix(providers): register gpt-6-sol and gpt-6-luna with the 1,050,000 context window - #15164

Merged
diegosouzapw merged 6 commits into
diegosouzapw:release/v3.8.52from
shipsfromrio:fix/gpt6-sol-luna-context-window
Oct 8, 2026
Merged

diegosouzapw merged 6 commits into
diegosouzapw:release/v3.8.52from
shipsfromrio:fix/gpt6-sol-luna-context-window

Conversation

@shipsfromrio

Copy link
Copy Markdown
Contributor

Problem

gpt-6-sol and gpt-6-luna were missing from the OpenAI public API registry and from MODEL_SPECS, so an imported OpenAI connection fell back to defaultContextLength (128,000) for them. The issue measured /v1/models advertising 128k for both, against the documented 1,050,000, and combos that include an OpenAI route inherit the smaller window through min(members).

Closes #15023

Fix

  • Add gpt-6-sol and gpt-6-luna to open-sse/config/providers/registry/openai/index.ts with the same public API capabilities already used for gpt-6-astra.
  • Add the two ids to MODEL_SPECS with the same spec, so spec-aware paths (capability filter, compaction guard) stop falling back to 128k.

Out of scope, deliberately: pricing rows for the two models (no published per-token source in the issue) and the family-prefix fallback for unknown imports suggested in the issue's second bullet.

Tests

tests/unit/openai-gpt56-catalog.test.ts: new case for #15023 plus the updated ordering expectation. Fails without the registry change (openai registry must include gpt-6-sol), 5/5 pass with it.

@diegosouzapw
diegosouzapw merged commit e49754f into diegosouzapw:release/v3.8.52 Oct 8, 2026
29 of 51 checks passed
@diegosouzapw

Copy link
Copy Markdown
Owner

Thanks @shipsfromrio — merged into release/v3.8.52; it ships in the next release.

diegosouzapw added a commit that referenced this pull request Oct 8, 2026
* test(translator): expect boolean is_error on tool_result blocks (#15754)

#15754 made the OpenAI-to-Messages translator always emit a boolean is_error on
every tool_result block (strict upstreams such as the Zed hosted proxy
reject requests without it). The older multimodal translation test still
pinned the block shape without the field.

* test(images): include Codex GPT Image models in the image catalog listing (#14976)

#14976 registered gpt-image-2.5-flare and gpt-image-2 under the codex image
provider (routed to the dedicated Codex Images API) and updated the registry
test to the five-id list, but the image catalog route test still pinned the
three GPT-5.6 hosted-tool ids.

* docs(flags): keep RATE_LIMIT_AUTO_ENABLE catalog default in sync with its definition

#15736 changed the catalog Default cell to _(unset)_, but the catalog
documents FEATURE_FLAG_DEFINITIONS 1:1 and the definition (what the
feature-flags API/UI resolves when nothing is set) is still "false".
Restore the code value and keep the corrected runtime explanation in the
description: rateLimitManager reads only the env var and falls back to the
dashboard setting (default on) when it is unset.

* test(combos): pin on-demand per-candidate reads on the tables #15378 left unmemoized

#15353 added a contrast test asserting the on-demand capability path re-reads
the synced catalog per candidate (>50 reads). #15378, merged just before it,
memoized the synced vision verdict behind the catalog version, so that path
now issues 7 synced reads and the contrast went red on the tip.

Keep the contrast on the capability and override tables (still thousands of
per-candidate reads on demand vs <=2 / bounded on the snapshot route) and pin
the memo itself: synced reads stay within the per-provider bound. With the
pre-#15378 module the new assertion fails (336 synced reads).

* test(chatcore): end the prompt-cache fixture on a user turn (#15830)

#15830 re-landed #13572: the first-party Messages provider now strips a trailing
text-only assistant turn (upstream rejects assistant prefill). The prompt-cache
metadata fixture ended on an assistant text block carrying a cache_control
breakpoint, so the strip dropped it and the recorded totalBreakpoints fell from
3 to 2. Append a user turn so the fixture still exercises system, user and
assistant breakpoints; the assertions are unchanged.

* fix(providers): keep discovered Codex effort variants in the exclusive dashboard listing

#13224 lists one <model>-<tier> row per reasoning level the Codex account
advertises (appendSyncedEffortVariants, non-exclusive branch). #15132 then made
Codex an exclusive synced-listing provider, and the exclusive branch returns
before that step, so the provider dashboard / Test All listing lost the
discovered tier rows while /v1/models still advertised them (cx/<model>-max).

Apply the same variant step on the exclusive branch for codex. The variants
come from the live inventory, so #15132's contract (no static aliases the
account does not advertise) still holds; its own tests stay green. The one
assertion in codex-discovered-reasoning that expected a static registry-only
row (gpt-5.6-sol-ultra) next to the live inventory is flipped to #15132's
contract.

* test(providers): keep the custom gpt-6 max_tokens case on an unregistered id (#15164)

The #14869 custom-model case used gpt-6-luna because it was not in the openai
registry, so it stayed on Chat Completions and had to be renamed to
max_completion_tokens. #15164 registered gpt-6-luna with targetFormat
openai-responses, so the request now goes through the Responses translator
(max_output_tokens) and the Chat Completions assertion read undefined.

Use an unregistered gpt-6 id for the custom-model case and add a case for the
registered gpt-6-luna Responses path (max_output_tokens, no max_tokens).

* chore(changelog): add fragment for the v3.8.52 tip unit-red drain
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

fix(providers): Imported OpenAI models default to 128000 context window (GPT-6 capped 8x)

2 participants