One companion, several AI applications

Sharh, Lineleaf, TabBeam and Shoora do different jobs: reading, writing, asking about a web page, and comparing models. Underneath, they need the same plumbing: find an installed AI provider, start a request, stream the output, cancel it, and recover when something fails.

Seatline is that plumbing, written once in Rust. It began as TabBeam’s provider runtime and was extracted into its own repository.

Where the boundary sits

Seatline runs the providers’ own command-line tools (Codex, Claude Code, Gemini through Antigravity, and Grok) with the accounts the user is already signed in to. It handles processes, streaming, scheduling, private working files, and which app may use what. Each app keeps its own prompts, conversations, interface and product decisions.

One install, no open port

A single companion installation serves all of them. It opens no listening port: apps on the machine talk to it over a private local socket, and web apps such as Shoora reach it through an outbound, encrypted relay.

Local coordination does not make the models local. A prompt sent to a hosted provider still leaves the device, and the apps should make that clear when the user chooses what to share.

Measure before optimizing

A slow answer can come from app startup, provider preparation, the model itself, or the delay between the final answer and the process exiting. Seatline records timings for each phase and has a benchmark harness for comparing runs, so effort goes to the layer that is actually slow.

Where it stands

Seatline is pre-1.0, and apps pin it to an exact commit. Sharh has its readers, analysis engine and evaluation harness in place, with live quality checks still to do. Shoora’s web app and its four providers work. TabBeam and Lineleaf are at the foundation stage.

Seatline’s architecture and companion