Never let a robot spend your money while you sleep

What happened and why it matters

The difference between a hobby and a bill is whether anything you built can spend money while you are asleep. Once an automatic job can reach a paid service, you have handed a credit card to something that does not get tired, does not get bored, and will happily keep trying all night.

This is not a warning about enormous disasters. Those get noticed. The dangerous version is quiet and small: a scheduled job that costs a little every night and never tells anybody.

You do not notice a slow leak until it has been running long enough to matter, because nothing about it ever looked wrong.

There are four moves that fix this, and the order is deliberate, because each one is worthless without the one before it.

One: see it

You cannot manage what you cannot look at. Before any cleverness, record what every paid request cost and put the total somewhere you will actually see. Not a file you would have to remember to open. A number on a page you already look at.

Almost everybody who gets surprised by a bill was flying blind, not being reckless.

Two: predict it, then pause

Before a big job runs, estimate what it will cost, and set a number that stops it.

And measure with the tool's own counter rather than your mental picture. My worst predictions all came from estimating the work myself instead of asking the software what it was actually about to process.

Three: check the environment, not just the settings file

This one cost me real money for an embarrassing reason.

I confirmed the settings file held no credentials and concluded the job could not possibly spend anything. It spent anyway, because the key it found was sitting in the surroundings the program ran in, set somewhere else entirely and inherited without anyone noticing.

The settings file was genuinely clean. I had checked the wrong thing with complete confidence.

Four: fail cheap, cap, and cage

Set every automatic job to use the free or local option by default, and make the paid one an explicit choice rather than a fallback. A job that quietly upgrades to the expensive path when the cheap one is unavailable is the exact shape of a surprise bill.

And if a job must never spend, do not rely on it choosing well. Remove the keys from its surroundings entirely, so the expensive path is unreachable rather than merely discouraged.

That last distinction is the whole discipline. Discouraged means it will happen eventually. Unreachable means it cannot. Anywhere you can turn the first into the second, do it, and then you get to stop worrying about that one forever.

How to do it yourself

Cost visibility, a gate that pauses, the environment check, and how to make the expensive path structurally impossible. None of this needs a particular provider.

1. Record every paid request

def log_cost(source, units, dollars):
    with open("spend.log", "a") as f:
        f.write(f"{time.time()}\t{source}\t{units}\t{dollars:.4f}\n")

2. Total it somewhere you will see it

awk -v d="$(date +%s -d today)" '$1>d {s[$2]+=$4} END \
  {for (k in s) printf "%-18s %.2f\n", k, s[k]}' spend.log | sort -k2 -rn

3. Ask the tool what it is about to process

scope = tool.scan(path, exclude=["vendor/", "node_modules/"])
print(scope.file_count, scope.total_words)

4. Set a ceiling and stop at it

CEILING = 200_000       # what you are willing to spend unattended
est = estimate(scope)
print(f"projected: {est} (floor, expect higher)")
if est > CEILING:
    sys.exit(f"STOP: projection {est} over ceiling {CEILING}")

5. Check the environment, not the settings file

env | grep -iE '_(API_)?KEY|_TOKEN|_SECRET' | cut -d= -f1

6. Make the expensive path unreachable

# in the job definition
UnsetEnvironment=VENDOR_A_KEY VENDOR_B_KEY VENDOR_C_KEY

# and again where it is actually run
env -u VENDOR_A_KEY -u VENDOR_B_KEY -u VENDOR_C_KEY ./nightly-job.sh

7. Verify the cage rather than trusting it

ExecStartPre=/bin/sh -c 'env | grep -ciE "VENDOR_._KEY" | grep -qx 0'

8. Default to free, cap each source

if spend_today(source) > CAP[source]:
    return use_local()        # degrade, never escalate

9. Watch the first unattended run

The first scheduled run after any change is the one that surprises you. Check the spending record the next morning and compare it against your prediction.

That comparison is how your estimates stop being wrong.

Related: give every job its own key, so a limit and a leak both stay contained.