How I configure Cline, Continue, and similar tools against a multi-protocol gateway

Disclosure and availability

DaoXE is a service we operate. It is not available in mainland China. This article is for developers in regions allowed by the service terms.

Most coding assistants still speak one common dialect: OpenAI Compatible with a custom base URL. That is convenient for migration. It is not the whole story of a multi-model gateway. I run coding clients against DaoXE, a multi-protocol API gateway that exposes more than Chat Completions. This post is the practical setup path I use for Cline, Continue, Roo Code, Aider, and similar tools: one base URL, one key, live model discovery, and no hardcoded model IDs from blog posts.

If you want the protocol-level checklist first, start with:

• The 3-step smoke test I use for any OpenAI-compatible API
• One gateway, three protocols: Chat Completions, Responses, and Anthropic Messages

What this post is (and is not)

This is a client configuration guide. It is not a claim that DaoXE is a built-in provider inside Cline, Continue, Roo Code, Aider, LibreChat, or Open WebUI. In every case below, you use the client's generic OpenAI-compatible / custom endpoint option.

It is also not a claim that every client uses every protocol. Many IDE tools only talk Chat Completions. Other stacks prefer OpenAI Responses or Anthropic Messages. The gateway may support all three; the client may only use one.

The three values every client needs

Before opening any settings panel, collect three values from your own account:

Exact values for DaoXE:

• Base URL: https://daoxe.com/v1
• API key: create in your own DaoXE account
• Model ID: copy an exact ID currently available to your account

Homepage for account and docs: https://daoxe.com/?utm_source=devto&utm_medium=organic&utm_campaign=global_launch_clients

Public examples and client notes: https://github.com/seven7763/DaoXE-AI

Detailed client matrix: CLIENT_SETUP.md

Smoke-test the gateway before fighting the IDE

If the endpoint is wrong, every client will look broken. I always run the same two checks from the first post before I touch VS Code settings.

1. Auth + model discovery

export DAOXE_API_KEY="your_api_key"
export DAOXE_BASE_URL="https://daoxe.com/v1"

curl --fail-with-body --show-error --silent \
  -H "Authorization: Bearer $DAOXE_API_KEY" \
  "$DAOXE_BASE_URL/models"

What I want:

• 401/403 for a bad key
• 200 with exact model IDs for a good key

Copy one ID from the response. Do not invent a pretty alias.

2. One tiny Chat Completions request

export DAOXE_MODEL="paste_exact_model_id_here"

curl --fail-with-body --show-error --silent \
  -H "Authorization: Bearer $DAOXE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "'"$DAOXE_MODEL"'",
    "max_tokens": 8,
    "messages": [{"role": "user", "content": "ping"}]
  }' \
  "$DAOXE_BASE_URL/chat/completions"

If this fails, stop. Fix auth, base URL, or model ID before opening the IDE.

Multi-protocol reality, one client-facing base URL

DaoXE is multi-protocol. Public surface includes:

• OpenAI Chat Completions
• OpenAI Responses
• Anthropic Messages
• image-compatible endpoints where available

Coding assistants in this post mostly use the OpenAI Compatible path: https://daoxe.com/v1

That is intentional. When Cline or Continue asks for a base URL and an API key, you are almost certainly on Chat Completions. That is fine. Just do not assume the gateway is OpenAI-only or limited to one model family because the client form is OpenAI-shaped. If another tool in your stack speaks Responses or Anthropic Messages, configure that tool for that protocol. Do not force every client through the same dialect.

Cline

Cline is configured through OpenAI Compatible, not through a native DaoXE dropdown.

• Open Cline settings.
• Set API Provider to OpenAI Compatible.
• Set Base URL to https://daoxe.com/v1.
• Paste your DaoXE API key.
• Enter an exact model ID from your current account catalog.

Notes:

• There is no first-class DaoXE provider option to look for.
• If the model list is empty, re-check the key and base URL with the curl smoke test above.
• Prefer the shortest path that works; do not invent extra path segments under /v1 unless the client requires them.

