Zurück
Live2026

Kairotokens

Claude Code weiterbenutzen, nur günstiger.

Claude Code ist ein sehr gutes Werkzeug, aber teuer, weil es fest an die Anthropic-API gebunden ist. DeepSeek kostet einen Bruchteil. Also habe ich etwas dazwischengesetzt, das sich für Claude Code exakt wie Anthropic verhält, die Anfragen aber an DeepSeek weiterreicht. Zwei Umgebungsvariablen ändern, sonst bleibt alles wie es war.

kairotokens.cc

Fakten

Rolle
Alles: Architektur, Worker, Abrechnung, Betrieb
Status
Live, kommerziell genutzt
Quellcode
Nicht öffentlich

Das Problem

  1. Claude Code spricht nur die Anthropic-API. Ein anderes Modell davorzuhängen geht nicht über eine Einstellung, sondern nur über eine Zwischenschicht, die sich für den Client exakt wie Anthropic verhält.

  2. Exakt heißt exakt: dasselbe Wire-Format, dasselbe Streaming, dieselbe Fehlerform. Jede Abweichung fällt sofort auf, weil der Client dann schlicht abbricht.

  3. Zugang weiterverkaufen heißt nicht, den eigenen Schlüssel herauszugeben. Der ist unteilbar, unbegrenzt und nicht pro Kunde sperrbar. Es braucht eigene Schlüssel mit eigenem Guthaben.

  4. Die Abrechnung muss stimmen. Laufen zwei Anfragen desselben Kunden gleichzeitig und buchen beide vom selben Guthaben ab, darf nichts verloren gehen, sonst gebe ich Leistung heraus, die niemand bezahlt.

Architektur

  1. Claude Codeunverändert, spricht die Anthropic-API
  2. WorkerSchlüssel prüfen, Modell setzen, bereinigen
  3. Durable ObjectGuthaben, streng konsistent
  4. DeepSeekantwortet im Anthropic-Format

Entscheidungen

  1. Das Modell wird erzwungen, nicht durchgereicht

    Der Worker überschreibt das angefragte Modell immer auf DeepSeek, statt den Wunsch des Clients weiterzugeben. Sonst könnte jemand ein Anthropic-Modell anfragen und stillschweigend eine Antwort von woanders bekommen. Ein Feld, das nur manchmal stimmt, ist schlimmer als eines, das immer überschrieben wird, und auf der Seite steht deshalb auch offen, welches Modell tatsächlich antwortet.

  2. Durable Objects fürs Guthaben, KV nur für Schlüssel

    KV ist eventually consistent, also gut genug für „ist dieser Schlüssel gültig?“, untauglich für „wie viel Guthaben ist noch übrig?“. Zwei parallele Anfragen könnten denselben veralteten Stand lesen und beide abbuchen. Durable Objects serialisieren die Zugriffe pro Kunde und geben starke Konsistenz: genau ein Objekt pro Käufer, ein Schreiber nach dem anderen.

  3. Abrechnen nach der Antwort, nicht davor

    Der Preis steht erst fest, wenn die Antwort da ist und die verbrauchten Tokens bekannt sind. Die Verrechnung läuft deshalb über waitUntil() weiter, nachdem die Antwort schon beim Kunden ist. Latenz ist ein Feature: alles, was nicht vor der Antwort passieren muss, gehört dahinter.

  4. Streaming durchreichen statt neu kodieren

    Server-Sent Events laufen über einen TransformStream direkt durch. Ich parse die Events nicht und baue sie nicht neu. Das spart Latenz und macht den Proxy unempfindlich dagegen, dass der Upstream neue Event-Typen einführt, die ich noch nicht kenne.

  5. Unbekannte Felder entfernen statt Fehler werfen

    Der Upstream versteht nicht alles, was Anthropic-Clients schicken. Statt mit einem Fehler abzubrechen, entferne ich diese Felder und leite die Anfrage weiter. Das Ergebnis ist minimal schlechter, aber die Anfrage läuft. Ein harter Fehler wäre für den Nutzer die deutlich schlechtere Erfahrung.

  6. Fehler in der Form zurückgeben, die der Client kennt

    Upstream-Fehler werden in die Anthropic-Fehlerform übersetzt und mit dem ursprünglichen Status weitergegeben: leeres Guthaben, Rate-Limit, Überlast. Der Client kann seine normale Fehlerbehandlung benutzen und muss nichts über den Proxy wissen. Kompatibilität endet nicht beim Happy Path.

Ergebnis

  • Claude Code läuft unverändert weiter: zwei Umgebungsvariablen umstellen, kein neues Werkzeug, kein anderer Ablauf.

  • Live auf eigener Domain; die von Cloudflare vergebene Standard-Subdomain ist deaktiviert, damit es genau einen Einstiegspunkt gibt.

  • Schlüssel werden über eine geschützte Admin-Schnittstelle ausgegeben, aufgeladen und gesperrt. Der Schlüssel selbst ist genau einmal sichtbar, danach liegt nur noch eine Referenz im System.

  • Dazu eine eigene Landingpage mit Preisrechner, Setup-Anleitung und FAQ.

  • Das erste Projekt, bei dem ein Fehler unmittelbar Geld kostet.

Was ich gelernt habe

  • Konsistenzmodelle sind keine Theoriefrage. Der Unterschied zwischen eventually und strongly consistent war hier ein Geschäftsrisiko.

  • Kompatibel sein heißt, sich an einen fremden Vertrag zu halten, auch bei Statuscodes und Fehlern.

  • Sinnvolle Degradation schlägt einen sauberen Abbruch, wenn am anderen Ende jemand arbeiten will.