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

[Discussion] Agent Performance Optimization, Improvements & Pain Points for opencode #7680

New Issue
Open
opened 2026-02-16 18:07:55 -05:00 by yindo · 9 comments
yindo commented 2026-02-16 18:07:55 -05:00
Owner
Copy Link
Copy Source

Originally created by @JeffC0628 on GitHub (Jan 26, 2026).

Originally assigned to: @thdxr on GitHub.

As opencode evolves, we’re gathering community input to identify key optimization points, feature ideas and existing pain points — with a focus on AI Agent-related performance tuning. This thread is a centralized space for sharing technical insights and practical feedback.

Focus areas for discussion

  • Agent-specific performance optimization: Bottlenecks in agent reasoning pipeline, task scheduling, context management, multi-step execution, tool calling efficiency, and actionable tuning strategies (e.g., inference caching, pipeline parallelism, context pruning)
  • General performance improvements: Module-level bottlenecks (latency/CPU/memory/throughput), tunable logic, or optimization schemes (e.g., async processing, algorithm tweaks, IO optimization)
  • High-value feature ideas & future directions: New capabilities, integrations or use cases for the core project and agent module
  • Unresolved issues & pain points: Bugs, usability friction, or development roadblocks faced in daily usage

Share specific observations, reproducible scenarios, or concrete implementation ideas — all technical details that help prioritize improvements are welcome!

Originally created by @JeffC0628 on GitHub (Jan 26, 2026). Originally assigned to: @thdxr on GitHub. As opencode evolves, we’re gathering community input to identify key optimization points, feature ideas and existing pain points — with a focus on **AI Agent-related performance tuning**. This thread is a centralized space for sharing technical insights and practical feedback. #### Focus areas for discussion - **Agent-specific performance optimization**: Bottlenecks in agent reasoning pipeline, task scheduling, context management, multi-step execution, tool calling efficiency, and actionable tuning strategies (e.g., inference caching, pipeline parallelism, context pruning) - **General performance improvements**: Module-level bottlenecks (latency/CPU/memory/throughput), tunable logic, or optimization schemes (e.g., async processing, algorithm tweaks, IO optimization) - **High-value feature ideas & future directions**: New capabilities, integrations or use cases for the core project and agent module - **Unresolved issues & pain points**: Bugs, usability friction, or development roadblocks faced in daily usage Share specific observations, reproducible scenarios, or concrete implementation ideas — all technical details that help prioritize improvements are welcome!
yindo commented 2026-02-16 18:07:55 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 26, 2026):

This issue discusses opencode's current technical debt and known issues. One of the technical debts mentioned here (权限持久化 - Permission Persistence) directly corresponds to:

  • #10753: Persist 'always' permission approvals to disk

Feel free to check that issue, as it's actively being tracked separately.

@github-actions[bot] commented on GitHub (Jan 26, 2026): This issue discusses opencode's current technical debt and known issues. One of the technical debts mentioned here (**权限持久化 - Permission Persistence**) directly corresponds to: - #10753: Persist 'always' permission approvals to disk Feel free to check that issue, as it's actively being tracked separately.
yindo commented 2026-02-16 18:07:55 -05:00
Author
Owner
Copy Link
Copy Source

@neavo commented on GitHub (Jan 26, 2026):

Currently, OpenCode is too conservative in invoking tools and subagents. I have noticed that most models (such as GPT-5.2 and Gemini-3-Pro) do not proactively invoke subagents or even specify the todolist during tasks. If we could be more aggressive in this regard, it would significantly improve task completion efficiency (for instance, by allowing multiple subagents to read code in parallel during the code-reading phase) and plan adherence.

@neavo commented on GitHub (Jan 26, 2026): Currently, OpenCode is too conservative in invoking tools and subagents. I have noticed that most models (such as GPT-5.2 and Gemini-3-Pro) do not proactively invoke subagents or even specify the todolist during tasks. If we could be more aggressive in this regard, it would significantly improve task completion efficiency (for instance, by allowing multiple subagents to read code in parallel during the code-reading phase) and plan adherence.
yindo commented 2026-02-16 18:07:55 -05:00
Author
Owner
Copy Link
Copy Source

