[HN Gopher] Show HN: Nori CLI, a better interface for Claude Cod...
___________________________________________________________________
Show HN: Nori CLI, a better interface for Claude Code (no flicker)
Hi HN, my name's Clifford and I'm one of the creators of Nori. I've
been using Claude Code heavily since last summer, and after
understanding some of the tradeoffs with their TUI implementation,
I knew I couldn't see myself living for years with this interface
as one of my daily-driver tools. It is _not_ a hard problem to
make monospace text output performant, so why does Claude Code
suffer from flicker and strobing in the terminal
(https://github.com/anthropics/claude-code/issues/1913)? Even after
they've released multiple improvements for this, I still see the
issue in terminal splits with fewer rows, or in less performant
emulators, and even within a virtual TTY (the absolute simplest
environment to run an interactive program in). After digging in
throughout the past half year, the issue is mostly inevitable
because Claude reprints full terminal history without using alt
screen mode and uses a React-based framework (Ink) to render and
style their text. That's great for JS+CSS being "on distribution"
for LLMs in order to vibecode the continued development of Claude
Code, but it doesn't deliver the experience I'd like. The
frameworks they've chosen also have limitations around [terminal
input parsing (i.e. the shift enter issues from last year:
https://github.com/anomalyco/opencode/issues/1505#issuecomme...).
Great terminal interfaces I've lived with for years (neovim, btop,
helix, Cataclysm DDA, etc) don't sacrifice user experience as a
tradeoff for development convenience. They build resilient terminal
interfaces on languages more appropriate for this problem, like C
or C++ or Rust. Finally, while I'm definitely rooting for
Anthropic to continue improving their products, I can't see myself
coupling a commandline tool I use often with a single LLM provider.
It would be insane if pushing my code to GitHub required me to edit
it in VSCode -- I want my tooling to do one thing well, and that's
display the read-eval-tool-loop from talking to an agent. Opus 4.5
has been stellar, but it's nonnegotiable to me that I can try out
varied providers with the same tools I plan to use everyday. Claude
Code will not be working long term on how best to interface with
multiple agents, from varying providers, in one terminal pane, and
that makes perfect sense for their business. However based on our
other experiences building out profiles and skillsets for agents,
deeper customizations of agent instructions and subagents, and
parallel worktrees for local agents, we have a lot of vision for
how to handle local agentic work. And with the current design to
integrate at the agent-level, we don't plan on working around the
OAuth flows or spoofing the system prompt outside of the Claude
Code SDK (like with the OpenCode situation), and risk the tools
coming into conflict with the providers. These were the main
considerations that went into designing Nori CLI. It's a very thin
and very fast TUI wrapper around multiple agent providers. It
integrates with providers at the agent level, instead of the model
level. Not only does that provide better performance in our
experience, but that is also *compliant with current ToS for
subscription based usage.* This is a very early version, but given
the timing this week it might give you a flicker-free way to code
with Claude Code! The project is open source, and built on the
stellar work by folks at Zed (on the abstraction over varied coding
agents), and the folks working on Codex CLI (who have put together
one of the nicest proprietary terminal experiences). I'm very
curious: What are the Claude Code features you couldn't give up, to
make the switch to a tool like this? What are the Claude Code
features that work as intended, but you can't stand?
Author : csressel
Score : 21 points
Date : 2026-01-14 14:40 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| maphew wrote:
| On the flicker free console as well as agent agnostic front, also
| see BatrachianAI's Toad (https://github.com/batrachianai/toad).
| Maybe you two should/could collaborate.
| csressel wrote:
| good callout, I've seen Will McGugan's work on textual and rich
| before and that really pushed forward the Python+terminal
| ecosystem in the past five years. I've seen a lot of CLI tools
| coalesce on the rust and go ecosystems, for various reasons
| (uv, fzf, helix, just, etc). But I didn't know toad had gone
| open source now, very excited to check it out!
| maphew wrote:
| my ulterior motive: I use some of Nori skills, and also toad,
| ampcode, codex, kilocode, and... I want to reduce my tool
| noise. ;-)
| csressel wrote:
| our vision with Nori CLI is to smooth the headache of
| hooking in skills and other customizations into _any_ agent
| that 's running under the hood, which I think is exactly in
| line with that. I see that Toad is also built on top of the
| ACP approach, so there's definitely an overlap or possible
| integration
___________________________________________________________________
(page generated 2026-01-14 23:01 UTC)