anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: Support for a local Relevance Index #3255

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

Originally created by @Judahmeek on GitHub (Dec 2, 2025).

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

Problem Summary (from AI):
LLM architecture results in context window data loss because it is bandwidth-limited by the Softmax function. It forces the model to ignore the vast majority of the context to focus on a few spikes. When the context is too long, the "noise" of irrelevant tokens drowns out the "signal" of relevant ones, and the mechanism defaults to looking at the beginning (anchors) and end (immediate context) while losing the middle.

Best Possible Solution that I could think of:
We need a data structure that enables AI to tell what entities are relevant to modifications of any specific entity at a glance, a.k.a. a single script command.

AI is able to figure this out fairly well for any individual entity, but it's currently restricted to storing that information in the context window, which is seriously lossy due to LLM's attention transformer architecture.

Thus, optimal LLM-assisted programming will require a new data system that supplements source code with relevance weights? for the entities that the source code represents. The relevance index wouldn't even have to be exhaustive in order to cause operations that involve a fuzzy search (one of the main things I want AI to be able to do) to be more comprehensive.

Relevance weights could also remind Agents that if they make a change to a particular entity (some configuration of a transpiler or linter, perhaps) that it's a Chesterton's Fence and will likely require changes to lines A & B in File X, and line C in File Z. Or even something as basic as "This comment above this function has particular relevance to these two lines of logic nested about 25 lines down",

Finally, the relevance index needs to be updated somehow upon test failure, because in my experience, test failures are mainly caused by things slipping through the context window's cracks (or by a failure to test changes, either manually or in CI).

This data structure would be stored locally and committed to version control as it could possibly grow to match the size of the code base itself.

Why OpenCode?:
I'd love to see open-source get some bragging rights in the AI war. Also, I'm pretty sure that all the Corps keep their eyes on us.

A little marketing: This isn't the only crazy idea I've had lately. Check out https://github.com/Judahmeek/Significance-Hypothesis-Based-ARC-AGI-2-puzzle-solver for another one.

Originally created by @Judahmeek on GitHub (Dec 2, 2025). ### 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 **Problem Summary (from AI):** LLM architecture results in context window data loss because it is bandwidth-limited by the Softmax function. It forces the model to ignore the vast majority of the context to focus on a few spikes. When the context is too long, the "noise" of irrelevant tokens drowns out the "signal" of relevant ones, and the mechanism defaults to looking at the beginning (anchors) and end (immediate context) while losing the middle. **Best Possible Solution that I could think of:** We need a data structure that enables AI to tell what entities are relevant to modifications of any specific entity at a glance, a.k.a. a single script command. AI is able to figure this out fairly well for any individual entity, but it's currently restricted to storing that information in the context window, which is seriously lossy due to LLM's attention transformer architecture. Thus, optimal LLM-assisted programming will require a new data system that supplements source code with relevance weights? for the entities that the source code represents. The relevance index wouldn't even have to be exhaustive in order to cause operations that involve a fuzzy search (one of the main things I want AI to be able to do) to be more comprehensive. Relevance weights could also remind Agents that if they make a change to a particular entity (some configuration of a transpiler or linter, perhaps) that it's a Chesterton's Fence and will likely require changes to lines A & B in File X, and line C in File Z. Or even something as basic as "This comment above this function has particular relevance to these two lines of logic nested about 25 lines down", Finally, the relevance index needs to be updated somehow upon test failure, because in my experience, test failures are mainly caused by things slipping through the context window's cracks (or by a failure to test changes, either manually or in CI). This data structure would be stored locally and committed to version control as it could possibly grow to match the size of the code base itself. **Why OpenCode?:** I'd love to see open-source get some bragging rights in the AI war. Also, I'm pretty sure that all the Corps keep their eyes on us. **A little marketing:** This isn't the only crazy idea I've had lately. Check out https://github.com/Judahmeek/Significance-Hypothesis-Based-ARC-AGI-2-puzzle-solver for another one.
yindo added the discussion label 2026-02-16 17:39:21 -05:00
yindo commented 2026-02-16 17:39:21 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 2, 2025):

Searching for potential duplicates...

@github-actions[bot] commented on GitHub (Dec 2, 2025): Searching for potential duplicates...
yindo commented 2026-02-16 17:39:21 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Dec 2, 2025):

This issue might be a duplicate of existing issues. Please check:

Your "relevance index" proposal could complement these existing discussions, particularly #2108's RAG/repository map concept and #1990's context management controls.

Feel free to ignore if your feature request addresses a specific gap these issues don't cover.

@github-actions[bot] commented on GitHub (Dec 2, 2025): This issue might be a duplicate of existing issues. Please check: - #2108: [Is there a repository map or RAG feature?](https://github.com/sst/opencode/issues/2108) - discusses indexing and optimizing LLM understanding of codebase structure - #1990: [[Feature Request] Add User Controls for Context Management](https://github.com/sst/opencode/issues/1990) - addresses context window limitations and fine-grained control over what stays in context - #3982: [Context tokens resets to zero with every new action of AI agent](https://github.com/sst/opencode/issues/3982) - discusses context window being reset during multi-turn tasks Your "relevance index" proposal could complement these existing discussions, particularly #2108's RAG/repository map concept and #1990's context management controls. Feel free to ignore if your feature request addresses a specific gap these issues don't cover.
yindo commented 2026-02-16 17:39:21 -05:00
Author
Owner
Copy Link
Copy Source

