4 ms·

Open Claude Code? Better than OpenCode and Codex

by lanbin 6mo ago

rurban 6mo ago
Not really. This guy expresses my feelings: https://www.youtube.com/watch?v=nxB4M3GlcWQ https://www.youtube.com/watch?v=nxB4M3GlcWQ I also prefer codex over claude. But opencode is best. If you can use a good model. We can via Github Business Subscription.
- sandipb 6mo ago
  The only issue I have with opencode is that it takes over the entire terminal, unlike claude code. Otherwise I love OC.
arcanemachiner 6mo ago
I wish. Claude Code is clearly a pile of vibe-coded garbage. The UI is janky and jumps all over the place, especially during longer sessions. (Which also have a several second delay to render. In a terminal). Lately, it's been crashing if I hold the Backspace key down for too long. Being open-source would be the best thing to happen to them. At least they would finally get a pair of human eyes looking at their codebase. Claude is amazing, but the people at Anthropic make some insane decisions, including trying (and failing, apparently) to keep Claude Code a closed-source application.
- encoderer 6mo ago
  As a point of reference, I’m a heavy cc user and I’ve had a few bugs but I’ve never had the terminal glitches like this. I use iterm on macOS sequoia.
  - breatheoften 6mo ago
    To offer the opposite anecdotal evidence point -- claude scrolls to the top of the chat history almost capriciously often (more often than not) for me using iterm on tahoe
    - JelteF 6mo ago
      Scrolling around when claude is "typing" makes it jump to the top
    - jen20 6mo ago
      I've had it do it occasionally in all of Ghostty, iTerm2 and Prompt 3 (via SSH, not sure what terminal emulator that uses under the hood)
    - kgp7 6mo ago
      I thought I was the only one who had this problem - so annoying, and the frequent Ui glitches when it asks you to choose an option .
    - iterateoften 6mo ago
      Wow I thought it was tmux messing up on me, interesting to hear it happens without it too
      - rafaelmn 6mo ago
        Not tmux related at all had it happen in all kinds of setups (alacritty/linux, vscode terminal macos)
  - jetbalsa 6mo ago
    i will note that they really should of used something like ncurses and kept the animations down, TTYs are NOT meant to do the level of crazy modern TUIs are trying to pull off, there is just too many terminal emulators out there that just don't like the weird control codes being sent around.
  - tmp10423288442 6mo ago
    To be fair, iTerm is likely to be the single most common terminal emulator used by Claude Code developers, so I'd hope that it would work tolerable well there.
- radlad 6mo ago
  Imagine being Anthropic and opening yourself up to the deluge of CC-coded PRs by all of your users.
  - mcintyre1994 6mo ago
    See also: https://github.com/openclaw/openclaw/pulls https://github.com/openclaw/openclaw/pulls (6,647 open PRs)
- ambicapter 6mo ago
  > Claude Code is clearly a pile of vibe-coded garbage. The UI is janky and jumps all over the place, especially during longer sessions. (Which also have a several second delay to render. In a terminal). Don't you know, they're proud of their text interface that is structured more like a video game. https://spader.zone/engine/ https://spader.zone/engine/
  - spencerflem 6mo ago
    Not to stand up for Claude Code in any way, I don’t like the company or use the product. This is just a related tangent- one of my favorite software projects, Arcan, is built on the idea that there’s a lot of similarities between Game Engines, Desktop Environments, Web Browsers, and Multimedia Players. https://speakerdeck.com/letoram/arcan?slide=2 https://speakerdeck.com/letoram/arcan?slide=2 They have a really cool TUI setup that is kinda in a real sense made with a small game engine :) https://arcan-fe.com/2022/04/02/the-day-of-a-new-command-line-interface-shell/ https://arcan-fe.com/2022/04/02/the-day-of-a-new-command-lin...
  - rafaelmn 6mo ago
    I mean if you want glitchy garbage that works in the happy path mostly then game engine is the right foundation to build on. Software quality is the last thing game devs are known for. The whole industry is about building clever hacks to get something to look/feel a certain way, not building robust software that's correct to some spec.
    - FartyMcFarter 6mo ago
      Can confirm (used to work in the games industry). Code reviews and automatic testing of any kind are a rare sight.
    - spencerflem 6mo ago
      In my experience games crash a lot less often than the windows file explorer I feel like we give what’s some pretty impressive engineering short shrift because it’s just for entertainment
