Runs on the box
Planning, routine implementation, review, and QA run on local models — 70B-class on the client's own hardware. Nothing leaves.
Raptor runs a software task through a crew of agents — a planner, workers, a reviewer, a QA gate. Most of it stays on local models. When a task is too hard, or too sensitive to send anywhere, the Escalation Boundary decides what happens next. Submit a job below and watch it route.
Local models are fast, private, and cheap, and they handle most of the work. But some tasks need a frontier model's reasoning — and some specifications are too sensitive to leave the building at all. Raptor's Escalation Boundary is the component that holds both truths at once: it routes by difficulty and by classification, so a sensitive task never escalates off-site even when a harder one would. On an air-gapped deployment, the boundary's answer to "escalate?" is simply always no, and the pipeline is built to finish anyway.
Planning, routine implementation, review, and QA run on local models — 70B-class on the client's own hardware. Nothing leaves.
Hard reasoning can escalate to a frontier model — but only for tasks the classification policy permits. Sensitive specs never qualify.
Every job writes to a STATUS.md the way a human team writes to a standup — who picked up what, what passed review, what bounced off QA, where a task escalated and why. The rail on the console is that file, updating as work moves. Raptor is built to be watched, not just run.