Task Execution

A healthy AlphaBase task should render in this sequence:

1. user prompt accepted
2. running/streaming state
3. tool activity and intermediate updates
4. file/tool outputs
5. final completion response

Tool Activity Expectations

Good tool timelines are action-oriented and grouped, for example:

• searched workspace
• explored files
• ran shell checks
• applied edits

Multi-Task Sessions

A single session can accumulate many unrelated prompts over time (a quick question, then an unrelated build task, then another unrelated build task). AlphaBase segments a session’s history into tasks and scopes the active task’s context — both the message history sent to the model and the search_history tool — to that task only. Earlier unrelated tasks in the same session are kept out of the model’s context for the current prompt, so the model does not drift onto a topic from a different, earlier task.

Deliverable Verification

For build-style tasks AlphaBase distinguishes a plan from a finished deliverable. Planning artifacts (for example a SPEC.md or plan.md the model writes to organize its own work) are explicitly not treated as task completion. A turn is only considered complete once a concrete output exists that is non-trivial in size and matches the task’s stated topic.

Recovery And Loop Limits

If a turn ends without a tool call or concrete output, AlphaBase injects a synthetic recovery turn asking the model to finish the work it described. This is bounded on two axes so a struggling model cannot loop indefinitely:

• a hard cap on synthetic recovery turns per task (ALPHABASE_MAX_SYNTHETIC_DELIVERABLE_RECOVERIES, default 3)
• a finite ceiling on total loop steps per task when no other budget applies (ALPHABASE_MAX_LOOP_STEPS_CEILING, default 40)

Once either limit is reached, AlphaBase stops nudging and returns a clear, user-visible terminal message explaining that the deliverable could not be produced, rather than continuing to retry silently. If Smart Router is enabled for the request, the next attempt may escalate to a different model instead of repeating the same one.

Output Integrity Checks

If execution is healthy:

• generated code appears in write/edit artifact blocks
• file paths are concrete and openable
• completion message summarizes what changed

Regression Signals

Watch for:

• intermediate response text leaking into final response area
• abrupt termination before terminal completion message
• duplicate thought/response emissions
• disappearing or flickering streamed content
• a task repeatedly re-planning without ever writing output (see Recovery And Loop Limits above — this should now stop with a clear message rather than loop; if it doesn’t, that’s a regression worth reporting)

Use Troubleshooting for investigation flow, and Launch Gates for how this behavior is tested before a release.