Skip to content
titah

Getting started

Introduction

Titah is a coding agent CLI with its own LLM loop, tool set and session storage — and the ability to hand a question to another agent CLI and bring the answer back.

Titah is a coding agent in its own right. It has its own agent loop, its own tools, its own permission engine and its own session storage. What sets it apart is one extra capability: it can delegate a question to claude, opencode, or any other agent CLI installed on your machine, and bring the answer back into the conversation — including consensus mode, where one question is fanned out to several agents at once, synthesised, with the disagreements marked.

Status

0.7.0, usable. Milestones M0 through M6 are complete. Releases after 0.2.0 added project tracking, session sync, and the extension system: side panels contributed by npm packages, a registry to find them, and a version check that refuses the ones that would not load. 0.5.0 was about moving around the terminal — a cursor that walks visual rows and words, tool blocks that open by default, and a full-page transcript for any sub-agent. 0.6.0 turned each side panel into a stack of foldable boxes, and 0.7.0 moved the extension version check onto the API version, so a Titah minor bump stops killing every installed extension. Anything below 1.0 may still move under you.

What remains before v1.0.0 is not code: using Titah to build Titah for a full week. That is the only test that finds the defects a test suite does not. See the changelog.

What Titah is not

It is not a wrapper over other agents. Remove claude and opencode from the machine entirely and Titah still works in full — you lose delegation and consensus, and nothing else.

It does not redistribute, bundle, or bypass any other agent. It spawns the CLI you installed, with your own credentials, as an ordinary subprocess — exactly as if you had typed it in your terminal. If an agent is not installed, Titah reports it as unavailable and keeps working without it.

The shape of it

AreaDecision
Language / runtimeTypeScript on Node (developed on v26; node:sqlite is built in)
TopologyClient/server. The core is an HTTP server; titah spawns a local one and attaches the TUI to it
ProtocolHTTP REST for client→server, SSE for server→client
StorageSQLite for metadata and messages; large blobs on disk with a pointer in the DB
ProvidersAI SDK v7. Any OpenAI-compatible endpoint is first-class; Anthropic and OpenAI are presets
ConfigJSONC with $schema, global merged with per-project
DistributionOne npm package, titah-code; it installs the titah command
PlatformLinux and macOS. Windows is not supported in v1
LicenceApache-2.0
Verification1,242 tests, no live LLM calls

Why client/server from day one

Splitting a monolith into client and server later is open-heart surgery. Starting from a server is cheap and immediately opens the door to attach, a web UI, and remote use. To you it still feels like one process, because titah spawns its own server on a random port and connects to it.

That decision is also what makes the core testable. curl is a client too — the entire agent loop can be exercised with no TUI in the picture, which is the difference between a ten-minute debug and a two-hour one.

Why SQLite plus blobs on disk

The opencode install on the development machine had a 580 MB opencode.db while every other directory held a few hundred kilobytes. Agent transcripts are dominated by tool output — file contents, grep results, build logs — that nobody reads again after the turn ends.

Titah separates blobs from the database from the start, and ships retention (titah sessions prune) in v1. Adding retention after someone already has a 600 MB database is too late.