Always-On Is Not Always-Running
The fantasy version of a 24/7 agent reasons continuously — a mind that never sleeps. The economics of that are not merely unfavorable; they are the reason a whole cohort of agent products will die. The viable version is something else: an agent that is always available and almost always idle.
Three facts about the bill
Frontier prices don't fall. The observation (Ethan Ding's token-economics essay) that reframes everything: while any given model gets ~10× cheaper over time, the price of the frontier model has stayed roughly constant — each generation launches near the same per-token price, and serious users always migrate to the frontier because agent capability compounds there. If your agent rides the best model — and an agent trusted with real work does — token deflation never arrives for you.
Consumption explodes. Meanwhile the tokens per task grew orders of magnitude as workloads went agentic: outputs that were ~1,000 tokens became ~100,000; autonomous task length keeps doubling. Ding's projection for a continuously-running frontier agent lands around $72/day per user — and the prediction validated early: Anthropic rolled back its unlimited Max tier after users ran it as 24/7 automation, with top accounts consuming on the order of 10 billion tokens a month. There is no flat subscription that survives always-running agents.
Naive conversations are quadratic. Within a single session, every turn reprocesses all prior context, so cost grows with the square of conversation length. Kanwat's production example: a database agent whose 100-turn conversations cost $50–100 in tokens alone — more than the value it delivered by around query 50. An ever-growing context is an ever-growing invoice (and, per Part 1, a worse agent too — you pay more for degraded recall).
Gartner supplies the market-level echo: over 40% of agentic-AI projects predicted canceled by end-2027, citing exactly this triad — escalating costs, unclear value, inadequate risk controls. The skepticism isn't about the trajectory (the same firm forecasts 15% of daily work decisions autonomous by 2028); it's about undisciplined deployments.
The duty-cycle model
Against the $72/day projection stands a documented counterexample: a persistent scheduled Claude agent running 15+ daily tasks for under $1/day in variable cost (Kjetil Furas). The difference isn't a cheaper model — it's the shape of the workload:
The operational kit that makes the cheap version work is the same kit from Part 4, plus explicit metering:
- Short sessions, fresh contexts. Each task starts clean, reads state from disk, works, writes state, exits. No quadratic tail.
- Tasks as data. Schedules and task definitions live in config (JSON + cron), not in code or in a standing conversation — changeable without redeploying, auditable, and enumerable.
- Hard caps. A daily budget with a circuit breaker; retry limits with cooldowns. Cost bugs and thrash bugs are the same bug.
- Justify agentic cost per task. Anthropic's own framing: agentic systems trade cost and latency for capability, and the trade must be explicitly worth it. Some scheduled work doesn't need a model at all — a deterministic script gathers the facts, and the model only interprets.
That last point deserves its own sentence, because it's the cheapest optimization available: split every recurring job into a deterministic collector and a judgment step. The collector (shell script, cron) is free and reliable; the model spends tokens only on interpretation. XiaoSteve's nightly self-maintenance runs exactly this shape — a read-only collector script produces a report on disk; a short headless session reads it, acts on a whitelist, journals, and exits. On a subscription plan the same discipline shows up as staying inside session caps rather than a dollar meter — same constraint, different unit. This series met that constraint personally: its research fan-out hit the session cap at minute 62, and the synthesis was finished by a single cheap linear session reading artifacts from disk.
Applying it
- Design for duty cycle: triggers (cron, webhooks, notifications) wake the agent; nothing "runs" between triggers.
- Keep per-session context lean; carry continuity in files (Part 1), not in a standing conversation.
- Meter everything: budget caps, retry ceilings, and a log line per run so cost anomalies surface in review.
- Before any fan-out or long autonomous run, estimate tokens against the value of the task — and against a boring script that might do 80% of it.
Next: the loop that makes an agent better over time — and the three conditions without which "self-improvement" quietly becomes self-deception. Part 7 →