Skip to main content
Vendo runs on any AI SDK LanguageModel. createVendo’s models slot is optional, and what you do with it decides which key gets spent. One rule explains most of this page: env keys are credentials, config selects. A provider key sitting in your environment does not pick a model. models on createVendo does. ANTHROPIC_API_KEY is what the @ai-sdk/anthropic provider you pass authenticates with, nothing more. Model credentials are real keys only. A coding-agent login (Claude Code, Codex) can help at init time, but it never serves product turns.

​
Bring your own model

Pass it. An explicit model always wins, in development and production alike, and the key its provider reads (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_GENERATIVE_AI_API_KEY, …) is the provider’s business, not Vendo’s:
Install the matching @ai-sdk/* provider and put its key in .env.local. That is the whole setup, and no Vendo key is involved.

​
Two models, two credentials

If you already ship your own agent loop, you have two model seats, and they do not share a key. Your loop keeps its own model and key. No Vendo key replaces it. Vendo’s internal turns (micro-app builds, the delegate) need a model of their own, and they will not borrow your loop’s.
  • Name Vendo’s model in the composition with models: { default: … }, and Vendo’s builds ride exactly that, whatever your loop uses.
  • Or leave the seat unset and set VENDO_API_KEY, which fills it with the Vendo Cloud gateway.
  • With neither, Vendo’s internal turns fail on first use and say so. An ANTHROPIC_API_KEY sitting in the environment for your loop does not quietly become Vendo’s model. That used to happen, and it meant your Cloud key was shadowed by a key you set for something else.
  • If your loop’s own model has no key on this machine, either set one or point your model at vendoModel() from @vendoai/vendo/server to ride the same ladder Vendo does.
The done-criterion for a BYO-agent install is a real chat turn that renders a Vendo tool output. vendo doctor cannot check your loop’s model.

​
Leaving the seat unset

Omit models and the runtime resolves one through vendoModel() (formerly devModel(), which remains as a deprecated alias). It walks two rungs and stops at the first one that resolves.
1

Vendo Cloud key

VENDO_API_KEY delegates to the Vendo Cloud model gateway (Anthropic Messages wire, served through the stock @ai-sdk/anthropic provider, which Vendo ships — the key alone suffices, and your app’s own install wins when present). On this rung the default model is vendo (the console maps it to a concrete model server-side); pin a different id with VENDO_MODEL. No key on hand? npx vendo login mints a free metered API key.
2

None

No credential resolves, and the first turn says exactly that:
Two rungs, and ANTHROPIC_API_KEY is not one of them. VENDO_DEV_CREDENTIAL pins a ladder rung, including the env-key rungs that nothing else can reach any more. It is internal — Vendo’s own E2E rung matrix and escape hatch, not a host knob, and it can change without notice. Pinning a rung that cannot resolve produces the same honest error as the none case.

​
The generated composition

The route init scaffolds calls createVendo() without a model, so the runtime resolves the ladder above on every turn. Init does not scaffold a model file. To pin a provider, add models to the composition with any AI SDK LanguageModel:
The handler contract does not change either way.

​
Verifying the model

Init does not run a live turn. vendo doctor sends one real model turn through the same ladder, so doctor and runtime agree on what is wired:
Exit 0 means a real user would have gotten an answer. A failed turn reports E-TURN-001.