Opencode: AI coding agent, built for the terminal
github.com
github.com
I prefer the command line tools to IDE integration, even though I don't feel like the contextual options are great. In other words, I don't always feel that I can see the changes fully. I like Claude Code's option to expand the result using ctrl-r, and I like the diffs it provides. But, it still feels like there is a way to get better than what I see inside Zed and what I see inside Claude and Aider.
Maybe an editor that can be controlled and modified on the fly using natural language?
It would likely quickly devolve into typical editor config bikeshedding, only AI powered? At least for me, maybe someone smarter could streamline it enough to be useful though!
But, do it for emacs, ok? </joke>
Actually, I *do* prefer emacs.
bind-key C-g display-popup -E -d "#{pane_current_path}" -xC -yC -w 80% -h 75% "lazygit"
not only does it allow you to see the diffs, but you can directly discard changes you don't want, stage, commit, etc.
tmux is the quickest way to implement such an idea.
The best experience I've had is to completely divorce editing from vibe coding. Ask the chatbot to do something, then review the results as if a junior developer submitted them - that means diffs and opening files in the editor.
Fundamentally I think these are really distinct operations. I understand why the kitchen sink IDEs jam the genAI tools into their UIs, but I don't think it's necessarily important to link the two functions.
I exclusively use Claude Code these days, and I don't remember having accepted the result of a prompt a single time on the first shot. I always have to fix some stuff here and there, improve some tests or comments or even make the code more readable. Being in an IDE is a must for me, and I don't see how this could change.
Just for fun I typically also have an emacs window open; "git diff > working.diff" lets you see the diff, then "C-c C-c" on a diff hunk will take you the place in the file where that change was made.
It was the first time I felt like I could write up a large prompt, walk away from my laptop, and come back to a lot of work having been done. I've been super happy with the experience so far.
Outside of JetBrains IDEs I also quite enjoy RooCode, though stuff like GitHub Copilot is decent.
It's been my go-to, along with Claude Code on the side for bigger stuff.
I don't know if others share this sentiment but with all these tools/agents coming out, the main personal "metric" I look at when using them is happiness, rather than other more traditional metrics that I look at when evaluating tools.
One other thing that would be neat to make more visible: what kind of prompts and tools are at the heart of this agent?
I found a bunch of tools here. Haven't found an overarching prompt yet. https://github.com/sst/opencode/tree/dev/packages/opencode/s...
but we're going to make all this very configurable next week
As another comment by the authors said, they're still pretty early days, so there's a lot of missing documentation and functionality; that's the price you pay for being on the bleeding edge.
Two big differences:
1. opencode is much more "agentic": It will just take off and do loads of stuff without asking, whereas aider normally asks permission to do everything. It will make a change, the language server tells it the build is broken, it goes and searches for the file and line in the error message, reads it, and tries to fix it; rinse repeat, running (say) "go vet" and "go test" until it doesn't see anything else to do. You can interrupt it, of course, but it won't wait for you otherwise.
2. aider has much more specific control over the context window. You say exactly what files you want the LLM to be able to see and/or edit; and you can clear the context window when you're ready to move on to the next task. The current version of opencode has a way to "compact" the context window, where it summarizes for itself what's been done and then (it seems) drops everything else. But it's not clear exactly what's in and out, and you can't simply clear the chat history without exiting the program. (Or if you can, I couldn't find it documented anywhere.)
ETA: opencode will tell you how big the context window is, but not what's in the context (AFAICT).
3. As sort of a side effect of both of those, the "rtt" seems much shorter for opencode: lots of small actions with quick feedback for opencode, vs long contiguous responses for aider. But that could be more how I happened to use it than something specific.
I do feel like opencode's UI is more... "sparkling"? The screen is much more "managed", with windows, a status bar, more colors, etc. Aider is much more like the REPL loop of, say, python or sqlite3.
we're a little over a month into development and have a lot on our roadmap
the cli is client/server model - the TUI is our initial focus but the goal is to build alternative frontends, mobile, web, desktop, etc
we think of our task as building a very good code review tool - you'll see more of that side in the following weeks
can answer any questions here
After a brief play last night, the biggest feature of aider I miss is more control over the context window -- saying "/clear" to re-start the conversation from scratch, or specifying files to add or remove as they become relevant or irrelevant. Not clear how much or how long files stay in the context window.
The other question I have is whether you use Anthropic's "prompt caching" [1] to reduce the cost of the long conversation?
[1] https://docs.anthropic.com/en/docs/build-with-claude/prompt-...
and nothing expires out from the session until you get near the context window max - at which point we do a compaction process
Again the theme of the difference is control over the context: partly for cost management, partly because the quality tends to degrade with the length of the context.
But it may be that the main thing needed is just a change of workflow. So far I am finding opencode's ability to find things out for itself quite refreshing.
And as if to emphasize this, I was using opencode this morning with Sonnet; but once the context window got up close to 100k, only about 30% through implementing a new feature (which doesn't seem that large to me), it repeatedly failed with "Error: oldString not found in content or was found multiple times", which I take to mean that it wasn't generating patches in the right format.
This isn't the first time this has happened to me. Maybe my code is just more complicated than other people's, so it gets confused more easily. But having tools to manage the complexity the LLM is exposed to has been critical to making it useful.
I am using Claude Code almost exclusively. I am using the Claude Pro subscription and it allows Claude Code usage, with limits on the number of prompts per 5 hours, according to their site. I have not hit these limits yet even though I use this full-time, daily.
With other tools, do I have to pay API based costs or are there ways to use my subscription? As I see it, the API costs add up quickly. That means we can be stuck with a few tools from the top tier model companies.
Guess I really have to look into making this more efficient.
I have coded a few landing pages and even a full React Native app with the same Claude Pro account in the last month. I do not consider this huge usage, but this is similar to a couple months of my own programming with AI assistance (like Zed + Supermaven).
Please note: SmartCrawler is not ready for usage, you can surely try it out though but I am changing the inner workings and it is half-complete.
Also, there are many branches of code that I have thrown away because I did not continue that approach. Example, I was trying a bounding box way to detect what data to extract, using the HTML element's position and size on browser. All coded with Claude Code. Generating such ideas is cheap in my opinion.
other than the focus on tui design, does this have any advantage over Claude Code, Aider, Gemini using the same model?
I asked it to examine a codebase and it went lightning-fast into full refactoring mode and started "fixing" stuff - while profusely apologising because it couldn't get the code to compile :D
Currently the best way to use Gemini CLI is to instruct Claude to use it when examining large codebases. Gemini investigates -> generates markdown summary -> Claude uses summary to direct itself without wasting context.
we're very focused on UX and less so on LLM performance. we use all the same system prompts/config as claude code
that said people do observe better performance because of out of the box LSP support - edit tools return errors and the LLM immediately fixes them
> we're very focused on UX and less so on LLM performance
I'm gonna stick with this for now. The dev is responsive, updates regularly, it works fine, and it just seems to keep getting better.
sst/opencode I can use with my existing Copilot subscription, and select Claude Sonnet 4 freely. I never hit the limit before, and all friction is gone! If Google ever builds a better model, I can switch the same day, and keep my workflows, configs, etc.
Also, with Claude COde I always felt a little mistrust, since theoretically they benefit from providing a more expensive service. opencode doesn't have this misaligned incentive.
I'm curious about how they feel to use and their "performance".
ETA: The above link is at the bottom of the original submission's README. (https://github.com/sst/opencode) I posted it without context, and I have no opinion on the matter. Please read theli0nheart's comment below for an X rebuttal.
--
I’m the founder and CEO of Charm. There are claims circulating about OpenCode which are untrue, and I want to clarify what actually happened.
In April, Kujtim Hoxha built a project called TermAI—an agentic coding tool built on top of Charm’s open-source stack: Bubble Tea, Lip Gloss, Bubbles, and Glamour.
Two developers approached him offering UX help and promotion, and suggested renaming the project to OpenCode. One of them bought a domain and pointed it at the repo.
At the time, they explicitly assured Kujtim that the project and repo belonged entirely to him, and that he was free to walk away at any point.
We loved what Kujtim built and offered him a full-time role at Charm so he could continue developing the project with funding, infrastructure, and support. The others were informed and declined to match the offer.
I also mentioned that if the project moved to Charm, a rename might follow. No agreement was made.
Shortly after, they forked the repo, moved it into their company’s GitHub org, retained the OpenCode name, took over the AUR package, and redirected the domain they owned.
To clarify specific claims being circulated:
- No commit history was altered
- We re-registered AUR packages for continuity
- Comments were only removed if misleading or promotional
- The project is maintained transparently by its original creator
The original project, created by Kujtim, remains open source and active—with the full support of the team at Charm.
That’s the story. We’ll have more to share soon.
Okay I feel old now.
Seriously, though: Charm creates CLI tools, not coding agents: https://charm.sh/ https://github.com/orgs/charmbracelet/repositories
Also, https://github.com/kujtimiihoxha 's recent commits are in https://github.com/opencode-ai/opencode .
But what does https://sst.dev/ (org behind https://github.com/sst/opencode) have to do with either charm or opencode?? Like Charm, it has nothing to do with coding agents.
Not for me.
Neither of these companies are focused on LLMs or AI, they're both just using this as AI dust to sprinkle on top of their products.
Anybody know where exactly this is hosted?
This is the original OpenCode repository, now continuing at Charm with its original creator, Kujtim Hoxha.
Development is continuing under a new name as we prepare for a public relaunch.
Follow @charmcli or join our Discord for updates.
This is a third party retelling of this story from some post I read, as I came to know about it only after Dax started working on TS TUI for opencode under SST.
I should be one of those people, I guess. I love shell scripts and all the rest... but interactive terminal UIs have always sucked.
So much of what AI companies are putting out is designed to capture developer mindshare. Substantive improvements to their core product (models) are few and far between, so they release these fidgets about once a month to keep the hope alive.
From that standpoint, TUI makes sense because it obscures the process and the result enough to sucker more people into the vibe-coding money hole.
It makes sense I guess if a TUI is easier to build and ship than a GUI.
It does make we wonder why devs don't just use the TUI to vibecode a GUI and compete with Cursor...
It also doesn't prevent you from using an IDE at all, but still fits for people with text editors like Vim who doesn't want to use IDEs.
On the other hand, agent integrations in IDEs seem to often add a lot more widgets for interacting with agents, and often they put the agent is in its own little tab off to the side, and I find that harder to work with.
That's why, even though I love using IDEs and have never been a big terminal person, I much prefer using Claude Code in the terminal rather than using tools like Copilot in VSCode (ignoring the code quality differences). I just find it nicer to separate the two.
The portability of being able to really easily run Claude Code in whatever directory you want, and through SSH, is a nice bonus too.
I've been using Roocode (Cline fork) a lot recently and while it's overall great, the UI is janky and incomplete feeling. Same as Cursor and all the others.
I tried Claude Code after hearing great things and it was just Roocode with a worse UX (for me). Most of the people telling me how great it was were talking up the output as being amazing quality. I didn't notice that. I presume the lack of IDE integration makes it feel more magical. This is fun while you're vibing the "first 80%" of your product, but eventually the agents need much more hand holding and collaborative edits to keep things on track.