Claude API Migration was bei Trading-Tools 2026 bricht.

Wer Research- oder Trading-Tools auf der Claude API betreibt, muss bis Ende November handeln: Claude Sonnet 4.5 wird am 30.11.2026 abgeschaltet, und der Umstieg auf Sonnet 5.5 oder Opus 5.5 bricht typische Muster wie temperature=0, erzwungene Tool-Aufrufe und abgeschaltetes Thinking. Dazu kommt das Python-SDK 1.0, das Sampling-Parameter nicht mehr annimmt und Python 3.10 voraussetzt. Seit dem 07.10.2026 gibt es zudem Haiku 5.5 als Nachfolger von Haiku 4.5, ebenfalls mit Änderungen beim Thinking. Dieser Beitrag ist eine Checkliste für bestehende Pipelines: welche Code-Stellen Sie ändern müssen, warum die Kosten weniger stark sinken, als die Listenpreise vermuten lassen, und wie Sie mit einem festen Testkorpus prüfen, ob das neue Modell Ihre Ergebnisse verschlechtert, bevor es live geht.

Welche Claude-Modelle werden bis Ende 2026 abgeschaltet?

Für bestehende Pipelines zählen zwei Termine. Claude Sonnet 4.5 (claude-sonnet-4-5-20250929) ist seit dem 30.09.2026 abgekündigt und wird am 30.11.2026 auf der Claude API abgeschaltet; Anthropic empfiehlt Sonnet 5.5 als Ersatz. Danach schlagen Anfragen an dieses Modell fehl. Für Claude Haiku 4.5 nennt Anthropic als frühesten Termin „nicht vor dem 15.10.2026“. Stand 07.10.2026 steht Haiku 4.5 aber noch als aktiv in der Liste, und Anthropic kündigt Abschaltungen öffentlich verfügbarer Modelle mindestens 60 Tage vorher an. Eine Abschaltung direkt am 15.10. ist damit nicht zu erwarten, eine Abkündigung kann aber jederzeit kommen. Der Nachfolger Haiku 5.5 (claude-haiku-5-5) ist seit dem 07.10.2026 verfügbar.

Die Termine gelten für die von Anthropic betriebenen Plattformen (Claude API, Claude Platform on AWS, Microsoft Foundry). Amazon Bedrock und Google Cloud legen eigene Daten fest. Welche Modelle es gibt und wofür sie sich eignen, steht im Überblick Claude-Modelle 2026. Hier geht es nur darum, was im Code passiert, wenn Sie wechseln.

Wer nicht weiß, welche Skripte noch alte IDs nutzen: In der Claude Console liefert der Export auf der Usage-Seite eine CSV mit Verbrauch je API-Key und Modell. So fallen auch vergessene Cronjobs auf einem VPS auf, solange sie noch Anfragen senden.

Was bricht beim Wechsel auf Sonnet 5.5, Opus 5.5 und Haiku 5.5?

Der größte Bruch betrifft das Thinking, also die interne Überlegung des Modells vor der Antwort. Bei Sonnet 4.5 und Haiku 4.5 blieb Thinking aus, solange kein thinking-Feld gesetzt war. Bei Opus 5.5 ist adaptives Thinking immer an: thinking: {"type": "disabled"} und feste Budgets mit budget_tokens liefern einen 400-Fehler. Die Tiefe steuern Sie nur noch über effort (low bis max, Standard bei Opus 5.5 ist medium). Sonnet 5.5 denkt ohne Angabe ebenfalls. Abschalten heißt dort thinking: {"type": "between_tools"}, und das nur bei Effort low, medium oder high; bei xhigh und max gibt es wieder einen 400-Fehler.

Das hat drei praktische Folgen. Erstens gilt max_tokens für Thinking und Antwort zusammen; ein Limit von 512 Tokens, das für knappe JSON-Antworten gereicht hat, kann nun mitten in der Antwort abbrechen. Zweitens beginnen Antworten oft mit thinking-Blöcken. Code, der resp.content[0].text liest, bricht. Lesen Sie Blöcke immer über ihr type-Feld. Drittens müssen Thinking-Blöcke in Tool-Schleifen unverändert zurückgeschickt werden; wer den bisherigen Verlauf nachträglich ändert, riskiert je nach Konto einen 400-Fehler.

