Opus 4.7 Migration, was sich für API-Builder geändert hat

Opus 4.7 ist am 16. April 2026 GA gegangen. Auf den ersten Blick sieht es aus wie ein Routine-Refinement-Release, das Pricing ist unverändert (5 Dollar Input, 25 Dollar Output pro Million Tokens, 1 Million Context bleibt), und das Modell heisst weiter claude-opus-4-7. Sobald Du aber den ersten 400 Error in Deinem Production-Code siehst, weisst Du dass die Migration nicht ganz trivial ist.

Dieser Playbook ist für Dich wenn Du eine Codebase hast die Anthropic-API-Calls mit Opus 4.6 oder früher macht, und sicherstellen willst dass nichts bricht wenn das Modell auf 4.7 hochgezogen wird. Plus einer kurzen Bewertung ob der neue xhigh-Effort-Level für Deinen Use-Case Sinn macht.

Drei Breaking API-Changes, harte 400 Errors

Anthropic hat drei Parameter aus dem messages.create() Endpoint herausgenommen die in 4.6 noch akzeptiert wurden. Wenn Du sie an Opus 4.7 schickst, kommt ein 400 Bad Request zurück.

Erstens, thinking.budget_tokens ist weg. In 4.6 konntest Du dem Modell ein hartes Token-Budget für die Reasoning-Phase geben (thinking: { type: "enabled", budget_tokens: 5000 }). In 4.7 ist das Konzept ersetzt durch Adaptive Reasoning, das Modell entscheidet selbst wieviel es nachdenkt. Migrations-Pflicht, das budget_tokens-Feld komplett aus dem Request rausnehmen. Wenn Du Cost-Control brauchst (siehe unten), nutze Task Budgets in der Public Beta.

Zweitens, temperature und top_p sind weg. Beide waren in 4.6 deprecated mit Warnung, in 4.7 sind sie hart entfernt. Wenn Du temperature: 0.7 mitschickst, 400 Error. Migrations-Pflicht, beide Parameter ersatzlos rausnehmen. Anthropic hat das Modell so trainiert dass es die "richtige" Sampling-Strategie selbst kalibriert. Praktisch heisst das, Du gibst der API nur noch die Konversation und das Tool-Schema, kein Sampling-Tuning mehr.

Drittens, top_k ist weg. Gleiche Logik wie temperature und top_p.

In Summe, die Sampling-Konfiguration ist bei Opus 4.7 nicht mehr Bestandteil des API-Contracts. Das ist ein bewusstes Design-Statement von Anthropic, sie wollen weniger Knobs auf der Builder-Seite.

Reasoning-Traces sind hidden by default

Ein zweiter Punkt der bei der Migration auffällt, in 4.6 hast Du bei thinking.type: "enabled" per Default die vollen Reasoning-Tokens als Antwort-Stream zurückbekommen. In 4.7 ist das auf "summarized" als Default geändert. Heisst Du bekommst eine kurze Zusammenfassung was das Modell gedacht hat, nicht die Roh-Trace.

Wenn Du die Roh-Trace willst (Debugging, Eval-Infrastruktur, oder weil Du den Reasoning-Stil monitoren willst), explizit thinking.display: "raw" setzen. Das ist nicht teurer, nur explizit verlangt.

Tokenizer-Update, 1.0 bis 1.35x mehr Tokens

Opus 4.7 nutzt einen neuen Tokenizer. Anthropic gibt offiziell an dass derselbe Text-Input je nach Sprache und Content-Type 1.0 bis 1.35 Mal so viele Tokens produziert wie in 4.6.

Praktisch heisst das, Code mit etwa 1.10x leicht teurer, Englisch-only Text mit 1.0 bis 1.05x praktisch gleich, multilinguale oder nicht-westliche Inputs mit bis zu 1.35x deutlich teurer. Wenn Deine API-Bills in Deutsch oder Spanisch laufen, plan mit ungefähr 15 bis 20 Prozent mehr Token-Cost ein. Wenn Du für japanisch- oder koreanisch-sprachige User baust, kann es bis 35 Prozent mehr sein.

CloudZero und der unabhängige Karoz-Substack haben das mit Test-Corpora bestätigt. Anthropic-Statement ist im Help-Center-Release-Notes-Dokument für Opus 4.7 zu finden.

Extended Thinking ist komplett raus

In 4.6 hattest Du den Schalter thinking.type: "enabled" | "disabled" plus den separaten Modus "Extended Thinking" für längere agentic Reasoning-Phasen. In 4.7 ist Extended Thinking kein eigener Modus mehr. Adaptive Reasoning ist der einzige Modus, das Modell entscheidet pro Turn ob und wieviel es denkt.

Migrations-Hinweis, falls Du in Deiner Codebase explizit Extended Thinking aktiviert hast (z.B. via beta-header extended-thinking-2026-01-15), den Header rausnehmen. Es passiert nichts dramatisches wenn Du ihn drin lässt, aber er hat keine Wirkung mehr.

Neuer Effort-Level "xhigh" plus Claude-Code-Default-Wechsel

Anthropic hat zwischen high und max einen neuen Effort-Level eingeführt, xhigh. Das ist relevant wenn Du Claude API direkt nutzt und den effort_level Parameter setzt, oder wenn Du Claude Code (CLI) nutzt.

