What feature would you like to be added or updated?
Add LLMTR as a first-class model provider, alongside the existing OpenAI, Anthropic, Azure, OpenRouter, Doubao, Ollama and Google providers.
LLMTR is an OpenAI-compatible AI gateway that serves Türkiye-hosted models (Trendyol Asure, Muse Glimmer, and other Turkish-language models) next to global models from OpenAI, Anthropic, Google, xAI, Qwen, Mistral, DeepSeek, Moonshot, Z.ai and others, behind a single API key. Model ids use an owner/model form, e.g. anthropic/claude-sonnet-5 or llmtr/trendyol-asure-12b.
Usage would look like:
trae-cli run "Fix the bug in main.py" --provider llmtr --model "anthropic/claude-sonnet-5"
trae-cli run "Kodu Türkçe yorumla" --provider llmtr --model "llmtr/trendyol-asure-12b"
Why do you need this feature?
Configuring LLMTR through the existing openai provider with a custom base_url mostly works, but it breaks down on one important detail: LLMTR's catalogue spans two endpoint families.
Of the 237 models it currently serves:
- 172 speak
/v1/chat/completions
- 15 speak only
/v1/responses — including openai/gpt-5.3-codex, openai/gpt-5.5, openai/gpt-5.6-* and the whole xai/grok-4.x family
- 50 are non-chat models (embeddings, images, video, audio, rerank)
OpenAICompatibleClient only speaks chat completions, so the responses-only group — which contains several of the models a coding agent would most want — cannot be reached at all today. Pointing the openai provider at them returns:
{"error": {"message": "Model \"gpt-5.3-codex\" requires the /v1/responses endpoint instead of /v1/chat/completions.", "type": "endpoint_mismatch"}}and the non-chat models fail only after the full retry loop has burned through its backoff.
A dedicated provider can read LLMTR's public model catalogue (GET /v1/models, no API key required) and route each model to the endpoint it actually supports, reject non-chat models up front with a clear message, and pick up LLMTR_API_KEY / LLMTR_BASE_URL through the existing provider env var resolution.
Additional information that you believe is relevant to this feature request
I have an implementation ready and will open a PR referencing this issue. It reuses OpenAICompatibleClient unchanged for the chat completions route, and mirrors the Responses API message translation already used by ollama_client.py for the responses route. It adds no new dependencies — the catalogue is read through the openai SDK that is already a dependency.
Similar provider requests for reference: #247, #421.
What feature would you like to be added or updated?
Add LLMTR as a first-class model provider, alongside the existing OpenAI, Anthropic, Azure, OpenRouter, Doubao, Ollama and Google providers.
LLMTR is an OpenAI-compatible AI gateway that serves Türkiye-hosted models (Trendyol Asure, Muse Glimmer, and other Turkish-language models) next to global models from OpenAI, Anthropic, Google, xAI, Qwen, Mistral, DeepSeek, Moonshot, Z.ai and others, behind a single API key. Model ids use an
owner/modelform, e.g.anthropic/claude-sonnet-5orllmtr/trendyol-asure-12b.Usage would look like:
Why do you need this feature?
Configuring LLMTR through the existing
openaiprovider with a custombase_urlmostly works, but it breaks down on one important detail: LLMTR's catalogue spans two endpoint families.Of the 237 models it currently serves:
/v1/chat/completions/v1/responses— includingopenai/gpt-5.3-codex,openai/gpt-5.5,openai/gpt-5.6-*and the wholexai/grok-4.xfamilyOpenAICompatibleClientonly speaks chat completions, so the responses-only group — which contains several of the models a coding agent would most want — cannot be reached at all today. Pointing theopenaiprovider at them returns:{"error": {"message": "Model \"gpt-5.3-codex\" requires the /v1/responses endpoint instead of /v1/chat/completions.", "type": "endpoint_mismatch"}}and the non-chat models fail only after the full retry loop has burned through its backoff.
A dedicated provider can read LLMTR's public model catalogue (
GET /v1/models, no API key required) and route each model to the endpoint it actually supports, reject non-chat models up front with a clear message, and pick upLLMTR_API_KEY/LLMTR_BASE_URLthrough the existing provider env var resolution.Additional information that you believe is relevant to this feature request
I have an implementation ready and will open a PR referencing this issue. It reuses
OpenAICompatibleClientunchanged for the chat completions route, and mirrors the Responses API message translation already used byollama_client.pyfor the responses route. It adds no new dependencies — the catalogue is read through theopenaiSDK that is already a dependency.Similar provider requests for reference: #247, #421.