Warum steigt die KI-Rechnung, obwohl Token billiger werden?

2023 kostete GPT-4 auf der API noch rund 30 US-Dollar pro Million Input-Tokens. Ende 2024 lagen vergleichbare Modelle unter 3 Dollar. 2026 reicht für Haiku- oder Mini-Klassen oft weniger als ein Dollar. Wer nur die Preisliste liest, denkt: AI wird billiger — Problem gelöst.

Dann öffnet man die OpenRouter- oder Anthropic-Abrechnung vom letzten Monat und sieht eine Zahl, die höher ist als vor einem Jahr. Kein Einzelfall. In DACH-Teams — von Berliner SaaS-Startups bis zu Schweizer Fintechs mit strenger Finanzaufsicht — ist das inzwischen der Standard-Konflikt im Engineering-Alltag: Token-Preise fallen, Gesamtkosten steigen.

Das ist kein Abrechnungsfehler und kein versteckter Aufschlag. Es ist ein 160 Jahre altes ökonomisches Muster, das in der AI-Ära wieder voll zuschlägt: das Jevons-Paradoxon.

Jevons-Paradoxon: billiger heißt nicht weniger verbrauchen

1865 beobachtete der britische Ökonom William Stanley Jevons: Je effizienter Dampfmaschinen Kohle nutzten, desto mehr Kohle verbrauchte Großbritannien insgesamt. Effizienz senkte die Kosten pro Einheit — und machte neue Anwendungen wirtschaftlich, die vorher undenkbar waren. Fabriken, die eine Linie betrieben, schalteten drei an; Branchen ohne Dampfmaschinen stiegen ein.

Die Lektion: Einsparung pro Einheit bedeutet nicht Einsparung insgesamt. Wird eine Ressource billiger oder effizienter nutzbar, steigt die Gesamtnachfrage oft — nicht sinkt sie.

Bei LLM-APIs wiederholt sich dasselbe Muster. Jede Preisstufe öffnet Use Cases, die vorher an der Kostenbarriere scheiterten:

• Bei 30 $/M: AI nur für Meeting-Zusammenfassungen.
• Bei 3 $/M: automatisierte Code-Reviews in der CI.
• Bei 0,30 $/M: Hintergrund-Agenten für Logs, Tickets, Nightly-Scans.
• Bei 0,03 $/M: ganze Workflows dauerhaft angebunden — und niemand schaltet sie ab.

Jede Senkung ist keine Einladung zum Sparen, sondern zum mehr Wagen. Die absolute Rechnung steigt, während die Stückkosten fallen. Für CTOs und Tech Leads in DACH bedeutet das: Der Budget-Dialog verschiebt sich von „welches Modell?“ zu „welche Governance-Struktur hält Menge und Zweck im Gleichgewicht?“

Drei strukturelle Treiber der Rechnungsinflation

Das Paradoxon erklärt das „Warum“. Um Kosten zu steuern, muss man wissen, wo das Geld fließt. In typischen Entwickler- und Team-Setups sind es drei Mechanismen — unabhängig davon, ob Sie OpenRouter, Anthropic direkt oder ein gemischtes Setup nutzen. Die OpenRouter-Dokumentation macht Preise transparent; sie verhindert aber nicht, dass Volumen und Kontextexplosion die Gesamtrechnung nach oben treiben.

Treiber 1: Volumenexplosion — von gelegentlichen Prompts zu Dauerbetrieb

Vor zwei Jahren war AI-Nutzung reaktiv: eine Frage, eine Antwort. Heute laufen Cursor, OpenClaw, Custom-Skripte und CI-Agenten parallel — oft auf derselben Cloud-Mac- oder VPS-Infrastruktur. AI ist vom Assistenten zum ständig laufenden Hintergrundprozess geworden: nachts CI-Analyse, tagsüber PR-Kommentare, im Meeting still Repository-Summaries.

Die Aufrufhäufigkeit springt von Dutzenden auf Tausende pro Tag. Selbst bei einem Zehntel des Stückpreises reicht das für eine Verdopplung der Monatsrechnung.