Wichtig, Claude Code defaultet seit 2.1.110 auf xhigh für alle Plans (Pro, Max, Team, Enterprise). Das ist eine bewusste Entscheidung von Anthropic, die Begründung steht im NxCode-Developer-Guide für Opus 4.7 und im Apiyi-Beitrag zum xhigh-Mode. Praktisch heisst das, wenn Du Claude Code nutzt, denkst Du jetzt häufiger und länger pro Turn als vor dem Update. Output-Qualität wird dadurch deutlich besser, aber Token-Verbrauch steigt.

Wenn Du Cost-Control im Claude Code brauchst, kannst Du den Effort-Level pro Session auf high runterstellen mit dem /effort high Command oder per Setting. Tradeoff, weniger Reasoning, schnellere und billigere Antworten, aber bei agentic Workflows weniger sauberes Tool-Use-Verhalten.

Task Budgets als Public Beta

Anthropic hat parallel zu 4.7 das Konzept "Task Budgets" als Public Beta released. Das ist der Replacement für thinking.budget_tokens, aber auf einer höheren Ebene, nämlich der ganzen agentic Loop (Reasoning plus Tool-Calls plus Output).

Aktivierung über Beta-Header task-budgets-2026-03-13. Du gibst der API ein Token-Limit für die ganze Task, und das Modell respektiert es. Wenn das Limit erreicht ist, das Modell stoppt sauber statt durchzuarbeiten. Das ist gerade für Claude Code und agentic Frameworks der relevante Hebel gegen Cost-Explosion.

Implementations-Hinweis, das Beta-Header geht in den extra_headers-Slot des SDK. Plus max_tokens_for_task als Body-Parameter. Genauen Spec checkst Du im Verdent-Guide oder im Anthropic Help Center.

Migrations-Checkliste, sieben Punkte

Wenn Du heute migrieren willst, geh durch diese sieben Punkte.

Eins, suche in Deiner Codebase nach temperature:, top_p:, top_k: und thinking.budget_tokens. Alle Vorkommen entfernen. Schnellstes Pattern, grep -rn "temperature\|top_p\|top_k\|budget_tokens" src/ und manuelle Cleanup.

Zwei, falls Du Cost-Control über budget_tokens hattest, plan stattdessen Task Budgets ein. Beta-Header und body-Parameter.

Drei, falls Du in Deiner Codebase Reasoning-Tokens parsest (z.B. für eigene Eval-Pipelines), thinking.display: "raw" explizit setzen.

Vier, plan Token-Cost-Erhöhung von ungefähr 15 bis 20 Prozent für deutschsprachige Workloads ein. Updated Cost-Schätzungen ggf. in Deine Pricing-Pages oder internen Dashboards einarbeiten.

Fünf, Extended-Thinking Beta-Header (falls genutzt) entfernen. Kein Funktions-Einfluss, aber weniger toter Code.

Sechs, falls Du Claude Code nutzt und kein implizites Default-Update willst, Effort-Level explizit setzen statt sich auf den Default zu verlassen.

Sieben, lauf Deine bestehenden Eval-Tests einmal gegen 4.7 und vergleich mit 4.6. Anthropic gibt einen Score-Sprung von 53 auf 57 (Artificial Analysis Intelligence Index) an, das sollte sich in Deinen Real-World-Tests widerspiegeln. Wenn nicht, hast Du einen Prompt der speziell auf 4.6-Verhalten optimiert war. Re-Tunen oder bewusst auf 4.6 bleiben (claude-opus-4-6 ist weiter verfügbar).

Sollst Du überhaupt migrieren

Anthropic hat 4.7 als Default für neue API-Calls eingestellt. 4.6 bleibt explizit ansprechbar als claude-opus-4-6, ist aber nicht mehr Default in der Doku oder in Claude Code. Praktische Empfehlung, wenn Deine Codebase aktiv weiterentwickelt wird und Du frische Releases bekommst, migrier in den nächsten 4 bis 8 Wochen. Wenn Deine Codebase eingefroren ist und Du nur API-Bills bezahlst, kannst Du auf 4.6 bleiben bis Anthropic eine Sunset-Frist ankündigt.

Stand Mai 2026 hat Anthropic keine offizielle Sunset-Frist für 4.6 publiziert, aber das Pattern aus 4.5-Sunset war ungefähr 6 bis 9 Monate nach GA des Nachfolgers. Heisst, plan damit dass 4.6 bis spätestens Q4 2026 abgekündigt wird.

Was als nächstes

Wenn Du parallel Claude Code 2.1+ migrierst, "claude-code-update-strategie" Playbook erklärt das Update-Ritual und welche Releases stabil sind. Wenn Du Token-Cost-Control über Task Budgets ernst nehmen willst, "claude-code-cost-controls" hat den passenden Workflow. Für API-Cost-Monitoring auf Provider-Ebene, "claude-code-headless-in-ci-cd" zeigt wie Du Token-Verbrauch pro Run misst.

Hauptquellen falls Du tiefer einsteigen willst, Anthropic News-Post zu Opus 4.7 (anthropic.com/news/claude-opus-4-7), Help-Center Release-Notes (support.claude.com/en/articles/12138966-release-notes), Artificial Analysis Pre-Release-Review, und der NxCode-Developer-Guide für die migrations-relevanten API-Details.