aSPARK — Blog

Was ein vollständiger Loop kostet: 42 Millionen Tokens, 35 Dollar — und 96 % davon Cache

2026-09-21T00:00:00.000Z

Die erste Frage, die ein Entwickler stellt, wenn er hört, dass sieben Agenten ein Feature durch fünf Phasen tragen, ist nicht „wie gut wird das Ergebnis". Sie lautet: was kostet mich das.

Die übliche Antwort in dieser Produktkategorie ist Schweigen. Also hier die Zahl, gemessen statt geschätzt.

Der Fall

todo-filter-bar — eine Filterleiste für eine Todo-App, gebaut am 19. September 2026 in einem Durchlauf. Von /spark mit einem Satz Feature-Idee bis v0.1.0 released. Alle fünf Phasen, sieben Rollen-Agenten, 29 Acceptance Criteria, QA im echten Browser auf Desktop und bei 375 px. 47 Minuten, fünf Gates, an jedem eine menschliche Entscheidung.

Es ist dieselbe Session, aus der das Demo-Video geschnitten ist.

Das Ergebnis


Tokens gesamt	42.307.448
Zu API-Listenpreisen (Opus 5)	35,52 $
Dieselbe Arbeit ohne Prompt-Caching	217,37 $
Ersparnis durch Caching	181,85 $ — 83,7 %

Die erste Zahl ist die, bei der man erschrickt. Die letzte ist die, auf die es ankommt.

Warum 42 Millionen Tokens die falsche Größe sind

Von den 42,31 Millionen Tokens sind 40,76 Millionen Cache-Reads — 96,3 %.

Frischer Input über den gesamten Loop: 960 Tokens. Output: 291.732.

Ein gegateter Loop liest denselben Kontext immer wieder. Die Spec, die beim Planen vorliegt. Der Plan, den der Reviewer gegen den Diff hält. Die Acceptance Criteria, die QA einzeln abhakt. Genau diese Form von Arbeitslast ist der Fall, für den Prompt-Caching gebaut wurde — und deshalb kostet das Wiederlesen ein Zehntel des ersten Lesens.

Wer die Bruttozahl zitiert, misst die Datenmenge. Wer die Rechnung aufmacht, misst die Kosten. Das ist nicht dasselbe.

Aufschlüsselung nach Rolle

Rolle	Output	Cache-Read	Cache-Write	Kosten
Hauptsession (Orchestrator + Gates)	145.113	29.697.805	411.863	21,05 $
QA-Tester	38.576	7.365.329	281.134	6,41 $
Reviewer	25.416	1.787.327	161.016	2,54 $
Product Owner	39.135	682.356	128.610	2,12 $
Release Manager	16.023	980.193	103.122	1,54 $
Engineering Manager	16.846	178.398	82.279	1,02 $
Designer	10.623	69.156	86.168	0,84 $

Zwei Dinge fallen auf.

Die Hauptsession trägt 59 Prozent. Sie ist kein Agent, sondern der Orchestrator: Sie hält den Kontext über alle 47 Minuten, führt jedes Gate und spricht mit Ihnen. Die spezialisierten Rollen laufen als Subagenten mit eigenem, kürzerem Kontext — sie bekommen, was sie brauchen, und nicht die ganze Sitzung. Das ist der Grund, warum sechs Agenten zusammen weniger kosten als der eine Faden, der sie zusammenhält.

Der QA-Tester ist der teuerste Einzelagent. Das passt zur Sache: Er ist der Einzige, der tatsächlich einen Browser bedient — 29 Kriterien, per Maus und per Tastatur, einmal auf Desktop und einmal in einem 375 Pixel breiten Rahmen, dazu ein Durchlauf mit hundert Todos. Prüfen ist teurer als planen. Das sollte es auch sein.

Wie gerechnet wurde

Nicht aus dem Bauch und nicht aus einer Statusanzeige. Die Zahlen stammen aus den usage-Feldern der Claude-Code-Transkripte dieser Session: alle Assistant-Nachrichten der Hauptsitzung plus die zwölf Subagenten-Transkripte. Die Zuordnung zu den Rollen kommt aus den agentType-Feldern der zugehörigen Metadaten, nicht aus einer Zuordnung von Hand.

Preise, Stand heute, claude-opus-5, API-Liste:

	pro 1 Mio. Tokens
Input	5,00 $
Output	25,00 $
Cache-Read	0,50 $
Cache-Write, 5-Minuten-TTL	6,25 $
Cache-Write, 1-Stunden-TTL	10,00 $

Der Anteil der beiden TTLs ist nicht angenommen, sondern aus usage.cache_creation gelesen: 842.329 Tokens auf fünf Minuten, 411.863 auf eine Stunde.

