https://github.com/charmbracelet/crush/pulse/monthly
https://github.com/sst/opencode/pulse/monthly
An unfortunate clash. I can say from experience that the sst version has a lot of issues that would benefit from more manpower, even though they are working hard. If only they could resolve their differences.
Language server, check, Plugin ecosystem, check, Running tests on demand, check. lua sucks but that's an acceptable compromise as vimscript is worse.
Also terminals support mice. Have done for literally decades.
Ultimately though, it just boils down to personal preference
I had lots of problems with plugins in the ecosystem breaking, becoming incompatible with others, or often falling into unmaintained status. Integrations with external SaaS services are much better too
Also information density (and ease of access) as a peer comment has mentioned
This is a common complaint but I haven't done any setup for months.. And installing a language server because I need to write typescript is just <leader>cm and then lllll on the servers I need.
I'm also not sure whether Gemini CLI is actually better aligned with the context of development environments.
Anyway—slightly off-topic here:
I’m using Gemini CLI in exactly the same way I use VS Code: I type to it. I’ve worked with a lot of agents across different projects—Gemini CLI, Copilot in all its LLM forms, VS Code, Aider, Cursor, Claude in the browser, and so on. Even Copilot Studio and PowerAutomate—which, by the way, is a total dumpster fire.
From simple code completions to complex tasks, using long pre-prompts or one-shot instructions—the difference in interaction and quality between all these tools is minimal. I wouldn’t even call it a meaningful difference. More like a slight hiccup in overall consistency.
What all of these tools still lack, here in year three of the hype: meaningful improvements in coding endurance or quality. None of them truly stand out—at least not yet.
I don't think any will every truly stand out from the others. Seems more like convergence than anything else
If the optimal way to do a particular thing is a grid of rectangular characters with no mouse input, nothing prevents you having one of those in your GUI where it makes sense.
For instance, you can look up the documentation for which keys to press to build your project in your TUI IDE, or you can click the button that says "build" (and hover over the button to see which key to press next time). Why is typing :q<enter> better than clicking the "X" in the top-right corner? Obviously, the former works over ssh, but that's about it.
Slowness is an implementation detail. If MSVC6 can run fast enough on a computer from 1999 (including parsing C++) then we should be able to run things very fast today.
Being some IDE for a terminal doesn't mean you can't have menues and everything must be driven with vi modal keys and commands.
> works with no dev environment at all
The terminal is a dev environment, my IDE has it built in. Copilot can read both the terminal and the files in my project, it even opens them and shows me the diff as it changes them. No need to switch context between where I normally code and some AI tool. These TUIs feel like the terminal version of the webapp, where I have to go back and forth between interfaces.
Much better to use Neovim than a very clunky slow editor like VS Code or Jetbrains just to edit a text file.
The keyboard is far faster than clicking everywhere with the mouse.
I think the sentiment that VS Code is clunky and slow is outdated. I have seen no noticeable impact since moving over from neovim
It's easier to see the diff file by file and really control what the AI does IMO.
On another note VS Code is not an IDE, it's a text editor.
Perhaps your definition of IDE is more restrictive. I see VS Code as my environment where I develop with masses of integrations
No, I used neovim and spent way too much time trying to turn it into an IDE, even with the prepackaged setups out there
VS Code is sitting below 5% CPU and 1G of memory, not seeing the resource hog you are talking about. LSPs typically use more resources (which is outside and the same for both)
I like terminal things because they are easy to use in context wherever I need them - whether that's in my shell locally or over SSH, or in the integrated terminal in whatever IDE I happen to be using.
I use vim if I need to make a quick edit to a file or two.
Idk, terminal just seems to mesh nicely into whatever else I'm doing, and lets me use the right tool for the job. Feels good to me.
What I don't get is going back to terminal first approaches and why so many companies are putting these out (except that it is probably (1) easy to build (2) everyone is doing it hype cycle). It was similar when everyone was building ChatGPT functions or whatever before MCP came out. I expect the TUI cycle will fade as quickly as it rose
I don't know for sure or have anything besides anecdotal evidence but I'd wager this is a majority of vscode users.
For me, a terminal environment means I can use any tool or tech, without it being compatible with the IDE. Editors, utilities, and runtimes can be chosen, and I'm responsible for ensuring they can interop.
IDEs being convenience by integrating all of that, so the choice is up to the user: A convenient self contained environment, vs a more custom self assembled one.
Choose your own adventure.
What I don't have to do is context switch between applications or interfaces
In other comments I relayed the sentiment that I enjoy not having to custom assemble a dev environment and spend way too much time making sure it works again after some plugin updates or neovim changes their APIs and breaks a bunch of my favorite plugins
it's basic, edit the config file. I just downloaded it, ~/.cache/share/crush/providers.json add your own or edit an existing one
Edit api_endpoint, done.
``` { "providers": { "ollama": { "type": "openai", "base_url": "http://localhost:11434/v1", "api_key": "ollama", "models": [ { "id": "llama3.2:3b", "model": "Llama 3.2 3B", "context_window": 131072, "default_max_tokens": 4096, "cost_per_1m_in": 0, "cost_per_1m_out": 0 } ] } } } ```
I spent at least an hour trying to get OpenCode to use a local model and then found a graveyard of PRs begging for Ollama support or even the ability to simply add an OpenAI endpoint in the GUI. I guess the maintainers simply don't care. Tried adding it to the backend config and it kept overwriting/deleting my config. Got frustrated and deleted it. Sorry but not sorry, I shouldn't need another cloud subscription to use your app.
Claude code you can sort of get to work with a bunch of hacks, but it involves setting up a proxy and also isn't supported natively and the tool calling is somewhat messed up.
Warp seemed promising, until I found out the founders would rather alienate their core demographic despite ~900 votes on the GH issue to allow local models https://github.com/warpdotdev/Warp/issues/4339. So I deleted their crappy app, even Cursor provides some basic support for an OpenAI endpoint.
Almost from day one of the project, I've been able to use local models. Llama.cpp worked out of the box with zero issues, same with vllm and sglang. The only tweak I had to make initially was manually changing the system prompt in my fork, but now you can do that via their custom modes features.
The ollama support issues are specific to that implementation.
Also, it looks like Crush has an irrevocable eventual fallback to MIT[1] allowing them to develop in open so you basically get all the bells and whistles available. We probably couldn't ask for more :)
[1] https://github.com/charmbracelet/crush/blob/317c5dbfafc0ebda...
> opencode kinda cheats by using Antropic client ID and pretending to be Claude Code, so it can use your existing subscription. [1]
I'd definitely like to see Anthropic provide a better way for the user's choice of clients to take advantage of the subscription. The way things stand today, I feel like I'm left with no choice but to stick to Claude Code for sonnet models and try out cool tools like this one with local models.
Now, with all that said, I did recently have Claude code me up a POC where I used Playwright to automate the Claude desktop app, with the idea being that you could put an API in front of it and take advantage of subscription pricing. I didn't continue messing with it once the concept was proved, but I guess if you really wanted to you could probably hack something together (though I imagine you'd be giving up a lot by ramming interactions through Claude Desktop in this manner). [2]
Though i think in Neovims case they had to reverse engineer the API calls for Claude Code. Perhaps that's against the TOS.
Regardless i have the intention to make something similar, so hopefully it's not against the TOS lol.
What I miss from all of these (EDIT: I see opencode has this for github) is the lack of being able to authenticate with the monthly paid services; github copilot, claude code, openai codex, cursor etc etc
That would be the best addition; I have these subscriptions and might not like their interfaces, so it would be nice to be able to switch.
So they just don't tend to work at all like you'd expect a REPL or a CLI to work, despite having exactly the same interaction model of executing command prompts. But they also don't feel at all like fullscreen Unix TUIs normally would, whether we're talking editors or reader programs (mail readers, news readers, browsers).
Is this just all the new entrants copying Claude Code, or did this trend get started even earlier than that? (This is one of the reasons Aider is still my go-to; it looks and feels the way a REPL is supposed to.)
(Technically, WezTerm's semantic zones should be the way to solve this for good - but that's WezTerm-only, I don't think any other terminal supports those.)
On the other hand, with GUIs this is not an issue at all. And YMMV, but for me copying snippets, bits of responses and commands is a very frequent operation for any coding agent, TUI, GUI or CLI.
I quite like them, unlike traditional TUIs, the keybindings are actually intuitively discoverable, which is nice.
They make a CLI framework for golang along with tools for it.
They didn't do it flashy for this project specifically (like Claude Code, which I don't think is flashy at all) but every single one of their other projects are like this.
> A command-line toolkit to support you in your daily work as a software programmer. Built to integrate into your existing workflow, providing a flexible and powerful pair-programming experience with LLMs.
The team behind DCD[1] are funding my work, as we see a lot of potential in a local-first, open-source, CLI-driven programming assistant for developers. This is obviously a crowded field, and growing more crowded by the day, but we think there's still a lot of room for improvement in this area.
We're still working on a lot of the fundamentals, but are moving closer to supporting agentic workflows similar to Claude Code, but built around your existing workflows, editors and tools, using the Unix philosophy of DOTADIW.
We're not at a state where we want to promote it heavily, as we're introducing breaking changes to the file format almost daily, but once we're a bit further along, we hope people find it as useful as we have in the past couple of months, integrating it into our existing terminal configurations, editors and local shell scripts.
[0]: https://github.com/dcdpr/jp [1]: https://contract.design
^ for the uninitiated
Its next gen script kids.
I 100% unironically believe we're better off more script kiddies today, not fewer.
I fear that todays kids are too compliant on everything; the script kiddie ethos at the time still wasn't primarily clear fraud, just chaos. Which, yeah, I think we could use a little of that now.
I was a script kiddie, I exploited games too when I was a kid, and so on.
Flashy stuff for the terminal it's not new. Heck, in late 90's/early 00's everyone tired e17 and eterm at least once. And then KDE3 with XRender extensions with more fancy stuff on terminals and the like, plus compositor effects with xcompmgr and later, compiz.
But I'm old fashioned. I prefer iomenu+xargs+nvi and custom macros.
The parent commenter seems to be asking for the same thing, but with rich text/media.
Presumably, you'd want this, but with some sort of interface _like_ these TUI systems?
Yeah, I prefer something like that (which should be strictly easier to make than these elaborate TUIs). I could also be interested in a shell that supports it natively, e.g. with a syntax such as `-- this is my prompt! it's not necessary to quote stuff`. I'd also enjoy an HTML shell that can output markdown, tables and interactive plots rather than trying to bend a matrix of characters to do these things (as long as it's snappy and reliable). I haven't looked very hard, so these things might already exist.
Personally, I find warp a bit disorienting, but it is indeed a more integrated approach.
The whole advantage to a shell, and why people get so obsessed with it, is that they provide a standard interface to every program. Tuis break that by substituting their own ui.
They also provide a standard output... limitation, really, which means you can suddenly do pipes.
The future should look to capture both of those benefits.
Everyone will get super mad, but html is honest to god a great way to do this. Imagine a `ls` that output html to make a prettt display of your local files, but if you wanted to send the list to another program you pass some kind of css selector `ls | .main-list.file-names.name` or something. It's not exactly beautiful but you get the idea.
https://ratatui.rs/showcase/apps/
https://github.com/charmbracelet/bubbletea/tree/main/example...
https://textual.textualize.io/
I've been drafting a blog post about their pros and cons. You're right, text input doesn't feel like a true REPL, probably because they're not using readline. And we see more borders and whitespace because people can afford the screen space.
But there's perks like mouse support, discoverable commands, and color cues. Also, would you prefer someone make a mediocre GUI or a mediocre GUI for your workflows?
Discover the joys of Turbo Vision and things like Norton Commander, DOS Navigator, Word Perfect etc.
They problem is that most current tools can neither do the TUI right or the terminal part right.
I'm guessing building this is what Charm raised the funds for.
https://dictionary.cambridge.org/dictionary/english/glamorou...
Is there secret sauce that would make one better than the other? Available tools? The internal prompting and context engineering that the tool does for you? Again, assuming the model is the same, how similar should one expect the output from one to another be?
Am curious about such results, it's one thing to think it's another to know! :D
I think Claude Code specifically has a reputation for being a 1st class citizen - as in the model is trained and evalled on that specific toolcall syntax.
This is the most interesting feature IMO, interested to see how this pans out. The multiple sessions / project also seems interesting.
[1] - https://github.com/charmbracelet/crush/blob/317c5dbfafc0ebda...
Up / down history Copy text
Other than these issues feels much nicer than Claude Code since the screen does not shake violently.
Other papercuts: no up/down history, and the "open editor" command appears to do nothing.
Still, it's a _ridiculously_ pretty app. 5 stars. Would that all TUIs were this pleasing to look at.
I've been following Charm for some time and they’re one of the few groups that get DX and that consistently ship tools that developers love. Love seeing them joining the AI coding race. Still early days, but this is clearly a tool made by people who actually use it.
edit: setting the key as an env variable works tho.
Silly
Let's not forget they're the company that bought an OSS project, OpenCode, and tried to "steal" it
One problem with these agents is that the tokens don't count for your Claude Max subscription. (Same reason I use CC instead of Zed's AI agent.)
Pros:
- Beautiful UI
- Useful sidebar, keep track of changed files, cost
- Better UX for accepting changes (has hotkeys, shows nicer diff)
Cons:
- Can't combine models. Claude Code using a combination of Haiku for menial search stuff and Sonnet for thinking is nice.
- Adds a lot of unexplained junk binary files in your directory. It's probably in the docs somewhere I guess.
- The initial init makes some CHARM.md that tries to be helpful, but everything it had did not seem like helpful things I want the model to know. Simple stuff, like, my Go tests use PascalCasing, e.g. TestCompile.
- Ctrl+C to exit crashed my terminal.
Oh god please no... can we please just agree on a standard for a well-known single agent instructions file, like AGENT.md [1] perhaps (and yes, this is the standard being shilled by Amp for their CLI tool, I appreciate the irony there). Otherwise we rely on hacks like this [2]
The terminal is so ideal for agentic coding and the more interactive the better. I personally would like to be able to enter multiline text in a more intuitive way in claude code. This nails it.
Opencode allows auth via Claude Max, which is a huge plus over requiring API (ANTHROPIC_API_KEY)
cristea•23h ago
I just can’t get an easy overview of how each tool works and is different
riotnrrd•22h ago
Even aside from the expense (which penalizes universities and smaller labs), I feel it's a bad idea to require academic research to compare itself to opaque commercial offerings. We have very little detail on what's really happening when OpenAI for example does inference. And their technology stack and model can change at any time, and users won't know unless they carefully re-benchmark ($$$) every time you use the model. I feel that academic journals should discourage comparisons to commercial models, unless we have very precise information about the architecture, engineering stack, and training data they use.
tough•14h ago
you can totally evaluate these as GUI's, and CLI's and TUI's with more or less features and connectors.
Model quality is about benchmarks.
aider is great at showing benchmarks for their users
gemini-cli now tells you % of correct tools ending a session
imjonse•21h ago
beanjuiceII•15h ago
tough•14h ago
moozilla•13h ago
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.
canadaduane•11h ago
/me up and continues search for good people and good projects.
DavidPP•1h ago
paradite•20h ago
And all these factors are not independent. Some combinations work better than others. For example:
- Claude Sonnet 4 might work well with feature implementation, on backend code python code using Claude Code.
- Gemini 2.5 Pro works better for big fixes on frontend react codebases.
...
So you can't just test the tools alone and keep everything else constant. Instead you get a combinatorial explosion of tool * model * context * prompt to test.
16x Eval can tackle parts of the problem, but it doesn't cover factors like tools yet.
https://eval.16x.engineer/