Three things I had to fix before my status line could tell me what a session cost

The cost field may or may not reach you

This was the second problem. The 1.1.21 release notes say an unrounded session cost was added to the status line data model. The "Available JSON fields" table in the documentation lists cwd, session_id, conversation_id, model, context_window, quota, plan_tier and more — with nothing corresponding to cost. The version value in the documented sample payload is also older than the current release.

So the release notes and the reference table are out of sync. Having read the table first, I nearly concluded the field had not shipped. The only way to know is the dump described earlier.

Rather than betting on either answer, I write for both.

printf '%s' "$payload" | python3 -c '
import sys, json
p = json.load(sys.stdin)
 
# cost may be absent depending on your build.
# Descend with get() so a missing key never takes the status line down.
cost = (p.get("cost") or {}).get("total_cost_usd")
 
cw = p.get("context_window") or {}
usage = cw.get("current_usage") or {}
 
if cost is not None:
    print("cost ${:.4f}".format(cost))
else:
    # Store the token breakdown instead; rates can be applied later
    print("in {} / out {} / cached {}".format(
        usage.get("input_tokens", 0),
        usage.get("output_tokens", 0),
        usage.get("cache_read_input_tokens", 0),
    ))
'

There is a side benefit to writing it this way. current_usage carries input_tokens, output_tokens, cache_creation_input_tokens and cache_read_input_tokens. Keep those four and you can recompute history when rates change or when your plan does. Store only a dollar figure and you cannot.

I am deliberately not printing my own rates here. They differ by plan and change over time. Check your own usage and pricing first, then keep the rate table in a single config file. A cost formula scattered across several scripts is a problem you pay for later.

A naive ledger reads about 50 percent high

The third one. The status line runs every time the agent state changes — idle to thinking, thinking to tool_use, and so on. That means it fires many times within a single conversation.

And context_window.total_input_tokens is a running total for that conversation. It grows on every call. Append one row per invocation and sum every row later, and you get this — reproduced locally with one conversation firing three times and a second firing once.

Obvious once stated, but the inflated numbers look perfectly plausible sitting in a file. You are left with a vague sense of spending more than expected, and because the inflation scales with conversation length, comparisons between kinds of work are distorted too.

Keep only the last value per conversation ID.

#!/usr/bin/env bash
# The recording half, kept separate from the rendering half
LEDGER="$HOME/.gemini/antigravity-cli/usage.jsonl"
 
printf '%s' "$payload" | python3 -c '
import sys, json, os
p = json.load(sys.stdin)
cw = p.get("context_window") or {}
row = {
    "conversation_id": p.get("conversation_id"),
    "model": (p.get("model") or {}).get("id"),
    "cwd": p.get("cwd"),
    "in": cw.get("total_input_tokens"),
    "out": cw.get("total_output_tokens"),
    "cost": (p.get("cost") or {}).get("total_cost_usd"),
}
with open(os.environ["LEDGER"], "a") as f:
    f.write(json.dumps(row) + "\n")
' 2>/dev/null || true

And on the reporting side, collapse by conversation ID.

#!/usr/bin/env python3
"""Collapse usage.jsonl per conversation and group by working directory.
 
Summing every appended row double-counts the running totals,
so the last row per conversation is the only correct choice.
"""
import json
import os
from collections import defaultdict
 
LEDGER = os.path.expanduser("~/.gemini/antigravity-cli/usage.jsonl")
 
last = {}
with open(LEDGER) as f:
    for line in f:
        try:
            row = json.loads(line)
        except json.JSONDecodeError:
            continue  # drop half-written lines
        cid = row.get("conversation_id")
        if cid:
            last[cid] = row  # later rows win
 
by_dir = defaultdict(lambda: {"sessions": 0, "tokens": 0})
for row in last.values():
    key = row.get("cwd") or "(unknown)"
    by_dir[key]["sessions"] += 1
    by_dir[key]["tokens"] += (row.get("in") or 0) + (row.get("out") or 0)
 
for key, v in sorted(by_dir.items(), key=lambda kv: -kv[1]["tokens"]):
    per = v["tokens"] / v["sessions"]
    print(f"{key:<40} {v['sessions']:>5} sessions {v['tokens']:>12,} tokens  avg {per:>10,.0f}")

