One chat can't ship real work.
A single model is great for a sketch. On real work you end up doing the orchestration yourself: re-pasting context into a tool that has never seen the project, carrying the plan from one chat to the next, watching for drift. Vibestrate runs a crew of agents through a supervised flow instead, so a brief becomes a planned, multi-model run you watch, approve, and audit.
How a run works
Hover a step to open it.
You write what you want in plain English. That brief is the entry point to a run.
A flow is a reusable recipe of phases (plan, build, review, verify, and more). Pick one, or pull one from the hub.
Each phase gets a seat. You fill the seats from eleven built-in providers (Claude Code, Codex, Gemini, OpenCode, Aider, Cursor CLI, Amp, Goose, Crush, Qwen Code, and local models via Ollama) so the right model runs the right phase.
The phases execute in order, and each agent's output (the plan, the diff, the findings) is handed to the next one.
Explicit gates pause before risky steps and after the work is done. You approve, send it back, or let an automated check decide.
Every prompt, diff, token, and dollar lands on a local ledger you can read and replay, step by step.
Rules the run has to obey
Telling a model "stop using em-dashes" works right up until the run where it doesn't, and you can't audit an instruction the model only agreed to. Write the rule down once, at the project level, and every run gets checked against it, whichever model is in the chair.
The reviewer reads your rule next to the diff. If the diff breaks it, the reviewer flags it and it goes through the normal review-and-fix loop, like any other finding.
Judgment calls. "No eyebrow labels." "Match our design language." "Don't over-engineer this." A model catches the paraphrase a regex would miss.
A deterministic matcher over the run's changed lines. If it matches, the run lands blocked with the reason shown, even if the reviewer approved it.
Rules with a shape you can name. A matcher does not get talked out of anything, and it does not forget three steps later.
Only you can create a block. The supervisor can propose a rule from a consult, but only at the advise tier, and it waits as a proposal until you confirm it. A model can't write its own merge blocker. The gate also fails closed: if it can't read the diff, it blocks rather than waving the change through.
Yours, on your machine
- Local-first. The orchestrator runs on your machine. No cloud relay sits between you and your models.
- Your keys, your models. Credentials stay in the vendor CLIs you already use. Vibestrate never stores or transmits them.
- You approve. Nothing pushes or merges until you sign off at a gate.
- No telemetry. The tool does not phone home. The ledger stays local.
Questions
A single chat is fine for sketches. For real work, Vibestrate runs a flow of specialized agents: by default a planner, an implementer and a reviewer, and in the deep flow an architect, a fixer and an independent verifier as well. Each phase goes to the model you picked for it, the run pauses for your approval between phases, and every token, dollar and decision lands in a ledger you can replay.
Any CLI-driven model. Eleven built-in providers: Claude Code, Codex, Gemini, OpenCode, Aider, Cursor CLI, Amp, Goose, Crush, Qwen Code, and Ollama for local models (LM Studio and llama.cpp connect over a localhost proxy). Any binary that streams structured output can be added. There is no proxy layer - you log in once per vendor with your own key.
Yes. Vibestrate separates the flow from the crew. The flow defines phases, gates, validators, and handoffs; the crew defines which model sits in each phase. If one model becomes unavailable, overpriced, or weak for the task, you can swap that seat and keep the process.
No. The orchestrator runs as a single local process on your machine and drives the vendor CLIs as child processes. Vibestrate never proxies your code through a hosted service.
No. Your vendor credentials live in the vendor CLIs (claude, codex, gemini, ollama), the same place they lived before. Vibestrate spawns those CLIs as child processes and reads their output. It is not in the middle of the connection to any model vendor.
Yes. You write a project policy once and every run is checked against it. An advise policy is carried into the reviewer, so a violation gets flagged and fixed in the normal loop. A block policy is a deterministic matcher over the run's changed lines: if it matches, the run lands blocked with the reason, even if the reviewer approved the diff. Blocks are owner-only. The supervisor can propose a rule, but only ever at the advise tier, and only you can confirm it.
Yes. Vibestrate is Apache 2.0 and free to use. You pay only for the models you choose to run.
