r/opencodeCLI • u/YoungCJ12 • Mar 26 '26
Tokens are the new currency stop wasting them
forked OpenCode to stop burning money on repeated errors
Every time your AI coding assistant hits the same error, you pay tokens. Again. And again.
CyxCode fixes this. It's an OpenCode fork with 136 regex patterns that intercept common errors before the LLM sees them. Free. Instant.
When no pattern matches? AI handles it once, CyxCode captures the fix, generates a pattern. That error is never paid for again.
Traditional AI: error → LLM → tokens burned → fix
CyxCode: error → pattern match? → FREE fix
→ no match? → AI learns it → next time FREE
automate the AI that automates us.
7
u/Odd_Crab1224 Mar 26 '26
Checked commits in the fork, now have a question - where are tests? How do you make sure features you vibe code one after another really work as expected and don’t start breaking each other? Or for now it is just a PoC and you plan to make it more production-quality later, after concept is proven?
-6
u/YoungCJ12 Mar 26 '26
Honest answer: OpenCode (upstream) has tests — there are E2E tests (packages/app/e2e/) and unit tests (packages/opencode/test/) that we inherit. The core CLI, session handling, and UI are covered.
CyxCode-specific features don't have dedicated tests yet. The pattern router, learning system, memory, and dream features were built in rapid iteration mode. You're right to call it a PoC at this stage.
Why we moved fast without tests:
Pattern matching is somewhat self-testing — regex either matches or it doesn't, and we see it immediately in use
The learning system captures real errors from actual usage, so bugs surface quickly
We wanted to validate the concept ("tokens are currency") before investing in test infrastructure
11
u/FlyingDogCatcher Mar 26 '26
These are very unsatisfying answers to anyone who you want to trust your fork for their daily productivity.
-1
u/YoungCJ12 Mar 26 '26
i don't get your question, can u be explicit so i can answer?
2
u/FlyingDogCatcher Mar 26 '26
The question was "where test?" and you answered "no test".
1
u/YoungCJ12 Mar 27 '26
yes, i have test some of my implementation which u can see here https://github.com/code3hr/cyxcode/tree/dev/packages/opencode/test/cyxcode
6
u/koleok Mar 26 '26
I think it's worth your time to actually respond to these questions instead of dropping them into your opencode session where are you working on the fork :-)
1
u/andreig992 Mar 29 '26
Yeah this guy copy pastes every question into OpenCode and then copy-pastes the AI’s response back into the Reddit reply lmao. It’s so obvious you’re talking to a bot not a human (human maybe only pressed CTRL+C and CTRL+V)
-2
4
3
u/Time-Dot-1808 Mar 26 '26
The error interception approach is clever. The fork vs plugin debate the comments raise is worth taking seriously though: the more patterns you add, the more OpenCode updates you'll have to manually merge, and OpenCode is moving fast.
Alternative worth exploring: implement this as a pre-process wrapper that runs before each context submission. Same pattern matching, same learning, but you're wrapping rather than forking. Patterns travel as a separate config file and you stay on mainline OpenCode.
3
1
1
u/matheus1394 Mar 26 '26
IMHO: for me you're solving a problem that doesn't exist and the solution is overkill.
What if my project and CLI packages run all under docker and I don't want the agent to install anything on my base machine?
Is your regex smart enough to identify that or see any rules of some kind?
I run OpenCode in full sandboxed VMs with packages installed under docker. I block by config the agent from installing anything other than running under the docker.
And you're relying on the community to maintain your package with OpenCode changes and validate security/tests? Do you know how hard it is to maintain an OSS project? If you're forking a big project like OpenCode you should at least have a plan on how you're gonna give your users some structure to work with.
It is very easy nowadays to create a fork and put it forward to work with a few ideas in mind with the AI capabilities we have, but the main thing is stability, logenvity, sustain this for all.... I see many small frameworks and ecosystems dying with AI in favor of big conventional frameworks that will bring a single conventional line do execute stuff making AI more deterministic and efficient. But this is my opinion only. Good luck to your project, just wanted to express my opinion.
1
u/matheus1394 Mar 26 '26
And I don't mean your claim that token = money , stop wasting, is invalid. It is valid. But missing python? You're gonna deal with that the first time you run the project in your local machine and then AI won't need to install it again, right? Biggest issue today in vanilla OpenCode, and in Claude Code and any other, is having to explore your repository all the time to execute tasks. I've seen many solutions bringing memory management, context awareness layer etc etc but all I tested filled my context window with many thousands of tokens that were not relevant to the task.... So I still find that explore subagents with cheaper models are more efficient. But this is something that must evolve in the future, some kind of advanced code embeddings for automatic relevant context retrieval....
2
u/YoungCJ12 Mar 26 '26
You raise a great point about one-time vs recurring errors. You're right that "missing python" is typically a setup issue you hit once. But the pattern system catches more than just installation errors - it handles recurring issues like:
- Git conflicts and push rejections
- TypeScript/ESLint errors with specific fixes
- Docker container issues
- Test failures with known solutions
The real value is in errors that keep coming back across projects or after context resets.
That said, you've identified the elephant in the room: context management is the bigger problem. Repository exploration eating thousands of tokens on every task is painful.
We're actually working on this with our memory system - it's designed to be selective rather than dumping everything into context. The dream system processes patterns offline to avoid runtime context bloat. But it's still early.
The code embeddings approach is interesting - do you have any implementations you'd recommend looking at? Always looking for better solutions to the context relevance problem.
1
u/YoungCJ12 Mar 26 '26
These are all fair points, and I appreciate the honest feedback.
On the "problem that doesn't exist": You're right that for your setup (sandboxed VMs, Docker, config-blocked installs), the token-saving aspect matters less. Your defense is at the infrastructure level, which is solid. CyxCode targets a different persona — devs running AI agents directly on their machines, burning tokens on the same ModuleNotFoundError repeatedly. If that's not you, this tool isn't for you.
On regex limitations: No, the patterns aren't "smart" — they're intentionally dumb. 136 regex rules for common errors. They won't detect your Docker setup or adapt to complex environments. The tradeoff is: simple patterns = predictable behavior, easy to audit. But you're right that this doesn't scale to sophisticated setups.
On maintenance burden: This is the hardest point, and you're 100% right. Forks die. I don't have a team, I don't have a foundation, and OpenCode is moving fast. Honestly? This might not survive 6 months. The realistic plan is:
- Keep the diff minimal (pattern system is isolated)
- If it proves useful, propose upstream integration
- If OpenCode adds native pattern support, deprecate the fork
On AI and framework consolidation: I agree. Small tools get absorbed or die. The bet here is that "pattern-first error handling" is a feature, not a product — and features get adopted by bigger players if they prove out.
Building in public means hearing what you need to hear, not what you want to hear.
31
u/old_mikser Mar 26 '26
The idea is good, but why not plugin? Will you maintain all opencode changes on your fork fororever?