SDKs, Frameworks and Clients

ModelSite exposes two entry points. Use the matching official SDK; no dedicated client is needed.

On the text-model entrances the platform reads the key only from Authorization: Bearer, never from x-api-key. Clients that speak the Anthropic protocol must therefore send Bearer (auth_token, ANTHROPIC_AUTH_TOKEN), as shown below. The video and image entrances (paths starting with /api/v1, /api/v3 and /v2) also accept X-API-KEY, which ComfyUI's built-in API nodes send; if both headers are present, Authorization: Bearer wins. See Use ModelSite in ComfyUI.

Verification status

Every entry below carries exactly one of three statuses:

A stub server only shows what the client sends. It does not show that every upstream model behind ModelSite handles those requests. The "Limitations" lines record differences we found by reading code or official docs. Tools with no evidence are not listed; see Tools not listed.

API key

A new key is sk-ms- followed by 64 hex characters (70 characters in total). Older keys starting with sk-relay- still work. Every example below reads the key from the MODELSITE_API_KEY environment variable; do not hard-code a real key:

export MODELSITE_API_KEY="sk-ms-xxxxxxxx"   # replace with the full key from the console

Official SDKs

OpenAI SDK

• What it does: calls Chat Completions, Responses and Embeddings through the official OpenAI SDK.
• What to set: base_url = https://api.modelsite.ai/v1; key sent as Authorization: Bearer; model = a platform model ID such as glm-5.3-flash.
• Endpoints: /v1/chat/completions, /v1/responses, /v1/embeddings.
• Status: request captured against a stub server (OpenAI Python 2.54.0, Node 6.49.0).
• Limitations: when a model's upstream has no native Responses support, /v1/responses goes through a conversion path that differs from the official API; see the limitations in the Codex CLI entry.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.modelsite.ai/v1",
    api_key=os.environ["MODELSITE_API_KEY"],
)

# Non-streaming
resp = client.chat.completions.create(
    model="glm-5.3-flash",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

# Streaming
stream = client.chat.completions.create(
    model="glm-5.3-flash",
    messages=[{"role": "user", "content": "Hello"}],
    stream=True,
)
for chunk in stream:
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")

The same client can also call client.responses.create(...) (/v1/responses) and client.embeddings.create(...) (/v1/embeddings). See Responses and Embeddings for parameters.

Anthropic SDK

• What it does: calls Messages through the official Anthropic SDK.
• What to set: base_url = https://api.modelsite.ai (no /v1); pass the key as auth_token / authToken, not api_key; model = a platform model ID.
• Endpoints: /v1/messages.
• Status: request captured against a stub server (Anthropic Python 1.15.0, Node 0.135.0). With api_key the key appears only in the x-api-key header and the platform returns 401.

import os
from anthropic import Anthropic

client = Anthropic(
    base_url="https://api.modelsite.ai",            # no /v1; the SDK appends /v1/messages
    auth_token=os.environ["MODELSITE_API_KEY"],     # sends Authorization: Bearer
)

# Non-streaming
msg = client.messages.create(
    model="glm-5.3-flash",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello"}],
)
print(msg.content[0].text)

# Streaming
with client.messages.stream(
    model="glm-5.3-flash",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello"}],
) as stream:
    for text in stream.text_stream:
        print(text, end="")

The SDK sends anthropic-version: 2023-06-01 automatically. If you set anthropic-beta yourself, the platform forwards it upstream.

Frameworks

LangChain (Python)

• What it does: calls Chat Completions through ChatOpenAI from langchain-openai.
• What to set: base_url = https://api.modelsite.ai/v1; api_key = the key; model = a platform model ID.
• Endpoints: /v1/chat/completions (non-streaming and streaming).
• Status: request captured against a stub server (langchain-openai 1.7.2). The base_url and api_key parameters are described in the LangChain docs; without base_url it reads OPENAI_API_BASE, then OPENAI_BASE_URL.
• Limitations: the official docs say ChatOpenAI targets the official OpenAI specification only; non-standard fields returned by third-party models (for example reasoning_content) are not extracted or preserved. To read reasoning content, use the OpenAI SDK directly or a provider-specific integration package.

import os
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    base_url="https://api.modelsite.ai/v1",
    api_key=os.environ["MODELSITE_API_KEY"],
    model="glm-5.3-flash",
)
print(llm.invoke("Hello").content)

