Why one word of error from a metered assistant meant nothing

A scheduled AI task ran for fifteen minutes that morning, spent most of a day’s budget, and still failed to deliver a single result.

That job’s whole purpose was reading a handful of sites overnight and dropping a short summary into a shared notes file every morning. It was a reasonable use of a smart assistant when we set it up. It just cost a lot to run every single day, whether or not anything worth reporting had happened.

The night the cost showed up

That same evening, a different and unrelated question came up: had a business partner posted an update yet? Out of habit, I sent it to the same capable but metered assistant. It ran for a couple of minutes and came back with a single word: an error, no explanation. A different assistant, one that wasn’t metered the same way, took the same question and answered it in under thirty seconds.

The natural read of a bare error is “something’s broken, try again” or “the connection hiccuped.” That is a bad way to read a balance. What had happened was boring. The morning’s expensive run had already spent almost everything, and this second, smaller ask emptied it out entirely. An error with no number attached looks the same whether the cause is a flaky connection or an empty wallet, and the message alone gives you no way to tell which.

What the two jobs actually were

Looking at both failures side by side made the shape of the problem obvious. The morning job was not “go think about the news.” It was a poll: check whether anything new and worth mentioning had shown up, and on most mornings the answer barely changes. The thing that mattered that night was not a summary of the internet either. It was one specific fact: had the update landed yet, so the reply could go out promptly.

That is a “yes or no” question, and it had been handed to the expensive option purely out of habit.

What replaced it

We swapped the daily assistant job for a small, unglamorous script. It checks the shared workspace every few minutes and only says something out loud when there is something new to report. No model reads anything, no reasoning happens, and nothing is spent when nothing has changed. It runs constantly and costs nothing per check, which is the opposite shape of a job that runs once and costs a lot whether or not it finds anything.

The daily assistant job stayed off after that. If it comes back, the plan is to put a balance check in front of it, so a dead job shows “no credits left” instead of a message that looks like a shrug.

Which checks need a thinker

Some recurring questions need judgment: is this news item relevant, does this pattern mean something. Plenty of others are a plain comparison wearing a fancier job title: did the number change, did the file update, did the message arrive. The second kind doesn’t get smarter by paying more for it. It gets a watcher that costs nothing to run and only speaks up when there is something to say. For us, the first sign we’d been paying for the wrong kind was a bill, and then an error, that didn’t tell us why.

So list your scheduled AI jobs and ask of each one whether it needs judgment or only a yes or no answer. Move the yes or no checks to a plain script that costs nothing when nothing changes. Then put a balance check in front of any metered job, so an empty account shows up as “no credits left” and not as a bare error.

dxdev LESSON · paste into your AI coding agent
LESSON: Replace a metered reasoning job with a deterministic watcher wherever the decision is really just a comparison
SOURCE: dxdev.com/blog/metered-agent-quota-to-eventwatch
WHAT HAPPENED: A daily scheduled agent on a credit-metered platform scanned for news every morning at a high fixed cost per run, and one run failed to deliver its findings at all. That evening, a second, unrelated task on the same metered platform failed with a bare error that looked identical to the first failure but actually meant the account balance had reached zero. The daily job was replaced with a small script that checks a repository for a new update every few minutes and posts only when something actually changed, using no model calls at all.
THE RULE: Before assigning a recurring job to a reasoning agent, check whether its real decision is judgment or just a comparison. "Did something change" is answerable with two values and does not need a model in the loop, a shared error budget, or a credit balance that can silently reach zero.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Every recurring AI-assigned job is checked for whether its actual decision could be replaced with a plain comparison (a hash, a timestamp, a diff) instead of a model call.
  2. Any job running on a metered or credit-limited path fails loudly with its remaining balance, not a bare error string, when it can't complete.
  3. A deterministic watcher, not a reasoning model, owns any notification whose only job is detecting that something changed.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.