Trae Agent को हर model के लिए एक endpoint पर point करें।

Quick answer: एक provider block, एक model block।

Trae Agent की current configuration YAML है: project directory में trae_config.yaml, तीन relevant blocks के साथ। model_providers endpoints define करता है, और हर entry api_key, provider, और base_url लेती है, तो एक OpenAI-compatible gateway बस एक openai-type provider है जिसका base_url swap किया गया। models named model configs define करता है जो model_provider के through एक provider reference करते हैं। agents trae_agent को उन model names में से एक से bind करता है। Upstream README exactly यही shape एक multi-model service के through routing के लिए दिखाता है: एक openai provider entry जिसका base_url service के /v1 root पर point करता है। APIsRouter के लिए, वह https://api.apisrouter.com/v1 है, और model field फिर कोई भी catalog id एक plain string के तौर पर लेती है, Claude और Kimi ids शामिल, क्योंकि provider type सिर्फ request format तय करता है, 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

Trae Agent अंदर से कैसे wired है।

Trae Agent (GitHub पर bytedance, लगभग 12K stars) ByteDance का command line के लिए research-oriented software-engineering agent है: trae-cli को एक task दें और यह एक transparent tool loop से इसे काम में लाता है, bash, file editing, और sequential thinking built-in tools में शामिल, एक configurable max_steps तक। यह जानबूझकर modular है, यही वजह है config providers को models से और models को agents से अलग करता है: same provider कई model configs को back कर सकता है, और agent किस पर चलता है यह बदलना एक name reference का one-line edit है। Practice में दो model slots matter करते हैं। trae_agent_model main loop है, वह model जो reasoning, tool calls, और edits करता है, जहां दो सौ की max_steps मतलब एक single task कई billed calls की एक लंबी sequence हो सकती है। lakeview_model Lakeview को power करता है, Trae की step-summarization feature जो हर step पर agent ने क्या किया इसकी छोटी readable summaries produce करती है। Lakeview अक्सर fire होता है और इसका output glanceable prose है, जो इसे एक fast id के लिए textbook slot बनाता है जबकि main loop एक frontier वाला रखता है। Configuration सिर्फ YAML से resolve नहीं होता: CLI per run --provider और --model flags accept करता है, और provider-specific environment variables, documented set में OPENAI_API_KEY और OPENAI_BASE_URL शामिल, same settings feed करते हैं। Flags वह तरीका है जिससे आप file छुए बिना एक दूसरा model A/B करते हैं।

पूरा setup: agent, Lakeview, और एक run।

Complete config agent को एक main model से और Lakeview को एक fast वाले से bind करता है, दोनों same provider entry के through। इस indirection को नोट करें: agents.trae_agent.model models में एक entry का नाम लेता है, और उस models entry का model_provider एक provider का नाम लेता है। किसी भी reference में typo पूरी chain fail करता है, तो तीनों names को consistent रखें। एक historical note जो ज़्यादातर confused tutorials explain करता है: Trae Agent की configuration पहले trae_config.json होती थी, और repo अब उस format को legacy और YAML को current documenting करता है। JSON दिखाने वाले guides पुराने layout describe कर रहे हैं; keys migrate हो गईं, concepts carry हुए। अगर आपके पास एक पुराना JSON config है, repo का legacy-config doc mapping cover करता है। One-key angle खासकर इस tool के लिए बताने लायक है। Trae Agent की native provider list American और Chinese vendors के across फैली है, जिसका मतलब आमतौर पर per vendor एक account और key होता है, जिनमें से कुछ आप जहां बैठे हैं उसके हिसाब से पाना मुश्किल है। एक gateway entry के पीछे, claude-sonnet-4-6, gpt-5.5, deepseek-v4-pro, glm-5.2, और kimi-k2.7-code सब एक model-string दूर हैं, एक key पर, एक balance के साथ, Pacific के किसी भी तरफ से आप develop करें।

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

Agent loop के लिए models चुनना।

--provider और --model flags comparison workflow को concrete बनाते हैं: same task को अलग-अलग flags के साथ दो बार चलाएं, console में steps-to-done और priced usage per model पढ़ें, और winner को trae_config.yaml में promote करें।

