No way to set compaction provider.

[Falven]

Client or integration

Codex App

Area

Other

Summary

When trying to use only the GHCP provider, compaction triggers:

Error running remote compact task: unexpected status 404 Not Found: Model gpt-5.6-sol requires the canonical openai provider. Run: ocx provider add openai && ocx sync && ocx restart, url: http://localhost:10100/v1/responses

And there's no way to set the provider for compaction.

Reproduction

Start ocx and send a request that requires compaction

Version

2.31.0

Operating system

macOS 26.6.2

Provider and model

github-copilot

Logs or error output

Error running remote compact task: unexpected status 404 Not Found: Model gpt-5.6-sol requires the canonical openai provider. Run: ocx provider add openai && ocx sync && ocx restart, url: http://localhost:10100/v1/responses

Screenshots and supporting files

No response

Redacted configuration

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[lidge-jun]

리뷰 · 우선순위 58 / 80

이 이슈는 Codex App이 긴 대화를 줄일 때, GitHub Copilot만 켜 둔 사용자가 실패하는 이야기다.
앱이 보내는 모델은 gpt-5.6-sol 이다.
OpenCodex는 그 이름을 네이티브 OpenAI 가족으로 보고, 켜진 openai 공급자가 없으면 404를 준다.
메시지 그대로다. Model gpt-5.6-sol requires the canonical openai provider. Run: ocx provider add openai && ocx sync && ocx restart.
사용자는 2.31.0 / macOS에서 재현했다. 지금 dev 는 2.36.0, HEAD 8df705120 이다. 그 사이 compact 재시도(#2858)는 들어갔지만, 공급자를 고르는 설정은 아직 없다.

코드 경로는 짧다.
src/server/responses/compact.ts 506행이 일반 턴과 같은 routeModel(config, raw.model, ...) 을 부른다.
586행 compactProvider = route.provider 는 그 라우트의 공급자를 그대로 쓴다.
별도 compact 공급자 필드가 없다. 설정 타입에도 compactProvider / compactModel 키가 보이지 않는다.

라우터 쪽은 src/router.ts 695-700행이다.
isBareOpenAiFamilyModel(modelId) 이면 config.providers.openai 가 있고 꺼져 있지 않을 때만 통과한다.
없으면 462-469행 NoEnabledOpenAiProviderError 를 던진다.
compact.ts 507-514행이 그 에러를 404 본문으로 그대로 돌려준다.
계정 네임스페이스 경로(616-626행)도 같은 에러를 쓴다. canonical forward openai 가 아니면 역시 막힌다.

그래서 증상은 'compact 공급자를 못 고른다'가 맞다. 더 정확히 말하면, compact가 턴과 같은 라우터를 쓰는데 Codex App이 네이티브 모델 이름을 보내고, 그 이름은 openai 없이는 라우팅이 안 된다.
GHCP만 있는 구성에서는 일반 대화는 github-copilot 쪽으로 가도, compact만 openai를 요구한다.
#2858 compact handoff는 이미 성공한 compact 모델을 기억해 402/429를 다시 시도한다. 첫 라우팅이 404로 죽으면 그 맵은 쓰이지 않는다.

고치는 방향은 하나가 아니다.
openai를 추가하라는 안내를 앱에 더 잘 보여 주는 것은 임시 안내일 뿐이다. 사용자가 원한 것은 GHCP로 compact 하는 길이다.
설정에 compact 공급자/모델을 두면 types/config 분할 캠페인과 겹친다. 그 캠페인이 commiting 중인 파일에 키를 더하는 PR은 리베이스하지 말고 닫는 편이 낫다.
더 작은 길은, compact가 네이티브 가족을 받았을 때 openai가 없으면 켜진 다른 공급자의 compact 가능 모델로 떨어지거나, '이 구성에서는 remote compact를 할 수 없다'를 404가 아니라 명확한 안내로 주는 것이다.
어느 쪽이든 GHCP /api/chat 가 /responses/compact 를 진짜로 받는지부터 확인해야 한다. 못 받으면 공급자 설정만으로는 부족하다.

경로 src/router.ts 695-700 - 맨이름 gpt-* 는 openai가 없으면 항상 NoEnabledOpenAiProviderError 다. compact만의 예외가 없다.
경로 src/server/responses/compact.ts 506-516 - compact가 턴과 같은 routeModel을 쓰므로, 앱이 보낸 모델 이름이 곧 compact 공급자가 된다.
경로 compactProvider 설정 - HEAD에 키가 없다. 이 이슈의 제목 그대로다.
버전 2.31.0 vs 2.36.0 - 재현 버전과 HEAD 사이 compact 재시도는 들어왔지만, 이 404 경로는 그대로다.

메인테이너의 판단이 필요한 지점

• compact를 반드시 ChatGPT/openai 네이티브로 둘지, GHCP 같은 다른 공급자로 보낼 수 있게 할지
• 설정 키를 추가할지, openai 부재 시 안내만 더 명확히 할지
• 설정 키를 넣는다면 types.ts/config.ts 분할이 끝난 뒤에 할지
• Codex App이 compact 모델을 바꾸는 입력을 이미 가지는지, 앱 쪽 이슈로 넘길지

너의 추천
열어 두세요. 중복으로 닫을 이슈는 지금 목록에 없다.
바로 설정 키 PR을 받기보다, GHCP가 compact 엔드포인트를 받는지부터 확인하고 설계를 고르세요.
openai 없이 네이티브 모델 compact를 받는 길이 없다면, 404 대신 '이 구성에서는 remote compact를 쓰려면 openai를 켜야 한다'를 앱이 읽기 쉬운 코드로 주는 작은 고침이 먼저다.
types/config 에 키를 더하는 초안이 오면 분할 캠페인에 밀려 닫고 다시 받는 편이 낫다.

이 댓글은 grok-bot이 작성했습니다

[lidge-jun]

Relabeling this as an enhancement rather than a bug, and keeping it open — the 404 you hit is
intentional routing behavior, but the capability you are asking for genuinely does not exist.

Why the 404 happens. The router reserves every bare gpt-*/o* model name for canonical
openai, and that check runs before configured model lists and defaultProvider. So a bare
gpt-5.6-sol is never captured by GHCP even when GHCP is your default provider. Compaction has
no separate model selection at all: both the v1 /v1/responses/compact handler and the v2
compaction_trigger turn route whatever model the client sent.

One correction to the framing. There is no compaction-only setting today, which is the real
gap. But it is not true that there is no way to route this to GHCP: a qualified
github-copilot/gpt-5.6-sol routes correctly, since explicit provider namespaces take priority
over bare-family handling. A one-target combo with alias: "gpt-5.6-sol" and nativeAlias: true
also works — though that redirects every request for that bare name, not just compaction, which
is probably not what you want.

What a proper fix looks like. A single optional top-level route selector, applied only when
the request is a compaction request:

{ "responsesCompactionModel": "github-copilot/gpt-5.6-sol" }

One selector rather than separate provider/model fields, so it reuses existing qualified
selectors, combos, policies, and credential resolution. Two things make this more delicate than it
looks, and are why it is not being rushed in alongside the current bug sweep: compaction sends
essentially the whole conversation to the selected provider, so the setting carries real privacy
and billing weight and must be explicit; and v1 and v2 have to agree, or newer clients stay
broken. Native encrypted compaction blobs also may not be readable by a different provider later
in the conversation.

Worth noting the underlying question your report raises but does not answer: why did Codex App
send a bare model during compaction when your ordinary GHCP turns worked? If you still have the
request body or your config, that would be useful — there may be a separate slug-loss defect
hiding behind this one.

[lidge-jun]

Landed on dev via #3201 (squash commit c7f3f6f).

Resolution: no new config key. Compaction turns that name a bare OpenAI-family model (gpt-5.6-sol, ...) now fall back to the configured defaultProvider as the summarizer when there is no enabled canonical openai provider — so a GitHub Copilot-only (or any non-OpenAI-only) setup gets a real compaction result instead of a 404. This applies to both POST /v1/responses/compact and compaction_trigger turns on POST /v1/responses.

What does not change: ordinary turns keep the canonical-openai reservation, account-qualified selectors like side/gpt-5.6-sol still fail closed, and any configuration that already has an enabled openai provider behaves exactly as before. The proxy logs one notice per provider when the fallback engages.

Docs: the compaction section of the proxy-formats reference. If a separate explicit compactionProvider override is still wanted on top of this, please open a follow-up with the concrete case.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}