Claude API 413 request_too_large: Das Limit liegt jetzt bei 128 MB – Bedrock- und Drittanbieter-Limits, große PDFs und Screenshots senden

Kurz gesagt: Laut Claude-Dokumentation nimmt die First-Party-Claude-API Messages- und Token-Counting-Anfragen jetzt bis 128 MB an (vorher 32 MB). Batch liegt bei 256 MB, die Files API bei 500 MB. Das gilt nur für Anthropics eigene API: Amazon Bedrock bleibt bei 20 MB, das von Google verwaltete Claude auf Vertex bei 30 MB, Claude Platform on AWS, das von Anthropic verwaltete Google Cloud und Microsoft Foundry bei 32 MB. Drittanbieter-Gateways setzen eigene Grenzen.

Wir haben Messages-Anfragen von 10 MB bis 130 MB mit unserem eigenen Key getestet:

• bis etwa 50 MB kam immer 200 zurück, in 5 bis 9 Sekunden;
• ab etwa 54 MB kam 413, die größten Anfragen wurden nach etwa 1 Sekunde abgelehnt.

Bei 413 also nicht das Modell wechseln: Anfragegröße messen, dann Bilder verkleinern, PDFs teilen und alte Screenshots entfernen. Das Kontextfenster ist nicht gewachsen: In 128 MB passen heißt nicht, in die Tokens passen.

API Key erstellen und Claude in Claude Code nutzen →

413 request_too_large erkennen

Die offizielle API liefert HTTP 413 mit dem Fehlertyp request_too_large:

{
  "type": "error",
  "error": {
    "type": "request_too_large",
    "message": "Request exceeds the maximum allowed number of bytes."
  }
}

Laut offizieller Fehlerseite gibt auf der First-Party-Claude-API Cloudflare diesen Fehler zurück, bevor die Anfrage die API-Server erreicht. Das heißt:

• die Anfrage hat das Modell nie erreicht, keine Ausgabe, keine Tokens verbraucht;
• dieselbe Anfrage erneut senden hilft nicht, der Body muss kleiner werden;
• es ist ein anderes Problem als 400 invalid_request_error (Format), 429 (Rate Limit) und 529 (Überlastung).

Über ein Drittanbieter-Gateway sieht die 413-Antwort anders aus. Wir haben zwei Formen gesehen: die eigene Meldung des Gateways (auf Chinesisch: „Anfrage zu groß, bitte Inhalt reduzieren und erneut versuchen“) und bad response status code 413, also eine 413 vom Upstream. Beide bedeuten „Anfrage zu groß“. Andere Fehler: Claude Haiku 5.5 API-Fehler beheben.

Erst die eigene Anfrage messen:

import json
body = json.dumps(payload).encode()
print(f"{len(body) / 1024 / 1024:.1f} MB")

Limits je Plattform

Zahlen laut offizieller API-Übersicht; maßgeblich ist laut Doku jeweils die Dokumentation der Cloud-Plattform. Laut AlphaSignal zielt die Erhöhung auf bildlastige Anfragen.

Weitere Grenzen gelten zusätzlich (laut Vision-Doku und PDF-Doku):

• jedes Bild höchstens 8000×8000 px; bei mehr als 20 Bildern pro Anfrage darf die lange Seite jedes Bildes höchstens 3000 px sein (vorher 2000 px, laut AlphaSignal), sonst invalid_request_error mit Hinweis auf many-image requests;
• bis zu 600 Bilder pro Anfrage, 100 bei Modellen mit 200K-Kontext;
• PDFs bis 600 Seiten pro Anfrage, 100 bei einem Kontextfenster unter 1M Tokens;
• base64 macht die Daten etwa ein Drittel größer: aus einem 3-MB-PNG werden rund 4 MB.

Lösung 1: Bilder komprimieren und herunterskalieren

Das Modell nutzt nicht deine volle Auflösung. Laut Doku skalieren Claude 4.7 und neuere Modelle Bilder auf eine lange Seite von 2576 px, andere Modelle auf 1568 px. 4K-Screenshots vervielfachen nur die Bytes. Vor dem Senden verkleinern:

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()

Faustregeln:

• Screenshots als JPEG speichern (Qualität 75 bis 85), deutlich kleiner als PNG;
• lange Seite 1568 px, 2576 px nur für kleine Schrift;
• bei mehr als 20 Bildern immer unter 3000 px bleiben;
• ein Bild nur einmal pro Gespräch senden und danach im Text darauf verweisen.

Lösung 2: große PDFs per file_id der Files API

Auf der offiziellen API lädst du große Dateien in die Files API (500 MB pro Datei) und verweist in Messages auf die file_id. Der Body enthält dann nur noch eine 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..."}}

