Claude Code에서 DeepSeek Input length exceeds maximum 오류를 복구하는 방법
먼저 diff와 작업 상태를 모델 밖에 저장한 뒤 범위를 좁힌 /compact를 시도합니다. 이마저 실패하면 checkpoint 또는 빈 세션으로 복구하고, 실제 모델·gateway·조기 compact 임계값을 점검합니다.
목차
Claude Code에 짧은 지시를 하나 추가했는데 status_code=400, Input length 1048609 exceeds the maximum length 1048566.가 반환될 수 있습니다. 같은 요청을 반복하거나 “43글자만 지우면 된다”고 판단하지 마세요. 가장 안전한 순서는 코드와 작업 상태를 모델 밖에 보존하고, 범위를 지정한 /compact를 시도한 뒤, compact 자체가 실패하면 checkpoint나 빈 세션으로 옮기고, 마지막으로 모델·Claude Code·중간 gateway 중 어느 계층이 요청을 거부했는지 분리하는 것입니다.
이 메시지가 확실히 말해 주는 것은 어느 계층이 입력을 상한보다 43개의 ‘정의되지 않은 단위’만큼 길다고 판단했다는 사실뿐입니다. 그 단위가 token인지, 문자 수인지, byte인지 알 수 없습니다. 요청이 DeepSeek까지 도달했다는 증거도 아닙니다. 실제 model ID, Base URL, Claude Code 버전, proxy 경로, 원본 response header가 없으면 특정 모델의 결함으로 단정할 수 없습니다.
다음 모델 호출 전에 작업부터 보존하기
먼저 넘친 대화에서 재시도를 멈추세요. 코드 변경은 대개 이미 디스크에 기록되어 있습니다. 잃기 쉬운 것은 대화 안에만 남아 있는 정보입니다. 무엇을 바꿨는지, 어디까지 검증했는지, 다음 단계가 무엇이었는지가 여기에 해당합니다.
다른 terminal을 열고 모델에게 요약을 시키지 않은 채 현재 상태를 저장합니다.
claude --version
git status --short
git diff --stat
git diff > claude-context-recovery.patch
git diff --cached > claude-context-recovery-staged.patchGit 저장소가 아니라면 수정한 파일을 복사하거나 editor의 local history로 snapshot을 만드세요. 그다음 짧은 RECOVERY.md를 직접 작성합니다.
목표:
수정한 파일:
검증 완료:
아직 실패하는 항목:
핵심 결정:
다음 한 가지 행동:
다시 불러오지 않을 것: 전체 log, repository 전체, 무관한 과거 대화완벽한 문서일 필요는 없습니다. 새 세션이 수십만 token의 과거를 다시 읽지 않고 몇 문단만으로 작업을 이어받을 수 있으면 충분합니다.
진단 정보를 공유할 때는 claude --version, model ID, Base URL의 domain, proxy 이름, 정확한 error처럼 민감하지 않은 값만 남기세요. API Key, 인증 header, 업무 prompt 전문, credential이 포함된 환경 변수는 출력하지 마세요.
비슷한 길이 오류라도 제한 종류는 다르다
먼저 원본 error 문구를 구분해야 합니다. 제한이 다르면 해결 방법도 달라집니다.
| 오류 형태 | 의미할 수 있는 것 | 첫 조치 |
|---|---|---|
Input length X exceeds the maximum length Y | 어느 계층이 input 또는 request 길이를 제한함. 단위가 token이라고 보장할 수 없음 | history와 tool output을 줄이고 거부 계층을 찾기 |
input length and max_tokens exceed context limit: A + B > C | 입력과 예약된 출력의 합이 context budget을 넘음 | 더 일찍 compact하고, 원인이 확인된 경우에만 출력 예산 조정 |
HTTP 413, request body too large | HTTP body 또는 reverse proxy의 byte 제한 | upload, encoding, proxy body-size 확인 |
All target providers failed 같은 일반 오류 | gateway가 upstream의 실제 원인을 숨겼을 수 있음 | raw attempt, gateway log, request ID 확인 |
Claude Code #42에는 input과 max_tokens 합계가 window를 넘었다는 사용자 보고가 있습니다. #8136에는 상한에 가까워졌을 때 compact 요청도 출력 공간이 필요해 /compact 자체가 실패할 수 있다는 보고가 있습니다. 두 사례 모두 독립적인 사용자 경험일 뿐, 현재 환경의 원인을 증명하지는 않습니다.
따라서 차이가 43이라고 해서 보이는 텍스트 43글자를 정확히 삭제하는 방식은 안전하지 않습니다. Claude Code는 system instruction, 대화 history, tool definition, 파일 내용, tool result도 함께 전송합니다. 경계 바로 아래를 맞추려 하지 말고 충분한 여유를 만드세요.
분기 A: /compact가 아직 실행되는 경우
slash command가 동작한다면 사용량을 확인하고, compact가 반드시 보존할 내용을 명시하세요.
/context그다음 범위를 좁힌 compact를 실행합니다.
/compact 현재 목표, 수정한 파일, 검증한 결과, 핵심 결정, 미해결 문제, 다음 행동을 유지한다. 전체 log, 반복된 파일 내용, 폐기한 분기, 무관한 대화는 제거한다.compact가 성공하더라도 곧바로 repository 전체를 다시 탐색하지 마세요. 작고 결과를 확인할 수 있는 요청으로 복구 상태를 점검합니다.
RECOVERY.md와 src/auth/session.ts만 읽는다. 다음에 수정할 함수를 설명한다. 다른 directory는 탐색하지 않고 파일도 변경하지 않는다.다음 네 조건을 함께 만족하면 복구가 제대로 된 것으로 볼 수 있습니다.
/context의 사용량이 눈에 띄게 줄었다.- 작은 request가 더 이상 400을 반환하지 않는다.
- 모델이 목표, 수정 파일, 다음 행동을 정확히 설명한다.
git diff와 test 결과가 복구 메모와 일치한다.
compact 과정에서 일부 세부 사항이 빠질 수 있습니다. 오래 유지해야 하는 project rule은 root의 CLAUDE.md에 두고, 중요한 작업 상태는 긴 대화가 아니라 파일에도 기록하세요.
분기 B: /compact도 Conversation too long 또는 같은 400을 반환하는 경우
같은 과대 history에 /compact를 반복하지 마세요. Claude Code #26317에는 일반 요청이 한계에 도달한 뒤 compact도 Conversation too long을 반환했다는 사용자 보고가 있습니다. issue가 not planned로 닫혔다고 해서 모든 버전과 호환 endpoint에서 문제가 사라졌다는 뜻은 아닙니다.
큰 log나 tool output이 들어오기 전으로 되돌리기
공식 checkpointing 문서에 따르면 /rewind를 실행하거나 입력창이 빈 상태에서 Esc를 두 번 눌러 checkpoint를 선택할 수 있습니다. 대표 옵션은 다음과 같습니다.
- Restore conversation: 대화는 이전으로 되돌리되 현재 code는 유지합니다.
- Summarize from here: 선택한 시점 이후의 message를 요약합니다.
- Summarize up to here: 선택한 시점 이전 history를 압축하고 이후 message를 유지합니다.
전체 log를 붙여 넣기 전, 큰 파일을 읽기 전, 비정상적으로 큰 tool result가 들어오기 전의 checkpoint를 고르세요. code를 유지한 채 대화만 되돌리고 더 작은 task를 보내는 것이 이미 overflow한 끝부분을 계속 요약하는 것보다 안전할 수 있습니다.
요약 기능도 model call을 필요로 할 수 있습니다. upstream이 이 호출까지 거부한다면 빈 context 복구로 넘어갑니다.
rewind로도 해결되지 않으면 /clear 또는 새 세션 사용하기
/clear공식 command reference에 따르면 /clear는 빈 context로 새 대화를 시작하고, 이전 session은 나중에 사용할 수 있도록 보존합니다. 디스크 파일이나 Git diff는 삭제하지 않습니다.
깨끗한 session의 첫 지시는 작고 검증 가능하게 만드세요.
RECOVERY.md, git diff --stat, 거기에 적힌 두 파일만 읽는다. 먼저 현재 상태를 확인한다. repository 전체는 탐색하지 않는다. 다음 단계 하나만 제안하고 승인 전에는 수정하지 않는다.즉시 claude --continue, claude --resume, /resume를 실행하지 마세요. 공식 session 문서는 resume이 전체 history와 tool result를 복원한다고 설명합니다. 바로 그 history가 한계를 넘겼다면 다음 model request도 다시 실패할 수 있습니다.
비용이 낮은 네 가지 테스트로 거부 계층 찾기
작업을 보존한 뒤에는 테스트마다 변수 하나만 바꾸고, 같은 작은 read-only task를 control로 사용하세요.
| 테스트 | 결과 | 가장 유용한 해석 |
|---|---|---|
| 같은 endpoint와 model, 빈 session, 작은 task | 성공 | 이전 session의 누적 history 또는 큰 tool output이 원인일 가능성이 높음 |
| 빈 session에서도 같은 작은 task 실패 | 실패 | model mapping, request envelope, client version, server-side cap 점검 |
| 허용되는 경우 공식 endpoint와 gateway 비교 | 직접 호출 성공, gateway 실패 | gateway 제한, 변환, error aggregation 점검 |
/compact는 실패하지만 /clear 후 작은 task 성공 | 성공 | compact request가 실제 window를 넘었거나 client가 window를 잘못 인식했을 가능성 |
secret을 노출하지 않고 routing 값을 기록합니다.
printf 'BASE_URL=%s\nMODEL=%s\nOPUS=%s\nSONNET=%s\nHAIKU=%s\nSUBAGENT=%s\n' \
"${ANTHROPIC_BASE_URL:-<unset>}" \
"${ANTHROPIC_MODEL:-<unset>}" \
"${ANTHROPIC_DEFAULT_OPUS_MODEL:-<unset>}" \
"${ANTHROPIC_DEFAULT_SONNET_MODEL:-<unset>}" \
"${ANTHROPIC_DEFAULT_HAIKU_MODEL:-<unset>}" \
"${CLAUDE_CODE_SUBAGENT_MODEL:-<unset>}"이 command는 의도적으로 ANTHROPIC_AUTH_TOKEN을 출력하지 않습니다. Claude Code Router, switcher, 사내 gateway, reverse proxy, multi-provider fallback을 거치는지도 함께 기록하세요.
Claude Code Router #1799에는 gateway가 upstream의 context error를 All target providers failed로 바꿔 버렸다는 사용자 보고가 있습니다. 보고자가 제안한 local patch를 보편적인 production fix로 볼 수는 없습니다. 다만 support log가 upstream status, body, request ID를 보존해야 하는 이유는 보여 줍니다.
[1m] 표시가 아니라 실제 DeepSeek route 확인하기
2026년 9월 30일 기준, DeepSeek 공식 Claude Code 통합 페이지의 클라이언트 환경 변수 예시는 다음 값을 설정합니다.
ANTHROPIC_MODEL,ANTHROPIC_DEFAULT_OPUS_MODEL,ANTHROPIC_DEFAULT_SONNET_MODEL:deepseek-flash[1m]ANTHROPIC_DEFAULT_HAIKU_MODEL,CLAUDE_CODE_SUBAGENT_MODEL:deepseek-flashCLAUDE_CODE_AUTO_COMPACT_WINDOW=786432
같은 페이지는 별도 항목에서 Claude 형식 model name의 서비스 측 mapping도 설명합니다. claude-opus로 시작하는 이름은 deepseek-v4-pro로, claude-haiku 또는 claude-sonnet으로 시작하는 이름은 deepseek-flash로 map됩니다. 이 서비스 측 규칙과 위 클라이언트 예시의 명시적 값은 서로 다른 사실이므로, 실제 route에 대한 하나의 결론으로 합치면 안 됩니다.
두 설명 모두 이번 customer request를 최종 처리한 model이나 context window를 증명하지 않습니다. 사용 가능한 request/usage 기록, 원래 model field, 선택된 provider/route, upstream request ID를 확인하고 UI나 예전 tutorial만으로 추정하지 마세요.
[1m] label도 경로의 모든 계층이 100만 token을 받는다는 보장은 아닙니다. client, compatibility API, gateway, fallback provider, 최종 model이 각각 별도 제한을 둘 수 있고, 예약된 output도 context를 사용합니다.
window를 부풀리지 말고 더 일찍 compact하기
현재 DeepSeek 예시는 다음 값을 사용합니다.
export CLAUDE_CODE_AUTO_COMPACT_WINDOW="786432"이 값은 client가 compact를 시작하는 임계값이지 provider의 hard limit을 늘리는 설정이 아닙니다. Claude Code 공식 environment variable reference는 값이 plain integer여야 하고, model context window 이하로 제한되며, /autocompact, launch flag, settings보다 우선한다고 설명합니다.
실제 model이나 gateway의 허용량이 더 작다면 확인된 더 낮은 값을 사용하세요. CLAUDE_AUTOCOMPACT_PCT_OVERRIDE는 compact를 더 일찍 시작하게 할 수 있지만 window를 키우지는 못합니다.
CLAUDE_CODE_MAX_CONTEXT_TOKENS도 “context를 해제하는 스위치”가 아닙니다. custom route나 인식되지 않은 model의 실제 확인된 window를 Claude Code에 알려 주는 값입니다. server cap보다 크게 설정하면 compact가 늦어지고 upstream 400 가능성이 커집니다.
평소에는 다음 습관이 더 효과적입니다.
- 큰 log는
grep,rg,tail또는 script로 줄여 전달합니다. - 큰 파일은 함수 또는 line range 단위로 읽습니다.
- 서로 관련 없는 task 사이에는
/clear를 사용합니다. - 넓은 조사는 subagent에게 맡기고 main session에는 요약만 가져옵니다.
- 새 phase에 들어가기 전에 목적을 지정한
/compact를 실행합니다. - 같은 schema, 전체 build log, 완전한 diff를 반복해서 넣지 않습니다.
작은 실제 작업으로 복구 확인하기
복구하거나 설정을 바꾼 뒤에는 다음 순서로 재검증합니다.
- 빈 session을 시작합니다.
RECOVERY.md와 작은 파일 하나만 읽습니다.- 짧고 범위가 정해진 답변을 요청합니다.
- 400이 사라졌는지 확인합니다.
- 파일과 tool call을 조금씩 추가합니다.
작은 request도 실패한다면 이전 대화를 더 줄이는 일을 멈추고 endpoint, model mapping, proxy behavior, request format을 조사하세요. 긴 session에서만 실패한다면 compact 시점, tool output 크기, task 사이의 session 경계를 점검하면 됩니다.
자주 묻는 질문
Claude Code를 다시 시작했는데 왜 해결되지 않나요?
재시작이 빈 history를 뜻하지는 않습니다. --continue, --resume, session picker는 이전 대화를 복원합니다. 원인을 분리하려면 정말 새로운 session과 작은 control request가 필요합니다.
output token을 줄이면 해결되나요?
error가 input과 max_tokens의 합이 context budget을 넘었다고 명시할 때만 유효합니다. input 자체에 별도 제한이 있다면 output을 줄여도 해결을 보장할 수 없습니다.
gateway를 바꾸면 항상 해결되나요?
아닙니다. 현재 gateway가 더 작은 body limit을 적용하거나 upstream error를 숨기는 경우에는 도움이 될 수 있습니다. 어떤 gateway도 최종 model의 hard context limit을 넘을 수는 없습니다.
/clear가 code를 삭제하나요?
아닙니다. 대화 context만 지우고 디스크에 작성된 파일은 그대로 둡니다. 그래도 실행 전 git status를 확인하고 patch, commit, editor snapshot을 저장하세요.
왜 정확히 43글자만 지우면 안 되나요?
단위가 불명확하고 request에는 system content, tools, history처럼 보이지 않는 내용도 들어가기 때문입니다. 경계에 맞추는 것보다 충분한 여유를 확보하는 편이 안전합니다.
기억할 복구 순서
Input length exceeds maximum이 나오면 다른 terminal에서 diff와 수동 handoff 저장 → /context → 범위를 지정한 /compact → 실패하면 큰 output 이전으로 /rewind → 그래도 실패하면 /clear 또는 새 session → 작은 control task로 제한 계층 확인 → 확인된 server window 아래에서 auto compact 설정 순으로 진행하세요.
이 절차는 숫자 43의 단위를 추측하지 않으며, proxy가 model의 hard limit을 우회할 수 있다고 주장하지도 않습니다. 먼저 이미 끝낸 작업을 지키고, 그다음 모호한 400을 계층별로 재현 가능한 진단으로 바꿉니다.
