The approach you're describing (redesign the protocol) is one path. Another is to sidestep the protocol entirely by using a platform that already owns its rendering surface and happens to run in a terminal: my preference is Neovim.
Let me get the caveats out of the way first: this only makes sense if you already live in Neovim. The whole ergonomic case is muscle memory you already have. If you're not a Neovim user, you're just buying another learning curve. Also, the language is Lua (not Rust) so it won't appeal to the ratatui crowd on that front, and there's no proper layout system yet.
Neovim [0] renders to its own buffer system (extmarks, floating windows, virtual text) rather than emitting ANSI escape codes. Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box.
On the UI framework side, morph.nvim [1] provides a React-like component model (h(), state, reconciliation) on top of Neovim. It's not a general answer the way ratatui is, but for the slice of devs already in Neovim (there are dozens of us!), it's a pragmatic way to get GUI-framework-like ergonomics without the terminal protocol fight.
For a sample of what TUIs in this paradigm can look like, I've been working on tuis.nvim [2] (Docker, K8s, SystemD services, process management, and more all as native Neovim buffer TUIs).
I have built a pretty full version of that idea in rust (codex tui2). There's a while tonne of downsides that make it basically impossible to really get to 100% good on this.
> Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box.
All that is not true. Take scrolling for example. Each terminal emulator implements this subtly differently (mouse/trackpad/speed etc.), scrolling will never feel native unless you push the control of it into the terminal emulator.
There's more than that, each and every point on this becomes something that you have a gap between native and the terminal emulator that you're building to run in the terminal.
On k8s/devops tooling: I'm building tuis.nvim [1] — Docker and Kubernetes management as Neovim buffer TUIs, built on morph.nvim [2], a react-like UI framework for Neovim. Stay in the editor (if you already use Neovim, of course) instead of switching to k9s, works over SSH, same Vim keybindings you already use. Also has plugins for Bitwarden, process management, and file exploration.
To me particularly, leaving editor isn't a hassle because kitty makes it seamless. Neovim, k9s, zsh shell, agents, it feels like it's just a single IDE, and I believe that specialized tools are simpler and more robust to maintain instead of adding functionality that wasn't intended for neovim. Don't get me wrong, neovim is sufficiently flexible for this, it's just that I had too much agro with neovim extensions that I just prefer native tools.
That is a valid point of view. For me, however, I have found a huge productivity boost being able to stay in Neovim for extended periods of time. That's not to say that my way is the only right way, but the more I'm able to accomplish in Neovim, the less friction I personally experience.
I've been working on exactly this with morph.nvim [1] — a React-like component model (h(), component lifecycle, reconciliation, extmark-based styling) for building declarative TUIs. It uses Neovim as a base, which might seem like an odd choice, but Neovim gives a lot out of the box that most TUI frameworks don't: syntax highlighting, extmark tracking (i.e., editable regions that feed back into the component state — type in a filter and the UI re-renders around it), and navigation that Vim users already know without learning yet another keybinding layer. Built on top, tuis.nvim [2] ships real plugins — Docker, K8s, Bitwarden, process manager — all as native Neovim buffer TUIs. No Electron, no separate app window, runs over SSH.
So far, it's just a flash-banner on their `/code` page. I don't see any announcement other than folks mentioning that they are getting email announcements about its release.
Total Parameters: 1 trillion (1T)
Active Parameters: 32 billion (32B)
Number of Experts: 384, with 8 experts activated per token
Context Length: 256K tokens (upgraded from 128K in the original K2)
Model Layers: 61 layers (including 1 dense layer)
Attention Mechanism: MLA (Multi-head Latent Attention)
Activation Function: SwiGLU
Attention Hidden Dimension: 7168
Vocabulary Size: 160K
Training Data: 15.5 trillion tokens
Knowledge Cutoff: April 2025
License: Apache 2.0 (open-source, commercially usable)
There are no benchmarks yet for that specific model:
> While official benchmark data for K2.6 Code Preview has not yet been released, the K2 series' historical performance speaks to its strength: (…)
I could not find any info who is behind kimi-k2.org. There is no info on the site itself and no one has that site in its bio. There are some people and repos treating that site as official site of Moonshot AI, but it is not. The footer cleary says:
> kimi-k2.org is an unofficial resource site dedicated to Kimi K2, offering objective and comprehensive information along with practical use cases. The site is completely free to access with no login required. (…) Not affiliated with MoonshotAI. All trademarks belong to their respective owners.
Tommy Emmanuel apparently learned by transrcibing, famously thinking that both the bass line and guitar lines he was hearing were a singular "guitar part". Just by having his expectations (incorrectly) raised, he rose to the occasion and played both parts.
I forget where I heard this story -- it's probably either rather famous, or buried in an interview somewhere.
Tommy drew a lot of inspiration from Chet Atkins who was really the pioneer of the bass+guitar "one hand band" style of playing. Tommy just improved on it a lot, adding more rhythmic elements, but to your point, yes, he was largely self-taught and driven to learn.
The percussionist Trilok Gurtu has said the same thing about listening to many recordings as he was growing up. He just assumed that all the percussion was played by one person, all at once, and so he figured out ways to do it, even when it was 2 or even 3 people with overdubs.
As others have said, the fact that they're letting the ecosystem settle before including something out-of-the box is beneficial in some sense. It's allowed time for experiments (including my own "how would I do UI in Neovim: morph.nvim [1]").
For some, this stage of a project attracts tinkerers and builders, and lets the community shape how things are done in the future. It's not always practical, but it does have a certain appeal.
Let me get the caveats out of the way first: this only makes sense if you already live in Neovim. The whole ergonomic case is muscle memory you already have. If you're not a Neovim user, you're just buying another learning curve. Also, the language is Lua (not Rust) so it won't appeal to the ratatui crowd on that front, and there's no proper layout system yet.
Neovim [0] renders to its own buffer system (extmarks, floating windows, virtual text) rather than emitting ANSI escape codes. Under the hood it's still a terminal app, but from the UI author's perspective you're not fighting terminfo, CSI sequences, or varying terminal support. You get proper cursor tracking, scroll regions, and editable text areas out of the box.
On the UI framework side, morph.nvim [1] provides a React-like component model (h(), state, reconciliation) on top of Neovim. It's not a general answer the way ratatui is, but for the slice of devs already in Neovim (there are dozens of us!), it's a pragmatic way to get GUI-framework-like ergonomics without the terminal protocol fight.
For a sample of what TUIs in this paradigm can look like, I've been working on tuis.nvim [2] (Docker, K8s, SystemD services, process management, and more all as native Neovim buffer TUIs).
[0] https://neovim.io
[1] https://github.com/jrop/morph.nvim
[2] https://github.com/jrop/tuis.nvim
reply