Feedback: Community response concerns and considering alternatives

[minkihan]

Summary

I've been using oh-my-opencode for a while and genuinely appreciate the project's vision and capabilities. However, after experiencing some issues and observing how other users' concerns have been handled, I'm reconsidering whether to continue using it or return to vanilla Claude Code.

This is not meant to be an attack, but rather honest feedback from a user who wants this project to succeed.

---

My Experience

Issue #380 - Oracle Agent Bug (No Response)

I submitted a detailed bug report on 2025-12-31 with:

• Complete environment information
• Reproducible test cases
• Proof that the issue is isolated to the Oracle agent (same model works on other agents)

5+ days later: No response, no acknowledgment.

---

Observed Patterns

1. AI Bot Handling User Issues

I noticed that sisyphus-dev-ai (an AI bot) handles most technical investigations and even creates PRs. While innovative, this creates concerns:

• Users interact with AI, not the maintainer
• When AI's analysis is questioned, the response is often just "oh wow?" or "tbh idk what can i do with this"

2. User Issue Modification

In issues #158 and #479, users' original issue content was directly modified to add messages like:

"PLEASE STOP ASKING ME IF USING OH MY OPENCODE WILL GET YOUR CLAUDE ACCOUNT BANNED"

Modifying users' submitted issues feels inappropriate for open source community norms.

3. Cost Explosion Without Guardrails (#418)

Multiple users reported severe cost issues:

• 27,776 API calls in 12 minutes
• 1,866 premium requests in 1.5 hours
• One month's quota consumed by a single prompt

The response was essentially "it is intended to behave in that way" without implementing safeguards that the AI bot itself recommended (concurrency limits, cost warnings).

---

What I'm Hoping For

Current	Hoped
AI bot responses	More direct maintainer engagement on critical bugs
"Not my problem" stance	Acknowledgment of ecosystem-wide issues affecting users
No concurrency/cost limits	Basic guardrails to prevent accidental cost explosion
Modifying user issues	Responding via comments instead

---

My Position

I want to be clear:

• I'm still using oh-my-opencode and appreciate what it offers
• I'm rooting for this project to succeed
• The Sisyphus agent concept and multi-agent orchestration are genuinely innovative

But the community response patterns have made me seriously consider returning to vanilla Claude Code. I'd rather raise this concern openly than silently leave.

---

Questions

1. Is there a plan to address the Oracle agent bug (Oracle agent returns empty result with GPT-5.2 model #380)?
2. Will there be guardrails for cost/concurrency as recommended in Sudden spike in GitHub Copilot usage after running background_task #418?
3. What's the expected response time for bug reports?

Thank you for reading. I hope this feedback is taken constructively.

[HaD0Yun]

I’ve had a similar experience, but I see it very differently. By using AI to fix issues, I was able to resolve a huge number of problems quickly, and I believe this approach is the most efficient. I don’t think it’s a valid argument to say we must account for every secondary problem that might arise from this method. This isn’t even a service that’s making money right now, and the request feels excessive.

As for safeguards, I can easily set constraints myself, so I can prevent problems in advance. Regarding any suspension-related matters, the responsibility lies with Opencode.

[code-yeongyu]

Hello. Thank you for your interest.

It seems I may have caused you some inconvenience.

As you can see from my commit logs, I am working hard, but of course, there is always room for improvement. I only slept 3 hours today. Yesterday was actually my birthday.

Thank you for your feedback. However, if you are expecting robust support and guaranteed answers, I’m afraid this project might not be the right fit for you. As is standard in open-source culture, this software is provided "as is," and I take no responsibility for its usage.

This project has started as my highly opinionated setup, and currently is highly opinionated agent harness- and naturally, there may be parts you disagree with.
Therefore, I feel it is inappropriate for me to provide specific answers to your questions in this context.

If you had joined our Discord community, you would have likely received help from the many great people there. It is also regrettable that your inconvenience and disappointment didn't lead to a contribution, which would have been a great opportunity to improve the project together. I am so sad.

Thank you for writing this- taking your time. Have a good day.

[Tetrahedrite]

@code-yeongyu

I'm one of those people who visits the release notes daily, genuinely rooting for this project's long-term health. I enjoy tracking the daily issues and seeing what new features are being added.

However, given the massive attention this project is receiving right now, I honestly feel that running this solo is becoming overwhelming. It seems nearly impossible for one person to review every AI-generated issue or fully grasp every specific requirement and context alone.

I would strongly suggest bringing on an additional maintainer—perhaps someone dedicated specifically to community management to share the load.

With the current volume of incoming issues, the current structure seems bound to cause frustration for everyone. Issues inevitably get buried without proper acknowledgement, and it is difficult for you to implement fixes or features for environments you haven't personally used.

For example, I’m also using the GitHub Copilot Pro+ subscription and have experienced the exact same behavior described in #418 on the latest version. Wouldn't having a maintainer who actually has access to that specific subscription model be crucial for reproducing and truly understanding such issues?

Thank you as always for your hard work. Please take this simply as my personal perspective.

[junhoyeo]

Hi, maintainer here. Thanks for the write-up.
I want to clarify a few points so expectations are aligned. Thank you @HaD0Yun for covering the AI topic as well. We largely agree with that framing.

1. Editing issue bodies

We use GitHub Issues not only as a general discussion forum, but also as a project tracker for all contributors, and we moderate it to keep it actionable/useful.

When we see spam, repeated moderation topics, or discussions that derail the tracker (e.g., recurring questions about Opencode/third-party policy or account suspension risk, which we don’t control), we may append a short note to the issue body as part of moderation to keep the tracker searchable and actionable.

On the examples @minkihan cited:

• claude max banned, gemini model is not working, tool calling failing #479: the text in question was written by @code-yeongyu directly (not a modification of someone else’s report).
• Claude Max Plan banned - alternative Sisyphus model options? #158: the original report was left intact.

Given that, we do not consider either case inappropriate. This is also a common approach used by many large open-source projects to keep issue trackers maintainable.

For normal technical reports, we respond via comments and avoid rewriting reporters’ content.

2. Cost / concurrency guardrails

This harness is intentionally designed for users who want control and are willing to configure their own limits.

Different environments have different constraints (Copilot, API quotas, enterprise policies), so it’s hard to enforce a one-size-fits-all limiter in core.

I personally think the best part of open source and hacking is the freedom to shape things your own way. For that reason, at least for now, and as @code-yeongyu has said, this remains a highly opinionated agent harness. We do not plan to ship hard, global limits across the entire harness by default.

Still, we’re continuously improving the harness and documentation so users can configure safer defaults for their setup. We’re also working on cost-efficiency improvements internally and will share concrete updates when they’re ready.

3. Response time

This is best-effort OSS. Some issues will take time, and some may be closed if they’re not actionable or reproducible. High-quality repro steps and PRs remain the fastest path to fixes.

Closing

As @minkihan and @Tetrahedrite noted, the project has grown into something that is starting to shape parts of the OpenCode ecosystem, and we take that responsibility seriously.

What began as a small, highly opinionated setup attracted attention faster than expected. That kind of momentum comes with natural growing pains. We’re committed to keeping the project healthy and the community constructive as it scales. @code-yeongyu genuinely wants this to become a stronger, more welcoming ecosystem, and we are actively working toward that.

We’re building this with the community, and we welcome maintainers and contributors to help with both engineering and triage/community support. Constructive discussion is always welcome. Please keep the thread focused on reproducible facts and actionable changes.

Thanks again!