Was diese Zahl nicht sagt

Ohne diesen Abschnitt wäre der Rest unredlich.

Es sind Listenpreise. Die Session lief über Claude Code. Wer ein Abonnement hat, hat diese 35,52 $ nicht bezahlt. Die Zahl beantwortet eine andere Frage: Was kostet diese Arbeitslast, wenn man sie zu API-Preisen abrechnet? Das ist die Vergleichsgröße für jemanden, der aSPARK gegen eine Alternative hält — nicht Ihre Abrechnung.

Es ist ein Modell. Opus 5. Mit einem günstigeren Modell sieht die Rechnung anders aus, und die Frage, ob das Ergebnis dann noch durch dieselben Gates kommt, ist offen.

Es ist ein Messpunkt. Ein Feature, eine kleine Anwendung, ein Projekt. Daraus einen Durchschnitt zu machen wäre genau die Sorte Verallgemeinerung, die dieses Projekt an anderer Stelle vermeidet. Ein zweiter Durchlauf auf einem größeren Feature wäre ehrlicher als dieser eine, hochgerechnet.

Die 47 Minuten sind nicht 47 Minuten Modellzeit. An fünf Gates hat ein Mensch gelesen und entschieden. Diese Zeit steht in der Uhr, aber nicht in der Rechnung.

Warum das hier steht

Weil niemand sonst diese Zahl nennt, und weil eine Software, die ihren Wert aus Nachprüfbarkeit zieht, bei der eigenen Kostenfrage nicht ausweichen darf.

Die Rechnung ist aus den Transkripten reproduzierbar. Wenn Sie aSPARK laufen lassen, können Sie Ihre eigene aufmachen — und wenn sie deutlich anders ausfällt, ist das ein Ergebnis, das uns mehr wert ist als dieses hier.

Der erste Durchlauf: mit /charter anfangen, nicht mit dem Feature

2026-09-20T00:00:00.000Z

aSPARK ist seit v0.11.0 an einer Stelle deutlich einfacher geworden: Es gibt jetzt einen klaren Startpunkt. Wer früher mit /spark oder /next-steps auf einem Projekt ohne Constitution begann, wurde von beiden auf das jeweils andere verwiesen. Heute führen beide zuerst zu /charter — und /charter weiß, was zu tun ist, egal ob das Repository leer ist oder seit zwei Jahren wächst.

Installation: zwei Befehle

In einer laufenden claude-Sitzung:

/plugin marketplace add a-lottes/aSPARK
/plugin install aspark@aspark

Danach Claude Code neu starten, denn Plugins werden erst nach einem Neustart aktiv. Ein /plugin zeigt anschließend aspark als installiert und aktiviert. Es gibt keinen Dienst, kein Konto und keine Datenbank — aSPARK ist Markdown, das in Ihrem Repository arbeitet.

Schritt 1: /charter, einmal pro Projekt

/charter schreibt die Constitution: die stehenden Regeln, die jede Phase jedes Features erbt. Das Ceremony verhält sich unterschiedlich, je nachdem was es vorfindet.

Auf einem leeren Repository stellt es eine kurze Reihe harter Produktfragen. Für wen ist das? Was tun diese Menschen heute ohne Ihr Produkt? Was ist die kleinste Version, die schon hilft? Woran merken Sie, dass es funktioniert? Welcher Stack, welche harten Einschränkungen? Am Ende steht ein Vorschlag für die Constitution und für den ersten Schnitt — beides zur Freigabe, nichts läuft ungefragt los.

Auf einem Projekt mit Code liest es stattdessen, was schon da ist: README, ein vorhandenes CLAUDE.md, bestehende Specs. Daraus entsteht ein begrenzter Projektüberblick — Zielgruppe, Stack, wie man es startet, Konventionen, bekannte Schwachstellen — den Sie einmal korrigieren. Danach müssen Product Owner und Engineering Manager das System nicht bei jedem Feature neu herleiten.

Drei Angaben lohnen besondere Aufmerksamkeit, weil sie den Rest des Loops prägen:

Projekttyp und Merkmale. Daraus ergeben sich die aktiven Lenses. Ein öffentlicher website bekommt SEO-Checks, eine api bekommt Fehler-Envelope und Versionierung, ein Projekt mit Zahlungsverkehr bekommt die Security-Lens durch alle Phasen. Wichtig: Ohne Constitution ist keine Lens aktiv. Die Constitution ist die einzige Stelle, an der eine Lens eingeschaltet wird.
Qualitätslatte. Was in §4 steht, muss keine Spec mehr wiederholen. Gibt es kein Testframework und soll auch keines entstehen, schreiben Sie das hin — dann baut niemand eines.
QA-Methode. Hat Ihr Projekt keine Oberfläche, die ein Browser bedienen kann, deklarieren Sie hier die Ersatzmethode. Sonst fragt jedes Feature erneut danach.