Roo Code

Roo Code follows the same OpenAI-compatible pattern as Cline.

• Open provider settings.
• Choose the OpenAI-compatible / custom OpenAI-style option available in your build.
• Base URL: https://daoxe.com/v1.
• API key: your DaoXE key.
• Model: exact current account ID.

If a menu item looks like a branded provider list, do not assume DaoXE is there. Use the custom compatible endpoint path.

Continue

Continue usually means provider: openai plus a custom apiBase. Conceptually:

models:
  - name: DaoXE current model
    provider: openai
    model: paste_exact_model_id_here
    apiBase: https://daoxe.com/v1
    apiKey: your_api_key

Practical rules:

• provider: openai here means the OpenAI-compatible protocol shape, not "only OpenAI models".
• apiBase should be https://daoxe.com/v1.
• Put secrets in env or local config that is not committed.
• Refresh the model ID from /models when the catalog changes.

If Continue cannot list models, validate with curl first. IDE plugins often obscure 401 vs 404 vs timeout.

Aider

Aider is environment-variable driven for many OpenAI-compatible endpoints. Typical pattern:

export OPENAI_API_BASE=https://daoxe.com/v1
export OPENAI_API_KEY=your_api_key
# then pass the exact model ID with Aider's model flag/config for your version

Because Aider versions differ, treat the living notes in CLIENT_SETUP.md as the source of truth for flag names. The invariants stay the same: base URL, key, exact model ID.

LibreChat

LibreChat uses a custom endpoint style configuration rather than a DaoXE-specific built-in. Pattern:

• endpoint type: OpenAI-compatible / custom
• baseURL / apiBase: https://daoxe.com/v1
• apiKey: your key
• models: fetch from the endpoint when possible, otherwise pin exact IDs from your account

Do not paste keys into shared YAML committed to a public repo.

Open WebUI

Open WebUI is another Chat Completions-path client. That does not prevent other tools from using Responses or Anthropic Messages against the same gateway. Typical setup:

• Add an OpenAI-compatible connection.
• API base: https://daoxe.com/v1.
• API key: your DaoXE key.
• Verify models load from the connection.
• Pick an exact model ID available to your account.

If models fail to load, re-run the curl /models check from the same machine/network.

A pattern that scales across clients

Every client above collapses to the same checklist:

1. Confirm the client dialect (almost always Chat Completions for these IDEs).
2. Set base URL to https://daoxe.com/v1.
3. Inject the API key outside source control.
4. Discover model IDs from the current account.
5. Smoke-test with curl before blaming the plugin UI.
6. Only then configure advanced features (tools, streaming preferences, context limits).

Troubleshooting map

Security habits I keep for coding clients

• Never commit keys. Prefer env vars or OS secret storage.
• Rotate a key if it ever appears in a screenshot or chat log.
• Keep max_tokens tiny during smoke tests to limit accidental spend.

Why multi-protocol still matters if the IDE only speaks one dialect

Because your stack is bigger than one IDE:

• which clients use Chat Completions today
• which future tools may want Responses
• which Claude-oriented tools may want Anthropic Messages

Configuring Cline correctly is necessary. It is not the whole gateway story.

Minimal checklist you can reuse

1. Curl /models with your key.
2. Curl one tiny Chat Completions request.
3. Set the IDE provider to OpenAI Compatible / custom OpenAI.
4. Base URL https://daoxe.com/v1.
5. Exact model ID from step 1.
6. Send one short prompt in the IDE.

If it fails, compare IDE error to the curl result before changing five settings at once.

Links

• Smoke test post: The 3-step smoke test I use for any OpenAI-compatible API
• Multi-protocol post: One gateway, three protocols: Chat Completions, Responses, and Anthropic Messages
• Client matrix: CLIENT_SETUP.md
• Examples repo: DaoXE-AI
• DaoXE homepage: https://daoxe.com/?utm_source=devto&utm_medium=organic&utm_campaign=global_launch_clients