Compute ist der neue Flaschenhals – warum Rechenleistung über den Erfolg von KI-Agenten entscheidet

Anthropic hatte offenbar ein massives Nachfrageproblem: Die Nutzung von Claude wuchs viel stärker als geplant. Das führte zu spürbaren Einschränkungen: Claude-Nutzungslimits wurden härter, Claude Code wurde für Heavy User eingeschränkt, API-Rate-Limits bremsten produktive Workflows. Neue Compute-Deals sollen das entspannen – Limits wurden offenbar verdoppelt, API-Rate-Limits deutlich erhöht. Aber die grundlegende Lektion bleibt: Rechenleistung ist nicht unbegrenzt, und wer Agenten produktiv betreibt, muss Compute als strategische Ressource planen, nicht als selbstverständliche Grundlage. Für Kundenprojekte heißt das: Bei der Planung eines Agentensystems müssen Rate Limits, Latenz, Kosten, Verfügbarkeit, Token-Durchsatz und die Möglichkeit paralleler Agenten von Anfang an berücksichtigt werden.

Lokale Modelle wie Gemma 4 und Ollama werden durch technische Verbesserungen wie Multi-Token-Prediction schneller und zugänglicher. In der Praxis zeigt sich aber: Auf normaler Kundenhardware ist lokale Nutzung für anspruchsvolle Agentenarbeit oft zu langsam. Das bedeutet nicht, dass lokale Modelle irrelevant sind – sie sind strategisch wichtig für Datenschutz, Kostenkontrolle, Offline-Szenarien und sensible Daten. Aber für produktive High-Performance-Agenten sind aktuell die großen Cloud-Provider überlegen. Für den DACH-Markt entstehen daraus drei Kundenklassen: Cloud-first für schnelle, leistungsfähige Lösungen. Hybrid für sensible Daten lokal und komplexe Reasoning-Aufgaben in der Cloud. Und Local/On-Prem nur bei besonderen Datenschutz-, Compliance- oder Konzernanforderungen.

Die Managed-Agents-Entwicklung bei Anthropic – Multi-Agent-Sessions, Subagents, Webhooks, externe Endpunkte, Dreaming – ist grundsätzlich stark. Agenten laufen dann nicht mehr nur auf dem eigenen Rechner, sondern in der Anbieter-Infrastruktur. Aber die Kehrseite ist real: Vendor Lock-in, intransparente Kosten, geringe Kontrolle über die eigene Delivery, abhängig von einem einzigen Provider. Für ein Unternehmen, das Kunden bedient, ist das ein ernstes Risiko. Der bessere Ansatz: Die Orchestrierung bleibt beim Dienstleister, das Modell ist austauschbarer Lieferant. Kundensysteme werden über n8n, Make, eigene APIs, CRM, Kalender und Telefonie verbunden – mit Claude, OpenAI, Gemini oder lokalen Modellen je nach Use Case. Memory und Business-Logik werden nicht an einen Anbieter gekettet.

Daraus entsteht ein technischer Standard, der für jedes produktive Agentenprojekt gelten sollte: Jeder Agent braucht eine Fallback-Strategie. Hauptmodell plus Backup-Modell plus günstigere Modelle für einfache Tasks plus lokale oder kleine Modelle für Klassifikation plus harte Eskalation an Menschen bei Modellfehlern plus Queue-System bei Rate Limits. Das klingt komplex, aber es ist der Unterschied zwischen einem Prototypen und einem produktiven System. Ein gutes Modell bringt nichts, wenn es im Kundenprozess dauernd ins Limit läuft.

Schritt 1 – Compute-Budget als fixen Posten in Kundenprojekte aufnehmen. Nicht nur Lizenzkosten für Software planen, sondern API-Kosten, Token-Verbrauch, Rate Limits und Fallback-Szenarien. Ein Agent, der 200 Anrufe pro Tag verarbeitet, hat andere Compute-Anforderungen als einer, der 20 verarbeitet.

Schritt 2 – Für jeden produktiven Agenten ein Fallback-Modell definieren. Hauptmodell fällt aus oder ist limitiert? Welches Modell übernimmt? Zu welchen Kosten? Mit welchen Einschränkungen? Das muss vor dem Livegang geklärt sein, nicht währenddessen.

Schritt 3 – Lokale Modelle nicht als Standard verkaufen, sondern als Premium-Option für spezifische Use Cases. Datenschutz-Kunden, Compliance-intensive Branchen, Unternehmen mit eigener Serverinfrastruktur – dort ist lokal sinnvoll. Für alle anderen ist Cloud-first schneller, günstiger und leistungsfähiger.

Schritt 4 – Vendor-Lock-in aktiv vermeiden. Keine geschäftskritische Logik, die nur mit einem Anbieter funktioniert. Orchestrierung und Business-Regeln bleiben unter eigener Kontrolle. Modelle sind Lieferanten, nicht Partner.