$187 und 16 Stunden: Meine erste Million-Token-Session

Zwei Dinge kamen in derselben Woche zusammen: das 1-Million-Token-Kontextfenster und die Claude Agentic Teams Beta. Eines gab mir Raum zum Denken. Das andere gab mir eine Möglichkeit zur Parallelisierung. Ich hab das gemacht, was jeder vernünftige Ingenieur gemacht hätte: sofort versucht, beides mit einem zu ambitionierten Plan zu überlasten.

Der Plan: eine vollständige Cashback-Kampagnen-Web-App bauen — Backend, Frontend, komplette Testsuite, containerisiertes Deployment — in einer einzigen Session. Ein Orchestrator. Acht spezialisierte Agenten als Team. Nicht aufhören, bis sie live ist.

Was tatsächlich passiert ist, ist interessanter als die Erfolge und die Fehler je für sich.

Das Setup

Das Agentic Teams Feature war der entscheidende Enabler. Statt einem Agenten, der alles sequenziell abarbeitet, hatte ich einen Orchestrator, der spezialisierte Subagenten startete — jeder mit eigenem frischen Kontextfenster, jeder auf eine Domäne fokussiert:

1. Backend-Implementierer — Spring Boot Service, API-Endpunkte, Geschäftslogik
2. Frontend-Implementierer — React SPA, ans Backend angebunden
3. QA-Reviewer — Tests ausführen, Lücken aufzeigen, Coverage prüfen
4. Deployment-Agent — Dockerfile, Compose-Dateien, Deployment-Konfiguration
5. Git-Agent — Branches, Commits, Repo sauber halten
6. PR-Handler — Pull-Request-Erstellung, Beschreibungen, Reviewer zuweisen
7. CI-Monitor — Pipeline beobachten, Fehler früh erkennen
8. Slack-Notifier — Statusupdates in den Team-Channel

Die Kombination aus 1M Kontext und Teams hat das Spiel grundlegend verändert. Der Orchestrator hielt das große Bild — Architektur, Entscheidungen, Koordination — während jeder Subagent ein frisches Fenster bekam, das ganz seiner Domäne gehörte. Kein Kontext-Rauschen zwischen den Bereichen. Das Fenster des Backend-Implementierers war nicht mit CSS-Entscheidungen vollgestopft. Der Deployment-Agent hat nicht den ganzen Test-Output mitgetragen.

Das ist kein größerer Notizblock. Das ist eine grundlegend andere Art zu arbeiten.

Die Zahlen

Erst die Quittung, dann die Geschichte.

Kennzahl	Wert
Gesamtkosten	$186,92
Wanduhrzeit	16 Stunden
API-Zeit	7 Stunden 42 Minuten
Geschriebene Code-Zeilen	5.800+
Backend-Tests	649 (alle grün)
End-to-End-Tests	80 (alle grün)
Orchestrator-Kontext bei Abschluss	34,8 % genutzt

Die Lücke zwischen Wanduhrzeit und API-Zeit erzählt ihre eigene Geschichte. Rund neun Stunden Warten — auf Builds, auf hochfahrende Container, auf CI-Pipelines, auf mein Reviewen und Umleiten. Das System war mehr als die Hälfte der Uhrzeit im Leerlauf. Multi-Agenten-Arbeit dreht sich oft mehr um das Management von Parallelität und Wartezuständen als um rohen Token-Durchsatz.

Die Kontext-Zahl braucht eine Erklärung: 34,8 % ist die Auslastung des Orchestrators — des zentralen Agenten, der alles koordiniert. Aber das ist der Witz an Agentic Teams: Jeder Subagent startet mit eigenem frischen Kontextfenster. Der Backend-Implementierer hat den Großteil seines Fensters genutzt, um 3.000+ Zeilen Spring Boot Code zu schreiben. Der Frontend-Implementierer hat ein separates Fenster mit React-Komponenten gefüllt. Die gesamten verbrauchten Tokens über alle Agenten hinweg waren ein Vielfaches dessen, was der Orchestrator allein genutzt hat.