Der zweite Bruch ist Forced Tool Use, also der erzwungene Werkzeugaufruf. Viele Research-Tools erzwingen mit tool_choice vom Typ tool oder any einen Werkzeugaufruf, um verlässlich strukturierte Daten zu bekommen. Auf Opus 5.5 und Sonnet 5.5 (wie schon auf Fable 5.1) liefert genau das einen 400-Fehler. Erlaubt sind nur noch auto und none. Anthropic empfiehlt auto mit Strict Tool Use (strict: true an der Tool-Definition, die Tool-Eingaben folgen dann strikt dem Schema) oder Structured Outputs (Antwort in einem vorgegebenen JSON-Schema) über output_config.format. Auf Bedrock sind Structured Outputs für diese beiden Modelle nicht verfügbar; dort bleibt nur auto plus eigene Validierung.

Haiku 5.5 verhält sich anders: Thinking ist standardmäßig adaptiv an, feste Budgets mit budget_tokens liefern 400. Ein erzwungener Tool-Aufruf ist dort weiter erlaubt, die Antwort beginnt dann ohne Thinking direkt mit dem Tool-Aufruf.

Zwei weitere Punkte treffen alle Umsteiger von Sonnet 4.5 und Haiku 4.5, auch auf Haiku 5.5: Eine vorbefüllte letzte Assistant-Nachricht (Prefill, etwa ein öffnendes {) wird abgelehnt, und abweichende Sampling-Parameter ebenfalls. Ob ein Modell Thinking abschalten lässt, können Sie seit dem 05.10.2026 über die Models API prüfen (capabilities.thinking.types.disabled). Das eignet sich für einen automatischen Check in der CI.

Was ändert sich mit dem Anthropic Python-SDK 1.0?

Unabhängig vom Modell hat Anthropic am 20.08.2026 das Python-SDK in Version 1.0 veröffentlicht. Wer anthropic ohne Versionsgrenze installiert, bekommt die Änderungen beim nächsten Neuaufbau der Umgebung, auch wenn am Modell nichts geändert wurde. Die wichtigsten Brüche laut Migrationsleitfaden:

• Python 3.10 ist Mindestversion. Ältere Server oder Docker-Images mit 3.9 müssen zuerst aktualisiert werden.
• httpx2 statt httpx: Eigene Timeouts, Transports und Typannotationen kommen aus httpx2. Test-Bibliotheken wie respx, pytest-httpx oder vcrpy greifen nur, wenn Sie beim Start httpx2.alias_httpx() aufrufen. Sonst greifen die Mocks nicht mehr, und Tests können unbemerkt echte Anfragen auslösen.
• temperature, top_p und top_k sind aus messages.create(), stream(), parse() und Batch-Anfragen entfernt. Übergeben Sie sie trotzdem, gibt es einen TypeError. Für ältere Modelle geht es noch über extra_body.
• Structured Outputs: Rohe Schemas laufen über output_config={"format": …}; die Helfer wie parse() akzeptieren für output_format nur noch Typen (etwa Pydantic-Klassen).
• Entfernt: die alte Text Completions API (client.completions.create()), parse(stream=True) und das clientseitige compaction_control.
• Async: Bei with_raw_response müssen parse(), text() und read() nun mit await aufgerufen werden.
• Bedrock: AnthropicBedrock verlangt eine Region und fällt nicht mehr still auf us-east-1 zurück.

Typisches Beispiel: ein News-Extraktor, der Meldungen in ein festes Ereignisformat überführt. Vorher sah der Aufruf so aus:

# vorher: SDK 0.x, Sonnet 4.5
resp = client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=1024,
    temperature=0,
    tools=[NEWS_TOOL],
    tool_choice={"type": "tool", "name": "record_news_event"},
    messages=msgs,
)
event = resp.content[0].input

Nach der Umstellung entfallen temperature und das erzwungene Tool, das Format kommt aus dem Schema, die Antwort wird nach Typ gelesen:

# nachher: SDK 1.x, Sonnet 5.5
resp = client.messages.create(
    model=cfg.model_id,                      # "claude-sonnet-5-5"
    max_tokens=4096,                         # deckt Thinking + Antwort ab
    thinking={"type": "between_tools"},      # kein Vorab-Thinking
    output_config={
        "effort": "low",
        "format": {"type": "json_schema", "schema": NEWS_SCHEMA},
    },
    messages=msgs,
)
text = next(b.text for b in resp.content if b.type == "text")
event = NewsEvent.model_validate_json(text)  # eigene Prüfung bleibt Pflicht

Die Modell-ID steht dabei bewusst in der Konfiguration, nicht im Code. Ab der Generation 4.6 sind auch datumslose IDs wie claude-sonnet-5-5 feste Snapshots; das Modell dahinter ändert sich nicht still. Der Wechsel ist also immer eine bewusste Konfigurationsänderung, die Sie testen und zurückdrehen können.

