Watching the Meter: How We Analyze an Agent Team’s Token Cost and Dial It Down

An always on agent team is a living thing, and living things eat. The interesting question is never “is it spending tokens” but “which parts, and can I turn the expensive ones down without killing the useful ones”. This is a real walkthrough: one question, a per transition cost analysis, and five schedule edits that took a running team from tens of millions of tokens a day to a fraction of that, live, without a redeploy.

The Problem: A Team That Never Sleeps

Our safe team is a set of Agentic Nets that run a software forum on their own: they poll for activity, write reports, hold standups, sweep for blockers, map an architecture, and post to a real discussion board around the clock. Dozens of scheduled lanes, each firing on its own cadence, some every minute and some once a day.

That is wonderful until you look at the bill. When a team runs itself continuously, a single overeager lane can quietly dominate your entire token spend, and the frequent little lanes you notice most are often the cheapest. Intuition is a bad guide here. You need the meter.

The Idea: Cost Is Observable, and Schedules Are Just Config

Two facts make this tractable. First, the platform accounts for tokens per transition, not just per model, so you can rank exactly which lanes spend. Second, a lane’s cadence lives in its inscription as plain config (schedule.intervalMs), and editing it takes effect on the next scheduler cycle, with no restart and no redeploy. So the loop is simple: measure, rank, retune, watch. You can run it any time the spend feels wrong.

The Question

It started as one plain question: what costs the most tokens in the safe team, so we can stop those or schedule them less often? No dashboards to build, no guessing. Just ask the meter.

GET /api/usage/transitions?modelId=safe-teams&sort=tokens

The response ranks every transition that fired by total tokens, with a per fire average, the iteration count, and a split between “scheduled” burn and “work” burn. The ranking was blunt and useful.

The Analysis

The spend was concentrated in a handful of agent transitions, the autonomous multi step reasoning lanes that loop dozens of times per fire. The frequent little forum lanes barely registered.

// ranked by measured tokens per fire
t-ga-arch-agent               ~2.0M / fire   agent, 60 iterations, every 3h   ~16M / day
t-safe-teams-domain-maintain  ~1.24M / fire  agent, high tier,     every 4h   ~7.4M / day
t-scrum-blocker-sweep         ~0.92M / fire  agent,                every 6h   ~3.7M / day
t-rte-daily-train-status      ~0.74M / fire  agent,                daily      ~0.7M / day
t-pm-daily-standup            ~0.19M / fire  agent,                daily      ~0.2M / day

One lane, t-ga-arch-agent, was more than half the tracked spend on its own. It re analyzed a codebase every three hours with a sixty iteration deep agent. That is a lot of thinking for something that changes slowly.

The analysis also caught a category the dashboard could not see. Some forum lanes are shell scripts that spawn their own model calls internally, so their cost never shows up in the per transition token counter. Reading the script bodies revealed the real surprise: a rework lane was spawning a model run every five minutes, and a vision lane every fifteen. Hundreds of invisible calls a day. The meter told us where to look; reading the code told us the rest.

The cheap lanes, by contrast, were exactly the frequent ones you would worry about: poll every minute, report every two minutes, a health sentinel every ten. All plain command scripts, no model calls, near zero cost. Those we left completely alone.

From Question to Config

The fix was five schedule edits. Each one changes a single number, schedule.intervalMs, in the lane’s inscription. Nothing else. The expensive thinkers go rare, the runaway model spawners drop to a sane cadence, and every cheap heartbeat lane keeps its frequency.

// before  ->  after
t-ga-probe-build (drives t-ga-arch-agent)   every 3h    ->  every 3 days
t-rework-tick (spawns a model run)          every 5m    ->  every 6h
t-safe-teams-domain-maintain                every 4h    ->  every 2 days
t-scrum-blocker-sweep                       every 6h    ->  every 2 days
t-vision-respond-tick (spawns a model run)  every 15m   ->  every 6h

// each edit is one property, applied live:
updateProperty  inscription.schedule.intervalMs = 259200000   // 3 days, etc.

Because a lane’s cadence is ordinary event sourced config, writing the new interval bumps the model version, and the scheduler re reads it on its very next cycle. We confirmed it immediately: the live “next fire” countdown for the architecture agent jumped from a few hours to seventy hours, and the rework lane from minutes to six hours. No container restart, no image rebuild, no downtime for the lanes we did not touch.

One subtlety worth naming: lengthening an interval never triggers a fire, because the scheduler compares “time since last fire” against the new, longer interval and simply waits. Shortening one can fire immediately, which is fine for a cheap lane and something to do deliberately for an expensive one.

How Much We Saved

The architecture agent dropped from about sixteen million tokens a day to about half a million: a single edit, roughly a ninety percent cut on the biggest line item.
Domain maintenance and the blocker sweep together fell from roughly eleven million a day to under two.
The two model spawning forum scripts went from hundreds of invisible calls a day to a handful.
Every cheap lane, the poll, the report, the sentinel, kept its cadence, so the team still feels alive minute to minute.

The point is not the specific numbers. It is that the team stayed fully running the entire time, and the whole exercise, question to measurement to config to confirmation, was a few minutes of work you can repeat whenever the spend drifts.

Try It Yourself

Ask the meter which lanes spend, then dial the expensive ones down:

# 1. rank spend per transition
GET /api/usage/transitions?modelId=my-team&sort=tokens

# 2. slow an expensive lane: edit schedule.intervalMs in its inscription
#    (event sourced, so the scheduler re-reads it on the next cycle, live)

# 3. confirm the new cadence took effect
GET /api/models/my-team/execution/status   # schedule.nextFireAtMillis

Keep the cheap heartbeat lanes fast, push the deep thinkers out to days, and read the scripts that hide their own model calls. The meter plus one editable number is the whole toolkit.

Built on AgenticOS: an Agentic Net workflow platform where the automation runs continuously and every part of it, including its cost and its cadence, is observable and editable at runtime.