What a multi-agent research pipeline actually costs to run

Kyle turns a research topic into a formatted document. Four agents do the work: a planner breaks the topic into sections and decides whether it needs live sources, a researcher scrapes what it asks for, a writer synthesises the document, and a verifier audits the result against a schema before anything gets delivered.

I had no idea what a single document cost until last week. I could have guessed. Most people building these things do guess, and the guess is usually a total, something like "about a cent", with no sense of which part of the pipeline is responsible for it.

Here are three real runs, recorded with the cost attributed per agent.

Mean cost per document: $0.0099. All three on gemini-3.5-flash-lite.

The writer takes three quarters of everything

Across those runs the split is writer 74.4%, planner 16.3%, verifier 9.4%, researcher 0%.

I had assumed the planner would be expensive, since it does the reasoning, and the writer cheap, since it is mostly transcription. The opposite is true, and the token counts show why. The planner reads a topic and emits a JSON array of headings, maybe 300 tokens out. The writer reads the topic, the outline, and up to 15KB of scraped article text, then emits an entire structured document. It does an order of magnitude more work in both directions.

The practical consequence: any optimisation that does not touch the writer is not worth doing. I could halve the planner's cost and save 8% of a cent. Switching the writer to a cheaper model, or trimming what I feed it, is where the money is.

The researcher costs nothing, which is easy to misread

Zero, in all three runs. That is not a rounding artifact. The researcher does not call a model at all. It runs a search, scrapes three pages, and hands the text back. The only cost it incurs is time.

Adding a research step to an agent pipeline sounds expensive, and people leave it out to save money. In this design it is free. What it costs is 5 to 8 seconds of wall clock, which is most of the difference between the 19 second run and the 30 second one.

It does raise downstream cost, of course. Scraped text goes into the writer's prompt, and the writer is billed on input tokens. The multi-agent run above pulled in more source text than the other two and its writer bill is the highest of the three. So research is free at the point of use and shows up on someone else's line. Per-agent attribution makes that visible; a single total hides it.

Computing cost at emit time, not query time

The number above would be worthless if I calculated it later.

Provider prices change. If I stored token counts and multiplied by current pricing when someone loads a dashboard, then every historical figure would rewrite itself the next time Google adjusts its rates. Last month's cost per document would become whatever this month's prices imply it was, and I would have no way of noticing.

So the cost is computed when the event is emitted, from a pricing table checked into the repo, and the version of that table is recorded on the run:

type PriceRow struct {
	Model         string
	InputPer1M    float64
	OutputPer1M   float64
	EffectiveDate string
	SourceURL     string
}

Every row carries the URL it came from. When I change a price I bump the table version, and old runs keep the number they were actually billed. A test asserts that every model the code can configure has a row, so swapping models without pricing the new one fails the build instead of reporting zero. That earned itself back about four hours later, when I changed a default model and the build caught me.

What the numbers do not cover

These are three runs, not a distribution. A mean of three is a number, not a statistic. The p95 I publish is the nearest-rank value from a tiny sample, and I say so on the page rather than letting it look like a measurement from real traffic.

And they exclude the parts that are not model calls. Redis, the container, the document render, and the upload to storage all cost something. On a free tier that something is zero, which is convenient and temporary. The figure is the marginal model cost of one document, not the fully loaded cost of running the service.

Why bother

Because "roughly a cent" and "$0.0099, of which 74% is the writer" lead to different decisions.

The first tells you the thing is cheap. The second tells you that if you want it cheaper you have exactly one lever, that adding research is free, and that your verifier costs less than a tenth of a cent to run, so there is no financial reason to skip it. All three of those changed what I did next.

The instrumentation took an afternoon. The dashboard is at kyle.firebcorps.online/ops if you want to see the current numbers rather than the ones I recorded for this post.