aSPARK — Blog

What a full loop costs: 42 million tokens, $35 — and 96% of it cache

2026-09-21T00:00:00.000Z

The first question a developer asks on hearing that seven agents carry one feature through five phases is not "how good is the result". It is: what does this cost me.

The usual answer in this product category is silence. So here is the number, measured rather than estimated.

The case

todo-filter-bar — a filter bar for a todo app, built on 19 September 2026 in a single run. From /spark with a one-sentence feature idea to v0.1.0 released. All five phases, seven role agents, 29 acceptance criteria, QA in a real browser at desktop width and at 375 px. 47 minutes, five gates, a human decision at every one.

It is the same session the demo video is cut from.

The result


Total tokens	42,307,448
At API list prices (Opus 5)	$35.52
The same work without prompt caching	$217.37
Saved by caching	$181.85 — 83.7%

The first number is the one that startles. The last one is the one that matters.

Why 42 million tokens is the wrong measure

Of those 42.31 million tokens, 40.76 million are cache reads — 96.3%.

Fresh input across the entire loop: 960 tokens. Output: 291,732.

A gated loop re-reads the same context constantly. The spec, while the plan is written. The plan, while the reviewer holds it against the diff. The acceptance criteria, ticked off one by one in QA. That shape of workload is exactly what prompt caching was built for — which is why re-reading costs a tenth of reading.

Quote the gross figure and you are measuring data volume. Do the arithmetic and you are measuring cost. They are not the same thing.

Per role

