Batch vs real time: the cost tradeoff.

There are only two ways a Claude request can run, and the choice between them is the single largest pricing decision most teams never consciously make. The real time path returns an answer the instant the model finishes, which is what an interactive user needs and what every first integration defaults to. The batch path accepts the same request, processes it within a longer window, and returns the same output at roughly half the real time rate. The model is identical. The prompt is identical. The answer is identical. The only thing that differs is how long you wait, and for a large share of enterprise work nobody is waiting at all. That is the tradeoff in one sentence: you are paying a speed premium on work that gains nothing from speed.

The reason this matters so much is that the premium is not small. Real time costs roughly twice what batch costs for the same tokens. When a workload that could have run in batch runs real time instead, you are paying double for a result that arrives sooner than anyone needs it. Multiply that across the overnight reports, the bulk classification jobs, the enrichment pipelines, and the evaluation runs that fill a typical enterprise token budget, and the unclaimed discount becomes one of the largest single line items in the entire bill. It is also one of the easiest to claim, because batch asks for no quality compromise and no rewrite of your prompts.

What you actually trade

It helps to be precise about what changes when you move a workload from real time to batch, because the fear of a hidden quality cost is what keeps teams on the expensive path. There is no quality cost. The same model answers the same prompt and produces the same output. What you give up is immediacy. A batch job is submitted as a set of requests and the results come back within a longer service window rather than in the moment. For an interactive feature that window would be unacceptable. For an overnight report that a person reads the next morning, the window is invisible. The tradeoff is latency for price, full stop, and on asynchronous work latency is a resource you were never using.

This is why batch is the rare optimization with genuinely no downside on the workloads it fits. Most cost levers involve a real decision: a cheaper model that might miss on the hardest cases, a shorter prompt that might drop useful context, a cache that adds engineering work. Batch involves no such decision on work that is already asynchronous. You are simply declining to pay for a speed you were throwing away.

The one question that decides the path

Every workload sorts cleanly once you ask it honestly: is a human or a live system actually waiting on this result the instant it is produced? If yes, it belongs on the real time path and the premium is the price of a good experience. If no, it belongs in batch and paying real time is pure waste. The discipline is in the honesty, because a surprising amount of work runs real time not because anyone is waiting but because the integration was built that way and nobody revisited it. The work was urgent once, or seemed urgent, and the real time default calcified into habit long after the urgency was gone.

When you apply the waiting test across a real workload map, the split usually favors batch far more than the team expected. The clearest batch candidates are scheduled and bulk jobs: overnight processing of the day's data, periodic reports and digests, bulk classification and tagging across large datasets, content enrichment that prepares material for later use, backfills when a prompt or model changes, and evaluation runs that score behavior offline. In every one of these, the output is read hours later or consumed by a downstream process, so the real time path buys speed that goes straight into the bin.

What stays on the real time path

Batch is not a universal answer and pretending it is would damage the product. Anything a user is actively waiting on stays real time. Interactive chat, live assistance, anything in a request and response loop where a person is watching the screen for the reply, all of it belongs on the real time path and the premium is justified. The skill is separating the genuinely interactive from the merely habitual, because those are the two categories that get confused. Genuinely interactive work is rightly real time. Habitually real time work is the prize, and moving it is where the saving lives.

Where the tradeoff compounds

The batch decision does not sit alone. It stacks with the other token levers, which is what turns a useful saving into a large one. The batch discount applies on top of whatever model you route to, so a bulk job moved to Sonnet rather than Opus captures the routing saving and the batch saving together. It also combines with prompt caching: a bulk job that reuses a large shared prefix across thousands of items earns the caching discount on the repeated input and the batch discount on the rate at the same time. The levers multiply rather than add, which is why teams that deploy routing, caching, and batch together see aggregate reductions of 40 to 70 percent against uniform real time use on the top model.

• Ask the waiting test of every workload: if no user needs the result this instant, it is a batch candidate.
• Move scheduled jobs, bulk classification, enrichment, backfills, and evaluation runs to batch first.
• Keep interactive and user facing work on the real time path where latency is the product.
• Separate genuinely interactive work from work that is real time only out of habit.
• Run batch jobs on the cheapest model tier that clears the quality bar to stack the savings.
• Cache shared prefixes inside bulk jobs so the batch and caching discounts compound.

Why the tradeoff belongs in the contract

Sorting your workloads by the waiting test does more than cut the monthly invoice. It changes the number you should commit to Anthropic. Committed spend should reflect the real, optimized cost of your workloads, and a portfolio that runs its asynchronous half in batch costs materially less than the same volume run entirely real time. A buyer who commits before sorting the workloads locks the real time premium into the commitment for the whole term and pays twice over for a habit. A buyer who sorts first commits to a leaner number and negotiates from demonstrated efficiency rather than from a bloated baseline. The order is the lesson: optimize, then commit, never the reverse, because savings found after the commitment is set are stranded inside a figure you already agreed to.

The cost tradeoff between batch and real time is usually the fastest win available, because the answer to the waiting question is already known for most jobs. Our token optimization playbook walks the full method, the waiting test in detail, the workloads that move most easily, and the way batch combines with caching and routing for the compounding saving. Download it below, then list every job that runs real time today and ask, honestly, which of them anyone is actually waiting on.