Laut Doku senden Mehrrunden-Gespräche und Agents in jeder Runde den ganzen Verlauf erneut, base64-Bilder also jedes Mal mit; mit file_id bleibt der Body klein.

Unterstützt dein Gateway die Files API nicht (der Upload-Aufruf an unser Gateway gab in diesem Test 400 zurück), teile das PDF in Teile mit höchstens 100 Seiten unter dem Anfragelimit:

qpdf report.pdf --pages . 1-100 -- part1.pdf
qpdf report.pdf --pages . 101-200 -- part2.pdf

Jede PDF-Seite wird als Bild verarbeitet; bei gescannten PDFs bringt eine niedrigere Auflösung der eingebetteten Bilder viel.

Lösung 3: In langen Computer-Use- und Claude-Code-Sitzungen alte Screenshots entfernen

Computer Use und Screenshot-lastige Agents laufen am häufigsten in 413: Jeder Schritt legt einen Screenshot in tool_result, jede Runde sendet den ganzen Verlauf, und nach ein paar Dutzend Schritten liegt der Body über 100 MB. Laut Doku zählen Screenshots in tool_result auch zur 20-Bilder-Schwelle.

So geht's:

• nur die letzten Screenshots behalten, ältere durch eine Textzeile ersetzen („Schritt 12: Einstellungen geöffnet“);
• in einer eigenen Agent-Schleife alle N Schritte den Verlauf zusammenfassen;
• in Claude Code /compact ausführen oder für lange Aufgaben eine neue Sitzung starten. Wann Claude Code automatisch komprimiert, steht in Claude Code Idle-Kompaktierung.

Um Claude Code an einen Drittanbieter-Endpunkt anzubinden, gehört die globale Konfiguration in ~/.claude/settings.json:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.aicodewith.ai",
    "ANTHROPIC_AUTH_TOKEN": "IHR_API_KEY"
  },
  "model": "claude-sonnet-5-5"
}

Die Adresse ist https://api.aicodewith.ai ohne /v1. Alle Schritte: Drittanbieter-API in Claude Code einrichten; zu API-Version und SDK vom 21. Oktober siehe Claude API 2026-10-21 Migration.

Test: Wie große Anfragen unser Gateway annimmt

Vorgehen: claude-sonnet-5-5, max_tokens 16, eine Messages-Anfrage mit mehreren base64-Bildern (16×16-px-Bilder mit Fülldaten, damit die Tokens niedrig bleiben), von 10 MB bis 130 MB, per POST an https://api.aicodewith.ai/v1/messages.

Ergebnis: In unserem Test lieferten Messages-Anfragen über unser Gateway bis etwa 52 MB 200 und ab etwa 54 MB 413, also unter den offiziellen 128 MB. Ein Chat mit ein paar Bildern, einigen Screenshots oder einem PDF mit ein paar Dutzend Seiten ist weit davon entfernt; wer Dutzende MB senden muss, fährt mit den drei Lösungen oben sicherer. Einige Anfragen verloren beim Upload die Verbindung und liefen beim erneuten Senden durch. Testskript und Anfragedateien haben wir danach gelöscht.

API Key erstellen und Claude mit Claude Code verbinden →

FAQ

Kann ich mit 128 MB mehr Inhalt senden?

Das Byte-Limit ist gewachsen, das Kontextfenster nicht. Ein großes Bild hat nach dem Skalieren auf die Arbeitsauflösung eine feste Tokenzahl, zusätzliche Bytes sind verschwendete Bandbreite. Text stößt meist lange vor 128 MB an das Kontextfenster.

Was unterscheidet 413 von 400 „prompt is too long“?

413 heißt zu viele Bytes, die Anfrage wird vor dem Modell gestoppt; prompt is too long heißt zu viele Tokens für das Kontextfenster, die Anfrage hat die API erreicht. Im ersten Fall Bytes reduzieren, im zweiten Inhalt kürzen oder den Verlauf komprimieren.

Warum bekomme ich auf Bedrock weiter 413?

Bedrock erlaubt 20 MB, das von Google verwaltete Vertex 30 MB; die 128 MB gelten nur für die First-Party-Claude-API. Auf das Limit der Plattform komprimieren.

Kann Batch größere Anfragen tragen?

Ein ganzer Batch darf 256 MB groß sein, jedes Element bleibt aber eine Messages-Anfrage. Batch ist für viele Offline-Aufgaben gedacht, nicht zum Umgehen der Größe pro Anfrage.

Hilft erneutes Senden bei 413?

Nein. Derselbe Body wird jedes Mal abgelehnt; erst verkleinern.