I read it with a different flavor. Is it possible that Mythos did all of this? I mean, life has always been finding a way, hasn't it? The first cry of cyber-life?
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.
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.
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?
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.
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.
I think they were saying that in "cup" screen mode (CUP: CUrsor Position, activated with smcup termcap), when you exit (rmcup) the text is lost, as well as the history since it was managed by the application, not the terminal.
Their hypothesis was that maybe there was aj intention to have claude code fill the terminal history. And using potentially harzardous cursor manipulation.
In other words, readline vs ncurse.
I don't see python and ipython readline struggling as bad tho...
To clarify: this is the terminal's scrollback buffer vs one managed by the application in the alternate screen.
When I scroll up in nvim, it will keep the editor frame in place (that's the top bar and bottom bar showing things like open buffers, git status, the scratch buffer or whatever it's called), but the file contents will scroll by because nvim at that point has exclusive ownership of the entire screen and can do anything with it, including repainting parts of it in response to motions or a mouse scrolling (if your terminal supports emitting mouse events).
This is in contrast to the `rmcup` "normal" terminal mode where it will scroll back in the terminal's history.
The best analogue I have for that last one is to use tmux with nvim open, and have a tmux visual selection going. You can scroll up and out of nvim, and keep scrolling to whatever was executed before neovim, and when you get out of tmux visual mode it'll snap back down to the bottom of your scrollback buffer, nvim (nominally) taking up the entire pane like nothing happened; but we can probably agree that outside of a few narrow use cases, this isn't a very desirable way to manage scrolling in a terminal.
I don't think that's likely to explain jankiness. I do know my way around terminal screens and escape codes, and doing flicker-free, curses-like screen updates works equally well on the regular screen as on the alternate screen, on every terminal I've used.
It's also not a hard problem, and updates are not slow to compute. Text editors have been calculating efficient, incremental terminal updates since 1981 (Gosling Emacs), and they had to optimise better for much slower-drawing terminals, with vastly slower computers for the calculation.
Yesterday, I resumed a former claude code session in order to copy code it had generated earlier in that session. Unfortunately, when resuming, it only prints the last N hundred lines of the session to the terminal, so what I was looking for was cut off.
I think that for this sort of _interactive_ application, there's no avoiding the need to manage scroll/history.
That conversation should still exist in the Claude Code log files. Just give Claude some context on how to find it, and it will pull whatever you need. I use this to recall particularly effective prompts later on for reuse.
> 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/
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.
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
They have a really cool TUI setup that is kinda in a real sense made with a small game engine :)
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
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.
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.
Not really. This guy expresses my feelings: 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.
It is not a tricky problem because it has a simple and obvious solution: do not filter or block usage just because the input includes a word like "gun".
The utils directory should only contain truly generic, business-agnostic utilities (such as date retrieval, simple string manipulation, etc.).
We can see that the code produced by Vibe is not what a professional engineer would write. This may be due to the engineers using the Vibe tool.
reply