Run Enterprise-Scale Batch Jobs on the Plan You Already Pay For

Domain 4 · Lesson 4.5 · Structured Output and Grounded Verification

tl;dr The bulk document processing that companies buy developer accounts and per-token contracts for runs on the subscription already sitting on your desk, overnight, with the agent you built and its tools intact. What it will not do is tell you which documents came back empty, and an unattended run hands back a full set either way.

I added a bookkeeper to my switchboard this month. It reads a bank statement, classifies every line on it, and checks what cleared the bank against what my books say happened. In its first runs it found three things I had not found myself: an owner’s draw recorded twice, so the books showed twice that money leaving the business; a credit card payment booked as an expense, which counts every purchase on that card a second time; and a rental property’s tax sitting in the business books, where it belongs to a different entity entirely.

Then I looked at the backlog behind it. Fourteen months of statements, and a folder of receipts going back further. Handled the way it works now, one document at a time with me reading the summary after each one, that is a few weeks of evenings.

So I went looking for how you push a large pile of documents through a model without sitting at the keyboard for each one. There is a standard arrangement for exactly this, and all three of the big labs sell it: Anthropic calls it the Message Batches API, OpenAI and Google offer the same thing under their own names. This is how a company does this work. Somebody opens a developer account, somebody signs off on per-token pricing, somebody builds and maintains the pipeline, and the invoice arrives monthly. The mechanism is simple enough: you write every document out as its own separate, self-contained request, hand over the entire pile in one go, and give up any claim on when the answers come back. Most piles finish within the hour. The only actual promise is twenty-four hours, and anything not reached by then is returned untouched, unanswered, and unbilled.

Three things come off the table when you work that way. There is no follow-up question, because each document gets exactly one question and one answer. There is no correcting it midstream, so a mistake in your instructions was made nine hundred times before you saw it once. And there is nobody at the other end of any individual answer.

What you get in return is fifty percent off. That number is real, it is the same at all three labs, and it is the reason anyone puts up with the rest of it.

None of which matters to you, if you are on a Claude subscription. The fifty percent is a discount on developer pricing, where a company is billed for every page of every document it sends and the bill arrives at the end of the month. A subscription does not work that way. You pay a flat monthly fee, twenty dollars for Pro, a hundred or two hundred for the two Max plans, and running a stack of bank statements through it costs you nothing on top of that. There is no per-document bill for the discount to come off. Getting that discount would mean opening a separate developer account, putting a card behind it, and starting a second, metered bill for work the plan on your desk already covers.

Which is the part I would not skip past. The work in question is the kind a company treats as a project: a procurement conversation, a developer account, a per-token budget somebody has to defend, an engineer to build the pipeline and another to keep it running. You can do the same class of work tonight, on a plan you are already paying for, using an agent you built yourself, and the marginal cost of the run is zero. That is not a cheaper version of the enterprise thing. For a person with a backlog and a laptop, it is the only version that was ever going to happen. My switchboard runs on my subscription. So does my bookkeeper, so does the reviewer that reads my pull requests, and so does the thing that wakes up at 2am when a statement appears in a folder. Nothing in that stack has an API key in it, and adding one would cost me money to get less.

So the interesting question was never how to buy the discount. It was what happens to the work itself once I am not the one reading each answer as it comes back. Every one-at-a-time run has a person at the end of it, glancing at the reply, and that glance has been doing more checking than I realized. A number that looks wrong, a summary that says nothing, a reply that names a document I do not recognize: I catch all of that without ever calling it review. Run nine hundred without me and nobody looks at any single one. I look at a count.

What I am going to recommend is that you run this yourself, overnight, on the subscription you already pay for. That is what my switchboard does at 2am and it costs nothing beyond the plan. It has one weakness, and you should know about it before you start. When a lab processes a pile for you, every item comes back labelled: this one finished, this one failed, this one was never reached. You can see what you actually got. When you run the same work yourself, you get a folder of files, one per document. Some of them hold the work. Some hold a short note saying the job could not be done, sitting in the file where the work should have been. Nothing marks the difference between the two, and either way the number of files is right.

Everything below the line is what I built before I ran my own backlog: the one question that decides whether a job should run unattended at all, the two ways to run it on the plan you already pay for and which one I use for what, and the accounting you have to add yourself because nothing in this path provides it. It ends with a prompt you paste into Claude Code that works out for itself how you are set up, checks which account your unattended run will actually bill, finds every place the run can stall, writes the manifest, then proves the whole thing on one real document and one deliberately broken one before you start. Your files, your agent, your machine, your plan.