The pitch says the agent is free because the software is open source. The software is the one part of an AI system that was already approaching free. Everything the software touches runs on a meter, and there are three of them. The demo on this site is small enough to show its meters in public, and the client systems in the brief show how the same three lines scale.
Meter one: idle, the cost of being ready
In the demo's first week, the machines scaled to zero when idle. Free-ish. It also meant the first visitor after a quiet hour waited out a cold boot plus a model call, and concluded the demo was broken. The fix was keeping one machine always warm, and the consequence is the point: the meter now runs whether anyone visits or not.
The demo's idle line is about $20 a month at Fly.io's published rates for three shared-CPU machines running around the clock. Small number, structural lesson. Availability is a subscription you pay to your own infrastructure, and it exists before the first user shows up. A "free" agent that answers phone calls at 3 a.m. is a machine that was awake, billing, at 2 a.m.
Meter two: tokens, the cost per call
Every question the demo answers is metered twice. Embedding the query costs $0.15 per million tokens. The answer costs $0.30 per million tokens in and $2.50 per million out, at the published rates for the model it runs.
Look at that ratio. Output costs roughly 8x input. That asymmetry should shape system design, and mostly it shapes nothing, because most teams never see the number per call. A chatty agent that pads every answer with three paragraphs of preamble is not a style problem; it is a unit-economics problem multiplied by your query volume.
The prerequisite for doing anything about it is attribution. On a studio-scale ETL we operate, every embedding writes its token count to the database, which is what makes cost-per-tenant a query instead of a shrug. On another platform, the model gateway's spend logs land in a queryable trace table. The pattern is the same everywhere: persist cost like you persist logs, at the grain you bill or budget at.
What pulls the token meter down
Four levers, all running in production systems today, all described with receipts in the brief:
- Cache what repeats. The MCP tool server behind one client platform runs a Redis L2 cache with per-tool TTLs. A tool result served from cache is a model call that never happened.
- Cap what the task needs. Batch matching on a recruiting platform runs a small model capped at 200 to 800 output tokens per call, with an hourly cache so recomputation never happens by accident. The cap is not a limit on quality; it is a statement of how much output the task actually requires.
- Fall back to cheaper. When the primary model rate-limits, one system degrades to a smaller model instead of queueing. Slightly worse answers beat no answers, and beat paying peak rates for retry storms.
- Shrink the catalog. One agent platform replaced 200+ hardcoded tool definitions with one generic tool and a 9k-token compressed catalog. Tool definitions ride into the context window on every single turn; the catalog diet cut per-turn cost across the board.
Meter three: actions, the cost of touching the world
The first two meters are at least visible on a cloud bill. The third is scattered across a dozen vendors, and it is the one the viral pitch never mentions.
An agent that answers missed calls pays per phone minute. Per SMS. Per email send past the free tier. Per CRM API seat. The HVAC play from the first article in this series works because the recovered jobs are worth multiples of the per-action costs, but that arithmetic was done, not assumed. Someone multiplied cost-per-recovered-call by call volume before promising a return.
Actions also carry the only meter that compounds when things go wrong. A retry loop on a metered SMS API is a money printer running in reverse. This is why every write action in our systems is idempotent, capped, and audit-logged: the log is not just for security, it is the itemized receipt for the most expensive meter.
The bill is a design property
None of these numbers is alarming. The demo's whole footprint is coffee-budget scale, and that is the point of measuring it: cost stayed small because it was visible from the first commit, not because AI is cheap by default.
"Free because open source" fails as arithmetic, but the fix is not "AI is secretly expensive." The fix is treating cost as a designed property of the system, like latency: attributed per call, budgeted per tenant, gated the same way quality is gated in CI. The demo whose meters you just read is live right now, and the operator brief has the full cost machinery behind the bigger systems.