The harness decides how many calls a task costs

The layer that turns one instruction into provider calls is usually not code you wrote. The harness — the coding agent, the orchestrator, the CLI around them — decides how many turns a task takes, what is re-sent on each one, how wide it fans out, and which credential pays. Run the same task, on the same model, with the same prompt under a different harness and you arrive at a different number. That makes the harness a cost parameter, and it is the one parameter in the system that changes without a commit in your repository.

Three separate threads in the week to 2026-10-30 are arguments about harness behaviour rather than about models or prompts, and none of them is framed as a cost review.

The re-send policy belongs to the harness

A Hacker News submission on 2026-10-29 is titled Claude Code regularly sends each background agent's transcript to its model, and the discussion under it treats that as a spend question. Whether the behaviour is as the title describes is not something we can confirm from a thread title, and we have not tested it — what is worth taking from the item is the shape of the claim, because it is a shape you can check yourself on whatever you run.

A re-send policy is a decision about which prior bytes go back to the provider on each turn: the full transcript, a window of it, a summary, or only the delta. That decision sets the input-token floor for every remaining turn of the run, it is made by the harness, and it is not expressed anywhere in your application code. It belongs with the other calls you never wrote — real spend, issued on your behalf, by something you installed rather than something you authored.

You do not need the vendor's answer to measure it. Input tokens per turn, read per worker over the index of the turn, tells you the policy empirically: a flat line is a windowed or delta policy, a line climbing with turn count is a full-transcript one.

The credential decides which ledger the work lands in

A comment in a Hacker News thread on 2026-10-29 about agent SDKs quotes a third-party harness's own provider documentation:

Third-party harness usage draws from extra usage and is billed per token, not against Claude plan limits.

That is the harness choosing the billing basis on your behalf. The work is identical either way; where it is recorded is not.

Your Anthropic API usage is the per-token spend accrued against an API key, and it is the only place a harness's calls appear if the harness authenticated with one. A harness running on a subscription credential draws on that plan's allowance instead — the calls happen, the output is real, and the API usage figure never moves. Any total built by reading the provider's usage view is therefore complete only for the credentials that view covers, which is the same problem in a different direction from what a run costs under prepaid capacity.

Fan-out width is a harness setting, paid whether or not it works

A commenter on 2026-10-28, in a thread that drifts into agent economics, states the multiplier plainly:

Subagent flows can improve overall performance, but it generally also comes with disproportionately high token use.

A commenter in a separate thread on 2026-10-29 on inter-agent communication supplies the other half, from someone who is not short of budget:

When I start using an orchestrator and team of agents it rarely gets a lot better.

Put together, those are the two halves of multi-agent amplification: the token cost of a fan-out is incurred at dispatch, and the quality improvement it was bought for is not guaranteed. How many workers to dispatch is a harness default or a flag, not a design decision anyone in your team reviewed, and the width interacts with what running several copies at once does to each one.

A comparison between harnesses needs three things pinned

A submission on 2026-10-29 carries the comparison in its title — Posit Assistant makes better use of your token budget than leading coding agents. Vendors are now competing on token efficiency, which is a reasonable thing to compete on and a difficult thing to read.

A claim of that shape is only interpretable if three things are held fixed: the task, the model, and the version of every harness in the comparison. The third is the awkward one. A harness updates on its own release cadence, and a change to its re-send policy, its default fan-out or its background helpers lands in your spend without a line changing in your repository. A step increase in cost per completed task the week after an auto-update looks exactly like a prompt regression, and will be investigated as one.

This is hard to see from inside your own code

The reason this is difficult to audit is that there is usually nothing in your repository to audit. We scanned 133 public Python agent repositories; 51 made direct LLM calls or used LangGraph. Most agent repositories call providers through a framework rather than directly, and a harness sits a layer above even that. Reading your own call sites tells you about a shrinking fraction of the requests your process issues.

What to record

1. Harness name and version, as a dimension on the cost row. It moves like a model price and it is not reconstructable from a spend total afterwards.
2. Billed provider calls per completed task, not per turn. The quantity the harness changes is the call count, so a per-call average cannot see it.
3. Input tokens per turn, split by worker, against the turn index. This is the re-send policy, measured rather than asked about.
4. Which credential served each call, so the work that never reaches an API usage view is a named line rather than a silent absence.
5. Cost per run compared across harness versions, not across calendar weeks. A week is the interval in which both the harness and your prompts changed.

How this works in Capsera, and what it does not do

Capsera captures at the provider client rather than at your call sites, which is what makes a harness's calls visible at all. capsera.init() patches the clients — Anthropic messages, OpenAI chat completions, OpenAI embeddings and Google Gemini, sync and async — so a request issued by a background worker or a framework inside the same process is recorded like any other, with its input, output and cache token counts kept separate. @capsera.agent(name="planner") adds who, not whether, and because the agent stack is a contextvars ContextVar rather than thread-local state, nested workers inherit the identity instead of each needing a tag threaded through.

Two limits, stated plainly. Capsera runs in-process, so it sees what the Python process issues — a harness that shells out to a separate binary, or that runs entirely outside your interpreter, is outside that boundary and its spend has to be reconciled from the provider side instead. And Capsera stores hashes and token counts, never prompt or completion content, so it can tell you a call was large without telling you it was a re-sent transcript; you still read that from the size and the turn index. Budgets are checked before the provider call, scoped per agent, per team or globally, which bounds a harness whose default fan-out nobody reviewed.

Where to go instead. If what you need is the transcript itself at the moment a worker was dispatched — the content, not its size — Langfuse is open source, free, and built to store and inspect exactly that; Capsera is not, by design. If the harness authenticates through a gateway and you want spend capped per key, team or organisation across many providers, LiteLLM is MIT-licensed, free, and enforces hard budgets at those scopes.