Bandura’s AI features run on a provider you choose and pay for directly. There’s no credit meter and no middleman; requests go from your machine to the endpoint you configure, on your terms. Everything else in Bandura works without any provider at all (including self-healing, which is deterministic and needs no AI).
There are three providers. All of them work on every AI surface (chat, the agentic tool-use
loop, flow generation, and ai-action nodes):
| Provider | What it talks to |
|---|---|
| Anthropic | Claude, natively. The default, and the best-tested path. |
| Gemini, natively. A Google AI Studio key and no other setup. | |
| OpenAI-compatible | Any /chat/completions endpoint: OpenAI, Groq, OpenRouter, Together, Ollama, LM Studio. |
The Google provider needs 1.0.0-rc.4 or newer, which both current builds are: the desktop app on
the download page and the @bandura/cli a plain npm i -g @bandura/cli installs. On
rc.3 and earlier the Settings dropdown offered Anthropic and OpenAI-compatible only, and
GEMINI_API_KEY was ignored by headless runs. Anthropic and OpenAI-compatible work on every
published build.
One code path covers everything in the last row, because they all speak the same wire format.
If your endpoint accepts an OpenAI-style /chat/completions request, Bandura can use it.
That includes one running on your own machine, where
nothing leaves it at all.
Pick a provider
-
Open Settings from the gear icon in the activity bar, or with ⌘,.
-
In AI provider, choose Anthropic (Claude), Google (Gemini) or OpenAI-compatible.
-
Google needs nothing but a key: its endpoint is fixed, so no Base URL field appears. For OpenAI-compatible, fill in the Base URL that does. Common ones:
Endpoint Base URL Ollama http://localhost:11434/v1LM Studio http://localhost:1234/v1Groq https://api.groq.com/openai/v1OpenAI https://api.openai.com/v1If a local endpoint is the plan, local LLM API testing covers which Bandura features hold up on small models and which want a frontier one.
-
Set the Model. It’s a free-text field with suggestions, not a fixed list; no dropdown could cover every model every endpoint serves, so anything you type is accepted. Left empty, Anthropic falls back to Claude Opus 4.8 and Google to Gemini 3.6 Flash; an OpenAI-compatible endpoint has no default, so name the model there.
Add the key
In the API key section, paste your key and click Save key.
The key is stored in your operating system’s encrypted store (Keychain on macOS, DPAPI on
Windows, libsecret on Linux), not in settings.json, not in the
workspace, never in Git. Remove key in the same section deletes it. Keys are held
per provider, so switching from Anthropic to Groq and back doesn’t make you paste anything
twice.
Anthropic keys come from the Anthropic Console and start with
sk-ant-; Google keys come from Google AI Studio and start
with AIza. Bandura checks those prefixes so a copy slip fails at the paste rather than mid-run.
The check applies only to those two: an OpenAI-compatible endpoint mints its own key format, and a
local model needs no key at all.
Which requests carry your key, what travels with them, and what never leaves the machine is written out request by request on the security page.
Test the connection
Test connection sends one tiny message to whatever you’ve configured and reports back. A
wrong base URL, a stale key, or a model id the endpoint doesn’t serve shows up here in a second
instead of 20 minutes later inside a chat turn or a CI run. A pass reads
Connected to <model> - replied "ok".
Anything else it can say, and what each message means, is on
AI provider troubleshooting. One thing to check first,
because it’s the most common: the base URL needs its path prefix. Bandura appends
/chat/completions, so Ollama is http://localhost:11434/v1, not http://localhost:11434.
Headless runs: CLI, CI, and MCP
The CLI and the MCP server have no Settings view, so they read
the environment instead. ANTHROPIC_API_KEY keeps working exactly as it always has; the
provider-neutral variables are new.
| Variable | Meaning |
|---|---|
BANDURA_AI_PROVIDER | anthropic, gemini (or google), or openai-compatible. Optional (see the rule below). |
BANDURA_AI_BASE_URL | Endpoint base URL for an OpenAI-compatible provider. |
BANDURA_AI_API_KEY | The key, whichever provider. Takes precedence over the vendor names. |
BANDURA_AI_MODEL | Model id. Empty falls back to the provider’s default. |
ANTHROPIC_API_KEY / ANTHROPIC_MODEL | The original Anthropic variables. Still work, unchanged. |
GEMINI_API_KEY / GOOGLE_API_KEY / GEMINI_MODEL | Gemini fallbacks. Either key name works. |
OPENAI_API_KEY / OPENAI_BASE_URL / OPENAI_MODEL | Fallbacks, so a shell already configured for OpenAI needs nothing new. |
A base URL alone selects the OpenAI-compatible adapter, and a bare GEMINI_API_KEY selects
Gemini, so you rarely need to set BANDURA_AI_PROVIDER explicitly. If both an Anthropic and a
Gemini key are exported, Anthropic wins: a shell that already worked should not change providers
the day you add a Google key for something unrelated. Pointing a CI job at Groq is two variables:
export BANDURA_AI_BASE_URL=https://api.groq.com/openai/v1
export BANDURA_AI_API_KEY=gsk_...
bandura run "flows/**/*.aether"If nothing is configured, ai-action nodes fail with a message saying so, and every other node
type runs unaffected; a suite with one AI node doesn’t become a suite that can’t run in CI.
What a provider gives you
- Generate flows with AI takes a sentence in and gives a runnable flow out.
- AI chat & ai-action nodes give you an agentic chat that can read, run, and propose edits to your flows, plus a node type that asks the model questions mid-run.
- Run a local model with Ollama covers the same features with no key, no vendor, and no traffic leaving your machine.
- Run flows in CI uses the same variables in a pipeline, with working workflow files.