Grouping by cwd is the part that matters. It buckets spend per repository, which for anyone running several products in parallel is the view you actually want.

Rounding hides frequency, not unit price

With a ledger in place, is an unrounded figure worth the trouble? Rounding to cents costs you less than a cent per session, which sounds like noise.

It stops being noise when session counts are lopsided. Three workload groups, worked through:

Any group whose per-session amount falls below the rounding unit sums to $0.00 no matter how often it runs. It is 13.8% of real spend and 0% of what you see. The absolute dollars are small; the distortion of the shares is the real problem, because deciding what to cut is a question about shares.

What rounding hides is frequency, not unit price. Expensive work is unaffected. Cheap, frequent work disappears — and the more you automate, the more of that kind of call you make.

Does the ledger need a lock?

With several repositories open at once, several CLIs append to the same usage.jsonl concurrently. I assumed I would need a lock — interleaved writes, corrupted lines, the usual story.

I measured it first. Six processes appending to one file with O_APPEND, at varying line lengths, counting lines that failed to parse:

Not one corrupted line. A write to a descriptor opened with O_APPEND seeks and writes without a gap in between, so no other process lands in the middle of a line. The buffered version behaves the same because the whole string is flushed once when the with block exits.

So in this case I would recommend not adding a lock. A lock adds a failure path, and the status line runs under a tight budget — waiting on a lock is itself a way to hit the timeout described earlier. If the guarantee already holds, doing nothing is the safest option.

The guarantee has conditions, though, and this is where I nearly tripped:

1. Write each line in one call. Flushing mid-line, or writing the body and the newline separately, opens the gap you were trying to avoid. Build the whole string including \n and hand it over once.
2. Keep lines small. It is tempting to store the entire payload; you only need conversation ID, cwd, and the token breakdown. Longer lines leave more room for a split on some systems.
3. Do not put the ledger in a synced folder or on a network share. I keep repositories under a sync folder, so I almost created the ledger there too. Under cloud sync, a partially appended state can become visible to another process. The ledger lives on local disk; only the rollup output leaves the machine.

Once you can no longer honour those three, that is the moment to reach for a lock. This is a local measurement file rather than production state, and "delete it and start over" is an acceptable recovery — that assumption is part of the call.

Split what goes on screen from what goes in a file

After those three fixes I separated rendering from recording. The status line has a tight time budget, and mixing heavy work into it walks you back toward the timeout.

The ledger write ends in || true. Losing the status line because an append failed would be the wrong priority. But swallow errors and you can go weeks without noticing an empty ledger, so my rollup script warns when the ledger has not been touched in two days. Configuration that stops taking effect silently is a recurring shape — I wrote about one version of it in config keys that are ignored on the way through CI — and every silent path is one you have to close yourself.

Exit codes deserve the same care. Wrap a script in one more layer and inner failures stop propagating outward; I covered that pattern in exit codes swallowed by the wrapper.

What the numbers actually told me to stop

I expected the cut list to be obvious once I had data. What I got was slightly more awkward.

The most expensive directory was also where the most valuable work happened. Cutting there is the wrong move. The cheap, high-frequency group — the one rounding had erased — was where cutting cost me almost nothing. It was full of the same confirmation asked repeatedly, and files re-read that could have been read once.

So I stopped ranking by dollars and started ranking by average tokens per session. A large population of very small sessions is usually a habit rather than a task. Sessions with a high average are usually large because they need to be. That is why the rollup prints avg.

Watching the distribution and fixing the habit did more for the quality of the remaining work than watching the total ever did. Two weeks in, I cannot speak to anything seasonal yet. But it beats reading an invoice at the end of the month and feeling vaguely bad about it.

Where to start

Three steps, kept separate:

1. Drop in the throwaway script and capture payload-sample.json once. Whether your build sends cost is a question only that file answers
2. Swap in a minimal display-only status line and confirm that timeout 2 cat and the fallback both behave
3. Then add the recording half, let it run for a week, and run the rollup

Build the recording half first and the timeout symptoms and the accounting mistakes surface together, which makes neither diagnosable. I did not keep that order, which is why the double-counting took me longer than it should have. Reasoning from the documentation table is the same class of detour.

Thank you for reading — I am still reshaping this as I go, and would be glad to keep learning alongside you.