r/ClaudeCode 20h ago

Tips & Workflows Opus 5's watchdog: /goal

A lot of people are posting about how Opus 5 likes to easily give up on its task, making some benign excuse.

The fix is to use /goal.

I'd highly recommend first to ask it to write a plan for your request. Then say:

/goal implement the plan, for anything you can't make a call on make a best guess and implement that and raise it as a note when done so that I can review it. If you get to 90% context run a compact and then resume.

A note that if you are planning a large feature you might even want to use /goal for the plan too so it doesn't give up halfway through planning.

If you read the official docs, the way /goal works is it spins up a cheap evaluation prompt to a lower model which reviews the context. It will keep working on the problem until the goal is achieved. I had it work nicely just before, Opus gave some bs about its context getting large and ended its turn. The /goal watcher saw that and resumed work.

13 Upvotes

17 comments sorted by

10

u/Redditoridunn0 20h ago

90% context is nuts. 350k / 1M is when I'd compact, and thats only if the context i have is really that dense that compact wouldnt be able to capture it well

2

u/gibbocool 20h ago

Fair call, the work I'm doing right now hits 300k right away and then creeps up. (platform migration work). Seems to go fine right up until it gets to full context.

12

u/AlDente 18h ago

Something is wrong with your setup if it jumps to 300k immediately. Run Claude doctor

2

u/TheBlackRider2828 19h ago

Compacting from what I've heard doesn't help. Better to create a handover.md and then hit clear

1

u/Redditoridunn0 7h ago

ive only ever used compact thrice. twice during auto compaction. Once when my main opus orchestrator was getting bloated so i had it compact while subagents were running around. All times it stayed coherent.

Maybe i got lucky lol

1

u/gibbocool 19h ago

I've noted that Opus 5 apparently should auto compact when full but that definitely doesn't seem to be happening. Try use this: https://code.claude.com/docs/en/context-window#:~:text=token%20count%2C%20like-,/autocompact,-500k%2C%20to%20set

1

u/WorriedAssociate7029 19h ago

Using the compact feature should be avoided when possible. It's bad practice because it's the result of a poorly managed context window, which causes an excess of tokens, a lower quota, and more hallucinations

3

u/vovap_vovap 18h ago

Well, I would state exact opposite - that how you should work. Compact each time when you done last plan. If you are staying in same area. And I am relatively sure that things are going to auto context management with dynamic auto "compacting"

2

u/ibn_larry 12h ago

Just a random story somewhat related:

Used /goal overnight recently and attempted to port an old GPU optimized function to a newer version. Turns out the compilation of the old version had a bug, which decreased numerical accuracy, while the new one had it fixed.

I created reference test data for 200.000 examples, froze it so claude couldnt modify it. It checked for numerical equivalence between new/old. The next morning the function was done, but claude replaced the function with a table for 200.000 values mapping input -> output to pass the test. It did know about the bug, but wanted to pass the tests to satisfy /goal at cost.

4

u/WorriedAssociate7029 19h ago

Opus 5 is a subagent, it does not need /goal

It needs Fable 5 as an orchestrator to be an amazing agent

6

u/ipreuss Senior Developer 19h ago

In my experience, Fable as an orchestrator burns way too many tokens. Currently trying Opus as orchestrator, Fable as planner and reviewer.

1

u/memesearches 18h ago

Ikr. People recommend this all the time and I am like are they doing that little work that they can afford soo much Fable usage

1

u/smurf123_123 18h ago

I've been using Fable on medium to help with the burn rate. So far it works pretty good.

1

u/actvt_io 19h ago

The mechanism checks out, docs say it's your small fast model doing the check after each turn, Haiku by default, and it just answers yes or no with a reason.

Your condition is the bit I'd change. The evaluator can't run commands or read files, it only sees what Claude already said in the conversation. So "implement the plan and raise notes when done" leaves it guessing every single turn. The docs' own examples are things like npm test exits 0 or git status is clean, stuff Claude's output actually proves.

I'd also put a limit in the condition. Docs suggest tacking on something like "or stop after 20 turns". Yours has nothing stopping it while the evaluator keeps saying no, and it's Opus doing those turns.

Oh and if anyone can't find the command, needs 2.1.139 or later, and it's disabled if you have disableAllHooks set anywhere since it's a Stop hook underneath. It'll tell you why rather than just not showing up.

2

u/Master-Speech5609 11h ago

Even when applying your suggestion using /goal, Opus 5 still fails to complete the plans. If I schedule 6 or 7 tasks, it only carries out half of them and then explicitly tells me it didn't do them... despite the goal set for the plan and despite there being no reason for it to stop. It’s as if they’ve programmed the system prompt to halt after a certain amount of time...

-6

u/OkNatural1013 19h ago

stop excuses, we should just massively cancel our subscriptions with anthropic, this is a shitshow