Die letzte Zeile: von 450K auf 480M — faktor 1.000. Selbst 90 % Preisverfall seit 2023 lässt die Rechnung gegenüber dem Ausgangspunkt um Größenordnungen steigen. Für Teams mit DSGVO-Pflichten kommt hinzu: mehr Aufrufe bedeuten mehr Verarbeitungsvorgänge, die in Verarbeitungsverzeichnissen und Auftragsverarbeitungsverträgen nachvollziehbar sein müssen. Unkontrolliertes Volumen ist nicht nur ein Finanz-, sondern ein Compliance-Risiko, wenn Prompts Kundendaten oder Quellcode enthalten.

Treiber 2: Kontextinflation — jeder Request wird schwerer

Der zweite, leisere Kostenfaktor ist nicht die Anzahl der Calls, sondern deren Gewicht. 2023 passten in 4K Context ein paar Chat-Runden. 2026 sind 200K–1M Context Standard. Entwickler schicken ganze Repos, PDFs und vollständige Thread-Historien mit — „das Modell schafft das ja“.

Hinzu kommen „Extended Thinking“- und Reasoning-Modi: interne Denk-Tokens werden mitberechnet und übersteigen oft die sichtbare Antwort. Eine „tiefe Analyse“ kann fünf- bis zehnmal teurer sein als der Endnutzer vermutet. In regulierten Umgebungen (Banking, Health, öffentliche Verwaltung in DE/AT/CH) sollten solche Modi bewusst geroutet werden — nicht als Default für jeden Cron-Job.

Treiber 3: Agent-Multiplikator — Tokens addieren sich nicht, sie multiplizieren

Der aggressivste Treiber: agentische Workflows. Eine Nutzeranfrage löst eine ganze Kette aus — nicht einen einzelnen API-Call.

Eine Nutzeraktion, sieben bis acht abrechenbare LLM-Aufrufe — jeder mit großem Kontext. Das ist der Multiplikator: ein Klick, acht Zeilen auf der Rechnung.

Besonders riskant: Agenten ohne klare Abbruchbedingung. Fehler → Retry → Endlosschleife. Zwei Agenten, die aufeinander warten, blockieren Ressourcen und Tokens gleichzeitig.

Rechnung aufschlüsseln: eine nüchterne Rechnung

Annahme: 10 Agent-Tasks pro Tag, je 8 LLM-Calls, je 10.000 Tokens (inkl. Kontext).

72–360 $ pro Person — ohne Team, ohne Wochenend-Peaks. Skaliert das Team auf zehn Köpfe oder verdoppeln sich die Tasks, multipliziert sich die Summe. Die Rechnung hängt an der Länge der Multiplikator-Kette, nicht daran, ob man „AI nutzt“.

Kosten steuerbar machen — nicht weniger nutzen, sondern bewusst

Jevons lehrte nicht „Verzicht“, sondern „Struktur“. Mehr Kohle trieb die Industrialisierung; mehr Tokens können echte Produktivität sein — wenn Wert und Kosten sichtbar bleiben. Für DACH-Teams bedeutet Cost Governance oft auch: wer darf welches Modell mit welchen Daten aufrufen, dokumentiert und begrenzt. Drei Hebel, aufsteigend nach Implementierungsaufwand:

Hebel 1: Gestuftes Routing — günstige Modelle für Massenarbeit

Nicht jede Aufgabe braucht Opus. Syntax-Check und Architektur-Review liegen Welten auseinander; gleiches Modell → gleiche überhöhte Rechnung.

Drei Stufen reichen meist:

• Formatierung, Klassifikation, Kurzfassungen: Haiku / GPT-4o-mini (~0,15–0,30 $/M).
• Code, mehrstufige Reasoning, Docs: Sonnet / GPT-4o (~3–5 $/M).
• Architektur, Deep Debug, Extended Thinking: Opus / o3 — nur on demand.

In LiteLLM Aliase (fast / smart / deep) definieren; Clients routen nach Task-Typ. Master-Keys und Routing-Logik zentral auf dem Gateway — Schritt-für-Schritt im Cloud-Mac- + OpenRouter-Praxisguide.

