8gent Code.Docs
Using 8gent

/goal

State an outcome and let 8gent work turn after turn until a separate judge model says it is done, or the budget runs out.

/goal turns a request into a loop. You state a checkable outcome. The agent works a turn, a different local model judges whether the goal is met, and the loop continues until the judge says yes, it says the goal failed, or a budget runs out.

/goal create notes/today.md with a summary of today's git log
/goal make bun test pass in packages/slug

Commands

CommandWhat it does
/goal <goal>Start a goal run
/goal statusWhat is happening now
/goal stopStop the run. Its state is kept
/goal resumeContinue a stopped run
/goal clearStop and drop the run's state
/goal ?Help, inline
/subgoal <text>Add a sub-goal to the running loop

The plan column (Ctrl+X) shows the goal's tasks as they are created and updated.

When it stops

Whichever comes first:

  • the judge returns satisfied
  • the judge returns failed
  • the judge says "continue" 8 times in a row
  • a budget runs out

Default budget per run:

BudgetDefault
Turns12
Tokens100,000
Wall-clock10 minutes
Files changed50
Network egress25 MB

The judge

  • Local first. The judge runs through the local failover chain.
  • Never the executor. A judge with the same model as the executor is refused, so the agent cannot mark its own work.
  • Fails open to the budget. If the judge cannot answer, the turn counts as "continue", and the budget is the backstop. A broken judge never wedges the loop.

Your permission mode still applies to every command inside a goal run. Guarded is a good fit: routine steps run, risky ones still ask.

The record

Every event of a run is appended to ~/.8gent/runs/<runId>/ledger.jsonl, hash-chained and signed with a key kept on your machine, so a changed or missing entry shows up when the ledger is verified.

When not to use it

  • One-shot questions. Just ask.
  • Work where "done" is a matter of taste.
  • Anything you would not leave running while you look away.