Add a provider

A provider is how Vibestrate reaches a model - almost always a command-line tool already on your machine. The detector knows eleven, so most of the time you add nothing.

Open the dashboard with vibe ui (127.0.0.1:4317), go to Crew, and switch to the Providers tab. Every detected CLI is a card: Install if it is missing, Set up if it is detected but unconfigured, then Test, Set default and Edit. Under Cloud APIs & local model servers the same tab has Add cloud API, Add local server and Custom CLI.

You write config by hand when you want the file under version control, or when you are scripting.

Three sections: Popular (the first-class set, detected and ready to bind), Optional (detected, never auto-bound), and Cloud APIs & local model servers (anything driven over HTTP rather than a process).

Every card carries the same actions, and setting one up opens a single editor where command, args and input are composed, tested and saved together.

When a test says a provider is not authenticated, the card prints the login command and stops. Vibestrate never logs you in - you run codex login, or the bare command, in your own terminal.

vibe shell has no providers screen; its Profiles page cycles models and effort for providers already configured.

The Custom CLI button writes this block for you. By hand, add providers: to project.yml. Here my-model is the id you give this provider, my-coding-cli the command Vibestrate runs:

providers:
  my-model:
    type: cli
    command: my-coding-cli
    args: [--prompt-on-stdin, --no-color]
    input: stdin           # stdin | arg

input is how the prompt reaches the CLI, and it takes one of exactly two values:

There is no workingDir to set. Vibestrate always runs the CLI in the run worktree, the isolated copy of your repo it works in.

A provider does nothing until a Profile names it and a Role runs on that Profile. There is no top-level agents: key - roles live under crews.<crewId>.roles:

profiles:
  my-model-default: { provider: my-model }

crews:
  default:
    roles:
      reviewer:
        seats: [reviewer]
        profile: my-model-default
        prompt: .vibestrate/roles/reviewer.json
        permissions: read_only

In the dashboard the Crews tab does the second half: open a crew and set profile on the role card. For a single run, point at a Profile that names the provider:

vibe run "..." --profile my-model-default

Test on the card sends a safe prompt and reports back. From a terminal that is vibe provider list, then vibe provider test my-model.

A failing test is almost always one of these:

• The CLI expects a flag you did not pass.
• The CLI exits non-zero when there is nothing to do. Some will not talk without a model selected.
• input is wrong. Try the other one.

For Claude Code under a custom invocation, use the claude-code type instead of cli:

providers:
  claude-experimental:
    type: claude-code
    command: claude
    args: [-p, --model, claude-sonnet-4-6]

That type unlocks deeper integration: a reported session id, tracked token usage, and session resume.

The other two types take an HTTP endpoint rather than a command. localhost-proxy is for a server on your own machine, like Ollama or any OpenAI-compatible local runtime; http-api calls a remote endpoint, the one type that leaves your machine. Add local server and Add cloud API write these.

providers:
  ollama-local:
    type: localhost-proxy
    api: ollama                # or: openai
    baseUrl: http://localhost:11434
    model: qwen3.5

  anthropic-api:
    type: http-api
    api: anthropic             # or: openai
    baseUrl: https://api.anthropic.com
    model: claude-sonnet-4-6
    # an env reference, never a literal key
    apiKey: env:ANTHROPIC_API_KEY

The schema draws the line. A localhost-proxy needs a baseUrl resolving to localhost; an http-api needs https and must not be loopback. A key written out in full is rejected outright, so it cannot reach your git history.

A provider’s job is deliberately narrow.

• Two providers on the same CLI sharing an id. Give them distinct ids, like claude and claude-fast.
• Putting API keys in args. Use whatever auth flow the CLI itself supports.

• Provider (concept) - what a provider is and where it fits.
• Provider reference - every field and type, in full.