A platform shipped a thirty-minute wall-clock cap on long-running agent tasks, paired with a refund policy that returned the token spend on any task that hit the timeout without producing a deliverable. The intent was protective: a hung agent should not bill the customer. Six months later, the timeout rate had doubled, the engineering team was deep in an "agent reliability" investigation, and the support queue was full of users complaining that the agent "keeps timing out" — with screenshots that showed the user's own browser tab closing at twenty-nine minutes and change.
The unit economics had quietly inverted on a behavioral cohort the finance model never named. The refund population was not a quality population. It was a strategy.
The Boundary You Reimburse Against Is a Target #
Any operational threshold a platform reimburses against becomes a coordinate users can learn to land on. This is not new in cloud or SaaS — SLA credits, refund windows, and free-tier ceilings have been gamed for decades — but agent platforms have a uniquely sharp version of the problem because the cost of one task is large enough to be worth optimizing against individually.
The arithmetic, from the user's perspective, is simple. A complex multi-hour task that completes will bill at the agent's full token spend. The same task interrupted at the twenty-eight-minute mark hits the refund boundary, returns most of that spend, and the resulting in-context state can be picked up cheaply in a follow-up turn that does not start from zero. A user who runs ten of these workflows a week and has done the math will deliberately steer toward the boundary on every expensive run.
Power users find the seam first. They are the cohort with the highest dollar exposure, the highest motivation to read the policy carefully, and the operational sophistication to restructure a workflow around an envelope. They are also the cohort the platform least wants to lose, which is why the refund policy was generous to begin with.
The platform's response curve gets the directionality exactly wrong. Timeouts go up, so the reliability team investigates the agent. The agent is fine. The bill for refunds rises, and finance treats it as elevated platform failure cost. The on-call sees no incident. Every dashboard reports a problem with a different etiology than the one actually firing, because the dashboards were designed against a model of the user as a passive recipient of agent behavior rather than a participant in a pricing game.
Why This Failure Mode Is Specific to Agent Platforms #
Traditional SaaS gives users a few coarse levers — cancel, downgrade, dispute a charge. Agent platforms expose much finer-grained behavioral controls that map directly onto unit cost. The user can decide when to abort a task, how to phrase the next message, whether to spawn a subagent, when to commit to a tool call. Each of these is a knob on the bill.
The timeout-refund game is structurally similar to the cost-attack class that has been documented against cloud APIs over the last two years: a pricing surface that scales with usage creates an incentive to push usage in a direction the platform did not intend. The difference with agents is that the optimizer is a customer, not an attacker, and the action is not malicious — the user is just reading the policy as written.
A second compounding factor: agent runs are long enough that the user has time, mid-run, to make a decision about whether to let the run complete. A two-second API call has no useful "abort here for refund" surface. A twenty-eight-minute agent task does. The very property that makes long-running agents valuable — durable, multi-step work — also gives users a window in which to optimize against the billing boundary.
A third factor, the one that turns this from an isolated trick into a behavioral cohort: the in-context state from a partially completed agent run has value. If the user can resume cheaply after the refund fires, they have effectively converted "the agent did most of the work" into "the agent did most of the work for free." The platform's checkpoint-and-resume capability — sold as a reliability feature — is doing double duty as a billing exploit. Reliability and refund-arbitrage share a code path, and the platform did not realize it was funding both.
The Diagnosis Looks Like a Quality Regression #
This is the most expensive part of the failure mode, because it routes the response to the wrong team.
When the timeout rate doubles, the natural read inside engineering is "the agent is getting worse." Reliability investigations spin up. Eval suites get re-run. Model versions get bisected. Tool latencies get audited. None of it finds anything, because nothing has regressed — the agent is performing exactly as before, on a workload that has shifted under it.
References:
https://www.ravelin.com/insights/policy-abusehttps://www.mindstudio.ai/blog/ai-agent-token-budget-management-claude-codehttps://developers.googleblog.com/build-long-running-ai-agents-that--resume-and-never-lose-context-with-adk/https://dev.to/waxell/the-47000-agent-loop-why-token-budget-alerts-arent-budget-enforcement-389ihttps://www.infoworld.com/article/4138748/finops-for-agents-loop-limits-tool-call-caps-and-the-new-unit-economics-of-agentic-saas.htmlhttps://tdwi.org/blogs/ai-101/2026/05/goodharts-law-and-ai.aspxhttps://www.braintrust.dev/articles/best-ai-agent-observability-tools-2026https://zylos.ai/zh/research/2026-02-20-graceful-degradation-ai-agent-systems
Let's stay in touch and Follow me for more thoughts and updates