---
title: "Troubleshooting"
version: "v0.27.0"
canonical: "https://docs.obot.ai/v0.27.0/llm-gateway/troubleshooting"
unreleased: false
---

# Troubleshooting

Start with the request's Obot provider endpoint, requested model, user, and time. An administrator or auditor can use **Operations > Audit Logs > Model** to correlate the request with its recorded outcome. Remove API keys and sensitive prompts before sharing diagnostics.

<a id="obot-doc-authentication-fails"></a>

## Authentication fails

Confirm that the client sends an Obot API key with **LLM proxy access**, using the authentication format documented for that client and provider route. An upstream provider key does not authenticate the client to Obot. An expired or deleted authorization scope no longer grants access.

Check the key against `/api/me` as described in [Testing an API key](https://docs.obot.ai/v0.27.0/functionality/agent-auth-scopes.md#obot-doc-testing-an-api-key). A successful result verifies the key's identity; it does not prove the key has LLM proxy access or that its owner has model grants.

<a id="obot-doc-no-models-appear-or-a-model-is-denied"></a>

## No models appear or a model is denied

1. Open **Models** as the affected user and check which models are available.
2. Ask an administrator to check the matching policies under **Models > Access Policies**. Administrators also need model grants.
3. Check that the provider is configured and the intended model is active under **Models > Model Providers**.
4. Use the provider model ID shown in Obot. For Azure, use the configured deployment name.

A configured provider does not grant every user access. See [Control model access](https://docs.obot.ai/v0.27.0/functionality/model-access-policies.md).

<a id="obot-doc-an-alias-fails-or-uses-an-unexpected-model"></a>

## An alias fails or uses an unexpected model

`llm` and `llm-mini` refer to global defaults. An administrator can inspect their targets under **Models > Model Providers > Set Default Models**.

The alias must point to an active model, the caller must have access to that model, and the request must use the matching provider route. For example, an alias pointing to an Anthropic model cannot be sent to the OpenAI route. If the alias target changes providers, update the client's base URL. See [Model aliases](https://docs.obot.ai/v0.27.0/llm-gateway/how-it-works.md#obot-doc-using-model-aliases).

<a id="obot-doc-the-endpoint-or-request-format-is-rejected"></a>

## The endpoint or request format is rejected

Check the client's base URL against the example on **Models**. Use the route for the configured provider and the API format it supports. The OpenAI-compatible gateway routes support the Responses API; they do not support Chat Completions. Azure deployment names do not determine whether a request uses the Anthropic or OpenAI format.

For model discovery differences and client-specific settings, use [API compatibility](https://docs.obot.ai/v0.27.0/llm-gateway/compatibility.md) and [Connect clients and applications](https://docs.obot.ai/v0.27.0/llm-gateway/connect-clients.md).

<a id="obot-doc-the-upstream-provider-rejects-the-request"></a>

## The upstream provider rejects the request

An administrator should inspect the provider configuration, upstream credentials, requested model or deployment, and any upstream quota or rate-limit error. Check network access from Obot to the provider. Repeatedly changing the user's Obot key will not repair an invalid upstream credential.

<a id="obot-doc-verify-the-repair"></a>

## Verify the repair

Repeat a small request using the same client route and affected user's access. Check the returned model and the new audit outcome. A successful request under an administrator's account does not establish another user's access. For an unreachable Obot service, continue to [deployment troubleshooting](https://docs.obot.ai/v0.27.0/operations/troubleshooting.md).