Once a team sees the fifty percent batch saving, the temptation is to push it too far, until a job a user actually waits on gets moved to the asynchronous path. Here is where batch helps, where it breaks the experience, and how to set the boundary on purpose.
Batch processing is the easiest fifty percent saving on Claude, which is exactly why it gets pushed too far. Once a team sees what batch does to the bill, the temptation is to route more and more work through it, and somewhere along that line a job that a user actually waits on gets quietly moved to the asynchronous path. The saving looks great on the invoice and terrible in the product. This guide is about the boundary: where batch helps, where batch breaks the experience, and how to decide which side of the line a given workload sits on before the decision shows up as churn or a support backlog.
Every workload reduces to one question. Is a person waiting on this result the instant it is produced? If no one is waiting, batch is free money, because the same model returns the same output later at roughly half the rate and nothing is lost. If someone is waiting, batch is not an optimization, it is a latency regression you are paying yourself to inflict. The reason teams get this wrong is that the question is about the consumer of the output, not about how the code happens to be written. A request can run on the real time path purely out of habit while no user waits on it, in which case it belongs in batch. And a request can be buried inside a pipeline yet sit directly in front of a waiting person, in which case it must stay real time no matter how tempting the discount.
The failures are predictable once you know to look for them. Interactive chat and live assistance are the obvious cases: a user typing to Claude and watching for a reply cannot be served from a batch window. Less obvious are the workflows that feel like background jobs but are not. A document a user just uploaded and is staring at a spinner to see processed is a real time job even though the same document type runs fine in batch overnight. A checkout or onboarding step that calls Claude inline is real time because the user cannot proceed until it returns. An agent loop where each step depends on the last and a human is watching the agent work is real time end to end. Anything inside a request and response loop with a person on the other side breaks when you batch it, and the breakage shows up as abandoned sessions, angry tickets, and a metric nobody connected back to the change.
On the other side of the line sits a large amount of work that runs real time today purely because it always has. Overnight processing of the day's data. Periodic reports and digests that someone reads in the morning. Bulk classification, tagging, and extraction across datasets. Content enrichment that prepares material for later use. Backfills and reprocessing when a prompt or model changes. Evaluation and test runs that score behavior offline. In all of these the output is consumed by a system or read by a person hours later, so the real time premium buys speed nobody uses. The skill is auditing honestly, because the share of work that can move is almost always larger than the team's first guess, and the share that must stay real time is smaller and more specific than the fear of breaking things suggests.
The answer is rarely all batch or all real time. The strongest designs split a single feature across both paths. A document platform serves the interactive preview a user is waiting on through real time, then runs the deeper full document analysis in batch and notifies the user when it is ready. A support tool answers the live question in real time but enriches and categorizes the full ticket history in batch. A research assistant streams the immediate answer and queues the exhaustive citation pass for batch. Designing the experience around the waiting test, rather than around a single global setting, is what lets you claim the batch discount on the asynchronous majority of a feature while protecting the real time moment the user actually feels. This is a product decision as much as an engineering one, and getting it right is worth a strategy conversation before you ship.
The fix is not to retreat from batch, it is to set the boundary on purpose rather than by accident. Map every Claude call in the product to a consumer, then label each one waiting or not waiting based on whether a person needs the result the instant it is produced. Move everything in the not waiting column to batch, leave everything in the waiting column on real time, and for features that contain both, split them deliberately along that line. Then instrument it: watch latency and abandonment on the real time paths and watch cost on the batch paths, so you can see immediately if a change pushed work across the line. Done this way, batch captures its fifty percent on the asynchronous majority of your workload without ever touching the moments your users feel.
Where you draw the batch line directly shapes the number you should commit to Anthropic. A workload split correctly into batch and real time costs materially less than the same volume run entirely real time, and your committed spend should reflect the optimized, correctly split cost rather than the unoptimized one. But the split has to be right, because a team that batched too aggressively and then walks it back to fix the experience will see its real spend rise back toward the real time number after the commit is already set. We sit between you and Anthropic, and part of what we do is pressure test the batch boundary so the commitment reflects a workload design you can actually live with in production. If you are weighing how far to push batch before a renewal or a new commit, that is exactly the kind of decision worth talking through with us first.
The token optimization playbook covers the waiting test in detail, the hybrid patterns that protect the experience, and how the batch boundary feeds the commit math. If you would rather walk your specific workloads through with someone on the buyer side, book a strategy call and we will help you set the line before it costs you either money or users.
Book a strategy call and we will help you split batch from real time so you claim the saving without touching the moments your users feel.
Book a Strategy CallWeekly intelligence on Anthropic pricing moves and the buyer side counters that work.