While working on this project, I had to transcribe and edit hundreds of audio files — 145 at first, later almost 400 — using a paid AI service. Each file cost real money. The whole job took hours, sometimes even overnight.

If you’ve ever started a long task where each step costs money, you know the worry. Three problems can happen, and I ran into all three before I learned how to prepare for them.

  1. Costs run wild. Once, I bought the service’s smallest prepaid credit. I watched it disappear in just a few hours. Another time, my balance dropped from $21.80 to exactly $0.00 in the middle of a job.
  2. It crashes halfway through. Your PC goes to sleep, your network has a problem, or your script hits an error on file 86 out of 145. Then you don’t even know which files finished.
  3. You have to babysit it. Sitting and watching a progress bar for three hours is not productive.

Here’s how I made my expensive, large batch jobs safe enough to start and then walk away from. None of these are clever ideas. It’s all about the difference between automation that helps you and automation that hurts you.

Pattern 1 — Make it free to run again (Resumability)

The most important thing for any long task is this: If the job stops, running the same command again should skip everything already done and start again from where it left off.

My first version of the script didn’t do this. When it crashed on file 86, running it again would start from file 1. I had to pay again for the 85 files already processed. That’s how you burn money.

The fix is simple to ask for, even if you can’t code it yourself: “Before processing each file, check if the output for that file already exists. If it does, skip it.” Now, a crash doesn’t cost me anything. When I run the same command again, it skips the finished files in seconds and picks up from file 86. Engineers call this idempotency. It means running something twice does no extra harm. I didn’t know that word. I just knew I didn’t want to pay twice for the same file.

This one thing changes a fragile, three-hour job into something you can stop, restart, and run in parts over several days.

Pattern 2 — Set a strict cost limit (No auto-recharge)

Most paid APIs kindly offer to auto-recharge your balance when it gets low. For a buggy batch job, this is like a trapdoor under your bank account. A loop that accidentally re-processes files will automatically refill your balance and keep spending money while you sleep.

So I purposely do the opposite: I pay a fixed amount upfront and turn off auto-recharge. My balance becomes a hard limit. If something goes wrong, the worst that can happen is the job stops with an “insufficient funds” error. This is exactly what I want. A job that stops when it runs out of money is much safer than one that keeps charging you.

Combine this with resumability (Pattern 1), and failure isn’t painful. You refill your balance, run the same command again, and it keeps going. Your balance acts as both a budget and a brake.

Oh, ElevenLabs let me set a monthly limit. It also let me auto-recharge a set amount if my balance dropped below a certain point. Because of these options, I felt okay using the auto-recharge feature.

Pattern 3 — Check progress (and failures)

A job you can’t see is a job you can’t trust. I made my script output two things.

Live progress, so I could glance at it and know it was alive:

[1/86  1%]  downloading 48 MB → compressing → transcribing...

A summary at the end, so I didn’t have to guess how it went:

── Done ──
Succeeded: 77   Skipped: 6   Failed: 1
Failed (re-run individually):
  <one file>

That list of failures does a lot of quiet work. The job doesn’t have to be all or nothing. The script finishes what it can, then gives me a short list of exactly which tasks failed. Often, it comes with a command to retry just that file. One failed file out of 145 isn’t a disaster; it’s just a footnote. As long as the job tells you which one it is.

Pattern 4 — Expect unstable infrastructure

Working from home means you have to get used to home-level reliability. My script reads files from my NAS over the local network. Sometimes, a read simply timed out. One file errored on the first try, but the same file processed fine when I ran it again. Nothing was “broken”. The network was just busy for a moment.

Two honest defenses:

  • Retry small failures so they don’t stop the whole batch. One slow read shouldn’t ruin a three-hour job.
  • Keep your computer awake. A laptop or PC that goes into deep sleep will pause your work. I make sure my PC stays awake. Terminal jobs can keep running even with the screen off, but full system sleep can stop them.

Add resumability to this, and even a hard crash isn’t a big deal. Anything that stopped will pick up again on the next run.

Main takeaway: Boring stability is the feature

Here’s what I hope fellow non-developers take away from this post. The exciting part of AI coding is the app itself. But what makes automation truly usable are a bunch of boring traits. These are: it can be safely re-run, it won’t bankrupt you, it tells you what it’s doing, and it survives small bumps on a home network.

I didn’t learn these things from a textbook. I learned each one by running into the problem myself. Like a vanished balance, a crash on file 86, or a timeout that wasn’t a real failure. Then I described what I needed to the AI in plain language: “If the job stops, it should skip finished files when I run it again. Don’t auto-recharge unless there’s a monthly cap. Output progress and a summary. Retry network timeouts.” The AI wrote every line. My part was knowing what dangers to look out for, based on my experience.

This is the pattern for this whole project. The AI does the building, and you make the judgment calls about what matters. And nothing teaches you what matters faster than waking up to a zero balance overnight.

If you run costly jobs from home, please subscribe. I’ll keep sharing the boring, expensive lessons so you don’t have to pay for them yourself.

Key Takeaways

  • Resumability is key: If a crashed job is run again, it should skip finished work and keep going. Don’t pay twice for the same file.
  • Turn off auto-recharge unless you have a monthly cap: Pay a fixed amount upfront so a buggy loop stops instead of draining your account.
  • Make it visible: Include live progress, a final summary (succeeded / skipped / failed), and a list of failures you can retry.
  • Expect home-level instability: Retry small network timeouts, and keep your computer awake.
  • You don’t need to code these. You need to know how to ask for them, which usually comes after you’ve been burned once.