Das 1M-Fenster war entscheidend dafür, dass der Orchestrator den vollständigen Projektstatus halten konnte — jede Architekturentscheidung, den Status jedes Agenten, jeden Fehler und jede Behebung — ohne jemals Nuancen durch Zusammenfassungen zu verlieren. Die Subagenten profitierten von einem frischen Fenster, das ganz ihrer Domäne gehörte.

Was wir gebaut haben

Eine Cashback-Kampagnen-Web-App. Nutzer registrieren sich für Kampagnen, reichen Kaufbelege ein und bekommen Cashback ausgezahlt. Das Backend stellt REST-Endpunkte mit vollständiger Authentifizierung, Kampagnenverwaltung, Einreichungsverarbeitung und Auszahlungslogik bereit. Das Frontend begleitet die User Journey: Kampagnenliste, Einreichungsformular, Statusanzeige, Kontoverwaltung.

649 Backend-Tests für Units, Integration und API-Contracts. 80 End-to-End-Tests, die vollständige User Flows gegen das deployete System durchlaufen. Beide Suites waren beim Deployment grün.

Containerisiert mit Docker, auf einem Demo-Server deployed, über HTTPS erreichbar. Der vollständige Stack war live — nicht Prototyp-live oder Local-Dev-live, sondern wirklich deployed und laufend mit einer URL, die man teilen konnte.

In einer Session.

Was kaputt ging

Drei Dinge sind auf eine Art schiefgelaufen, die es wert sind, dokumentiert zu werden.

Der UI-Refiner-Agent hat sich mid-Session aufgehangen. Nach ungefähr zehn Stunden hab ich einen zusätzlichen Agenten gestartet, um das Frontend-Styling zu polieren. Er hat angefangen zu arbeiten, dann keinen Output mehr produziert, dann wieder angefangen, dann dauerhaft aufgehört. Der Prozess lief noch — hat Tokens verbraucht, nichts Sinnvolles geliefert. Ich musste ihn abwürgen und seine verbleibenden Aufgaben an den Frontend-Implementierer umleiten. Ursache: unklar. Hypothese: Der Kontext hatte genug mehrdeutiges Signal angehäuft, dass der Agent in ein lokales Minimum geraten war und ohne menschlichen Eingriff nicht herausgekommen wäre. Dieses Verhalten kannte ich schon aus kürzeren Sessions. In diesem Maßstab hat es mehr Zeit gekostet. (Einen vollständigen Postmortem dazu und zu drei weiteren Multi-Agenten-Fehlern hab ich in Der Agent, der festhieng geschrieben.)

Die Docker-Konfiguration brauchte mehrere Debug-Zyklen. Die ersten drei Dockerfile-Versuche des Deployment-Agenten haben Images produziert, die erfolgreich gebaut haben und dann zur Laufzeit fehlgeschlagen sind. Jedes Mal mit einem anderen Fehlermodus: falscher Umgebungsvariablenname, fehlender Health-Check-Endpunkt, falscher Volume-Mount-Pfad. Nichts davon war ein schwieriges Problem — die Art, die zehn Minuten braucht zum Fixen, sobald man weiß, was los ist. Aber jeder Zyklus war 15–20 Minuten Build-Zeit, das summiert sich. Der Agent hat nicht systematisch falsch gelegen — sondern zufällig, was schwieriger zu diagnostizieren ist.

CORS-Whitelisting fehlte beim ersten Live-Deployment. Backend deployed, Frontend deployed, erste echte URL im Browser aufgerufen — CORS-Fehler. Frontend und Backend lagen auf unterschiedlichen Origins, und niemand hatte die erlaubten Origins in der API konfiguriert. Im Nachhinein offensichtlich. Wenn man gerade an allem anderen denkt, unsichtbar. In zwanzig Minuten gefixt — aber die Lücke zwischen „funktioniert in Tests” und „funktioniert wenn man wirklich einen Browser aufmacht” ist real und sollte nicht heruntergespielt werden.