Schritt 2: das erste Feature

Entweder Phase für Phase oder am Stück:

/spark Eine Filterleiste über der Todo-Liste mit All, Active, Done …

/spark fährt Specify, Plan, Act, Review und Keep und hält an jedem Gate an. Sie sehen jeweils das Artefakt und entscheiden. Das ist kein Formalismus, sondern der Punkt der Übung: Die Agenten entwerfen, prüfen und empfehlen — freigegeben wird von Ihnen.

Was an den Gates wirklich zur Entscheidung steht:

Gate	Ihre Frage
Spec	Ist das das richtige Feature, und sind die Kriterien prüfbar?
Plan	Trägt der Ansatz? Hier ist Ablehnen noch billig, danach steht Code.
Review	Findings verstanden: jetzt beheben, oder bewusst annehmen?
QA	Wurde jedes Akzeptanzkriterium wirklich verifiziert?
Release	Geht das raus? Ohne Ihr ausdrückliches Ja passiert nichts.

Zwischendurch bietet /spark nach schweren Phasen an, /clear zu machen und wieder einzusteigen. Nehmen Sie das an. Die Artefakte auf der Platte sind der Zustand; ein frischer Kontext nimmt den Loop genau dort wieder auf, ohne alles mitzuschleppen, was die letzte Phase gelesen hat.

Schritt 3: optional erweitern

Core läuft allein vollständig. Zwei Erweiterungen greifen in den Loop ein, wenn Sie sie installieren:

/plugin install aspark-guard@aspark

aspark-guard verlegt die Gates aus dem Prompt in eine Prüfung außerhalb des Modells und führt ein Hash-Ledger über jeden Schreibvorgang unter .spark/. aspark-graph (pip install aspark-graph) grenzt Plan, Review und QA auf die Dateien ein, um die es geht. Fehlen beide, verhält sich der Loop exakt wie beschrieben — kein Fehler, keine Warnung.

Was Sie nach der ersten Stunde haben

Ein Feature, das durch fünf Gates gegangen ist, und einen Ordner .spark/, den Sie lesen, diffen und committen können: Spec mit Stories und Akzeptanzkriterien, Plan mit Tasks, Review mit Findings, QA-Bericht mit jedem geprüften Kriterium, Release-Notiz mit den Lehren.

Und eine Constitution, die Sie nie wieder erklären müssen.

Wie so ein Durchlauf in der Praxis aussieht, zeigt das Demo-Video auf der Startseite: 47 Minuten echte Session, auf 100 Sekunden geschnitten.

Die Idee formulieren, nicht das Ticket: wie das Spec-Gate kurz bleibt

2026-09-20T00:00:00.000Z

Der Product Owner in aSPARK ist absichtlich kein Ja-Sager. Nach dem ersten Entwurf läuft ein Clarify-Durchgang, der die Spec gegen eine feste Taxonomie prüft: funktionale Grenzen, Daten, Berechtigungen, Fehler- und Randfälle, nicht-funktionale Anforderungen, Integrationen, UX-Zustände, Out of Scope. Alles, was dort offen ist, kommt als Frage zurück.

Das ist gut so. Genau diese Fragen sind der Grund, warum ein Feature hinterher stimmt. Aber Sie entscheiden mit der Formulierung Ihrer Idee, welche dieser Fragen gestellt werden — die interessanten oder die offensichtlichen.

Das Muster

Eine gute Idee für /story-time oder /spark beantwortet im Vorbeigehen, was ohnehin gefragt würde, und lässt genau das offen, wo Sie eine Meinung hören wollen. Fünf Dinge lohnen sich fast immer:

Das sichtbare Verhalten, nicht die Umsetzung. Was sieht und tut die Nutzerin? Technische Entscheidungen gehören in den Plan, nicht in die Spec.
Die Zustände am Rand. Was steht da, wenn nichts da ist? Was passiert beim ersten Mal, beim letzten Element, bei 100 Einträgen?
Tastatur und Fokus, sobald es eine Oberfläche gibt. Das ist die Frage, die sonst garantiert zurückkommt.
Die Zahl oder Form, an der man es messen kann. "Zeigt an, wie viele offen sind" ist schwächer als "zeigt N items left, Singular 1 item left".
Out of Scope, ausdrücklich. Ein Satz, der sagt, was nicht dazugehört, spart im Review eine Diskussion und im Plan einen Umweg.

