Quick conclusion
I ran nine different articles through the same pipeline in three different shapes: one after another, three at once, and three inside a single long chat. The parallel-to-serial ratio fell inside my pre-set “can’t tell” band. The one-chat group used fewer tokens, but different articles and output make a direct conclusion difficult.
- Serial vs. parallel: parallel used 0.80 times the tokens of serial. Before the run I had written down that anything between 0.7 and 1.3 would count as “can’t tell.” It landed inside that band.
- Per request: about 163k tokens (serial), 156k (parallel) and 159k (one chat). The group averages were close.
- Time: parallel took 9 minutes. Serial took 31.
This is one run, on different articles in each group, so it does not say parallel is cheaper or that one long chat is better. The counts alone do not establish which way of working is cheaper.
What I wanted to know
Usage limits keep shaping how I work (I wrote about one case in my Codex weekly limit post). So I had a plain question: does the shape of the work change how much I spend?
I had two guesses, and they pulled in opposite directions:
- Parallel costs more. Three agents starting at once might each build the same large prompt cache, so I would pay for the startup three times.
- One long chat costs more. The conversation keeps growing, and every new request re-reads all of it.
I expected the one-chat group to cost 1.3 to 2.0 times the serial group. I wrote that down too.
How I ran it
The test material was nine recipe-style articles for a different blog of mine. For each one, Claude Code did the same stretch of work: set up the working folder, research, draft, and fact-check. I split the nine into three groups of three:
- S (serial): three articles, one after another, each in a fresh chat.
- P (parallel): three articles at the same time, each in its own fresh chat.
- C (one chat): three articles back to back inside one chat.
On October 20, 2026, S started at 5:52 a.m. JST, P at 6:26 a.m., and C at 10:27 a.m.
I fixed the serial and parallel plan before those runs. I added and hashed the one-chat plan after S and P, before running C. The rule I committed to: if the parallel-to-serial ratio fell between 0.7 and 1.3, I would report “can’t tell.” My narrower null range was 0.9 to 1.1.
What I counted. I summed every request in the session transcripts, including sub-agents: ordinary input tokens, output tokens, cache writes and cache reads. Cache reads are most of the total (about 92% in both S and P), which is why the numbers look huge for a few articles.
What came out
| Group | Requests | Total tokens | Tokens per request | Elapsed | Plan usage, 5-hour window (my reading) | Plan usage per million tokens |
|---|---|---|---|---|---|---|
| S: serial, 3 articles | 133 | 21,709,697 | about 163k | 31 min | +27 pt | about 1.24 pt |
| P: parallel, 3 articles | 112 | 17,448,407 | about 156k | 9 min | +23 pt | about 1.32 pt |
| C: one chat, 3 articles | 91 | 14,453,877 | about 159k | about 17 min | +20 pt | about 1.38 pt |
Here are the same numbers as ratios, with serial as 1.00:
| Ratio to serial | Requests | Total tokens | Tokens per request | Elapsed | Plan usage, 5-hour | Plan usage per million tokens |
|---|---|---|---|---|---|---|
| P / S | 0.84 | 0.80 | 0.95 | 0.28 | 0.85 | 1.06 |
| C / S | 0.68 | 0.67 | 0.97 | about 0.55 | 0.74 | 1.11 |
The plan-usage columns are my own readings of a whole-number percentage meter, and the parallel and one-chat windows include some report-writing and design-session usage. That is why I only compare the 5-hour window, and only loosely. Plan usage fell roughly in step with tokens, and per million tokens the meter moved by a similar amount in all three groups (the other two groups were about 6% and 11% higher than serial). Given the rounded readings and mixed-in activity, I cannot attribute those differences to the work shape.
The parallel articles ran at the same time, while the serial articles ran in sequence. That explains why their elapsed times are not directly comparable as per-article speeds. One possible reason the one-chat group finished sooner is that later articles did not reload startup material, but I did not test that, and the group also produced fewer review-folder bytes, including review notes.
Parallel over serial came to 0.80 on total tokens. Dropping the first request of every session left it at 0.80. That is a point estimate of about 20% fewer tokens, and I don’t want to wave it away. It is outside my narrow null range of 0.9 to 1.1 but inside the 0.7 to 1.3 band I had called “can’t tell,” so “can’t tell” is the call I had committed to making.
Why I stop short of crediting parallel: most of the gap is associated with the number of requests (0.84); the average tokens per request also differed (0.95). One parallel article took only 33 requests, and serial also ran first and had a slightly heavier set of articles. Any of those could produce a gap of this size without parallelism doing anything.
The per-request weight is the number I trust most. It was 163k, 156k and 159k, a difference of about 5% between serial and parallel. The number of requests contributed more to the total token difference than the average size of a request did. Request counts varied from article to article, and these numbers cannot identify why the groups differed. One parallel article needed only 33 requests, while the others took 37 to 46.
Per article, the three shapes looked like this:
| Group | Tokens per article | Requests per article | Review-folder files per article |
|---|---|---|---|
| S | about 7.24M | about 44 | about 22.0k bytes |
| P | about 5.82M | about 37 | about 20.1k bytes |
| C | about 4.82M | about 30 | about 16.3k bytes |
The one-chat group came out lowest: 0.67 of serial and 0.83 of parallel. Different articles and smaller review-folder files limit what that comparison can tell me.
Where my predictions broke
The cache guess was not supported by these observations. Five of the six first requests each recorded 55,523 cache-read tokens. The first serial article recorded 46,516; my interpretation is that its cache was not yet warm. I did not observe a larger first-request cache-creation count in P. This does not establish cache behavior for all requests.
The one-chat guess was wrong. I expected a big penalty for letting one conversation grow. Its context grew from roughly 100k to roughly 250k tokens. No automatic summarization marker appeared, and the group averaged about 159k tokens per request. This average does not show that each request stayed constant. The group did not cost 1.3 to 2.0 times serial. It cost less.
What I can’t say
These are the limits I would keep in mind when reading the results.
- The “can’t tell” band. I chose 0.7 to 1.3 before the run, and it is wide. A 20% difference is not small in practice, so please read “can’t tell” as “I can’t separate this from the other factors below,” not as “there is no difference.” If parallel really does use fewer tokens, this run was not built to confirm it.
- One run. I ran each shape once. I don’t know the run-to-run spread, so I can’t say whether 0.80 is a real gap or noise.
- Different articles in each group. Every article was different, and the one-chat group used a different set of base articles from S and P, so its difficulty is only roughly comparable.
- Order. Serial ran first and parallel second, so any warm-up or time-of-day effect is mixed in.
- Difficulty. My pre-run proxy scores totaled 9 for serial, 8 for parallel and 9 for one chat. These scores do not establish that the articles required the same work.
- Output. The one-chat group produced fewer review-folder bytes (including review notes, about 74% of serial’s). Tokens per byte of review-folder files came out at about 0.9 of serial. The lower byte count may reflect differences in what was produced; it does not establish workload or quality.
- Quality. I did not compare quality. All three one-chat articles were reported to have “needs checking” items after review, and the count of such lines was 15 (S), 7 (P) and 19 (C) across three articles each. Using fewer tokens tells me nothing about whether the result was as good.
- Rate limits. I didn’t check whether any run hit a rate limit.
- Plan usage. The meter readings in the table are my own, in whole percentages, and the windows include some non-experiment usage. I’m not reading anything into small differences there.
What I’d do with this
For this kind of job (27 to 46 requests per article, about 4.1 to 7.5 million tokens each), I would not pick a shape to save tokens based on this run: the parallel-to-serial result was inside my pre-set band, and the one-chat result is confounded by different articles and output. Pick parallel when I want the time back. Nine minutes against thirty-one is a gap I could see, while the token gap stayed inside my “can’t tell” band.
I also have a hunch that splitting work into separate chats pays off in much longer sessions, hundreds of requests long. I haven’t tested that here, and a 27-to-46-request job doesn’t speak to it.
FAQ
Did parallel save tokens? Not in a way I can show. The ratio was 0.80, but it sits inside the band I had called “can’t tell,” and it comes from one run with uneven articles. What parallel clearly saved was time.
Is one long chat worse than several short ones? This run did not establish whether one chat is better or worse: the articles differed and quality was not compared. The main-chat context grew from about 100k to 250k tokens, while the group average was about 159k tokens per request; that average does not establish how individual requests changed.
How did you count tokens? I added up every request in the session transcripts, sub-agents included: ordinary input and output tokens plus cache writes and cache reads. Cache reads dominate that sum, so compare ratios between groups rather than reading the raw totals as “new” work.
Next steps
I’m not repeating the run. These nine articles were not enough to justify a token-based choice between the shapes. If I measure again, I would test the one thing I couldn’t here: a much longer session split into pieces against the same work kept whole, with a quality check on both sides.
For another write-up where I decided how to read the result before running it, see I Ran Three Experiments to Find a Cheap Checker. I Never Picked One.