Schon mal wegen einer über Nacht explodierten AI-Rechnung die Nacht durchgemacht, ohne zu wissen, warum?
Das ist AI-Devs schmutziges Geheimnis: Diese Modelle saufen Tokens wie Sportwagen Sprit, aber ohne Armaturenbrett fliegen Sie blind. Hier kommt das Three-Table-Pattern – Requests, Responses, Exchanges. Eine irrsinnig einfache Struktur, die speichert, was Sie rausschicken, was zurückkommt, und alles fest verknüpft. So purzeln Kosten von allein raus. Ich hab’s in Chat-Apps, Background-Jobs, überall, wo AI ins Spiel kommt, den Nebel lichten sehen.
Und das Beste: Kein Enterprise-Bloatware. Nur drei Tabellen, eine ID-Verknüpfung – und zack, jeder Round-Trip nachverfolgbar. Kein Log-Wühlen. Kein UI-Raten.
Warum fühlt sich AI-Round-Trip-Tracking wie Hexerei an – bis jetzt?
AI ist ein Plattformwechsel größer als das iPhone – Modelle als Endpoints, Prompts als APIs. Aber Kosten? Die Steuer auf die Magie. Input-Tokens, Output-Tokens, Vendor-Preisstufen – das eskaliert schnell.
TL;DR: AI in App packen? Request speichern, Response speichern, mit Exchange verknüpfen. Diese Struktur macht jeden Round-Trip nachverfolgbar – Token-Kosten fallen natürlich raus.
Das ist der Urknall, direkt aus dem Schützengraben. Peng. Autorität.
Mein Twist? Das erinnert an die Geburt der Web-Observability – wisst ihr noch, als HTTP-Request-Logs noch eine Neuheit waren? Heute Standard dank New Relic. Vorspulen (nein, doch nicht): Dieses Drei-Tabellen-Tänzchen ist AI’s New Relic – heute primitiv, morgen überall. Fetter Einsatz: Bis 2026 backt’s in Frameworks wie LangChain ein und schreddert Verschwendung, indem es Prompt-Lecks früh aufspürt.
Kurzer Absatz. Wumms.
Jetzt aufbrechen. Requests-Tabelle: User-Input, User-ID, Kontext (z. B. YouTube-Transcript-ID), Status pending. Minimal. Responses: Model-Output, vielleicht strukturiertes JSON, Token-Zahlen hier manchmal. Exchanges: Der Kleber – request_id, response_id, input_tokens, output_tokens, model_used, status. Eine Zeile pro Chat-Turn. Das abfragen für Rechnungen.
Der Ablauf? Request einfügen (pending). Exchange einfügen (verknüpft Request, pending). Model treffen. Response einfügen. Exchange updaten: Tokens, Model, done. Fail? Als failed markieren. Immer audit-ready.
Wie verkabeln Sie das in Supabase – ohne durchzudrehen?
Supabase glänzt hier – Postgres drunter, Edge Functions für Calls. Nehmen wir Chat-UI mit YouTube-Transkripten.
Code plumps rein: insertKnowledgeTranscriptChatRequest. Holt user_id, transcript_id, content, setzt pending. Gibt ID zurück.
Dann insertKnowledgeTranscriptChatExchange: Verknüpft zu request_id, user_id, pending.
Model zündet – sagen wir GPT-4o-mini. Response landet: Exchange updaten mit response_id, tokens, model, completed.
Client kriegt responseId, tokens, modelUsed. Redux-Slice normalisiert – kein Extra-Kostenservice. Session liest Kosten direkt.
Magie im Gang. Und skalierbar – gleiche Form für Blog-Ideen-Jobs. Topic, ICP-Kontext in Request. Strukturierte Ideen, Tokens in Response. Exchange verknüpft. Redux-Dump per ID. Konsistent.
Aber warte – Corporate-Hype? Nee, kein Vercel-Vector-Gequatsche. Rohes, dev-first Pragmatismus. Kein Vendor-Lock. Postgres überall.
Fragment: Sauber.
Tiefer: Token-Zahlen in Exchange lassen Aggregate-Queries fliegen. „User Xs Monatsausgabe?“ SELECT SUM(input_tokens * price_per_million) FROM exchanges JOIN users… Fertig. Dashboards sprießen.
Oder debuggen: „Warum ist der Prompt gefloppt?“ Request.content, response.structured ziehen. Kein Zerstreuen.
Wird dieses Muster AI-Dev-Kosten explodieren lassen – oder begraben?
Ja – begraben. Mein Alleinstellungsmerkmal: Die fehlende Observability-Schicht für die agentic era. Agents ketten Calls; ohne das, Token-Black-Hole. Exchanges pro Agent-Run tracken, und ROI-Rechnung klar. Historisches Pendant? Unix-Pipes – einfaches Verknüpfen machte Komplexes komponierbar. Das tut’s für AI-Pipelines.
Echter Win: Background-Blog-Jobs. createMarke
