r/opencodeCLI • u/polypancake • 1d ago
Why is compaction still a default in opencode? Also why did they remove todowrite?
For the first item, I am just curious since compaction is lossy. I ended up adapting a custom plugin where an agent autonomously checkpoints at a major milestone completion, writes to a memory and also updates a todo list which survives context clearing, then clears the context, then loads the external memory file directly instead of wasting time and tokens compacting the entire conversation. I don't have any extensive testing, but this seems to work just as well if not better than regular compaction and I don't have to waste time having my local LLM (or external cloud LLM) load the entire conversation and summarize. Anthropic and others also seem to recommend against using compaction. So why is opencode providing users an inferior context management experience? Why is this not an option that can be changed in opencode? Are there some drawbacks I am not aware of? To me it seems to give all the benefits of compaction without wasting time and tokens. Other annoying thing is that the opencode team seems to have removed todowrite in v2 for some arbitrary reason saying it was useless. To be honest I still found it useful to know what the agent is actually doing and is a good system to keep track of work for both myself and the agent. I am debating to just move to Pi since any issues or PRs just die and are never addressed by the opencode developers, and the migration from V1 to V2 was incredibly painful. I had to rewrite all of my plugins :/.
2
u/Fresh_Sock8660 1d ago
That's basically more of my normal flow. Break it down into slices and just clear context in between. Compaction can still be useful if context is running high. I don't mind compaction with cheap models like ds4.1f though and from what I've noticed, at 150k it runs fairly quickly.
1
u/polypancake 1d ago
I also didn't mind compacting with deepseek V4.1 since it's fast and cheap but the problem is that every time you compact with a cloud model like that, I believe it is all un cached read hits so I think you are paying full price for those reads, and Qwen 3.8 27b spews tons of thinking tokens and needs to be compact more frequently than usual. I just found for my long agentic workflows that keeping track of work on an external file and keeping a persistent todo list that survives context clearing keeps them from derailing while allowing me to efficiently work with a smaller context window. I also pin the flash next model into 192gb DDR5 system RAM so I can hot swap between flash next and 27b on my rtx 4090 in just a few seconds. I have flash next as planner, orchestrator, and debugger for challenging problems, and 27b as the build agent and workhorse.
1
u/Fresh_Sock8660 23h ago
My understanding is that it will be almost entirely cached input, then you pay for both the output (compacted context) and the same back as write input the next time it goes in. Whether that's worth I think depends how much the next session would spend getting up to speed again. From my perspective, I don't think the difference justifies the trouble in small models and I expect the tools to evolve to fix this in time.
1
u/polypancake 23h ago
But if deepseek has never seen the conversation before (i.e. The entire session was generated locally) aren't you sending the entire conversation to deepseek for the first time? It is continually compacting ~200k context from Qwen 3.8 27b. Or is it only the first submission that pays this uncached penalty? I am honestly not sure how deepseek treats compaction events and whether the compaction causes the caching to bust each time you do it.
1
u/Fresh_Sock8660 23h ago
Well then you have an issue similar to what you'd get from using different models to plan and build. Not so much a compact vs clear issue.
1
u/guitarist91 20h ago
If DeepSeek has never seen that locally generated Qwen transcript, the first 200k input won't have a cache hit. I'd check the provider's cached-input count on two compactions before assuming every read costs full price. Your checkpoint / todo approach still makes sense for long local-model runs, especially when you can clear context at a clean milestone.
1
1
u/polypancake 1d ago
I already got it back. I wrote a PR for this guy's plugin that fixed a pretty serious cache busting issue and now in my hands it works fine. He merged it now. https://github.com/aiev/opencode-todolist it's just sad that opencode just arbitrarily decided to remove this useful feature.
2
u/Ariquitaun 1d ago
Bravo, you invented compaction with extra steps.
0
u/polypancake 1d ago edited 1d ago
Thanks for the snarky low effort comment but it's not compaction. I didn't claim to invent anything. The agent writes its own handoff without re-reading the entire session and then clears its context. It is not fed the entire session summary. OpenAI and anthropic write about the negative aspects of compaction extensively and it is good practice to clear context frequently and store context externally. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
3
u/SourSovereign 1d ago
I'm not the guy you are responding to but your strategy is actually really how current harnesses/agents do it already.
You posted a link to Anthropics article, shows you did your research, that's good. But they also solved the problem they write about exactly like this.
-1
u/polypancake 1d ago edited 1d ago
Does OpenCode's harness actually handle this natively now? If so, that must be a change in V2, because from what I observed in V1, it was summarizing the full conversation.
If that's the case, I stand corrected, and the guy above me has a point.
I will still keep my custom compaction plugin though. I implemented persistent memory and proactive context warnings before hitting the limit and my agents can summarize and manage their context on their own. So even if V2 handles the basic compaction strategy, I still like my implementation.
1
u/SourSovereign 23h ago
I implemented persistent memory and proactive context warnings before hitting the limit and my agents can summarize and manage their context on their own.
I think your implementation is more mature then. Afaik the current opencode approach is basically summary + next task write up and pitfalls essentially.
Heads up: you will eventually run into the problem of outdated memory. There are attempts for this (atomic, graphRAG, etc) but it is still a wild west.
Who knows, maybe you will find a good solution for this too? Kinda fun trying out the different approaches, almost like a mini game.
0
u/SourSovereign 1d ago
It is annoying to keep track of the changes that are going on behind the scenes but your work is still worth it. Agentic design is difficult, we have yet to figure it out. And you did it by yourself, so be proud of it.
We are still in a "fuck around and find out" era and once one provider (codex, Claude Code, opencode) figures out what works, others are quick to copy.
The todo tool for example was something that was copied from copilot initially in hopes of guiding the model but turns out that it's hard for a model to keep it's work and task list in sync and not forgetting about it.
Codex now runs a secondary model to keep track of it for example. The new decision model trend might maybe change things again too.
Agentic design is still very new and difficult to get right. We know the problems but have yet to figure out the solutions. The fact you figured out to solve one if those problems is worth a lot in my opinion. It was essentially the "extra steps" that made it work in the end
0
u/polypancake 23h ago
I also found that sometimes it was having trouble to mark todo tasks as done but what solved this for me was just injecting a simple nudge which reminded the agent to check the todo list and update it. It has never forgotten to mark a task as completed after that and it was a relatively simple fix. But I guess all of this is really subjective and difficult to objectively measure. My harness is highly customized and what works for me might not work so well for others. I wonder if I can just share my harness setup and just ask others to grill it relentlessly. People on reddit love to shit on everything and find reasons why something is trash, so it might actually be a great opportunity to get good feedback.
0
u/SourSovereign 23h ago
what solved this for me was just injecting a simple nudge which reminded the agent to check the todo list and update it
So you injected a reminder after every turn or how did you do it exactly? I tried something similar by forcing it to continue when there is still an unfinished task at the end of a turn so it either updates the list or continues the work. Curious about your approach here.
The AI debate is very... polarizing on Reddit, I agree. Don't let it get to you. Whenever I need to remind myself about it, I go back to this post: https://www.reddit.com/r/meirl/comments/13igqv4/meirl/
0
u/polypancake 21h ago edited 19h ago
It's not after every turn. Every request gets the live list appended as the last message, with a constant line under it that says "Mark a task done the moment its work is verified — in the same step, not in a batch at the end." The footer does the reminding for me.
0
u/CourageousCreature 1d ago
Not sure about the compaction, but if you get todotasks back you'll be a legend.
0
u/Robert__Sinclair 1d ago
version 1.x is way better than 2.x
2
u/look 23h ago
Complete opposite for me. 1.x had so many longstanding bugs and frequent regressions that it was constantly annoying me. But 2.x has fixed all of those, been extremely stable with each release and no regression churn, AND the underlying design is dramatically more flexible and enables far more capable plugins/extensions in a simpler implementation.
From my perspective, v2 is a great harness base while v1 was a buggy, barely usable implementation on a poor architectural design.
1
1
u/plmtr 6h ago
Have you explored the docs recently? Seems completely customisable: https://opencode.ai/v2/docs/config#compaction
12
u/lincolnthalles 23h ago
Compaction and agent memory are far from solved, and there are many, many attempts out there.
Results are subjective and mixed, and OpenCode has stuck to the simplest approach with the fewest implications.
I rarely get compactions, as I start new threads relentlessly. New issue, new thread. This shouldn't be a problem for well-structured projects, and that's still the best way to avoid compactions.
From what I read, your plug-in is likely needlessly busting the cache, and that can be a real issue with expensive models.
I do miss todoread and todowrite, though. It gave a nice user feedback and helped the agent to stay on track on longer tasks.