@JeffC0628 commented on GitHub (Jan 27, 2026):

Currently, OpenCode is too conservative in invoking tools and subagents. I have noticed that most models (such as GPT-5.2 and Gemini-3-Pro) do not proactively invoke subagents or even specify the todolist during tasks. If we could be more aggressive in this regard, it would significantly improve task completion efficiency (for instance, by allowing multiple subagents to read code in parallel during the code-reading phase) and plan adherence.

I think we should discuss this case-by-case. While being more proactive with tools and subagents can definitely boost efficiency for complex tasks, it also carries risks like higher token consumption and potential noise for simpler ones. A balanced or configurable approach might be better to ensure both efficiency and precision."

@JeffC0628 commented on GitHub (Jan 27, 2026): > Currently, OpenCode is too conservative in invoking tools and subagents. I have noticed that most models (such as GPT-5.2 and Gemini-3-Pro) do not proactively invoke subagents or even specify the todolist during tasks. If we could be more aggressive in this regard, it would significantly improve task completion efficiency (for instance, by allowing multiple subagents to read code in parallel during the code-reading phase) and plan adherence. I think we should discuss this case-by-case. While being more proactive with tools and subagents can definitely boost efficiency for complex tasks, it also carries risks like higher token consumption and potential noise for simpler ones. A balanced or configurable approach might be better to ensure both efficiency and precision."
yindo commented 2026-02-16 18:07:55 -05:00
Author
Owner
Copy Link
Copy Source

@neavo commented on GitHub (Jan 27, 2026):

I think we should discuss this case-by-case. While being more proactive with tools and subagents can definitely boost efficiency for complex tasks, it also carries risks like higher token consumption and potential noise for simpler ones. A balanced or configurable approach might be better to ensure both efficiency and precision."

You're right, OMO is too aggressive; we need more refined strategies.
It is clear that there are still significant differences between current models. I've observed that GLM-4.7 can be very proactive in calling tools (including using the right-side planning panel), but Gemini 3 does not, even though the Gemini 3 series itself has stronger agent capabilities.
This is exactly the kind of "refinement" I'm referring to.

@neavo commented on GitHub (Jan 27, 2026): > I think we should discuss this case-by-case. While being more proactive with tools and subagents can definitely boost efficiency for complex tasks, it also carries risks like higher token consumption and potential noise for simpler ones. A balanced or configurable approach might be better to ensure both efficiency and precision." You're right, OMO is too aggressive; we need more refined strategies. It is clear that there are still significant differences between current models. I've observed that GLM-4.7 can be very proactive in calling tools (including using the right-side planning panel), but Gemini 3 does not, even though the Gemini 3 series itself has stronger agent capabilities. This is exactly the kind of "refinement" I'm referring to.
yindo commented 2026-02-16 18:07:55 -05:00
Author
Owner
Copy Link
Copy Source

@NamedIdentity commented on GitHub (Jan 28, 2026):

@JeffC0628

I'm developing an Agentic Collaboration Framework which optimizes agents to exercise discretion and autonomy by constructing a conceptual framework that helps them figure out how to make appropriate choices rather than making a set of rigid narrow-scope rules. I don't think it'll change how inept Gemini 3 is at tool-calling, but it will models perform much better across a wide-array of tasks.

I think when further complete, my work can help define a clearer direction for OpenCode improving agent performance.

But, it's WIP and not yet ready to publish. I'm currently trying to adapt DCP into a proper context management system that optimizes for performance, not token usage reduction.

That said, if someone at OpenCode is actively working on improving how OpenCode helps agents perform better, it might be worthwhile to collaborate and get on-the-same page. Otherwise, I'll proceed in the expectation this is just going to be a PR fork with a plugin that the community decides what to do with.

I've been, hoping to see more efforts at coordinating collaboration in the OpenCode community by maintainers. There's a lot of people interested in building, and developing, and so far, it's scattershot and unfocused. If we can focus that, we could get a lot done. OpenCode development seems to be encountering a huge bottleneck and it's unclear where it is.

I feel like OpenCode development is like a kids game of soccer where they're all aggregated around the ball. We need a coach and to get people to come to practice, so we can really play-the-field.