LlamaIndex (Python)

• What it does: calls any OpenAI-compatible Chat Completions service through OpenAILike from llama-index-llms-openai-like.
• What to set: api_base = https://api.modelsite.ai/v1; api_key = the key; model = a platform model ID; is_chat_model=True.
• Endpoints: /v1/chat/completions (chat and stream_chat).
• Status: request captured against a stub server (llama-index-llms-openai-like 0.8.1).
• Limitations: we only tested chat and stream_chat; embeddings and tool calling were not tested.

import os
from llama_index.llms.openai_like import OpenAILike
from llama_index.core.llms import ChatMessage

llm = OpenAILike(
    model="glm-5.3-flash",
    api_base="https://api.modelsite.ai/v1",
    api_key=os.environ["MODELSITE_API_KEY"],
    is_chat_model=True,
)
print(llm.chat([ChatMessage(role="user", content="Hello")]).message.content)

Vercel AI SDK (TypeScript)

• What it does: calls models with ai plus @ai-sdk/openai-compatible (or @ai-sdk/anthropic).
• What to set: baseURL = https://api.modelsite.ai/v1; apiKey (OpenAI-compatible) or authToken (Anthropic) = the key; model = a platform model ID.
• Endpoints: createOpenAICompatible(...).chatModel() and createOpenAI(...).chat() use /v1/chat/completions; @ai-sdk/anthropic uses /v1/messages.
• Status: request captured against a stub server (ai 6.0.309, @ai-sdk/openai-compatible 2.0.85, @ai-sdk/openai 3.0.130, @ai-sdk/anthropic 3.0.133).
• Limitations:
  • createOpenAI(...)(model) requests /v1/responses by default, not Chat Completions. Use .chat(model) for Chat Completions.
  • The baseURL for @ai-sdk/anthropic must include /v1 (the opposite of the official Anthropic SDK; we observed it appending /messages directly).
  • With apiKey, @ai-sdk/anthropic puts the key in x-api-key, which the platform does not read. Pass authToken.

import { generateText } from 'ai'
import { createOpenAICompatible } from '@ai-sdk/openai-compatible'

const modelsite = createOpenAICompatible({
  name: 'modelsite',
  baseURL: 'https://api.modelsite.ai/v1',
  apiKey: process.env.MODELSITE_API_KEY,
})

const { text } = await generateText({
  model: modelsite.chatModel('glm-5.3-flash'),
  prompt: 'Hello',
})

Coding assistants

Claude Code

• What it does: Anthropic's terminal coding assistant, speaking the Anthropic Messages protocol.
• What to set: ANTHROPIC_BASE_URL = https://api.modelsite.ai; ANTHROPIC_AUTH_TOKEN = the key; ANTHROPIC_MODEL = a platform model ID.
• Endpoints: /v1/messages (streaming).
• Status: request captured against a stub server (Claude Code 2.1.303). The settings come from the Claude Code gateway docs.

export ANTHROPIC_BASE_URL="https://api.modelsite.ai"
export ANTHROPIC_AUTH_TOKEN="$MODELSITE_API_KEY"
export ANTHROPIC_MODEL="glm-5.3-flash"
claude

What we captured it sending:

• POST /v1/messages?beta=true with Authorization: Bearer, stream: true and 20 tool definitions. The gateway forwards by path only, so ?beta=true is ignored.
• The body contains thinking (observed value {"type":"adaptive","display":"omitted"}), context_management (clear_thinking_20251015) and output_config (effort). The headers carry several anthropic-beta values.
• This run made a single /v1/messages request and no count_tokens request.

Limitations:

• Use ANTHROPIC_AUTH_TOKEN. The official docs say ANTHROPIC_API_KEY is sent as x-api-key, which the platform does not read, so it returns 401. apiKeyHelper sends both headers and also works.
• GLM models and medium effort. glm-5.3 and glm-5.3-flash support the effort levels low, high and max; when the effort level is set to medium, the request runs at high. Other chat models accept every level as sent. Details and a verified run: Claude Code.
• For a model ID it does not recognize, Claude Code prints a notice and assumes a 200k context window; see the official model-config page for how to correct it.
• The official docs say the opus / sonnet / haiku aliases resolve to Anthropic model IDs by default. Point them at platform model IDs with ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL and ANTHROPIC_DEFAULT_HAIKU_MODEL.
• When parsing the request the platform does not reject unrecognized top-level fields; it keeps them, and for models that do not use the native Anthropic endpoint they are carried through to the upstream. We have not checked, model by model, whether each upstream accepts context_management and similar fields. If you get a 400 such as Extra inputs are not permitted, set CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 as the official troubleshooting table says.
• Tool calls and multi-turn conversations were not tested end to end (the stub returns text only).

