# DBX AI Providers: Supported LLMs, API Styles, and Authentication Methods

> Explore DBX AI providers, supported LLMs like Claude and Gemini, API styles, and authentication methods. Discover how DBX integrates with various AI services seamlessly.

- Repository: [skyler/dbx](https://github.com/t8y2/dbx)
- Tags: api-reference
- Published: 2026-07-04

---

**DBX supports eight AI providers including Claude, OpenAI, Google Gemini, DeepSeek, Qwen, Ollama, OpenAI-compatible services, and Codex CLI, with authentication ranging from API keys and Bearer tokens to no-auth for local servers, while API styles vary between Completions, Responses, and AnthropicMessages formats.**

The open-source database client DBX (t8y2/dbx) ships with a flexible AI SQL Assistant capable of integrating with multiple large language model providers. Understanding which AI providers DBX supports and how their APIs and authentication methods differ is essential for configuring secure, functional connections to both cloud and local LLM services.

## Supported AI Providers in DBX

The `AiProvider` enum in [`crates/dbx-core/src/ai.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/ai.rs) defines eight distinct provider options, each with unique endpoint configurations and authentication requirements.

### Cloud LLM Providers

**Claude (Anthropic)** uses the `https://api.anthropic.com/v1/messages` endpoint and requires an API key sent via the `x-api-key` header. DBX treats this as an *API-Key* authentication method, though the header differs from standard Bearer tokens.

**OpenAI** connects to `https://api.openai.com/v1/chat/completions` (or the legacy completions endpoint) using Bearer token authentication via the `Authorization: Bearer <key>` header. This is the default *API-Key* method in DBX's configuration.

**Google Gemini** calls `https://generativelanguage.googleapis.com/v1/models/<model>:generateContent`, passing the API key as a query parameter `key=` rather than a header. DBX stores this as an API-Key but transmits it in the URL query string.

**DeepSeek** and **Qwen** both implement OpenAI-compatible endpoints (`https://api.deepseek.com/v1/chat/completions` and `https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation` respectively) and use standard Bearer token authentication identical to OpenAI's format.

### Local and Specialized Options

**Ollama** connects to local instances at `http://localhost:11434/api/chat` with **no authentication** required by default. DBX can still send an empty API-Key field for consistency, but the local server typically ignores it.

**OpenAI-Compatible** providers allow users to specify any endpoint following the OpenAI Chat Completions JSON schema, such as Azure OpenAI or proxy servers. Authentication accepts either Bearer tokens or API keys depending on the specific service requirements.

**Codex CLI** executes a locally-installed `codex` binary directly for offline code generation. This requires **no HTTP authentication**; instead, DBX may supply environment variables defined in `codex_cli_env` when launching the binary.

**Custom** providers offer full control over endpoint URLs and request shapes, supporting both `ApiKey` and `Bearer` authentication methods as specified by the user in the `auth_method` field.

## API Style Differences Across Providers

DBX normalizes request payloads using the `AiApiStyle` enum defined in [`crates/dbx-core/src/ai.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/ai.rs). The UI exposed in [`apps/desktop/src/stores/settingsStore.ts`](https://github.com/t8y2/dbx/blob/main/apps/desktop/src/stores/settingsStore.ts) allows users to select the appropriate style for their chosen provider.

### Completions Style

The `Completions` style targets legacy OpenAI `/v1/completions` endpoints that expect a single prompt string rather than role-based messages. Older OpenAI models and some custom endpoints utilize this format.

### Responses Style

The `Responses` style implements the modern OpenAI `/v1/chat/completions` format with role-based messages (system, user, assistant). This is the default for OpenAI, Azure OpenAI, DeepSeek, and Qwen providers.

### AnthropicMessages Style

The `AnthropicMessages` style serializes requests according to Anthropic's `/v1/messages` specification, supporting tool-use and specialized Claude features. This is required for Claude (Anthropic) integrations.

## Authentication Handling in DBX

The `AiAuthMethod` enum in [`crates/dbx-core/src/ai.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/ai.rs) controls how DBX transmits credentials, with the desktop UI storing keys securely in user settings.

### API Key Authentication

The default `ApiKey` method sends `Authorization: Bearer <key>` for OpenAI-compatible providers, but adapts to provider-specific requirements such as `x-api-key: <key>` for Anthropic and `key=<value>` query parameters for Google Gemini. The UI presents a single "API key" input field that maps to these various transport mechanisms.

### Bearer Token Authentication

The `Bearer` method explicitly sends `Authorization: Bearer <key>` headers, useful for services requiring JWT or OAuth tokens rather than simple API keys. This is rarely needed but exposed for advanced custom endpoints.

### No Authentication

**Ollama** and **Codex CLI** operate without HTTP authentication. Ollama accepts requests to local endpoints without headers, while Codex CLI launches as a local subprocess with optional environment variables instead of HTTP headers.

## Configuration Examples

Below is a minimal JSON configuration stored in user settings (managed by [`settingsStore.ts`](https://github.com/t8y2/dbx/blob/main/settingsStore.ts)) for an OpenAI connection:

```json
{
  "provider": "Openai",
  "api_key": "sk-xxxxxxxxxxxxxxxxxxxxxx",
  "auth_method": "ApiKey",
  "endpoint": "https://api.openai.com/v1",
  "model": "gpt-4o-mini",
  "api_style": "Responses",
  "proxy_enabled": false
}

```

For **Claude**, change the provider and style:

```json
{
  "provider": "Claude",
  "api_key": "sk-ant-xxxxxxxx",
  "auth_method": "ApiKey",
  "endpoint": "https://api.anthropic.com/v1",
  "model": "claude-3-opus-20240229",
  "api_style": "AnthropicMessages"
}

```

For **Ollama** local inference, omit the API key:

```json
{
  "provider": "Ollama",
  "api_key": "",
  "endpoint": "http://localhost:11434",
  "model": "llama3.1",
  "api_style": "Responses"
}

```

## Implementation Details

| Concern | Source File |
|---------|-------------|
| Provider & auth enums | [`crates/dbx-core/src/ai.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/ai.rs) |
| UI configuration store | [`apps/desktop/src/stores/settingsStore.ts`](https://github.com/t8y2/dbx/blob/main/apps/desktop/src/stores/settingsStore.ts) |
| AI Assistant documentation | `docs/content/docs/ai-assistant.mdx` |
| Request construction | [`crates/dbx-core/src/ai.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/ai.rs) (functions building `reqwest` requests based on `AiConfig`) |
| Proxy support | `AiConfig` struct fields `proxy_enabled` and `proxy_url` in [`crates/dbx-core/src/ai.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/ai.rs) |

## Summary

- DBX supports **eight AI providers**: Claude, OpenAI, Google Gemini, DeepSeek, Qwen, Ollama, OpenAI-compatible services, and Codex CLI, plus a custom option.
- **Authentication methods** vary by provider: API keys (sent as headers or query parameters), Bearer tokens, or no authentication for local services.
- **API styles** determine request payload format: `Completions` for legacy prompts, `Responses` for chat-based messages, and `AnthropicMessages` for Claude-specific formats.
- Configuration is centralized in [`crates/dbx-core/src/ai.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/ai.rs) with UI management in [`settingsStore.ts`](https://github.com/t8y2/dbx/blob/main/settingsStore.ts), ensuring consistent handling of provider-specific quirks like Anthropic's `x-api-key` header or Gemini's query parameter authentication.

## Frequently Asked Questions

### Which AI providers does DBX support for SQL generation?

DBX supports Claude (Anthropic), OpenAI, Google Gemini, DeepSeek, Qwen, Ollama (local), OpenAI-compatible services (including Azure), Codex CLI (local binary), and a custom provider option for private endpoints. Each is defined in the `AiProvider` enum within [`crates/dbx-core/src/ai.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/ai.rs).

### How does DBX handle authentication differently between Claude and OpenAI?

Claude requires an API key sent in the `x-api-key` HTTP header, while OpenAI uses the standard `Authorization: Bearer <key>` header. DBX abstracts this through the `AiAuthMethod` enum—when you select "API Key" in the UI, DBX automatically chooses the correct header format based on the selected provider.

### Can I use a local LLM with DBX without authentication?

Yes. **Ollama** runs locally at `http://localhost:11434/api/chat` and requires no authentication by default. You can leave the API key field empty in the DBX settings, and the application will still send requests to your local instance. Similarly, **Codex CLI** runs as a local subprocess without HTTP authentication.

### What is the difference between API styles in DBX configuration?

The `api_style` setting determines how DBX serializes the request payload. `Responses` sends role-based chat messages (used for modern OpenAI, DeepSeek, and Qwen), `AnthropicMessages` sends Claude-specific message formats, and `Completions` sends single-prompt strings for legacy endpoints. This setting is found in [`crates/dbx-core/src/ai.rs`](https://github.com/t8y2/dbx/blob/main/crates/dbx-core/src/ai.rs) and configurable via the desktop UI.