Batchwork launches a unified batch API for 7 AI providers

• Hayden Bleasel's launch thread introduced Batchwork as a unified batch wrapper for seven AI providers, with one interface for submission, polling, and result parsing.
• According to Hayden Bleasel's provider format post, the package smooths over incompatible provider batch shapes, including OpenAI JSONL uploads and Anthropic inline request arrays.
• Hayden Bleasel's API design post says each batch item mirrors AI SDK generateText input and adds a customId, which is the bit you need once unordered results come back.
• Hayden Bleasel's server layer post and Hayden Bleasel's Next.js post position the package for offline workloads like evals, migrations, and enrichment jobs, not low-latency user requests.

You can jump straight to the docs, skim the model syntax examples, and inspect the Next.js App Router helper. The small reveal that makes this more than another wrapper is in the server layer post, which adds managed polling, signed webhooks, and durable stores on top of provider normalization.

Batchwork is aimed at the annoying part of batch inference, not the model call itself. As Hayden Bleasel's batch explainer notes, batch APIs are the cheap, wait-until-capacity-is-free lane, but every major provider packages that lane differently.

Hayden Bleasel's provider format post names the mismatch directly:

• OpenAI uses JSONL file uploads.
• Anthropic uses inline request arrays.
• Google, Groq, Mistral, Together, and xAI each expose their own variants.

That makes Batchwork a format normalizer first, and a cost-saving helper second.

The package keeps the request shape deliberately small. According to Hayden Bleasel's API design post, each request follows AI SDK generateText input plus a customId for correlating results after the provider returns them out of order.

Model syntax post adds that model references follow AI SDK conventions too:

• openai.chat("gpt-5.5")
• openai("gpt-5.5")
• "openai/gpt-5.5"

The same post also says provider packages are optional peer dependencies, so you only pull in the adapters you actually use.

The split between script use and production use is one of the more concrete details in the thread. Hayden Bleasel's server layer post shows a simple job.wait().then(() => job.collect()) flow for scripts, then moves production traffic to a server layer with managed polling, signed webhooks, durable stores, and OpenAI native webhooks when available.

That is the part most teams usually end up writing themselves after the first successful demo.

Batchwork also ships a batchwork/next package for App Router apps. According to Hayden Bleasel's Next.js post, it can mount a cron route, track submitted batches, and persist streamed results in onComplete without bouncing a webhook back into your own app.

Hayden Bleasel's install post says the docs cover requests, models, results, server polling, Next.js, and provider adapters, while Hayden Bleasel's workload examples frames the sweet spot as evals, migrations, enrichment jobs, and other high-volume offline runs.