I don't use it for coding but as an agent backend. Maybe opencode was thought for coding mainly, but for me, it's incredibly good as an agent, especially when paired with skills, a fastapi server, and opencode go(minimax) is just so much intelligence at an incredibly cheap price. Plus, you can talk to it via channels if you use a claw.
I see great potential in this use case, but haven’t found that many documented cases of people doing this.
Do you have resources you can point to / mind sharing your setup? What were the biggest problems / delights doing this?
> and (partly as a result) it's fairly resource inefficient (often uses 1GB of RAM or more. For a TUI). That's (one of the reasons) why I'm favoring Codex over Claude Code. Claude Code is an... Electron app (for a TUI? WTH?) and Codex is Rust. The difference is tangible: the former feels sluggish and does some odd redrawing when the terminal size changes, while the latter definitely feels more snappy to me (leaving a…
Anthropic needs to spend some tokens rewriting Claude Code in Rust (yes, really). The difference in feel between Codex and Claude Code is obvious. The whole thing is vibed anyway, I'm sure they could get it done in a week or two for their quality standards.
I'm currently experimenting with (trying to) fine tune Qwen3.5 to make it better at a given language (Nim in this case); but I am quite bad at this, and honestly am unsure if it's even really fully feasible at the scale I have access to. Certainly been fun so far though, and I have a little Asus GX10 box on the way to experiment some more!
Been playing around with fine-tuning models for specific languages as well (Clojure and Rust mostly), but the persistent problem is high quality data sets, mostly I've been generating my own based on my own repositories and chat sessions, what approach are you taking for gathering the data?
Yeah I have a body of work of 15 years, plus I’ve been building labelled sets from open source (the source code isn’t quite enough on its own)
Now I’m using that to generate synthetic sets and clean it up, but man I’m struggling hah. Fun though.
Why most of those tools are written in js/ts? JS is not something that was developed with CLI in mind and on top of that that language does not lend itself to be good for LLM generation as it has pretty weak validation compared to e.g. Rust, or event C, even python. Not to mention memory usage or performance.
TS is just a boring default. It’s simply one of the most productive languages. It actually has a very strong type system, while still being a dynamic language that doesn’t have to be compiled, leading to very fast iteration. It’s also THE language you use when writing UIs. Execution is actually pretty fast through the runtimes we have available nowadays. The only other interpreted language is Python and that thorough…
I was going to say that pnpm isn't that old but wikipedia says 2017!
OpenCode was the first open source agent I used, and my main workhorse after experimenting briefly with Claude Code and realizing the potential of agentic coding. Due to that, and because it's a popular an open source alternative, I want to be able to recommend it and be enthusiastic about it. The problem for me is that the development practices of the people that are working on it are suboptimal at best; they're con…
> and (partly as a result) it's fairly resource inefficient (often uses 1GB of RAM or more. For a TUI). That's (one of the reasons) why I'm favoring Codex over Claude Code. Claude Code is an... Electron app (for a TUI? WTH?) and Codex is Rust. The difference is tangible: the former feels sluggish and does some odd redrawing when the terminal size changes, while the latter definitely feels more snappy to me (leaving a…
I run many instances of Claude Code simultaneously and have not experienced what you are seeing. It sounds like you have a bias of Rust over Typescript.
By default OpenCode sends all of your prompts to Grok's free tier to come up with chat summaries for the UI. To change that, you need to set a custom "small model" in the settings.
I had to double check this. Here is summary:
The model selection for title generation works as follows (prompt.ts:1956-1960):
1. If the title agent has an explicit model configured — that model is used.
2. Otherwise, it tries Provider.getSmallModel(providerID) — which picks a "small" model from the same provider as the current session, using this priority list (provider.ts:1396-1402):
- claude-haiku-4-5 / claude-haiku-4.5 / 3-5-haiku / 3.5-haiku
- gemini-3-flash / gemini-2.5-flash
- gpt-5-nano
- (Copilot adds gpt-5-mini at the front; opencode provider uses only gpt-5-nano)
3. If no small model is found — it falls back to the same model currently being used for the session.
So by default, title generation uses a cheaper/faster small model from the same provider (e.g., Haiku if on Anthropic, Flash if on Google, nano if on OpenAI), and if none are available, it just uses whatever model the user is chatting with. You can also override this entirely by configuring a model on the title agent.
OpenCode was the first open source agent I used, and my main workhorse after experimenting briefly with Claude Code and realizing the potential of agentic coding. Due to that, and because it's a popular an open source alternative, I want to be able to recommend it and be enthusiastic about it. The problem for me is that the development practices of the people that are working on it are suboptimal at best; they're con…
This is why I'm taking a wait-and-see approach to these tools on HN myself. My month with Claude Code (the TUI, not the GUI) was amazing from an IT POV, just slop-generating niche tools I could quickly implement and audit (not giant-ass projects), but I ain't outsourcing that to another company when Qwen et al are right there for running on my M1 Pro or RTX 3090.
I'm looking forward to more folks building these kinds of tools with a stronger focus on portability via API or loading local models, as means of having a genuinely useful assistant or co-programmer rather than paying some big corp way too much money (and letting them use my data) for roughly the same experience.
This is the way. If you’re not running your agent harness/framework in a container with explicit bind mounts or copy-on-build then you’re doing it wrong. Whenever I see someone complain about filesystem access and sequirity risk it’s a clear signal of incompetence imo.
> container with explicit bind mounts Someone correct me if I'm wrong, but if you're doing bind-mounts, ensure you do read-only, if you're doing bi-directional bind mounts with docker, the agent could (and most likely know how to) create a symlink that allows them to browse outside the bind mount. That's why I explicitly made my tooling do "Create container, copy over $PWD, once agent completes, copy back to $PWD" ra…
> create a symlink that allows them to browse outside the bind mount
Could you reproduce that? iiuc the symlink that the agent creates should follow to the path that's still inside the container.
opencode stands out as one of the few agents with a proper client server architecture that allows something like openchambers great vscode extension so its possible to seamlessly switch between tui, vscode, webapp, desktop app. i think there is hardly a usable alternative for most coding agent usecases (assuming agents from model providers are a no go, they cannot be allowed to own the tools AND the models). But its also far from perfect: the webui is secretly served from their servers instead of locally for no reason. worse the fallback route gets also sent to their servers so any unknown request to opencode api ends up being sent to opencode servers potentially leaking data. the security defaults are horrific, its impossible to use it safely outside a controlled container. it will just serve your whole hard drive via rest endpoint and not constrain to project folders. the share feature uploading your conversations to their servers is also so weirdly communicated and implemented that it leaves a bad taste. I dont think this will become much better until the agent ecosystem is more modular and less monolith, acp, a2a and mcp need to become good enough so tools, prompts, skills, subagent setups and workflow engines and UIs are completely swappable and the agent core has to only focus on the essentials like runtime and glue architecture. i really hope we dont see all of these grow into full agent oses with artificial lock in effects and big effort buy in.