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
| Area | Decision |
|---|---|
| Language / runtime | TypeScript on Node (developed on v26; node:sqlite is built in) |
| Topology | Client/server. The core is an HTTP server; titah spawns a local one and attaches the TUI to it |
| Protocol | HTTP REST for client→server, SSE for server→client |
| Storage | SQLite for metadata and messages; large blobs on disk with a pointer in the DB |
| Providers | AI SDK v7. Any OpenAI-compatible endpoint is first-class; Anthropic and OpenAI are presets |
| Config | JSONC with $schema, global merged with per-project |
| Distribution | One npm package, titah-code; it installs the titah command |
| Platform | Linux and macOS. Windows is not supported in v1 |
| Licence | Apache-2.0 |
| Verification | 1,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.
What to read next
- Installation — requirements and the three ways to install.
- Quickstart — first session in under five minutes.
- Configuration — where config lives and what it holds.
- Delegation — the differentiator, in detail.
- Structured output — using Titah from a script or CI.
- Architecture — the design decisions and why they were made.