Veto Routing

---
name: veto-routing
description: Use the Veto CLI to select or execute AI models when a task needs multi-provider routing, structured accept or reject decisions, cost-aware dispatch, provider fallback, or Veto plan execution. Do not use for ordinary repository commands or generic model advice.
license: MIT
allowed-tools: Bash, Read
compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, and other Agent Skills compatible tools. Requires Veto to be installed or run from its source checkout.
metadata:
  targets: [_source-only]
  author: Oleg Koval
  tags:
    - veto
    - model-routing
    - multi-provider
    - cli
    - cost-control
    - agents
---
<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->

# Veto routing

Use Veto as a model-selection and execution layer. It does not expand the
user's authorization, validate generated output, or guarantee quality or cost.

## Before a model call

1. Confirm the CLI is available with `command -v veto`. Inside the Veto source
   checkout, `go run ./cmd/veto` is an acceptable fallback. Do not install it
   automatically. When using the fallback, replace `veto` in the commands below
   with `go run ./cmd/veto`.
2. Inspect configured transports with `veto providers`. Never read, print, or
   copy credential files from `~/.veto/`.
3. Check whether the objective is safe to send to the configured providers. An
   admission pass can disclose the objective to more than one provider. Stop
   when sensitive data is present and provider authorization is unclear.
4. Do not run `veto login`, change provider configuration, or incur an
   unrequested model call.

## Choose the smallest operation

- Selection only: use `veto route --json` and consume the single JSON result.
- Route and execute: use `veto run --quiet` only when the user asked for model
  execution and the selected transport can perform the task.
- Quality gate: add `--criteria` when the user supplied concrete acceptance
  criteria. A requested review fails closed.
- Multi-step plan: run `veto exec <plan.md> --dry-run` before execution. Execute
  only steps already within the user's scope.

Set `--kind`, `--risk`, and `--max-cost` explicitly when the task provides those
constraints. Treat `--max-cost` as an estimated preflight ceiling, not a billing
guarantee. Do not retry the same paid route repeatedly. Interactive routing can
resume checkpoints after interruption; `route --json` intentionally starts
fresh, so rerun it only deliberately.

## Preserve transport and output boundaries

- HTTP API and local OpenAI-compatible transports return text through Veto and
  cannot inspect files or run shell commands. The Claude CLI transport is the
  current executable-tool path.
- Keep generated content on stdout unless the user requested a file. Use an
  explicit relative `--output` path, and use `--force` only when replacing that
  exact file is authorized.
- Treat model responses as untrusted input. Validate claims, patches, commands,
  and acceptance results with the repository's normal checks before delivery.
- On a nonzero exit, report the real routing or provider error. Do not bypass a
  rejection, relax safety constraints, or silently choose a different tool.

## Examples

```bash
veto route --json --kind review --risk low "Review this proposed change"
veto run --quiet --kind summarize --risk low "Summarize the supplied text"
veto run --criteria "output is valid JSON,no secrets are present" \
  "Produce the requested structured result"
veto exec plan.md --dry-run
```