limoni

Quick start

go get github.com/thebanri/limoni

package main

import "github.com/thebanri/limoni"

func main() {
	limoni.Run(func(f *limoni.Frame, ev *limoni.Event) bool {
		if ev != nil && ev.Type == limoni.EventKey && ev.Key.Type == limoni.KeyEsc {
			return false // quit
		}
		f.RenderComponent(limoni.Border(
			limoni.Center(limoni.Label("Hello from Limoni 🍋  (Esc quits)", limoni.Bold())),
			limoni.SymbolsRounded,
			limoni.Fg(limoni.Hex("#FFCC00")),
		), f.Area())
		return true
	})
}

Or generate a project that runs straight away, with a test already written:

go run github.com/thebanri/limoni/cmd/limoni@latest new myapp    # -template counter|dashboard|form|ssh
cd myapp && go mod tidy && go run .
go test ./...                                                     # a uitest test comes with every template

Next: Getting started · Widget gallery · Examples

Why Limoni

1. Your TUI has a semantic tree, so tests and agents address widgets by name

Most terminal automation, such as termwright or mcp-tui-test, parses the rendered character grid, so a test breaks when the layout moves by one column. A Limoni app builds a semantic tree every frame (the same tree a screen reader uses), and the tools below work on that tree instead.

uitest: Playwright-style tests. Checks wait instead of sleeping, and a failure prints the whole tree of the last frame.

page := uitest.Run(t, 80, 24, app.draw)            // in process: no terminal needed

page.GetByRole("input", "New task").Type("Tag v1.0")
page.GetByRole("button", "Add task").Click()
page.Expect(page.GetByRole("list-item", "").Within(page.GetByRole("list", "Tasks"))).ToHaveCount(3)
page.Expect(page.GetByID("status")).ToContainLabel("Added")

limoni-mcp: let an AI agent drive the app. It gives Claude Code, Cursor or any MCP client eight tools (tree, click, type_text, wait_for…) that work on the same tree. In one recorded run, Claude Code completed a release checklist in 17 tool calls. That run included typing a deploy token the agent could not read back.

go run -tags limoni_debug ./examples/agent_checklist
claude mcp add limoni -- limoni-mcp -socket "$XDG_RUNTIME_DIR/limoni-checklist.sock"

The automation socket only exists in -tags limoni_debug builds. It is closed by default, only the same user can connect, and secret fields are never exposed. → Semantic automation, MCP and uitest

2. Fast where you can feel it

• Zero heap allocations per frame for the renderer, every widget's drawing, and the click handling of the common input widgets, enforced in CI, so animations don't stutter from GC pauses. Widgets with drag or custom handlers (Table, Slider, Dialog, …) still allocate a closure each. The details.
• Few bytes per frame. Blank runs become ECH/EL and repeats become REP: a full-screen redraw is 377 bytes, and an idle app sends nothing. Bytes, not CPU, are what you feel over SSH.
• Virtual tables and lists. One million rows scroll at ~2.7 ms a frame, because only visible rows are touched.

Absolute numbers depend on the machine. The comparisons against Ratatui 0.30.2, Ultraviolet and Bubble Tea v1.3.10, including which ratios are not meaningful, are in docs/benchmarks.md and the methodology. One earlier run showed a 4,700× lead; it came from a bug in the benchmark harness, and the methodology explains how it was caught.

3. Batteries that other TUI libraries leave to you

The only dependencies are golang.org/x/sys and golang.org/x/crypto.

Is Limoni the right choice?

Pick Limoni if you are writing a terminal app in Go and any of these matter:

• You want to test the UI, or let an AI agent use it, by widget role and label rather than by screen coordinates (uitest, limoni-mcp).
• It redraws a lot: dashboards, log viewers, monitoring, games, animation, anything over SSH. The draw path makes no garbage and sends few bytes.
• It needs things other libraries leave to you: 3D models, images, charts, markdown, a million-row table, screen-reader support, WebAssembly in the browser.
• You want both styles in one library: immediate mode (limoni.Run) for dashboards, the Elm architecture (limoni.RunProgram) for forms and wizards.
• You want a small dependency tree: golang.org/x/sys and golang.org/x/crypto.

Pick something else if:

• You need a stable 1.0 API today. Limoni is pre-1.0 (see Status).
• You rely on the Charm ecosystem (Bubbles, Huh, Glamour, Wish) and its community. Bubble Tea is the larger and older project. If you already have a Bubble Tea app, compat/bubbletea runs your models on Limoni (migration guide), so you can try it without a rewrite.
• You are writing Rust: use Ratatui.
• The app is a one-shot prompt (a single question, a spinner): a small prompt library is less to learn.

A feature-by-feature table against Bubble Tea v1/v2 and Ratatui 0.30 is in docs/comparison.md.

Built with Limoni: zest

zest is a log viewer and Limoni's flagship app. It follows files and pipes, colours by level, and filters a million lines without stalling. A 67 MiB, 1,000,000-line log is on screen in about half a second.

go install github.com/thebanri/limoni/cmd/zest@latest
zest -demo 1000000        # or: zest app.log, kubectl logs -f pod | zest

Or try it in the browser: the "Logs · zest" scene.

And: globe

globe is a world you can turn, search, zoom into and pin — and what a Limoni application looks like from the outside, since it is a module of its own that depends on a published Limoni and uses nothing but its public API.

go install github.com/thebanri/limoni/apps/globe@latest
globe -at Türkiye

go install puts the binary in $(go env GOPATH)/bin — ~/go/bin unless you changed it — which a fresh Go install does not add to your PATH. If globe is "command not found", add that directory to PATH or run ~/go/bin/globe.

Everything on it is in the semantic tree, so "find Turkey on the world map" is something an agent can do over MCP: type into search, click the