Annoying and alarming things about OpenCode

alekq 379 points 247 comments July 20, 2026
wren.wtf · View on Hacker News

Discussion Highlights (20 comments)

josh-wrale

Related post of mine: https://news.ycombinator.com/item?id=48946283

alightsoul

This could be a series of issues on the opencode repo

htrp

Don't use Opencode, Don't use remote models (cloud providers), Don't use Docker to isolate coding agents. May as well write a post saying don't use LLM's for any SWE work. >Conclusion Stop using OpenCode. >Post-script: Local LLMs This is worth its own post – I have multiple attempts in my blog drafts – but it needs to be addressed briefly here. My opinion on local LLMs like Qwen3.6-27B is they are corrosive to the stability and conceptual fidelity of your codebase in the same way as frontier models, with the following three differences: >You avoid the uncanny valley where the model appears to be intelligent before doing something stupid; the stupidity is self-evident and this helps calibrate your interactions. >The weight count is too low to reproduce the training set verbatim, which nudges the calculus on whether the output should be considered tainted. This is distinct from larger models which can reproduce inputs verbatim, but are trained to refuse to. >You avoid supporting or relying upon cloud providers. >I’ve had useful results from input-oriented tasks like: “I think there is a bug in code x with symptoms y, my guess on the mechanism is z. Read all relevant code, come back with a call chain and code citations.” Framing it as a search problem reins in the clanker’s propensity to make shit up. >Using LLMs for code generation feels like a dead end. However thoroughly you think you understand your architecture, your planning is constantly undone by shortcuts like “what if I just move this mutable state into the middle of the design so everyone can share it?” This is hostile to your ability to understand your code, beyond the fact that you didn’t write it. >Drawing answers directly from knowledge in model weights leads to hallucination even for multi-trillion-parameter models, so why bother making them that big? If people were realistic about limitations then we wouldn’t be building new power stations for datacenters, and they wouldn’t be rammed into every product. >The entire software ecosystem around LLMs is completely rotten, and if they do ever become “just a tool” then some actual systems engineering needs to be done around them to turn them into tools instead of security black holes. That work will have to be done by humans.

kristopolous

Opencode offers free models with 200/requests over 5 hours. That's why I use it. It is the only reason I care about. What's the alternative there? Gemini used to have free tiers. Qwen used to. AMP used to. Ollama cloud used to. Codebuff used to... None of them have those programs anymore The reason I use it is purely financial. I do not have an employer and I'm writing free software Edit: pi.dev doesn't have free inference endpoints. That's the constraint.

chuckadams

> If you don’t know what OpenCode is, imagine a boot stamping on a human face forever. The boot is made of TypeScript and the face is everything we have learned about security and systems software since the invention of the electronic computer in the 1940s. I nominate this for a Bulwer-Lytton prize in the Tortured Metaphor category.

volf_

I switched from OpenCode to Pi and there was a big improvement in terms of tool calling performance and I find the experience less buggy. OpenCode has also seemed to have disappeared from https://openrouter.ai/apps/category/coding

tomaytotomato

My bet: In a years time the discussions on using CC, Opencode, Pidev etc. will be redundant as we will be building our own tooling with whatever programming language and tooling you want. Some will repurpose a popular opensource tool or harness, others will build it from scratch in an hour or so.

LaurensBER

I feel that a better title for this article would be: "Some minor annoyances that, when fixed, would improve OpenCode" # Prompt Cache Misses > It globs your filesystem and re-reads AGENTS.md (injected in turn-0 system prompt) on every SSE turn. If you put a quick note in AGENTS.md to be read in the next session, you immediately force a full re-evaluation. > Personal favourite: it puts the current date in the turn-0 system prompt and re-evaluates every SSE turn. If you’re using OpenCode at midnight you get a full prompt cache miss. Okay, I can live with those. # Compaction > Want to sit for 10 minutes while the LLM server prefills the entire session with a new prompt prefixed to it, just to turn it into 5 bullet points that go at the top of a new session? Me neither. I get what they are going for, but I’ve not seen it work well. Neither compaction nor pruning is implemented well, and they interact poorly. Is this an OpenCode specific issue? I've seen the same with Codex and Claude # System Prompts > The default system prompt is opinionated (fine) but it has shit opinions (not fine). It took me a while to figure out why my agent kept saying “Use ABSOLUTELY NO COMMENTS” when dispatching subagents. Okay, so change it? Any LLM is opinionated, this system prompt enforces consistency across different models which seems reasonable.