- _verandaguy 6mo ago
  I've actually heard a plausible theory about the TUI being janky, that being that they avoid use of the alternate screen feature of ANSI (and onwards) terminals. The theory states that Anthropic avoids using the alternate screen (which gives consuming applications access to a clear buffer with no shell prompt that they can do what they want with and drop at their leisure) because the alternate screen has no scrollback buffer. So for example, terminal-based editors -- neovim, emacs, nano -- all use the alternate screen because not fighting for ownership of the screen with the shell is a clear benefit over having scrollback. The calculus is different when you have an LLM that you have a conversational history with, and while you can't bolt scrollback onto the alternate screen (easily), you can kinda bolt an alternate screen-like behaviour onto a regular terminal screen. I don't personally use LLMs if I can avoid it, so I don't know how janky this thing is, really, but having had to recently deal with ANSI terminal alternate screen bullshit, I think this explanation's plausible.
  - edvinbesic 6mo ago
    Not disagreeing but scrolling works just fine in vim/emacs/etc. Wouldn't it be just managing the scroll back buffer yourself rather than the terminals?
    - jdiff 6mo ago
      Yes, but this does come with differences and tradeoffs. If the terminal isn't managing the scrollback, you don't get scrollbars and you lose any smooth/high resolution scrolling. You also lose fancy terminal features like searching the scrollback, all that needs to be implemented in your application. Depending on the environment it can also wind up being quite unpleasant to use with a trackpad, sometimes skipping around wildly for small movements.
      - _verandaguy 6mo ago
        The other part (which IMO is more consequential) is that once the LLM application quits or otherwise drops out of the alternate screen, that conversation is lost forever. With the usual terminal mode, that history can outlive the Claude application, and considering many people keep their terminals running for days or sometimes even weeks at a time, that means having the convo in your scrollback buffer for a while.
- snackbroken 6mo ago
  > Lately, it's been crashing if I hold the Backspace key down for too long. Golden opportunity to re-enact xkcd 1172.
lrvick 6mo ago
If you want something better than both of those try Crush which is a standalone go binary by the original developer of OpenCode.

Open Claude Code? Better than OpenCode and Codex

by lanbin 6mo ago

Open Claude Code? Better than OpenCode and Codex

Not really. This guy expresses my feelings: https://www.youtube.com/watch?v=nxB4M3GlcWQ https://www.youtube.com/watch?v=nxB4M3GlcWQ I also prefer codex over claude. But opencode is best. If you can use a good model. We can via Github Business Subscription.

sandipb 6mo ago
The only issue I have with opencode is that it takes over the entire terminal, unlike claude code. Otherwise I love OC.

arcanemachiner 6mo ago

I wish. Claude Code is clearly a pile of vibe-coded garbage. The UI is janky and jumps all over the place, especially during longer sessions. (Which also have a several second delay to render. In a terminal). Lately, it's been crashing if I hold the Backspace key down for too long. Being open-source would be the best thing to happen to them. At least they would finally get a pair of human eyes looking at their codebase. Claude is amazing, but the people at Anthropic make some insane decisions, including trying (and failing, apparently) to keep Claude Code a closed-source application.

encoderer 6mo ago
As a point of reference, I’m a heavy cc user and I’ve had a few bugs but I’ve never had the terminal glitches like this. I use iterm on macOS sequoia.
- breatheoften 6mo ago
  To offer the opposite anecdotal evidence point -- claude scrolls to the top of the chat history almost capriciously often (more often than not) for me using iterm on tahoe
  - JelteF 6mo ago
    Scrolling around when claude is "typing" makes it jump to the top
  - jen20 6mo ago
    I've had it do it occasionally in all of Ghostty, iTerm2 and Prompt 3 (via SSH, not sure what terminal emulator that uses under the hood)
  - kgp7 6mo ago
    I thought I was the only one who had this problem - so annoying, and the frequent Ui glitches when it asks you to choose an option .
  - iterateoften 6mo ago
    Wow I thought it was tmux messing up on me, interesting to hear it happens without it too
    - rafaelmn 6mo ago
      Not tmux related at all had it happen in all kinds of setups (alacritty/linux, vscode terminal macos)
