Repository navigation
[Feature][GitHub Copilot] Expose model context tiers and apply the OpenCodex cap #3281
Description
Activity
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
리뷰 · 우선순위 54 / 80
이 이슈는 GitHub Copilot 쪽 업스트림 context tier를 고르는 스위치를 달자는 요청이다, 이미 끝난
#3156/#3163과는 결이 다릅니다.#3163은 Copilot/models가 주는capabilities.limits.max_context_window_tokens를 카탈로그에 읽기만 하게 고쳤고, 지금devHEAD(fd324dc88, package2.41.0)의src/codex/catalog/provider-fetch.tscatalogHintsFromModelsApiItem에도 그 경로가 들어가 있습니다. 그런데 Copilot GPT-5.6 Luna처럼 default / long_context 두 칸이 있는 모델은, OpenCodex의providerContextCaps나modelContextWindows만 올려도 업스트림 요청이 long 티어로 바뀌지는 않습니다. Codex가 보는 창만 커지고, 실제 Copilot 쪽은 여전히 default 티어에 남는 상태가 됩니다. 그래서 긴 대화를 덜 압축하려면 “읽은 숫자”가 아니라 “보낼 티어”가 필요합니다.지금 HEAD에서 Copilot 요청 준비는
src/providers/github-copilot-transport.ts의resolveGithubCopilotTransport가 전부입니다. 하는 일은 에디터 fingerprint 헤더를 채우고, OAuth면*.githubcopilot.comallowlist로 baseUrl을 고정하는 것뿐입니다. body에contextTier같은 필드를 넣거나, 모델별로 default/long_context를 고르는 설정 키는 없습니다.ocx provider edit(src/cli/provider-runtime.ts)에도--model-context-tier같은 플래그가 없고, managementPATCH /api/providers는modelContextWindows숫자 맵은 받지만 티어 enum 맵은 없습니다. 반면 네이티브 Codex 로그인 경로에는 이미nativeOpenAiContextTier(src/codex/catalog/metadata.ts)가 있어서 Cursor local-agent Context 선택기용 default/long 쌍을 광고합니다. 그건 openai 네이티브 창 광고이지 Copilot 업스트림 티어 선택이 아닙니다. Copilot 정적 시드에는gpt-5.6-luna/sol/terra가 들어 있고modelWireDefaults로 Responses를 타게 되어 있어서(#748 계열), 티어를 붙인다면 Chat가 아니라 Responses 송신 경로에 꽂는 쪽이 맞습니다.요청 본문이 말한 모양은 타당합니다. (1) provider 설정·헤드리스 CLI에 모델별
default|long_context, (2) 지원 모델 요청에만 전달, (3) 카탈로그에는 long 티어 능력을 먼저 알린 뒤 기존 OpenCodex provider cap으로 Codex-visible 창을 줄이기, (4) 미설정이면 지금과 동일. Copilot SDK 쪽 공개 타입에도 session 메타의contextTier가default|long_context로 잡혀 있어 값 이름은 이슈 제안과 같습니다. 다만 VS Code Copilot의 Responses body 조립 코드가 그 필드를 api.githubcopilot.com으로 그대로 넘기는지는 이 저장소만으로는 확정이 안 됩니다. 그래서 구현 PR은 “설정 UI만”이 아니라 라이브 프로브로 와이어 필드/헤더를 증명하는 쪽이 안전합니다. types/config 스플릿 캠페인과도 겹칩니다. 새 provider 필드를src/types/provider.ts와 validation·GUI에 넣을 때, 스플릿으로 곧 갈릴 큰 PR 위에 올리면 close-don't-rebase 대상이 될 수 있으니 작은 전용 PR이 낫습니다.src/providers/github-copilot-transport.ts- 헤더·baseUrl만 다루고 요청 body/티어 주입 지점이 없다. long_context를 고를 자리가 비어 있다
src/cli/provider-runtime.ts-ocx provider edit에 이슈가 제안한--model-context-tier류 플래그가 없다
src/server/management/provider-routes.ts-modelContextWindows숫자 맵은 받지만default|long_contextenum 맵 계약이 없다
src/providers/context-cap.ts/applyProviderContextCap- Codex-visible cap은 이미 있다. 이슈가 원하는 “long 능력 광고 후 cap” 순서를 카탈로그 힌트에 어떻게 심을지 설계가 비어 있다
심볼nativeOpenAiContextTier- 네이티브 openai용 Cursor 선택기 쌍이라 Copilot 업스트림 티어와 이름이 비슷해 보이지만 경로가 다르다. 그대로 재사용하면 안 된다
이슈 본문 예시ocx provider edit github-copilot --model-context-tier gpt-5.6-luna=long_context- CLI 모양이 구체적이라 재현·수락 기준은 좋지만, 실제 와이어 필드명은 아직 증거 부족이다메인테이너의 판단이 필요한 지점
- Copilot에 넣을 정확한 와이어(요청 body
contextTier인지, 헤더/세션 RPC인지)를 라이브 프로브로 고정할지, 아니면 문서화된 SDK 값만 믿고 갈지 - 카탈로그에 long 창을 먼저 광고한 뒤
providerContextCaps로 줄일지, Codex-visible 창은 cap만 보여 주고 업스트림만 long으로 보낼지(compact 빈도 vs 사용자에게 보이는 숫자) - 티어 스위치를
gpt-5.6-*Responses 모델만으로 좁힐지, discovery가 티어를 알리는 모든 Copilot 모델로 넓힐지 - 새 설정 키를 types/config 스플릿 전에 작은 PR로 받을지, 스플릿 열차 뒤로 미룰지
너의 추천
#3156/#3163중복으로 닫지 말고 enhancement로 둔다. 구현은 (a) 라이브로 확인한 와이어에contextTier를 모델별로만 넣고, (b) 미설정·미지원 모델은 무패스, (c) 카탈로그는 long 능력을 알린 뒤 기존applyProviderContextCap으로 Codex 창을 깎는 작은 PR이 맞다. Cursor Private Inference / Kiro 열차보다 급하지는 않으니help wanted를 붙여 외부 PR을 받아도 되고, 와이어 증거가 없는 PR은 머지하지 않는 편이 안전하다.이 댓글은 grok-bot이 작성했습니다
- Copilot에 넣을 정확한 와이어(요청 body
Closing in favor of #3377, which carries the remaining scope forward.
Thank you @Simon-Opopeee — the request for GitHub Copilot model context tiers is valid and still unimplemented.
Verified current state.
src/providers/github-copilot-transport.tsonly enriches headers and base URL; provider edit has no context-tier option.Your PR #3282 implements this and remains open — it is not superseded by the consolidation.
All three open requests of this kind are blocked at the same layer: the provider/model row has nowhere to declare what the model can do, so each one would otherwise land as a separate bespoke flag. #3377 asks for the capability block that all three populate, names this issue, and credits you for the original analysis.
Please follow #3377; if the consolidation lost a detail you asked for, say so there and it will be added.
Area
Multiple areas
What are you trying to accomplish?
Use GitHub Copilot GPT-5.6 Luna with its long-context tier while keeping OpenCodex's provider cap as the effective Codex-visible limit, so long conversations compact less often.
What prevents this today?
OpenCodex can cap a provider context window, but the GitHub Copilot route currently leaves the upstream model on its default context tier. Raising the OpenCodex cap alone therefore does not opt the Copilot request into the larger upstream context.
What should OpenCodex do?
Expose a small per-model GitHub Copilot context-tier setting with
defaultandlong_contextvalues in the provider settings and headless CLI. Forward the selected tier on compatible requests, advertise the long-tier capability before applying the existing OpenCodex provider cap, preserve current behavior when unset, and avoid forcing the tier on unsupported models.Example usage or interface
In the GitHub Copilot provider settings, choose Long context (when supported). The equivalent headless command is:
With a
400000provider cap, the catalog should remain capped at 400,000 tokens while the upstream request carriescontextTier: "long_context".Alternatives or workarounds
The current workaround is to edit the provider configuration manually or use a locally patched OpenCodex build. The VS Code Copilot Chat client exposes the tier, but the OpenCodex provider settings do not.
Additional context
This is separate from #3156/#3163, which addressed reading Copilot context-window metadata. This request concerns selecting and forwarding the upstream context tier. No credential or OAuth-flow change is required.
Checks