# What LLM Providers Are Supported by the Proxy Service in TencentDB-Agent-Memory

> Discover which LLM providers TencentDB-Agent-Memory's Proxy service supports. Learn about OpenAI and Anthropic compatible integrations and configuration options.

- Repository: [Tencent Cloud/TencentDB-Agent-Memory](https://github.com/TencentCloud/TencentDB-Agent-Memory)
- Tags: api-reference
- Published: 2026-08-30

---

**The Proxy service supports OpenAI-compatible providers (including Azure OpenAI, DeepSeek, and custom self-hosted endpoints) via the `openai` protocol, and Anthropic-compatible providers via the `anthropic` protocol, configurable through the `LLM_PROTOCOL` environment variable.**

The TencentDB-Agent-Memory repository provides a Proxy component that acts as a forwarding layer for LLM requests rather than embedding a concrete model itself. Understanding what LLM providers are supported by the Proxy service enables you to integrate any compliant upstream endpoint, from commercial APIs to private deployments, by selecting the appropriate protocol and configuration parameters.

## Supported Protocols and Provider Families

The Proxy understands two official LLM protocols, each tied to a specific provider family:

- **OpenAI-compatible providers** — Uses the `openai` protocol keyword. This covers OpenAI itself, Azure OpenAI, DeepSeek, and any service exposing the standard `/v1/chat/completions` endpoint shape. The Proxy translates requests to the **Chat Completions** format.

- **Anthropic-compatible providers** — Uses the `anthropic` protocol keyword. This covers any service exposing the `/v1/messages` endpoint shape, including Claude and compatible proxies. The Proxy translates requests to the **Messages** format.

Because the Proxy does not embed model logic, it works with any upstream endpoint that respects the selected protocol's request and response shape. This architecture allows you to plug in **any OpenAI-compatible endpoint** (including custom or self-hosted deployments) or **any Anthropic-compatible endpoint** by simply adjusting configuration variables.

## How Protocol Selection Works

### Configuration via Environment Variables

The Proxy determines which protocol to use based on the **`LLM_PROTOCOL`** environment variable, which defaults to `openai`. According to the source code in `deploy/global-images/.env.example`, the accepted values are explicitly `openai` or `anthropic`.

```bash

# From deploy/global-images/.env.example

LLM_PROTOCOL=openai   # Options: openai | anthropic

```

When deploying the Proxy, you must also set the upstream connection details:

- **`PROXY_UPSTREAM_URL`** — The base URL of your LLM provider's API
- **`PROXY_UPSTREAM_API_KEY`** — The authentication key for the upstream service
- **`PROXY_UPSTREAM_MODEL`** — The specific model identifier to request

### Internal Protocol Routing

Internally, the request-building code branches on the protocol value to handle provider-specific logic correctly. In [`MemoryProxy/src/turnSeq.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryProxy/src/turnSeq.ts), the `countHumanTurns` function explicitly accepts a `protocol` argument typed as `"openai" | "anthropic"`, confirming the binary support model:

```typescript
// From MemoryProxy/src/turnSeq.ts (lines 44-51)
export function countHumanTurns(
  messages: Message[],
  protocol: "openai" | "anthropic"
): number {
  // Implementation counts human turns based on protocol-specific message shapes
}

```

The authentication header selection logic in [`MemoryProxy/src/systemUserPassthrough.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryProxy/src/systemUserPassthrough.ts) (lines 22-30) demonstrates how the Proxy switches between providers:

- **OpenAI protocol**: Uses `Authorization: Bearer <token>` header format
- **Anthropic protocol**: Uses `x-api-key: <token>` header format

## Practical Configuration Examples

Configure your deployment environment to point at your chosen provider:

```bash

# .env configuration for DeepSeek (OpenAI-compatible)

LLM_PROTOCOL=openai
PROXY_UPSTREAM_URL=https://api.deepseek.com/v1
PROXY_UPSTREAM_API_KEY=sk-your-secret-key-here
PROXY_UPSTREAM_MODEL=deepseek-chat

```

```bash

# .env configuration for Anthropic Claude

LLM_PROTOCOL=anthropic
PROXY_UPSTREAM_URL=https://api.anthropic.com
PROXY_UPSTREAM_API_KEY=sk-ant-your-key-here
PROXY_UPSTREAM_MODEL=claude-3-opus-20240229

```

Deploy the Proxy container with these environment variables:

```bash
docker run -d --name tdai-proxy \
  -e PROXY_UPSTREAM_URL=$PROXY_UPSTREAM_URL \
  -e PROXY_UPSTREAM_API_KEY=$PROXY_UPSTREAM_API_KEY \
  -e PROXY_UPSTREAM_MODEL=$PROXY_UPSTREAM_MODEL \
  -e LLM_PROTOCOL=$LLM_PROTOCOL \
  tdai-proxy:latest

```

Once running, clients such as `workbuddy`, `codebuddy`, or `claude-code` can connect to the Proxy, which forwards requests to your configured upstream endpoint using the correct protocol translation.

## Key Source Files

| File | Purpose |
|------|---------|
| [`MemoryProxy/src/turnSeq.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryProxy/src/turnSeq.ts) | Defines the `protocol` union type (`"openai" \| "anthropic"`) and implements `countHumanTurns` for message sequence handling. |
| [`MemoryProxy/src/systemUserPassthrough.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryProxy/src/systemUserPassthrough.ts) | Contains the authentication header selection logic, routing between `Authorization: Bearer` for OpenAI and `x-api-key` for Anthropic. |
| `deploy/global-images/.env.example` | Documents the accepted `LLM_PROTOCOL` values and environment variable patterns. |
| [`README.deployment.md`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/README.deployment.md) | Provides comprehensive LLM configuration guidance, reinforcing that any OpenAI-compatible service can function as the upstream. |

## Summary

- The Proxy supports **two protocol families**: `openai` (Chat Completions format) and `anthropic` (Messages format).
- **Any compliant endpoint** works as an upstream provider, including commercial APIs (OpenAI, Azure, DeepSeek, Anthropic) and self-hosted solutions.
- Set **`LLM_PROTOCOL`** to `openai` or `anthropic` to determine request translation and authentication header formats.
- The source code explicitly types the protocol as a union of these two strings in [`turnSeq.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/turnSeq.ts) and handles auth differences in [`systemUserPassthrough.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/systemUserPassthrough.ts).

## Frequently Asked Questions

### Can I use custom or self-hosted LLM models with the Proxy service?

Yes. Because the Proxy forwards requests rather than hosting models internally, you can point `PROXY_UPSTREAM_URL` at any OpenAI-compatible endpoint (such as vLLM, Ollama, or Text Generation Inference) or Anthropic-compatible proxy. As long as the endpoint respects the protocol's request shape and authentication method, the Proxy will function correctly.

### How do I switch between OpenAI and Anthropic protocols?

Set the `LLM_PROTOCOL` environment variable to either `openai` or `anthropic` before starting the Proxy container. This variable defaults to `openai` if not specified. You must also update `PROXY_UPSTREAM_URL` and `PROXY_UPSTREAM_API_KEY` to match your new provider's endpoint and credentials.

### What authentication headers does the Proxy use for different providers?

The Proxy automatically selects the correct authentication scheme based on the protocol. For the `openai` protocol, it sends `Authorization: Bearer <token>`. For the `anthropic` protocol, it sends `x-api-key: <token>`. This logic is implemented in [`MemoryProxy/src/systemUserPassthrough.ts`](https://github.com/TencentCloud/TencentDB-Agent-Memory/blob/main/MemoryProxy/src/systemUserPassthrough.ts) to ensure compatibility with each provider's security requirements.

### Does the Proxy support provider-specific features like function calling?

The Proxy forwards requests to the upstream endpoint but focuses on protocol compatibility rather than feature negotiation. If your upstream provider supports function calling or other extensions within the standard Chat Completions or Messages format, those capabilities pass through. However, the Proxy specifically handles the core request routing and authentication translation defined in the two supported protocols.