Provider

A Provider is what actually runs a model. Vibestrate writes the prompt; the provider returns the answer, plus the file changes when it can edit files.

Most providers are coding-agent CLIs you already installed and logged into. Vibestrate does not hold your API keys and never logs you in: it spawns the tool you use anyway.

The Providers tab on the dashboard’s Crew page is where they live. Two tiles count what is detected and what is configured; the cards group into Popular, Optional, and Cloud APIs & local model servers. Each carries Set up or Edit, Set default and Test, plus Install when a popular CLI is missing.

Counted by how many profiles point at them.

Declared under providers: in project.yml:

Only one of the four reaches the network:

This is what keeps the tool local-first, where local-first means sovereignty, not zero-egress: there is no Vibestrate-operated backend or relay, so you run an independent tool you fully control. Pointing a provider at a model API with your own key is your choice, and does not change that guarantee, because nothing ever flows through a service we run.

Eleven CLIs ship with Vibestrate. The five under Popular are configured the moment they are detected, because their flags are stable enough to drive without surprises:

The six under Optional are detected but never auto-bound. Set up on the card wires one into this project:

Each one’s command, preset args and login step are in the providers reference, generated from the same table the detector reads.

Set up and Edit open the same editor: the command, its args, how the prompt is fed in, a live preview of the YAML that will be written, and Save & test so the fix-and-check loop stays on one screen. Edit as YAML switches it to Advanced - raw provider YAML for anything the form does not surface - environment variables, claude-code settings, extra args, custom headers - seeded from the saved config and validated on save. Remove deletes the provider from project.yml.

A CLI Vibestrate ships no preset for goes in through Custom CLI, in the third section’s header. Fixing or setting up a provider is fully doable in the dashboard, without dropping to vibe provider setup. Authentication is the one exception by design.

One mistake worth naming: setting up the same provider twice. If Claude Code is your claude id, do not add a claude-pro and a claude-haiku unless the flags actually differ. One provider, several profiles.

By default your own Claude Code environment applies inside a run: your global CLAUDE.md, hooks and memory load exactly as they would in your terminal. That is deliberate - the model you tuned is the model that works your runs.

Hooks are the customization most likely to surprise you. A personal UserPromptSubmit “supervisor” hook fires inside every run turn, injecting into prompts and skewing reviewer verdicts. So vibe doctor flags when your ~/.claude or project .claude hooks will load inside runs and a claude provider is not using safe mode. It reports only the hook event names and the settings file, never the hook commands.

For hermetic turns instead - only the prompt Vibestrate compiled, plus the skills and MCP servers it attaches explicitly - set settings.safeMode: true on the provider. It adds --safe-mode, which disables personal customizations while auth and permissions keep working.

A claude-code provider also streams by default (--output-format stream-json --verbose --include-partial-messages) so the live transcript shows the model working token by token. Set settings.outputFormat to take manual control.

Add cloud API and Add local server on the Providers tab create the two HTTP-backed kinds. Both blocks are the same shape - a type, an api family, a baseUrl and a model - and only the cloud one takes a key:

providers:
  # Cloud API - your own key, external destination.
  anthropic-api:
    type: http-api
    api: anthropic       # or: openai
    baseUrl: https://api.anthropic.com
    model: claude-sonnet-4-5
    # env-ref ONLY - never a literal key
    apiKey: env:ANTHROPIC_API_KEY

  # Local model server - no key, no egress.
  ollama-local:
    type: localhost-proxy
    # or: openai, for OpenAI-compatible servers
    api: ollama
    baseUrl: http://localhost:11434
    model: qwen3.5

Rules the schema enforces:

• http-api must be https and not a localhost host; its apiKey must be an env:NAME reference, and a literal key in config is rejected. The key is resolved at call time, never written to YAML, never logged, and redacted from any error. The dashboard marks these providers external.
• localhost-proxy must point at a loopback host (localhost / 127.0.0.1 / [::1]), so there is no egress. A key is optional.

Both report real token usage from the API response, not estimates. They run one request per turn with no session reuse: only claude-code reports a session id back, and every other provider is a fresh start per call.

Vibestrate ships a built-in capability catalog: per provider, the real models and effort levels and how each is applied (a CLI flag, a -c key=value, or an HTTP request-body field). The profile editors only offer knobs that are in this catalog, so you never set an effort the runtime ignores.

The Capability catalog panel at the bottom of the Providers tab shows the merged result and where each entry came from. Refresh from providers on that panel probes your configured CLI providers for their real models and efforts and writes the findings into an overlay for review. It is local only - each provider’s own --help or equivalent, no network and no API keys - and it gap-fills rather than overwriting a built-in spec or a hand-authored entry. Probing cloud /models endpoints is deliberately left out; that would mean egress with your key.

For a provider Vibestrate ships no spec for, declare its real knobs yourself in .vibestrate/providers-catalog.yml. The overlay merges over the built-in catalog, your entry winning per field, and feeds the spawn and every editor from the same source:

# .vibestrate/providers-catalog.yml
cli:
  mycli:
    models: [turbo, eco]
    # -> --model turbo
    model: { kind: flag, flag: --model }
    effort:
      levels: [eco, turbo]
      # -> --set reasoning=turbo
      apply:
        kind: config
        flag: --set
        key: reasoning
  gemini:
    # explicitly clear a built-in knob
    effort: null
http:
  openai:
    # add a model suggestion to this api family
    models: [my-finetune]

Omit a field to keep the built-in value; set it to null to clear it.

vibe shell has no providers page of its own, but its [4] Profiles page flags when an overlay is active and names each provider’s source, and r there runs the same catalog probe as the button.

The command line is the automation path:

vibe provider detect            # which coding CLIs are on this machine
vibe provider list              # what this project is configured to drive
vibe provider setup             # apply a preset, wire the flags
vibe provider set claude        # make it the default
vibe provider test claude       # safe smoke test; names the login command if needed
vibe provider remove mycli

vibe provider catalog           # built-in + overlay, with sources
vibe provider catalog --json
vibe provider refresh --dry-run # show what a probe would add, write nothing
vibe provider refresh --force   # also replace built-in / existing overlay entries
vibe provider refresh --probe-cloud  # ALSO ask cloud providers, over the network

vibe provider refresh reads your local CLIs and never leaves the machine. --probe-cloud is the exception, and the only part of a refresh that does: it asks each http-api or localhost-proxy provider for its model list at /v1/models (or Ollama’s /api/tags), using that provider’s own configured key.

The result is written into the catalog overlay under the API family - openai, anthropic, ollama - because that is how the catalog is keyed, so two providers on the same family share one list. Existing entries are left alone unless you pass --force. Model names are only ever suggestions: any model can be typed by hand, so a probe that fails costs you the suggestions and nothing else.

Provider commands manage the raw tools only. A profile wraps a provider with a model and an effort level, and a role in your crew runs on a profile - roles never name a provider directly. The annotated crew config shows all three blocks side by side.

CLI providers authenticate through their own login flow, so a literal API key never belongs in project.yml.

• Provider reference - generated from the detector’s own table.
• Extending: add a provider - wire up your own CLI.

Next: run is all of this working together on one task.