Repository navigation
[FEATURE]: Save plan to file for token efficiency and compaction persistence #7579
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
I typically start non-trivial tasks in Plan mode and iterate on the plan extensively until it's thorough and matches exactly what I want to build, and then I switch to Build mode to let the agent run on that plan to completion. Unfortunately, this burns a considerable portion of the context window as the Plan agent repeats the entire plan in its context window after every round of iteration.
To make matters worse, after compaction events occur (including during Plan mode itself), large portions of the plan are forgotten, as the compaction summary only has a very low-fidelity version of the plan and occasionally loses track of it entirely. I've worked around this by directing the agent to save the plan to a file in the working directory before beginning any implementations, but that still requires me to manually direct it to read the plan again after most compaction events.
It'd be incredibly helpful if plans were instead saved to some temporary file as part of the Plan mode workflow, and the agent iterated on the plan by modifying it like any other file. For further token-efficiency, the agent could have a built-in tool to display the plan in the UI for review without dumping it into its context again. Then, after compaction events, the agent can have a direction prepended to its compaction summary to read the plan to restore its overall goal, and to continue working on that unless the plan has been fully-completed (this might need another built-in tool to eventually mark the plan as done).
Activity
karashiiro commentedon Jan 10, 2026
I did a few searches and this didn't seem to have already been requested, but FYI the issue triage failed to install OC:
m10rten commentedon Jan 10, 2026
Think this is not something that should be built-in, rather something you can create tools/agents/plugins for to do yourself.
Me personally I have a custom planner agent that writes plans in markdown, gives a summary of tasks/scopes and requires human approval to continue. The planner is a subagent of my main agent, so the main agent only does delegation, keeping context window small. The main agent then knows the tasks and delegates to the builder agent, which executes singular tasks only to avoid noise and ensures 100% completion of each task.
karashiiro commentedon Jan 10, 2026
I am aware that this could be something custom, but I just don't think it's a very intuitive user experience that a plan can be degraded over time like this due to compaction events. People who run into this shouldn't need to be aware of how compaction works to figure out how to deal with this, and I believe most people who run into this failure mode will chalk it up to the model being incompetent and move on, rather than understanding that it's the consequence of a design decision in OpenCode and that they need to customize it to work around the issue.
m10rten commentedon Jan 11, 2026
Im not saying it's a bad choice to store tmp files, but rather that this should not be forced upon all users. Having to deal with context window is not what opencode should do as this includes choices, on how you want the flow to be, what you do and do not want in context.
karashiiro commentedon Jan 11, 2026
Are there any cases in which this feature request would go against someone's choices about these things? I can't think of a case where the current flow can be construed as a good user experience. OpenCode already deals with the context window (every coding agent does, fundamentally), but I think maintaining a plan between compaction events - which are themselves an opinionated feature of OC - would considerably improve the default flow as it would reduce the impact of the model forgetting information after OC-driven compaction events.
karashiiro commentedon Jan 11, 2026
Alternatively: I don't think Plan mode is a useful feature to include out of the box unless the plan is remembered between compaction events - if OC doesn't want to do this, I think it might be better if it's even less opinionated about the feature and leaves the entire planning system up to the end-user to reduce confusion, so that users who do want a robust planning mode know from the outset that they need to build that themselves.
YPares commentedon Jan 15, 2026
There could be two Plan modes then?
Like "Short-term plan" (current behaviour) and "Long-term plan" (persisted)
Yes, persistent plan-making is something that can be built by users, but it's a way of doing things that is common enough throughout ai agent users, so it may warrant some default implementation by the harness itself.
[Anecdotal] When claude-code implemented that, I didn't feel it was forced upon me, I felt it was a welcome change (YMMV, I know it's just my opinion, but when something is replaced by a new behaviour that supports all previous use cases plus new ones, I'm usually not one to complain).
karashiiro commentedon Jan 19, 2026
FYI: This was implemented under the
OPENCODE_EXPERIMENTAL_PLAN_MODE=1feature flag recently, I like it 👀TomLucidor commentedon Jan 21, 2026
I kinda wanted this too, but the concept of planning has issues on
YPares commentedon Jan 21, 2026
@TomLucidor It seems to me none of these is under the responsibility of the planning feature, which is aimed at producing one specific plan for one specific feature at one point in time. It's by design limited in scope and should not have to deal about these larger-scope considerations.
art-shen commentedon Jan 21, 2026
@YPares, on the other hand, when you have solid planning inside the agent harness, you can update the plan file according to new details, new information, up to date progress, nothing lost on compaction, etc.
This is exactly the only exception I find where Claude Code is performing notably better for me than OpenCode because of the deeply integrated planning functionality.
YPares commentedon Jan 21, 2026
@art-shen I agree, but I don't believe ClaudeCode is currently addressing TomLucidor's concerns. Right now, it's still functioning at the level of a single task, without external context/input unless the user explicitly provides it. In any case, that's beyond the scope of this issue.
TomLucidor commentedon Jan 21, 2026
WIth Claude Code (and IDEs like Cursor/Windsurf), it can at the very least dynamically adjust/expand the todo-list.
karashiiro commentedon Jan 22, 2026
I think there is room for improvement on long-horizon task sequencing, and there's a lot of competing solutions for that right now (deciduous, ticket, chainlink, etc.) - I'd love to see that kind of solution built directly into a coding agent plan system someday, but I'm also (simultaneously) very happy with this.
YPares commentedon Jan 22, 2026
@TomLucidor So would it here. Everything that is part of the persisted plan file could be changed dynamically.
YPares commentedon Jan 22, 2026
@karashiiro Also, for long term planning, it's very likely you'd want to interoperate with some external service (be it local or remote: github, linear, jira, etc.) to integrate with existing issues boards & projects, instead of rolling up your own local "project planning storage".
So that's a very different kind of beast which is IMO best suited for provided-specific plugins, CLI tools or MCP servers.
YPares commentedon Jan 22, 2026
For a more featureful solution for more long-term planning that works with opencode, see for instance https://github.com/backnotprop/plannotator
github-actions commentedon Mar 26, 2026
To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.