Check both meters before the job runs

Failure mode: jobs default to one provider. The cap shows up mid-run. A long job dies partway and needs a rerun.

Fix: look at the meters before starting, and have somewhere else to go.

The gate (runs before every job):

1. Read the weekly usage for provider A.
2. Read the 5-hour session usage for provider A.
3. Both at or under 90%? Run on A.
4. Either one over 90%? Try provider B. Same two reads, same rule.
5. Either read errors, times out, or comes back malformed? Treat it as over and fall through to the next provider.
6. Nobody passes? The job doesn’t start. It waits and says why.

for provider in route:
    try:
        weekly  = usage(provider, window="weekly")
        session = usage(provider, window="5h")
    except Exception:
        log(provider, "check failed, treated as over")
        continue
    if weekly <= 0.90 and session <= 0.90:
        return run(job, provider)
    log(provider, weekly, session, "over threshold")
hold(job, reason="no provider under threshold")

Why both meters. They fail differently. The weekly number can look fine while a busy afternoon has burned through the 5-hour window. The session window can reset to almost nothing while the week is nearly gone. Checking one gives you half the picture, and the other half is the half that kills the job.

Why 90% and not 100%. The check happens before the job, and the job spends after. A long agent run can use a lot in one go. The headroom is there so a job that starts legally doesn’t finish illegally. 90% is the rule I use. It’s a knob, not a law; heavier jobs could justify a lower one.

Why an error falls through. The tempting bug is except: pass followed by “probably fine, run it.” That turns every outage of the usage endpoint into a free pass to run straight into the cap, which is the exact failure the gate exists to prevent. An unknown is a no for that provider, not for the job. The job moves down the list.

Why a list, not a default. “Use A unless something breaks” means you only find out about B when you’re already in trouble. With a written order (Claude, then Codex, then Grok) every provider gets exercised, and a fallback that’s actually been used is one you can trust.

What the gate logs, every time:

• job id, provider tried, both readings, pass or fail
• which rule failed (weekly, session, or check error)
• where the job finally ran, or that it was held

That log is the cost report. If one provider keeps failing the session check by Tuesday, the routing order is wrong, not the job.

Not solved yet:

• A job that’s huge on its own can still blow through 10% headroom. That needs a per-job estimate, which I don’t trust yet.
• Two jobs can pass the same check at the same moment and both start. A short lock around check-and-start would close that.
• Different providers count usage differently. “90%” only means the same thing if each meter is read the way that provider defines it.

Tells you don’t have a gate:

• The first sign of a cap is a failed job.
• The fallback provider has never run a real job.
• The usage check has a try with nothing in the except.
• Only one of the two meters is ever looked at.

Look at both meters. Treat silence as a no for that provider and move on.

An agent job that defaults to one model provider finds out about the cap mid-run.

Now a gate checks two meters first: weekly usage and the 5-hour session. Both at or under 90%, the job runs. Either one over, it goes to the next provider. If the check errors, it goes to the next provider too.

A lot of agent setups pick one model provider and treat its usage cap as something to deal with when it hits, which means a long job can die halfway and need a rerun. The fix I use is a small gate in front of every job: before it starts, read both the weekly usage and the rolling 5-hour session usage for the provider, run the job only if both are at or under 90%, and otherwise send it to the next provider on the list. The part people skip is what happens when the usage check itself fails. An error isn't a pass, so the job falls through to the next provider rather than running blind into a cap. I wrote it up as a short lab note.

https://acidlemon.com/posts/2026-11-02-check-both-meters-before-the-job-runs/