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 AI configuration of the team the work belongs to.
The team's AI configuration
Team admins and operators choose it under Teams → Team settings → AI provider:
| Choice | Effect |
|---|---|
| Use platform default | The provider, model and key an installation administrator configured for all teams. The team never sees the key or the endpoint. |
| Team override | A provider, model and key of its own. The platform default is never used for this team, not even when the override fails. |
| Disable AI | No AI for this team. Scans run without their AI stages. |
Test AI configuration sends one short prompt through the saved choice and reports only whether it answered. A scan keeps the configuration it started with, so changing it affects new scans only.
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 source code is transmitted to the provider. For sensitive or proprietary codebases, point the OpenAI API URL at a model running on self-hosted 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. The endpoint must use HTTPS; see Configuring API keys for external systems for models served with an internal certificate. For hosted OpenAI, enter https://api.openai.com/v1 and an API key.
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 team. A team can set a monthly token budget under the AI provider settings, and an installation administrator can set a monthly limit per team; the lower of the two applies, including to a team override. Once the month's budget is used up, AI stages report that AI is unavailable until the next month or a higher budget.
Spend is shown in money once the models are priced under LLM prices: US dollars per million prompt tokens and per million completion tokens, per model. Scan History, the scan page, the Products pages and the Top 10 LLM Token Consuming Targets panel then show the cost beside the tokens. Changing a price re-prices past scans; their token counts never change. In the classic edition LLM prices are in Settings; in ScanSuite Teams an installation administrator sets them in the system settings.
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 the 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.
Staying within the provider's rate limit
In the classic edition, two settings in Settings control how many AI requests run at the same time:
| Setting | What it does |
|---|---|
| AI SAST requests at once per scan | How many files, candidate findings or mitigation rewrites one scan sends to the provider at the same time, from 1 to 8. 1 handles them one after another. Higher is proportionally faster while the provider's rate limit allows it; the results are the same either way. |
| AI requests at once per provider, all scans | A cap shared by every scan running at the same time, so parallel scans together stay within the rate limit. A request waits for a free slot. 0 means no cap. |
When the provider does answer that its rate limit is reached, the scan waits and tries again rather than failing; the scan log says how long it waits.
Output language
LLM generations language, under Additional Settings in Team integrations, 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-09-25