Hebel 2: Budget-Fuses — abschalten, bevor das Budget weg ist

Routing wählt das richtige Modell; Budget-Limits fangen Runaway-Agenten ab. Minimum: zwei Schichten.

1. Upstream Credit Cap: hartes Monatslimit in OpenRouter oder Anthropic — API lehnt ab statt still weiterzulaufen.
2. Virtual Keys mit Spend Cap: pro Client (Cursor, OpenClaw, Skript) eigener Key und eigenes Budget im selbst gehosteten Gateway.

curl -X POST http://127.0.0.1:4000/key/generate \
                  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
                  -H "Content-Type: application/json" \
                  -d '{
                    "key_alias": "cursor-dev",
                    "models": ["fast", "smart"],
                    "max_budget": 20,
                    "budget_duration": "1mo",
                    "metadata": {"tool": "cursor", "env": "dev"}
                  }'

Monatsdeckel 20 $, nur fast und smart — bei Überschreitung 429, Master-Key unberührt. Das ist die kleinste tragfähige Governance-Schicht für Einzelpersonen und kleine Teams — und erleichtert Audits: „Welches Tool hat im März wie viel verbraucht?“

Hebel 3: Observability — ohne Sicht kein Sparen

Viele Überraschungen kommen am Monatsende: ein Agent hat freitags still 50 $ verbrannt, die Aufgabe war längst erledigt. Ohne Echtzeit-Spend fehlt die Grundlage für FinOps und für DSGVO-konforme Nachweise, welche Systeme personenbezogene Daten an welche Subprozessoren senden.

• LiteLLM Dashboard: unter /ui Spend, Request-Rate und Latenz pro Virtual Key.
• Tägliche Alerts: Cron + SQLite-Abfrage auf litellm_verificationtoken, bei Schwellwert Slack oder E-Mail.
• Abgleich mit Upstream: wöchentlich LiteLLM-Spend vs. OpenRouter-Konsole — Abweichung >10 % deutet auf Bypass des Gateways hin (direkte Keys auf Laptops).

Die eigentliche Frage ist nicht „Wie spare ich?“

Jevons hat Effizienz nicht verdammt — er hat gezeigt, dass Nachfrage mitwächst. Mehr Tokens können mehr Wert bedeuten, wenn man unterscheiden kann zwischen bewusster Investition und unbewusstem Verschleiß.

• Erzeugen die zusätzlichen Tokens messbaren Gegenwert?
• Wie viel der Rechnung ist geplant, wie viel Nebenwirkung?
• Kann das Team das jederzeit beantworten — ohne Excel und Bauchgefühl?

Ziel ist nicht „weniger Tokens“, sondern jeder Token an der richtigen Stelle. Routing, Budget-Fuses und Transparenz sorgen dafür, dass steigende Rechnungen zumindest „gute“ Steigerungen sind — und dass Finanz- und Datenschutz-Verantwortliche dieselben Zahlen sehen.

FAQ

Gilt das Jevons-Paradoxon für AI dauerhaft? Solange neue Use Cases bei jedem Preissturz freigeschaltet werden — und Reasoning fast unbegrenzt menschliche Arbeit ersetzen kann —, ja. Erst wenn Fähigkeit und Nachfrage saturiert sind, flacht der Effekt ab. Diese Grenze ist derzeit nicht absehbar.

Reicht „billigeres Modell“? Kurzfristig ja. Langfristig wandert das eingesparte Budget in mehr Tasks — zurück auf Jevons-Kurs. Nachhaltig wirken harte Budgets und Sichtbarkeit, nicht dauerhaftes Downgrading.

Kann man den Agent-Multiplikator eliminieren? Nein, aber begrenzen: Max-Schritte pro Task, Result-Caching, Orchestrator-Regeln statt LLM wo möglich.

Wird es mit Teamgröße schlimmer? Ab drei Personen ohne Gateway: Keys verstreut, niemand kennt den Gesamt-Spend. Virtual Keys und per-User-Caps werden Pflicht — Migration später ist teurer als früher Aufbau.