Public beta · Go CLI · multi-provider

The model should earn the task.

Veto filters AI models by capability, task complexity, and estimated cost, then asks each viable model to explicitly accept the task before routing or execution.

brew install oleg-koval/tap/veto
veto route
$ veto route "review this pull request" --kind review

── filtering candidates ───────────
luna          pass
terra         pass
sol           pass

── asking models ─────────────────
luna          rejected
terra         accepted · 91%

→ selected: terra

Routing contract

Selection you can inspect.

Veto filters candidates first, before any model judges the task. Every admission result stays structured and scriptable.

01 / FILTER

Capability before confidence

Tool access, task kind, complexity, context, disabled models, and cost ceilings remove unfit candidates first.

02 / ADMIT

Models must explicitly accept

Surviving candidates return an accept/reject decision, confidence, estimated usage, and reasons your scripts can read.

03 / EXECUTE

Routing and execution stay separate

Use route for selection, run for one task, or exec for a multi-step plan.

04 / VERIFY

Acceptance reviews reject invalid results

Requested criteria do not pass when the review is unavailable, malformed, incomplete, or inconsistent.

How it works

One task. A rehearsed admission gate.

Illustrative route: Veto narrows the roster, asks the survivors, and only then hands execution to the selected model.

Sequence playing
  1. Task enters. An objective and its constraints become the routing input.
  2. Filters run first. Candidates lacking capability, exceeding the estimated cost ceiling, or violating constraints leave the roster without being asked.
  3. Viable models answer. Each survivor returns a structured accept/reject decision with confidence and reasons.
  4. One accepted model wins. Veto selects the first accepted candidate that clears the configured confidence threshold.
  5. Execution is explicit. Routing ends at the decision; run or exec starts the separate task.

Provider roster

Cloud, subscription, or local.

Each model connection keeps its real boundaries: API and local HTTP models are text-only; executable tools are never advertised where they are unavailable.

AnthropicOpenAIOpenRouterxAIOllamaLM StudioOpenAI-compatible
Honest beta boundary. Offline tests prove routing mechanics, packaging, and integrity checks—not account-specific model access, live pricing, or production calibration. Validate those claims with your own providers and workload.

Next: run veto verify-models, then follow the quick start with your own provider.