- jetbalsa 6mo ago
  i will note that they really should of used something like ncurses and kept the animations down, TTYs are NOT meant to do the level of crazy modern TUIs are trying to pull off, there is just too many terminal emulators out there that just don't like the weird control codes being sent around.
- tmp10423288442 6mo ago
  To be fair, iTerm is likely to be the single most common terminal emulator used by Claude Code developers, so I'd hope that it would work tolerable well there.
radlad 6mo ago
Imagine being Anthropic and opening yourself up to the deluge of CC-coded PRs by all of your users.
- mcintyre1994 6mo ago
  See also: https://github.com/openclaw/openclaw/pulls https://github.com/openclaw/openclaw/pulls (6,647 open PRs)
ambicapter 6mo ago
> Claude Code is clearly a pile of vibe-coded garbage. The UI is janky and jumps all over the place, especially during longer sessions. (Which also have a several second delay to render. In a terminal). Don't you know, they're proud of their text interface that is structured more like a video game. https://spader.zone/engine/ https://spader.zone/engine/
- spencerflem 6mo ago
  Not to stand up for Claude Code in any way, I don’t like the company or use the product. This is just a related tangent- one of my favorite software projects, Arcan, is built on the idea that there’s a lot of similarities between Game Engines, Desktop Environments, Web Browsers, and Multimedia Players. https://speakerdeck.com/letoram/arcan?slide=2 https://speakerdeck.com/letoram/arcan?slide=2 They have a really cool TUI setup that is kinda in a real sense made with a small game engine :) https://arcan-fe.com/2022/04/02/the-day-of-a-new-command-line-interface-shell/ https://arcan-fe.com/2022/04/02/the-day-of-a-new-command-lin...
- rafaelmn 6mo ago
  I mean if you want glitchy garbage that works in the happy path mostly then game engine is the right foundation to build on. Software quality is the last thing game devs are known for. The whole industry is about building clever hacks to get something to look/feel a certain way, not building robust software that's correct to some spec.
  - FartyMcFarter 6mo ago
    Can confirm (used to work in the games industry). Code reviews and automatic testing of any kind are a rare sight.
  - spencerflem 6mo ago
    In my experience games crash a lot less often than the windows file explorer I feel like we give what’s some pretty impressive engineering short shrift because it’s just for entertainment
_verandaguy 6mo ago
I've actually heard a plausible theory about the TUI being janky, that being that they avoid use of the alternate screen feature of ANSI (and onwards) terminals. The theory states that Anthropic avoids using the alternate screen (which gives consuming applications access to a clear buffer with no shell prompt that they can do what they want with and drop at their leisure) because the alternate screen has no scrollback buffer. So for example, terminal-based editors -- neovim, emacs, nano -- all use the alternate screen because not fighting for ownership of the screen with the shell is a clear benefit over having scrollback. The calculus is different when you have an LLM that you have a conversational history with, and while you can't bolt scrollback onto the alternate screen (easily), you can kinda bolt an alternate screen-like behaviour onto a regular terminal screen. I don't personally use LLMs if I can avoid it, so I don't know how janky this thing is, really, but having had to recently deal with ANSI terminal alternate screen bullshit, I think this explanation's plausible.
- edvinbesic 6mo ago
  Not disagreeing but scrolling works just fine in vim/emacs/etc. Wouldn't it be just managing the scroll back buffer yourself rather than the terminals?
  - jdiff 6mo ago
    Yes, but this does come with differences and tradeoffs. If the terminal isn't managing the scrollback, you don't get scrollbars and you lose any smooth/high resolution scrolling. You also lose fancy terminal features like searching the scrollback, all that needs to be implemented in your application. Depending on the environment it can also wind up being quite unpleasant to use with a trackpad, sometimes skipping around wildly for small movements.
    - _verandaguy 6mo ago
      The other part (which IMO is more consequential) is that once the LLM application quits or otherwise drops out of the alternate screen, that conversation is lost forever. With the usual terminal mode, that history can outlive the Claude application, and considering many people keep their terminals running for days or sometimes even weeks at a time, that means having the convo in your scrollback buffer for a while.
snackbroken 6mo ago
> Lately, it's been crashing if I hold the Backspace key down for too long. Golden opportunity to re-enact xkcd 1172.

lrvick 6mo ago

If you want something better than both of those try Crush which is a standalone go binary by the original developer of OpenCode.