Claude's /goal Mode: Run Until Done, or Endlessly Burn Tokens?

Claude Code's new /goal mode is one of those features that immediately sounds like the future and immediately triggers the right kind of paranoia. The pitch is clean: tell the agent what "done" means, let it keep working across turns, come back later.

The question hiding underneath is less clean: does this mean run until done, or does it mean run until quota?

That tension was all over the Reddit discussion when the feature landed. The excitement was real. So was the skepticism. A lot of the reaction boiled down to the same fear: if the agent is weakly grounded and the goal is weakly specified, "fire and forget" can become "pay and pray." The thread is here: Claude Code just shipped a run until done mode.

The problem is not autonomy. It is ambiguous completion.

Autonomous coding loops are not inherently bad. In fact, they are the natural direction of travel. The real problem is that software tasks rarely have simple stopping conditions. "All tests pass" is crisp syntactically, but mushy semantically. Tests can be adjusted. Coverage can be narrow. The code can satisfy the letter of the condition while missing the thing the human actually meant.

Goal string:
"all tests pass and the PR is ready"

Risk:
- tests can be gamed
- "ready" is underspecified
- hidden regressions can be missed
- the agent may keep trying low-value loops

This is why goal mode feels simultaneously powerful and scary. A strong model can keep grinding. But grind toward what, exactly? If the objective is underspecified, the model may simply explore more wrong branches with more persistence.

Run until done can quietly become run until drift

When agents run for longer, they do not just get more chances to succeed. They get more chances to drift. They can overfit to local metrics, pursue increasingly low-value retries, mutate the codebase to satisfy a shallow verifier, or spend hours repairing artifacts of their own previous attempts.

This is the same class of failure we point at in context grounding and hallucination control. The more cycles you give an agent, the more important it becomes that the system around it knows how to tell progress from motion.

A good harness should already do this without a magic mode

This is the stronger take: with good grounding and a serious harness, the system should already be able to work toward completion across iterations without needing a theatrical "run until done" badge.

In other words, the useful part is not the command name. It is the surrounding machinery: retrieved repository context, explicit constraints, budget awareness, adversarial verification, permission boundaries, and external stop logic.

Grounding
  -> repository facts
  -> product rules
  -> explicit constraints
  -> verifier pass
  -> external stop conditions
  -> done or blocked

The harness matters more than the model's self-confidence

A model saying "I think I am done" is not a completion system. It is just text. A harness has to inspect the work, verify the goal, track costs, detect retries, enforce limits, and stop the loop when the run is no longer economically or technically justified.

That means checking more than pass/fail. It means asking whether the agent is revisiting the same failing branch, whether new context is arriving, whether risk is increasing, and whether the goal itself was badly specified from the start.

Run loop
  -> act
  -> retrieve fresh context
  -> verify against goal
  -> check budget/time/risk thresholds
  -> continue, block, or stop

Speculation: this will make the gap between toy workflows and serious workflows obvious

For small, well-scoped tasks, /goal may feel fantastic. Rename a thing. Fix a flaky test. Update a simple component. Clean up a script. Those are the tasks where "let it cook" can feel like a genuine unlock.

The scarier outcome is what happens when teams generalize that feeling to harder software problems. The moment the task touches architecture, business rules, hidden side effects, product constraints, or long-tail integration behavior, autonomous persistence stops being obviously helpful and starts becoming expensive ambiguity.

Token burn is really a symptom of poor grounding

People often talk about token burn as a cost problem. It is that. But it is also a signal problem. Long, expensive runs often indicate that the agent does not have enough truth to converge cleanly.

If the model had the right architecture context, the right business rules, the right tests, the right stop conditions, and the right verifier, the run should narrow faster. If it keeps wandering, revising, or gaming the local metric, that is usually not just "bad luck." It is evidence that the system around the model is underbuilt.

This is where Kognita fits

Kognita is built around the idea that agent autonomy becomes useful only when the system is grounded enough to support it. Repository context, workflow context, schema context, product rules, and operational knowledge have to be available together, not as scattered fragments. Then the harness can reason about whether the agent is moving toward a real objective or just consuming more runway.

The end state is not "never let agents run." It is "let them run inside a system that knows what reality looks like, knows what good stopping looks like, and knows when persistence has turned into waste."

Final takeaway

/goal is a real feature, not a gimmick, but it points straight at the harder problem underneath autonomous coding. The value is not merely letting the agent continue. The value is knowing whether continuing is still meaningful. Without grounding and a real harness, "run until done" can absolutely become "run until budget." With them, the system should be able to drive toward completion anyway.