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.
The bigger point is that the codebase is hopelessly bloated by vibe coded features at this point, mirroring the same problems with Claude Code. And stability, performance, memory use have all gotten terrible.
I liked Opencode a lot previously but there's no doubt it's not well-written software. Pi has fully replaced it for me and there are quite a few newer options that learned from Opencode and exercise more minimalism where it matters
I keep seeing these conceptual complaints about OpenCode but it's unreasonably effective, so it's difficult to justify any time spent in changing to something else.
It hardly matters that it's vibe coded and ugly if it works well... and it does (for me).
Saving a few CPU cycles and reducing RAM utilization on my local system isn't going to meaningfully improve anything in and of itself; the wall time is all bounded by the model or by the code it's invoking (i.e. compiling or running the test suite).
For the future, adding the related concepts/themes around hard to search for terms tend to do the trick. Instead of searching "go" for example, do "go programming language". Or instead of "pi", do "pi agent" or even "pi llm".
I am on this trajectory too; opencode got me started but I tried to understand the way it is working and to do that I would normally read the source code, but the source code is really not fun.
This seems to be quite common. You start with OpenCode (assuming you're someone who skips all the Claude Code hype); then you start thirsting for more, and switch to oh-my-pi.
I generally view the kind of code in projects like OpenCode to be the same as binary machine code, and the harness that works on it is the compiler. The source code is the prompts (I guess), except we live in a weird state now we use the existing machine code + more prompts to make even more machine code.
Yeah, this has been my progression as well. Maybe next it'll be just using plain pi when you figured out exactly what you want from omp and what you don't
OpenAI's Codex tool is not limited to only calling their models. You can create a profile that uses any OpenAI API compatible endpoint.
It's written in Rust. It seems to perform well. It also seems (from my poking around in it) on the whole well and deliberately written. It doesn't consume memory like a mf'er like Claude Code. It doesn't sit and chew background CPU like I've seen opencode.
I suspect it will accumulate more specific-to-OpenAI-isms over time though.
Hey! I work on OpenCode, so thank you for this measured reply ;)
Just wanted to add a few things:
- We actually don't do tool-call pruning any more. But compaction is a necessary evil for the time being. There's only so much context window, and if you wish to keep working on the same task for a long time, the model needs to summarize its current progress so it can continue without hitting its token ceiling.
- With V2 (in beta atm), we have a new system for handling changing system instructions (AGENTS.md files, available skills, etc.) that avoids cache misses at all costs, while still giving the robot the newest information. I recorded a little video about it here:
Can you shed some light on what's the deal with the new interface (web/desktop)?
I updated one of my opencode containers today and had to downgrade it back because:
1. Worktree/workspace support is gone altogether. No way for agent to work in parallel on different things safely except prompting it directly to create a worktree.
2. Seeing multiple sessions properly now requires opening tabs for those?
3. In general, switching between several projects/sessions/whatever stopped working, and command palette is hotkey-only.
Issues about the new design just sit in an endless unsolved pile on GitHub which seems hopeless. And an agressive stale bot is not helping with that.
I came to OpenCode because it seemed hackable and simple, and at this point it seems like a "move fast break a lot" project that you got to live with.
(rant over, sorry if this is addressed to the wrong person, just needed to vent a bit)
Workspace support is being worked on, it was half-implemented before, so we are taking a proper pass at it now.
For switching between sessions, can you tell me about your workflow from before? Because a tab can hold a session from any project. Are you saying that opening up a tab is too heavy of an action?
GitHub issues though has been a problem from us, we deal with a ton of noise/spam.
This article has several sections and you are commenting on things under the section titled "Annoying Things".
There is another section titled "Alarming Things", with a subsection titled "It’s Fucking Full of RCEs". (Those are RCEs other than those which simply derive from the issues pointed out in previous subsections).
>> > 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.
So that's why OpenCode likes to randomly remove my comments.
Opinionated system prompts forcing this are awful. It's similar to putting "ALWAYS INDENT WITH TABS" in the system prompt, but worse, because "self-documenting code" is a convenient lie lazy developers like to propagate.
I have the following in my instructions, but I often need to remind agents of it because they follow the shitty system prompt instructions:
"ALWAYS include MANY inline code comments describing what blocks of code are supposed to be doing. Inline comments serve as inline specification, a parity check between the code and the specification, and are a means to _communicate_ with all future programmers, including yourself. Write Once, Read Many. The code needs to talk to whomever is looking at it in natural language."
Cache Misses are pretty bad, i have a locally running deepseek v4 flash, i have tuned it now to have 1100-1300 prefill. Its not great but properly useable. Imagine having a session with already 100k and half of it has to be prefilled it would be waiting minutes with worse numbers. And if you are paying by the token, for hosted models, you are wasting money.
> 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.
I used opencode with deepseek v4 via openrouter during the weekend. Openrouter claims a cache hit rate of about 95%. Maybe it can be improved, but it doesn't seem broken.
I agree that it is bloated, and uses a lot of memory and cpu. But I don't remember seeing any bug during its usage, or at least not big enough to notice
It is a pretty catastrophically dumb CVE, of the sort that makes me not want to allow OpenCode anywhere near any of my machines in the future. It was basically "RCE as a service", not some subtle bug.
Personally, I run pi-agent in a custom sandbox based on bwrap, with an internet proxy. This mostly limits the blast radius to one source tree and one git checkout. And I don't give it push/pull permission. Local models are fun in a "closely supervised but slightly clueless minion" sort of way.
Those are Claude Code security issues? And Claude Code is a gigantic vibe-coded dumpster fire with more bugs than an ant hill?
pi-agent famously doesn't even try to provide a sandbox, so obviously it can't have sandbox security bugs!
I actually think that this is the right model: The agent should not have access to anything it doesn't actually need: User files outside the work tree (except for maybe some allow-listed dotfiles), network access, real credentials, etc. Lock it down tight, and reduce exposure on multiple parts of the "Lethal Trifecta".
there were only 110 words before it said “There are two parts to this post: annoying things and alarming things. The second part is longer.” But I agree it would be better with a table of content at the top (or on the side)
I use nono.sh for sandboxing -- I think a lot of power users are using sandbox + YOLO mode because approval prompts slow them down
yes it's bad if the permission system is broken, but serious users have not trusted this stuff for a while, find the built-in permissions layer burdensome, and are already using a safety layer somewhere else
Which makes sense, but as long as the tool itself pretends to provide security features, the fact that these features don't work is a big problem, as it may provide a false sense of security to end users.
It'd be better if they had absolutely no permission enforcement and delegated it entirely to another program, as you say.
Comments sometimes help the LLM think through a problem. They are particularly useful if you have thinking disabled, eg. it's not uncommon to run Qwen3.6 locally, but its thinking is extremely verbose, so it's fast if you disable thinking, but doing that will sometimes cause it to think a little in comments, and if you disable that too, then it will produce worse output.
That is interesting, I had no idea comments were used in the process. I've only been using frontier models with maxed thinking, but this could be useful on the other end.
> I feel that a better title for this article would be: "Some minor annoyances that, when fixed, would improve OpenCode"
> 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.
Regardless if that's a good or bad take, I'd like titles on HN to reflect what the author wanted to say and not editorialized to what HN readers think the article should be saying.
I always run opencode with envvar `OPENCODE_DISABLE_AUTOCOMPACT=1` because I discover a new horrible bug in its autocompact every time I don't... including the config .json option to turn off autocompact not working.
Sad but not surprised to hear about all these other issues. I like opencode, it does plenty right but plenty wrong.
When I looked into opencode a few months ago I was struck by the default system prompt which came across as messy and random, iirc it also contained a typo or two. It made me look elsewhere and I didn't look back.
> > 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.
OpenCode embeds scatters bad coding policy all over all of its inbuilt prompts, including tool instructions. The only way I've found to fix them is to edit the source code. And, yes, they're also huge and repetitive.
A framework's native prompts should include only information about how to interact with the framework itself.
That's the thing. You can't change it. They do not accept PRs from what I've seen. Whilst it's open source it's only in name. There may be the odd PR accepted from outside the team. But very very rarely.
It's honestly embarrassing to call this open source.
Pi on the other hand, whilst they have their own unique issues with PRs, if you came to them with a genuine problem, or fix, they seem to accept it.
Now I point back to those issues you pointed out, all have PRs... Unmerged. Same with the infinite depth subagent calling.
This is a good summary of the dangers of using agentic clis, but the title & general focus on opencode is odd for two reasons:
1. Most obviously & importantly this is a complaint without a straightforward suggested alternative. A sibling commenter mentions suggesting fixes to Opencode would be more productive: I don't necessarily agree since many of these issues are fundamental & would likely require an almost ground up rethink & rewrite, but the issue is that the article contains no constructive proposal at all: it may as well be titled "Stop Using LLMs"
2. None of the major issues listed are unique to OpenCode. At least the full list within the "Alarming Things" seems in my mind to apply to Claude CLI, & I would guess most other agents from frontier model providers.
Granted it's worthwhile documenting these issues as a plea for someone to build better tooling from the ground up, so the article is far from worthless - on the contrary I've bookmarked it & will be sharing & referencing it widely & often. But the title & focus is just very odd & seems misguided, especially when the contents of the piece is otherwise so good.
Sure, the two main approaches are revoking execute permission from the executable itself, and write-protecting the things that it would modify (like $PWD/.git). Both of these are achievable with sandbox-exec or landlock_restrict_self(2).
This works for the `bash` example too. Spawning a new shell and running arbitrary commands is not an escalation because the child shell inherits the parent's restrictions.
It's an allowlist so not-git would be disallowed by default. Renaming it to a binary that is already listed in the allowlist should fail due to a cryptographic binary signature mismatch.
That's a pretty oddly narrow & specific definition of what LLM harnesses are for & it certainly doesn't match my experience. In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact. Sure many devs might ask it to for convenience of not having to spend 3 seconds typing & running the command themselves but I can't see it ever being explicitly necessary.
I will note you used the term "harness" which - while terms around LLM tooling is still inconsistently defined - in my experience generally pertains to agentic automations: e.g. LLM CI integrations, etc. Rather than interactive local tooling like OpenCode. So maybe you're referring to that (though even then I still can't think of examples)
> In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact.
You should look into "testing". It's when you run the code you just wrote to make sure it works.
For example, in LLM harnesses, it's used to ensure the produced code has the desired properties. It is the key element needed to allow agents to continue to work until they have succeeded.
I mean, ideally enforce W ^ X, and enforce stricter permissions on executables where the agent has flipped the W to X. My broader point is we should be using operating system primitives instead of regex and wishful thinking.
You can't give shell access and then revoke special parts of it. This is not controversial.
All your criticisms apply to all LLM harnesses - and everyone who genuinely cares about these things is using security on top of the harness, because OBVIOUSLY.
This doesn't require cooperation from the shell. If writable paths are non-executable, and executable paths are non-writable, then executing `cp $(which git) my-new-favourite-binary` doesn't grant you permission to run it.
The part which does require cooperation (from outside of the shell, i.e. from the harness) is the ability to upgrade writable paths to executable, at the cost of writability and whatever other restrictions you place on the binaries generated by your agent.
This kind of W^X invariant is widely deployed in every desktop operating system, and the type of W-X upgrade hook I described is used by every JIT engine.
> You are confusing CPU-level security with filesystem-level security.
> I'm curious - how do you expect an LLM harness to build and test executables without being able to build and execute executables?
W^X applies to file systems as well as page tables, and this is called out in paragraph 4 of the Wikipedia article you didn't read. Respectfully, I'm leaving this conversation at this point because it doesn't seem productive.
You did not hit max depth - you hit a timer designed to prevent rage posting.
My question stands - if you accept that LLM harnesses are designed to allow the building and testing of executables - how do you imagine you can prevent the building and running of executables?
This is very doable - it's a shell you're creating within the cli so you have a lot of control over the environment. If you look at tools like sandbox-exec & apparmor, they specifically target binaries, not string input. E.g. if I write a bash script & put it in my path, OpenCode's allowlists aren't looking at the commands my bash script is exec-ing, nor monitoring subshells it creates. A proper sandbox has full context of the execution chain. Not only that, it's potentially much more powerful & expressive in that you can allowlist indirect filesystem access from commands run.
For example, I recently ran opencode via sandbox-exec & naively granted the sandbox access to the aws cli. First attempt to exec it failed because I hadn't granted the sandbox access to the credential file in ~/.aws. This took 2 seconds to resolve but effectively highlights how utterly useless the tree-sitter string-parsing they're doing is. It's so concerning because implementing tree-sitter for that is non-trivial to the point that any competent dev should surely realise quickly while implementing it that this avenue is utterly useless. Yet every high-profile agent cli has taken this approach.
Yes, I am aware that sandboxing technology exists. I use them. I don't expect them to be built into my LLM harness because I value modular software composition - and sandboxing should be provided by a product that specializes in that area.
OpenCode's allowlists are not there for security. They exist for LLM behavior guidance.
I don't honestly believe that the allowlist isn't (naively) intended to be there for security. It's certainly not a very useful ux for providing LLM guidance: prompts, memories & AGENTS.md already provide an avenue for this & having it in a formalised, structured format isn't conducive to LLM guidance. The implementation brings in a lot of dependencies (tree-sitter) & contains enough complex targeted string parsing that's definitely superfluous for something intended to be fed to an LLM as guidance. Perhaps most importantly - the LLM behaviour on encountering limits of the allowlist is neither intuitive nor consistent enough to be considered reliably guiding (& system prompt doesn't do anything to mitigate this).
> I don't expect them to be built into my LLM harness because I value modular software composition
I value software modularity, in particular where software architecture is concerned, but I wouldn't go as far as being prescriptive about the unix philosophy. Direct integration does have its pros, & most of the cons associated with it in practice are specific to bad architecture (or black box software). For example Claude cli does integrate sandbox-exec internally, but it does do in a closed-source inaccessible way that negates its value. I am confident it can be done well though, even if I'm somewhat less confident that it ever will be.
> 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.
"There will be no curiosity, no enjoyment of the process of life. All competing pleasures will be destroyed. But always— do not forget this, Winston— always there will be the intoxication of power, constantly increasing and constantly growing subtler. Always, at every moment, there will be the thrill of victory, the sensation of trampling on an enemy who is helpless.
If you want a picture of the future, imagine a boot stamping on a human face— forever."
That would be an example of a non-torturted metaphor. When you copy the famous quote verbatim and then substitute both parts of it for things that are almost entirely unrelated, it becomes tortured.
Is that right though? I feel like "tortured" is usually used more when one term is overly specific/over-fitted to the other. I've never heard it used like this, where it's about its provenance?
Not that anyone really cares here, but the gp quote isn't even really fundamentally a metaphor either way, its an exhortation to "imagine". The Orwell isn't even a metaphor!
This prose feels extremely angry and ungenerous; abstractly, I agree with a lot of the points, but when I read this:
> My conclusion is that OpenCode is clown-car turboslop with a security posture of “let me bend over for you daddy”. Everyone using it should stop using it.
I do not want to keep reading. There are regular people who wrote this software. When did it become normal to talk about open source like this? How would you feel if someone wrote this about some software that you wrote? Reading this article made me feel extremely gross
I agree with your sentiment, but to answer your question: Since forever. (At least I know examples in the 90's).
In the old days of comp.lang.lisp, there were certain individuals who would really get off on denigrating people who wrote code that was not up to their ivory tower level. Some people left because of it. Others took it as a badge of honor falsely believing that the dressing down was necessary for them to improve their coding skills.
Calling something "vibe-coded" nowadays is a permission slip to unload on it with hyperbole and insults because you can presume there's no human in the line of fire. I really don't think the people engaging in that kind of rhetoric understand how corrosive it is to the humans who do get caught in the crossfire sometimes, and to themselves for normalizing that kind of behavior.
> People familiar with OpenCode internals (if you are on the OpenCode dev team I assume this doesn’t include you) might have objected to my python3 example above.
I promise I'm not normally uptight like this, but there's a difference between having a laugh and whatever this is. Like I said, this feels (a) legitimately angry and (b) in a spit flecked enraged way that has become popular. I guess if you're cool with people calling whatever you work on clown-car turboslop then more power to you.
Author here. Just wanted to say: thank you for posting this. You've given me something to think about, and I regret writing this post the way that I did.
I mean, unless you think AI is conscious and would feel hurt by this, who exactly is harmed here? The prompters? Why? They obviously know the code generated by AI is slop, why would they be hurt by these comments?
I use CC at a client because that's their stack. I use (a particular version of) OpenCode for my own work, because it is so much better. Reading this post makes me sad.
Because everything matches and explains oddities I've seen and forgiven. So despite the hyperbole and the places where the authors' general sentiment are not mine, he's basically right, and I need to find a different harness.
If the post resonates for you too and you've found something better, happy for recommendations. pi seems to get the most mentions here, anyone feel it (or another option) is specifically better on these architectural aspects?
Regardless of its flaws, OpenCode is the harness I’ve been the most productive with by far, and I’ve tried them all.
These are all just some minor annoyances, some disagreements, and most importantly, a fundamental misunderstanding of the point of command filtering. It is not for security, it’s for steering.
Anyway, it didn’t sound like the author tried building anything with OpenCode, and if they did, they said nothing about the most important part: how well did it do?
> a lot of apps run 100% of traffic through openrouter while for us it's a small subset
> but companies we were trying to work with used openrouter as a source of truth on popularity so they thought products that were much smaller were bigger than us
> How you deal with LSP? One of the best things in OpenCode is LSP integration.
I would love to learn how LSP helps you. I did various basic evals with LSP and I did not find it to improve the agent performance at all. Maybe on newer models this gets better because they are now RLing with LSP in the context, but at least in the past having a commit hook that runs lints and typecheck at the end, is more token efficient than having every edit be injected extra LSP results. You are almost guaranteed to be wasting tokens since partial edits are unlikely going to result in type checks passing.
It's for using lsp to do things like symbol renames. It's cheaper to call an LSP server to do those kind of simple refactors than to spend tokens on the model doing it.
It can also use LSP to build context without having to grep around a ton. You don't have to grep and hten pull lines and make guesses for a function. You just ask the LSP for it.
How helpful all that is is heavily dependent on the quality of the language server so usefulness is varies wildly between languages
> It's for using lsp to do things like symbol renames. It's cheaper to call an LSP server to do those kind of simple refactors than to spend tokens on the model doing it.
Is OpenCode pushing the LLM into doing these refactors via LSP? I found that making these refactors with ast-grep is quite efficient.
> It can also use LSP to build context without having to grep around a ton. You don't have to grep and hten pull lines and make guesses for a function. You just ask the LSP for it.
I guess I was not particularly successful with having the agent actually do that. I think what fff is attempting to do (with fuzzy expansion of slightly inaccurate greps) results in better results to me, but even that is debatable.
To be fair, we do not have evals for this today, but we're generally looking into token efficiency and how likely models are at using tools the right way, and we did not find a ton of evidence of LSP helping, even for finding data.
But I would love to see some sessions from people where they have success with LSP data for either refactoring or looking up, because this would be super useful to better understand out blind spots.
To be fair in every harness I've ever used that has LSP support, they never actually utilize the LSP for more deterministic refactoring tools. And even then when I do enable the LSP in many harnesses oftentimes it doesn't even use it at all.
Maybe they haven't been taught to do so or it's not integrated into the system prompt or the tools but all of them only ever use the LSP to read files/symbols.
Every harness I've used will happily just call the edit tool over and over or do a find and replace via sed or programatically call a python/perl script rather than rename a symbol via other means.
It sounds a lot like you are focused on using Pi as a OpenAI/Anthropic wrapper when that isn’t your audience. (Hint: raw token usage is less of a concern).
Oh My Pi has it. I'm a big OMP shill right now. Seems not very popular, but it has the stability of Pi with the features Opencode (and more I think; OMP has web browsing and a more advanced edit system too). OMP often outperforms Claude Code and Codex for me.
I disliked OpenCode's LSP integration, as Pyright kept distracting the model from what I wanted done in a Django project. I prefer to run MyPy at my own convenience
I use a forked version of the pi-lsp. It works pretty well out of the box, but I just tend to fork extensions by default and then hack them up how i see fit.
> Having come from Claude code, I was a bit shocked that both seem to allow edits by default with no confirmation dialog.
There are confirmation dialogs in OpenCode. You can configure them using the permission config, same as Claude Code. Having said that, as a general rule, none of these harnesses are safe to run on your local file system.
I wonder if that's a recent change. When I first started using OpenCode, it didn't ask permissions. I had to manually go and set that config to get it to ask.
There may be differences based on whether the command is under the directory you're running OpenCode from vs some other directory...
I purged OpenCode when I noticed it downloads npm packages in the background without asking the users first. This exposes higher risk of supply chain attach risk.
I find it absurd that a TUI desktop app is heavier than a native one AND heavier than most browser based desktop apps, it's so much waste of RAM, CPU, energy/battery just to show text.
I've been working on my own AI harness/chat in C++ Qt6[1] and it's lighter than anything else even with lots of features like sub-agents, code diff, terminal emulator, simple editor, markdown preview, translucent background, custom themes, permissions, MCP, git integration(commits, stage, diffs), dock system to move elements and tabs for projects; but it's not released yet as I want to polish it a bit, remove a few bugs I found and simplify the UI.
The other day I upgraded my pi.dev coding harness and was testing with Qwen 3.6 35B-A3B model on my Laptop and noticed there was a slight drop in performance from the earlier version I used though the agent worked as expected. Any slight changes in the system prompts will have impact on performance and this is understandable as LLMs are non deterministic. This is the case with any harness including OpenCode. Giving coding harness its own environment (Container/VM) is the best way forward as the article denounces. Running coding agent harness without sufficient guardrails is like sitting on a time bomb. Using AI slop guardrails is still better than having no guardrails.
Including the date in the system prompt - at the cost of a cache invalidation at midnight - is an entirely reasonable decision. Most other harnesses do the same thing.
Including the full datetime would be irresponsible, but that's not what OpenCode does.
It felt unreasonable when I was using it at midnight and had to wait 10 minutes to refill the KV cache on my local GPU :-)
A simple solution here would be to evaluate the date once per session, or once each time the `opencode` binary is launched (to avoid old, long-running sessions getting stuck in the past).
I was confused about how this was written in the article. Sure, include system time, or a simple get current time tool, whatever, it’s inconsequential for the most part, but who is out here changing datetimes in a conversation and invalidating prefixes?
If you need to, just prefix user messages with the current datetime.
I suspect that if you prefixed every user message with a date the model might get confused and start treating the date as more relevant to the current task than it actually is.
some things mention are outdated - particularly the tool call pruning feature. this has been disabled by default for a while specifically because of complaints like this
also i'm pretty excited about our new system prompt approach - can define each component in a way that avoids busting the cache when they change. eg that midnight issue: https://x.com/thdxr/status/2070721003924103651
providers (anthropic is the first) are supporting this as a native concept
Was that issue addressed? The comment where it was marked as closed suggested it "needed more testing" but didn't have any linked PRs.
Gemini translates the closing comment as "We are closing this ticket after a quick look. The login issue is either caused by a wrong setting/external provider, or it's a deeper problem that requires someone to dig into the backend Go server code directly."
> 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.
GAH!!! So that's why its been deleting comments. That is annoying as hell.
FWIW though, I think this applies to other harnesses also (not the annoying bits, but the security risks). I was thinking this morning about how much of a supply-chain vulnerability these tools are. Like, basically, they have a ton of data, they're updated practically daily, and given their vibe coded nature I really doubt anyone is auditing the 10,000 NPM dependencies they drag in. It really will just take one left-pad incident for this to be an absolute disaster.
> Textual command filtering is entirely useless. It is fit for no purpose. Nobody with any instinct or experience in security would even bother to implement this filter because it achieves nothing except a false sense of security.
Not if you only use an allow list. E.g. only allow things matching a particular prefix to run. Also, isn't this what every agent does? And by every I mean Codex because I haven't used the others.
Good to see Codex as a datapoint: I haven't used it. I can confirm though that this is certainly what Claude does, with the addition that Claude's adherence to its own string-match based allowlist seems even less deterministic than OpenCode's.
I haven't independently verified all the claims in the article, but as a codex, Claude, and opencode user, opencode is easily my favorite harness. From a user perspective it's a dream
I agree generally but I'd moderate this to say this is an "anti- the current state of AI" post insofar as none of the issues listed are inherent to LLMs, they just seem to be ubiquitous in the current generation of agentic CLIs. I'm not aware of any CLI that doesn't have the listed severe issues, but I could certainly write a CLI myself (if I had the time & energy) that avoided these issues.
> - Sensible permission system - when the agent runs git diff && rm -rf /, what do you think will happen in your current coding agent? It will treat it as git *. Maki uses tree-sitter to parse the bash command and figure out the permissions requested are git * and rm *. Disable using --yolo.
This sounds identical to what OpenCode does (&, contrary to their own marketing, does not seem sensible at all).
The fact that this mechanism is so primitive across all agentic clis is frankly a serious indictment of the competence & experience behind LLM-focused development teams.
This is a security issue that has in the past been solved via explicit file-path-based allowlisting, & more recently - due to file-path matching being deemed insufficiently secure - apps have been switching to cryptographically signed binary matching as a more modern alternative to the less secure path matching. In that context, the fact these recently-written "modern" agentic clis are using a method that's more basic & even less secure than the "old insecure" method most apps use is pretty shocking.
Maybe sandboxing isn't the job for an agent harness?
Maybe choosing a VM as your sandbox, with access only to project directory.. and then enabling YOLO mode on the agent, is the way to go.
And in any case, for an agent that can write and run code, no allowlist for which programs are allowed to run is sufficient, since the agent can just write the code the program would run anyway. And the issue isn't which software the agent runs, but whether they inherit the same ambient authority as your user - read the same files as you do, modify your config files, etc. Running in a VM stops that.
I've run agentic CLIs in a sandbox (using MacOS sandbox-exec) & in VMs - both solutions have an inherent advantage over any integrated sandboxing by virtue of their independence (even before we get into configurability). Claude CLI integrates sandbox-exec internally, but I can't really trust it completely because Anthropic don't really have any vested interest in restricting their own tooling on my machine - they want me to rely on the tooling more, not less, which naturally entails granting the tool broader access: this is reflected in two ways in their sandbox-exec implementation: (1) it's wrapped in a relatively lax default profile & (2) not everything the cli does is sandbox-wrapped.
All that said, I don't think I'd agree that sandboxing doesn't belong in the agent harness. Ultimately, I want to be using an open source cli tool that doesn't come with the above Anthropic perverse incentives. The advantage of using a separate sandbox solution with Claude CLI isn't that it's separate, it's that I control it. Ideally I should control my agentic cli though, & in that context, bundling the sandbox comes with a lot of inherent advantages.
Unfortunately, as far as I've seen, the current batch of open source clis are pretty poor at the above, leaving little incentive to switch from proprietary solutions.
I really, really wanted to make agent sandboxes work. Filed issues on the sandbox created by Anthropic and later also adopted by Copilot, and also to Codex repository. I think none of them is actually usable - they either allow too much or too little.
There is one case where VMs are not fit, and it's when you need to do GPU work. Well unless you have gpu passthrough or virtual gpus.
I've used VMs because dealing with tool access is infinitely simpler & less fraught than tailoring sandbox profiles, but ultimately using sandbox-exec has yielded better workflows (if & when I've gotten an appropriate profile stood up). The sandbox tends to have a lot more rough edges than the VM, so I do switch back & forth between VM & sandbox, but I suspect a good sandbox-wrapping implementation with nice ux is the future.
Perhaps one could go further & combine them: e.g. a sanbox-wrapped on-host CLI that subshells/subagents out to VMs on demand. Seems potentially overcomplicated but I guess one can dream.
> The fact that this mechanism is so primitive across all agentic clis is frankly a serious indictment of the competence & experience behind LLM-focused development teams.
Not at all. The proper solution to this problem is running in a sandbox - which is not reinvented by the LLM harness because there are already many great options.
You misunderstand the mechanism. It is not intended to provide security. It is intended to guide LLM behavior.
OpenCode is pretty awesome. The article appears written by someone who couldn’t handle a glance behind the curtain and definitely should not research how sausages are made.
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.
I am afraid this is a very click-baity title. I actually opened the article and thought I would learn something from it.
Instead what I read was typical issues about Agentic CLI's in general dubbed as `alarming`. I would have been happy if the title was just `Annoying` which a lot of `OpenCode` is. But adding the `alarming` made it what it became, something that attracts enough eyeballs to get to the front page of HN.
Heavy disagree. I can't be sure about other AI coding agents as I haven't used others enough, but especially the items around prompt cache misses and compaction have hit me personally.
This article (combined with another article previously comparing CC and OC's system prompt, to which someone replied pi.dev sends even less) has made me want to switch agents, so I'm likely going to try out pi.dev and aim to migrate.
I don't know whether other arguments are true, but some arguments in the end are right:
> Using LLMs for code generation feels like a dead end. ..., This is hostile to your ability to understand your code, beyond the fact that you didn’t write it.
What you get from AI is not worth of what you have invested for it in long period.
> Drawing answers directly from knowledge in model weights leads to hallucination even for multi-trillion-parameter models, so why bother making them that big?
Current AI is like the film company producing TV series or movies. "If similar stories do not exist or details are missing, screenwriters use imagination to fill in the gaps (remember hallucination? It's just a makeup.)", refer to the article https://devcyc.life/current-ai-is-like-the-film-company-prod...
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.
The solution is not to use docker to sandbox Opencode. It is to use flatpak/bubblewrap/flatseal.
I have vscode running in flatpak with directory permissions handled by flatseal. Vscode only has access to my dev folders and nothing else. Even the git bundled by vscode cannot call git push because of this (vscode doesn't have permission to read ~/.ssh!).
It's an easy sandbox that's provided free of charge courtesy of bubblewrap/flatpak.
As someone who uses opencode regularly, the quip about it asking for permission to read logs in /tmp after already writing to the directory is pretty funny.
Re local LLMs: “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.”
Thanks for that, I've been using it but some of these are bad. Specially that it sends data to the cloud by default for session titles, since I use my local model exclusively. So I'm done with it, trying maki now which seems promising and it's so much lighter.
For some reason OpenCode doesn't find my local models through LM Studio. Instead it shows three other models that I don't have.
I guess I should add the models myself in opencode.json, but I generally dislike hardcoding things when computers are really good at listing things. The model list is right there in the API, please just use it.
Interesting article. What are the alternatives that address the issues raised?
I see some folk recommending https://pi.dev/.
Has anyone used https://aider.chat/ and liked it?
- 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.
>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.
This seems to be capturing a feeling I am finding messing with local LLMs: popular software around this seems to be slop coded by no talent hacks. It's a common experience to see a python process pegged at 100% CPU with a huge amount of memory allocated, seemingly doing something that could be a simple shell script. That is before stuff reaches the LLM.
If that runs on somebody else's machine, you don't notice. When you see it in top it's frustrating.
I have an MBP M4 Max 128 GB and have encountered these very limitations, though many are averted by using Qwen3.6-35B-A3B. I'm also not sure there's a magical harness out there that obviates these limitations.
It's not a great UI, but for messing with ideas in a VM, the free tier is very hard to beat, otherwise I'd be on Claude Code, but still on a VM, because I won't let them near anything I actually care about.
There are a number of points I completely agree with in this blog post. Security implications, handing out all your data to anthropic/openai/google, allowing a slop machine to execute arbitrary code on your machine and having full access to your network is something that would have made anyone working in security commit a ritual suicide just thinking about it as recent as 2022-2023. And I am baffled by the fact that we all sign tons of NDA's as part of our employment contracts, just to throw all out the window by giving it all away to anthropic/openai/google etc, at what is effectively a symbolic fee. We all know it costs a lot more than 100 bucks a month or whatever it is they charge.
That said, I firmly believe that if AI is to survive, the future HAS TO BE local or near-local. Having said that, statements such as
> Docker causes security holes:
> It creates a god-service that runs as root.
> It deliberately punches a hole in ufw firewalls.
Sorry, none of those are correct IF you know what you are doing. Though I will admit, seeing people that know what they are doing is increasingly uncommon.
Also there is nothing wrong with developing inside containers. If anything, that is arguably one of the biggest selling points for containers - environment(s) you can crash infinitely at no cost.
I still dislike opencode for a bunch of reasons - the assumption that llms are immune to screw ups, being one. As for the default behavior - using cloud by default - I didn't know that(I do not use any AI for direct coding tasks) and if that is the case, yeah, this is bad. Undeniably a horrible decision.
Yeah, this is one of the weaker parts of the post because I didn't really make my position clear: that sandboxing should be a first-class integral part of every harness, not an afterthought that risks putting something you care about on the same side of the trust boundary as the LLM.
Some of my own frustrations with bad Docker deployments leaked through. I did snip some of them out way back when I posted this, but maybe not enough.
> that sandboxing should be a first-class integral part of every harness,
Essentially, what you want is that the people who produce harnesses like OpenCode to also implement proper sandboxing and security. Why... why do you believe they'll do anything remotely satisfactory?
It's been empirically demonstrated, again and again, that at least 85% of software developers (and this is a very generous estimation) can not be trusted to bother about the security, so leaving the implementation of the security mechanisms and policies up to them simply doesn't work in practice. It just doesn't.
Any recommendations for non-typescript-based coding TUI harnesses/agents other than Codex? Given that Codex is open source someone should've built an untethered client?
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.
unless someone fixes the issues with LLMs at a fundamental level those will all have the same kinds of issues as is described with OpenCode and they will all be horrendous.
> "I just don’t want to use Docker for development – if your dependencies are so sprawling that you’ve lost track of how to install them on a new machine, why do you have so many?"
I mean, there's a perfectly good solution for many of the security issues mentioned in the article... But it is dismissed because the author just doesn't "want to"?
By the way, LXC is probably better suited for reproducible build/development environments, over Docker.
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.
Opencode's cache hit rate is better than claude code. Opencode has in my experience been better than any of the closed source / closed development alternatives and is not locked down.
> 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.
Um. Which then gets immediately cached again.
I prefer this behavior. I prefer my changes incorporated immediately, rather than wait for the next session. Call me crazy.
(Author is unhinged and this story is upvoted because #AI-HATE.)
I also would want anything that I saved into AGENTS.md to be incorporated right after I saved it.
I might accept if my newly saved information was overlooked, but it's hard for me to fathom how I'd demand "I want to save this information in AGENTS.md now, but I don't want you to look at it until the next time I launch you..." and call any behavior other than that annoying or alarming.
Also, aren't instructions earlier in the prompt treated with more weight than those that occur much later? Sure, you could insert the system prompt later to avoid re-caching as much, but then the system prompt (if I am understanding correctly) carries MUCH less weight.
(And also your point about immediately being re-cached a good one)
It’s a shame they have such a dominant position in terms of harnesses. There are many much better alternatives that deserve attention. Especially since one of their main devs is such an asshole online.
OpenCode is indeed bad, but it's the least bad agent out there :(
Plugin opencode-slim-system can be used to override the system prompt and the tool description for any tool (including bash). It helps a lot to fix their nonsense.
magic-context plugin fixes the compaction issues.
Run the entire process in landstrip for sandboxing to alleviate any bash concerns.
I'm glad that when I recommended opencode to a friend, I taught them first to install a vm and create an app specific user to boot.
Many users did things right the first couple of days and then turned the security off after seeing it 'work fine' on its own.
Was a cool thing to use for a couple of weeks in v1, you have to be quite static to keep using it at v68 of self vibecoding while the llm providers like openai already developed their in house alternative.
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
Yeah, I don't think that line quite landed. My point was that LLMs are inherently adversarial (read, "relentlessly proactive") and sandboxing should be a first-class integral feature of your harness, not an afterthought. The problem with dev containers is you still tend to end up with something you care about on the same side of the trust boundary as the LLM.
> LLMs are inherently adversarial (read, "relentlessly proactive") [and] you still tend to end up with something you care about on the same side of the trust boundary as the LLM
I mean this is a problem with many coworkers too, so you deal with it in the same way: limit what they can do to creating pull requests.
Cache misses are the one reason I stopped using OpenCode in favor of Pi. OpenCode mutates the system prompt every turn, which is completely unacceptable and betrays such a basic misunderstanding of LLMs that I can't in good conscience trust the rest of the product regardless of how technically impressive it is.
> If OpenCode is so terrible it wouldn't be the base
Ignoring the appeal to authority inherent to this kind of statement, it's ignoring another implication. Large companies can afford to maintain a fork. Using the latest release of OpenCode day to day is a different proposition than serving as some corporate developmental branch "base", as shorthand for all sorts of changes/usage.
Well, out of the agentic harnesses available, OpenCode is the most promising and capable whilst still remaining open; proprietary alternatives like Claude Code have all these problems and more. So I guess the only way out is to just not use LLMs for development at all.
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.
As I said in other reply there's Mimo. But I would check the opencode Go plan. First month for 5 usd and renewal at 10. (With referral offers too). If you use only deepseek flash it would take you a long way every month.
Yes I understood your other comment. I used free models for a long time. Less than 6 months ago there were a ton of options but the current free choices are very limited in number and usability. They run out way too quickly and some of them have smaller context sizes than paid offerings. As far as I know the only currently really free offering is Mimo via their own CLI.
Go is not free at all (you can't use any of the models you listed without a subscription) and the free Zen models will not be on other CLIs as far as I know.
The mix of humanizing the LLM, calling it "clanker" and being very aggressive towards it is really weird. I don't think it's a good habit to take, it feels like it could bleed into how you interact with people. Many interactions are through text interfaces these days.
The mouth speaks what is in the heart. What is inside eventually leaks out. In anonymized spaces, this is especially true, and has been acknowledged from the beginnings of the internet (and perhaps long before). When you don a mask, your heart speaks freely.
But the knife cuts both ways. As you speak, so will your heart be. I think modern psychology supports this. Actions drive attitude, and attitude drives actions. If you assert your will in either place, the other is disrupted and will adjust.
You can literally change yourself into whoever you want to be. But a passive participant in this process will simply show the world what kind of person they are without ever realizing it.
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.
That's not how it works. While there are some research papers looking into using chunks of kv cache while discarding others, those involve architecture changes in the models themselves. HiCache / LMcache (used in sglang/vllm) are ways of optimising the juggling of kv cache, but IIUC it still needs to be token perfect atm.
Prefix caching is inherent in how global softmax attention works. Modifying the prefix invalidates the suffix because the suffix's cached KV projections are a function of the hidden state after the model has evaluated the prefix.
There have been some attempts to approximately stitch KV blocks without full re-evaluation (see: CacheBlend on arxiv), but the results aren't promising.
You mentioned HiCache: as far as I can tell this is a prefix tree cache that efficiently shares prefixes across related histories. If you change the prefix, everything after the change still misses the cache and needs to be prefilled again.
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.
The bigger point is that the codebase is hopelessly bloated by vibe coded features at this point, mirroring the same problems with Claude Code. And stability, performance, memory use have all gotten terrible.
I liked Opencode a lot previously but there's no doubt it's not well-written software. Pi has fully replaced it for me and there are quite a few newer options that learned from Opencode and exercise more minimalism where it matters
I keep seeing these conceptual complaints about OpenCode but it's unreasonably effective, so it's difficult to justify any time spent in changing to something else.
It hardly matters that it's vibe coded and ugly if it works well... and it does (for me).
Saving a few CPU cycles and reducing RAM utilization on my local system isn't going to meaningfully improve anything in and of itself; the wall time is all bounded by the model or by the code it's invoking (i.e. compiling or running the test suite).
Got a link? Pi is suitably as to make search engines questionable
For the future, adding the related concepts/themes around hard to search for terms tend to do the trick. Instead of searching "go" for example, do "go programming language". Or instead of "pi", do "pi agent" or even "pi llm".
While this is a generally useful suggestion you are giving, for Go in specific you can just use "golang".
All of the major search engines have understood that as a stand-in for "Go the programming language" for many years.
Yeah. That is a sore point.
It has overridden a 4000 year old strategy board game played by millions (mostly Asians).
"golang" is literally "Go language". Doesn't matter that it's one word.
pi.dev
I am on this trajectory too; opencode got me started but I tried to understand the way it is working and to do that I would normally read the source code, but the source code is really not fun.
This seems to be quite common. You start with OpenCode (assuming you're someone who skips all the Claude Code hype); then you start thirsting for more, and switch to oh-my-pi.
I generally view the kind of code in projects like OpenCode to be the same as binary machine code, and the harness that works on it is the compiler. The source code is the prompts (I guess), except we live in a weird state now we use the existing machine code + more prompts to make even more machine code.
Yeah, this has been my progression as well. Maybe next it'll be just using plain pi when you figured out exactly what you want from omp and what you don't
No one here started with Aider? Or even text-generation-webui? Or SillyTavern? Or were they too pseudo-agentic? :)
I like how browser and websearch is handled in omp. But I only like these two features, it might be time for me to actually spend some time with pi
Can you name a few? I'm looking for alternatives
Pi or Dirge
write your own using pi.
OpenAI's Codex tool is not limited to only calling their models. You can create a profile that uses any OpenAI API compatible endpoint.
It's written in Rust. It seems to perform well. It also seems (from my poking around in it) on the whole well and deliberately written. It doesn't consume memory like a mf'er like Claude Code. It doesn't sit and chew background CPU like I've seen opencode.
I suspect it will accumulate more specific-to-OpenAI-isms over time though.
Hey! I work on OpenCode, so thank you for this measured reply ;)
Just wanted to add a few things:
- We actually don't do tool-call pruning any more. But compaction is a necessary evil for the time being. There's only so much context window, and if you wish to keep working on the same task for a long time, the model needs to summarize its current progress so it can continue without hitting its token ceiling.
- With V2 (in beta atm), we have a new system for handling changing system instructions (AGENTS.md files, available skills, etc.) that avoids cache misses at all costs, while still giving the robot the newest information. I recorded a little video about it here:
https://x.com/kitlangton/status/2075749116760457346/video/1
Just checked out the video...you, my friend, could be a professional voice actor (assuming that job still exists in the future).
Can you shed some light on what's the deal with the new interface (web/desktop)?
I updated one of my opencode containers today and had to downgrade it back because:
1. Worktree/workspace support is gone altogether. No way for agent to work in parallel on different things safely except prompting it directly to create a worktree.
2. Seeing multiple sessions properly now requires opening tabs for those?
3. In general, switching between several projects/sessions/whatever stopped working, and command palette is hotkey-only.
Issues about the new design just sit in an endless unsolved pile on GitHub which seems hopeless. And an agressive stale bot is not helping with that.
I came to OpenCode because it seemed hackable and simple, and at this point it seems like a "move fast break a lot" project that you got to live with.
(rant over, sorry if this is addressed to the wrong person, just needed to vent a bit)
Yeah it's a big change.
Workspace support is being worked on, it was half-implemented before, so we are taking a proper pass at it now.
For switching between sessions, can you tell me about your workflow from before? Because a tab can hold a session from any project. Are you saying that opening up a tab is too heavy of an action?
GitHub issues though has been a problem from us, we deal with a ton of noise/spam.
Does V2 finally imminentize the eschaton? V1 has completely failed at this so far
I see what you did there ;P
> I feel that a better title for this article would be: "Some minor annoyances that, when fixed, would improve OpenCode"
Those are labeled as "annoying things"
Read also the "alarming things"
This article has several sections and you are commenting on things under the section titled "Annoying Things".
There is another section titled "Alarming Things", with a subsection titled "It’s Fucking Full of RCEs". (Those are RCEs other than those which simply derive from the issues pointed out in previous subsections).
>> > 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.
So that's why OpenCode likes to randomly remove my comments.
Opinionated system prompts forcing this are awful. It's similar to putting "ALWAYS INDENT WITH TABS" in the system prompt, but worse, because "self-documenting code" is a convenient lie lazy developers like to propagate.
I have the following in my instructions, but I often need to remind agents of it because they follow the shitty system prompt instructions:
"ALWAYS include MANY inline code comments describing what blocks of code are supposed to be doing. Inline comments serve as inline specification, a parity check between the code and the specification, and are a means to _communicate_ with all future programmers, including yourself. Write Once, Read Many. The code needs to talk to whomever is looking at it in natural language."
Cache Misses are pretty bad, i have a locally running deepseek v4 flash, i have tuned it now to have 1100-1300 prefill. Its not great but properly useable. Imagine having a session with already 100k and half of it has to be prefilled it would be waiting minutes with worse numbers. And if you are paying by the token, for hosted models, you are wasting money.
# 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.
I used opencode with deepseek v4 via openrouter during the weekend. Openrouter claims a cache hit rate of about 95%. Maybe it can be improved, but it doesn't seem broken.
I agree that it is bloated, and uses a lot of memory and cpu. But I don't remember seeing any bug during its usage, or at least not big enough to notice
DeepSeek has a phenomenal cacheing architecture that specifically can work with less-than-ideal clients like this and get cache hits anyway.
Definitely agree on the title. Also could have worked as 'Some minor annoyances that, when fixed, would improve OpenCode. Also, I don't like AI"
Did both of you intentionally skip the part of the article about the critical security issues?
The RCE they mention was fixed in December, 2025:
https://github.com/anomalyco/opencode/releases?page=21#relea...
It is a pretty catastrophically dumb CVE, of the sort that makes me not want to allow OpenCode anywhere near any of my machines in the future. It was basically "RCE as a service", not some subtle bug.
Personally, I run pi-agent in a custom sandbox based on bwrap, with an internet proxy. This mostly limits the blast radius to one source tree and one git checkout. And I don't give it push/pull permission. Local models are fun in a "closely supervised but slightly clueless minion" sort of way.
I too love and use pi agent.
But all of these agents have or had "dumb" security issues:
https://github.com/anthropics/claude-code/security/advisorie...
You probably know that since you run pi inside https://github.com/containers/bubblewrap.
Those are Claude Code security issues? And Claude Code is a gigantic vibe-coded dumpster fire with more bugs than an ant hill?
pi-agent famously doesn't even try to provide a sandbox, so obviously it can't have sandbox security bugs!
I actually think that this is the right model: The agent should not have access to anything it doesn't actually need: User files outside the work tree (except for maybe some allow-listed dotfiles), network access, real credentials, etc. Lock it down tight, and reduce exposure on multiple parts of the "Lethal Trifecta".
There were 3,905 words above any mention of an RCE. Can you blame them?
there were only 110 words before it said “There are two parts to this post: annoying things and alarming things. The second part is longer.” But I agree it would be better with a table of content at the top (or on the side)
I use nono.sh for sandboxing -- I think a lot of power users are using sandbox + YOLO mode because approval prompts slow them down
yes it's bad if the permission system is broken, but serious users have not trusted this stuff for a while, find the built-in permissions layer burdensome, and are already using a safety layer somewhere else
Which makes sense, but as long as the tool itself pretends to provide security features, the fact that these features don't work is a big problem, as it may provide a false sense of security to end users.
It'd be better if they had absolutely no permission enforcement and delegated it entirely to another program, as you say.
I actually share that opinion of no comment from LLMs. I just dont want to read them. So as usual, an opinion is… an opinion.
Comments sometimes help the LLM think through a problem. They are particularly useful if you have thinking disabled, eg. it's not uncommon to run Qwen3.6 locally, but its thinking is extremely verbose, so it's fast if you disable thinking, but doing that will sometimes cause it to think a little in comments, and if you disable that too, then it will produce worse output.
Comments can always be stripped reliably later.
That is interesting, I had no idea comments were used in the process. I've only been using frontier models with maxed thinking, but this could be useful on the other end.
IMO, if you "put a quick note in AGENTS.md" then you should expect a cache miss.
I think that is reasonable and intuitive.
That was the first complaint I came across in the article and it made me question the level of indignation of the whole thing.
> I feel that a better title for this article would be: "Some minor annoyances that, when fixed, would improve OpenCode"
> 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.
Regardless if that's a good or bad take, I'd like titles on HN to reflect what the author wanted to say and not editorialized to what HN readers think the article should be saying.
I always run opencode with envvar `OPENCODE_DISABLE_AUTOCOMPACT=1` because I discover a new horrible bug in its autocompact every time I don't... including the config .json option to turn off autocompact not working.
Sad but not surprised to hear about all these other issues. I like opencode, it does plenty right but plenty wrong.
When I looked into opencode a few months ago I was struck by the default system prompt which came across as messy and random, iirc it also contained a typo or two. It made me look elsewhere and I didn't look back.
> > 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.
OpenCode embeds scatters bad coding policy all over all of its inbuilt prompts, including tool instructions. The only way I've found to fix them is to edit the source code. And, yes, they're also huge and repetitive.
A framework's native prompts should include only information about how to interact with the framework itself.
yet OpenCode is #1 harness per Artificial Analysis
https://artificialanalysis.ai/agents/coding-agents?coding-ag...
That's the thing. You can't change it. They do not accept PRs from what I've seen. Whilst it's open source it's only in name. There may be the odd PR accepted from outside the team. But very very rarely.
It's honestly embarrassing to call this open source.
Pi on the other hand, whilst they have their own unique issues with PRs, if you came to them with a genuine problem, or fix, they seem to accept it.
Now I point back to those issues you pointed out, all have PRs... Unmerged. Same with the infinite depth subagent calling.
Open source doesn't mean that it has to accept PRs. It has never meant that the code author's must accept community contributors.
OpenCode has an MIT license, which allows you to copy/fork the code and modify it how you see fit.
Please review the open source initiative's definition of open source: https://opensource.org/osd
SQLite famously doesn't accept PRs either, and it's public domain.
I pinged the OC devs to get someone else's PR merged to fix a slop artifact, they did indeed merge external PRs.
Like many popular Ai projects, they get 1000s of slop PRs. They are also working on a v2, so fixes to old code are much less likely to land now.
This is a good summary of the dangers of using agentic clis, but the title & general focus on opencode is odd for two reasons:
1. Most obviously & importantly this is a complaint without a straightforward suggested alternative. A sibling commenter mentions suggesting fixes to Opencode would be more productive: I don't necessarily agree since many of these issues are fundamental & would likely require an almost ground up rethink & rewrite, but the issue is that the article contains no constructive proposal at all: it may as well be titled "Stop Using LLMs"
2. None of the major issues listed are unique to OpenCode. At least the full list within the "Alarming Things" seems in my mind to apply to Claude CLI, & I would guess most other agents from frontier model providers.
Granted it's worthwhile documenting these issues as a plea for someone to build better tooling from the ground up, so the article is far from worthless - on the contrary I've bookmarked it & will be sharing & referencing it widely & often. But the title & focus is just very odd & seems misguided, especially when the contents of the piece is otherwise so good.
I wonder how he imagines you can give shell access but securely prevent arbitrary command execution.
His complaint that "echo git | bash" still works is particularly nutty.
Sure, the two main approaches are revoking execute permission from the executable itself, and write-protecting the things that it would modify (like $PWD/.git). Both of these are achievable with sandbox-exec or landlock_restrict_self(2).
This works for the `bash` example too. Spawning a new shell and running arbitrary commands is not an escalation because the child shell inherits the parent's restrictions.
And what would prevent the LLM from downloading and compiling its own version of git? But it names it "not-git".
It's an allowlist so not-git would be disallowed by default. Renaming it to a binary that is already listed in the allowlist should fail due to a cryptographic binary signature mismatch.
LLM harnesses build executables and run them. That is their primary purpose.
Changing an executable's signature by inserting a single extra printf() is well within that spec.
That's a pretty oddly narrow & specific definition of what LLM harnesses are for & it certainly doesn't match my experience. In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact. Sure many devs might ask it to for convenience of not having to spend 3 seconds typing & running the command themselves but I can't see it ever being explicitly necessary.
I will note you used the term "harness" which - while terms around LLM tooling is still inconsistently defined - in my experience generally pertains to agentic automations: e.g. LLM CI integrations, etc. Rather than interactive local tooling like OpenCode. So maybe you're referring to that (though even then I still can't think of examples)
> In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact.
You should look into "testing". It's when you run the code you just wrote to make sure it works.
For example, in LLM harnesses, it's used to ensure the produced code has the desired properties. It is the key element needed to allow agents to continue to work until they have succeeded.
Anthropic's harness Claude Code:
https://code.claude.com/docs/en/best-practices — "Claude does the work, runs the check, reads the result, and iterates"
https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135a... — "autonomous loops where Claude writes code, runs tests, and iterates continuously"
https://www.anthropic.com/research/long-running-Claude — "Run pytest tests/ -x -q before every commit"
https://platform.claude.com/docs/en/agents-and-tools/tool-us... — "Claude edits a file with one tool and requests the command that runs it"
https://platform.claude.com/docs/en/agents-and-tools/tool-us... — "writes Python with the file operations sub-tool and runs it with a Bash command"
OpenAI's harness Codex:
https://openai.com/index/introducing-codex/ — "can iteratively run tests until it receives a passing result"
https://openai.com/index/introducing-upgrades-to-codex/ — "iterating on its implementation, fixing test failures, and ultimately delivering a successful implementation"
Aider harness:
https://aider.chat/ — "Automatically lint and test your code every time aider makes changes"
https://aider.chat/docs/usage/lint-test.html — "run your test suite after each time the AI edits your code"
Devin harness:
https://cognition.com/blog/introducing-devin — "Devin writes and debugs code to run a computer vision model"
https://cognition.com/blog/introducing-devin-2-2 — "Devin runs through your app and sends back screen recordings"
https://cognition.com/blog — "Devin now builds, runs, and tests natively in Windows VMs"
SWE-bench harness:
https://www.vals.ai/benchmarks/swebench — "running unit tests against the generated patch"
Copilot:
https://github.blog/changelog/2025-05-19-github-copilot-codi... — "makes changes, and even validates its work with your tests and linter"
https://docs.github.com/copilot/concepts/agents/coding-agent... — "how to build, test and validate its changes"
https://docs.github.com/copilot/how-tos/agents/copilot-codin... — "If Copilot is able to build, test and validate its changes"
https://github.blog/ai-and-ml/github-copilot/github-copilot-... — "coding agent can independently write, run, and test code"
The executables built by LLMs should only given access to a restricted test environment by default.
I mean, ideally enforce W ^ X, and enforce stricter permissions on executables where the agent has flipped the W to X. My broader point is we should be using operating system primitives instead of regex and wishful thinking.
I don't know what you mean by "enforce W ^ X".
You can't give shell access and then revoke special parts of it. This is not controversial.
All your criticisms apply to all LLM harnesses - and everyone who genuinely cares about these things is using security on top of the harness, because OBVIOUSLY.
Your complaints are misguided.
Here: https://en.wikipedia.org/wiki/W%5EX
This doesn't require cooperation from the shell. If writable paths are non-executable, and executable paths are non-writable, then executing `cp $(which git) my-new-favourite-binary` doesn't grant you permission to run it.
The part which does require cooperation (from outside of the shell, i.e. from the harness) is the ability to upgrade writable paths to executable, at the cost of writability and whatever other restrictions you place on the binaries generated by your agent.
This kind of W^X invariant is widely deployed in every desktop operating system, and the type of W-X upgrade hook I described is used by every JIT engine.
Replying inline because this hit max depth:
> You are confusing CPU-level security with filesystem-level security.
> I'm curious - how do you expect an LLM harness to build and test executables without being able to build and execute executables?
W^X applies to file systems as well as page tables, and this is called out in paragraph 4 of the Wikipedia article you didn't read. Respectfully, I'm leaving this conversation at this point because it doesn't seem productive.
You did not hit max depth - you hit a timer designed to prevent rage posting.
My question stands - if you accept that LLM harnesses are designed to allow the building and testing of executables - how do you imagine you can prevent the building and running of executables?
Respectfully.
You are confusing CPU-level security with filesystem-level security.
I'm curious - how do you expect an LLM harness to build and test executables without being able to build and execute executables?
This is very doable - it's a shell you're creating within the cli so you have a lot of control over the environment. If you look at tools like sandbox-exec & apparmor, they specifically target binaries, not string input. E.g. if I write a bash script & put it in my path, OpenCode's allowlists aren't looking at the commands my bash script is exec-ing, nor monitoring subshells it creates. A proper sandbox has full context of the execution chain. Not only that, it's potentially much more powerful & expressive in that you can allowlist indirect filesystem access from commands run.
For example, I recently ran opencode via sandbox-exec & naively granted the sandbox access to the aws cli. First attempt to exec it failed because I hadn't granted the sandbox access to the credential file in ~/.aws. This took 2 seconds to resolve but effectively highlights how utterly useless the tree-sitter string-parsing they're doing is. It's so concerning because implementing tree-sitter for that is non-trivial to the point that any competent dev should surely realise quickly while implementing it that this avenue is utterly useless. Yet every high-profile agent cli has taken this approach.
Yes, I am aware that sandboxing technology exists. I use them. I don't expect them to be built into my LLM harness because I value modular software composition - and sandboxing should be provided by a product that specializes in that area.
OpenCode's allowlists are not there for security. They exist for LLM behavior guidance.
> allowlists are not there for security
I don't honestly believe that the allowlist isn't (naively) intended to be there for security. It's certainly not a very useful ux for providing LLM guidance: prompts, memories & AGENTS.md already provide an avenue for this & having it in a formalised, structured format isn't conducive to LLM guidance. The implementation brings in a lot of dependencies (tree-sitter) & contains enough complex targeted string parsing that's definitely superfluous for something intended to be fed to an LLM as guidance. Perhaps most importantly - the LLM behaviour on encountering limits of the allowlist is neither intuitive nor consistent enough to be considered reliably guiding (& system prompt doesn't do anything to mitigate this).
> I don't expect them to be built into my LLM harness because I value modular software composition
I value software modularity, in particular where software architecture is concerned, but I wouldn't go as far as being prescriptive about the unix philosophy. Direct integration does have its pros, & most of the cons associated with it in practice are specific to bad architecture (or black box software). For example Claude cli does integrate sandbox-exec internally, but it does do in a closed-source inaccessible way that negates its value. I am confident it can be done well though, even if I'm somewhat less confident that it ever will be.
Well - pretty much everyone knows it's lousy security, because you know, it's pretty obvious.
But maybe some people think it's not obvious, and point it out because they think they're clever?
I suppose that's possible.
> 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.
"There will be no curiosity, no enjoyment of the process of life. All competing pleasures will be destroyed. But always— do not forget this, Winston— always there will be the intoxication of power, constantly increasing and constantly growing subtler. Always, at every moment, there will be the thrill of victory, the sensation of trampling on an enemy who is helpless. If you want a picture of the future, imagine a boot stamping on a human face— forever."
George Orwell, 1984
That would be an example of a non-torturted metaphor. When you copy the famous quote verbatim and then substitute both parts of it for things that are almost entirely unrelated, it becomes tortured.
Is that right though? I feel like "tortured" is usually used more when one term is overly specific/over-fitted to the other. I've never heard it used like this, where it's about its provenance?
Not that anyone really cares here, but the gp quote isn't even really fundamentally a metaphor either way, its an exhortation to "imagine". The Orwell isn't even a metaphor!
If you don't know what OpenCode is, imagine a dark and stormy night.
Referring to the top comment on yesterday's submission for Terranc McKenna psychadelic bad trip. https://news.ycombinator.com/item?id=48968515
perhaps if the boot were Rust it would crumble in the face of Bare Metal
As tortured as you will feel after using OpenCode!
This prose feels extremely angry and ungenerous; abstractly, I agree with a lot of the points, but when I read this:
> My conclusion is that OpenCode is clown-car turboslop with a security posture of “let me bend over for you daddy”. Everyone using it should stop using it.
I do not want to keep reading. There are regular people who wrote this software. When did it become normal to talk about open source like this? How would you feel if someone wrote this about some software that you wrote? Reading this article made me feel extremely gross
I agree with your sentiment, but to answer your question: Since forever. (At least I know examples in the 90's).
In the old days of comp.lang.lisp, there were certain individuals who would really get off on denigrating people who wrote code that was not up to their ivory tower level. Some people left because of it. Others took it as a badge of honor falsely believing that the dressing down was necessary for them to improve their coding skills.
Example of an old discussion on HN about it:
https://news.ycombinator.com/item?id=587045
Calling something "vibe-coded" nowadays is a permission slip to unload on it with hyperbole and insults because you can presume there's no human in the line of fire. I really don't think the people engaging in that kind of rhetoric understand how corrosive it is to the humans who do get caught in the crossfire sometimes, and to themselves for normalizing that kind of behavior.
And even so, when something is truly vibecoded it doesn't mean the vibecoder has not put a lot of love and attention into building the product.
I found this part funny.
> People familiar with OpenCode internals (if you are on the OpenCode dev team I assume this doesn’t include you) might have objected to my python3 example above.
It's funny though. I haven't contributed to OpenCode but if I had I'd still laugh because I have a sense of humor. Don't take everything so seriously.
I promise I'm not normally uptight like this, but there's a difference between having a laugh and whatever this is. Like I said, this feels (a) legitimately angry and (b) in a spit flecked enraged way that has become popular. I guess if you're cool with people calling whatever you work on clown-car turboslop then more power to you.
Author here. Just wanted to say: thank you for posting this. You've given me something to think about, and I regret writing this post the way that I did.
please don't regret writing the post the way you did, I for one enjoy well-written rants
> When did it become normal to talk about open source like this?
It's not normal today, but it's also not new, that kind of language has been around for a long time.
> When did it become normal to talk about open source like this?
Why does something being open source absolve it of any sins?
I mean, unless you think AI is conscious and would feel hurt by this, who exactly is harmed here? The prompters? Why? They obviously know the code generated by AI is slop, why would they be hurt by these comments?
I use CC at a client because that's their stack. I use (a particular version of) OpenCode for my own work, because it is so much better. Reading this post makes me sad.
Because everything matches and explains oddities I've seen and forgiven. So despite the hyperbole and the places where the authors' general sentiment are not mine, he's basically right, and I need to find a different harness.
If the post resonates for you too and you've found something better, happy for recommendations. pi seems to get the most mentions here, anyone feel it (or another option) is specifically better on these architectural aspects?
Regardless of its flaws, OpenCode is the harness I’ve been the most productive with by far, and I’ve tried them all.
These are all just some minor annoyances, some disagreements, and most importantly, a fundamental misunderstanding of the point of command filtering. It is not for security, it’s for steering.
Anyway, it didn’t sound like the author tried building anything with OpenCode, and if they did, they said nothing about the most important part: how well did it do?
>Regardless of its flaws, OpenCode is the harness I’ve been the most productive with by far, and I’ve tried them all.
I feel the same way. It's the right amount of 'gets out of my way' and 'won't nuke my machine'.
Especially the ease of using Plan mode and quickly getting stuff done.
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
OpenCode requested to be removed from OpenRouter rankings: https://github.com/anomalyco/opencode/issues/11926#issuecomm...
Why is stated:
> a lot of apps run 100% of traffic through openrouter while for us it's a small subset
> but companies we were trying to work with used openrouter as a source of truth on popularity so they thought products that were much smaller were bigger than us
> 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.
That's not because OpenCode is bad, but because Pi is good. I can say the same about Claude vs pi.
How you deal with LSP? One of the best things in OpenCode is LSP integration.
> How you deal with LSP? One of the best things in OpenCode is LSP integration.
I would love to learn how LSP helps you. I did various basic evals with LSP and I did not find it to improve the agent performance at all. Maybe on newer models this gets better because they are now RLing with LSP in the context, but at least in the past having a commit hook that runs lints and typecheck at the end, is more token efficient than having every edit be injected extra LSP results. You are almost guaranteed to be wasting tokens since partial edits are unlikely going to result in type checks passing.
(Disclaimer: I work on Pi)
lsp integration isn't for checks like that.
It's for using lsp to do things like symbol renames. It's cheaper to call an LSP server to do those kind of simple refactors than to spend tokens on the model doing it.
It can also use LSP to build context without having to grep around a ton. You don't have to grep and hten pull lines and make guesses for a function. You just ask the LSP for it.
How helpful all that is is heavily dependent on the quality of the language server so usefulness is varies wildly between languages
> It's for using lsp to do things like symbol renames. It's cheaper to call an LSP server to do those kind of simple refactors than to spend tokens on the model doing it.
Is OpenCode pushing the LLM into doing these refactors via LSP? I found that making these refactors with ast-grep is quite efficient.
> It can also use LSP to build context without having to grep around a ton. You don't have to grep and hten pull lines and make guesses for a function. You just ask the LSP for it.
I guess I was not particularly successful with having the agent actually do that. I think what fff is attempting to do (with fuzzy expansion of slightly inaccurate greps) results in better results to me, but even that is debatable.
To be fair, we do not have evals for this today, but we're generally looking into token efficiency and how likely models are at using tools the right way, and we did not find a ton of evidence of LSP helping, even for finding data.
But I would love to see some sessions from people where they have success with LSP data for either refactoring or looking up, because this would be super useful to better understand out blind spots.
To be fair in every harness I've ever used that has LSP support, they never actually utilize the LSP for more deterministic refactoring tools. And even then when I do enable the LSP in many harnesses oftentimes it doesn't even use it at all.
Maybe they haven't been taught to do so or it's not integrated into the system prompt or the tools but all of them only ever use the LSP to read files/symbols.
Every harness I've used will happily just call the edit tool over and over or do a find and replace via sed or programatically call a python/perl script rather than rename a symbol via other means.
LSP helps massively with some models.
It sounds a lot like you are focused on using Pi as a OpenAI/Anthropic wrapper when that isn’t your audience. (Hint: raw token usage is less of a concern).
Oh My Pi has it. I'm a big OMP shill right now. Seems not very popular, but it has the stability of Pi with the features Opencode (and more I think; OMP has web browsing and a more advanced edit system too). OMP often outperforms Claude Code and Codex for me.
I haven't tried it myself but there seems to be an extension for this: https://pi.dev/packages/pi-lsp
I disliked OpenCode's LSP integration, as Pyright kept distracting the model from what I wanted done in a Django project. I prefer to run MyPy at my own convenience
I use a forked version of the pi-lsp. It works pretty well out of the box, but I just tend to fork extensions by default and then hack them up how i see fit.
I tried opencode and pi recently.
Having come from Claude code, I was a bit shocked that both seem to allow edits by default with no confirmation dialog.
One IIRC allows you to enable it in config and the other needs a plugin.
> Having come from Claude code, I was a bit shocked that both seem to allow edits by default with no confirmation dialog.
There are confirmation dialogs in OpenCode. You can configure them using the permission config, same as Claude Code. Having said that, as a general rule, none of these harnesses are safe to run on your local file system.
Which is why he said "by default".
There are confirmation dialogs by default, though.
I wonder if that's a recent change. When I first started using OpenCode, it didn't ask permissions. I had to manually go and set that config to get it to ask.
There may be differences based on whether the command is under the directory you're running OpenCode from vs some other directory...
Yeah. I installed OpenCode in a container about a month ago, and I had a hell of a time figuring out how to get it into complete yolo mode.
I purged OpenCode when I noticed it downloads npm packages in the background without asking the users first. This exposes higher risk of supply chain attach risk.
Kilo is the top 3 option there, and that's a fork of OpenCode.
yeah I noticed it missing on the openrouter leaderboard -- very interested to know what that's about
probably about their own model routing service zen?
I can imagine the builtin router stealing traffic, but not removing opencode from the ranking completely?
Like the 'top apps' in my private openrouter.ai activity usage is opencode with 55.1M tokens
The bottom of the public apps leaderboard is 'kern agent' with 150 million tokens
if there are 2 other people like me, opencode should be on here somewhere
(edit: user shiggity points out https://github.com/anomalyco/opencode/issues/11926#issuecomm..., they asked to be removed from the ranking)
I find it absurd that a TUI desktop app is heavier than a native one AND heavier than most browser based desktop apps, it's so much waste of RAM, CPU, energy/battery just to show text.
I've been working on my own AI harness/chat in C++ Qt6[1] and it's lighter than anything else even with lots of features like sub-agents, code diff, terminal emulator, simple editor, markdown preview, translucent background, custom themes, permissions, MCP, git integration(commits, stage, diffs), dock system to move elements and tabs for projects; but it's not released yet as I want to polish it a bit, remove a few bugs I found and simplify the UI.
[1]: https://zeteo.krysoph.com/preview.html
The other day I upgraded my pi.dev coding harness and was testing with Qwen 3.6 35B-A3B model on my Laptop and noticed there was a slight drop in performance from the earlier version I used though the agent worked as expected. Any slight changes in the system prompts will have impact on performance and this is understandable as LLMs are non deterministic. This is the case with any harness including OpenCode. Giving coding harness its own environment (Container/VM) is the best way forward as the article denounces. Running coding agent harness without sufficient guardrails is like sitting on a time bomb. Using AI slop guardrails is still better than having no guardrails.
Including the date in the system prompt - at the cost of a cache invalidation at midnight - is an entirely reasonable decision. Most other harnesses do the same thing.
Including the full datetime would be irresponsible, but that's not what OpenCode does.
It felt unreasonable when I was using it at midnight and had to wait 10 minutes to refill the KV cache on my local GPU :-)
A simple solution here would be to evaluate the date once per session, or once each time the `opencode` binary is launched (to avoid old, long-running sessions getting stuck in the past).
Or they could add the frozen initial starting date once at the start, then inject an additional "the date is now X" message any time midnight passes.
But then someone would write an article complaining about how the newly-injected date confused their agent!
I was confused about how this was written in the article. Sure, include system time, or a simple get current time tool, whatever, it’s inconsequential for the most part, but who is out here changing datetimes in a conversation and invalidating prefixes?
If you need to, just prefix user messages with the current datetime.
Why is this even a complaint?
I suspect that if you prefixed every user message with a date the model might get confused and start treating the date as more relevant to the current task than it actually is.
not too much actionable here. most of the more glaring issues are already fixed in our upcoming v2 if you'd like to try beta: https://x.com/thdxr/status/2075636594640376165
some things mention are outdated - particularly the tool call pruning feature. this has been disabled by default for a while specifically because of complaints like this
when we looked through our data it's not so clear cut that it's net negative https://x.com/thdxr/status/2048268697790300343
also i'm pretty excited about our new system prompt approach - can define each component in a way that avoids busting the cache when they change. eg that midnight issue: https://x.com/thdxr/status/2070721003924103651
providers (anthropic is the first) are supporting this as a native concept
Are there sandboxes you typically use?
I think the biggest concern from the article would be the open http server, and things like the fetched arbitrary command execution here: https://github.com/anomalyco/opencode/issues/22191
Was that issue addressed? The comment where it was marked as closed suggested it "needed more testing" but didn't have any linked PRs.
Gemini translates the closing comment as "We are closing this ticket after a quick look. The login issue is either caused by a wrong setting/external provider, or it's a deeper problem that requires someone to dig into the backend Go server code directly."
> 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.
GAH!!! So that's why its been deleting comments. That is annoying as hell.
FWIW though, I think this applies to other harnesses also (not the annoying bits, but the security risks). I was thinking this morning about how much of a supply-chain vulnerability these tools are. Like, basically, they have a ton of data, they're updated practically daily, and given their vibe coded nature I really doubt anyone is auditing the 10,000 NPM dependencies they drag in. It really will just take one left-pad incident for this to be an absolute disaster.
> Textual command filtering is entirely useless. It is fit for no purpose. Nobody with any instinct or experience in security would even bother to implement this filter because it achieves nothing except a false sense of security.
Not if you only use an allow list. E.g. only allow things matching a particular prefix to run. Also, isn't this what every agent does? And by every I mean Codex because I haven't used the others.
Good to see Codex as a datapoint: I haven't used it. I can confirm though that this is certainly what Claude does, with the addition that Claude's adherence to its own string-match based allowlist seems even less deterministic than OpenCode's.
I haven't independently verified all the claims in the article, but as a codex, Claude, and opencode user, opencode is easily my favorite harness. From a user perspective it's a dream
I tried it when trying to move away from Claude, and just did not like how it worked... I find Pi much better to work with!
A more accurate title would be "The Problem with AI Agent Harnesses, and small annoyances with OpenCode specifically"
Possibly the author didn't dig this deep into all AI Agent Harnesses, just Open Code?
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.
I agree generally but I'd moderate this to say this is an "anti- the current state of AI" post insofar as none of the issues listed are inherent to LLMs, they just seem to be ubiquitous in the current generation of agentic CLIs. I'm not aware of any CLI that doesn't have the listed severe issues, but I could certainly write a CLI myself (if I had the time & energy) that avoided these issues.
Maybe https://github.com/tontinton/maki
> - Sensible permission system - when the agent runs git diff && rm -rf /, what do you think will happen in your current coding agent? It will treat it as git *. Maki uses tree-sitter to parse the bash command and figure out the permissions requested are git * and rm *. Disable using --yolo.
This sounds identical to what OpenCode does (&, contrary to their own marketing, does not seem sensible at all).
The fact that this mechanism is so primitive across all agentic clis is frankly a serious indictment of the competence & experience behind LLM-focused development teams.
This is a security issue that has in the past been solved via explicit file-path-based allowlisting, & more recently - due to file-path matching being deemed insufficiently secure - apps have been switching to cryptographically signed binary matching as a more modern alternative to the less secure path matching. In that context, the fact these recently-written "modern" agentic clis are using a method that's more basic & even less secure than the "old insecure" method most apps use is pretty shocking.
Elsewhere in the thread someone linked to https://pleasedonotescape.com/ which is a list of sandboxes
Maybe sandboxing isn't the job for an agent harness?
Maybe choosing a VM as your sandbox, with access only to project directory.. and then enabling YOLO mode on the agent, is the way to go.
And in any case, for an agent that can write and run code, no allowlist for which programs are allowed to run is sufficient, since the agent can just write the code the program would run anyway. And the issue isn't which software the agent runs, but whether they inherit the same ambient authority as your user - read the same files as you do, modify your config files, etc. Running in a VM stops that.
Clawk (recently submitted to HN here https://news.ycombinator.com/item?id=48892859) might be good
I've run agentic CLIs in a sandbox (using MacOS sandbox-exec) & in VMs - both solutions have an inherent advantage over any integrated sandboxing by virtue of their independence (even before we get into configurability). Claude CLI integrates sandbox-exec internally, but I can't really trust it completely because Anthropic don't really have any vested interest in restricting their own tooling on my machine - they want me to rely on the tooling more, not less, which naturally entails granting the tool broader access: this is reflected in two ways in their sandbox-exec implementation: (1) it's wrapped in a relatively lax default profile & (2) not everything the cli does is sandbox-wrapped.
All that said, I don't think I'd agree that sandboxing doesn't belong in the agent harness. Ultimately, I want to be using an open source cli tool that doesn't come with the above Anthropic perverse incentives. The advantage of using a separate sandbox solution with Claude CLI isn't that it's separate, it's that I control it. Ideally I should control my agentic cli though, & in that context, bundling the sandbox comes with a lot of inherent advantages.
Unfortunately, as far as I've seen, the current batch of open source clis are pretty poor at the above, leaving little incentive to switch from proprietary solutions.
I really, really wanted to make agent sandboxes work. Filed issues on the sandbox created by Anthropic and later also adopted by Copilot, and also to Codex repository. I think none of them is actually usable - they either allow too much or too little.
There is one case where VMs are not fit, and it's when you need to do GPU work. Well unless you have gpu passthrough or virtual gpus.
I've used VMs because dealing with tool access is infinitely simpler & less fraught than tailoring sandbox profiles, but ultimately using sandbox-exec has yielded better workflows (if & when I've gotten an appropriate profile stood up). The sandbox tends to have a lot more rough edges than the VM, so I do switch back & forth between VM & sandbox, but I suspect a good sandbox-wrapping implementation with nice ux is the future.
Perhaps one could go further & combine them: e.g. a sanbox-wrapped on-host CLI that subshells/subagents out to VMs on demand. Seems potentially overcomplicated but I guess one can dream.
> The fact that this mechanism is so primitive across all agentic clis is frankly a serious indictment of the competence & experience behind LLM-focused development teams.
Not at all. The proper solution to this problem is running in a sandbox - which is not reinvented by the LLM harness because there are already many great options.
You misunderstand the mechanism. It is not intended to provide security. It is intended to guide LLM behavior.
OpenCode is pretty awesome. The article appears written by someone who couldn’t handle a glance behind the curtain and definitely should not research how sausages are made.
> 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.
Gonzo style / polemic would make a good filter on here.
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.
I am afraid this is a very click-baity title. I actually opened the article and thought I would learn something from it.
Instead what I read was typical issues about Agentic CLI's in general dubbed as `alarming`. I would have been happy if the title was just `Annoying` which a lot of `OpenCode` is. But adding the `alarming` made it what it became, something that attracts enough eyeballs to get to the front page of HN.
Heavy disagree. I can't be sure about other AI coding agents as I haven't used others enough, but especially the items around prompt cache misses and compaction have hit me personally.
This article (combined with another article previously comparing CC and OC's system prompt, to which someone replied pi.dev sends even less) has made me want to switch agents, so I'm likely going to try out pi.dev and aim to migrate.
I don't know whether other arguments are true, but some arguments in the end are right:
> Using LLMs for code generation feels like a dead end. ..., This is hostile to your ability to understand your code, beyond the fact that you didn’t write it.
What you get from AI is not worth of what you have invested for it in long period.
> Drawing answers directly from knowledge in model weights leads to hallucination even for multi-trillion-parameter models, so why bother making them that big?
Current AI is like the film company producing TV series or movies. "If similar stories do not exist or details are missing, screenwriters use imagination to fill in the gaps (remember hallucination? It's just a makeup.)", refer to the article https://devcyc.life/current-ai-is-like-the-film-company-prod...
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.
The solution is not to use docker to sandbox Opencode. It is to use flatpak/bubblewrap/flatseal.
I have vscode running in flatpak with directory permissions handled by flatseal. Vscode only has access to my dev folders and nothing else. Even the git bundled by vscode cannot call git push because of this (vscode doesn't have permission to read ~/.ssh!).
It's an easy sandbox that's provided free of charge courtesy of bubblewrap/flatpak.
As someone who uses opencode regularly, the quip about it asking for permission to read logs in /tmp after already writing to the directory is pretty funny.
I’m running my development from a Mac which I think precludes flatpack usage. Pity because I love the control you have over git
When using local only models, OpenCode uploaded prompts and other data, to remote server to generate session titles, with some free tier model.
Useless, if you are dealing with privacy compliance and tons of legal requirements.
When i use local models with OpenCode, ClaudeCode or Pi, I just switch off internet just in case, and it works ok, no complains.
Lost me at the very first sentence.
> If you don’t know what OpenCode is, imagine a boot stamping on a human face forever.
Re local LLMs: “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.”
Making the authors stance on LLMs clear.
It's a tool. Use it like a tool. It's not a substitute brain.
Clarity is a hallmark of good writing.
Admittedly I prefer Hermes and oh-my-pi, but most of this post is just hyperbole
Thanks for that, I've been using it but some of these are bad. Specially that it sends data to the cloud by default for session titles, since I use my local model exclusively. So I'm done with it, trying maki now which seems promising and it's so much lighter.
Related post of mine: https://news.ycombinator.com/item?id=48946283
For some reason OpenCode doesn't find my local models through LM Studio. Instead it shows three other models that I don't have. I guess I should add the models myself in opencode.json, but I generally dislike hardcoding things when computers are really good at listing things. The model list is right there in the API, please just use it.
Interesting article. What are the alternatives that address the issues raised? I see some folk recommending https://pi.dev/. Has anyone used https://aider.chat/ and liked it?
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.
Wrong adam. The adam who cofounded chef has nothing to do with opencode
This could be a series of issues on the opencode repo
Currently 3690 open issues.
https://github.com/anomalyco/opencode/issues
yes, and they could all be closed by the stale bot
There are a ton of super serious issues there. They are not getting fixed.
60 days ago there were 73 pages of open issues. Now there are over 150 pages.
Nobody is reading the issues; nobody is accepting PRs.
I am interested - you mention Pi in a few places, and I am wondering how it mitigates the issues you've described in your article.
> My opinion on local LLMs [...] :
>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.
This seems to be capturing a feeling I am finding messing with local LLMs: popular software around this seems to be slop coded by no talent hacks. It's a common experience to see a python process pegged at 100% CPU with a huge amount of memory allocated, seemingly doing something that could be a simple shell script. That is before stuff reaches the LLM.
If that runs on somebody else's machine, you don't notice. When you see it in top it's frustrating.
I really hope truly open models and local inference are the future.
But are there are any reasons a pragmatic and informed developer would use OpenCode vs Claude/Codex as a harness today?
I'm not seeing anything competitive in terms of cost/quality/trust?
I have an MBP M4 Max 128 GB and have encountered these very limitations, though many are averted by using Qwen3.6-35B-A3B. I'm also not sure there's a magical harness out there that obviates these limitations.
Finally good seeing someone else also getting frustrated with OpenCode and posting the issues.
It's not a great UI, but for messing with ideas in a VM, the free tier is very hard to beat, otherwise I'd be on Claude Code, but still on a VM, because I won't let them near anything I actually care about.
This is why I use the reasonix or whale harness for Deepseek, prefer the hyper optimized cache hits making request converge on almost free.
There are a number of points I completely agree with in this blog post. Security implications, handing out all your data to anthropic/openai/google, allowing a slop machine to execute arbitrary code on your machine and having full access to your network is something that would have made anyone working in security commit a ritual suicide just thinking about it as recent as 2022-2023. And I am baffled by the fact that we all sign tons of NDA's as part of our employment contracts, just to throw all out the window by giving it all away to anthropic/openai/google etc, at what is effectively a symbolic fee. We all know it costs a lot more than 100 bucks a month or whatever it is they charge.
That said, I firmly believe that if AI is to survive, the future HAS TO BE local or near-local. Having said that, statements such as
> Docker causes security holes:
> It creates a god-service that runs as root.
> It deliberately punches a hole in ufw firewalls.
Sorry, none of those are correct IF you know what you are doing. Though I will admit, seeing people that know what they are doing is increasingly uncommon.
Also there is nothing wrong with developing inside containers. If anything, that is arguably one of the biggest selling points for containers - environment(s) you can crash infinitely at no cost.
I still dislike opencode for a bunch of reasons - the assumption that llms are immune to screw ups, being one. As for the default behavior - using cloud by default - I didn't know that(I do not use any AI for direct coding tasks) and if that is the case, yeah, this is bad. Undeniably a horrible decision.
Yeah, this is one of the weaker parts of the post because I didn't really make my position clear: that sandboxing should be a first-class integral part of every harness, not an afterthought that risks putting something you care about on the same side of the trust boundary as the LLM.
Some of my own frustrations with bad Docker deployments leaked through. I did snip some of them out way back when I posted this, but maybe not enough.
> that sandboxing should be a first-class integral part of every harness,
Essentially, what you want is that the people who produce harnesses like OpenCode to also implement proper sandboxing and security. Why... why do you believe they'll do anything remotely satisfactory?
It's been empirically demonstrated, again and again, that at least 85% of software developers (and this is a very generous estimation) can not be trusted to bother about the security, so leaving the implementation of the security mechanisms and policies up to them simply doesn't work in practice. It just doesn't.
Any recommendations for non-typescript-based coding TUI harnesses/agents other than Codex? Given that Codex is open source someone should've built an untethered client?
2 of the most promising Rust ones
https://github.com/1jehuang/jcode https://github.com/gi-dellav/zerostack
I just did the obvious thing and asked an AI to plan / consider and implement improvements / changes in the code based on the article.
No mistakes
On the upside, Opencode has finally nudged me to learn sandboxing via bwrap in Linux and sandbox-exec on Mac.
posted just as I start to use OpenCode haha
Pi, especially bundled as OhMyPi, performs significantly better than anything else.
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.
unless someone fixes the issues with LLMs at a fundamental level those will all have the same kinds of issues as is described with OpenCode and they will all be horrendous.
> "I just don’t want to use Docker for development – if your dependencies are so sprawling that you’ve lost track of how to install them on a new machine, why do you have so many?"
I mean, there's a perfectly good solution for many of the security issues mentioned in the article... But it is dismissed because the author just doesn't "want to"?
By the way, LXC is probably better suited for reproducible build/development environments, over Docker.
There are definitely annoyances with OpenCode.
The remote-preferred attitude caught me once. Also, its server APIs don't match its docs, if you want to talk to it programatically.
The following config works for me to keep it on a local model:
{ "$schema": "https://opencode.ai/config.json", "provider": { "local-llama": { "npm": "@ai-sdk/openai-compatible", "name": "Local llama.cpp Server", "options": { "baseURL": "http://localhost:8080/v1" }, "models": { "Chefs Choice": { "name": "ANY" } } }, ...
This allows me to put any model I want on port 8080.
This is a time when I don’t want HN to rewrite an article’s title.
I understand why the mods do it, but I don’t appreciate it. It’s your space, but it’s not your article.
Use Picode as an alternative to Opencode
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.
> > 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.
Alternatives exist
I have moved to kilo code for now
that... is an opencode fork
Opencode's cache hit rate is better than claude code. Opencode has in my experience been better than any of the closed source / closed development alternatives and is not locked down.
https://news.ycombinator.com/item?id=48883275
Have you tried Pi though? I was a big Opencode user but once I started using Pi I never looked back
> 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.
Um. Which then gets immediately cached again.
I prefer this behavior. I prefer my changes incorporated immediately, rather than wait for the next session. Call me crazy.
(Author is unhinged and this story is upvoted because #AI-HATE.)
I also would want anything that I saved into AGENTS.md to be incorporated right after I saved it.
I might accept if my newly saved information was overlooked, but it's hard for me to fathom how I'd demand "I want to save this information in AGENTS.md now, but I don't want you to look at it until the next time I launch you..." and call any behavior other than that annoying or alarming.
Also, aren't instructions earlier in the prompt treated with more weight than those that occur much later? Sure, you could insert the system prompt later to avoid re-caching as much, but then the system prompt (if I am understanding correctly) carries MUCH less weight.
(And also your point about immediately being re-cached a good one)
Yes, exactly. This whole complaint boils down to "I don't want my changes to take effect when I make them because I don't expect that behavior."
It’s a shame they have such a dominant position in terms of harnesses. There are many much better alternatives that deserve attention. Especially since one of their main devs is such an asshole online.
OpenCode is indeed bad, but it's the least bad agent out there :(
Plugin opencode-slim-system can be used to override the system prompt and the tool description for any tool (including bash). It helps a lot to fix their nonsense.
magic-context plugin fixes the compaction issues.
Run the entire process in landstrip for sandboxing to alleviate any bash concerns.
I'm glad that when I recommended opencode to a friend, I taught them first to install a vm and create an app specific user to boot.
Many users did things right the first couple of days and then turned the security off after seeing it 'work fine' on its own.
Was a cool thing to use for a couple of weeks in v1, you have to be quite static to keep using it at v68 of self vibecoding while the llm providers like openai already developed their in house alternative.
Weird this is currently #1 on the front page.
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
`greywall -- opencode`
Yeah, I don't think that line quite landed. My point was that LLMs are inherently adversarial (read, "relentlessly proactive") and sandboxing should be a first-class integral feature of your harness, not an afterthought. The problem with dev containers is you still tend to end up with something you care about on the same side of the trust boundary as the LLM.
> LLMs are inherently adversarial (read, "relentlessly proactive") [and] you still tend to end up with something you care about on the same side of the trust boundary as the LLM
I mean this is a problem with many coworkers too, so you deal with it in the same way: limit what they can do to creating pull requests.
I was taking this semi-seriously until I read his CLI complaints.
Author is unhinged.
With posts like this there's usually priors involved, it's crazy vitriolic.
Cache misses are the one reason I stopped using OpenCode in favor of Pi. OpenCode mutates the system prompt every turn, which is completely unacceptable and betrays such a basic misunderstanding of LLMs that I can't in good conscience trust the rest of the product regardless of how technically impressive it is.
I've had the same experience. Tried it and use in 2 hours more token than in a whole week. Normally i got 80 - 90 % cache hit rate.
If OpenCode is so terrible it wouldn't be the base for many of the fortune 500's internal cli coding agents, Meta included
I'm not sure that I buy into the premise that everything Meta does is OK
> If OpenCode is so terrible it wouldn't be the base
Ignoring the appeal to authority inherent to this kind of statement, it's ignoring another implication. Large companies can afford to maintain a fork. Using the latest release of OpenCode day to day is a different proposition than serving as some corporate developmental branch "base", as shorthand for all sorts of changes/usage.
Well, out of the agentic harnesses available, OpenCode is the most promising and capable whilst still remaining open; proprietary alternatives like Claude Code have all these problems and more. So I guess the only way out is to just not use LLMs for development at all.
...
[chadjak.png] Your terms are acceptable.
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.
There are other OSS agent harnesses.
That offer free inference?
I've written my own. I know they exist.
I don't offer free inference on large models however
OpenCode Zen works with Pi, etc. It's totally separate from the OpenCode harness that this article is about.
As I said in other reply there's Mimo. But I would check the opencode Go plan. First month for 5 usd and renewal at 10. (With referral offers too). If you use only deepseek flash it would take you a long way every month.
On the Opencode client it's literally 0. I haven't even signed up for an account. It's my daily driver. 0 is a powerful number
Again if I can get this somewhere else then I'm game.
Yes I understood your other comment. I used free models for a long time. Less than 6 months ago there were a ton of options but the current free choices are very limited in number and usability. They run out way too quickly and some of them have smaller context sizes than paid offerings. As far as I know the only currently really free offering is Mimo via their own CLI.
You could easily just use Pi or even a Codex fork to avoid Opencode as a harness and still pay zero dollars.
Can't get those generous free quotas from opencode with that.
hmm you can.
https://opencode.ai/zen/v1/models
https://opencode.ai/zen/go/v1/models
Go is not free at all (you can't use any of the models you listed without a subscription) and the free Zen models will not be on other CLIs as far as I know.
That's just a models endpoint. They'll just let you use them unauthenticated with any client you wish?
I'll go check that but this would be fairly shocking
I checked. Shocked. Here's the models they allow that with
nemotron-3-ultra-free big-pickle north-mini-code-free mimo-v2.5-free deepseek-v4-flash-free hy3-free
Alright.
Currently only Mimo has a usable free offer with their own CLI. (opencode clone)
pi.dev
The mix of humanizing the LLM, calling it "clanker" and being very aggressive towards it is really weird. I don't think it's a good habit to take, it feels like it could bleed into how you interact with people. Many interactions are through text interfaces these days.
The mouth speaks what is in the heart. What is inside eventually leaks out. In anonymized spaces, this is especially true, and has been acknowledged from the beginnings of the internet (and perhaps long before). When you don a mask, your heart speaks freely.
But the knife cuts both ways. As you speak, so will your heart be. I think modern psychology supports this. Actions drive attitude, and attitude drives actions. If you assert your will in either place, the other is disrupted and will adjust.
You can literally change yourself into whoever you want to be. But a passive participant in this process will simply show the world what kind of person they are without ever realizing it.
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.
That's not how it works. While there are some research papers looking into using chunks of kv cache while discarding others, those involve architecture changes in the models themselves. HiCache / LMcache (used in sglang/vllm) are ways of optimising the juggling of kv cache, but IIUC it still needs to be token perfect atm.
Prefix caching is inherent in how global softmax attention works. Modifying the prefix invalidates the suffix because the suffix's cached KV projections are a function of the hidden state after the model has evaluated the prefix.
There have been some attempts to approximately stitch KV blocks without full re-evaluation (see: CacheBlend on arxiv), but the results aren't promising.
You mentioned HiCache: as far as I can tell this is a prefix tree cache that efficiently shares prefixes across related histories. If you change the prefix, everything after the change still misses the cache and needs to be prefilled again.