Problem
Alluka displays streamed assistant output and individual tool UI parts, but it does not provide a durable, task-level account of what actually occurred. A completed assistant response can be mistaken for proof that a requested action succeeded, and users cannot inspect a concise chronology of tool activity, failures, approvals, duration, or resource use after the stream ends.
Long-running or autonomous work also has no user-visible execution limits beyond the request-level step and output caps. A task can consume more time or tool activity than the user intended without a task-specific boundary or an explicit explanation of why it stopped.
Feature
Add an execution record for each interactive chat run and automation run, with a readable timeline, objective action evidence, usage reporting, and optional run budgets.
The timeline should present observed lifecycle events in chronological order: task start/end, tool activity, approvals, tool failures, cancellations, and terminal reason. It must distinguish provider/agent claims from independently observable tool outcomes.
The usage view should report only measurements that are available for the run, including duration, model/provider-reported token usage, tool-call count, and context size. Unknown measurements remain unknown rather than estimated as actual usage.
Optional task budgets establish explicit user-selected limits for time, tokens when reported, tool calls, and retries. The resulting execution record explains approaching and exhausted limits.
Expected behavior
- Pure conversational turns remain visually quiet; activity summaries appear only when there is meaningful run evidence.
- Tool successes and failures are counted from observed outcomes, not inferred from the assistant's final prose.
- Completion copy never overclaims that the user's goal was achieved when only action evidence exists.
- Interrupted, cancelled, budget-exhausted, and failed runs have distinct terminal states.
- Usage and budget data are retained with the relevant task and survive reloads.
- The same lifecycle semantics apply to scheduled automation runs and interactive runs.
Why this matters
This makes autonomous behavior inspectable and bounded. It gives users a truthful answer to both "what did it do?" and "why did it stop?" without treating a model response as verification.
References
Problem
Alluka displays streamed assistant output and individual tool UI parts, but it does not provide a durable, task-level account of what actually occurred. A completed assistant response can be mistaken for proof that a requested action succeeded, and users cannot inspect a concise chronology of tool activity, failures, approvals, duration, or resource use after the stream ends.
Long-running or autonomous work also has no user-visible execution limits beyond the request-level step and output caps. A task can consume more time or tool activity than the user intended without a task-specific boundary or an explicit explanation of why it stopped.
Feature
Add an execution record for each interactive chat run and automation run, with a readable timeline, objective action evidence, usage reporting, and optional run budgets.
The timeline should present observed lifecycle events in chronological order: task start/end, tool activity, approvals, tool failures, cancellations, and terminal reason. It must distinguish provider/agent claims from independently observable tool outcomes.
The usage view should report only measurements that are available for the run, including duration, model/provider-reported token usage, tool-call count, and context size. Unknown measurements remain unknown rather than estimated as actual usage.
Optional task budgets establish explicit user-selected limits for time, tokens when reported, tool calls, and retries. The resulting execution record explains approaching and exhausted limits.
Expected behavior
Why this matters
This makes autonomous behavior inspectable and bounded. It gives users a truthful answer to both "what did it do?" and "why did it stop?" without treating a model response as verification.
References