Point Trae Agent at one endpoint for every model.

Quick answer: one provider block, one model block.

Trae Agent's current configuration is YAML: trae_config.yaml in the project directory, with three relevant blocks. model_providers defines endpoints, and each entry takes api_key, provider, and base_url, so an OpenAI-compatible gateway is just an openai-type provider with its base_url swapped. models defines named model configs that reference a provider through model_provider. agents binds trae_agent to one of those model names. The upstream README shows exactly this shape for routing through a multi-model service: an openai provider entry whose base_url points at the service's /v1 root. For APIsRouter, that is https://api.apisrouter.com/v1, and the model field then takes any catalog id as a plain string, Claude and Kimi ids included, because the provider type only decides the request format, not the vendor.

model_providers:
  apisrouter:
    api_key: your_apisrouter_api_key
    provider: openai
    base_url: https://api.apisrouter.com/v1

models:
  trae_agent_model:
    model_provider: apisrouter
    model: claude-sonnet-4-6
    max_tokens: 4096
    temperature: 0.5

How Trae Agent is wired inside.

Trae Agent (bytedance on GitHub, roughly 12K stars) is ByteDance's research-oriented software-engineering agent for the command line: give trae-cli a task and it works through it with a transparent tool loop, bash, file editing, and sequential thinking among the built-in tools, up to a configurable max_steps. It is deliberately modular, which is why the config separates providers from models from agents: the same provider can back several model configs, and swapping what the agent runs on is a one-line edit to a name reference. Two model slots matter in practice. trae_agent_model is the main loop, the model doing the reasoning, tool calls, and edits, where max_steps of two hundred means a single task can be a long sequence of billed calls. lakeview_model powers Lakeview, Trae's step-summarization feature that produces short readable summaries of what the agent did at each step. Lakeview fires often and its output is glanceable prose, which makes it the textbook slot for a fast id while the main loop keeps a frontier one. Configuration resolves from more than the YAML: the CLI accepts --provider and --model flags per run, and provider-specific environment variables, OPENAI_API_KEY and OPENAI_BASE_URL among the documented set, feed the same settings. The flags are how you A/B a second model without touching the file.

Full setup: agent, Lakeview, and a run.

The complete config binds the agent to a main model and Lakeview to a fast one, both through the same provider entry. Note the indirection: agents.trae_agent.model names an entry in models, and each models entry names a provider through model_provider. A typo in either reference fails the chain, so keep the three names consistent. One historical note that explains most confused tutorials: Trae Agent's configuration used to be trae_config.json, and the repo now documents that format as legacy with YAML as the current form. Guides showing JSON are describing an older layout; the keys migrated, the concepts carried over. If you have an old JSON config, the repo's legacy-config doc covers the mapping. The one-key angle is worth spelling out for this tool in particular. Trae Agent's native provider list spans American and Chinese vendors, which normally means an account and key per vendor, some of which are hard to obtain depending on where you sit. Behind one gateway entry, claude-sonnet-4-6, gpt-5.5, deepseek-v4-pro, glm-5.2, and kimi-k2.7-code are all one model-string away, on one key, with one balance, whichever side of the Pacific you develop from.

agents:
  trae_agent:
    enable_lakeview: true
    model: trae_agent_model
    max_steps: 200
    tools:
      - bash
      - str_replace_based_edit_tool
      - sequentialthinking
      - task_done

model_providers:
  apisrouter:
    api_key: your_apisrouter_api_key
    provider: openai
    base_url: https://api.apisrouter.com/v1

models:
  trae_agent_model:
    model_provider: apisrouter
    model: claude-sonnet-4-6
    max_tokens: 4096
    temperature: 0.5
  lakeview_model:
    model_provider: apisrouter
    model: claude-haiku-4-5-20251001
    max_tokens: 4096
    temperature: 0.5

Choosing models for the agent loop.

The --provider and --model flags make the comparison workflow concrete: run the same task twice with different flags, read steps-to-done and the priced usage per model in the console, and promote the winner into trae_config.yaml.

• The main loop is long-horizon tool work: reading files, editing, running bash, judging when the task is done. claude-sonnet-4-6 and gpt-5.5 hold a two-hundred-step plan together; this slot is the last place to economize.
• Lakeview is high-frequency, low-stakes summarization. claude-haiku-4-5-20251001 or deepseek-v4-flash keeps it effectively free next to the main loop's spend.
• kimi-k2.7-code and glm-5.2 are serious candidates for the main loop on codebases with Chinese comments, commit history, or docs; a bilingual repo is where they beat English-first models on comprehension, not just price.
• deepseek-v4-pro is the volume pick for batch runs, sweeping the same fix across many repos or running the agent in CI, where per-task cost multiplies.
• max_steps is your cost governor. A model that wanders burns steps; when comparing candidates, compare steps-to-done on the same task, not tokens per request.

Pay-as-you-go · transparent per-model pricing

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Failure modes specific to Trae Agent.

The JSON-versus-YAML confusion leads everything. A trae_config.json copied from an older guide is read as legacy at best and ignored at worst, and the symptom is the CLI behaving as if you never configured anything. Current setups belong in trae_config.yaml; migrate old files using the repo's legacy-config doc rather than guessing key names. The three-name chain breaks quietly. agents.trae_agent.model must name a models entry, and that entry's model_provider must name a model_providers entry. Rename one and not the others and the run fails at startup with a resolution error rather than a request error, which points you at the YAML, not the network. base_url wants the /v1 included, matching the upstream example that points at a router's /v1 root. A bare host produces 404s once the client appends the chat-completions path. Lakeview failing while the agent works means lakeview_model references an id the endpoint does not serve, easy to miss because you tested the main model and forgot the second slot. And environment variables silently backing a provider you thought was file-configured, OPENAI_API_KEY especially, are worth checking when authentication behaves inconsistently between shells.

Who routes Trae Agent through a gateway.

• Developers who want Claude or GPT driving the agent loop and GLM, Kimi, or DeepSeek a flag away, without holding an account at each vendor.
• Bilingual teams working across Chinese and English codebases, for whom the strongest model per repo may come from either ecosystem, addressable through one key.
• Engineers running batch or CI agent tasks, where per-key usage tracking turns a fleet of trae-cli runs into a readable cost report.
• Researchers benchmarking agent models, since Trae Agent is built for ablation-style comparison and the gateway makes every candidate the same one-flag change.
• Developers without access to a given vendor's billing. Top-up based access with no card requirement removes the per-provider sign-up dependency.

Verify the endpoint and debug the first task.

Confirm the endpoint serves your ids before the first run: the /v1/models listing with your key is the authoritative spelling for every model field in the YAML, main slot and Lakeview slot both. First-run failures sort cleanly. A config resolution error before any request is the three-name chain or a legacy JSON file. A 401 is the api_key in the provider block, or an environment variable overriding it. A 404 on every request is a base_url missing its /v1. A model-not-found error names the slot that is wrong, check whether it was the agent model or the Lakeview model. And a run that starts but stalls mid-task is usually the model wandering rather than the endpoint failing, which is what max_steps and the step log are for. Once tasks run, the APIsRouter console shows per-request model, token counts, and spend. An agent that takes a hundred steps per task multiplies everything, and the usage log is where you learn what a task genuinely costs on each candidate model.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

FAQ