LLM providers
Register the LLM providers your AI agents use on SonarQube Server 2026.5, and pick the provider type that matches how you reach your models.
AI agents need a large language model (LLM) to do their work. You give them access to one by registering an LLM provider, which connects either directly to a model service or through an AI gateway.
As an Instance Admin, you register providers once for the whole instance, and each one then becomes available across SonarQube Server. You select which provider and model an agent uses from that list, on the agent's own page. AI CodeFix is the exception: it keeps its own configuration and does not draw from this list. See Enable AI CodeFix.
Choosing a provider type
Each provider type asks for a different set of fields, so choose the type before you fill in the form. Find your setup in the following table.
AWS Bedrock Mantle, reached through its OpenAI-compatible endpoint, with an API key or the AWS identity available to SonarQube Server
AWS Bedrock Mantle
A model service, an AI gateway, or a proxy you run yourself, for example OpenRouter or Portkey
Custom
Every type other than AWS Bedrock reaches your models through an OpenAI-compatible API; see Supported API. For OpenAI and Anthropic, SonarQube Server already knows that endpoint, so the form only asks for an API key.
Prerequisites
A credential or an identity that can call the models you want to use.
Outbound network access from SonarQube Server to your models. SonarQube Server calls them when you register a provider and when you select a model, even when your agents run on separate hosts.
Outbound network access from your agent hosts to the same models, if you're registering the provider for an agent. The agents call them directly when they run.
A trusted certificate chain for the provider, if you reach it through a proxy or gateway that presents a certificate signed by a private certificate authority (CA).
If you're registering the provider for an AI agent, make sure you deploy that agent first.
Adding a provider
In SonarQube Server, go to Administration > Configuration > AI capabilities > LLM providers.
Select Add provider.
Enter a Name. It identifies the provider in the list and has no effect on the connection.
Select the Provider. The rest of the form changes to the fields that type needs.
Enter those fields. See the page for your provider type.
Select Add provider.
For every provider type except AWS Bedrock, SonarQube Server tests the connection when you save. If the test fails, SonarQube Server does not add the provider, and the form reports the problem. Correct the values and save again.
For AWS Bedrock, SonarQube Server checks the region and the AWS permissions later, when you select a model for an agent. See What happens when you save for what happens if that check fails.
Each provider you add appears in the list, showing the name you gave it and its type.
Selecting a provider and model for an agent
Adding a provider makes it available to every AI agent on your instance, but each agent still takes its own provider and model, set on that agent's own page under Administration > Configuration > AI capabilities. Pointing one agent at a provider does not change what any other agent uses, and several agents can share the same provider.
Before you select a model, check the agent's own page for the models it supports. For example, the Remediation Agent supports the claude-opus-4-6 and gpt-5.5 models; see Prerequisites. When you save your selection, SonarQube Server checks the model right away, so an identifier your provider does not recognize fails immediately instead of during a later run. For AWS Bedrock, that same check also confirms the region and the AWS permissions.
Managing providers
An instance holds up to 15 providers, and at the limit, Add provider is unavailable until you remove one. When you edit a provider, you do not need to re-enter a secret you are not changing: leave the field as it is, and SonarQube Server keeps the stored value.
Rotate a credential in this order, so the connection keeps working throughout the rotation:
Create the new key with your provider.
In SonarQube Server, update the provider with the new key, then select Save.
Revoke the old key with your provider.
Two situations can come up after a provider is added:
You cannot delete a provider while an AI agent is using it. The error names the agents that still point at it. Select a different provider for each of them first.
A provider that worked can start reporting an error later, for example after its key expires or its endpoint changes. Fix the configuration and save the provider again.
Security considerations
When an AI agent runs, it sends code and issue details to the provider you registered. Therefore, that provider's terms apply to that data. Choose a provider and a region that meet your requirements.
If your instance has a secret key configured, SonarQube Server encrypts API keys and any header values you mark as secret. To set one up, see Sensitive settings.
Apply least privilege to the credential or identity you register: give it access only to the models your agents use, not to your whole account.
If you reach the provider through a proxy or gateway that presents a certificate signed by a private CA, install that CA in the trust store used by SonarQube Server and in the one used by your agent hosts. Allowing the hostname through your network does not make an untrusted certificate valid.
Troubleshooting
When a message does not tell you enough, check the server log.
The endpoint is not a valid URL.
The endpoint is not a URL SonarQube Server can parse.
Check the URL, including the scheme and the version path.
Could not reach the endpoint.
SonarQube Server could not open a connection to the endpoint.
Confirm your network allows SonarQube Server to reach it. SonarQube Server refuses an endpoint that resolves back to itself.
Unexpected response from the endpoint.
The endpoint answered, but did not return a usable list of models.
Check that the base URL you entered exposes the OpenAI-compatible API, and that the credential is valid for it.
A provider that worked now reports an error
The credential expired or was revoked, or the endpoint changed.
Fix the configuration and save the provider again.
Could not verify model '<identifier>'
Your provider could not serve that model.
Check the identifier against your provider's catalog. The rest of the message gives your provider's reason.
The provider is saved, but its model cannot be verified
The endpoint lists its models, but POST /chat/completions does not reach a working backend.
Check POST /chat/completions on your endpoint separately. Verify that the route exists on your provider or gateway, that the gateway forwards it to the right backend path, that the authentication headers are present, that the response uses the OpenAI chat completions format, and that the certificate is trusted.
A Portkey provider is registered, but selecting a model fails
The Portkey API key has no provider configured for it, or the model does not match the provider the key is configured for.
In Portkey, configure the key for the provider that serves that model, then select the model again.
Model '<identifier>' not usable in <region>. (AWS Bedrock)
The model is not available in that region, the identifier is wrong, or your AWS identity is not allowed to invoke it.
Check all three. The message is the same in each case, so check the server log for the reason.
Add provider is unavailable
The instance already holds 15 providers.
Remove a provider you no longer use.
A provider cannot be deleted
An AI agent is using it.
The error names them. Select a different provider for each, then delete this one.
Related pages
Last updated
Was this helpful?