accept 413 gracefully

[DamnUi]

Client or integration

Codex App

Area

Proxy and routing

Summary

proxy returns four one three payload too large, provider error four one three.

Reproduction

start Ocx
send lot of text and some images to opus on github copilot provider
413 on output

Version

2.42.0

Operating system

mac O S 26.2Tahoe

Provider and model

opus 5 GitHub Copilot Provider

Logs or error output

Screenshots and supporting files

i think this was supposed to be fixed last update and I have made the same report earlier but it's not. What I think it's supposed to do is accept it gracefully like open code does and allow me to send in the prompt by removing a few things or automatically remove a few things maybe without erasing the work the model has done

Redacted configuration

Checks

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

[lidge-jun]

리뷰 · 우선순위 63 / 80

이 이슈는 Codex App에서 GitHub Copilot 제공자의 Opus로 긴 글과 이미지를 한꺼번에 보냈을 때, 프록시가 413 payload too large / provider error 413으로 끊기고 채팅이 막힌다는 보고입니다. 작성자는 같은 증상을 예전에 올렸고, “지난 업데이트에서 고쳐졌어야 한다”고 말합니다. 실제로 같은 작성자의 #3170이 그 요청이었고, #3177(0d6424f80, fix(responses): surface provider 413 as terminal context overflow)로 닫혔습니다. 그 수정은 이미 v2.42.0에도 들어 있습니다(지금 dev HEAD af50c6d34 / package 2.43.0에도 그대로 있습니다). 그래서 “아예 안 고쳐진 새 버그”라기보다, 닫힌 수정이 커버하는 범위와 사용자가 기대하는 OpenCode식 동작이 아직 어긋나는 잔여 이슈로 보는 편이 맞습니다.

#3177이 한 일은 단순합니다. 스트림이 시작되기 전에 공급자가 HTTP 413을 주면, Codex는 그걸 “예상 못한 전송 실패”로 보고 같은 큰 요청을 최대 5번까지 다시 보냅니다. 그래서 채팅이 완전히 막혔습니다. 수정 후에는 src/server/responses/context-overflow.ts의 streamingContextOverflowResponse가 그 413을 한 번의 종료 이벤트로 바꿉니다. 이벤트에는 context_length_exceeded 코드와 retryable: false가 붙고, 안내 문구는 프록시가 직접 만든 PROVIDER_INPUT_TOO_LARGE_MESSAGE입니다. 이렇게 하면 Codex가 재연결 루프를 멈추고, 다음 턴에서 자체 압축(compaction) 정책을 돌릴 수 있습니다. src/server/responses/core.ts의 패스스루·번역·아웃바운드 거절·Anthropic 이미지 한 단계 재시도 소진 경로에서도 같은 변환을 탑니다.

다만 그 수정은 프롬프트나 이미지를 자동으로 잘라 내지 않습니다. #3177 본문도 “silently deleting prompts or images”를 하지 않는다고 명시했습니다. 작성자가 지금 원하는 것(“OpenCode처럼 몇 개를 빼 주거나 자동으로 줄여서, 모델이 해 둔 작업을 지우지 않고 계속 보내기”)은 종료 신호 + 다음 턴 압축보다 한 단계 더 나간 현재 턴 자동 축소에 가깝습니다. 그건 열린 기능 이슈 #2511(제공자별 바이트 예산으로 이미지 축소·가지치기) 쪽에 더 가깝고, 인바운드 본문 한도 자체는 #3573이 따로 있습니다. Anthropic 어댑터만의 이미지 한 단계 재시도(src/server/image-retry.ts의 shouldAttemptImageTierRetry, adapterName === "anthropic"일 때만)도 GitHub Copilot의 기본 openai-chat 경로에는 그대로 적용되지 않습니다.

작성자 환경은 Codex App + github-copilot + Opus + 텍스트·이미지 혼합 + macOS + 보고 버전 2.42.0입니다. 레지스트리에서 github-copilot은 기본 어댑터가 openai-chat이고, 일부 GPT 계열만 modelWireDefaults로 Responses를 탑니다. Opus류는 라이브 카탈로그로 붙는 경우가 많아서, 어떤 와이어로 413이 왔는지(Responses 스트림 변환이 탔는지, 비스트림/다른 경로로 날 HTTP 413이 남았는지)를 로그로 확인해야 합니다. 스크린샷에 보이는 provider error 413 문구만으로는, (1) #3177 변환 후에도 이벤트 status 필드가 413이라 UI가 그렇게 그리는 경우, (2) 변환을 안 탄 잔여 경로, (3) 변환은 됐지만 다음 턴 압축이 이미지를 충분히 줄이지 못해 같은 실패가 반복되는 경우를 구분할 수 없습니다.

라인 / 경로 - 이게 무슨 문제다

src/server/responses/context-overflow.ts - #3177 종료 매핑은 이미 dev/v2.42.0에 있음. 이 이슈를 “미수정”으로 다시 열면 중복이 됨. 잔여 범위를 적어야 함
src/server/responses/core.ts (413 → streamingContextOverflowResponse 분기들) - 스트림·비콤보 경로 위주. 비스트림 413은 상태/본문 유지를 의도적으로 남김. Codex App이 비스트림이면 옛 UI가 남을 수 있음
src/server/image-retry.ts - 이미지 413 재시도는 Anthropic 어댑터 + 인라인 이미지일 때만 1회. Copilot/Opus 경로에는 자동 축소가 없음
src/providers/registry.ts (github-copilot) - 기본 openai-chat, Opus는 시드 목록에 없고 라이브 모델. 실제 wire/adapter를 재현 로그 없이 단정하면 안 됨
#2511 / #3573 - 작성자가 말하는 “자동으로 몇 개 제거”와 인바운드 한도는 여기 기능 범위. #3675와 한 PR로 섞으면 범위가 커짐

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

• #3675를 #3170의 잔여(재현·와이어 확인)로 두고 조사할지, 아니면 OpenCode식 자동 축소 요청으로 보고 #2511에 묶고 이 이슈는 중복 종료할지
• Codex App이 보여주는 provider error 413이 변환 후에도 정상 UI인지, 아니면 변환이 안 탄 회귀인지(로그의SSE에 context_length_exceeded가 있는지) 확인 기준을 어디에 둘지
• GitHub Copilot + Opus(+이미지)에 Anthropic식 이미지 재시도/바이트 예산을 확장할지, #2511 opt-in으로만 갈지

너의 추천

닫지 말고 열어 두되, 제목/본문에 “#3170/#3177 이후 잔여: Copilot·Opus에서 종료 매핑 후에도 막히거나, OpenCode식 현재 턴 자동 축소가 없다”고 범위를 적으세요. 작성자에게 (1) 같은 실패 직후 프록시 로그에 context_length_exceeded / streamingContextOverflowResponse 흔적이 있는지, (2) 모델 id 정확한 문자열, (3) 가능하면 /v1/responses SSE 한 토막을 요청하세요. 자동 삭제·가지치기는 #2511로 연결하고, 인바운드 한도만의 문제는 #3573으로 분리하세요. #3177을 다시 구현하지 마세요.

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