LLM Configuration
VigilQA's agents use a large language model for generation and analysis. Three provider options are available: Anthropic Claude (default cloud), Mistral (alternative cloud), and Ollama (local / air-gapped).
Provider overview
| Provider | Mode | Setup required | Best for |
|---|---|---|---|
| Anthropic Claude | Cloud (default) | API key in Settings | Best generation quality; prompt-cached for speed |
| Mistral | Cloud | API key in Settings | Cost-effective alternative for high-volume generation |
| Ollama | Local / air-gapped | Self-hosted Ollama instance | Strict data-residency; no data leaves your network |
Anthropic Claude (default)
The default provider is Anthropic Claude (claude-sonnet-4-6). It is optimised for code generation and structured reasoning and uses prompt caching so repeated KB context is served from cache rather than re-tokenised on every pipeline call — reducing both latency and API cost.
To configure: go to Settings → LLM Configuration, select Anthropic, and paste your Anthropic API key. The model field defaults to claude-sonnet-4-6; you can override it with any Anthropic model ID.
llm:
provider: anthropic
api_key: ${ANTHROPIC_API_KEY}
model: claude-sonnet-4-6
Mistral (alternative cloud)
Mistral is available as a cloud alternative. It produces comparable generation quality at lower per-token cost, which makes it a good choice for teams running large KB regeneration jobs frequently.
llm:
provider: mistral
api_key: ${MISTRAL_API_KEY}
model: mistral-large-latest
What data is sent to the LLM?
During the generation pipeline, the following data is sent to the LLM:
- Your Knowledge Base scenario descriptions (titles, steps, expected outcomes)
- AppExplorer selector maps (DOM structure, element labels — not user data)
- Previously generated test case documents (for ScriptGen context)
Test execution results, application user data, and database contents are not sent to the LLM. Post-run agent analysis (ResultAnalyzer, FlakyDetector) uses structured rule-based logic supplemented by the LLM only for the failure classification text — not the raw response data.
All LLM interactions use data scoped to your project's KB and structural metadata. Customer application data (user records, PII, financial data) is never included in LLM calls. See the Security page for full data handling details.
Local LLM via Ollama (Enterprise)
Enterprise plans support routing generation agent calls to a local Ollama instance instead of the VigilQA-hosted model. This is designed for organisations in air-gapped or strict data-residency environments where KB content must not leave the organisation's network perimeter.
With local LLM configured:
- All generation pipeline LLM calls are routed to your Ollama instance
- KB content and selector maps stay within your network boundary
- Post-run agent classifications still use VigilQA-hosted logic unless the local option is also configured for analysis
Supported local models
| Model | Minimum VRAM | Generation quality |
|---|---|---|
| Qwen2.5-Coder-32B-Instruct | 24 GB | Best — recommended for production use |
| Qwen2.5-Coder-7B-Instruct | 8 GB | Good — suitable for smaller projects |
| Mistral-7B-Instruct | 8 GB | Acceptable — lower code generation accuracy |
Configuring Ollama
In Project Settings → LLM Configuration, select Local (Ollama) and provide:
- Ollama base URL — the URL of your Ollama API endpoint (must be accessible from VigilQA's execution environment or your private network peering configuration)
- Model name — the Ollama model identifier (e.g.
qwen2.5-coder:32b)
Contact engage@sentinelflux.in to set up network peering for private Ollama access.