Gen3 Gt Api Compatibility Matrix

Start Here

Scan the matrix before onboarding a client. Match the compatibility mode to the key preset you issue from the GT API workspace.

Why this matters

Each row is evidence-backed against vendor documentation and GT /v1/* routes. Rows marked Guided OpenAI-compatible setup need operator validation beyond bare chat.

Details

Compatibility modes:

• Native OpenAI-compatible — chat (and often embeddings) against a custom base URL without GT-only routes.
• OpenAI plus GT extensions — standard chat plus GT conversation, upload, or file-status routes.
• Guided OpenAI-compatible setup — product UI or hosted constraints; follow the linked client runbook.

Client	Category	Compatibility	Key preset	Chat	Files	Persistence	Details
OpenAI SDK / curl · baseURL + Authorization bearer	SDK and HTTP	Native OpenAI-compatible	OpenAI-compatible chat client	Native /v1/models and /v1/chat/completions	Direct multipart calls to GT upload routes	Optional POST /v1/conversations + X-GT-Conversation-Id	Golden-path compatibility: point any OpenAI SDK or curl client at the tenant GT API base URL with a scoped bearer key; model discovery lists published agent aliases and raw-model catalog names allowlisted on the key. Python: OpenAI(base_url=f"{GT_BASE}", api_key=gtak_...) — Node: new OpenAI({ baseURL: GT_BASE, apiKey }). Use published alias or raw-model name strings from GET /v1/models as the model field; GT resolves routing internally. Validate this path with curl before onboarding frameworks or hosted products.
LangChain · ChatOpenAI base_url + api_key	Framework and orchestration	Native OpenAI-compatible	Chat plus embeddings framework client	ChatOpenAI / ChatOpenAI JS with custom base URL	No native GT upload — use HttpRequest / fetch side calls	App-managed POST /v1/conversations outside LangChain memory	Configure LangChain OpenAI chat and embedding classes with the GT API base URL; keep GT conversation bootstrap and file ingestion in adjacent application code. Python ChatOpenAI(base_url=GT_BASE, api_key=..., model="<alias>") — JS @langchain/openai ChatOpenAI with configuration.baseURL. Use OpenAIEmbeddings pointed at the same base URL when RAG chains need tenant-scoped /v1/embeddings. Document loaders and LangChain file tools do not map to GT dataset ingestion automatically.
LlamaIndex · OpenAI LLM + embedding api_base	Framework and orchestration	Native OpenAI-compatible	Chat plus embeddings framework client	OpenAI LLM class with api_base override	GT uploads via explicit HTTP outside LlamaIndex readers	Wrapper-owned GT conversation ids	Treat GT API as the OpenAI-compatible LLM and embedding backend for LlamaIndex; orchestrate GT-specific uploads and conversations in host application code. Python OpenAI(api_base=GT_BASE, api_key=...) or OpenAILike with api_base for chat pipelines. Set OpenAIEmbedding(api_base=GT_BASE) when indexes should use tenant /v1/embeddings. SimpleDirectoryReader ingestion stays local unless you add separate GT upload automation.
Vercel AI SDK · createOpenAI({ baseURL }) + server GT routes	Framework and orchestration	OpenAI plus GT extensions	Conversation app with uploads	OpenAI provider streamText / generateText against chat completions	GT conversation uploads via server Route Handlers	Strong fit: server-side POST /v1/conversations + header reuse	Use the Vercel AI SDK OpenAI provider pointed at GT API for chat; implement GT conversation bootstrap and file uploads in Next.js route handlers or server actions. Server: createOpenAI({ baseURL: GT_BASE, apiKey }) — never expose gtak_... to browser bundles. Prefer Chat Completions (streamText) — the Responses API surface is not the GT golden path. Store X-GT-Conversation-Id in session or database keyed to the UI thread.
LiteLLM · LiteLLM proxy upstream openai base	Framework and orchestration	Native OpenAI-compatible	Chat plus embeddings framework client	Proxy or SDK completion() with custom api_base	GT uploads outside LiteLLM unless proxied as custom HTTP	GT conversations via sidecar HTTP, not LiteLLM router	Point LiteLLM at GT API as an OpenAI-compatible upstream for chat and embeddings; keep GT upload and conversation routes in adjacent services. Proxy config.yaml: set model_list entry with api_base: https://<tenant-host>/api/tenant and api_key. Python: litellm.completion(model="openai/<alias>", api_base=GT_BASE, api_key=...) for direct calls. Validate direct curl/OpenAI SDK to GT before adding LiteLLM so failures are attributable.
CrewAI · LLM env OPENAI_API_BASE + orchestration glue	Framework and orchestration	OpenAI plus GT extensions	Conversation app with uploads	Crew LLM via OpenAI-compatible env vars	Explicit GT upload HTTP in crew tasks	Wrapper-managed GT conversation per crew session	Point CrewAI OpenAI LLM configuration at GT API for agent loops; keep GT conversation creation and file handling in the orchestration layer wrapping each crew run. Set OPENAI_API_BASE / OPENAI_BASE_URL to /api/tenant and OPENAI_API_KEY to the GT key in the crew runtime environment. Use published alias strings in CrewAI model fields — not internal provider model ids. Start stateless; add POST /v1/conversations only when a crew session needs durable GT context.
Langflow · OpenAI component base_url in flow	Workflow and builders	Guided OpenAI-compatible setup	Conversation app with uploads	OpenAI model component with custom API base	HTTP Request component for GT uploads	Flow variables storing GT conversation id	Configure Langflow OpenAI chat components with the GT base URL; add HTTP Request nodes for GT conversation bootstrap, dataset uploads, and file-status polling. In the OpenAI model component set OpenAI API Base to https://<tenant-host>/api/tenant. Store GT API key in Langflow global variables or credentials — not in exported flow JSON checked into git. Use HTTP Request nodes for routes Langflow OpenAI components do not cover.
Flowise · ChatOpenAI node basePath + credential	Workflow and builders	Guided OpenAI-compatible setup	Conversation app with uploads	ChatOpenAI / Agent nodes with custom base path	Custom Tool or HTTP node for GT uploads	Flow state variable for GT conversation id	Set Flowise ChatOpenAI nodes to the GT API base path with bearer credentials; use Custom Tool or HTTP nodes for GT-only conversation and upload routes. ChatOpenAI node: Base Path = /api/tenant, Credential = GT API key stored in Flowise credentials manager. Flowise .env may set OPENAI_API_KEY for defaults — override per-node for least privilege. Mirror Langflow pattern: chat in LLM nodes, GT extensions in HTTP/custom nodes.
Dify · Model Provider → OpenAI-API-compatible	Workflow and builders	OpenAI plus GT extensions	Chat plus embeddings framework client	App/workflow LLM nodes via OpenAI-compatible provider	HTTP Request tool or extension for GT uploads	Optional workflow step calling POST /v1/conversations	Add an OpenAI-API-compatible model provider in Dify pointed at GT API for chat and embeddings; implement GT upload and conversation routes as explicit HTTP workflow steps. Dify Settings → Model Provider → OpenAI-API-compatible: API Base URL = /api/tenant, API Key = GT bearer token. Map published aliases as external model names in apps and workflow LLM nodes. Validate chat, embeddings, and model list independently before enabling knowledge pipelines.
AnythingLLM · LLM Preference → Generic OpenAI base URL	Workflow and builders	Guided OpenAI-compatible setup	Chat plus embeddings framework client	Workspace chat via Generic OpenAI provider	Local workspace docs unless separate GT HTTP ingestion	Stateless GT chat unless external GT conversation orchestration	Configure AnythingLLM Generic OpenAI LLM connection with the GT API base URL and key; align chat and optional embedding calls with the same published alias boundary. AnythingLLM Settings → LLM Preference → Generic OpenAI: Base URL = /api/tenant, API Key = GT key. Workspace vector embeddings may stay local — enable GT /v1/embeddings only when both chat and embed should use GT. Document ingestion in AnythingLLM is product-local unless you add separate GT upload automation.
Semantic Kernel · OpenAI connector Endpoint + ApiKey	Framework and orchestration	OpenAI plus GT extensions	Chat plus embeddings framework client	Kernel OpenAI chat completion connector	Plugin HttpClient for GT uploads	Plugin calling POST /v1/conversations	Point Semantic Kernel OpenAI chat and embedding connectors at GT API; implement GT upload and conversation bootstrap in custom plugins or host services. C#: OpenAIChatCompletionService with custom endpoint URI ending in /api/tenant and GT API key. Python SK: configure OpenAIChatCompletion / embedding services with base_url override. Planners and plugins still execute against published agent policy inside GT.
Continue · config.yaml models → apiBaseUrl	Developer tooling	Guided OpenAI-compatible setup	Agentic IDE or editor client	Continue chat via OpenAI-compatible model entry	No GT upload expectation for editor chat	Stateless GT chat preferred	Add an OpenAI-compatible model provider in Continue config.yaml pointed at GT API with a dedicated editor-scoped inference key and published coding alias. Continue ~/.continue/config.yaml → models entry with provider: openai, apiBase: /api/tenant, apiKey. Use a dedicated inference key per developer or team — not shared app conversation keys. Validate model list and first completion before enabling for a broader team.
Cursor · Settings → Models → Override OpenAI Base URL	Developer tooling	Guided OpenAI-compatible setup	Agentic IDE or editor client	Editor chat when custom OpenAI base is permitted	No GT upload expectation	Stateless preferred	When the Cursor environment allows overriding the OpenAI API base URL, point it at GT API with a dedicated editor inference key and published coding alias. Cursor Settings → Models: enable OpenAI API key override and set Base URL to /api/tenant where the product version supports it. Agent/Composer modes may ignore custom base URLs — validate standard chat completion path first. Use a separate key from production app credentials.
Cline / Roo Code · Extension OpenAI Base URL + API Key	Developer tooling	Guided OpenAI-compatible setup	Agentic IDE or editor client	VS Code extension chat against custom OpenAI endpoint	No GT upload expectation	Stateless preferred	Configure Cline or Roo Code extension OpenAI-compatible provider settings with GT API base URL, bearer key, and a published coding alias. Cline: extension settings OpenAI Base URL = /api/tenant, API Key = GT key. Roo Code: Settings → API Provider → OpenAI Compatible with custom base URL field. These tools can generate high edit volume — use narrow keys and rate monitoring.
Aider · CLI --openai-api-base + OPENAI_API_KEY	Developer tooling	Guided OpenAI-compatible setup	Agentic IDE or editor client	Aider CLI chat/edits via OpenAI API	Local repo files only — not GT uploads	Stateless preferred	Run Aider with --openai-api-base pointed at GT API and OPENAI_API_KEY set to a dedicated inference key; use a published coding alias as the model name. CLI: aider --model openai/<alias> --openai-api-base ${GT_BASE} with OPENAI_API_KEY=gtak_.... Aider reads/writes local git files — GT dataset uploads are out of scope for standard Aider loops. Test one repository before team-wide adoption.
Manus · Manus Custom API (non-standard)	Developer tooling	Guided OpenAI-compatible setup	Agentic IDE or editor client	Chat tasks when custom OpenAI endpoint is accepted	GT uploads only via explicit custom HTTP you add	Stateless preferred	Manus is primarily a hosted agent product; GT API fits only when your deployment exposes a true OpenAI-compatible base URL override — not the default Manus Custom API shape alone. Manus Custom API settings often expect vendor-specific endpoint shapes rather than a plain OpenAI /v1 base — validate before rollout. When override is supported, set base to /api/tenant and GT bearer key with a published alias. Start with the same curl/OpenAI SDK validation as the golden path.
OpenClaw · Agent config openai_base_url + api_key	Developer tooling	Guided OpenAI-compatible setup	Agentic IDE or editor client	Agent loops when custom OpenAI endpoint supported	GT uploads via explicit API orchestration only	Stateless preferred	Configure OpenClaw (or compatible agent runners) with OpenAI-compatible base URL and bearer key when the runtime supports custom endpoints; validate model discovery before autonomous modes. Set agent config openai_base_url / OPENAI_BASE_URL to /api/tenant and OPENAI_API_KEY to GT key. Agent runners can generate sustained traffic — monitor quotas and use narrow alias allowlists. Confirm GET /v1/models before enabling tool-heavy loops.
Hermes Agent · Custom endpoint in config.yaml or hermes model	Developer tooling	Native OpenAI-compatible	Agentic IDE or editor client	Agent loops via OpenAI-compatible custom provider (api_mode: chat_completions)	GT uploads only via explicit HTTP you add to agent tooling	Stateless preferred — Hermes session state is local	Point Hermes Agent at the tenant GT API with a first-class custom OpenAI-compatible endpoint (provider: custom, base_url, api_key); use a published agent alias as the model id after validating GET /v1/models. Interactive: hermes model → Custom endpoint (self-hosted / vLLM / etc.) → base URL https://<tenant-host>/api/tenant, API key gtak_..., model = published alias. Persistent: ~/.hermes/config.yaml with model.provider: custom, model.base_url, model.api_key, and optional custom_providers[] entries using api_mode: chat_completions. Hermes scopes API keys to the configured base URL — use a dedicated GT inference key per operator or workspace. Auxiliary/vision tasks may use a separate model; validate the main chat path to GT API before enabling tool-heavy autonomy.
n8n · OpenAI node + HTTP Request nodes	Workflow and builders	OpenAI plus GT extensions	Dataset upload automation	OpenAI node or LangChain OpenAI sub-node	HTTP Request multipart to GT upload routes	Workflow static data for GT conversation id	Use n8n OpenAI-compatible nodes for chat against GT API and HTTP Request nodes for GT conversation bootstrap, dataset uploads, and file-status polling. OpenAI node: set Base URL override to /api/tenant and credential with GT API key. HTTP Request node: method POST, URL ${GT_BASE}/v1/datasets/{id}/files, Authorization Bearer header. Use dataset-upload preset for ingestion-only flows; conversation-app when chat + conversation files share one key.
Lovable · Server env + generated app backend	Workflow and builders	OpenAI plus GT extensions	Conversation app with uploads	Generated app OpenAI-compatible backend calls	Server-side GT conversation uploads	Server-side GT conversation bootstrap	Use GT API as the OpenAI-compatible backend for Lovable-generated apps via server-side env configuration; keep GT conversation and upload routes in backend helpers, not browser bundles. Lovable projects typically store secrets in platform env — set GT_API_BASE_URL and GT_API_KEY server-side only. Hosted Lovable SaaS may not allow arbitrary OpenAI base URLs on all tiers — confirm before promising GT connectivity. Favor conversation-app keys for user-facing flows with uploads.
Open WebUI · Admin OPENAI_API_BASE_URL + API key	Workflow and builders	Guided OpenAI-compatible setup	OpenAI-compatible chat client	UI chat via OpenAI connection settings	Product-local attachments unless wired to GT HTTP APIs	Stateless GT chat by default	Configure Open WebUI admin connection settings with GT API base URL (OPENAI_API_BASE_URL) and a scoped inference key; published aliases appear as selectable models. Docker/env: OPENAI_API_BASE_URL=https://<tenant-host>/api/tenant, OPENAI_API_KEY=gtak_.... Admin Settings → Connections → OpenAI may also expose base URL override in UI. Add inference:embed only when deployment routes embeddings through GT.
LibreChat · librechat.yaml custom endpoint + OPENAI_REVERSE_PROXY	Workflow and builders	Guided OpenAI-compatible setup	OpenAI-compatible chat client	Multi-model chat via custom OpenAI endpoint	LibreChat file flows separate from GT dataset uploads	Stateless GT chat unless middleware adds GT conversations	Point LibreChat custom OpenAI endpoints at GT API via librechat.yaml and environment secrets; bind custom model entries to published agent aliases. Env: OPENAI_REVERSE_PROXY=https://<tenant-host>/api/tenant, OPENAI_API_KEY=gtak_.... Define custom endpoints in librechat.yaml under endpoints.custom with GT base URL. Switch to chat-plus-embeddings preset if LibreChat embeds through GT.
Generic OpenAI-compatible HTTP client · Any client with base URL + bearer auth	SDK and HTTP	Native OpenAI-compatible	OpenAI-compatible chat client	Reference compatibility baseline	Direct GT upload routes via HTTP	Direct GT conversation route	Fallback row for unlisted products that can override OpenAI base URL and send bearer-authenticated requests to /api/tenant/v1/*. Requires ability to set base URL to https://<tenant-host>/api/tenant and Authorization bearer header. Start with GET /v1/models then minimal chat; add GT extensions only when the product truly needs them. Confirm whether callers should use agent aliases, raw-model names, or both before issuing keys.