Hazumi News

Hi HN, I built webctl because I was frustrated by the gap between curl and full browser automation frameworks like Playwright.

I initially built this to solve a personal headache: I wanted an AI agent to handle project management tasks on my company’s intranet. I needed it to persist cookies across sessions (to handle SSO) and then scrape a Kanban board.

Existing AI browser tools (like current MCP implementations) often force unsolicited data into the context window—dumping the full accessibility tree, console logs, and network errors whether you asked for them or not.

webctl is an attempt to solve this with a Unix-style CLI:

- Filter before context: You pipe the output to standard tools. webctl snapshot --interactive-only | head -n 20 means the LLM only sees exactly what I want it to see.

- Daemon Architecture: It runs a persistent background process. The goal is to keep the browser state (cookies/session) alive while you run discrete, stateless CLI commands.

- Semantic targeting: It uses ARIA roles (e.g., role=button name~="Submit") rather than fragile CSS selectors.

Disclaimer: The daemon logic for state persistence is still a bit experimental, but the architecture feels like the right direction for building local, token-efficient agents.

It’s basically "Playwright for the terminal."

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?