anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-23 02:36:57 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: Save plan to file for token efficiency and compaction persistence #4586

New Issue
Open
opened 2026-02-16 17:44:41 -05:00 by yindo · 17 comments
yindo commented 2026-02-16 17:44:41 -05:00
Owner
Copy Link
Copy Source

Originally created by @karashiiro on GitHub (Jan 10, 2026).

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).

Originally created by @karashiiro on GitHub (Jan 10, 2026). ### Feature hasn't been suggested before. - [x] 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).
yindo added the discussion label 2026-02-16 17:44:41 -05:00
yindo commented 2026-02-16 17:44:41 -05:00
Author
Owner
Copy Link
Copy Source

@karashiiro commented on GitHub (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:

@karashiiro commented on GitHub (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: - https://github.com/anomalyco/opencode/actions/runs/20873703654 - https://github.com/anomalyco/opencode/actions/runs/20873703668
yindo commented 2026-02-16 17:44:41 -05:00
Author
Owner
Copy Link
Copy Source

@m10rten commented on GitHub (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.

@m10rten commented on GitHub (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.
yindo commented 2026-02-16 17:44:41 -05:00
Author
Owner
Copy Link
Copy Source

@karashiiro commented on GitHub (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.

@karashiiro commented on GitHub (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.
yindo commented 2026-02-16 17:44:41 -05:00
Author
Owner
Copy Link
Copy Source

@m10rten commented on GitHub (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.

@m10rten commented on GitHub (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.
yindo commented 2026-02-16 17:44:41 -05:00
Author
Owner
Copy Link
Copy Source

@karashiiro commented on GitHub (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 commented on GitHub (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.
yindo commented 2026-02-16 17:44:41 -05:00
Author
Owner
Copy Link
Copy Source

@karashiiro commented on GitHub (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.

@karashiiro commented on GitHub (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.
yindo commented 2026-02-16 17:44:41 -05:00
Author
Owner
Copy Link
Copy Source

@YPares commented on GitHub (Jan 15, 2026):

this should not be forced upon all users

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).

@YPares commented on GitHub (Jan 15, 2026): > this should not be forced upon all users 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).
yindo commented 2026-02-16 17:44:42 -05:00
Author
Owner
Copy Link
Copy Source

@karashiiro commented on GitHub (Jan 18, 2026):

FYI: This was implemented under the OPENCODE_EXPERIMENTAL_PLAN_MODE=1 feature flag recently, I like it 👀

@karashiiro commented on GitHub (Jan 18, 2026): FYI: This was implemented under the `OPENCODE_EXPERIMENTAL_PLAN_MODE=1` [feature flag](https://bsky.app/profile/thdxr.com/post/3mcdmjd2f732h) recently, I like it 👀
yindo commented 2026-02-16 17:44:42 -05:00
Author
Owner
Copy Link
Copy Source

@TomLucidor commented on GitHub (Jan 20, 2026):

I kinda wanted this too, but the concept of planning has issues on

  • How it updates the plan based on newly visible roadblocks/issues
  • Granularity of short-term vs long-term plans and how they interact
  • Planning of projects with a lot of subtasks of similar procedures
  • The other GitHub repos on subagents/skills design
@TomLucidor commented on GitHub (Jan 20, 2026): I kinda wanted this too, but the concept of planning has issues on - How it updates the plan based on newly visible roadblocks/issues - Granularity of short-term vs long-term plans and how they interact - Planning of projects with a lot of subtasks of similar procedures - The other GitHub repos on subagents/skills design
yindo commented 2026-02-16 17:44:42 -05:00
Author
Owner
Copy Link
Copy Source

@YPares commented on GitHub (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.

@YPares commented on GitHub (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.
yindo commented 2026-02-16 17:44:42 -05:00
Author
Owner
Copy Link
Copy Source

@art-shen commented on GitHub (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.

@art-shen commented on GitHub (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.
yindo commented 2026-02-16 17:44:42 -05:00
Author
Owner
Copy Link
Copy Source

@YPares commented on GitHub (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.

@YPares commented on GitHub (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.
yindo commented 2026-02-16 17:44:42 -05:00
Author
Owner
Copy Link
Copy Source

@TomLucidor commented on GitHub (Jan 21, 2026):

WIth Claude Code (and IDEs like Cursor/Windsurf), it can at the very least dynamically adjust/expand the todo-list.

@TomLucidor commented on GitHub (Jan 21, 2026): WIth Claude Code (and IDEs like Cursor/Windsurf), it can at the very least dynamically adjust/expand the todo-list.
yindo commented 2026-02-16 17:44:42 -05:00
Author
Owner
Copy Link
Copy Source

@karashiiro commented on GitHub (Jan 21, 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.

@karashiiro commented on GitHub (Jan 21, 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.
yindo commented 2026-02-16 17:44:42 -05:00
Author
Owner
Copy Link
Copy Source

@YPares commented on GitHub (Jan 22, 2026):

@TomLucidor So would it here. Everything that is part of the persisted plan file could be changed dynamically.

@YPares commented on GitHub (Jan 22, 2026): @TomLucidor So would it here. Everything that is part of the persisted plan file could be changed dynamically.
yindo commented 2026-02-16 17:44:42 -05:00
Author
Owner
Copy Link
Copy Source

@YPares commented on GitHub (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 commented on GitHub (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.
yindo commented 2026-02-16 17:44:42 -05:00
Author
Owner
Copy Link
Copy Source

@YPares commented on GitHub (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

@YPares commented on GitHub (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
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4586
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?