Cloudflare AI Gateway statt SDK: Was der Stainless-Deal ändert

Was am Dienstag tatsächlich bekannt wurde

1. Mai 2026 – The Information machte die Gespräche öffentlich und berief sich dabei auf eine mit dem Vorgang vertraute Person. Der Kaufpreis: mindestens $300 Millionen, wobei ein Teil voraussichtlich in Anthropic-Aktien gezahlt würde. Quellen bezeichnen den Vorgang als erste Übernahme von Anthropic – und genau das sollte aufhorchen lassen. Anthropic kauft weder ein Modellteam noch ein Forschungslabor. Das Unternehmen kauft die technische Infrastruktur.

Auch der Preisaufschlag ist aufschlussreich. Stainless schloss im Dezember 2024 eine Series-A-Runde bei einer Bewertung von $150M ab. Fünf Monate später bietet Anthropic ungefähr das 2x-Fache. Am selben Tag, an dem die Gespräche durchsickerten, berichtete Bloomberg, Anthropic strebe in einer neuen Runde über $30B+ eine Bewertung von $900B an. Die Verhandlungen sind weit fortgeschritten, aber nicht abgeschlossen. Die Konditionen können sich noch ändern.

Was Stainless eigentlich entwickelt – in einem Absatz

Stainless ist ein KI-gestützter Compiler, der aus einer OpenAPI-Spezifikation produktionsreife SDKs für TypeScript, Python, Go, Kotlin, Java, Ruby, PHP und C# erzeugt. Terraform befindet sich in der Betaphase, Rust und Swift stehen auf der Roadmap. Wiederholungsversuche, Streaming, Paginierung und typisierte Fehlerbehandlung sind in den generierten SDKs bereits integriert. Für ein vier Jahre altes Startup liest sich die Kundenliste geradezu absurd: OpenAI, Anthropic, Google, Cloudflare, Meta, Runway, Groq, Cerebras, Lithic und Modern Treasury. Zusammengenommen verzeichnen diese Bibliotheken wöchentlich Downloads im zweistelligen Millionenbereich. Die Organisation github.com/stainless-sdks pflegt einen öffentlich sichtbaren Teil davon; der Rest liegt in kundeneigenen Repositorys, in die Stainless seine Commits schreibt.

Die realistischen Szenarien für OpenAI und Google

Vier Szenarien sind denkbar. Jedes ist auf seine Weise problematisch.

Szenario A – die Unternehmen bleiben per Vertrag bei Stainless. Kurzfristig ist das die günstigste Lösung, nach der nächsten Vertragsverlängerung jedoch kaum tragbar. Jede SDK-Veröffentlichung läuft dann über einen Anbieter, der dem größten Wettbewerber gehört. Zugleich müssten OpenAI und Google darauf vertrauen, dass dieser Wettbewerber keinen Einblick in die OpenAPI-Spezifikationen nimmt, die er nun kompiliert. Dass OpenAI einen solchen Folgevertrag unterzeichnet, erscheint unwahrscheinlich. Google könnte für ein Quartal dabeibleiben und parallel eine Alternative aufbauen.

Szenario B – sie forken den Generator. Der Wert von Stainless steckt im geistigen Eigentum des Compilers, nicht in dessen Ausgabe. Das zuletzt generierte SDK lässt sich mit einem einzigen git clone forken. Den Compiler zu forken, der die SDKs der kommenden zehn Jahre erzeugen soll, ist dagegen ein Entwicklungsprojekt über mehrere Quartale – und es muss abgeschlossen sein, bevor die nächste große API-Änderung erscheint. Schwierig und teuer, aber strategisch vertretbar. OpenAI dürfte diesen Weg innerhalb von sechs Monaten einschlagen.

Szenario C – sie holen die SDK-Erzeugung von Grund auf ins eigene Haus. OpenAI verfügt über genügend Personal. Zu erwarten wären 6–12 Monate mit Reibungsverlusten: Breaking Changes, fehlende Sprachunterstützung und all jene seltenen Grenzfälle, die Stainless bereits gelöst hat. Die SDKs für Kotlin und Go sind weniger ausgereift als jene für Python und TypeScript und dürften zuerst Rückschritte machen.

Szenario D – zwölf Monate lang bleibt stillschweigend alles beim Alten, während Anthropic beweist, dass es das Team weder aushöhlt noch Veröffentlichungen für Wettbewerber ausbremst. Möglich ist das. Darauf wetten sollte niemand. Eine Produktionsabhängigkeit darf nicht auf dem Wohlverhalten eines Wettbewerbers beruhen.

Für den Betrieb folgt daraus: SDK-Versionen jetzt festschreiben. Prüfen, von welchen offiziellen Bibliotheken der eigene Stack abhängt. Und dokumentieren, in welchen produktiv eingesetzten Sprachen die Testabdeckung dieser Bibliotheken am dünnsten ist – dort werden Regressionen zuerst auftreten.

Warum Cloudflare AI Gateway diese Woche anders wirkt

In einem einzigen Cloudflare-Workers-Stack betreibe ich sechs KI-Anbieter: Anthropic, Google AI Studio, xAI, OpenAI, DataForSEO und Browser Rendering. Keines ihrer SDKs wird importiert. Jeder kostenpflichtige Aufruf läuft per fetch() über den AI-Gateway-Endpunkt; der JSON-Body entspricht jeweils der REST-Struktur des Anbieters.

Diese Entscheidung fiel vor drei Wochen aus einem anderen Grund: Jeder kostenpflichtige Aufruf sollte einen zentralen callAi()-Wrapper passieren, der ein tägliches Kostenlimit von $20 und ein Limit von $1 pro Instanz durchsetzt. SDKs verstecken diesen Kontrollpunkt hinter einem Methodenaufruf. Wer das Limit dennoch auf dem SDK-Pfad erzwingen will, muss entweder den Client per Monkey-Patching verändern oder jede Aufrufstelle einzeln umschließen. Bei fetch() genügt dafür eine Funktion.

