atomic-agent 0.6.3 on macOS arm64 (MacBook Pro M5, 32 GB)
Component: tools/fusion/worker-runner.ts (task claiming / time limits)
Type: bug
What I see
A fusion.delegate call with more tasks than llama-server slots burns the queued tail's whole time budget before those tasks ever reach a slot. The tail comes back max_steps with 0 steps and 0 tool calls after exactly the worker time limit.
Fan-out of 8 tasks, localModels.managed.parallel = 2, worker model gemma-4-26b-a4b, orchestrator claude-opus-5 (openrouter). Per-task rows from fusion.delegate details.tasks[], verbatim:
shell ok steps=5 24.4 min writes=4
camera ok steps=2 16.5 min writes=1
main ok steps=2 21.2 min writes=1
scene1 ok steps=2 12.7 min writes=1
scene2 ok steps=2 14.1 min writes=1
scene3 ok steps=2 21.5 min writes=1
bodies max_steps steps=0 45.0 min calls=0
scene4 max_steps steps=0 45.0 min calls=0
The six leading tasks executed roughly two at a time (12–25 min each), so the two tail tasks could not have been claimed before ~40 min of wall time — at which point their 45-minute budget was already gone. llama-server.log shows no request for either task in that window.
Same shape reproduced the previous day on a qwen-3.8-27b fan-out: coreB came back max_steps with steps=0, calls=0, 45.0 min while coreA held the slots (attempt 1 trace in the gist).
The knock-on cost is real: the orchestrator reads max_steps as "the worker ran out of budget doing the work", re-briefs, and burns another cloud turn on a task that was never attempted.
What I expect
The per-task clock to start when the task is claimed by a worker slot, not when the fan-out launches — or the runner not to admit more tasks than the pool can serve within their budgets. A task that never got a slot should come back distinguishable from one that worked and ran out.
Full artifacts
Session trace (all fusion.delegate invocations with full briefs and outcomes), complete llama-server.log for the window, and the extracted delegate evidence: https://gist.github.com/sosidudku1/a9dc76c2cb34faaebd1c7363e6087e34
atomic-agent 0.6.3 on macOS arm64 (MacBook Pro M5, 32 GB)
Component:
tools/fusion/worker-runner.ts(task claiming / time limits)Type: bug
What I see
A
fusion.delegatecall with more tasks than llama-server slots burns the queued tail's whole time budget before those tasks ever reach a slot. The tail comes backmax_stepswith 0 steps and 0 tool calls after exactly the worker time limit.Fan-out of 8 tasks,
localModels.managed.parallel = 2, worker model gemma-4-26b-a4b, orchestrator claude-opus-5 (openrouter). Per-task rows fromfusion.delegatedetails.tasks[], verbatim:The six leading tasks executed roughly two at a time (12–25 min each), so the two tail tasks could not have been claimed before ~40 min of wall time — at which point their 45-minute budget was already gone. llama-server.log shows no request for either task in that window.
Same shape reproduced the previous day on a qwen-3.8-27b fan-out:
coreBcame backmax_stepswithsteps=0, calls=0, 45.0 minwhilecoreAheld the slots (attempt 1 trace in the gist).The knock-on cost is real: the orchestrator reads
max_stepsas "the worker ran out of budget doing the work", re-briefs, and burns another cloud turn on a task that was never attempted.What I expect
The per-task clock to start when the task is claimed by a worker slot, not when the fan-out launches — or the runner not to admit more tasks than the pool can serve within their budgets. A task that never got a slot should come back distinguishable from one that worked and ran out.
Full artifacts
Session trace (all
fusion.delegateinvocations with full briefs and outcomes), complete llama-server.log for the window, and the extracted delegate evidence: https://gist.github.com/sosidudku1/a9dc76c2cb34faaebd1c7363e6087e34