AI for API testing that never leaves your machine.

Any model your runtime serves over an OpenAI-compatible /chat/completions endpoint. The model id is a free-text field, not a fixed list. What matters more than size is tool-calling: the chat sidebar works by calling tools (list flows, read a flow, run it, check drift), so a model without reliable tool support will talk but not act. Tool-capable tags such as llama3.1 or qwen2.5-coder are the ones to reach for. Flow generation is schema-validated before anything is written, so a weaker model tends to fail validation rather than write a broken file.

No. A local runtime authenticates with nothing, so the key field stays empty and Bandura sends no Authorization header. You need two fields: the base URL (http://localhost:11434/v1 for Ollama, http://localhost:1234/v1 for LM Studio) and the model id, because a local endpoint has no default model to fall back on.

Nothing from the AI features: prompts, flow contents, captured tokens, and response bodies all go to your localhost endpoint and nowhere else. Bandura sends no telemetry, and the licence check is offline against a public key compiled into the app. Two things are still true and worth stating. The app asks our public releases list once a day whether a newer version exists, which carries no information about you, your machine, or your flows, downloads nothing without you pressing the button, and is one switch in Settings away from off. And your flows' own requests go where you addressed them: point one at a staging API over the internet and that call is made.

Yes, and there are two seams rather than one. The OpenAI-compatible adapter targets the wire format instead of the vendor, so anything serving OpenAI-style /chat/completions works: a self-hosted inference server, a company-internal gateway, or a hosted endpoint such as OpenAI, Groq, OpenRouter, or Together. You give it a base URL, a model id, and a key if it wants one. Separately, Anthropic and Gemini have native adapters, because neither speaks the OpenAI wire format closely enough for a base-URL swap to work.

Yes. The CLI and the MCP server read the environment instead of Settings, so BANDURA_AI_BASE_URL plus BANDURA_AI_MODEL is the whole configuration. On a self-hosted runner the model can be served on the same host as the job, which means an ai-action suite runs with no third-party AI API in the pipeline at all. With nothing configured, only ai-action nodes fail; every other node type runs unaffected.

One dropdown, with three entries: Anthropic and Gemini have native adapters, and OpenAI-compatible covers everything else including your local endpoint. Keys are held per provider in your operating system's keychain (macOS Keychain, Windows DPAPI, libsecret on Linux), so moving between a local endpoint and a hosted one does not make you paste a key twice, and no key is ever written into settings.json or your workspace.

The /security/ page, which is written for a reviewer rather than a buyer: the complete list of what crosses the network and when, where flows, credentials and run history sit on disk, how the desktop app is sandboxed, and the answers most vendor questionnaires ask in the order they ask them. Pointing the model at localhost removes the data transfer that review usually turns on, but it does not remove the review.