Skip to main content
Autumn tasks keep running in the cloud after your request returns, which makes them a natural fit for a worker: start the task, persist the task_id, and let the worker die and come back without losing anything. This recipe is the wiring that makes that safe.

1. Check credits before a batch

A worker that starts fifty tasks against an empty balance produces fifty 402s. Check once per batch, not per task:

2. Start the task, then persist the id first

The task_id is your resume point. Write it to your database before doing anything else with the response. If the worker crashes one line later, the task is still running in the cloud and the stored id is how you find it again.
Decision: if your jobs have a known shape (fixed columns, repeatable brief), start from a spec with /task/start instead. See The task model.

3. Poll with the full terminal check

Workers are exactly where a sloppy exit condition hurts most, because nobody is watching the loop spin. Use the complete check from Task lifecycle, including the deleted and out_of_credits cases, and poll on a lazy interval; a research task does not need sub-second updates.

4. Serialize writes per task

A task runs one turn at a time, so two workers continuing the same task_id produce a 409, not a queue. Route all writes for one task through one worker (or take a per-task lock), and treat 409 as “try again after the current turn”, never as a failure. See Errors.

5. Land the rows

Fetch the rows, flatten the cells into your own schema, and keep _sources if anything downstream needs to audit a value:

Crash recovery

On restart, reread the stored ids and resume polling; the tasks never stopped. If you lose the ids entirely, GET /task lists recent tasks so you can reconcile against your queue.

Task lifecycle

The terminal check this worker depends on.

Follow-up tasks

Sending refinements to a task the worker already finished.