@NamedIdentity commented on GitHub (Jan 28, 2026): @JeffC0628 I'm developing an Agentic Collaboration Framework which optimizes agents to exercise discretion and autonomy by constructing a conceptual framework that helps them figure out how to make appropriate choices rather than making a set of rigid narrow-scope rules. I don't think it'll change how inept Gemini 3 is at tool-calling, but it will models perform much better across a wide-array of tasks. I think when further complete, my work can help define a clearer direction for OpenCode improving agent performance. But, it's WIP and not yet ready to publish. I'm currently trying to adapt DCP into a proper context management system that optimizes for performance, not token usage reduction. That said, if someone at OpenCode is actively working on improving how OpenCode helps agents perform better, it might be worthwhile to collaborate and get on-the-same page. Otherwise, I'll proceed in the expectation this is just going to be a PR fork with a plugin that the community decides what to do with. I've been, hoping to see more efforts at coordinating collaboration in the OpenCode community by maintainers. There's a lot of people interested in building, and developing, and so far, it's scattershot and unfocused. If we can focus that, we could get a lot done. OpenCode development seems to be encountering a huge bottleneck and it's unclear where it is. I feel like OpenCode development is like a kids game of soccer where they're all aggregated around the ball. We need a coach and to get people to come to practice, so we can really play-the-field.
yindo commented 2026-02-16 18:07:55 -05:00
Author
Owner
Copy Link
Copy Source

@JeffC0628 commented on GitHub (Jan 29, 2026):

@JeffC0628

I'm developing an Agentic Collaboration Framework which optimizes agents to exercise discretion and autonomy by constructing a conceptual framework that helps them figure out how to make appropriate choices rather than making a set of rigid narrow-scope rules. I don't think it'll change how inept Gemini 3 is at tool-calling, but it will models perform much better across a wide-array of tasks.

I think when further complete, my work can help define a clearer direction for OpenCode improving agent performance.

But, it's WIP and not yet ready to publish. I'm currently trying to adapt DCP into a proper context management system that optimizes for performance, not token usage reduction.

That said, if someone at OpenCode is actively working on improving how OpenCode helps agents perform better, it might be worthwhile to collaborate and get on-the-same page. Otherwise, I'll proceed in the expectation this is just going to be a PR fork with a plugin that the community decides what to do with.

I've been, hoping to see more efforts at coordinating collaboration in the OpenCode community by maintainers. There's a lot of people interested in building, and developing, and so far, it's scattershot and unfocused. If we can focus that, we could get a lot done. OpenCode development seems to be encountering a huge bottleneck and it's unclear where it is.

I feel like OpenCode development is like a kids game of soccer where they're all aggregated around the ball. We need a coach and to get people to come to practice, so we can really play-the-field.

This is great to hear, and I totally agree about focusing community efforts. Could you outline your current development plan or roadmap? That would make it easier to see where we might work together on agent performance improvements.

