Track AI Agent Costs with a 5-Column CSV and Stop the Silent Money Drain

Most AI agent cost problems don't stem from model pricing — they stem from untracked runs: nobody can say which run cost how much, what task it was for, or whether its output was ever used. A simple 5-column CSV log turns that black hole into an analyzable expense report.

Why Your Agents Are Quietly Burning Money

Traditional cost management focuses on the price per million tokens, but what actually devours your budget are the loops that repeatedly read state without performing any action. These runs still consume tokens yet produce zero business value. The problem isn't the unit price — it's the lack of a per-run attribution record.

When you can't answer "which agent role spent this money" or "did this run produce a valid output," cost optimization has nowhere to start. The end-of-month bill is just a single number — it won't tell you where the waste happened.

What are tokens and "repeatedly reading state" loops?

A token is the basic unit of text an LLM processes — roughly 0.75 words in English, or 1–2 characters in Chinese. Every time you call a model, the input text is counted as tokens_in, and the model's generated output is counted as tokens_out; together they form the billing basis.

A "repeatedly reads state without performing an action" loop refers to an agent that, across multiple turns, keeps stuffing the same context, tool return values, or environment state back into the prompt without advancing the task — for example, continuously checking a file that hasn't been updated, or polling an external endpoint that hasn't changed. Each turn of such a loop re-bills input tokens, but the resulting outcome is no_action. These loops are often triggered by vague stopping conditions, missing timeout mechanisms, or unstable tool return formats, and in long-chain agents they quickly accumulate into a sizable bill.

The 5-Column Tracking Schema

The core of this minimalist schema is making cost and result visible on the same row:

Column	Purpose
run_id	Links logs, cost, and final result
agent_role	Marks which agent spent this money
tokens_in / tokens_out	The raw drivers of cost
cost_usd	Computed at write time, not aggregated at month's end
outcome	Values: shipped, no_action, failed, retried

The outcome column is the soul. Without it, you only see how much was spent — not what that money bought. Computing cost at write time also makes real-time monitoring possible, instead of regretting it after the fact.

Why split outcome into four value types?

shipped means the task produced an adopted result — it's the denominator for "cost per useful output"; no_action flags idle spinning that consumes without producing; failed records runs that terminated with an error; and retried distinguishes those runs that executed again because the first attempt failed. Only with all four can you compute the retry multiplier and pinpoint whether the problem lies in the prompt, the tools, or an external dependency. With just a success/failure binary, the cost of retries gets mixed into successful runs, masking the real inefficiency.

Three Queries That Pay for Themselves

Once this data accumulates, three simple queries expose the most critical problems:

1. Cost per useful output: total cost_usd divided by the count of outcome = shipped. If this number is rising, agent efficiency is dropping — even if total spend is flat.
2. No-action burn: the sum of cost_usd where outcome = no_action. This is pure waste — the article notes that in loops that repeatedly read state without acting, this typically accounts for 20% to 40% of spend.
3. Retry multiplier: average number of runs per task. Above 2, and the problem is your prompts or tools, not your budget.

The value of these three queries is that they turn "it feels more expensive" into "which part got more expensive, and by how much."

A Minimal Python Logger

The article provides a ready-to-use logging function; here's the core snippet:

import csv, time, pathlib

PATH = pathlib.Path('agent_runs.csv')

def log_run(run_id, role, tin, tout, cost, outcome):
    new = not PATH.exists()
    with PATH.open('a', newline='') as f:
        w = csv.writer(f)
        if new:
            w.writerow(['ts','run_id','role','tokens_in','tokens_out','cost_usd','outcome'])
        w.writerow([time.strftime('%Y-%m-%dT%H:%M:%S'), run_id, role, tin, tout, round(cost, 4), outcome])

The key implementation detail: call it in a finally block so that failed and retried runs also get logged. The article stresses that "failed runs are where the money hides" — logging only successful runs is like voluntarily blindfolding yourself.

Why must you use a finally block?

In Python, the try...finally construct guarantees that the statements in finally execute whether the code returns normally, raises an exception, or is interrupted. Putting the log_run call in finally ensures the agent still leaves a cost record when it errors out, times out, or exits early. If you only log in the success branch, failed and retried runs vanish from the ledger — and those are precisely where spending grows fastest. Likewise, in async or concurrent scenarios, put your logging logic in a task-completion callback or the equivalent of a finally position, so a canceled coroutine doesn't cause a missed record.

Start with the Logging Habit, Not the Tool

The author packaged this structure into a Notion database template plus a CSV starter kit, with three preconfigured views to spare you manual setup. The link is Agent Ops Tracker (Notion + CSV), on a "pay what you want" model with a $1 minimum.

But the article is also explicit: the CSV approach above is completely sufficient, and the habit matters more than the tool. Whether you use Notion or a plain text file, consistently logging every run and computing cost at write time is the key to turning agent spending from a black box into a controllable list.

The author's closing question is worth every team asking itself: are you tracking the cost per call, or the cost per useful output? The former is just a bill; the latter is efficiency.

Key Takeaways

• The essence of the agent cost problem is untracked runs, not model unit price.
• The 5-column CSV schema — run_id, agent_role, tokens_in/out, cost_usd, outcome — makes cost and result visible on the same row.
• Three high-value queries: cost per useful output, no-action burn (often 20%–40% of spend), and retry multiplier.
• The logger must go in a finally block to ensure failed and retried runs aren't missed.
• Habit over tooling: a simple CSV is enough to start tracking costs.

One-line Summary

Track the cost and output of every AI agent run with a 5-column CSV, turning invisible spending into an optimizable report.

Paragraph Summary

The article argues that AI agent cost problems stem not from model unit price but from untracked runs. The author proposes a minimalist 5-column CSV schema — run_id, agent_role, tokens_in/out, cost_usd, and outcome — making cost and result visible on the same row. The outcome column is the soul, distinguishing four states: shipped, no_action, failed, and retried. Based on this data, three queries expose the core problems: cost per useful output, no-action burn (typically 20%–40% of spend), and retry multiplier. The logger must go in a finally block to ensure failed and retried runs aren't missed. The author stresses that habit matters more than tools — a plain CSV is enough to start, and the key is consistent logging with cost computed at write time, ultimately measuring the cost per useful output rather than per call.