Reproduzierbarkeit ohne temperature: was das für Research-Pipelines heißt.

Viele Trading-Research-Pipelines setzen temperature=0, um möglichst gleiche Antworten auf gleiche Eingaben zu bekommen. Ab Claude 4.7 lehnt die API abweichende Sampling-Werte mit 400 ab, das SDK 1.0 kennt die Parameter gar nicht mehr. Anthropic verweist stattdessen auf Prompting. Ganz deterministisch war ein Sprachmodell auch mit temperature=0 nie; jetzt fällt aber selbst dieser Hebel weg. Warum das bei Signalen und Klassifikationen relevant ist, beschreibt der Beitrag LLM-Determinismus im Trading.

Reproduzierbarkeit muss deshalb aus der Architektur kommen, nicht aus einem Parameter:

• Ausgaben speichern statt neu erzeugen: Jede Modellantwort, die in einen Backtest oder eine Auswertung einfließt, wird mit Eingabe-Hash, Modell-ID, Request-ID und Zeitstempel abgelegt. Backtests lesen gespeicherte Werte, statt das Modell erneut zu fragen.
• Ausgaben einengen: Structured Outputs mit enum-Feldern statt Freitext. Eine Kategorie aus fünf Werten schwankt weniger als eine frei formulierte Einschätzung.
• Streuung messen: Dieselbe Eingabe mehrfach senden und die Übereinstimmung als Kennzahl führen. Wo sie zu niedrig ist, hilft eine Mehrheitsentscheidung über mehrere Läufe, die aber Kosten vervielfacht.
• Effort festschreiben: Der Effort-Wert beeinflusst Tiefe und Tokenverbrauch. Setzen Sie ihn explizit, statt sich auf modellabhängige Standardwerte zu verlassen.

Ein Punkt wird bei Research-Pipelines oft übersehen: Die neuen Modelle haben laut Anthropic einen verlässlichen Wissensstand bis Juni 2026, Haiku 4.5 bis Februar 2025. Wer historische Nachrichten neu auswerten lässt, riskiert, dass das Modell den späteren Kursverlauf aus dem Training kennt. Neu erzeugte Merkmale für vergangene Zeiträume sind deshalb mit Vorsicht zu behandeln; gespeicherte Altwerte sind für Backtests in der Regel die sauberere Basis.

Mehr Tokens durch den neuen Tokenizer: Kosten neu rechnen.

Ab Claude 4.7 nutzt Anthropic einen neuen Tokenizer. Laut Preisdokumentation erzeugt er für denselben Text etwa 30 % mehr Tokens, je nach Inhalt mehr oder weniger. Sonnet 4.5, Sonnet 4.6 und Haiku 4.5 nutzen noch den alten. Ein Vergleich der Listenpreise allein führt deshalb in die Irre. Dazu kommt das Thinking: Thinking-Tokens werden als Output-Tokens abgerechnet, auch wenn der Text nicht zurückkommt.

Rechenbeispiel (Listenpreise Claude API, Abruf 07.10.2026): Eine Pipeline verarbeitet im Monat 180 Mio. Input- und 30 Mio. Output-Tokens, gemessen mit dem alten Tokenizer, ohne Thinking.

Von Sonnet 4.5 auf Sonnet 5.5 sinken die Kosten in diesem Beispiel also nur um rund 13 % statt um ein Drittel, wie es die Listenpreise nahelegen. Haiku 5.5 ist laut Preisliste deutlich günstiger als Haiku 4.5, wird aber nach Prompt-Länge abgerechnet: Über 100.000 Tokens pro Anfrage gelten 0,50 $ / 2,50 $. Dazu kommen Thinking-Tokens, und ob die Qualität für Ihre Aufgabe reicht, zeigt erst der Test. Die Batch API halbiert die Preise für alles, was nicht sofort gebraucht wird, etwa nächtliche Auswertungen von Unternehmensmeldungen.

Ein Sonderfall sind Chart-Screenshots: Sonnet 5.5 verarbeitet Bilder in höherer Auflösung. Anthropic nennt für ein 2000×1500-Bild etwa 2,5-mal so viele Tokens wie bei Sonnet 4.5. Wer Charts als Bild schickt, sollte vorher verkleinern, wenn die Zusatzschärfe nichts bringt. Für eigene Zahlen nutzen Sie den Token-Counting-Endpunkt mit echten Eingaben aus Ihrem Testkorpus.

Regressionstest vor dem Umstieg: Testkorpus, Vergleich, Rollback.

