41–50 of 134 posts
The chart at the top is somewhat confusing. It says, “lower is better” but the y-axis is inverted! So visually higher in the chart is better but lower in terms of # value.
What is /goal?
/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".
/goal has replaced plan mode for me. This is the pattern I use for 95% of my AI work now: 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_forwa…
> 3. /goal Spend X minutes from $time writing a technical design doc on $feature. 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…
I love that we have this on one hand and me cleaning up catastrophic CSS made by Sol on the other. Then again, maybe CSS is the ultimate benchmark.
Sol frontend is perfectly serviceable if you use it from something like Pi.
Earlier quoted context omitted.
Unfortunately I’ve used Claude and GPT models for a long time in a variety of harnesses and I agree with you and I think it’s the compaction. 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
Compacting at all is a mistake. With 1m context window there is no reason for a single task to require compaction. 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)…
Earlier quoted context omitted.
It's useful for things where it just needs to get through to completion. Long running tasks. I walk away and expect it to be done without pausing for input.
Can you give an example? And more curious about what you do with the resulting code afterwards I imagine its gonna be a big chunk then?
...is this not a Travelling Salesman Problem?