Role	Output	Cache read	Cache write	Cost
Main session (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

Two things stand out.

The main session carries 59%. It is not an agent but the orchestrator: it holds context across all 47 minutes, runs every gate and talks to you. The specialised roles run as subagents with their own, shorter context — they get what they need, not the whole sitting. That is why six agents together cost less than the single thread holding them.

The QA Tester is the most expensive individual agent. Which fits: it is the only one actually driving a browser — 29 criteria, by mouse and by keyboard, once at desktop width and once inside a 375-pixel frame, plus a run with a hundred todos. Checking costs more than planning. It should.

How it was calculated

Not from a gut feeling and not from a status line. The numbers come from the usage fields in this session's Claude Code transcripts: every assistant message in the main session plus the twelve subagent transcripts. Roles are attributed from the agentType field in the matching metadata, not assigned by hand.

Prices as of today, claude-opus-5, API list:

	per 1M tokens
Input	$5.00
Output	$25.00
Cache read	$0.50
Cache write, 5-minute TTL	$6.25
Cache write, 1-hour TTL	$10.00

The split between the two TTLs is not assumed but read from usage.cache_creation: 842,329 tokens at five minutes, 411,863 at one hour.

What this number does not say

Without this section the rest would be dishonest.

These are list prices. The session ran through Claude Code. On a subscription, nobody paid that $35.52. The figure answers a different question: what does this workload cost when billed at API rates? That is the comparison figure for someone weighing aSPARK against an alternative — not your invoice.

It is one model. Opus 5. On a cheaper model the arithmetic changes, and whether the result still passes the same gates is an open question.

It is one data point. One feature, one small application, one project. Turning it into an average would be exactly the kind of generalisation this project avoids elsewhere. A second run on a larger feature would be more honest than this one, extrapolated.

The 47 minutes are not 47 minutes of model time. At five gates a human read and decided. That time is on the clock but not on the bill.

Why this is published

Because nobody else states this number, and because software that draws its value from being checkable cannot dodge the question of its own cost.

The calculation is reproducible from the transcripts. Run aSPARK and you can do your own — and if it comes out substantially different, that result is worth more to us than this one.

Your first loop: start with /charter, not with the feature

2026-09-20T00:00:00.000Z

Since v0.11.0, aSPARK has one clear starting point. Running /spark or /next-steps on a project without a constitution used to leave you between the two — each behaved as if the other had already set things up. Today both point to /charter first, and /charter knows what to do whether the repository is empty or has been growing for two years.

Install: two commands

In a running claude session:

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

Then restart Claude Code — plugins only activate after a restart. A /plugin afterwards lists aspark as installed and enabled. There is no service, no account and no database: aSPARK is Markdown that works inside your repository.

Step 1: /charter, once per project

/charter writes the constitution: the standing rules every phase of every feature inherits. The ceremony behaves differently depending on what it finds.

On an empty repository it asks a short set of hard product questions. Who is this for? What do those people do today without it? What is the smallest version that would already help? How will you know it is working? Which stack, which hard constraints? It ends with a proposed constitution and a proposed first slice — both offered for your go, nothing starts unasked.

On a project that already has code it reads what is there instead: the README, an existing CLAUDE.md, existing specs. Out of that comes a bounded project picture — who it is for, the stack, how to run it, conventions, known pain points — which you correct once. After that, the Product Owner and Engineering Manager no longer re-derive the system on every feature.

Three entries deserve particular attention, because they shape the rest of the loop:

Project type and characteristics. These decide which lenses are active. A public website gets SEO checks, an api gets error-envelope and versioning checks, a project that handles payments gets the security lens through every phase. Important: without a constitution, no lens is active. The constitution is the only place a lens is switched on.
Quality bar. Whatever sits in §4 no spec has to repeat. If there is no test framework and none should appear, write that down — then nobody builds one.
QA method. If your project has no surface a browser can drive, declare the substitute method here. Otherwise every feature asks again.

Step 2: the first feature

Either phase by phase, or in one go:

/spark A filter bar above the todo list with All, Active, Done …

/spark runs Specify, Plan, Act, Review and Keep, stopping at every gate. You see the artifact and decide. That is not ceremony for its own sake — it is the point: the agents draft, check and recommend; approval is yours.

What is actually on the table at each gate:

Gate	Your question
Spec	Is this the right feature, and are the criteria testable?
Plan	Does the approach hold? Rejecting is still cheap here; after this, code exists.
Review	Findings understood: fix now, or knowingly accept?
QA	Was every acceptance criterion actually verified?
Release	Does this ship? Nothing happens without your explicit yes.

After heavy phases, /spark offers you a /clear and a fresh start. Take it. The artifacts on disk are the state; a fresh context resumes the loop exactly where it stood, without carrying everything the last phase read.

Step 3: extend, optionally

Core is complete on its own. Two extensions hook into the loop if you install them:

/plugin install aspark-guard@aspark

aspark-guard moves the gates out of the prompt into a check that runs outside the model, and keeps a hash ledger of every write under .spark/. aspark-graph (pip install aspark-graph) scopes plan, review and QA to the files that are actually involved. Without either, the loop behaves exactly as described — no error, no warning.

What you have after the first hour

A feature that has passed five gates, and a .spark/ folder you can read, diff and commit: a spec with stories and acceptance criteria, a plan with tasks, a review with findings, a QA report with every criterion checked, and a release note with what was learned.

Plus a constitution you never have to explain again.

What such a run looks like in practice is in the demo video on the home page: 47 minutes of a real session, cut to 100 seconds.

Write the idea, not the ticket: keeping the Specify gate short

2026-09-20T00:00:00.000Z

aSPARK's Product Owner is deliberately not a yes-man. After the first draft it runs a clarify pass that checks the spec against a fixed taxonomy: functional boundaries, data, permissions, error and edge cases, non-functional requirements, integrations, UX states, out of scope. Anything left open comes back as a question.

That is the point. Those questions are the reason the feature is right afterwards. But how you word your idea decides which of them get asked — the interesting ones, or the obvious ones.

The pattern

A good idea for /story-time or /spark answers in passing what would be asked anyway, and leaves open exactly where you want an opinion. Five things nearly always pay off:

The visible behaviour, not the implementation. What does the user see and do? Technical decisions belong in the plan, not in the spec.
The states at the edges. What does it say when there is nothing? What happens on the first item, the last one, with a hundred of them?
Keyboard and focus, as soon as there is a UI. This is the question that otherwise comes back, guaranteed.
A number or form you can check against. "Shows how many are open" is weaker than "shows N items left, singular 1 item left".
Out of scope, explicitly. One sentence about what does not belong saves a discussion in review and a detour in the plan.

A real example

The feature in our demo video started as exactly one sentence:

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.

Every one of the five points is in there: visible behaviour, three named empty states, keyboard operation, a checkable counter string, and an explicit boundary.

The Product Owner still pushed back — where it was worth it. One of its questions: when someone ticks a todo with the keyboard under Active, the row leaves the list immediately. Where does focus go then? I had no answer ready, and the answer became an acceptance criterion. That same detail came back later, when the Reviewer found that the focus ring also stayed after mouse clicks.

That one sentence became 3 stories and 29 acceptance criteria. The whole loop, idea to release, took 47 minutes.

What the pattern does not do

It does not shorten the loop; it moves the effort forward. Act, Review and QA take as long as the feature is big. And it does not replace the questions: when the clarify pass finds a gap, that is not a sign of a bad idea — it is the moment a mistake surfaces two hours earlier than it otherwise would.

When you have no idea

Then do not invent one. /next-steps surveys the project's current state — what shipped, what is in flight, what stalled, what the constitution requires — and proposes one concrete next feature. The proposal is advisory; nothing is written or approved. Whatever comes out of it you then hand to /story-time or /spark as your idea, ideally worded like the one above.

Why determinism is the more interesting property than speed

2026-08-07T00:00:00.000Z

When generating code costs nothing, writing is no longer the bottleneck — everything after it is: understanding, checking, proving. All three presuppose that identical inputs produce identical results.

What determinism means here, concretely

For aSPARK, determinism does not mean a language model produces the same text twice — it doesn't, and it doesn't need to. What is deterministic are the derived models: two builds of an unchanged repository produce a byte-identical graph.json. The same commitment holds for the sealed snapshots in aSPARK-insights.

That is a deliberately narrow claim. It is enough to enable three things:

Comparability. A diff between two snapshots shows a real change in the project, not tooling noise.
Traceability. A query answer can be reproduced instead of merely believed.
Auditability. An audit can rebuild the state instead of relying on a snapshot in time.

What it costs

Determinism costs expressiveness. A graph allowed to guess could find more connections. aspark-graph does not guess — it tags weak edges as inferred and fails loudly on template drift instead of quietly bridging it.

That is the right trade for a tool whose answers feed gate decisions. A graph answer is a map, never a verdict.

This post is the template for further articles. New posts go in as a Markdown file under src/blog/en/ and appear in the index and feed automatically.