@JeffC0628 commented on GitHub (Jan 29, 2026): > [@JeffC0628](https://github.com/JeffC0628) > > I'm developing an Agentic Collaboration Framework which optimizes agents to exercise discretion and autonomy by constructing a conceptual framework that helps them figure out how to make appropriate choices rather than making a set of rigid narrow-scope rules. I don't think it'll change how inept Gemini 3 is at tool-calling, but it will models perform much better across a wide-array of tasks. > > I think when further complete, my work can help define a clearer direction for OpenCode improving agent performance. > > But, it's WIP and not yet ready to publish. I'm currently trying to adapt DCP into a proper context management system that optimizes for performance, not token usage reduction. > > That said, if someone at OpenCode is actively working on improving how OpenCode helps agents perform better, it might be worthwhile to collaborate and get on-the-same page. Otherwise, I'll proceed in the expectation this is just going to be a PR fork with a plugin that the community decides what to do with. > > I've been, hoping to see more efforts at coordinating collaboration in the OpenCode community by maintainers. There's a lot of people interested in building, and developing, and so far, it's scattershot and unfocused. If we can focus that, we could get a lot done. OpenCode development seems to be encountering a huge bottleneck and it's unclear where it is. > > I feel like OpenCode development is like a kids game of soccer where they're all aggregated around the ball. We need a coach and to get people to come to practice, so we can really play-the-field. This is great to hear, and I totally agree about focusing community efforts. Could you outline your current development plan or roadmap? That would make it easier to see where we might work together on agent performance improvements.
yindo commented 2026-02-16 18:07:56 -05:00
Author
Owner
Copy Link
Copy Source

@NamedIdentity commented on GitHub (Jan 29, 2026):

@JeffC0628

@JeffC0628
This is great to hear, and I totally agree about focusing community efforts. Could you outline your current development plan or roadmap? That would make it easier to see where we might work together on agent performance improvements.

My roadmap so far has been, a goal-oriented roadmap. Whatever is necessary to build the tools my litigation/advocacy needs. Which is AI and data systems. To me, litigation isn't practicing law, it's rational analysis and data science.

I just finished the third major iteration of the Agentic Collaboration Framework. Each iteration has aided the construction of the next. ACF has become sophisticated and robust in short order. This coincided with using the ACF SPEC to optimize the dynamic-context-pruning (DCP) plugin so it will optimize a models task performance rather than prioritizing reducing token usage.

Now my agents have a means to intelligently manage their context windows such that they curate context for task performance.

I identified that 'need' many weeks ago, having no idea DCP existed. Just that, I had shared context files that my agents kept having to read over and over, I and needed to find a way to remove old reads to reduce context noise.

I learned about DCP then used what I've built during the past month to build a better DCP (dcp-acf, now) in basically a day. The dcp-acf is a 'band-aid' in my mind, yet compared to what it was, it is quite improved, and so-to is ACF.

I intend to evaluate RickRoss's PR which seems to align with the direction I was going (https://github.com/anomalyco/opencode/issues/4659). My end goal is creating a comprehensive context management system that models manage. I'm not sure if I can build from RickRoss's work, or will have to extract parts of it. But he has something working that needs looking at for sure.

As I find new problems, I'll work to solve them. I travel on a road to a goal; I don't have a map beyond knowing where I am going.

My framework works on the premise that models are smart, getting smarter, and the rules users impose usually make them much less capable then they are absent any instructions at all.

My roadmap is to build a foundational, conceptual framework that will work well now, can be adjusted with minor narrow-scope rules for edge-cases (models have deficiencies; create tools to compensate), and as models improve, release the brakes, and let it fly.

I think that when you create the systems that enable learning and meta-cognition, the models intelligence does the rest.

I don't want to have to wait for models to get smarter to have a smarter system that improves itself. I'm not going to wait.

@NamedIdentity commented on GitHub (Jan 29, 2026): @JeffC0628 > > [@JeffC0628](https://github.com/JeffC0628) > This is great to hear, and I totally agree about focusing community efforts. Could you outline your current development plan or roadmap? That would make it easier to see where we might work together on agent performance improvements. My roadmap so far has been, a goal-oriented roadmap. Whatever is necessary to build the tools my litigation/advocacy needs. Which is AI and data systems. To me, litigation isn't practicing law, it's rational analysis and data science. I just finished the third major iteration of the Agentic Collaboration Framework. Each iteration has aided the construction of the next. ACF has become sophisticated and robust in short order. This coincided with using the ACF SPEC to optimize the dynamic-context-pruning (DCP) plugin so it will optimize a models task performance rather than prioritizing reducing token usage. Now my agents have a means to intelligently manage their context windows such that they curate context for task performance. I identified that 'need' many weeks ago, having no idea DCP existed. Just that, I had shared context files that my agents kept having to read over and over, I and needed to find a way to remove old reads to reduce context noise. I learned about DCP then used what I've built during the past month to build a better DCP (dcp-acf, now) in basically a day. The dcp-acf is a 'band-aid' in my mind, yet compared to what it was, it is quite improved, and so-to is ACF. I intend to evaluate RickRoss's PR which seems to align with the direction I was going (https://github.com/anomalyco/opencode/issues/4659). My end goal is creating a comprehensive context management system that models manage. I'm not sure if I can build from RickRoss's work, or will have to extract parts of it. But he has something working that needs looking at for sure. As I find new problems, I'll work to solve them. I travel on a road to a goal; I don't have a map beyond knowing where I am going. My framework works on the premise that models are smart, getting smarter, and the rules users impose usually make them much less capable then they are absent any instructions at all. My roadmap is to build a foundational, conceptual framework that will work well now, can be adjusted with minor narrow-scope rules for edge-cases (models have deficiencies; create tools to compensate), and as models improve, release the brakes, and let it fly. I think that when you create the systems that enable learning and meta-cognition, the models intelligence does the rest. I don't want to have to wait for models to get smarter to have a smarter system that improves itself. I'm not going to wait.
yindo commented 2026-02-16 18:07:56 -05:00
Author
Owner
Copy Link
Copy Source

@JeffC0628 commented on GitHub (Jan 29, 2026):

@JeffC0628

@JeffC0628
This is great to hear, and I totally agree about focusing community efforts. Could you outline your current development plan or roadmap? That would make it easier to see where we might work together on agent performance improvements.

My roadmap so far has been, a goal-oriented roadmap. Whatever is necessary to build the tools my litigation/advocacy needs. Which is AI and data systems. To me, litigation isn't practicing law, it's rational analysis and data science.

I just finished the third major iteration of the Agentic Collaboration Framework. Each iteration has aided the construction of the next. ACF has become sophisticated and robust in short order. This coincided with using the ACF SPEC to optimize the dynamic-context-pruning (DCP) plugin so it will optimize a models task performance rather than prioritizing reducing token usage.

Now my agents have a means to intelligently manage their context windows such that they curate context for task performance.

I identified that 'need' many weeks ago, having no idea DCP existed. Just that, I had shared context files that my agents kept having to read over and over, I and needed to find a way to remove old reads to reduce context noise.

I learned about DCP then used what I've built during the past month to build a better DCP (dcp-acf, now) in basically a day. The dcp-acf is a 'band-aid' in my mind, yet compared to what it was, it is quite improved, and so-to is ACF.

I intend to evaluate RickRoss's PR which seems to align with the direction I was going (#4659). My end goal is creating a comprehensive context management system that models manage. I'm not sure if I can build from RickRoss's work, or will have to extract parts of it. But he has something working that needs looking at for sure.

As I find new problems, I'll work to solve them. I travel on a road to a goal; I don't have a map beyond knowing where I am going.

My framework works on the premise that models are smart, getting smarter, and the rules users impose usually make them much less capable then they are absent any instructions at all.

My roadmap is to build a foundational, conceptual framework that will work well now, can be adjusted with minor narrow-scope rules for edge-cases (models have deficiencies; create tools to compensate), and as models improve, release the brakes, and let it fly.

I think that when you create the systems that enable learning and meta-cognition, the models intelligence does the rest.

I don't want to have to wait for models to get smarter to have a smarter system that improves itself. I'm not going to wait.

your work on acf and dcp-acf sounds really impressive. I’ve also been focusing on context engineering, but I’ve been thinking a lot about the different goals behind it: are we optimizing context to improve task performance, or primarily to reduce redundancy and cut costs?

In my observations, these two goals don’t always align. For example, aggressively pruning redundant context might not actually lower overall costs, because frequent changes to the context window can hurt inference cache hit rates — which often ends up increasing overhead instead.

Have you encountered this trade-off in your work, or come across any research that addresses how to balance context optimization for performance vs. cost efficiency?

@JeffC0628 commented on GitHub (Jan 29, 2026): > [@JeffC0628](https://github.com/JeffC0628) > > > > [@JeffC0628](https://github.com/JeffC0628) > > > This is great to hear, and I totally agree about focusing community efforts. Could you outline your current development plan or roadmap? That would make it easier to see where we might work together on agent performance improvements. > > My roadmap so far has been, a goal-oriented roadmap. Whatever is necessary to build the tools my litigation/advocacy needs. Which is AI and data systems. To me, litigation isn't practicing law, it's rational analysis and data science. > > I just finished the third major iteration of the Agentic Collaboration Framework. Each iteration has aided the construction of the next. ACF has become sophisticated and robust in short order. This coincided with using the ACF SPEC to optimize the dynamic-context-pruning (DCP) plugin so it will optimize a models task performance rather than prioritizing reducing token usage. > > Now my agents have a means to intelligently manage their context windows such that they curate context for task performance. > > I identified that 'need' many weeks ago, having no idea DCP existed. Just that, I had shared context files that my agents kept having to read over and over, I and needed to find a way to remove old reads to reduce context noise. > > I learned about DCP then used what I've built during the past month to build a better DCP (dcp-acf, now) in basically a day. The dcp-acf is a 'band-aid' in my mind, yet compared to what it was, it is quite improved, and so-to is ACF. > > I intend to evaluate RickRoss's PR which seems to align with the direction I was going ([#4659](https://github.com/anomalyco/opencode/issues/4659)). My end goal is creating a comprehensive context management system that models manage. I'm not sure if I can build from RickRoss's work, or will have to extract parts of it. But he has something working that needs looking at for sure. > > As I find new problems, I'll work to solve them. I travel on a road to a goal; I don't have a map beyond knowing where I am going. > > My framework works on the premise that models are smart, getting smarter, and the rules users impose usually make them much less capable then they are absent any instructions at all. > > My roadmap is to build a foundational, conceptual framework that will work well now, can be adjusted with minor narrow-scope rules for edge-cases (models have deficiencies; create tools to compensate), and as models improve, release the brakes, and let it fly. > > I think that when you create the systems that enable learning and meta-cognition, the models intelligence does the rest. > > I don't want to have to wait for models to get smarter to have a smarter system that improves itself. I'm not going to wait. --- your work on acf and dcp-acf sounds really impressive. I’ve also been focusing on context engineering, but I’ve been thinking a lot about the *different goals* behind it: are we optimizing context to **improve task performance**, or primarily to **reduce redundancy and cut costs**? In my observations, these two goals don’t always align. For example, aggressively pruning redundant context might not actually lower overall costs, because frequent changes to the context window can hurt inference cache hit rates — which often ends up increasing overhead instead. Have you encountered this trade-off in your work, or come across any research that addresses how to balance context optimization for performance vs. cost efficiency?
yindo commented 2026-02-16 18:07:56 -05:00
Author
Owner
Copy Link
Copy Source

@NamedIdentity commented on GitHub (Jan 29, 2026):

@JeffC0628

your work on acf and dcp-acf sounds really impressive. I’ve also been focusing on context engineering, but I’ve been thinking a lot about the different goals behind it: are we optimizing context to improve task performance, or primarily to reduce redundancy and cut costs?

In my observations, these two goals don’t always align. For example, aggressively pruning redundant context might not actually lower overall costs, because frequent changes to the context window can hurt inference cache hit rates — which often ends up increasing overhead instead.

Have you encountered this trade-off in your work, or come across any research that addresses how to balance context optimization for performance vs. cost efficiency?

I came to nearly the same conclusions about the aggressive pruning being counterproductive. When you degrade performance you can end up having to use more compute/tokens to re-read or reperform tasks to get the output quality you need.

I've seen my agents complete a coding task, say it's done, and I ask 'are you really done', and it finds a few things it overlooked that were pretty important. Then I have it task 3 agents (Opus, Gemini 3 Pro, GPT 5.2 Thinking) to review the codebase and the SPEC and the user brief, and audit whether or not the code is ready or needs any additional changes or has room for further improvements. And almost always, yes they find more things missed or ways to improve, and the end product is better because of it.

When aggressive pruning is used, the primary agent is less able to make these types of assessments during the task performance. Optimizing for task performance means less to fix and improve after you complete the the main changes. It can also enable user-agent interactions that lead projects in beneficial directions that otherwise they could not go; the principle of emergent complexity requires first there to be complexity which maintains coherence and transforms a system into a new system that has higher complexity outputs.

Aggressive pruning destroys system complexity, which ends up having less signal and maintains poor coherence (think of it like having a strong thesis vs having a weak hypothesis). Intelligent pruning builds it.

This is, foundational neuroscience honestly. The 101 of neurodevelopment in childhood. We have lots of brain cells, we form lots of connections, and it gets pruned as we develop, and how you form connection and prune dictate the final product - smart kid of not-so-smart kid.

Aggressive Pruning is like giving a child a frontal lobotomy.

It prevents learning and building contextual intelligence in LLMs. Context management needs to facilitate a per-session learning process; you remember what you need and forget what you don't. It's that building of context that leads to the final output. Context building is a process of data transform. It's not 'memory', really. It's structure; it's like DNA. You need to build it so that under a specific circumstance, a stimulus (the last prompts that lead to edits/writes), the 'code' of the context executes to produce the organized system you intended as your target deliverable.

Natural language is code. The context is full of natural language. It must be built to execute to deliver the output.

If you make your thinking partner, the agent, lose its context, you end up with a simple worker managing your project.

I don't have direct data on cache hit rates, and I'm not sure when I might bother to pay attention to that. To me, cost is secondary not because it's unimportant, but because optimized performance produces outputs that are worth added costs. And the system I'm building is a sound design, and getting it built is more important than worrying about usage inefficiencies.

My only assessment at this time on cost/usage changes is noticing my 5-hour and weekly limits seem to climb a bit faster than usual; a very subjective assessment. So long as usage doesn't get maxed before it resets, I'm 'okay' with it.

@NamedIdentity commented on GitHub (Jan 29, 2026): > > [@JeffC0628](https://github.com/JeffC0628) > > your work on acf and dcp-acf sounds really impressive. I’ve also been focusing on context engineering, but I’ve been thinking a lot about the _different goals_ behind it: are we optimizing context to **improve task performance**, or primarily to **reduce redundancy and cut costs**? > > In my observations, these two goals don’t always align. For example, aggressively pruning redundant context might not actually lower overall costs, because frequent changes to the context window can hurt inference cache hit rates — which often ends up increasing overhead instead. > > Have you encountered this trade-off in your work, or come across any research that addresses how to balance context optimization for performance vs. cost efficiency? I came to nearly the same conclusions about the aggressive pruning being counterproductive. When you degrade performance you can end up having to use more compute/tokens to re-read or reperform tasks to get the output quality you need. I've seen my agents complete a coding task, say it's done, and I ask 'are you really done', and it finds a few things it overlooked that were pretty important. Then I have it task 3 agents (Opus, Gemini 3 Pro, GPT 5.2 Thinking) to review the codebase and the SPEC and the user brief, and audit whether or not the code is ready or needs any additional changes or has room for further improvements. And almost always, yes they find more things missed or ways to improve, and the end product is better because of it. When aggressive pruning is used, the primary agent is less able to make these types of assessments during the task performance. Optimizing for task performance means less to fix and improve after you complete the the main changes. It can also enable user-agent interactions that lead projects in beneficial directions that otherwise they could not go; the principle of emergent complexity requires first there to be complexity which maintains coherence and transforms a system into a new system that has higher complexity outputs. Aggressive pruning destroys system complexity, which ends up having less signal and maintains poor coherence (think of it like having a strong thesis vs having a weak hypothesis). Intelligent pruning builds it. This is, foundational neuroscience honestly. The 101 of neurodevelopment in childhood. We have lots of brain cells, we form lots of connections, and it gets pruned as we develop, and how you form connection and prune dictate the final product - smart kid of not-so-smart kid. Aggressive Pruning is like giving a child a frontal lobotomy. It prevents learning and building contextual intelligence in LLMs. Context management needs to facilitate a per-session learning process; you remember what you need and forget what you don't. It's that building of context that leads to the final output. Context building is a process of data transform. It's not 'memory', really. It's structure; it's like DNA. You need to build it so that under a specific circumstance, a stimulus (the last prompts that lead to edits/writes), the 'code' of the context executes to produce the organized system you intended as your target deliverable. Natural language is code. The context is full of natural language. It must be built to execute to deliver the output. If you make your thinking partner, the agent, lose its context, you end up with a simple worker managing your project. I don't have direct data on cache hit rates, and I'm not sure when I might bother to pay attention to that. To me, cost is secondary not because it's unimportant, but because optimized performance produces outputs that are worth added costs. And the system I'm building is a sound design, and getting it built is more important than worrying about usage inefficiencies. My only assessment at this time on cost/usage changes is noticing my 5-hour and weekly limits seem to climb a bit faster than usual; a very subjective assessment. So long as usage doesn't get maxed before it resets, I'm 'okay' with it.
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
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#7680
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?