AI batch cancellation: reconcile partial results

An AI batch cancellation policy should account for requests that finish after cancellation begins. Preserve the batch identifier, wait for the provider's terminal state and reconcile each submitted request with its result before authorising a retry. Assign a separate owner for retained inputs and outputs.

Asynchronous work continues outside the original user's interaction. A useful policy therefore specifies who can cancel it, who may consume late results and what evidence is needed to restart unresolved work. These controls complement AI spending limits, whose thresholds leave batch outcomes to be checked separately.

Authorise cancellation for the exact job

Bind a cancellation request to the provider, organisation or workspace, batch identifier and intended action. Record the reason and the person or system authorised to make it. A cancelled business task may also require the application to stop delivering results that were already generated.

Keep submission identifiers in an application-owned ledger. Include stable per-request identifiers, the input-set version and the destination that would receive each accepted output. Use references and hashes where appropriate, keeping full prompts outside the operational record.

Expect provider-specific state changes

OpenAI's Batch API guide describes a batch entering cancelling for up to ten minutes while in-flight requests complete. It then becomes cancelled, with available partial results accessible in the output file.

Anthropic's cancellation reference uses canceling, followed by ended. In-progress, non-interruptible requests may complete. Anthropic warns that cancellation can leave no requests with a cancelled outcome if those requests could not be interrupted.

Preserve the exact provider state and a separate application interpretation. An application that expects every provider to return a state named cancelled could wait indefinitely for Anthropic's completed cancellation. Agree a bounded polling and escalation procedure from the provider's current contract.

Reconcile results by identifier

Both providers document that output order can differ from input order. Match results to submitted requests using custom_id. Positional matching can attach one request's output to another request's business record.

Anthropic's batch guide distinguishes succeeded, errored, cancelled and expired request results. Successful completion counts and the other final result counts settle when processing of the entire batch ends. A job still in progress needs a pending interpretation.

For OpenAI, retain both output and error files where present. Its guide explicitly records expired requests with a batch_expired error. The sources reviewed here leave the location of cancelled-but-unrun request records unresolved, so require a reconciliation procedure before treating absent output as a confirmed retry candidate.

An ambiguous cancellation response also needs a state read. Repeating the application workflow without checking the existing batch can create duplicate work through a new submission.

Separate generation from delivery and retry

Consider a fictional batch producing internal document summaries. A policy change arrives after submission, and the owner cancels the job. Some summaries may still finish. The application needs a rule for retaining, reviewing or discarding those results before any downstream delivery.

Create a retry set only after reconciliation, with explicit handling for unresolved requests. Preserve the relationship between the original and replacement jobs. A downstream write, notification or payment needs its own authority check even when the text generation succeeded.

Anthropic states that errored, cancelled and expired requests are not billed. OpenAI documents charges for completed requests when a batch expires. We have not verified a complete OpenAI cancellation-billing rule from the reviewed sources, so obtain that answer before estimating the cost of a stopped job.

Give files their own retention plan

OpenAI's guide says output files are automatically deleted 30 days after completion. Its create-batch reference also offers output and error file expiry measured from file creation. Meanwhile, its data-controls table describes batch application state as retained until deletion.

Track these objects and clocks separately. Confirm the treatment of the batch record, input file, output file, error file and any downloaded copy. A cancellation response establishes no universal deletion outcome for that collection.

Anthropic says batch results remain available for 29 days after creation. Its deletion reference permits deletion only after processing has ended. Include retrieval and deletion deadlines in the job record, with an owner for each copy.

The acceptance exercise should use harmless synthetic requests and assert final provider state, per-request reconciliation, downstream delivery count and retained-file handling. These are proposed checks based on documentation, with no account test or cancellation-time guarantee established here.

Review your AI workflow policies with Promptective.