Ein echtes Beispiel

Das Feature aus unserem Demo-Video startete mit genau einem Satz:

Add a filter bar above the todo list with three toggle buttons — All, Active, Done — and a counter that reads "N items left" (singular "1 item left"), counting only active todos. Exactly one filter is selected at a time and is visually marked as selected; All is the default. The list shows only todos matching the selected filter; the counter is independent of the filter. Each filter has its own empty message: "Nothing to do — nice." for Active, "Nothing done yet." for Done; the existing "Nothing here yet" message stays for All. Buttons are real <button> elements, operable by keyboard, with the selected one exposed via aria-pressed. Out of scope: persisting the selected filter across reloads, URL routing, editing todos, animations, and any new dependency or file.

Darin steckt jeder der fünf Punkte: sichtbares Verhalten, drei benannte Leerzustände, Tastaturbedienung, ein prüfbarer Zählertext und eine ausdrückliche Abgrenzung.

Der Product Owner hat trotzdem nachgehakt — und zwar dort, wo es sich lohnte. Eine der Fragen: Wenn jemand per Tastatur unter Active ein Todo abhakt, verschwindet die Zeile sofort aus der Liste. Wohin geht dann der Fokus? Darauf hatte ich keine Antwort parat, und sie ist als Akzeptanzkriterium in die Spec gewandert. Genau dieses Detail hat der Reviewer später wieder aufgegriffen, als der Fokusrahmen auch nach Mausklicks stehenblieb.

Aus dem einen Satz wurden 3 Stories und 29 Akzeptanzkriterien. Der ganze Loop, von der Idee bis zum Release, dauerte 47 Minuten.

Was das Muster nicht tut

Es macht den Loop nicht kürzer, sondern verschiebt den Aufwand nach vorn. Act, Review und QA dauern so lange wie das Feature groß ist. Und es ersetzt nicht das Nachfragen: Wenn die Clarify-Runde eine Lücke findet, ist das kein Zeichen einer schlechten Idee, sondern der Moment, in dem ein Fehler zwei Stunden früher auffällt als sonst.

Wenn Sie keine Idee haben

Dann formulieren Sie auch keine. /next-steps sichtet den Projektstand — was ausgeliefert ist, was in Arbeit ist, was liegengeblieben ist, was die Constitution vorgibt — und schlägt ein konkretes nächstes Feature vor. Der Vorschlag ist beratend; geschrieben oder freigegeben wird nichts. Was dabei herauskommt, geben Sie dann als Idee an /story-time oder /spark, und zwar am besten so formuliert wie oben.

Warum Determinismus die interessantere Eigenschaft ist als Geschwindigkeit

2026-08-07T00:00:00.000Z

Wenn Codegenerierung nichts mehr kostet, wird nicht das Schreiben zum Engpass, sondern alles, was danach kommt: verstehen, prüfen, belegen. Genau diese drei Schritte setzen voraus, dass gleiche Eingaben auch gleiche Ergebnisse erzeugen.

Was Determinismus hier konkret heißt

Für aSPARK bedeutet Determinismus nicht, dass ein Sprachmodell zweimal denselben Text produziert — das tut es nicht und muss es auch nicht. Deterministisch sind die abgeleiteten Modelle: Zwei Builds eines unveränderten Repositories erzeugen ein byte-identisches graph.json. Dieselbe Zusage gilt für die versiegelten Snapshots von aSPARK-insights.

Das ist ein bewusst enger Anspruch. Er reicht aber aus, um drei Dinge zu ermöglichen:

Vergleichbarkeit. Ein Diff zwischen zwei Snapshots zeigt eine echte Veränderung im Projekt, nicht das Rauschen des Werkzeugs.
Nachvollziehbarkeit. Eine Query-Antwort lässt sich reproduzieren, statt nur geglaubt zu werden.
Prüfbarkeit. Ein Audit kann den Stand nachbauen, statt sich auf eine Momentaufnahme zu verlassen.

Der Preis dafür

Determinismus kostet Ausdrucksstärke. Ein Graph, der raten dürfte, könnte mehr Verbindungen finden. aSPARK-graph rät stattdessen nicht — es markiert schwache Kanten als inferred und meldet Template-Drift laut, statt sie stillschweigend zu überbrücken.

Das ist die richtige Richtung für ein Werkzeug, dessen Antworten in Gate-Entscheidungen einfließen. Eine Graph-Antwort ist eine Karte, nie ein Urteil.

Dieser Beitrag ist die Vorlage für weitere Artikel. Neue Beiträge landen als Markdown-Datei unter src/blog/de/ und erscheinen automatisch in Übersicht und Feed.