Skip to main content
The Settings page manages LLM provider credentials, platform defaults, and MCP connection configuration. All settings persist in a local SQLite database with credentials stored securely in the OS keyring.

​
Providers Section

Add and manage LLM provider credentials. Multiple providers can be configured for redundancy or model variety.

​
Provider Table

Displays all configured providers with status and action buttons:
  • Provider: Name (e.g., “anthropic”, “openai”)
  • Status badge: “configured” (green)
  • Actions:
    • Edit: Modify API key or base URL
    • Test: Validate credentials with a simple API call
    • Delete: Remove the provider

​
Add / Edit Provider Form

Provider dropdown: Select from available providers:
  • Cloud providers (require API key):
    • anthropic
    • openai
    • groq
    • openrouter
  • Local providers (require base URL):
    • ollama (defaults to http://localhost:11434)
    • lmstudio (defaults to http://localhost:1234)
  • custom: Bring your own provider with custom API endpoint
Fields:
  • API Key (cloud/custom providers): Stored securely in OS keyring. Password input field for safety.
  • Base URL (local/custom providers): HTTP endpoint for the provider. Required for non-cloud models.

​
Provider Testing

Click Test next to a provider to validate:
  1. Network connectivity to the endpoint
  2. API key validity (if applicable)
  3. Model availability
Result appears inline (success/failure with message).
Test your providers after configuration to catch credential errors early. Testing is non-blocking; other settings can be configured in parallel.

​
Provider Deletion

Click Delete to remove a provider. If it’s set as the default, you’ll be prompted to select a new default before deletion completes.
Deleting a provider doesn’t affect past runs. Historical results remain accessible; only future runs will be blocked if using that provider.

​
Defaults Section

Configure platform-wide defaults for workflows that haven’t specified explicit values.

​
Display Mode

When defaults are set, a read-only table shows:
  • Provider / Model: Display of currently selected provider and model variant
  • Audit Transport: Default MCP transport (stdio, sse, or streamable-http)
  • IPI Callback URL: Default listener endpoint for indirect prompt injection tests
Edit button: Switch to edit form. Clear button: Remove all defaults.

​
Edit Form

Fields available for configuration:
  • Provider / Model: Dropdown selector populated from configured providers.
    • Selecting a provider populates available model variants.
    • Example: provider=“anthropic”, model=“claude-3-5-sonnet”
  • Audit Transport: Select default transport for MCP connections.
    • stdio: Invoke command; used by default in Launcher forms
    • sse: Server-Sent Events over HTTP
    • streamable-http: HTTP streaming protocol
  • IPI Callback URL: Listener endpoint for callback-based indirect prompt injection tests.
    • Example: https://your-domain.example.com/callback
    • Can be overridden per-run in the Launcher

​
Saving Defaults

Submit the form to save all values. UI automatically switches back to display mode on success. Changes apply immediately to new workflow runs.
Defaults don’t affect already-running workflows. In-progress runs use values set at launch time.

​
Infrastructure Section

Configure MCP server and connection parameters for advanced scenarios.

​
MCP Connection Settings

  • MCP Connection Type: Select how the UI connects to MCP servers during testing (stdio, sse, streamable-http)
  • Custom MCP Endpoint (optional): For advanced deployments, specify a custom MCP server to connect to instead of the built-in one
Leave these at defaults for typical use. Advanced configurations are needed only for:
  • Multi-machine deployments
  • Custom MCP server implementations
  • Load-balanced MCP clusters

​
Bridge Token Management

The internal bridge token is used for secure communication between the UI and backend. It’s automatically generated and cached in memory; no manual intervention is needed. To rotate the bridge token:
  1. Stop the server (Ctrl+C)
  2. Delete ~/.qai/bridge.token
  3. Restart with qai
A new token is generated on next startup.

​
Data Persistence

All settings are stored in the local SQLite database (~/.qai/qai.db). This includes:
  • Provider configurations (API keys in OS keyring, metadata in DB)
  • Workflow defaults
  • Run history and results

​
Backing Up Settings

Stop the qai server before copying the database to ensure a consistent snapshot: 
# Stop the server first (Ctrl+C in the terminal, or kill the process)
pkill -f 'qai' || true

# Copy the main DB and WAL/SHM files if present
cp ~/.qai/qai.db ~/backup-qai.db
cp ~/.qai/qai.db-wal ~/backup-qai.db-wal 2>/dev/null || true
cp ~/.qai/qai.db-shm ~/backup-qai.db-shm 2>/dev/null || true
Restore from backup: 
# Stop the server first
pkill -f 'qai' || true

# Restore all DB files
cp ~/backup-qai.db ~/.qai/qai.db
cp ~/backup-qai.db-wal ~/.qai/qai.db-wal 2>/dev/null || true
cp ~/backup-qai.db-shm ~/.qai/qai.db-shm 2>/dev/null || true

# Restart the server
qai
SQLite WAL mode uses -wal and -shm companion files. Copying only qai.db while the server is running can produce a corrupted backup. Always stop the server and include all three files.

​
Credential Storage

API keys and sensitive credentials are stored in the OS-level keyring:
  • macOS: Keychain
  • Linux: Secret Service or pass
  • Windows: Windows Credential Manager
The database stores only provider metadata (name, type, base URL). Keys are never written to disk in plain text.
If the OS keyring becomes unavailable (e.g., locked, not initialized), credential operations will fail. Unlock your keyring or reinitialize it according to your OS.

​
Syncing with CLI

Settings configured in the Web UI are immediately available to CLI commands and vice versa. Both use the same database and keyring. Example workflow:
  1. Configure a provider in the Web UI
  2. Use it in a CLI command: qai inject campaign --model anthropic/claude-sonnet-4-20250514
  3. Return to Web UI; the provider is already available for selection

​
Resetting Settings

To completely reset settings:
  1. Remove the settings database: rm ~/.qai/qai.db
  2. Restart the server: qai
A fresh database is created with no defaults or providers configured.
Deleting qai.db only resets the database — provider API keys stored in the OS keyring are not removed. To fully clear credentials, manually remove provider entries from your system keyring (via your OS keyring manager or the keyring CLI) after deleting the database.
Use this approach if you encounter credential issues or want to start fresh. Your run history will be lost; export results before resetting if needed.