Independent directory of the Claude Code skills, MCP servers & marketplaces worth installing. 86,000+ tools indexed daily, ranked by real installs. Not affiliated with Anthropic.
The probe method is the right correction, and the JSONL usage blocks are the right source. One refinement worth adding to the writeup: that 54,154 lands in cache_creation_input_tokens, so it is written once at the cached-write rate and every later request in the same agent re-reads it at the cache-read rate, which is a much smaller number per request. Summing raw input tokens across a run therefore misprices the same context on every request. Did you check whether sibling subagents spawned in the same session share that cache prefix? If the system prompt and tool schemas hash identically across children, the second and third agent may not even pay the 54k write, and the break-even math for fan-out gets better again.
Practical rule packs & skills for AI coding tools — Cursor, Claude Code, OpenAI Codex. Writing about agent workflows, project rules, and what actually ships.
Checked the sibling question against transcripts from a session that spawned three agents. One sibling's first request came in at cache_creation 30,762 and cache_read 23,890, while the other two in that same session read 0 and wrote 54,812 and 49,516. A reviewer in a different session read 90,689 and wrote 2,971, so what the split tracks reads to me as whether a matching prefix was still cached rather than sibling-ness as such — the fields alone don't tell me what decided it. Caveat on my own sample: those three were individual Agent-tool spawns, not a workflow fan-out, and the stagger line I brought up last time promises the read only to the siblings that come after the first — so as I read it a fan-out still leaves the first write to someone. Agreed on the raw sum, though the effective-cost section already prices re-reads at 0.1× — these sibling numbers belong next to it, and I'll add them.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The probe method is the right correction, and the JSONL usage blocks are the right source. One refinement worth adding to the writeup: that 54,154 lands in cache_creation_input_tokens, so it is written once at the cached-write rate and every later request in the same agent re-reads it at the cache-read rate, which is a much smaller number per request. Summing raw input tokens across a run therefore misprices the same context on every request. Did you check whether sibling subagents spawned in the same session share that cache prefix? If the system prompt and tool schemas hash identically across children, the second and third agent may not even pay the 54k write, and the break-even math for fan-out gets better again.
Checked the sibling question against transcripts from a session that spawned three agents. One sibling's first request came in at cache_creation 30,762 and cache_read 23,890, while the other two in that same session read 0 and wrote 54,812 and 49,516. A reviewer in a different session read 90,689 and wrote 2,971, so what the split tracks reads to me as whether a matching prefix was still cached rather than sibling-ness as such — the fields alone don't tell me what decided it. Caveat on my own sample: those three were individual Agent-tool spawns, not a workflow fan-out, and the stagger line I brought up last time promises the read only to the siblings that come after the first — so as I read it a fan-out still leaves the first write to someone. Agreed on the raw sum, though the effective-cost section already prices re-reads at 0.1× — these sibling numbers belong next to it, and I'll add them.