Ein Modellwechsel ist ein Release wie jedes andere und gehört getestet, bevor er live geht. Die Grundidee: Ein fester Testkorpus läuft gegen altes und neues Modell, die Ergebnisse werden mit vorher festgelegten Kennzahlen verglichen. Allgemeine Prinzipien dazu stehen im Beitrag Modellwechsel ohne Reue; für Claude-Pipelines heißt das konkret:

1. Korpus aufbauen: 200 bis 500 echte, historische Eingaben aus Ihrer Pipeline, etwa Schlagzeilen, Auszüge aus Quartalsberichten oder Ad-hoc-Meldungen. Schwierige Fälle bewusst aufnehmen: mehrdeutige Meldungen, lange Dokumente, fremde Sprachen.
2. Referenz festhalten: Für jeden Fall die Antwort des alten Modells speichern und, wo möglich, eine von Ihnen geprüfte Soll-Antwort.
3. Kennzahlen vorher festlegen: Anteil schemakonformer Antworten, Übereinstimmung mit der Soll-Antwort, Übereinstimmung mit dem alten Modell, Streuung bei Mehrfachläufen, Ablehnungsquote (stop_reason: "refusal"), Latenz und Tokens je Fall.
4. Effort-Stufen vergleichen: Anthropic rät ausdrücklich, Effort neu zu kalibrieren statt alte Einstellungen zu übernehmen. Testen Sie mindestens zwei Stufen.
5. Schattenbetrieb: Das neue Modell läuft einige Tage parallel mit, seine Ausgaben werden nur protokolliert, nicht verwendet.
6. Rollback planen: Modell-ID per Konfiguration umschaltbar halten. Bei Sonnet 4.5 endet diese Rückfallebene am 30.11.2026; danach brauchen Sie ein anderes, noch laufendes Modell als Reserve.

Für die eigentlichen Code-Änderungen bietet Anthropic in Claude Code den Befehl /claude-api migrate. Er tauscht Modell-IDs, passt brechende Parameter und Prefills an und erstellt eine Liste manuell zu prüfender Punkte. Das spart Tipparbeit, ersetzt aber nicht den Regressionstest mit Ihrem Testkorpus.

Grenzen und Risiken der Migration.

• Structured Outputs sind keine Fachprüfung. Das Schema unterstützt keine Wertebereiche (minimum, maximum), keine Längenvorgaben und kein maxItems. Ein Stop-Loss-Abstand von minus 400 % ist schemakonform. Das Python-SDK prüft solche Pydantic-Regeln bei parse() clientseitig nach; bei rohen Schemas müssen Sie selbst validieren. Bei Ablehnungen oder erreichtem max_tokens kann die Ausgabe trotz Schema unvollständig sein.
• Latenz durch Thinking. Wo das Modell vorab denkt, dauert die Antwort länger. Ein Sprachmodell gehört ohnehin nicht in den zeitkritischen Pfad einer Orderausführung; Research, Überwachung und Berichte sind die passenden Einsatzfelder.
• Plattformunterschiede. Bedrock und Google Cloud haben eigene Abschaltdaten, und auf Bedrock fehlen für die 5.5-Modelle Structured Outputs. Ein Test auf der Claude API sagt nicht automatisch etwas über Bedrock aus.
• Modellwechsel mitten im Gespräch. Fallback-Logik, die eine laufende Konversation auf ein anderes Modell umleitet, verliert je nach Kombination die Thinking-Blöcke. Thinking-Blöcke von Sonnet 5.5 und Haiku 5.5 sind zudem an das erzeugende Konto gebunden.
• Kein Ersatz für eigene Regeln. Ein besseres Modell macht eine Strategie nicht profitabler. Risikogrenzen, Positionsgrößen und Freigaben gehören in deterministischen Code, nicht in eine Modellantwort.

Migrations-Checkliste: was Sie jetzt konkret tun können.

Für Python-Projekte bietet sich diese Reihenfolge an:

1. Usage-Export ziehen und alle Skripte mit claude-sonnet-4-5 und claude-haiku-4-5 auflisten, inklusive Bedrock- und Vertex-Aufrufen.
2. anthropic in der requirements.txt oder pyproject.toml mit Versionsgrenze pinnen, Python auf mindestens 3.10 bringen, httpx-Importe und Mocks auf httpx2 umstellen.
3. temperature, top_p, top_k und Prefills per Suche finden und ersetzen, bei Ziel Sonnet 5.5 oder Opus 5.5 auch tool_choice mit any oder tool.
4. Alle Stellen mit content[0] auf Lesen nach type umbauen, max_tokens neu bemessen, Effort explizit setzen.
5. Modell-ID in die Konfiguration verschieben, Testkorpus aufbauen, altes und neues Modell vergleichen, Kosten mit Token Counting nachrechnen.
6. Schattenbetrieb, dann Umschalten mit Rückfallebene. Sonnet 4.5 deutlich vor dem 30.11.2026 ablösen, nicht in der letzten Woche.
7. Haiku 5.5 als Ersatz für Haiku 4.5 mit dem Testkorpus prüfen und die Abkündigungsseite regelmäßig ansehen.

