AI providers and cost
Choosing a model, keeping code on-premise, and tracking what an engagement costs.
Every AI feature — AI Native SAST, reachability, dependency verification, secrets verification, AI DAST, AI Pentest, code documentation and rule generation — runs through the provider configured in Settings → AI Provider.
Choosing a provider
| Provider | Covers |
|---|---|
| OpenAI | Any endpoint implementing the OpenAI API specification: hosted OpenAI, a compatible gateway, or a model running locally through Ollama, LM Studio and similar. |
| Vertex AI Anthropic | Claude models served through Google Cloud Vertex AI. |
The fields for each are listed in Configuring API keys for external systems.
Keeping code on-premise
This is the decision that matters most for static analysis, because AI Native SAST sends source code to the model.
A cloud-hosted model means your source code is transmitted to the provider. For sensitive or proprietary codebases, point the OpenAI API URL at a model running on your own infrastructure — the platform is designed to run fully offline.
Setting a local API URL is all that is required; the rest of the platform behaves identically. If no API URL is configured, the hosted OpenAI service is used and a valid API key is required.
Model choice
Results are generated dynamically, so they vary slightly between runs. Larger models give more consistent results — 30B parameters and above is the practical floor for local models if you want reproducible findings rather than suggestions.
Provider selection is locked for the duration of a scan once a provider answers successfully, so a single engagement does not silently switch models halfway through.
Cost
Token usage is recorded per scan and shown as prompt, completion and total token counters on the Settings page, so the cost of an engagement is visible rather than inferred.
The features differ enormously in what they cost:
| Feature | Cost shape |
|---|---|
| AI Native SAST | One model call per file in scope, plus an agent loop per finding when reachability is enabled. Scope is your main control. |
| Dependency reachability | Gated four times over precisely because an unbounded dependency scan would be expensive. See that chapter. |
| Secrets verification | Cheap. Path filters, deterministic rules and a per-value cache resolve most findings before the model sees them. |
| AI code documentation | Reads a large portion of the codebase. Generate it once for an unfamiliar codebase, not per commit. |
| AI DAST / AI Pentest | Bounded by explicit budgets — maximum cycles, rounds per step, and a wall-clock limit. |
The three scoping modes on the Static Analysis page — Custom Scope, Incremental Scan and Monitor Changes — exist for this reason. They make a re-scan cost what the change costs rather than what the codebase costs.
Output language
LLM generations language, under Additional Settings, controls the language the models write findings and reports in.
When the provider is unreachable
Every scan begins with an availability check against the configured provider. If no provider answers, the scan reports the failure rather than silently producing an empty result. The scan log names the sanitised provider error.
Last reviewed 2026-08-16