Hacker News

> 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 aside that GPT's responses also seem more concise). At some point, I had both chewing concurrently on the same machine and same project, and Claude Code was using multiple GBs of RAM and 100% CPU whereas Codex was happy with 80 MB and 6%.

Performance _is_ a feature and I'm afraid the amounts of code AI produces without supervision lead to an amount of bloat we haven't seen before...

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

This is my experience with most AI tools that I spend more than a few weeks with. It's happening so often it's making me question my own judgement: "if everything smells of shit, check your own shoes." I left professional software engineering a couple of years ago, and I don't know how much of this is also just me losing touch with the profession, or being an old man moaning about how we used to do it better.

It reminds me of social media: there was a time where social media platforms were defined by their features, Vine was short video, snapchat was disappearing pictures, twitter was short status posts etc. but now they're all bloated messes that try do everything.

The same looks to be happening with AI and agent software. They start off as defined by one features, and then become messes trying to implement the latest AI approach (skills, or tools, or functions, or RAG, or AGENTS.md, or claws etc. etc.)

I am more concerned about their, umm, gallant approach to security. Not only that OpenCode is permissive by default in what it is allowed to do, but that it apparently tries to pull its config from the web (provider-based URL) by default [1]. There is also this open GitHub issue [2], which I find quite concerning (worst case, it's an RCE vulnerability).

[1] https://opencode.ai/docs/config/#precedence-order

[2] https://github.com/anomalyco/opencode/issues/10939

> The problem for me is that the development practices of the people that are working on it are suboptimal at best; they're constantly releasing at an extremely high cadence, where they don't even spend the time to test or fix things (or even build a proper list of changes for each release), and they add, remove, refine, change, fix, and break features constantly at that accelerated pace.

this is what i notice with openclaw as well. there have been releases where they break production features. unfortunately this is what happens when code becomes a commidity, everyone thinks that shipping fast is the moat but at the expense of suboptimality since they know a fix can be implemented quickly on the next release.

I recently listened to this episode from the Claude Code creator (here is the video version: https://www.youtube.com/watch?v=PQU9o_5rHC4) and it sounded like their development process was somewhat similar - he said something like their entire codebase has 100% churn every 6 months. But I would assume they have a more professional software delivery process.

I would (incorrectly) assume that a product like this would be heavily tested via AI - why not? AI should be writing all the code, so why would the humans not invest in and require extreme levels of testing since AI is really good at that?

OpenCode's creator acknowledged that the ease of shipping has let them ship prototype features that probably weren't worth shipping and that they need to invest more time cleaning up and fixing things.

https://x.com/thdxr/status/2031377117007454421

Highly recommend trying pi.dev

It's fully open, fairly minimal, very extensible and (while getting very frequent updates) never has broken on me so far.

Been using it more and more in the last two months, switching more and more from codex to it now.

I'm still trying to figure out how "open" it really is; There are reports that it phones home a lot[0], and there is even a fork that claims to remove this behavior[1]:

[0] https://www.reddit.com/r/LocalLLaMA/comments/1rv690j/opencod...

[1] https://github.com/standardnguyen/rolandcode

Probably all describe problems stem from the developers using agent coding; including using TypeScript, since these tools are usually more familiar with Js/Js adjacent web development languages.

The moment that OpenCode, after helping fix a Dockerfile issue, decided it was time to deploy to prod without asking for consent, I was out.

I agree that Opencodr is using a lot of RAM, but regarding the features, I am ak only using the built in features and I wouldn't say they are too many, they are just enough for a complete workflow. If you need more you can install plugins, which I haven't done yet and it's my daily driver for four months.

The value of having (and executing) a coherent product vision is extremely undervalued in FOSS, and IMO the difference between a successful project in the long-term and the kind of sploogeware that just snowballs with low-value features.

Is there a name for these types of "overbearing" and visually busy "TUIs"? It seems like all the other agents have the same aesthetic and it is unlike traditional nurses or plain text interfaces in a bad way IMO. The constant spinners, sidebars and needless margins are a nuisance to me. Especially over an ssh connection in a tmux session it feels wrong.

I’ve pretty much ended up with a pi.dev+gpt-5 and Claude combo. Sometimes I use GLM with Pi if I run out of quota or need some simple changes.

I tried Opencode but it was just too much? Same with Crush, 10/10 pretty but lacking in features I need. LSP support was cool though.

I’m a little surprised by your description of constant releases and instability. That matches how I would describe Claude Code, and has been one of the main reasons I tend to use OpenCode more than Claude Code.

OpenCode has been much more stable for me in the 6 months or so that I’ve been comparing the two in earnest.

That sounds a lot like my experience with claude code. IDK about OpenCode, but claude code is also largely written by LLMs, and you can tell.

I’ve been testing opencode and it feels TUI in appearance only. I prefer commandline and TUIs and in my mind TUI idea is to be low level, extremely portable interface and to get out of the way. Opencode does not have low color, standard terminal theme so had to switch to a proper terminal program. Copy paste is hijacked so I need to write code out to file in order to get a snippet. The enter key (as in the return by the keypad) does not work for sending a line. I have not tested but don’t think this would work over SSH even. I have been googling around to find if I am holding it wrong but it feels to break expectations of a terminal app in a way that I wish they would have made it a gui. Makes me sad because I think the goods are there and it’s otherwise good.

Yeah every time I want to like it, scrolling is glitched vs codex and Claude. And other various things like: why is this giant model list hard coded for ollama or other local methods vs loading what I actually have...

On top of that. Open code go was a complete scam. It was not advertised as having lower quality models when I paid and glm5 was broken vs another provider, returning gibberish and very dumb on the same prompt

Drives me nuts that we have TUIs written in friggin TS now.

That being said, I do prefer OpenCode to Codex and Claude Code.

> they add, remove, refine, change, fix, and break features constantly at that accelerated pace.

I wonder how much of this is because the maintainers are using OpenCode to vibe the code for OpenCode.

That is very disappointing coz I've been wanting to try an alternative to Gemini CLI for exactly these reasons. The AI is great but the actual software is a buggy, slow, bloated blob of TypeScript (on a custom Node runtime IIUC!) that I really hate running. It takes multiple seconds to start, requires restarting to apply settings, constantly fucks up the terminal, often crashes due to JS heap overflows, doesn't respect my home dir (~/.gemini? Come on folks are we serious?), has an utterly unusable permission system, etc etc. Yet they had plenty of energy to inject silly terminal graphics and have dumb jokes and tips scroll across the screen.

Is Claude Code like this too? I wonder if Pi is any better.

A big downside would be paying actual cost price for tokens but on the other hand, I wouldn't be tied to Google's model backend which is also extremely flaky and unable to meet demand a lot of the time. If I could get real work done with open models (no idea if that's the case yet) and switch providers when a given provider falls over, that would be great.

You are describing a typical state of a wibecoded project.

claude code easily uses 10+GB in single session :) 1Gb sounds very efficient by comparison

> they're constantly releasing at an extremely high cadence, where they don't even spend the time to test or fix things

Tbf, this seems exactly like Claude Code, they are releasing about one new version per day, sometimes even multiple per day. It’s a bit annoying constantly getting those messages saying to upgrade cc to the latest version

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.

Yeah I tried using it when oh-my-opencode (now oh-my-openagent) started popping off and found it had highly unstable. I just stick with internal tooling now.

Why not just code your own agent harness

How much of the development is being done by humans?

What is a better option?

yeah I agree is way too buggy, nice tho and I appreciate the effort but really feels sloppy

Yeah just try to select text to copy. Nope. Try to scroll back in terminal or tmux. Nope. Overbearing for sure.

its hard not to wonder if they are taking their own medicine, but not quite properly

this is a bot comment

I tried it briefly and the practice - argued for strategy for operation actually - to override my working folder seelction and altering to the parent root git folder is a no go.

Isn't this pretty much the standard across projects that make heavy use of AI code generation?

Using AI to generate all your code only really makes sense if you prioritize shipping features as fast as possible over the quality, stability and efficiency of the code, because that's the only case in which the actual act of writing code is the bottleneck.

I tried running Opencode on my 7$/yr 512mb vps but it had the OOM issue and yes it needs 1GB of ram or more.

I then tried running other options like picoclaw/picocode etc but they were all really hard to manage/create

The UI/UX I want is that I can just put my free openrouter api key in and then I am ready to go to get access to free models like Arcee AI right now

After reading your comments/I read this thread, I tried crush by charmbracelet again and it gives the UI/UX that I want.

I am definitely impressed by crush/ the charm team. They are on HN and they work great for me, highly recommended if you want something which can work on low constrained devices

I do feel like Charm's TUI's are too beautiful in the sense that running a connection over SSH can delay so when I tried to copy some things, the delay made things less copy-able but overall, I think that I am using Crush and I am happy for the most part :-)

Edit: That being said, just as I was typing this, Crush took all the Free requests from Openrouter that I get for free so it might be a bit of minor issue but overall its not much of an issue from Crush side, so still overall, my point is that Crush is worth checking out

Kudos to the CharmBracelet team for making awesome golang applications!

Rust > TS Codex > OpenCode

This is my main problem I have with it: It sends data and loads code left and right by default. For instance, the latest plugin packages are automatically installed on every startup. Their “Zen” provider is enabled by default so you might accidentally upload your code base to their servers. Better yet: The web UI has a button that just uploads the entire session to their servers WITH A SINGLE CLICK for sharing.

The situation is ... pretty bad. But I don’t think this is particularly malicious or even a really well considered stance, but just a compromise in order to move fast and ship useful features.

To make it easily adoptable by anyone privacy conscious without hours of tweaking, there should be an effort to massively improve this situation. Luckily, unlike Claude Code, the project is open source and can he changed!

> By default OpenCode sends all of your prompts to Grok's free tier

Just my prompts, or everything the agent has in the context window?

Also, could you please provide a reference for this claim? Thank you

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.

Fwiw this got changed about a week ago, where they changed the logic to match the documentation rather than default to sending your prompts to their servers. This is why so many people have noticed this happening but if you ask an AI about it right now it will say this is not true.

Personally I think it's necessary to run opencode itself inside a sandbox, and if you do that you can see all of the rejected network calls it's trying to make even in local mode. I use srt and it was pretty straightforward to set up

Also, even when using local models in ollama or lmstudio, prompts are proxied via their domain, so never put anything sensitive even when using local setup

https://old.reddit.com/r/LocalLLaMA/comments/1rv690j/opencod...

They also don't let you run all local models, but specific whitelisted by another 3rd party: https://github.com/anomalyco/opencode/issues/4232

Geez there should be a big warning on the tin about this. They’re so neatly integrated with copilot that I assumed (and told others) that they had all the privacy guarantees of copilot :(

this isn't true

it will use whatever small model there is in your provider

we had a fallback where we provided free small models if your provider did not have one (gpt nano)

some configs fell back to this unexpectedly which upset people so we removed it

Not true according to a CGPT question:

More importantly, the current dev branch source for packages/opencode/src/session/summary.ts shows summarizeMessage() now only computes diffs and updates the message summary object; it does not make an LLM call there anymore. The current code path calls summarizeSession() and summarizeMessage(), and summarizeMessage() just filters messages, computes diffs, sets userMsg.summary.diffs, and saves the message.

https://github.com/anomalyco/opencode/blob/dev/packages/open...

Yikes... sending prompts to a third party by default with no disclosure in the setup flow is a rough look for a tool that positions itself as the open sources alternative. "Open" loses meaning fast if the defaults work against the user.

Seems like an anti-pattern to me to run AI models without user’s consent.

My understanding is that it’s best to set a whitelist in enabled_providers, which prevents it from using providers you don’t anticipate.

Are you using Grok for the coding? Because I have Copilot connected and I can see the request to Copilot for the summaries - with no "small model" setting even visible in my settings.

Try pi.dev+gpt-5, it works amazingly well

Just note that you need to either create any special features yourself or find an implementation by someone else. It’s pretty bare bones by default

Couldn’t tell by the way they write their software.

They probably don't have to write OKRs every quarter saying the opposite.

Do you follow them? They most definitely pump out insane takes on twitter. But maybe that’s just engagement bait for a check, of course.

They are not blacklisted. You are allowed to use the API at commercial usage pricing. You are just not allowed to use your Claude Code subscription with OpenCode (or any other third‑party harness for the record).

You can still use OpenCode with the Anthropic API.

More what to come?

a $3000 AMD395+ will get you pretty close to a open development environment.

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.

Same.

Pi is refreshingly minimal in terms of system prompts, but still works really well and that makes me wonder whether other harnesses are overdoing. Look at OpenCode's prompts, for instance - long, mostly based on feels and IMO unnecessary. I would've liked to just overwrite OC's system prompts with Pi's (to get other features that Pi doesn't have) but that isn't possible today (without maintaining a custom fork)

Pi is the Emacs of coding AI agents.

It's a pity it's written in TS, but at least it can draw from a big contributor pool.

There is https://eca.dev/ too, which might worth considering, which is a UI agnostic agent, a bit like LSP servers.

I just found out about pi yesterday. It's the only agent that I was able to run on RISC-V. It's quite scary that it runs commands without asking though.

Same here!

The simplicity of extending pi is in itself addictive, but even in its raw form it does the job well.

Before finding pi I had written a lot of custom stuff on top of all the provider specific CLI tools (codex, Claude, cursor-agent, Gemini) - but now I don’t have to anymore (except if I want to use my anthropic sub, which I will now cancel for that exact reason)

Same.

I’m sure there’s a more elegant way to say this, but OpenCode feels like an open source Claude Code, while pi feels like an open source coding agent.

> Sessions are stored as trees

that is actually really nice

Pi is a great project, and the lightweight Agent development is really recommended to refer to Pi's implementation method.

Pi is good stuff and refreshingly simple and malleable.

I used it recently inside a CI workflow in GitLab to automatically create ChangeLog.md entries for commits. That + Qwen 3.5 has been pretty successful. The job starts up Pi programatically, points it at the commits in question, and tells it to explore and get all the context it needs within 600 seconds... and it works. I love that this is possible.

Hey I built that into my harness! http://github.com/computerex/z

Long tool outputs/command outputs everything in my harness is spilled over to the filesystem. Context messages are truncated and split to filesystem with a breadcrumb for retrieving the full message.

Works really well.

The infinite context window framing is the right way to think about it. Running inside Claude Code continuously, the prune step matters more than retrieve in practice — most of what gets dropped stays dropped. More useful is being deliberate about what goes in at the start of each loop iteration rather than managing what comes out at the end.

That doesn't sound all that useful to be honest and would likely increase costs overall due to the hit to prompt caching by removing messages

Have a look how pi.dev implements /tree. Super useful

That borks the cache and costs you more.

Seems interesting, but at a glance I can't find a repo or a package manager download for this. Have you made it available anywhere?

> Moat seems to be shrinking fast.

It's been a moving target for years at this point.

Both open and closed source models have been getting better, but not sure if the open source models have really been closing the gap since DeepSeek R1.

But yes: If the top closed source models were to stop getting better today, it wouldn't take long for open source to catch up.

The moat is having researchers that can produce frontier models. When OpenCode starts building frontier models, then I'd be worried; otherwise they're just another wrapper

Can you talk more about how you leverage higher quality models for the stuff that counts? Anywhere I can read more on the philosophy of when to use each?

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?

By "agent" you mean what?

Coding is mostly "agentic" so I'm bit puzzled.

Related https://github.com/anomalyco/opencode/issues/10416

You can't write your system prompt in opencode, there's no API to override the default anthropic.txt as far as I'm aware.

I considered creating a PR for that, but found that creating new agents instead worked fine for me.

Very cool! I have been using opencode, as almost everybody else in the lab is using codex. I found the tools thing inside your own repo amazing but somehow I could not get it to reliably get opencode to write its own tools. Seems also a bit scary as there is pretty much not much security by default. I am using it in a NixOS WSL2 VM

In terms of output, it's comparable. In terms of workflow, it suits my needs a lot more as a VIM terminal user.

I started out using VSCode with their Claude plugin; it seemed like a totally unnecessary integration. A better workflow seems to just run Claude Code directly on my machine where there are fewer restrictions - it just opens a lot more possibilities on what it can do

Aren’t those in-editor tools? Opencode is a CLI

Months ago I tested a concept revolving this issue and made a weird MCP-LSP-LocalLLM hybrid thing that attempts to enhance unlucky, fast changing, or unpopular languages (mine attempts with Zig)

Give it a look, maybe it could inspire you: https://github.com/fulgidus/zignet

Bottom-line: fine-tuning looks like the best option atm

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!

My own experience trying many different models is that general intelligence of the model is more important.

If you want it to stick to better practices you have to write skills, provide references (example code it can read), and provide it with harnessing tools (linters, debuggers, etc) so the agent can iterate on its own output.

I'd be interested in this too. I think that's what post-training can achieve but I've never looked into it.

i like the containerization idea. i wish you used the opencode cli as the actual underlying agent.

Do you think the design direction of “chat first” is compatible with editor first? I don’t know if any tools do both well. Seems like a fork in the road, design wise.

It’s both! The core is implemented as a server and any UI (the TUI being one) can connect to it.

It’s actually “dumber” than any of your suggestions - they just let the agent explore to build up context on its own. “ls” and “grep” are among the most used discovery tools. This works extraordinarily well and is pretty much the standard nowadays because it lets the agent be pretty smart about what context it pulls in.

Could you say more about the differences between Aider and OpenCode?

I briefly dabbled with Aider some months back but never got any real work done with it. Without installing each one of these new tools I'm having trouble grokking what is changing about them that moves the LLM-assisted software dev experience forward.

One thing I like with Aider is the fact that I can control the context by using /add explicitly on a subset of files. Can you achieve the same wit OpenCode ?

I'm curious: I'venever touched cloud models beyond a few seconds. I run a AMD395+ with the new qwen coder. Is there any intelligence difference, or is it just speed and context? At 128GB, it takes quite awhile before getting context wall.

I created a tool for this: https://github.com/Use-Tusk/fence

Same thoughts - I wanted a "permission manager" that defines a set of policies agnostic to coding agents. It also comes with "monitor mode" that shows operations blocked, but not quite an audit log yet though.

This is another one of OpenCode’s current weak points in the security complex: They consider permissions a “UX feature” rather than actual guardrails. The reasoning is that you’re giving the agent access to the shell, so it’ll be able to sidestep everything.

This is of course a cop-out: They’re not considering the case in which you’re not blindly doing that.

Fun fact: In the default setup, the agent can fully edit all of the harnesses files, including permissions and session history. So it’s pretty trivial for it to a) escalate privileges and then even b) delete evidence of something nefarious happening.

It’s pretty reckless and even pretty easy to solve with chroot and user permissions. There just has been (from what I see currently) relatively little interest from the project in solving this issue.

Granted, I just started playing around with OpenCode (but been using Codex and Claude Code since they were initially available, so not first time with agents), but anyways:

> they need broad file system access to be useful, but that access surface is also the attack surface

Do they? You give them access to one directory typically (my way is to create a temporary docker container that literally only has that directory available, copied into the container on boot, copied back to the host once the agent completed), and I don't think I've needed them to have "broad file system access" at any point, to be useful or otherwise.

So that leads me to think I'm misunderstanding either what you're saying, or what you're doing?

Codex has some OS-level sandboxing by default that confines its actions to the current workspace [1].

OpenCode has no sandboxing, as far as I know.

That makes Codex a much better choice for security.

[1] https://developers.openai.com/codex/concepts/sandboxing

Greywall/Greyproxy aims to address this. I haven't tried it yet though.

https://greywall.io/

Or just run it in your VPS?

I built a product solving this problem about a year ago, basically a serverless, container-based, NATed VScode where you can eg "run Claude Code" (or this) in your browser on a remote container.

There's a reason I basically stopped marketing it, Cursor took off so much then, and now people are running Claude/Codex locally. First, this is something people only actually start to care about once they've been bitten by it hard enough to remember how much it hurt, and most people haven't got there yet (but it will happen more as the models get better).

Also, the people who simultaneously care a lot about security and systems work AND are AI enthusiasts AND generally highly capable are potentially building in the space, but not really customers. The people who care a lot about security and systems work aren't generally decision makers or enthusiastic adopters of AI products (only just now are they starting to do so) and the people who are super enthusiastic about AI generally aren't interested in spending a lot of time on security stuff. To the extent they do care about security, they want it to Just Work and let them keep building super fast. The people who are decision makers but less on the security/AI trains need to this happen more, and hear about the problem from other executives, before they're willing to spend on it.

To the extent most people actualy care about this, they still want to Just Work like they do now and either keep building super fast or not thinking about AI at all. It's actually extremely difficult to give granular access to agents because the entire point is them acting autonomously or keeping you in a flow state. You either need to have a really compatible threat model to doing so (eg open source work, developer credentials only used for development and kept separate from production/corp/customer data), spend a lot of time setting things up so that agents can work within your constraints (which also requires a willingness to commit serious amounts of time or resources to security, and understanding of it), or spend a lot of time approving things and nannying it.

So right now everybody is just saying, fuck it, I trust Anthropic or Microsoft or OpenAI or Cursor enough to just take my chances with them. And people who care about security are of course appalled at the idea of just giving another company full filesystem access and developer credentials in enterprises where the lack of development velocity and high process/overhead culture was actually of load-bearing importance. But really it's just that secure agentic development requires significant upfront investment in changing the way developers work, which nobody is willing to pay for yet, and has no perfect solutions yet. Dev containers were always a good idea and not that much adopted either, btw.

It takes a lot more investment in actually providing good permissions/security for agent development environments still too, which even the big companies are still working on. And I am still working on it as well. There's just not that much demand for it, but I think it's close.

What caused the switch? Also, are you still trying to use Claude models in OpenCode?

I think Anthropic just highly RL’s their model to work best with it’s Claude Code’s particular ways of going about things.

All the background capability Claude code now has makes things way more complex and I saw a meaningful improvement with 4.6 versus 4.5, so imagine other harnesses will take time to catch up.

> I wasn't even aware TUI could have compatibility issues with Wayland

They shouldn't, as long as your terminal emulator doesn't. Why do you think it's Wayland related?

Strange. I've been running it on several different ubuntu 24 04 machines with standard terminal with no issues.

This shouldn't be related to Wayland.

It works perfectly fine on Niri, Hyprland and other Wayland WMs.

What problem do you have?

Definitely not Wayland related, or so I doubt. I'm on wayland and never had any issues, and it's a TUI, where the terminal emulator does or does not do GPU work. What led you to that conclusion?

Probably vibe coded

I've been paying OpenAI 200 bucks a month for what feels like forever by now, but used OpenCode for the first time yesterday, been using Codex (and Claude Code from time to time, to see if they've caught up with Codex) since then.

