The Question That Has to Be Answered First
A family that already talks to models through several vendor harnesses does not need another window. Those products already run a loop, already call tools, already keep a transcript, already ask before a dangerous command. If Firebrand were a prettier launcher over the same sessions, it would be a waste of a year.
The founding refusal is blunt. If we were going to be vendor-dependent, why build it? The vendor harnesses already work. Reinventing their window is not a product. Owning the loop, the tools, the record, and the permission decision is.
Two Jobs, Neither Optional
The first job is ownership without vendor gravity. A frontier harness is allowed to change its wire, its login, its pricing, or its shutdown date. That is their right. It is a bad place to keep the only copy of how the family delegates coding work. Firebrand keeps an attachment point that still boots when the only reachable model is a local daemon with no account at all.
The second job is a laboratory. Using a harness teaches you how to type at one. Building one teaches you what a step is, what a cut is, what a permission unit is, and what happens when a small model emits a tool call that is not actually a tool call. Those questions have no answer you can rent.
What This Quest Will Not Do
It will not teach you to beat those vendor products, or to stop using them. They remain the canonical homes of their own brains. Firebrand exists so the family can attach models that are not harness-bound, and so the family can measure harness ideas instead of only consuming them.