OpenAI ⇄ Anthropic Konverter

Wozu ist das gut?

Die Chat Completions API von OpenAI und die Messages API von Anthropic erlauben beide Multi-Turn-Konversationen, formen das JSON aber unterschiedlich genug, dass Prompts und Tool-Call-Traces beim Provider-Wechsel nicht sauber rüberkommen. Die Unterschiede sind klein (System-Message-Position, tool-call vs tool-use, Image-Block-Form, role: 'tool' vs Content-Array tool_result), aber jeder einzelne ist ein 10-Minuten-Kaninchenbau, wenn du unter Zeitdruck stehst. Dieser Konverter übernimmt die Übersetzung, damit du eine OpenAI-Konversation einfügen und eine Anthropic-geformte zurückbekommst (oder umgekehrt).

Was übersetzt wird

• System-Messages. OpenAI nutzt eine reguläre Nachricht mit role: "system". Anthropic legt sie auf Request-Top-Level als system-Feld ab. Wir verschieben und verketten, wenn mehrere vorhanden sind.
• Tool-Calls (assistant-Seite). OpenAI: tool_calls: [{id, type:'function', function:{name, arguments:'JSON-string'}}]. Anthropic: ein tool_use-Block im content-Array mit {id, name, input} (geparstes Objekt, kein String). Wir parsen OpenAIs escapte JSON-Argumente in das strukturierte input für Anthropic; die Gegenrichtung serialisiert zurück.
• Tool-Ergebnisse. OpenAI: eigene Nachricht mit role: "tool", tool_call_id und content. Anthropic: tool_result-Block im nächsten user-Content-Array mit tool_use_id. Aufeinanderfolgende OpenAI-tool-Nachrichten werden zu einer Anthropic-User-Message mit mehreren tool_result-Blöcken zusammengezogen.
• Bilder. OpenAI: {type:'image_url', image_url:{url}}. Anthropic: {type:'image', source:{type:'base64',media_type,data}} oder {type:'image', source:{type:'url',url}}. Wir erkennen data:-URLs und konvertieren; reine URLs gehen als URL-Source-Image durch.
• Reiner Text-Content. OpenAI nutzt einen String; Anthropic akzeptiert String und ein einelementiges [{type:'text', text}]-Array. Wir nehmen, was einfacher ist.

Was nicht übersetzt wird

• Streaming-Events. Wir handhaben Request/Response-JSON, nicht die SSE-Event-Streams. Bei Stream-Dumps die finale Nachricht erst rekonstruieren.
• Provider-spezifische Felder. Dinge wie OpenAIs logprobs, Anthropics stop_sequences, Sampling-Parameter — leben auf Request-Top-Level, nicht in Messages. Nicht Teil des Formats, das wir anfassen.
• Cache-Control-Hints. Anthropics cache_control: {type:'ephemeral'} hat kein OpenAI-Äquivalent. Überlebt OpenAI → Anthropic (keine Quelle), wird aber bei Anthropic → OpenAI verworfen.
• Tool-Definitionen. Das Schema deiner Tools (das tools-Feld auf dem Request) lebt außerhalb des Messages-Arrays. Format unterschiedlich zwischen den Providern — separat konvertieren.

Typische Stolperfallen

• OpenAI-Argument-Escaping. OpenAIs arguments ist ein JSON-codierter String, kein geparstes Objekt. Bei kaputtem JSON (selten, aber bei kleinen Modellen vorkommend) packen wir es in _raw in Anthropics input, statt zu werfen.
• Anthropic Top-Level-System. Bei OpenAI → Anthropic ist das Ergebnis {system, messages}. Wenn du nur das Messages-Array willst, nutze .messages — aber denk dran, system separat an den Request zu hängen.
• Strikte Alternation. Anthropic verlangt strikten Wechsel user/assistant nach dem optionalen System. Konverter erhält das meistens; bei zwei aufeinanderfolgenden User-Messages in OpenAI hat die Anthropic-Ausgabe das auch — und die API lehnt es ab. Vorher mergen.
• Multi-Modal in OpenAI. Eine OpenAI-User-Message mit Bildern nutzt ein Content-Array statt String. Handhaben wir; nur stell sicher, dass dein Input als JSON parst (kein Python-None, keine Single Quotes).
• Privacy. Nichts verlässt die Seite. Konvertierung ist reines JS; keine API-Keys, keine Netzwerk-Calls.