Die Fehler waren behebbar. Nichts davon war katastrophal. Aber es lohnt sich, sie zu benennen, weil die Erzählung „Multi-Agenten-KI baut komplette App in einer Session” leicht glatter klingt, als sie ist.

War $187 es wert?

Die Frage, die alle stellen.

$186,92 für eine vollständige, deployete, getestete Web-App. Die Frage ist: verglichen womit?

Meine Einschätzung für Solo-Entwicklung desselben Systems — Abende und Wochenenden, der realistische Modus für ein Nebenprojekt — liegt bei zwei bis drei Wochen. Das sind 40–60 Stunden tatsächlicher Coding-Zeit, verteilt über einen Monat Kalender. Durch mehr anstrengen geht es nicht schneller; durch mehr verfügbare Stunden schon.

Die Session hat das auf einen langen Abend komprimiert — angefangen am 17., durchgelaufen in die frühen Stunden des 18. Nicht nur in Wanduhrzeit, sondern im Kontext. Wenn man über drei Wochen Abende arbeitet, verbringt man einen nicht kleinen Teil jeder Session damit, Kontext wiederherzustellen. Was hab ich letztes Mal gebaut? Wo hab ich aufgehört? Warum hab ich diese Architekturentscheidung getroffen? Das 1M-Kontextfenster hat das verhindert. Jeder Agent hatte jederzeit Zugriff auf den vollständigen Projektstatus.

Diese Kontextkontinuität ist der eigentliche Wert. Die $187 zahlen nicht für Code-Generierung — die bekommt man günstig. Sie zahlen für ununterbrochene Kontinuität über ein gesamtes Projekt, vom leeren Repository bis zur deployeten Anwendung.

Ist $187 viel? Das ist ein Abendessen. Weniger als eine Stunde Beratungszeit. Für das, was es produziert hat, ist es lächerlich günstig — wenn der Output brauchbar ist. In diesem Fall war er brauchbar.

Die ROI-Frage wird schwieriger, wenn du fragst: „Okay, aber ich zahle $187 pro Feature — wie skaliert das?” Fair. Wer solche Sessions wöchentlich fährt, gibt $800–1.000 im Monat für Kontext aus. Das ist nicht nichts. Aber man komprimiert auch wochenlange Arbeit in Tage — und der Vergleichsmaßstab sollte „was würde ich einem Auftragnehmer zahlen” sein, nicht „was zahle ich für Rechenleistung”.

Was 1 Million Tokens wirklich verändert

Das Marketing rund um große Kontextfenster ist oft so vage, dass es den echten Wert verschleiert. Ich will konkret sein.

Es geht nicht darum, mehr Dateien hineinzupacken. Man konnte schon immer mehr Dateien über mehrere Sessions laden. Der Punkt ist nicht die Speicherkapazität.

Es geht darum, dass der Orchestrator das vollständige Bild hält. Das 1M-Fenster erlaubt dem koordinierenden Agenten, jede Entscheidung, jeden Fehler, jede Architekturwahl über eine 16-stündige Session zu tracken — ohne jemals zusammenzufassen oder Nuancen zu verlieren. Wenn der Backend-Agent eine Schema-Änderung meldet, gibt der Orchestrator diesen Kontext akkurat an den Frontend-Agenten weiter — nicht als verlustbehaftete Zusammenfassung, sondern als die tatsächliche Entscheidung mit vollständiger Begründung.

Teams multiplizieren den effektiven Kontext. Acht Agenten mit je eigenem Kontextfenster bedeuten, dass der gesamte Arbeitsspeicher des Systems weit größer als 1M Tokens ist. Jeder Spezialist bekommt ein frisches Fenster für seine Domäne. Das 1M-Fenster des Orchestrators koordiniert zwischen ihnen. Das ist nicht ein großer Kontext — das ist eine Architektur von Kontexten.

