Not your Git identity
Provider credentials are separate from the Git integration token, the CLI team key, and every other credential in the account. They authorize model calls and nothing else.
Bring your own LLM / Provider keys
Your models. Your keys. Your bill, not ours.
Attach the provider credentials your organisation already pays for, then assign a model to each review agent. Requests go from the review straight to that provider account, under your commercial relationship, and the token spend appears on your invoice rather than inside someone else's plan.
Availability
Bring your own key is a Scale and Enterprise capability — it is not part of the Free or Team plans. Self-hosted and air-gapped deployments, where inference runs on an internal endpoint, are Enterprise. Plan detail is on the pricing page; procurement and deployment questions go to a booked review.
- Reviews built for sub-minute turnaround
- Customer code is never used to train models
- Internal vLLM or Ollama endpoints supported
01How a BYOK review runs
Five stages between the webhook and the comment.
Your provider is involved at exactly one stage — the fourth. The rest is deterministic work that does not depend on which model you selected, which is why swapping a model does not change what a review is allowed to say.
The stage names below follow the documented review flow. The log beside them is an illustration of one run, not a transcript.
01
Provider connection resolved
The credential and the model for each agent are looked up before the diff is read.
Routing holds a default model plus per-task overrides — code review, Kody rules review, rule generation, business-rules validation, the pull-request summary, and chat. A task with no override of its own uses the default. The connected credential supplies the base URL and key, so the call goes to the provider account you chose.
routing.defaultModelId · routing.taskOverrides
02
Diff ingest
The webhook is verified, de-duplicated, and queued without blocking your Git provider.
The pull-request event is signature-checked, normalised, and stored against an idempotency key, then published to the queue through the outbox. A slow review can never hold up the webhook endpoint. Later pushes re-analyze only the files that changed, unless a shared module widens the scope.
signature check · idempotency key · queue
03
AST and taint analysis
Changed files are parsed into syntax trees, and taint is traced across files.
The diff is widened with surrounding code so a check sees intent rather than only changed lines. Deterministic checks — SQL string concatenation, hardcoded secrets, missing tenant filters, unbounded goroutines — run on the tree, and cross-file taint paths are traced through the nodes they cross.
per-language parse · cross-file taint paths
04
Model reasoning
An assembled context pack goes to the models you assigned, not a repository dump.
The diff, the analysis results, your active Drixy rules, and retrieved team guidelines are packaged into a context pack and sent to the provider account on the routing table. Entropy scanning and token-pattern detection replace suspected credentials with stable placeholders first, so a finding about a leaked secret can still be reported without the literal value leaving the process.
context pack · secret redaction before send
05
Validated comments and fixes
Candidates are checked against real nodes, then posted inline on the pull request.
Findings are verified against the parsed tree, grouped, and de-duplicated using stable finding IDs, so a retry cannot produce a comment storm. What survives is posted as inline review comments with severity badges and patch suggestions. Which severities block a merge is configured per repository or organization.
AST validation · stable finding IDs · inline comments
- webhook
- pull_request.updated · GitHub
- verified
- signature checked · idempotency key stored
- queued
- review job published to the queue
- ast
- 3 files parsed · 2 changed
- taint
- 1 path traced to a query layer
- routing
- codeReview → <provider> · <model id>
- kodyRulesReview → <provider> · <model id>
- businessValidation → <provider> · <model id>
- validated
- 3 of 6 candidates matched real AST nodes
- posted
- 2 inline comments · 1 fix suggestion
- state
- changes requested
Angle-bracketed values stand in for whatever you connected
02Provider connections
Ten connections, and how each model list is obtained.
The interesting question about a connection is not which provider it is, but how ScanDrix learns which models to offer you. Four mechanisms are in use, and the difference is visible in what you are allowed to pick.
Any endpoint that speaks the OpenAI or Anthropic protocol can be connected as a custom base URL. Families without a first-class connection — DeepSeek among them — are reachable that way, or through a provider whose catalog already serves them. They are not separate ScanDrix connections.
- Live listing
- The picker calls the provider's own model endpoint with the key you just entered, so the list is what your account can reach at that moment. A model released upstream shows up without a ScanDrix release.
- Live, curated fallback
- The provider is queried live when the credential allows it. When the live call cannot run — no bearer token, IAM-only credentials, or a failed fetch — the picker degrades to a curated set rather than showing nothing.
- Curated catalog
- Availability depends on your project, region, or agreement in a way the provider does not expose over an unauthenticated endpoint, so the list is maintained by hand. A model missing from it is not proof the model is unsupported.
- Model id entered by hand
- The endpoint cannot be enumerated before you tell us what it is, or does not publish a listing at all. You type the model id, and anything the endpoint accepts is usable.
The connections we ship
- OpenAIAPI key
- Live listing
Enumerated from your key against the provider's models endpoint. You can also type any id the endpoint accepts.
- AnthropicAPI key
- Live listing
Enumerated from your key, so the picker matches the models your account can currently call.
- Google GeminiAPI key
- Live listing
Enumerated from your key and filtered to Gemini models. Older generations stay usable for as long as Google serves them.
- OpenRouterAPI key
- Live listing
Enumerated from your key, so the picker reflects the catalog your account can reach rather than a fixed list.
- NovitaAPI key
- Live listing
Enumerated from your key across the models this provider serves on your behalf.
- Moonshot (Kimi)API key
- Live listing
Kimi is served over the Anthropic protocol, and the curated picks stay the default so you get a recommended starting set as well as the full list.
- Amazon BedrockAWS credentials and region, or a Bedrock API key
- Live, curated fallback
Listed from your own account and region when a Bedrock API key is present, so only inference profiles you can invoke are offered. With IAM credentials alone, the picker falls back to a curated set of common cross-region profiles.
- Google Vertex AIService account JSON, plus a region
- Curated catalog
Model availability is per project and per region and is not enumerable without your credentials, so the catalog is maintained by hand. It covers both the Gemini and the Claude families, and any other model id can be typed in.
- Azure OpenAIAPI key and your resource endpoint
- Model id entered by hand
The deployed model list lives inside your resource, not behind a listing endpoint, so you enter the model id. It has to match a deployment your resource actually has.
- Z.ai (GLM)API key
- Model id entered by hand
GLM is served over the Anthropic protocol and publishes no model listing, so you type the model id by hand.
- OpenAI-compatible endpointBase URL and API key
- Model id entered by hand
You supply the endpoint, so the model id is entered by hand. Use it for gateways, proxies, and self-hosted runtimes that speak the OpenAI protocol.
- Anthropic-compatible endpointBase URL and API key
- Model id entered by hand
You supply the endpoint, so the model id is entered by hand. Use it for anything that speaks the Anthropic protocol and has no first-class connection of its own.
Curated catalogs and the models named in this page are illustrative rather than exhaustive or current. Model names, generations, and regional availability change at the provider's pace, and a provider's own documentation is the authority — each connection links to it from the connect form.
03What BYOK changes
Two models for the same review.
The analysis, the rules, and the comments are the same either way. What changes is which account is billed, which model list you can choose from, and where the request is allowed to go.
| Concern | Your key | Managed inference |
|---|---|---|
| Who is billed for tokens | Your provider, on the invoice you already have | ScanDrix, as part of the plan you are on |
| Model choice | Any model the connected endpoint serves, assigned per task and changed in routing settings | The models available on your plan |
| Release and retirement schedule | The provider's own, including their retirements | ScanDrix's, on its own cadence |
| Existing cloud commitment | Bedrock, Vertex, and Azure usage stays inside your cloud account | A separate inference line item outside your cloud commit |
| Where inference runs | Your provider, or an internal endpoint in a self-hosted deployment | ScanDrix-operated inference |
| Egress your network needs | The provider endpoint you allow-listed, or nothing at all when self-hosted | ScanDrix only |
What this does not claim
A BYOK connection is a billing and routing decision. It is worth being precise about the boundary, because the alternatives are usually described more loosely than the providers themselves describe them.
- Provider availability, model retirement, and retention terms are set by the provider you connect and by the configuration you have with them. ScanDrix does not override them.
- BYOK changes who pays for inference and where a request goes. It does not change what a review analyzes, and it is not a compliance attestation on its own.
- Where no request may leave your network, a connected provider is the wrong answer. That is a self-hosted deployment with an internal endpoint, and it is an Enterprise capability.
How the credential is handled
A provider key is held as a credential, not as customer content. It is used to call the provider and sits behind an encrypted storage boundary; the diff, the assembled context pack, and the findings are what travel to the provider. The authoritative description of what is stored, redacted, and retained is the data handling documentation.
Credential scope
Not the analysis
Which model is connected changes reasoning quality, latency, and cost. It does not change which files are parsed, which taint paths are traced, or which findings are rejected as unsupported by the tree.
Not the trigger
When a review runs is decided by your trigger settings, path filters, and merge policies — the same on every plan, and independent of which provider answers the call.
Next step
Attach a key, choose the models, review the next pull request.
Connect GitHub, GitLab, Bitbucket, Azure Repos, or Forgejo, add a provider under Settings, and route your agents. Enterprise deployment questions — a private VPC, an internal endpoint, or an air-gapped install — start with a booked review.