@Judahmeek commented on GitHub (Dec 2, 2025):

I'd note that https://github.com/sst/opencode/issues/2108 injects information about the codebase into the context window. A relevance index could be accessed through a tool call, almost entirely bypassing the context window, thus risking far less information being lost.

@Judahmeek commented on GitHub (Dec 2, 2025): I'd note that https://github.com/sst/opencode/issues/2108 injects information about the codebase into the context window. A relevance index could be accessed through a tool call, almost entirely bypassing the context window, thus risking far less information being lost.
yindo commented 2026-02-16 17:39:21 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 4, 2025):

Have you considered making a custom-tool that can do this?

It'd be interesting to see how it performs, right now we are focused on some lower level things:

  • overall stability (bug fixes)
  • improvements to baseline tooling: better prompts, better grep (looking at things like ast-grep and mgrep)
  • adding highly in demand features

Typically, people will also have similar idea, then comment on this issue here or on discord and then it will move it up higher in our priority list.

We have some very important things we need to address first, but I like your idea

@rekram1-node commented on GitHub (Dec 4, 2025): Have you considered making a [custom-tool](https://opencode.ai/docs/plugins/#custom-tools) that can do this? It'd be interesting to see how it performs, right now we are focused on some lower level things: - overall stability (bug fixes) - improvements to baseline tooling: better prompts, better grep (looking at things like ast-grep and mgrep) - adding highly in demand features Typically, people will also have similar idea, then comment on this issue here or on discord and then it will move it up higher in our priority list. We have some very important things we need to address first, but I like your idea
yindo commented 2026-02-16 17:39:21 -05:00
Author
Owner
Copy Link
Copy Source

@Judahmeek commented on GitHub (Dec 6, 2025):

One reviewer made the suggestion of indexing the abstract syntax tree for relevance, which may simplify things.

Slightly off-topic: In the context of agentic execution, the same reviewer suggested making every level of abstraction handled by a different sub-agent, but that suggestion runs into the problem of making levels of abstraction discrete enough to distinguish between.

@Judahmeek commented on GitHub (Dec 6, 2025): One reviewer made the suggestion of indexing the abstract syntax tree for relevance, which may simplify things. Slightly off-topic: In the context of agentic execution, the same reviewer suggested making every level of abstraction handled by a different sub-agent, but that suggestion runs into the problem of making levels of abstraction discrete enough to distinguish between.
yindo commented 2026-02-16 17:39:22 -05:00
Author
Owner
Copy Link
Copy Source

@conradkoh commented on GitHub (Dec 23, 2025):

Wanted to quickly share something I wrote - it's a little unpolished but perhaps you could give it a try and make your own that might work better. I wanted something fully local and wanted to be able to see how far I could get with it.

You can give it a try:

npm install -g raggrep
raggrep opencode install

The second command simply adds a raggrep.ts file into your ~/.config/opencode/tool folder

@conradkoh commented on GitHub (Dec 23, 2025): Wanted to quickly share something I wrote - it's a little unpolished but perhaps you could give it a try and make your own that might work better. I wanted something fully local and wanted to be able to see how far I could get with it. You can give it a try: ```sh npm install -g raggrep raggrep opencode install ``` The second command simply adds a `raggrep.ts` file into your `~/.config/opencode/tool` folder
yindo commented 2026-02-16 17:39:22 -05:00
Author
Owner
Copy Link
Copy Source

@Judahmeek commented on GitHub (Dec 24, 2025):

@conradkoh Your repository looks really promising. You should jump on the OpenCode Discord Server & publicize it some.

There's also a thread in OpenCode's Discord of other projects related to indexing that I think you might want to take a look at (I already mentioned your raggrep project on the thread 😅).

@Judahmeek commented on GitHub (Dec 24, 2025): @conradkoh [Your repository](https://github.com/conradkoh/raggrep) looks really promising. You should jump on [the OpenCode Discord Server](https://discord.gg/9ZKWKBdH) & publicize it some. There's also [a thread in OpenCode's Discord of other projects related to indexing](https://discord.com/channels/1391832426048651334/1453183593110310912) that I think you might want to take a look at (I already mentioned your raggrep project on the thread 😅).
yindo commented 2026-02-16 17:39:22 -05:00
Author
Owner
Copy Link
Copy Source

@Judahmeek commented on GitHub (Jan 11, 2026):

Possibly relevant: https://qdrant.tech/articles/hybrid-search/

@Judahmeek commented on GitHub (Jan 11, 2026): Possibly relevant: https://qdrant.tech/articles/hybrid-search/
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#3255
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?