Es eliminiert die Zusammenfassungs-Steuer auf der Koordinationsebene. Kürzere Orchestrator-Fenster bedeuten ständiges Zusammenfassen: „hier ist, was ich gebaut habe, hier ist der aktuelle Stand, hier ist, was fehlschlägt.” Jede Zusammenfassung bedeutet Verlust. Mit 1M Tokens auf dem Orchestrator war alles, was über alle acht Agenten passiert ist, noch verfolgbar. Keine verlustbehafteten Übergaben.

Es macht Fehler ohne Neustart behebbar. Als der hängende UI-Agent abgebrochen werden musste, hatte der Orchestrator noch den vollständigen Kontext von dem, was er versucht hatte. Einen Ersatz-Agenten mit den richtigen Anweisungen zu starten war unkompliziert — der Orchestrator wusste genau, wo die Arbeit stehengeblieben war.

Deshalb hab ich es als eine andere Art beschrieben, Software zu bauen. Nicht eine größere Version der alten Art. Ein anderer Modus, der verfügbar wird, wenn man einen großen Orchestrator-Kontext mit spezialisierten parallelen Agenten kombiniert.

Was ich anders machen würde

Ehrlich gesagt nicht viel — aber ein paar Dinge.

CORS-Konfiguration von Anfang an auf einer Deployment-Checkliste. Nicht weil es schwer nachzutragen ist, sondern weil es zuverlässig vergessen wird und Zeit kostet. Das Muster ist konsistent genug, dass es fest im Kopf sein sollte.

Explizite Agent-Health-Checks einbauen. Der hängende UI-Agent lief über eine Stunde, bevor ich gemerkt hab, dass er nichts Nützliches produziert. Eine einfache Regel — „wenn in X Minuten kein sinnvoller Output, zur menschlichen Prüfung markieren” — hätte ihn früher erwischt.

Die Frontend-Arbeit von Anfang an aggressiver aufteilen. Im Maßstab einer vollständigen App hatte der Frontend-Implementierer viel zu tragen. UI-Komponenten und Datenintegration von Beginn an zu trennen hätte mehr Parallelisierung ermöglicht.

Der Meta-Punkt

Ich hab das im Februar 2026 gemacht. Das 1M-Token-Kontextfenster war neu. Die Agentic Teams Beta war neu. Die Multi-Agenten-Orchestrierungsmuster — die hatte ich seit Monaten aufgebaut. Alles kam auf einmal zusammen.

Was mich am meisten beeindruckt hat, war nicht das Ergebnis — sondern die Erfahrung des Bauens. Sechzehn Stunden lang hab ich nicht getippt. Keinen Code geschrieben. Ich hab Entscheidungen getroffen, Outputs reviewed, Agenten umgeleitet, über Architektur nachgedacht. Die Implementierung war geregelt. Das Denken war meins.

Das ist der Modus, auf den Agentic Engineering meiner Meinung nach zusteuert: nicht „KI schreibt meinen Code”, sondern „ich entwerfe die Architektur, während KI implementiert — kontinuierlich, in Echtzeit”. Es waren keine sechzehn Stunden Fortschrittsbalken beobachten. Es waren sechzehn Stunden gerichteter kreativer Arbeit auf einem Abstraktionsniveau über dem Code.

Ob das aufregend oder beunruhigend ist, hängt davon ab, wo du stehst. Für mich ist es beides — und das ist meistens ein Zeichen dafür, dass etwas Echtes passiert.

Die $187 waren gut investiert. Die sechzehn Stunden haben mich mehr über Multi-Agenten-Systemdesign gelehrt als jedes Tutorial. Die Quittung ist direkt im API-Abrechnungs-Dashboard.

Jetzt weiß ich, wie sich eine Million Tokens von innen anfühlen. (Was ich danach gelernt hab — diese Systeme produktionsreif zu machen — ist in Production Hardening beschrieben.)