Live data from Hacker News

Annoying and alarming things about OpenCode

wren.wtf

251–260 of 309 posts

Re: Annoying and alarming things about OpenCode

#251

Earlier quoted context omitted.

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).

Re: Annoying and alarming things about OpenCode

#252

Earlier quoted context omitted.

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.

"golang" is literally "Go language". Doesn't matter that it's one word.

Re: Annoying and alarming things about OpenCode

#253

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 s…

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 minimal…

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).

Re: Annoying and alarming things about OpenCode

#254
post #212

Earlier quoted context omitted.

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

Re: Annoying and alarming things about OpenCode

#255

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.

Re: Annoying and alarming things about OpenCode

#256
post #187

Earlier quoted context omitted.

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)

Re: Annoying and alarming things about OpenCode

#257
post #197

Earlier quoted context omitted.

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…

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.

Re: Annoying and alarming things about OpenCode

#258
post #187

Earlier quoted context omitted.

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…

> 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"

Re: Annoying and alarming things about OpenCode

#259
post #62

Earlier quoted context omitted.

hmm you can. https://opencode.ai/zen/v1/models https://opencode.ai/zen/go/v1/models

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.

Post reply on HN