Codex CLI

• What it does: OpenAI's terminal coding assistant, which speaks only the Responses protocol.
• What to set: a custom model_providers entry in ~/.codex/config.toml: base_url = https://api.modelsite.ai/v1, env_key naming the environment variable that holds the key, wire_api = "responses"; model = a platform model ID.
• Endpoints: /v1/responses (streaming).
• Status: request captured against a stub server (codex-cli 0.142.2). The model_providers fields are in the Codex configuration docs. The platform has known differences on this path; see the limitations below.

model = "glm-5.3-flash"
model_provider = "modelsite"

[model_providers.modelsite]
name = "ModelSite"
base_url = "https://api.modelsite.ai/v1"
env_key = "MODELSITE_API_KEY"
wire_api = "responses"

What we captured it sending:

• POST /v1/responses with Authorization: Bearer, stream: true and store: false.
• Tool types function, namespace and web_search; the body also has include, prompt_cache_key and client_metadata.
• If MODELSITE_API_KEY is not set, Codex fails locally with Missing environment variable and sends nothing.
• For a platform model ID Codex prints Model metadata ... not found and falls back to default metadata. OpenRouter's Codex guide records the same notice.

Limitations:

• Codex uses only /v1/responses. When a model's upstream has no native Responses support, the platform uses a conversion path that differs from the official OpenAI API: the conversion path is now aligned with the official API: streamed events carry sequence_number, response.created / in_progress / completed echo the request fields, reasoning uses the official summary structure (identical for streaming and non-streaming) and comes first in output, and streamed and non-streamed response IDs both start with resp_. Remaining differences: a function_call item's id equals its call_id; refusal content parts use text instead of refusal; the echoed store, truncation, previous_response_id and similar are echoes only and the conversion path does not act on them. These alignments are covered by unit tests (official event sequences); we still have not verified end to end that Codex parses them correctly against the real platform.
• On the conversion path, Responses-only request fields such as store, include and previous_response_id have no Chat Completions equivalent and are dropped.
• Per the code, the conversion path turns function and custom tools into Chat Completions function tools and web_search into web_search_options; there is no conversion branch for the namespace type. We have not verified whether upstreams accept web_search_options. In our capture, setting web_search = "disabled" in config.toml (DeepSeek's Codex guide uses the same key) removed the web_search tool from the request.

OpenCode

• What it does: an open-source terminal coding assistant; connects to an OpenAI-compatible endpoint through a custom provider in opencode.json.
• What to set: npm = @ai-sdk/openai-compatible; options.baseURL = https://api.modelsite.ai/v1; options.apiKey = the key; list the platform model IDs under models.
• Endpoints: /v1/chat/completions (streaming, with tools).
• Status: request captured against a stub server (OpenCode 1.2.27). The settings are in the OpenCode provider docs.
• Limitations: the official docs say @ai-sdk/openai-compatible is for /v1/chat/completions; if a model uses /v1/responses, switch to @ai-sdk/openai, and the Responses limitations in the Codex entry apply.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "modelsite": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "ModelSite",
      "options": {
        "baseURL": "https://api.modelsite.ai/v1",
        "apiKey": "{env:MODELSITE_API_KEY}"
      },
      "models": {
        "glm-5.3-flash": { "name": "GLM 5.3 Flash" }
      }
    }
  }
}

Run it with opencode run -m modelsite/glm-5.3-flash "Hello".

Aider

• What it does: a terminal pair-programming tool that works in a git repository.
• What to set: OPENAI_API_BASE = https://api.modelsite.ai/v1; OPENAI_API_KEY = the key; --model openai/ followed by a platform model ID.
• Endpoints: /v1/chat/completions (streaming).
• Status: request captured against a stub server (Aider 0.86.2). The settings are in the Aider docs.
• Limitations: the model name must carry the openai/ prefix, and the official docs say Aider warns about models it does not recognize. Aider reads OPENAI_API_KEY, so export the key into that variable.

