Tyran

📖 Documentation ·
  Getting started ·
  Videos ·
  Architecture ·
  Releases

The more you use it, the better it gets.

What Tyran is

Your most expensive model just renamed a variable. In the same chat, it judged
an authentication boundary.

One chat, one model, every job — that is why the bill is high and the work gets
worse. The context fills up, the plan is somewhere in the scrollback, and
*"the tests pass"* is a sentence rather than something you can check.

You didn't install a tool. You hired a manager. You describe the work once;
he interviews you until the goal is unambiguous — batches of at most four
questions, each with his recommendation — turns the plan into tickets on a
board, and hands each piece to a dedicated subagent with fresh context and a
model tier matched to how hard that piece actually is. A good manager doesn't
put a principal engineer on a grep: a scout reads the repo on the cheap tier,
implementers take one story each on their own branch, the reviewer can never
bless a patch it wrote, and security review always gets the strongest tier — a
floor no cost profile or flag can lower.

That is a cost lever and a quality lever at the same time. The conductor holds
the plan and never accumulates its agents' transcripts, which is where the
tokens in a long session actually go; and an agent that never saw the last six
failed attempts cannot inherit them, so the second opinion is a real one.

Nothing you say is lost. Remember something halfway through a run and say
it — it doesn't land in the scrollback, it becomes a ticket. Every decision,
spawn, report, merge and open question is appended to a journal committed to
your repo, so a restart, a compaction and a colleague on another branch all
read the same thing.

It learns your repo while it works.…