1 added, 1 removed. Audit A to A.
---
name: bulk
description: "Batch API processing for 50% cost savings on non-urgent bulk analysis. Triggers on: batch, bulk process, batch API, cheap bulk, process many, overnight analysis, 50% savings."
---
# Bulk Batch Processing
**IMPORTANT: Start your response with a context preamble.**
Call `help_lookup(topic="bulk", mode="preamble")` and display
the returned `preamble` text as a blockquote. Then tell the
user they can say "tell me more" for a step-by-step guide, or
answer the scoping questions below to proceed.
If the MCP call fails, fall back to:
> **Bulk** — Submits tasks to the Anthropic Batch API for 50% cost savings. Runs asynchronously (up to 24h), so it's ideal for non-urgent, high-volume analysis rather than interactive work.
## Scoping
Before submitting, ask:
1. **What to batch**: "Which tasks should I batch — e.g. a
workflow run across many files, or many independent
analyses?"
2. **How many / which targets**: "List the items (files,
modules, or task inputs) to process."
3. **Urgency check**: "Batch results take up to 24h. Is
non-urgent turnaround acceptable? If you need it now, run
the single-shot workflow instead."
## Execution
### Shared command workspace (preferred)
Open adapter `bulk` with either the provider-ready `requests` list or an
existing `batch_id`. Present the widget or returned Markdown. New submissions
must consume the bound, explicitly confirmed `submit_batch` action before
calling `analyze_batch`; a reconnect uses the read-only `check_batch` action.
Publish the real provider response as `submission_result` or `status_result`.
Only a response with the exact accepted task count and a non-empty batch id may
render as submitted. Rejections and timeouts must render “did not submit” (or
“did not complete” for status), never a synthetic batch id. Preserve the same
decision and receipt in compact text when the shared tools are unavailable.
The workspace status receipt completes the interactive invocation; `pending`
does not mean the remote work completed. Reinvoke later with the returned
`batch_id` to reconnect.
Call the `analyze_batch` MCP tool with a `requests` array,
one entry per task:
```
analyze_batch(requests=[
{"task_id": "<unique-id>", "task_type": "<e.g. analyze_logs>",
"input_data": {...}, "model_tier": "capable"},
...
])
```
- `task_id` and `task_type` and `input_data` are required per
request; `model_tier` is optional (`cheap` / `capable` /
`premium`, default `capable`).
- - **Premium tier policy:** interactive premium = `claude-fable-5`
+ - **Premium tier policy:** interactive premium = `claude-fable-5-1`
(with server-side opus fallback); **batch premium =
`claude-opus-4-8`** — the Batch API rejects the `fallbacks`
param, so fable models are downgraded at request-build time.
- The call returns a batch id and submits asynchronously — it
does not block for results.
## Output
Report back:
- The **batch id** and submitted task count.
- That processing is asynchronous (up to 24h) at 50% cost.
- How to retrieve results later (re-invoke and reference the
batch id).
## When to use
- Multi-workflow analysis runs, project-wide audits, nightly
/ CI jobs — anything non-interactive where cost matters more
than latency.
- For a single urgent analysis, use the matching workflow
skill directly (e.g. security-audit, bug-predict) instead.