jmkni

posted just as I start to use OpenCode haha

petesergeant

You should absolutely be running your AI agent inside _some_ kind of sandbox. I put together a list of 19 mostly open-source ones here: https://pleasedonotescape.com/ along with a list of non-project-solutions

singpolyma3

This is an anti AI post masquerading as an anti opencode port. Nevertheless I'm curious what people might suggest to use instead with local models.

archargelod

Good sentiment, wrong target. I took some liberties to fix the beginning: > If you don’t know what AI is, imagine a boot stamping on a human face forever. The boot is made of shit and the face is everything we have learned about security and systems software since the invention of the electronic computer in the 1940s.

codelion

Finally good seeing someone else also getting frustrated with OpenCode and posting the issues.

alanwreath

I’m not really here to defend opencode (or bash it, who has the time?), but in setting up SDD paired with the right tools to both make deterministic black boxes out of certain actions, paired with subagents. I have ran with opencode and qwen 3.2 on a 5090 and I’m getting results on a production codebase of golang where a review of changes from Claude had no changes but acceptance of the solution. I may be missing some aspect of where the local llm’s are losing, but I’m content with draining my local tokens and treating the frontier models like a less junior SWE.

drbscl

Admittedly I prefer Hermes and oh-my-pi, but most of this post is just hyperbole

urvader

About the caching things. This is a flaw in the backend, not in the Frontend. If the backend is only relying on prefix cache you need to look for more fine grained cache solutions like HiCache or Lmcache. If your backend discards the whole cache because of one date is changed, you really can’t blame it on the Frontend. It is an implementation detail that you push to the wrong side.

maxloh

Their "OpenCode" naming is controversial too. Quoting moozilla's comment 11 months ago ( https://news.ycombinator.com/item?id=44741894 ): --- If anyone is curious on the context: https://x.com/thdxr/status/1933561254481666466 https://x.com/meowgorithm/status/1933593074820891062 https://www.youtube.com/watch?v=qCJBbVJ_wP0 Gemini summary of the above: - Kujtim Hoxha creates a project named TermAI using open-source libraries from the company Charm. - Two other developers, Dax (a well-known internet personality and developer) and Adam (a developer and co-founder of Chef, known for his work on open-source and developer tools), join the project. - They rebrand it to OpenCode, with Dax buying the domain and both heavily promoting it and improving the UI/UX. - The project rapidly gains popularity and GitHub stars, largely due to Dax and Adam's influence and contributions. - Charm, the company behind the original libraries, offers Kujtim a full-time role to continue working on the project, effectively acqui-hiring him. - Kujtim accepts the offer. As the original owner of the GitHub repository, he moves the project and its stars to Charm's organization. Dax and Adam object, not wanting the community project to be owned by a VC-backed company. - Allegations surface that Charm rewrote git history to remove Dax's commits, banned Adam from the repo, and deleted comments that were critical of the move. - Dax and Adam, who own the opencode.ai domain and claim ownership of the brand they created, fork the original repo and launch their own version under the OpenCode name. - For a time, two competing projects named OpenCode exist, causing significant community confusion. - Following the public backlash, Charm eventually renames its version to Crush, ceding the OpenCode name to the project now maintained by Dax and Adam.

speedping

If OpenCode is so terrible it wouldn't be the base for many of the fortune 500's internal cli coding agents, Meta included

pelagicAustral

> My conclusion is that OpenCode is clown-car turboslop with a security posture of “let me bend over for you daddy” My type of writing.

alfiedotwtf

Weird this is currently #1 on the front page.

Semantic search powered by Rivestack pgvector
14,369 stories · 134,336 chunks indexed