Isn't it more appropriate to compare this to aider?
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?
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 share the same experience. Looking at diffs inside a terminal is as helpful as looking at diffs inside GitHub. I need code navigation to fully understand the impact of a code change or just the code base.
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.
Side note, if you're a lazygit fan, consider using gitui as an alternative. Feature wise they're pretty similar but gitui is much faster and I find it easier to use.
tmux! That was today's project. I'm using Claude Code Opus 4 to translate a K&R C computer algebra system (Macaulay) from the 1980's into C23. Finally getting to the "compiles but crashes" (64 bit issues) I found us living inside the lldb debugger. While I vastly prefer a true terminal to the periscope AI agent view in Cursor, it was still painful having at best a partial view of Claude's shell use, interleaved with our chat. What I wanted was a separate terminal session AI and I could share as equal partners.
tmux is the quickest way to implement such an idea.
That's an interesting idea! I struggle with the same issues you've mentioned, that space between the IDE integrated option and pure CLI. Your comment sparked an idea of using something like vim or similar where you can edit the config on the fly and reload it. I wonder how hard it would be to bolt a prompt interface to the front to have it build the editor for you?
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!
I'm running Claude Code with vscode. With frequent commits I can use the source control tab to get a feeling of changes being made. This helps in spotting changes to files that should not have been changed.
I've been using VSCode with aider, but with auto-committing turned off. VSCode has a thing where changes not yet checked into the tree are highlighted in the scrollbars -- blue for modified, green for added, red for removed. You can then click the colored part of the sidebar to see a diff.
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.
Just wanted to say I had been happily plodding along using AI tools in Zed, which had worked pretty well but seeing the SST team was behind OpenCode I decided to finally give a terminal based agent a try. I was blown away, primarily by the feedback loops of say OpenCode writing new tests, running the test suite, seeing the tests errored and looping back start the whole process again. That looping does not happen in Zed!
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.
I’ve definitely had exactly that sort of looping work with Zed, as long as I tell it how to run the tests. Are you perhaps not using one of the “thinking” models?
That might be it. I use GitHub CoPilot through Zed as Zed does not accept the Claude subscription (that I'm using with OpenCode). I've primarily used Sonnet 3.7 in Zed, I'll try out the thinking model and see if that changes anything.
"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." - this yet-to-be-defined "happiness" metric will be important moving forward. Apart from Opencode & Leap.new (so far) I still haven't found something where I feel as happy.
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.
I've had pretty good experiences with Junie, their UI is really pleasant! Kind of wish I could put in an API key for Sonnet or Gemini myself and get rid of any rate limits.
Outside of JetBrains IDEs I also quite enjoy RooCode, though stuff like GitHub Copilot is decent.
Been using aider as my daily driver for a while, just gave opencode a spin last night.
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.
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?
There’s some discussion in GitHub that suggests they are not using prompt caching, but recognize the need and are looking at it: https://github.com/sst/opencode/issues/254
I feel like the guy behind this project loves getting into internet fights to create drama/clickbait. That being said, it's a cool project - still in its early stages and nowhere as usable as the other CLIs...but it's a darn shame about all the drama.
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.
> do I have to pay API based costs
Usually, yes, you do.
However, in this case, opencode kinda cheats by using Antropic client ID and pretending to be Claude Code, so it can use your existing subscription.
> We recommend signing up for Claude Pro or Max, running opencode auth login and selecting Anthropic. It’s the most cost-effective way to use opencode.
https://opencode.ai/docs/
This ain’t what you asked but I’m using Claude Code with a pro subscription and I get about an hour use out of it before I run out of tokens. Then I spend 4 hours thinking about how to set up my context for the next session.
I have a very different experience. I have built https://github.com/pixlie/SmartCrawler almost entirely on Claude Code with some usage of Google Jules. Even all GitHub workflows are from CC. I still have tokens left since I try multiple other ideas in parallel.
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.
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.
Been spending the day with this. I have no experience with TUI tools like Claude Code, so I had no expectations going into it. My first go with it was unfortunately soured by a broken /init command, but that actually got fixed almost immediately -- the Discord is fairly busy. That one hitch aside, I authed it into my Github Copilot account and immediately I was able to start vibing out, adding some features to a random project of mine. Worked great.
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.
Readit News
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?
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.
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.
https://github.com/gitui-org/gitui
tmux is the quickest way to implement such an idea.
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.
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.
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.
Outside of JetBrains IDEs I also quite enjoy RooCode, though stuff like GitHub Copilot is decent.
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.
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...
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
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.
Deleted Comment
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.
Guess I really have to look into making this more efficient.
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
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.