But I don't use MCP, don't need anything complicated, and not sure what OpenCode actually offers on top. The UI is slightly nicer (but oh so much heavier resource usage), both projects source code seems vibecoded and the architecture is held together with hopes and dreams, but in reality, minor difference really.

Also, didn't find a way in OpenCode to do the "Fast Mode" that Codex has available, is that just not possible or am I missing some setting? Not Codex-Spark but the mode that toggles faster inference.

If it was a somewhat unique name, then yeah maybe. But "opencode" is probably as generic as you could make it, hard to claim to be "squatting" something so well used already... Earliest project on GitHub named "opencode" seems to date back to 2010, but I'm sure there are even earlier projects too: https://github.com/search?q=opencode&type=repositories&s=upd...

you'll be surprised the name was actually a controversy on x/twitter since opencode was originally another dev's idea who joined the charmcli team. they wanted to keep that name but dax somehow (?) ended up squatting it. the charmcli team has renamed their tool to "crush" which matches their other tools a lot better than "opencode"

They had that?! I saw that some people wrote skills and plugins to call claude cli and gemini cli to still be able to use the subscription. I would also wish that this was supported out of the box, something similar to goose cli providers or acp providers (https://block.github.io/goose/docs/guides/acp-providers). But I don't want to spend testing yet another agent harness or change the workflow when I somewhat got used to one way of working on things (the churn is real).

I guess you could look into my plugin for that use case of CC inside opencode: https://github.com/unixfox/opencode-claude-code-plugin

You can do it.

Rather than listing what tooling you think is worse than OpenCode, wouldn't it make sense to list what tooling you think is better?

"This guy is coding everything in the terminal, he must be really good!"

Yeah, support the company that promised to help your government illegally mass surveil and mass kill people, because they support a use case slightly better than the non-mass-murdering option.

You're right, Anthropic shouldn't have even taken a moral stance here at all. They should have just gone full send and allowed everything, because there will never be satisfying some people. Why even try?

In Claude Code, you can use the (undocumented command) "/model opusplan" to use opus for planning and sonnet for development

With OpenCode, I've found that I can do this by defining agents, assigning each agent a specifically model to use. Then K manually flip to that agent when I want it or define some might rules in my global AGENTS.nd file to gives some direction and OpenCode will automatically subtask out to the agent, which then forces the use of the defined model.

> we did our best to convince anthropic to support developer choice but they sent lawyers

https://x.com/i/status/2034730036759339100

‘abuse’. The same rate limits apply, the requests still go to the same endpoints.

Even as a CC user I’m glad someone is forcing the discussion.

My prediction: within two years ‘model neutrality’ will be a topic of debate. Creating lock-in through discount pricing is anti-competitive. The model provider is the ISP; the tool, the website.

Agree, I find it hard to support them when the team is so obnoxious on X.

API support was never removed

Because this site is basically dead for any other subject than vibecoding and AI agents.

Yes

I'm 90% sure Fireworks serves up quantized models.

No because Gemini CLI is slow and barely functioning.

It is clearly not. Why would you think so?

yep

Or just don't abuse the subscription and use the API instead.

Sure but will you get banned by anthropic anyway?

They are using effect-ts which uses yield as their equivalent to haskells Do notation.

I use bubblewrap. This ensures it only has access to the current working directory and its own configuration. No ability to commit or push (since it doesn't have access to ssh keys) or try to run aws commands (no access to awscli configuration) and so on. It can read anything from my .envrc, since it doesn't have access to direnv or the parent directory. You could lock down the network even further if you wanted to limit web searches.

  exec bwrap \
    --unshare-pid \
    --unshare-ipc \
    --unshare-uts \
    --share-net \
    --bind "$OPENCODE_ROOT" "$OPENCODE_ROOT" \
    --bind "$CURRENT_DIR" "$CURRENT_DIR" \
    --bind "$HOME/.config/opencode/" "$HOME/.config/opencode/" \
    --ro-bind /bin /bin \
    --ro-bind /etc /etc \
    --ro-bind /lib /lib \
    --ro-bind /lib64 /lib64 \
    --ro-bind /usr /usr \
    --bind /run/systemd /run/systemd \
    --tmpfs /tmp \
    --proc /proc \
    --dev /dev \
    --setenv OPENCODE_EXPERIMENTAL_LSP_TOOL true \
    --setenv EDITOR emacs \
    --setenv PATH "$OPENCODE_BINDIR:/usr/bin:/bin" \
    --setenv HOME "$HOME" \
    -- \
    "opencode" "$@"

I built Fence for this! https://github.com/Use-Tusk/fence

fence -t code -- opencode

nope - most folks wrap it in nono: https://nono.sh/docs/cli/clients/opencode

Does github copilot ToS allow this?

OpenCode, by reason of plugins alone, is better than all of them.

No

GPT 5.4 has been the winner this week. Last week Opus 4.6. You can use both in OpenCode.

If you want faster, anything running on a Cerebras machine will do.

Never tried it for much coding though.

do you care about harness benchmarks or no?

  > Please do not abuse the term "open" like in OpenBSD.

Are you sure that endpoint is sending all traffic to opencode? I'm not familiar with Hono but it looks like a catch all route if none of the above match and is used to serve the front-end web interface?

That linked code is not used by the opencode agent instance though right? Looks related to their web server?

They don't. That is just the route for their WebUI, which is completely optional.

I've point thought about making things that just send garbage to any data collecting service.

You'd be surprised how useless datasets become with like 10% garbage data when you don't know which data is garbage

Does opencode still work if you blackhole the telemetry?

this is a big red flag

You can use Github Copilot and also use Claude that way.

No, they haven’t. You can use claude like any other model via API, you just can’t reuse your subscription token.

There’s plenty of options to get around that.