Haiku 5.5 Batch API

The Haiku 5.5 Batch API is for work that can finish asynchronously: a collection of independent records, summaries or classifications whose results do not need to arrive inside a live chat interaction. The application submits a group, tracks its lifecycle and reconciles each item when results become available.

Do not confuse a provider batch job with sending several requests concurrently from a browser. They have different ownership and recovery models. This guide describes Anthropic's Message Batches interface; it does not mean that the website's comparison workspace uses that provider feature behind every multi-row comparison.

Decide whether the work can wait

Before choosing the Haiku 5.5 Batch API, write down the actual delivery deadline. A nightly document classification job can tolerate delayed completion differently from a support agent waiting for a suggested reply. A lower per-request price is not useful if the result consistently arrives after the operational decision has already been made.

Check whether items are independent. If the prompt for item two depends on the accepted output of item one, putting both into the same independent request collection does not establish that dependency. Split the workflow into stages, with a validation boundary between them, or use a different execution model.

Estimate how a partial result affects the business. A report may require every department's record before publication, while a tagging task can accept completed records individually. Choose that policy in advance so the job runner knows whether to wait, publish a partial result or escalate missing items.

Assign stable item identities

Each Haiku 5.5 Batch API request needs an identifier that maps back to your application record. Anthropic documents a custom identifier on each request and warns that results need not arrive in input order. Match by identity, never by the position of a line in the returned file.

Use opaque record references rather than customer email addresses or sensitive document names. Keep the mapping in your own access-controlled store. Include a source revision in the application record so a retry cannot silently apply an answer generated from yesterday's document to today's edited version.

The following authored payload illustrates two independent requests. It omits authentication and the surrounding submission call. The identifiers are fictional, and no paid batch was submitted to produce this example.

{
  "requests": [
    {
      "custom_id": "record-a-revision-1",
      "params": {
        "model": "claude-haiku-5-5",
        "max_tokens": 2048,
        "messages": [{ "role": "user", "content": "Label as billing or technical: Please resend my receipt." }]
      }
    },
    {
      "custom_id": "record-b-revision-1",
      "params": {
        "model": "claude-haiku-5-5",
        "max_tokens": 2048,
        "messages": [{ "role": "user", "content": "Label as billing or technical: The login button does nothing." }]
      }
    }
  ]
}

Validate before submitting the collection

Run local schema checks across the complete collection before submitting it. Detect duplicate identifiers, empty input and unsupported request fields. A malformed item should not disappear into a large job where its failure is noticed only when a downstream report is missing a row.

Test the task on a few representative records through a controlled workflow before scaling. This is a task-quality check, separate from payload validation. A syntactically valid request can still ask an ambiguous question or produce labels your application does not understand.

Record a manifest of the submitted items, their source revisions and prompt version. Once the provider accepts the job, preserve its job identifier against that manifest. A local process crash should not force you to choose between abandoning the job and submitting the entire collection again without knowing whether the first one exists.

Track job state outside the browser

A Haiku 5.5 Batch API job should survive the user closing a tab. Persist its status and ownership on the server. The browser can request a current snapshot, but it should not be the only place that remembers the provider job ID or decides whether completion has been processed.

Use the provider's supported status retrieval mechanism with a bounded recovery policy. Avoid one permanent tight polling loop per browser tab. Coordinate recovery work so several visits to the same job do not create several competing workers, each attempting to import and settle the same results.

Expose meaningful states such as submitted, processing, importing and complete in your own application. A provider job that has finished may still require result download and application validation. Showing complete before those steps succeed can make the interface promise records that are not actually available yet.

Reconcile every result independently

The batch-processing reference describes item-level outcomes, including successful and unsuccessful results. Handle those outcomes before parsing the model response. A failed item is not an empty successful answer, and an expired request is not evidence that the source contained no useful information.

For successful Haiku 5.5 Batch API items, apply the same completion and semantic checks as an interactive request. Validate labels, extracted fields or summaries against the task contract. Batch transport changes when results arrive; it does not make generated content automatically suitable for storage.

Import results idempotently using the job and item identities. If the import worker crashes halfway through a results file, rerunning it should preserve accepted rows and finish the remainder without duplicating records or usage charges. Store import progress in a way that distinguishes processed failures from items not yet examined.

Retry only the work that needs another attempt

Separate retryable operational failures from invalid inputs and rejected content. An unsupported parameter needs a request change. An answer failing a business rule may need prompt revision or human review. Re-submitting either unchanged can reproduce the same failure while making the job appear active.

For a Haiku 5.5 Batch API retry, create a new attempt record linked to the original item. Preserve the previous outcome and source revision. This makes it possible to calculate total effort per accepted record and prevents a retry from rewriting the history of a completed or reviewed result.

Do not automatically resubmit the entire original manifest because a few items failed. Select the eligible subset deliberately, and confirm that none of those items were accepted through another recovery path. Concurrent recovery workers need the same ownership discipline as the initial importer.

Account for asynchronous work honestly

Use returned usage and the current documented batch rate categories when reconciling cost. A batch discount does not mean the job has no output cost, and a large output allowance is still a ceiling rather than a prediction of actual consumption. Keep manufacturer pricing separate from your product's user-facing credit policy.

Cancellation also needs reconciliation. A cancellation request may arrive after some items have already completed. Preserve the outcomes the provider actually reports and settle them according to your policy; do not assume that pressing cancel makes every item unprocessed or unbilled.

For Haiku 5.5 Batch API reporting, show accepted, failed and unresolved counts separately. A single "finished" count can hide invalid records, expired items or results awaiting review. Operators need to know whether the next action is a corrected submission, a manual check or simply waiting for an import to finish.

Test recovery before increasing volume

Use synthetic result files containing out-of-order items, duplicate entries and a mixture of outcome types. Stop the importer halfway through, restart it and confirm that the final accepted set is identical to an uninterrupted run. Verify that unknown item IDs are rejected rather than attached to a convenient source row.

Then test permissions on status and download endpoints. Knowing a provider job identifier must not give another user access to its contents. The Python guide covers local record handling, while data extraction covers field-level acceptance. A durable batch workflow needs both reliable bookkeeping and a clear definition of a correct result.