export OPENAI_API_BASE="https://api.modelsite.ai/v1"
export OPENAI_API_KEY="$MODELSITE_API_KEY"
aider --model openai/glm-5.3-flash

Cline

• What it does: a coding assistant inside VS Code; connects through the OpenAI Compatible provider.
• What to set: API Provider = OpenAI Compatible; Base URL = https://api.modelsite.ai/v1; API Key = the key; Model ID = a platform model ID.
• Endpoints: OpenAI-compatible Chat Completions, that is /v1/chat/completions.
• Status: checked against official docs: Cline OpenAI Compatible lists the Base URL, API Key and Model ID fields used above. We did not run Cline, so the exact path it requests is not captured.
• Limitations: the docs say the Base URL must not be https://api.openai.com/v1 and that model IDs differ between providers. Context window, max output and tool-calling support are optional "Model Configuration" fields; set them to match the platform model.

Continue

• What it does: a coding assistant and CLI for VS Code and JetBrains.
• What to set: one entry under models in config.yaml: provider: openai, apiBase: https://api.modelsite.ai/v1, apiKey = the key, model = a platform model ID.
• Endpoints: provider: openai uses Chat Completions by default, that is /v1/chat/completions.
• Status: checked against official docs: Continue OpenAI provider shows the same apiBase override for OpenAI-compatible servers. We did not run Continue.
• Limitations: the docs say Continue uses /responses by default for o-series and gpt-5 models and that useResponsesApi: false turns it off. Platform model IDs are neither, and we have not verified how it picks a path for other model names.

models:
  - name: glm-5.3-flash
    provider: openai
    model: glm-5.3-flash
    apiBase: https://api.modelsite.ai/v1
    apiKey: sk-ms-xxxxxxxx

Chat clients

Cherry Studio

• What it does: a desktop chat client; add an OpenAI-compatible endpoint under "custom provider".
• What to set: provider type = OpenAI; API address = https://api.modelsite.ai (the client appends /v1/chat/completions) or https://api.modelsite.ai/v1/chat/completions#; API key = the key; models = add model IDs from the model list manually.
• Endpoints: /v1/chat/completions.
• Status: checked against official docs: Cherry Studio provider settings. Two statements there match the setup above: entering a root address makes the client append /v1/chat/completions, and an address ending in # is used exactly as entered. We did not click through it in the client.

Open WebUI

• What it does: a self-hosted web chat interface; add an OpenAI-compatible service under Connections.
• What to set: Settings > Admin > Connections > Add Connection: URL = https://api.modelsite.ai/v1; API Key = the key; fill the model ID allowlist as needed.
• Endpoints: /v1/chat/completions; "Verify Connection" requests GET /v1/models.
• Status: checked against official docs: the Open WebUI OpenAI-compatible provider page lists the same fields. We did not run Open WebUI. The platform answers GET /v1/models in the gateway itself (per the gateway routing code), and the request must carry Authorization: Bearer.
• Limitations: the docs say saving a connection does not test it, and a failed "Verify Connection" does not mean chat is broken; if the /models list is not what you expect, fill the model ID allowlist by hand.

Workflow platforms

No entries yet: for Dify, n8n and similar tools we could not retrieve official documentation for a custom OpenAI-compatible endpoint, and we did not capture any requests.

Tools not listed

These tools are not listed because we have no evidence, not because they are known not to work:

• Cursor: we could not retrieve the official page for overriding the OpenAI base URL. The only sources are third-party gateway docs and forum posts, which mention that the override covers only the chat panel, needs a paid plan and interacts with Cursor's own models. We verified none of that.
• Chatbox, LobeChat, Roo Code, Kilo Code, GitHub Copilot, Gemini CLI, Qwen Code, Goose, Zed and similar: we found no official configuration page and captured no requests.
• Dify, n8n, Flowise and other workflow platforms: same.

Tools that offer an "OpenAI-compatible provider with a custom Base URL" can follow the fields in the Cline, Continue and OpenCode entries: Base URL https://api.modelsite.ai/v1 and a platform model ID. That is an analogy, not a verified result.

Common errors

How we tested

"Request captured against a stub server" means: install the tool in an isolated directory with its own HOME and config directory, point it at a stub server on 127.0.0.1, and have the stub log the path, auth header and body fields before returning a fixed minimal response. No real key was used and no paid API was called. The 404 and 401 responses come from key-less requests to api.modelsite.ai.