• Main loop long-horizon tool work है: files पढ़ना, edit करना, bash चलाना, यह judge करना कि task कब done है। claude-sonnet-4-6 और gpt-5.5 दो सौ-step plan को साथ रखते हैं; यह slot economize करने की आखिरी जगह है।
• Lakeview high-frequency, low-stakes summarization है। claude-haiku-4-5-20251001 या deepseek-v4-flash इसे main loop के spend के मुकाबले effectively free रखते हैं।
• kimi-k2.7-code और glm-5.2 Chinese comments, commit history, या docs वाले codebases पर main loop के लिए serious candidates हैं; एक bilingual repo वह जगह है जहां वे English-first models को comprehension पर मात देते हैं, सिर्फ price पर नहीं।
• deepseek-v4-pro batch runs के लिए volume pick है, कई repos पर same fix sweep करना या CI में agent चलाना, जहां per-task cost multiply होती है।
• max_steps आपका cost governor है। एक model जो भटकता है steps burn करता है; candidates compare करते समय, same task पर steps-to-done compare करें, per request tokens नहीं।

जितना उपयोग उतना भुगतान · आधिकारिक मूल्य से कम

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

Trae Agent के लिए specific failure modes।

JSON-versus-YAML confusion हर चीज़ की तरफ ले जाती है। एक पुराने guide से copy किया गया trae_config.json legacy के तौर पर पढ़ा जाता है ज़्यादा से ज़्यादा और ignore होता है कम से कम, और symptom है CLI ऐसे behave करता है जैसे आपने कभी कुछ configure ही ना किया हो। Current setups trae_config.yaml में belong करते हैं; guessing key names की बजाय repo के legacy-config doc से पुराने files migrate करें। Three-name chain चुपचाप टूटती है। agents.trae_agent.model को models में एक entry का नाम लेना चाहिए, और उस entry के model_provider को model_providers में एक entry का नाम लेना चाहिए। एक rename करें और बाकी नहीं, और run startup पर एक resolution error के साथ fail होती है, request error नहीं, जो आपको YAML की तरफ point करती है, network की तरफ नहीं। base_url को /v1 शामिल चाहिए, upstream example से match करते हुए जो एक router के /v1 root पर point करता है। एक bare host 404s produce करता है एक बार client chat-completions path append कर दे। Agent काम करते हुए Lakeview fail होना मतलब lakeview_model एक ऐसी id reference करता है जो endpoint serve नहीं करता, miss करना आसान क्योंकि आपने main model test किया और दूसरा slot भूल गए। और environment variables चुपचाप एक provider back करते हुए जिसे आप file-configured सोचते थे, खासकर OPENAI_API_KEY, तब check करने लायक जब authentication shells के बीच inconsistently behave करे।

कौन Trae Agent को एक gateway के through route करता है।

• Developers जो Claude या GPT को agent loop drive करते हुए चाहते हैं और GLM, Kimi, या DeepSeek एक flag दूर, हर vendor पर account रखे बिना।
• Bilingual teams जो Chinese और English codebases के across काम करती हैं, जिनके लिए per repo strongest model किसी भी ecosystem से आ सकता है, एक key से addressable।
• Engineers जो batch या CI agent tasks चलाते हैं, जहां per-key usage tracking trae-cli runs के एक fleet को एक readable cost report में बदल देती है।
• Researchers जो agent models benchmark करते हैं, चूंकि Trae Agent ablation-style comparison के लिए बना है और gateway हर candidate को same one-flag change बना देता है।
• Developers जिनके पास किसी given vendor की billing तक access नहीं है। बिना card requirement वाला top-up based access per-provider sign-up dependency हटा देता है।

Endpoint verify करें और पहली task को debug करें।

पहली run से पहले confirm करें endpoint आपकी ids serve करता है: अपनी key के साथ /v1/models listing YAML में हर model field के लिए authoritative spelling है, main slot और Lakeview slot दोनों। First-run failures cleanly sort होती हैं। किसी request से पहले एक config resolution error three-name chain या एक legacy JSON file है। एक 401 provider block में api_key है, या इसे override करने वाला एक environment variable। हर request पर एक 404 base_url से छूटा /v1 है। एक model-not-found error उस slot का नाम लेती है जो गलत है, check करें कि यह agent model था या Lakeview model। और एक run जो शुरू होती है पर task के बीच stall हो जाती है आमतौर पर endpoint fail होने की बजाय model का भटकना है, जिसके लिए max_steps और step log हैं। एक बार tasks चलने लगें, APIsRouter console per-request model, token counts, और spend दिखाता है। एक agent जो per task सौ steps लेता है हर चीज़ को multiply करता है, और usage log वह जगह है जहां आप सीखते हैं कि हर candidate model पर एक task genuinely क्या खर्च करती है।

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

अक्सर पूछे जाने वाले प्रश्न