Wenn Sie die Umstellung nicht selbst machen möchten oder eine zweite Meinung zu Testaufbau und Architektur suchen, unterstütze ich Privatleute und Unternehmen bei der Trading-Automatisierung, von der Code-Migration bis zum Regressionstest.

Häufige Fragen.

Wann wird Claude Sonnet 4.5 abgeschaltet?

Anthropic hat Claude Sonnet 4.5 (claude-sonnet-4-5-20250929) am 30.09.2026 abgekündigt. Die Abschaltung auf der Claude API ist für den 30.11.2026 geplant, danach schlagen Anfragen fehl. Empfohlener Ersatz ist Claude Sonnet 5.5. Amazon Bedrock und Google Cloud legen eigene Termine fest, die abweichen können.

Wird Claude Haiku 4.5 am 15.10.2026 abgeschaltet?

Nach Stand 07.10.2026 nicht. Der 15.10.2026 ist nur der früheste mögliche Termin. Haiku 4.5 ist als aktiv gelistet, und Anthropic kündigt Abschaltungen öffentlich verfügbarer Modelle mindestens 60 Tage vorher an. Seit dem 07.10.2026 ist der Nachfolger Haiku 5.5 verfügbar. Er denkt standardmäßig, sein Tokenizer erzeugt für denselben Text etwa 30 % mehr Tokens, und er lehnt Prefill und Sampling-Parameter ab. Deshalb vor dem Wechsel testen.

Warum gibt Claude Opus 5.5 bei tool_choice einen 400-Fehler zurück?

Opus 5.5 und Sonnet 5.5 unterstützen keinen erzwungenen Tool-Aufruf mehr. Die tool_choice-Typen any und tool werden mit einem 400-Fehler abgelehnt, erlaubt sind nur auto und none. Für verlässlich strukturierte Daten empfiehlt Anthropic auto zusammen mit Strict Tool Use (strict: true) oder Structured Outputs über output_config.format. Auf Bedrock fehlen Structured Outputs für diese Modelle. Haiku 5.5 akzeptiert erzwungene Tool-Aufrufe weiterhin.

Wie setze ich temperature im Anthropic Python SDK 1.0?

Gar nicht mehr direkt. Das SDK 1.0 hat temperature, top_p und top_k aus den Messages-Methoden entfernt, eine Übergabe führt zu einem TypeError. Für ältere Modelle wie Haiku 4.5 geht es noch über extra_body. Ab Claude 4.7 lehnt die API abweichende Sampling-Werte ohnehin mit einem 400-Fehler ab. Anthropic empfiehlt, das Verhalten über Prompts zu steuern.

Wie mache ich Claude-Ergebnisse im Backtest reproduzierbar?

Indem Sie Modellantworten speichern, statt sie neu zu erzeugen. Legen Sie jede Ausgabe mit Eingabe-Hash, Modell-ID und Zeitstempel ab und lassen Sie Backtests nur gespeicherte Werte lesen. Engen Sie Ausgaben mit Structured Outputs und enum-Feldern ein und messen Sie die Streuung durch Mehrfachläufe. Ein Parameter für Determinismus steht bei den aktuellen Modellen nicht mehr zur Verfügung.

Quellen und Stand.

• Models overview — Anthropic
• Model deprecations — Anthropic
• Claude Platform release notes — Anthropic
• anthropic-sdk-python: v1 migration guide (MIGRATION.md) — Anthropic / GitHub
• Claude Haiku 5.5 migration guide — Anthropic
• Claude Sonnet 5.5 migration guide — Anthropic
• Pricing — Anthropic
• Structured outputs — Anthropic
• Claude Opus 5.5 migration guide — Anthropic
• Claude Haiku 4.5 (Modellseite) — Anthropic

Stand: 7. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.

Sie wollen Ihre Claude-Pipeline sauber auf die neuen Modelle umstellen? Unverbindlich anfragen — wir prüfen den Code, bauen den Regressionstest auf und planen den Umstieg mit Rückfallebene. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.