결론부터: Claude 공식 문서에 따르면 퍼스트파티 Claude API의 Messages와 Token Counting 요청 한도가 32 MB에서 128 MB로 올랐습니다. Batch는 256 MB, Files API는 500 MB입니다. 다만 이는 Anthropic 자체 API 기준이고, Amazon Bedrock은 20 MB, Google 관리형 Claude(Vertex)는 30 MB, Claude Platform on AWS·Anthropic 관리형 Google Cloud·Microsoft Foundry는 32 MB입니다. 서드파티 게이트웨이도 자체 한도가 있습니다.
저희 Key로 10 MB부터 130 MB까지 Messages 요청을 테스트했습니다:
- 약 50 MB까지는 모두 200, 소요 시간 5~9초;
- 약 54 MB부터는 413이 돌아왔고, 큰 요청은 1초 안팎에 거절됐습니다.
413이 뜨면 모델을 바꾸기 전에 요청 크기를 재고, 이미지를 줄이고, PDF를 나누고, 오래된 스크린샷을 지우세요. 컨텍스트 윈도는 커지지 않았습니다. 128 MB에 들어간다고 token에 들어가는 것은 아닙니다.
API Key 만들기, Claude Code에서 Claude 바로 쓰기 →
413 request_too_large 알아보기
공식 API는 한도를 넘으면 HTTP 413, 오류 유형 request_too_large를 돌려줍니다:
{
"type": "error",
"error": {
"type": "request_too_large",
"message": "Request exceeds the maximum allowed number of bytes."
}
}
공식 오류 문서에 따르면 퍼스트파티 Claude API에서는 요청이 API 서버에 닿기 전에 Cloudflare가 이 오류를 반환합니다. 즉:
- 요청은 모델에 닿지 않았고 출력도 token 사용도 없습니다;
- 같은 요청을 다시 보내도 소용없습니다. 본문을 줄여야 합니다;
- 400
invalid_request_error(형식), 429(속도 제한), 529(과부하)와는 다른 문제입니다.
서드파티 게이트웨이를 거치면 413 본문이 달라집니다. 이번 테스트에서는 두 가지를 봤습니다. 게이트웨이 자체의 중국어 메시지(「요청이 너무 큽니다. 내용을 줄이고 다시 시도하세요」)와, 상위 서버가 413을 반환했다는 뜻의 bad response status code 413입니다. 둘 다 「요청이 너무 큼」으로 처리하세요. 다른 오류는 Claude Haiku 5.5 API 오류 해결을 참고하세요.
먼저 요청 크기를 재 봅니다:
import json
body = json.dumps(payload).encode()
print(f"{len(body) / 1024 / 1024:.1f} MB")
플랫폼별 한도
| 접속 경로 | 요청당 최대 크기 |
|---|---|
| Claude API: Messages, Token Counting | 128 MB |
| Claude API: Message Batches | 256 MB |
| Claude API: Files API 업로드 | 500 MB |
| Claude API: Sessions, Agents, Environments | 32 MB |
| Claude Platform on AWS | 32 MB |
| Claude on Google Cloud(Anthropic 관리형) | 32 MB |
| Microsoft Foundry | 32 MB |
| Claude on Google Cloud(Google 관리형, Vertex) | 30 MB |
| Amazon Bedrock | 20 MB |
| 저희 게이트웨이(이번 실측) | 약 50 MB까지 통과, 약 54 MB부터 413 |
수치는 공식 API 개요 기준이며, 각 클라우드 값은 해당 문서가 우선이라고 안내합니다. AlphaSignal에 따르면 이번 상향은 이미지가 많은 요청을 겨냥했습니다.
크기와 함께 적용되는 제한도 있습니다(Vision 문서, PDF 문서 기준):
- 이미지 한 장은 최대 8000×8000 px. 한 요청에 이미지가 20장을 넘으면 각 이미지의 긴 변은 3000 px 이하(AlphaSignal에 따르면 이전은 2000 px), 넘으면 many-image requests를 언급하는
invalid_request_error; - 요청당 이미지 최대 600장, 200K 컨텍스트 모델은 100장;
- PDF는 요청당 최대 600페이지, 컨텍스트 윈도가 1M token 미만이면 100페이지;
- base64는 크기를 약 3분의 1 늘립니다. 3 MB PNG는 약 4 MB가 됩니다.
해결 1: 이미지 압축과 다운샘플링
모델은 원본 해상도 그대로 보지 않습니다. 문서에 따르면 Claude 4.7 이후 모델은 긴 변 2576 px로, 그 외 모델은 1568 px로 줄입니다. 4K 스크린샷은 바이트만 늘릴 뿐입니다. 보내기 전에 줄이세요:
from PIL import Image
import base64, io
def shrink(path, max_side=1568, quality=80):
im = Image.open(path).convert("RGB")
im.thumbnail((max_side, max_side))
buf = io.BytesIO()
im.save(buf, "JPEG", quality=quality, optimize=True)
return base64.b64encode(buf.getvalue()).decode()
요령:
- 스크린샷은 JPEG(품질 75~85)로. PNG보다 훨씬 작습니다;
- 긴 변 1568 px, 작은 글씨를 읽혀야 할 때만 2576 px;
- 20장을 넘으면 반드시 3000 px 미만;
- 같은 이미지는 대화에서 한 번만 보내고 이후엔 텍스트로 가리킵니다.
해결 2: 큰 PDF는 Files API file_id로
공식 API에서는 큰 파일을 Files API(파일당 500 MB)에 올린 뒤 Messages에서 file_id를 참조합니다. 본문에는 ID만 남습니다:
curl https://api.anthropic.com/v1/files \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: files-api-2025-04-14" \
-F "file=@report.pdf"
# -> {"id": "file_011C...", ...}
{"type": "document", "source": {"type": "file", "file_id": "file_011C..."}}
문서에 따르면 멀티턴 대화와 에이전트는 매 턴 전체 기록을 다시 보내므로 base64 이미지도 매번 다시 전송됩니다. file_id를 쓰면 이미지가 쌓여도 본문이 작게 유지됩니다.
쓰는 게이트웨이가 Files API를 지원하지 않으면(이번 테스트에서 저희 게이트웨이에 업로드를 호출하자 400이 돌아왔습니다) PDF를 100페이지 이하, 한도 이하로 나눠 보내세요:
qpdf report.pdf --pages . 1-100 -- part1.pdf
qpdf report.pdf --pages . 101-200 -- part2.pdf
PDF의 각 페이지는 이미지로 처리되므로 스캔 PDF는 내장 이미지 해상도를 낮추면 크게 줄어듭니다.
해결 3: 긴 computer use·Claude Code 세션은 오래된 스크린샷 정리
computer use와 스크린샷이 많은 에이전트가 413에 가장 잘 걸립니다. 단계마다 tool_result에 스크린샷이 들어가고 매 턴 전체 기록이 다시 가므로 수십 단계면 본문이 100 MB를 넘습니다. 문서에 따르면 tool_result 안의 스크린샷도 20장 기준에 포함됩니다.
방법:
- 최근 몇 장만 남기고 오래된 것은 한 줄 텍스트(「12단계: 설정 화면 열림」)로 바꾸기;
- 직접 만든 에이전트 루프라면 N단계마다 기록을 요약해 이어 가기;
- Claude Code에서는
/compact를 실행하거나 긴 작업은 새 세션으로. 자동 압축 시점은 Claude Code 유휴 자동 압축을 참고하세요.
Claude Code를 서드파티 엔드포인트에 연결할 때 전역 설정은 ~/.claude/settings.json에 씁니다:
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.aicodewith.ai",
"ANTHROPIC_AUTH_TOKEN": "내 API Key"
},
"model": "claude-sonnet-5-5"
}
주소는 https://api.aicodewith.ai이며 /v1을 붙이지 않습니다. 전체 절차는 Claude Code 서드파티 API 설정, 10월 21일 API 버전과 SDK 변경은 Claude API 2026-10-21 마이그레이션을 보세요.
실측: 저희 게이트웨이는 얼마까지 받나
방법: claude-sonnet-5-5, max_tokens 16. Messages 요청 하나에 base64 이미지를 여러 장 넣고(token을 줄이려고 16×16 px 이미지에 채움 바이트 추가) 10 MB부터 130 MB까지 키워 https://api.aicodewith.ai/v1/messages로 POST했습니다.
| 본문 크기 | 상태 코드 | 소요 시간 |
|---|---|---|
| 4.8 MB | 200 | 약 14초 |
| 10.1 MB | 200 | 약 5초 |
| 40.3 MB | 200 | 약 6초 |
| 50.3 MB | 200 | 약 9초 |
| 52.0 MB | 200 | 약 9초 |
| 53.7 MB | 413 | 약 6초 |
| 60.4 MB | 413 | 약 10초 |
| 75.5 MB | 413 | 약 1초 |
| 98.8 MB | 413 | 약 4초 |
| 129.6 MB | 413 | 약 1초 |
결과: 이번 테스트에서 저희 게이트웨이를 거친 Messages 요청은 약 52 MB까지 200, 약 54 MB부터 413으로, 공식 128 MB에는 못 미쳤습니다. 이미지 몇 장이 든 일상 대화, 스크린샷 몇 장, 수십 페이지 PDF는 이 한도와 거리가 멉니다. 수십 MB를 보내야 한다면 위 세 가지 방법으로 줄이는 편이 안정적입니다. 일부 요청은 업로드 중 연결이 끊겼다가 재전송하자 정상 처리됐습니다. 테스트 후 스크립트와 요청 파일은 삭제했습니다.
API Key 만들기, Claude를 Claude Code에 연결하기 →
자주 묻는 질문
128 MB가 됐으니 더 많은 내용을 보낼 수 있나요?
늘어난 건 바이트 한도이고 컨텍스트 윈도는 그대로입니다. 큰 이미지도 처리 해상도로 줄이면 token 수가 고정이라 남는 바이트는 대역폭 낭비입니다. 텍스트는 보통 128 MB보다 훨씬 먼저 컨텍스트 윈도에 걸립니다.
413과 400 「prompt is too long」은 뭐가 다른가요?
413은 바이트가 너무 많아 모델 앞에서 막힌 것이고, prompt is too long은 token이 컨텍스트 윈도를 넘은 것으로 요청은 API에 도달했습니다. 앞은 바이트를 줄이고, 뒤는 내용을 덜어내거나 기록을 압축합니다.
Bedrock에서는 왜 아직 413이 뜨나요?
Bedrock 한도는 20 MB, Google 관리형 Vertex는 30 MB이고 128 MB는 퍼스트파티 Claude API에만 해당합니다. 각 플랫폼 한도에 맞춰 압축하세요.
Batch로 더 큰 요청을 보낼 수 있나요?
배치 전체는 256 MB까지지만 각 항목은 여전히 Messages 요청입니다. 대량 오프라인 작업용이지 요청당 크기를 우회하는 수단이 아닙니다.
다시 보내면 413이 해결되나요?
아니요. 같은 본문은 매번 거절됩니다. 먼저 줄이세요.
