Batch API & token counting for cost control

I once ran a ten-thousand-lead scoring job as ordinary real-time calls, in the middle of the workday, one after another. It cost full price, it bumped into rate limits, and it tied up the afternoon, all for a result nobody needed until the next morning. I was paying rush rates and fighting for capacity to deliver something that could have run quietly overnight for about half the money.

Two features would have saved me: the Batch API, for work that can wait, and token counting, for knowing the cost before I hit go. This guide covers both, because at scale they are the difference between GTM automation that is quietly affordable and one that produces a bill nobody wants to explain.

Two levers: batch and measurement

Cost at scale comes down to two questions: are you paying the right rate, and do you know what you are spending. The Batch API answers the first, by offering a big discount for work that does not need an instant answer. Token counting answers the second, by letting you measure a request's size before you send it and estimate a job before you run it.

Most surprise bills come from ignoring one or both: running batchable work at real-time rates, or running a large job blind and finding out the cost afterward. Pull both levers and cost becomes something you decide on purpose rather than discover on an invoice.

The Batch API: half price for patient work

The Batch API takes a large set of requests, processes them asynchronously, and returns the results within a window, in exchange for a substantial discount, roughly half the cost of the same calls made in real time. You are trading immediacy for money: you give up an instant answer and get back a much smaller bill.

That trade is perfect for a huge amount of GTM work, because so much of it is not actually urgent. Scoring the week's inbound, enriching a target list, generating drafts for a campaign, none of these needs to be done this second. They need to be done by morning, which is exactly what batch delivers, cheaply.

How batch works

The shape is submit, wait, collect. You assemble your requests, submit them as a batch, and the job runs asynchronously on Anthropic's side. You poll for completion or come back later, and when it is done you collect all the results at once. It is a different rhythm from a real-time call, less a conversation, more a job you queue and pick up.

That rhythm is why it fits scheduled automation so naturally. A nightly job submits the day's work, and by the time anyone is looking, the results are ready to be written wherever they go. You are not sitting and waiting on each call; you are queuing a pile of work and retrieving the finished stack.

When batch fits, and when it doesn't

Batch fits whenever no one is waiting on the individual answer: bulk scoring, bulk enrichment, bulk generation, anything that runs on a schedule. If the result can be ready in a window rather than a moment, batch it and take the discount. This is most of the back-office volume in a GTM stack.

It does not fit anything interactive. A website assistant, a live chat, a rep asking for a brief right now, these need the answer immediately, so they stay real-time, discount or not. The rule is simply about who is waiting: if a person needs it now, real-time; if it can be collected later, batch.

Token counting: measure before you spend

Token counting lets you find out exactly how many input tokens a request will use before you send it. Because tokens are how the API is priced, that is the same as knowing the cost before you commit. It turns pricing from a thing you discover after the fact into a thing you check up front, the way you would check a quote before approving a job.

This is most valuable right before a big run. Counting the tokens on a representative request tells you what one call costs, and from there the arithmetic to a full job is simple. You never have to run ten thousand calls to find out what ten thousand calls cost.

Estimating a job before you run it

The practical routine: take one realistic request, count its tokens, apply the pricing for your model to get a per-call cost, and multiply by the number of calls. Halve it if the job will run through batch. In a minute of arithmetic you have a defensible estimate for a job that might cost cents or might cost real money, before a single call goes out.

This is the habit that keeps scale from being scary. A ten-thousand-call job is not a leap of faith when you have costed a single call and multiplied. You approve it the way you would approve any spend, with a number in front of you, and you catch the jobs that are secretly expensive before they run, not after.

The estimate is also how you decide between models for a job. Count the tokens once, then run the per-call arithmetic for a cheaper and a stronger model side by side. Often the cheaper model is fine for the task and the cost difference at scale is large, and seeing both numbers next to each other makes that call obvious instead of a guess.

• Count the tokens on one realistic request for the job.
• Multiply by your model's per-token price to get a per-call cost.
• Multiply by the number of calls for the job total.
• Halve it if you will run the job through the Batch API.

Batch also sidesteps rate limits

There is a second reason batch beats real-time for bulk work, beyond price: rate limits. Firing ten thousand real-time calls as fast as you can means hitting the ceiling on requests per minute and building retry logic to nurse the job through, which is exactly the afternoon I wasted. A batch hands the whole pile to Anthropic to schedule, so you are not fighting the rate limit call by call, the job just runs.

So batch buys you three things at once: about half the cost, no rate-limit wrestling, and no babysitting. For a genuinely large job the throughput alone is worth it, never mind the discount. If you have ever written backoff-and-retry code to push a big job through real-time, that is the code batch lets you delete.

Where it goes wrong

The expensive habit is defaulting everything to real-time, so batchable work quietly pays double. Nobody decides to overpay; it just happens because real-time is the path of least resistance and no one asked whether the answer was actually needed now. A quick who-is-waiting check on each job catches it.

The other is running large jobs blind, no token count, no estimate, and learning the cost from the invoice. At small scale that is harmless; at scale it is how a job costs ten times what anyone expected. Counting tokens takes a minute and removes the surprise entirely, so skipping it is a false economy.

• Running batchable, non-urgent work at real-time rates and paying roughly double.
• Launching a large job with no token count or cost estimate, then reading the bill in shock.
• Batching genuinely interactive work, making a person wait for a discount that does not matter.
• Forgetting the batch discount when estimating, and over-budgeting patient jobs.

The GTM version

The clean split for a GTM stack: everything the customer or a rep touches live stays real-time, and everything that runs on a schedule for a pile of records goes to batch. Scoring the week's inbound, enriching the target list, generating a campaign's drafts, all of it queued as a nightly batch at half the cost, all of it costed in advance with a token count so there are no surprises.

The ten-thousand-lead job that ate an afternoon at full price now runs overnight for about half, and I knew the number before I started it. Batch what can wait, measure before you spend. What job are you running at rush rates that nobody was actually waiting on?

How to set it up

Frequently asked questions

Sources & further reading

• Batch processing (Anthropic docs)
• Token counting (Anthropic docs)

Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.