Der BYOK-Passthrough von Cloudflare AI Gateway ermöglicht einen einzigen Authentifizierungs-Header (cf-aig-authorization) und ein gemeinsames URL-Muster für Anthropic, OpenAI, Google, xAI und die Bilderzeugung von OpenAI. Das Grundmuster sieht so aus:

export async function callAi(env: Env, ctx: Ctx, runner: () => Promise<Response>) {
  await assertUnderCostCap(env, ctx);
  const started = Date.now();
  const res = await runner();
  await recordCost(env, ctx, res, Date.now() - started);
  return res;
}

// usage – one provider, no SDK in the dep tree
const res = await callAi(env, ctx, () => fetch(
  `https://gateway.ai.cloudflare.com/v1/${env.ACCOUNT}/${env.GATEWAY}/anthropic/v1/messages`,
  {
    method: "POST",
    headers: {
      "cf-aig-authorization": `Bearer ${env.AI_GATEWAY_TOKEN}`,
      "x-api-key": env.ANTHROPIC_API_KEY,
      "anthropic-version": "2023-06-01",
      "content-type": "application/json",
    },
    body: JSON.stringify({ model, max_tokens, messages }),
  },
));

Der unbeabsichtigte Nebeneffekt in dieser Woche: Änderungen an Eigentumsverhältnissen bei Stainless können weder den Veröffentlichungstakt noch Breaking Changes oder Telemetrie-Hooks in diesem Stack berühren. Dafür müssen die Request-Payloads selbst geschrieben werden – genau jene Details also, die SDKs eigentlich verbergen sollen. Dieser Preis lohnt sich, wenn (a) mindestens drei Anbieter im Einsatz sind, (b) ein zentraler Kontrollpunkt für Kosten erforderlich ist und (c) nun zusätzlich das Eigentümerrisiko eines Anbieters abgesichert werden soll. Den dritten Grund gab es am Montag noch nicht.

Wie dieser Stack auf Cloudflare Workers läuft, ohne das Budget zu sprengen, habe ich ausführlicher im Beitrag Cursor-Cloud-Agent-Umgebungen im Vergleich zu Cloudflare Workers beschrieben.

Was diese Woche zu tun ist

Zuerst sollten package.json und requirements.txt auf SDKs geprüft werden, die Stainless erzeugt. Die Python- und Node-Clients von Anthropic und OpenAI sind die offensichtlichen Kandidaten. Auch Googles neues @google/genai stammt von Stainless – statt zu raten, liefert die Organisation github.com/stainless-sdks die vollständige Liste.

Jedes von Stainless generierte SDK sollte auf die aktuelle Minor-Version festgeschrieben werden. Patch-Updates können übernommen werden, Minor-Updates sollten zunächst geprüft werden. Der Aufwand beträgt 15 Minuten und schafft ein Quartal zusätzlichen Handlungsspielraum.

Bei jedem neuen Codepfad zu einer Modell-API sollte zuerst die direkte fetch()-Variante und erst danach der SDK-Aufruf entstehen. Bleibt die direkte Fassung einschließlich Typen unter 40 Zeilen, sollte sie produktiv eingesetzt werden. Die meisten Endpunkte für Chat Completions und Messages bleiben problemlos darunter. Streaming und Tool-Nutzung bringen weitere 20 Zeilen hinzu. Auch das liegt noch unter der sinnvollen Grenze für einen Pfad, der über Jahre gepflegt werden muss.

Wer ein Gateway wie Cloudflare AI Gateway, OpenRouter, Portkey oder LiteLLM betreibt, sollte jeden Modellaufruf darüber leiten. Eine Authentifizierung, eine zentrale Beobachtungsfläche und eine Stelle, an der sich Anbieter austauschen lassen, sobald das darunterliegende SDK politisch zum Risiko wird.

Außerdem gehört eine Erinnerung in 90 Tagen in den Kalender: Dann ist erneut zu prüfen, welche SDKs OpenAI und Google intern pflegen und welche weiterhin über Stainless laufen. Die Entscheidung zwischen Fork und Verbleib dürfte noch vor Jahresende fallen.

Das Gesamtbild

Der Modellwettbewerb verlagert sich von den Gewichten zur Infrastruktur. Das Modell selbst wird zunehmend austauschbar, die Integrationsschicht hingegen bindet Kunden. Nur unter dieser Annahme ergibt der Kaufpreis Sinn.

Anthropic nimmt $30B zu einer Bewertung von $900B auf und investiert gleichzeitig $300M in SDK-Infrastruktur statt in eine öffentlichkeitswirksamere Modellveröffentlichung. Das ist das entscheidende Signal. Beide Unternehmen greifen über das Modell hinaus nach der Bereitstellungsschicht. Das Modell wird zum günstigen Teil, die Integration zum Burggraben. Dasselbe Muster zeigt sich beim Verkauf von Claude an mittelständische Unternehmen. Der Beitrag über den Automatisierungs-Stack für $50K ist ein Beispiel für jene Reichweite im Unternehmensmarkt, die den Besitz der SDK-Schicht attraktiv macht.

Für Gründer geht es in den kommenden 12 Monaten darum, die eigene Integrationsschicht genauso zu kontrollieren wie die Datenschicht. Nicht die Bequemlichkeit eines SDKs sollte optimiert werden, sondern die Austauschbarkeit. Das heute aufgerufene Modell wird nicht dasselbe sein, das 2027 zum Einsatz kommt. Entscheidend ist ein Wrapper, der diesen Wechsel übersteht.