This is very anecdotal evidence but I have to rant about it... I tried 5.6 Terra (high) earlier today to fix a bug with a slow page. It just... removed the part of the page that was slow, and made it a client side request (still slow, but not blocking SSR I guess). I tried with Sonnet 5 and it correctly found the issue where an unhandled case was continuing to retry and failing. I am always telling people how the frontier models are SO much more capable than what they may think but this one thing today had me scratching my head at why it would ever do that. It was the first time I experienced the "great, I removed the failing test case" kind of issue.
I really really like Fable for software engineering cases; add an alert and write a runbook, go pull metrics for this incident, write me a TUI that does blank, etc. It is astoundingly good and I am very picky. It costs A LOT of money though. I am not sure how I get away with my Fable usage.
Ultra can fan out parallel investigators, run adversarial review at defined checkpoints, and do a bunch of other smart stuff to avoid getting stuck in a local optimum.
Generally as the OP notes, /goal works better for single-track investigations or small scale scatter/gather.
At least for Fable/Opus (didn’t confirm for Sol yet) Ultra means “write an ephemeral programmatic harness encoding this workflow”. There is actually a TS harness that gets run for the workflow.
If you have a task where the agent/sub-agent pattern works, Ultra just adds indirection.
I think it is possible to get an intuition for an individual model but really you need to eval to be sure. My heuristic though is if you need to treat each work item differently depending on the results, probably agent/subagent. If you want to do the same steps across some queue / tree / DAG of work items, ultra is a better bet. (Or actually write a durable scaffold if you are going to repeatedly run it over > thousands of items.)
"Ultra" is a harness feature, and has nothing to do with the model itself. If OpenAI wanted to, they could offer "Ultra" with any of the GPT models, although 5.6 supposedly been trained with this specific harness feature in mind. "max" is basically the top "work harder and achieve better results" parameter for the reasoning effort for the current models.
I had good success with it initially, until I discovered that OpenAI encrypts the prompts that the main model sends to the sub-agents (even in Codex, in local files you only see cipher text), then I completely dropped any experimentation of it as without introspection, it becomes basically useless for any real usage.
Went through something similar. Fable would just spends minutes thinking, processing, confabulating etc.
I dropped down to Haiku and got an answer in >30 seconds.
After a short discussion about the idea with Claude mostly on how it fits in my workflow and what models / effort I would like for certain tasks it placed a paragraph in my global Claude.md and it has worked wonders. Ultra became a lot better (faster, cheaper for the same output) and the amount of time Fable gets stuck overthinking things are reduced to the places where I think that model makes sense, for the rest it started fanning out a lot to Opus, Sonnet and even Haiku.
Does it spawn sub agents with different models or is it the same single conversation dynamically switching models?
I guess everyone needs a nap after a long day of conversing and writing code. So like us!
/compact is prone to error and I wouldn't recommend it in the middle of work. But when you are switching to a related but not completely new task, it helps. ("Now write the integration tests." vs. "on foo.go line 476 that you just wrote, I think there is a deadlock with bar.go line 123 that you just added". It doesn't really need the context to write the tests, it can get that by reading the code. But for iterating on lines of code it just produced, /compact is going to throw away whatever "thought process" led to that code and it's usually not a great thing to do.)
So for long running tasks I'll do
/protect your goal is.../brains inspect
that will let you inspect a session and one of the features is the ability to review a compacted message like so:
https://gitsense.com/screenshots/inspect-pi-session-compacte...
https://gitsense.com/screenshots/inspect-pi-session-compacte...
https://gitsense.com/screenshots/inspect-pi-session-compacte...
With /compact in Pi, it creates a message that you can easily review and I am curious as to how '/protect' works.
One of the features that I am working on is to make it easy for agents to retrieve the exact message/event before compaction and I am curious if /protect is a deterministic process or if it is just instructions.
Edit: removed off topic political spam
It's unrelated to my direct comment and it's a generic tangent off the thread further up, which is about technical issues with Claude Code. As the guidelines say:
"On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity."
"Eschew flamebait. Avoid generic tangents."
"Please don't use Hacker News for political or ideological battle. It tramples curiosity."
Nobody wants to see you hijacking technical threads to turn them into political flamewars. It's against the guidelines, anti-intellectual, and profoundly boring.
For some reason, codex compaction is like black magic. I’ve never felt like I can just one one continuous thread with other models, Claude I carefully curate when I compact
Much better to spend tokens breaking the task into chunks, documenting and storing them durably, then executing each one in clean context and just /clear after.
It’s a similar concept to compaction, just planned in advance. Much much more effective, and doesn’t burn tokens and time (“wall-clock”, Claude) doing the compaction.
Only if money is no object. Cache reads are cheap (10% of uncached input costs) but definitely not free, and cached reads dominate session costs at long context lengths. A prompt at 20k context with $0.01 in cached reads would cost $0.40 in cached reads at 800k context, that quickly adds up for long sessions.
Personally I find using /rewind judiciously is better than using /compact. The latter essentially gives you no control of what details to discard, but the former at least has coarse-grained control.
My whole point was that by planning in advance you can shard the work into manageable sections with clear beginnings and outputs with acceptance croteria, and never compact, or even use more than a few hundfed thousand tokens in context.
It’s all hierarchical. Looking at an eval feature building right now, it’s 20ish build plans, each with zero to five or so /clear moments.
But maybe that’s the key thing… I don’t iteratively prompt ad hoc software writing. I do iterate on requirements, but if those are solid enough there is no “now write this function, now write that module”.
Even if it doesn't fit in the context window, the model can search through past turns and sanity check if something doesn't seem to be going right, or be prompted to follow an early message, "when starting on a new item, review the first message for how we should approach this"
With swival.dev you can use long sessions without ever doing any manual compaction or reset, even with Claude models.
You don't need to go down the rabbit hole of crazy workflows, but to avoid slop:
- Break down the work into tasks
- New context. Create a plan for one task.
- New context. Implement the plan.
- New context. /code-review the implementation
- New context. Fix the review findings.
- Repeat for next task.
I do this with Fable 5, and the quality is consistently quite good. If the context goes over 50%, the quality will become crap and you end up with 4 duplicates of the same thing across the codebase. Letting a current session review its own work is like asking a student to grade their own paper.
Just like with real work, it's valuable to break down big tasks into small tasks that you can knock over in a single session. When a session does start getting too big, you just need to ask the agent to reply with a comprehensive handover report and paste it into a new session.
My impression is that it is about as intelligent as 5.5, but they dialed up the relentlessness meter to eleven. This makes it more likely that it will accomplish the task you give it, which I think is the primary reason it looks competitive in benchmarks. However, it also makes it more likely that it will resort to... unconventional, weird or outright unsafe methods to do it. So I have to watch it like a hawk.
The other day it tried to read env variables from prod using a CLI command. The task it was working on did not necessitate doing that even remotely. I have the SSH keys for that particular CLI tool tied to my 1Password. So when the agent failed (because I never authenticated the SSH key access), it wanted to take over the computer, for which I got an OS prompt. At that point I stopped the agent and asked it why it did that. It said it wanted to dig around 1Password itself to see if it could get the key. I asked it why it needed prod env variables, and it thought for a bit and admitted it actually shouldn't. So as of yesterday I stopped using the "approve for me" mode and now use it only for simpler tweaks and bug fixes.
Fable is not only more intelligent, but also way more insightful. It can sniff out my intent far more effectively, and its "real world" knowledge allows it to act as a seasoned product manager with domain expertise. It can also think outside the box and make suggestions that I would not have thought of. With GPT 5.6 I have to be way more literal.
On the DeepSWE 1.1 benchmark (IMHO currently the most relevant and least gamed SWE benchmark), the cost-benefit is clear: 5.6-Sol on xhigh achieves a slightly higher score than Fable 5, but consuming half the tokens and at about 1/3rd the cost.
But, on the Artificial Analysis intelligence index, Fable 5 appears to slightly beat 5.6-Sol, albeit at 3x the cost.
When I am coding, I send tasks to each model to get multiple opinions and it can be hard to predict which model will “win” because the results can be subjective. OP’s task is at least quantifiable, which is great. But many SWE tasks cannot be quantified so easily.
1. Read X feature of Y and tell me when you fully understand it (if there's any detail missing in the summary, repeat until the context is primed)
2. What time is it?
3. /goal Spend X minutes from $time writing a technical design doc on $feature. There must not be any vague language or ambiguity in the document. Read carry_forward_requirements.md and testing_best_practices.md and explicitly incorporate them into the document you write. The document should be executable for a contextless implementer when done and include specific code and document references and changes needed. Spend the full X minutes working on and reviewing this document - do not quit early and wait
Even just spending 10 minutes forcing GPT to write a design doc results in much more robust plans than plan mode, in my experience, and saves time I would spend iterating on the initial plan mode draft anyway.
Hmm, I feel like this is akin to making a recursive function have a exit condition not based on what it actually did/found, but based on how long time it took.
I'm always using /goal with explicit goals that the agent needs to achieve. Time-bounding them wouldn't make sense, I want something specific done regardless of how long time it takes.
So instead I'd put goals on what the design/architecture needs to achieve, and for the model to continuously check the outcome against these, then finish when everything is achieved. Doesn't really matter if it takes 10 minutes or 10 hours, which for me is a bit the point of /goal in the first place, otherwise I'd just use the agent normally.
Otherwise time boxing is both going to help stop entities from wandering off into the weeds. And also communicate expectations from the commissioner about the expected effort levels and output quality requirements.
Empirically in human world, get very different results when an employee, particularly a junior, is asked to spend 1/2 a day on a work package, a week or are left completely to their own devices.
I find explicit time bounds are useful for tasks like this, otherwise the LLM will almost certainly return too early.
Simply starting in the correct part of the search space is probably the biggest predictor of success. Forcing one big loop to fight its way through all the hypotheticals from zero looks like a dead end for many practical scenarios, regardless of how powerful the model is. I think you could draw some analogies to humans here.
I have found that delegating deep research to a simple tool call is the best way to ground the agent in complex domains. If you make the main agent loop carry the weight of this research, it's going to do a really shitty job because of how the RLHF tries to preserve context and get an answer to the user quickly. As a tool, you may find the agent invokes multiple rounds of research consecutively without realizing it has incurred billions of tokens of consumption. Many of the tokens are wasted when generating independent hypotheses and subsequently investigating them, but the point is that you sampled 10-100x search space before getting serious about mutating the environment. The tradeoff seems worth it in a lot of cases. Correctness >> Time >> Money.
It reminds me of this printing trick “until you are 95% confident”…
Would really be interested to know how this influences the work of the LLM. Also, how would it be if I write “until you certainly understand it”?
Both Codex and Claude Code have it, but they work slightly differently.
Claude Code uses Haiku to read through the transcript and decide if the goal has been completed. If not, Haiku injects a prompt back to the main model to indicate what still needs to be done.
In Codex, instead it's a tool available to the main model, plus some part of the surrounding harness that will re-prompt it if the tool calls haven't yet indicated that the goal is complete.
The issue that they are trying to solve is that sometimes models will stop before they have actually fully completed whatever task they were given; attention isn't perfect, and someitmes they'll complete part of it but not the whole task. Rather than making the user come back and re-prompt to keep going, they add a way to automatically do a bit more nudging to try to get the model to finish the task.
feels kinda odd to use a less capable model to determine if the goal is fully complete. Especially if the user is expecting /goal to thoroughly complete the task. A less capable model would be more likely to misclassify `isComplete?`
This is overselling it. In all implementations of this that I’ve seen, a more correct phrasing is “won’t stop until it pinky-promises it achieved your goal”.
It usually relies on something like a hook that refuses to let the agent stop unless it includes a “promise sentinel”, which is basically the model having to include “I swear I’m done” in the response (usually as a Markdown comment so the user doesn’t see it). If that sentinel isn’t in the response, the hook rejects the completion and hands it back to the agent (sometimes it also restates the goal to keep it focused). It’s useful for sure, but it fails many times for obvious reasons.
More robust implementations use the hook to spawn another agent that verifies the goal is achieved, but that too isn’t prefect and sometimes performs worse.
Of course if you have a problem that can be deterministically verified, you could have the hook run this verification instead, but this is usually not the case (and even when it is, agents will often cheat the verification e.g. by deleting a test file).
With /goal, a different Claude instance evaluates the goal. This is the robust version you described, and such an "adversarial Claude's" approach, with or without/goal, is exactly how you avoid pinky promises (from one Claude).
/goal open a draft PR that makes <endpoint> ~200ms faster while still passing tests, and adhering to nearby style+pattern
If you want to be able to use it like that, you need to find a way to encode (most of) your concerns into something that can be programmatically verified.
I haven't really found a good way to solve this other than:
1. Produce an initial PR fulfilling all the requirements I knew at the start
2. Chat with the model about any weird snippets I notice and talk through alternatives
3. Simplify anything that I think is overengineered or plain unncessary
Sometimes I restart all over with more precise requirements but then it sometimes makes different mistakes/takes different shortcuts.
In practice the earlier I review the better the end result imo, so /goal seems very unproductive to me?
/goal is a gimmick where you run a "parent" agent on top that runs the agent on a loop until the it decides to stop, just prompting it "nope, not done yet, continue".
Sol frontend is perfectly serviceable if you use it from something like Pi.
Offering freelance estimates for CSS design changes before frameworks were around was a problem.
Or I think my PTSD on advanced algorithm course kicked in
Edit: looks like the closet reduction should be https://en.wikipedia.org/wiki/Ring_star_problem with bounded circuit length
https://chatgpt.com/c/6a5bbe6a-a760-83ea-931a-4e2bbe028486
Thoughts?