About Rate limits / Spawning unwanted massive subagents - Share your Opinion

[code-yeongyu]

About Rate limits / Spawning unwanted massive subagents - Share your Opinion

Recently, I've received some feedback stating that "Sisyphus is calling agents excessively, more than necessary."
Although I have personally experienced this occasionally, I am confident that recent fixes have significantly reduced such issues.

However, I still hear feedback such as "it calls 6 sub-agents for a task that would have been sufficient with just a single Grep." I want to clarify that this is not intended behavior, so I would like to ask you to share your specific cases.

Please let me know what prompt you used, which agent appeared, how it acted, what the result was, and—in your opinion—how it should have acted if it were working correctly.

Additionally:

1. The explore agent uses grok-code by default, so no costs are incurred. It does not affect your rate limit.
2. Thanks to recent updates to the installation guide, the librarian agent uses the opencode/big-pickle model unless you are a "max 20" user. Similarly, this does not affect your rate limit.

[askl56]

I am happy to undertake this work, but only if others express interest.

A more judicious use of AST-grep, perhaps temporary AST storage and context slicing within an MCP, would significantly reduce these problems.

For my own purposes, I have built a Rust server with a context broker and a graph database; this yields token reductions of up to 70% for Go, Python, Rust, and TypeScript. That would obviously be overkill for this project, given not everyone has the capacity to run their own graph database; however, there is definitely room for improvement. I say this not to criticise; this project is done very well so far. However, regarding structural alpha, there are still rich seams to be mined.

In answer to the original query, my advice is:

   * Redefine the "Intent Gate": Change the trigger from "2+ files" to "Vague or Abstract Intent" (e.g., "How does this work?" vs "Where is X?").
   * Prioritize Concrete Tools: Explicitly instruct Sisyphus to use grep, lsp, and ast-grep as the default for all concrete searches, even if multiple files are involved.
   * Reserve Agents for Synthesis: Re-brand the explore agent in the prompt as "Deep Contextual Search" and instruct Sisyphus to only use it when it "doesn't know what to grep for."

[psolverdev]

Yeah me too, and it hogs ram like crazy, 3 omo agent call and 8gb is gone? and whats bad is after closing those its still doent reclaim memory, we have to close the opencode itself

[psolverdev]

I am happy to undertake this work, but only if others express interest.

A more judicious use of AST-grep, perhaps temporary AST storage and context slicing within an MCP, would significantly reduce these problems.

For my own purposes, I have built a Rust server with a context broker and a graph database; this yields token reductions of up to 70% for Go, Python, Rust, and TypeScript. That would obviously be overkill for this project, given not everyone has the capacity to run their own graph database; however, there is definitely room for improvement. I say this not to criticise; this project is done very well so far. However, regarding structural alpha, there are still rich seams to be mined.

In answer to the original query, my advice is:

   * Redefine the "Intent Gate": Change the trigger from "2+ files" to "Vague or Abstract Intent" (e.g., "How does this work?" vs "Where is X?").
   * Prioritize Concrete Tools: Explicitly instruct Sisyphus to use grep, lsp, and ast-grep as the default for all concrete searches, even if multiple files are involved.
   * Reserve Agents for Synthesis: Re-brand the explore agent in the prompt as "Deep Contextual Search" and instruct Sisyphus to only use it when it "doesn't know what to grep for."

would be happy if you make that public 😋