Managing jobs
Open a job from the Jobs page to change its settings, stop its automatic runs or delete it. Each row’s ⋯ menu also offers Run now and Settings. Starting runs, the sandbox and learning have guides of their own: Triggers and schedules, Sandboxes and How jobs learn.
The job page
Section titled “The job page”The job page has six tabs:
- Overview: the suggestions waiting for you, performance over 7, 30 or 90 days and the Graduation chart.
- Runs: this job’s runs (Reading a run).
- Playbook: the learnings, toolkit scripts and main script the job built up, with every earlier version (How jobs learn).
- Environment: the job’s Dockerfile and its image builds (Sandboxes).
- State: the values runs keep between runs (Job state).
- Settings: everything you can change, one card per topic.
The Graduation chart on Overview shows each run’s cost or tokens as a bar colored by its mode, its duration as a line, and each new playbook version as a marker. Click a bar to open that run.
Editing a job
Section titled “Editing a job”On the Settings tab, a card’s Save button saves that card’s fields and nothing else. Leaving the page drops the edits you haven’t saved, and a saved change applies to runs that start afterwards.
In the General card you edit the name, the instruction and the model. Saving a changed instruction compiles the goal, success criteria, inputs, outputs, services and side effects again, so the save takes as long as a compile. The name, schedule, network and Dockerfile keep what you set. To keep a spec you edited by hand, turn off Rebuild the spec, which appears as soon as you change the instruction.
In the Spec card you edit the goal, success criteria, inputs, outputs and side effects, and saving it costs no model call. You attach and detach MCP servers in the MCP servers card (MCP servers).
A graduated job runs its main script, which doesn’t read the instruction, so the next run after an edit still follows the old one. With Self-improve on, reflection on that run updates main. To skip that run, update the main script yourself in the Run scripts card on the Playbook tab, or turn off Graduate to a script until you have. A new or renamed output makes Scripted runs fall back to the agent until main reports it, and the Spec card warns you about that.
Job settings lists every field with its default and allowed values.
The model
Section titled “The model”Model in the General card sets the model that drives the agent for this job, and its list holds only enabled models. Workspace default follows the Agent model under Settings → General → Default models, and a job whose own model you disable later falls back to it. Providers, prices and the other model roles have their own page, Models and costs.
Limits per run
Section titled “Limits per run”Every run has a time, a turn and a cost limit, and its sandbox gets a fixed share of CPU and memory. You set them per job in the Sandbox card, where an empty field follows the workspace default under Settings → General → Sandbox defaults.
| Setting | Default | A run that reaches it |
|---|---|---|
| Timeout | 900 seconds | ends as Timed out. Waiting for the job’s image build counts, waiting in the queue doesn’t |
| Max turns | 60 | ends as Failed. A turn is one model call |
| Max cost per run | 2 USD | ends as Failed. 0 turns the limit off |
| CPUs | 1 | runs slower, since Docker throttles the sandbox to that many CPUs |
| Memory | 1024 MB | loses the command that ran out, which the kernel kills. The sandbox has no swap |
After a run that ran out of memory, time or turns, reflection suggests higher limits, which you apply with one click (How jobs learn). Models and costs explains what the cost limit counts and the workspace’s daily spend limit.
Stopping automatic runs
Section titled “Stopping automatic runs”To keep a job from running by itself without deleting it, click Pause in the job header. The button shows on jobs with a schedule or a webhook token, the two things that start runs without you.
Mode and learning
Section titled “Mode and learning”The Learning card holds two switches, both on for a new job.
Self-improve lets reflection turn what worked into new playbook versions after runs (How jobs learn). Turn it off to stop reflection after runs, along with what it spends, and the job header shows Learning off. The playbook then changes only through your own edits and Learn from this run on a run page.
Graduate to a script lets the job move from the agent to a main script once its runs repeat (How jobs learn). Turn it off for a job that needs the agent’s judgment on every run, or whose side effects you don’t want a script to handle. Its runs then never go past Assisted, and reflection leaves main alone. Turning the switch back on makes the next run Scripted again if the playbook has a main script.
Job state
Section titled “Job state”Job state is a set of key-value strings a job keeps between runs, such as the last item it reported. Runs fill it without you asking: the agent saves what the next run needs to skip finished work or spot a change, like the newest item handled or the IDs already reported.
The State tab lists every entry. Add one with Add entry, and edit or delete one from its row’s ⋯ menu. Runs can’t delete keys, so this tab and the API are the only places to remove one. Deleting the key a watcher compares against, for example, makes its next run behave like its first.
A job keeps up to 1,000 keys and 16 MiB of state, with values of up to 1 MiB. All runs of a job share one state, so runs in Parallel can overwrite each other’s values.