Integration guides · 2026-08-29
The LLMTR provider block in OpenCode configuration and model naming
Where the LLMTR connection for OpenCode is documented, how the connect flow runs, what the provider block in opencode.json looks like, and how catalog identifiers are written into that block step by step.
Which repository and branch holds the documentation
The source of this setup is the add-llmtr-docs branch in the knowhycodata/opencode repository. The change adds a new section inside the provider list in the file packages/web/src/content/docs/providers.mdx. What follows is therefore not a guess, it is a section written into the tool's own provider documentation.
The point that has to be stated plainly: the branch was not merged upstream. If you read the published OpenCode documentation you will not find the LLMTR section there. Anyone who wants to see the content has to look at the add-llmtr-docs branch in knowhycodata/opencode.
The section describes LLMTR briefly: an OpenAI-compatible gateway hosted in Turkey. A single API key reaches both its own first-party models and passthrough routes from vendors such as OpenAI, Anthropic and Google. The whole setup turns around that single key.
The connect command and a four-step flow
Setup runs through the interface. You create an account and generate a key on the dashboard, then run the connect command inside the tool and search the provider list for LLMTR. The command opens a small field asking for the key; you paste it and confirm.
The fourth step is model selection. When the models command runs, the first-party routes carrying the llmtr prefix are already in the list, because they arrive preloaded. If you want any other model from the catalog, the job is not finished there: its identifier has to be added to the configuration file. That is exactly what the next section covers.
| Step | Command or input | Result |
|---|---|---|
| 1 | Account and key on the dashboard | An API key with the llmtr prefix |
| 2 | Connect command | LLMTR is located in the provider list |
| 3 | Key entry | The key is stored by the tool |
| 4 | Models command | The picker opens with first-party routes listed |
The step of the connect command that asks for a key
/connect
┌ API key
│
│
└ enter
/modelsThe provider block in the configuration file
Additional models are declared in opencode.json. The block is three levels deep: a provider key, a model map below it, and a display name under each model. The map key is the canonical catalog identifier itself, the form where provider and model name are joined by a slash.
The name field only sets the label shown in the interface; the value that travels in the request is the map key. Knowing that distinction explains why the name in the picker can differ from the identifier in the catalog. Write the label however you like, but the key has to match the catalog letter for letter.
The schema declaration at the top of the file gives field completion in an editor. When writing the block by hand, copy and paste the identifier: version numbers are spelled with dots, and confusing a dot with a dash is the most common way to break the mapping.
Declaring two catalog identifiers in opencode.json
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"llmtr": {
"models": {
"anthropic/claude-opus-4.8": {
"name": "Claude Opus 4.8"
},
"openai/gpt-5.5": {
"name": "GPT-5.5"
}
}
}
}
}Naming differences between first-party and passthrough routes
The catalog holds two kinds of identifier and OpenCode treats them differently. Those beginning with the llmtr prefix are first-party routes running on the gateway's own infrastructure, and they appear in the picker without configuration. Identifiers whose leading segment is a vendor name are passthrough routes and have to be written into the configuration by hand.
When describing that second group, the provider documentation specifically mentions passthrough models that support tool calling. In a coding session the decisive property is whether the model accepts tool definitions, so it is worth checking that support in the catalog before committing an identifier to the block.
- Identifiers with the llmtr prefix arrive preloaded and need no configuration
- Vendor-prefixed identifiers are passthrough routes added to the model map by hand
- The map key is a literal copy of the catalog identifier
- The name field is an interface label only and is never sent in the request
- As many identifiers as you need can live under the same block
Check endpoint compatibility before writing an identifier
Every model on the gateway carries one or more bindings, and those decide which endpoint can call the identifier. A request arriving at the chat completions endpoint is served both when the model holds a chat completions binding and when it holds only a Responses binding. That is why the example list in the documentation can carry two different kinds of identifier at once.
The reverse is not true, though an OpenCode setup does not use that direction anyway. One exception is worth naming: the gateway documentation defines the GPT-5 Codex family as available on the Responses endpoint only. Non-chat routes such as embedding models should never enter the model map, because they do not serve the endpoint a coding session speaks.
| Identifier | Binding in catalog | Place in configuration |
|---|---|---|
| anthropic/claude-opus-4.8 | CHAT_COMPLETIONS | Added to the model map |
| openai/gpt-5.5 | RESPONSES | Added to the model map |
| llmtr/gemma-4 | CHAT_COMPLETIONS | First-party, arrives preloaded |
| llmtr/trendyol-asure-12b | CHAT_COMPLETIONS | First-party, arrives preloaded |
| llmtr/embeddinggemma-300m | EMBEDDINGS | Not a chat route, do not add |
Verification and what this branch does not cover
Before saving the block, confirm that the identifier really exists in the catalog and is not retired. The model list endpoint is readable without a key, so the check can be done before touching the tool. Pages for retired records stay published, so having seen an identifier somewhere is not evidence that it is still usable.
One scope note deserves to be explicit: the branch reviewed here adds documentation only. How the provider record is declared inside the tool, which package it speaks through, and which library carries the request all fall outside this change. This guide makes no claim about that part; it covers the documented flow and the configuration shape.
Cost follows the gateway rules. Billing is token based and computed from the tariff of the model you selected. The platform margin is not added to model prices; it applies only when topping up credit, and it is eight percent.
Verifying an identifier in the catalog before adding it
curl -s https://llmtr.com/v1/models \
| grep -o '"id":"anthropic/claude-opus-4.8"'Frequently asked questions
I cannot see an LLMTR section in the OpenCode documentation, where is it?
The section lives on the add-llmtr-docs branch of the knowhycodata/opencode repository, in the file packages/web/src/content/docs/providers.mdx. Because the branch was not merged upstream, it does not appear in the published documentation; you have to look at that branch to read it.
Why does the model picker show only a handful of models?
The first-party routes carrying the llmtr prefix are preloaded, so they are listed immediately. The rest of the catalog does not arrive automatically. A passthrough route appears in the picker once you add its identifier to the model map in opencode.json.
Can I change the name field in the model map?
Yes. The name field is only the label shown in the interface and can be written however you prefer. The value that travels in the request is the map key, so the key must match the canonical catalog identifier letter for letter.
Can every catalog identifier go into this block?
No. The block declares models for a coding session, so entering identifiers that are not chat routes serves no purpose. Embedding, image and audio routes are served on different endpoints. Check the supported operations of an identifier in the catalog before writing it down.