Goals and Side Tasks

Create and edit a goal

A goal is an outcome this conversation should keep working toward. Each conversation has one current goal. Klaus should create one only when you explicitly request it; ordinary tasks do not become goals automatically.

Choose "Goal mode" in the composer's + menu, or pick /goal in the quick commands submenu, to open goal input. Replacing the current goal shows a confirmation and a preview of the new objective; cancelling preserves the draft. The model cannot create another goal over unfinished work, but you can explicitly confirm a replacement or edit the objective. User edits preserve accumulated usage and creation time.

The goal progress row appears above the composer. Click the objective or Edit to open the goal editor in the right panel, inspect the full content and update time, and use Save/Revert or ⌘/Ctrl+S. Long text, pastes, and images can be stored with the objective; the editor loads the complete text. External updates and save conflicts preserve the draft and require recovery, rather than applying an old editor to another goal.

States and controls

State	Meaning and controls
Active	Work can continue; pause, edit, or clear the goal.
Paused	Suspended at your request; confirm resume, edit, or clear it.
Blocked	Work cannot currently progress; resolve the obstacle, then confirm resume, edit, or clear.
Usage limited	The model source's allowance prevents progress; confirm resume after it recovers.
Budget limited	The goal reached its token ceiling. There is no ordinary Resume button; address the budget or objective before deciding what work follows.
Complete	The required outcome has been achieved and verified. Completion and usage stay in history; the live composer row and open goal editor close.

Resuming a paused, blocked, or usage-limited goal explains that work can continue when idle. Cancelling leaves its state unchanged. Clearing a goal prevents later automatic continuation; it does not delete conversation history or undo existing file changes.

The model may report complete or blocked, or pause at your explicit request. It cannot resume itself, increase the budget, or assign usage/budget limits. Before declaring a blocker, it must establish that the same genuine obstacle persisted for at least three consecutive goal turns and that no meaningful work remains possible. Resuming starts a fresh blocker audit. Final execution or allowance errors can also stop automatic work directly; the error remains visible and a stop is not completion.

Continuation, stopping, and accounting

• The engine continues only at a safe idle boundary: an active goal, execution rather than Plan mode, no running or pending work, and no queued user input. Your steering and queued messages take priority. A turn ending does not by itself require another model request.
• Plan mode preserves the goal but suppresses automatic continuation and excludes planning-only usage from goal execution accounting. Reading history or reconnecting does not submit a goal request merely to observe its state.
• Stop pauses an active goal and interrupts its run. Resume is explicit; a delayed callback cannot restart a cleared or replaced goal.
• Charged tokens are uncached input plus output, without adding total or reasoning fields again. Goals can have no budget; a positive token budget is set only when explicitly requested. It is not a turn count. Reaching the limit stops substantive work and does not mean the objective is complete.
• Active or budget-limited goals with a budget display used/budget tokens; other cases display elapsed time. Active elapsed time updates while the goal is pursued; paused and planning-only periods do not accrue. Usage follows actual requests and lifecycle accounting, and completion reports should use final recorded values.
• The engine persists goal state and accounting across chat switching, reconnection, and reopening the same thread. Continuation still depends on the current mode, permissions, model source, and goal state.

Side tasks and background work

• Side tasks: a small question that branches off the current conversation, asked in its own thread so it neither interrupts nor pollutes the main line. A side task is its own tab in the right panel (not in the Overview panel), and it uses the same transcript and composer as the main conversation. Close it when the answer is in, or promote it to a real session and keep it.
  • It is a new thread forked from the parent session's most recent complete turn, inheriting the parent's project, working directory, model and thinking effort, but it has no record file of its own: closing it is the end of it, and it never shows up in recent conversations.
  • Each session allows at most 8 side tasks; idle ones are reclaimed after an hour (the turn that is currently running holds a lease, so reclamation cannot interrupt it).
• Running work: the "Sub-agents" section of the Overview panel lists the background sub-agents this session dispatched, one row each with an avatar, a task name and a status (long names scroll). This is where you look for "why is it still running" and "what did that sub-agent just do". Context usage is not in the Overview panel — it is the circular chip next to the composer. Sub-agents are named after their task and each has its own avatar, so several dispatched from one session stay distinguishable and their identities are remembered.