Half Price for the Same Model: Read the Batch API Terms First

Every major model provider will charge you half price for the same model, same prompt, same output quality. You pay for it in time, not in quality.

That is the whole trade in batch APIs. Anthropic charges "50% of the standard API prices" for the Message Batches API (Anthropic's batch docs). OpenAI lists a "50% cost discount compared to synchronous APIs" (OpenAI's batch guide). Google processes Gemini batch jobs "at 50% of the standard cost" (Gemini batch docs), with per-model batch columns published on the pricing page, such as Gemini 2.5 Flash-Lite at $0.10 standard against $0.05 batch.

The terms, side by side

Two details change the math. First, on the Anthropic side, prompt caching stacks with batching. The docs are explicit that both discounts combine, with the caveat that cache hits are best effort under concurrent processing and land somewhere between 30% and 98% depending on traffic. Anthropic suggests the 1 hour cache duration for batch jobs because batches usually run past the 5 minute default. Second, requests that expire at the 24 hour mark are not billed at all. For OpenAI batch pricing I found no first-party claim about caching stacking, so do not budget for it.

Batch is not a stripped-down endpoint either. Vision, tool use, system messages, multi-turn, and extended thinking all work. Streaming, Fast mode, Threads, and cache hints do not.

The qualifying test

One question sorts your workloads: does anyone wait on this output within the hour? If yes, keep it synchronous. If no, you are paying double for nothing.

Things that usually pass the test:

• Moderation backlogs. An engineer on Hacker News described moving a review pipeline to batch and accepting "that content can take 24 hours to be audited" (HN thread).
• Bulk tagging and captioning. Someone in the same thread ingested a large image set to extract descriptions and search tags, and pointed out that once the prompt is settled, the batch API just runs the pipeline. OpenAI's cookbook does the same thing on a furniture dataset and names marketplace enrichment and support-ticket categorization as ideal cases.
• Archive summarization. One commenter put it as summarizing decades of historical documents, where the queue is large enough that urgency stops mattering.
• Embeddings backfills, which nobody is watching in real time.
• Some coding work. A February 2026 Show HN covered an MCP routing Claude Code tasks to the Batch API, with the author reporting 30 to 60 minute turnarounds on terraform work, code reviews, and docs (thread), while also saying bills "remain high even with this, batch is not a magic bullet."

Scale is not the constraint. One HN commenter reported submitting tens of millions of requests at a time and never waiting more than a couple of hours.

What actually stops people

Iteration risk. In that same Gemini thread the complaint was direct: "you have to be pretty darn sure that your job is going to do exactly what you want to be able to wait 24 hours for a response." The same person said getting even 1% of results back quickly would have made a real difference. There is no partial return and no progress signal, so a prompt bug costs you a full cycle instead of ten seconds.

The workaround is unglamorous. Validate on a small synchronous sample, freeze the prompt, then submit the bulk job. The discount only pays off on prompts you have stopped editing.