> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/instance-administration/ai-features/llm-providers.md).
# 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](/sonarqube-server/instance-administration/ai-features/enable-ai-codefix.md).
## 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.
| Where your models are | Provider type | Where to go |
| ------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Azure AI Foundry | Azure AI Foundry, or Custom for some APIM policies | [Azure AI Foundry](/sonarqube-server/instance-administration/ai-features/llm-providers/azure-ai-foundry.md) |
| AWS Bedrock, using AWS credentials already available to SonarQube Server | AWS Bedrock | [AWS Bedrock](/sonarqube-server/instance-administration/ai-features/llm-providers/aws-bedrock.md) |
| AWS Bedrock Mantle, reached through its OpenAI-compatible endpoint, with an API key or the AWS identity available to SonarQube Server | AWS Bedrock Mantle | [AWS Bedrock](/sonarqube-server/instance-administration/ai-features/llm-providers/aws-bedrock.md#aws-bedrock-mantle) |
| OpenAI's own API | OpenAI | [OpenAI](/sonarqube-server/instance-administration/ai-features/llm-providers/openai.md) |
| Anthropic's own API | Anthropic | [Anthropic](/sonarqube-server/instance-administration/ai-features/llm-providers/anthropic.md) |
| A model service, an AI gateway, or a proxy you run yourself, for example OpenRouter or Portkey | Custom | [Custom](/sonarqube-server/instance-administration/ai-features/llm-providers/custom.md) |
Every type other than **AWS Bedrock** reaches your models through an OpenAI-compatible API; see [Custom](/sonarqube-server/instance-administration/ai-features/llm-providers/custom.md#protocol). 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
1. In SonarQube Server, go to **Administration** > **Configuration** > **AI capabilities** > **LLM providers**.
2. Select **Add provider**.
3. Enter a **Name**. It identifies the provider in the list and has no effect on the connection.
4. Select the **Provider**. The rest of the form changes to the fields that type needs.
5. Enter those fields. See the page for your provider type.
6. 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 [AWS Bedrock](/sonarqube-server/instance-administration/ai-features/llm-providers/aws-bedrock.md#saving) 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 [Remediation Agent](/sonarqube-server/instance-administration/ai-features/remediation-agent.md#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:
1. Create the new key with your provider.
2. In SonarQube Server, update the provider with the new key, then select **Save**.
3. 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](/sonarqube-server/instance-administration/security/encrypting-settings.md).
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.
| Message or symptom | Cause | What to do |
| ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `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 ''` | 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 '' not usable in .` (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
* [Remediation Agent](/sonarqube-server/instance-administration/ai-features/remediation-agent.md)
* [Enable AI CodeFix](/sonarqube-server/instance-administration/ai-features/enable-ai-codefix.md)
* [Agentic capabilities](/sonarqube-server/agentic-capabilities.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.sonarsource.com/sonarqube-server/instance-administration/ai-features/llm-providers.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.