Trae Agent を、すべてのモデルのために1つのエンドポイントに向ける。

早わかり: プロバイダーのブロック1つ、モデルのブロック1つ。

Trae Agent の現行の設定は YAML です。プロジェクトディレクトリの trae_config.yaml に、関連する3つのブロックがあります。model_providers はエンドポイントを定義し、各エントリは api_key・provider・base_url を取るため、OpenAI 互換のゲートウェイは、base_url を差し替えただけの openai タイプのプロバイダーにすぎません。models は、model_provider を通じてプロバイダーを参照する名前付きのモデル設定を定義します。agents は trae_agent をそれらのモデル名の1つに結び付けます。 upstream の README は、マルチモデルサービスを経由するルーティングについて、まさにこの形を示しています。そのサービスの /v1 ルートを指す base_url を持つ openai プロバイダーのエントリです。APIsRouter の場合、それは https://api.apisrouter.com/v1 であり、model フィールドはその後、Claude や Kimi の id も含め、任意のカタログ id をそのままの文字列として取ります。プロバイダーのタイプが決めるのはリクエストの形式だけで、ベンダーではないからです。

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 が、内部でどう配線されているか。

Trae Agent(GitHub 上では bytedance、スター数はおよそ12K)は、ByteDance によるコマンドライン向けのリサーチ指向のソフトウェアエンジニアリングエージェントです。trae-cli にタスクを与えると、透明なツールループ(bash、ファイル編集、逐次思考が組み込みツールに含まれます)でそれに取り組み、設定可能な max_steps まで続きます。意図的にモジュール化されており、それが設定がプロバイダー・モデル・エージェントを分離している理由です。同じプロバイダーが複数のモデル設定を支えることができ、エージェントが何の上で動くかを入れ替えるのは、名前参照の1行編集で済みます。 実践的に重要なモデルスロットは2つです。trae_agent_model はメインループであり、推論・ツール呼び出し・編集を行うモデルです。max_steps が200であるということは、1つのタスクが長い一連の課金対象呼び出しになり得るということです。lakeview_model は Lakeview を動かします。これは Trae のステップ要約機能であり、エージェントが各ステップで何をしたかの短く読みやすい要約を生成します。Lakeview は頻繁に発火し、その出力はさっと読める文章であるため、メインループがフロンティアの id を保つ一方で、速い id にとっての教科書的なスロットになります。 設定は YAML 以上のものから解決されます。CLI は実行ごとに --provider と --model のフラグを受け付け、プロバイダー固有の環境変数(ドキュメント化されているものの中に OPENAI_API_KEY と OPENAI_BASE_URL があります)が同じ設定を供給します。ファイルに触れることなく2つ目のモデルを A/B するには、このフラグを使います。

フルセットアップ: エージェント、Lakeview、そして実行。

完全な設定は、エージェントをメインモデルに、Lakeview を速いモデルに結び付け、どちらも同じプロバイダーエントリを経由します。間接参照に注意してください。agents.trae_agent.model は models の中のエントリを名指し、その models のエントリが model_provider を通じてプロバイダーを名指しします。どちらかの参照のタイプミスは連鎖全体を失敗させるため、3つの名前は一致させておいてください。 ほとんどの混乱したチュートリアルを説明する、歴史的な注記が1つあります。Trae Agent の設定は、かつて trae_config.json でした。リポジトリは今、そのフォーマットをレガシーとしてドキュメント化し、YAML を現行の形としています。JSON を示すガイドは古いレイアウトを説明しているものであり、キーは移行しても概念は引き継がれています。古い JSON の設定を持っている場合は、リポジトリのレガシー設定ドキュメントがそのマッピングをカバーしています。 このツールにとって特に価値のある、キー1つという観点も述べておく価値があります。Trae Agent のネイティブなプロバイダー一覧は米国と中国のベンダーにまたがっており、通常はベンダーごとにアカウントとキーが必要で、あなたがどこにいるかによっては入手が難しいものもあります。1つのゲートウェイのエントリの裏では、claude-sonnet-4-6、gpt-5.5、deepseek-v4-pro、glm-5.2、kimi-k2.7-code は、すべて1つのモデル文字列の距離にあり、1つのキー、1つの残高で、太平洋のどちら側から開発していても関係ありません。

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

エージェントループのためのモデル選び。

--provider と --model のフラグが、比較のワークフローを具体的にします。同じタスクを異なるフラグで2回実行し、コンソールで完了までのステップ数とモデルごとの課金済み利用状況を読み、勝者を trae_config.yaml に昇格させてください。

• メインループは、長時間にわたるツール作業です。ファイルを読み、編集し、bash を実行し、タスクが終わったかを判断します。claude-sonnet-4-6 と gpt-5.5 は、200ステップの計画をまとめ続けます。このスロットは、最後に節約を考えるべき場所です。
• Lakeview は高頻度で低リスクな要約です。claude-haiku-4-5-20251001 や deepseek-v4-flash は、メインループの支出に対してそれを事実上無料に保ちます。
• kimi-k2.7-code と glm-5.2 は、中国語のコメント・コミット履歴・ドキュメントを持つコードベースでは、メインループの真剣な候補です。バイリンガルなリポジトリは、単に価格だけでなく理解力の面で、これらが英語優先のモデルに勝る場面です。
• deepseek-v4-pro は、多くのリポジトリに同じ修正をスイープしたり、CI でエージェントを走らせたりするようなバッチ実行のためのボリューム選択です。タスクあたりのコストが乗算される場面です。
• max_steps はあなたのコストガバナーです。迷走するモデルはステップを消費します。候補を比較する際は、リクエストあたりのトークンではなく、同じタスクでの完了までのステップ数を比較してください。

従量課金 · 公式価格より安い

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

Trae Agent に特有の失敗パターン。

JSON と YAML の混同がすべての元凶です。古いガイドからコピーされた trae_config.json は、良くてレガシーとして読まれ、悪ければ無視されます。症状は、CLI がまるで何も設定していないかのように振る舞うことです。現行のセットアップは trae_config.yaml に属します。キー名を推測するのではなく、リポジトリのレガシー設定ドキュメントを使って古いファイルを移行してください。 3つの名前の連鎖は静かに壊れます。agents.trae_agent.model は models のエントリを名指ししていなければならず、そのエントリの model_provider は model_providers のエントリを名指ししていなければなりません。片方だけをリネームして他方をリネームしないと、実行はリクエストエラーではなく起動時の解決エラーで失敗し、ネットワークではなく YAML を見るべきだと示してくれます。 base_url には /v1 を含めてください。ルーターの /v1 ルートを指す upstream の例と一致させます。裸のホストは、クライアントがチャット補完のパスを付加した時点で 404 を生みます。 エージェントは動くのに Lakeview だけが失敗する場合、lakeview_model がエンドポイントが提供していない id を参照しているということです。メインモデルはテストしたのに2つ目のスロットを忘れがちなので見落としやすいところです。そして、ファイル設定だと思っていたプロバイダーを、環境変数(特に OPENAI_API_KEY)が静かに支えている場合もあり、認証がシェル間で一貫しない振る舞いをするときは確認する価値があります。

ゲートウェイ経由で Trae Agent を使うのは誰か。

• Claude や GPT にエージェントループを動かしてほしく、GLM・Kimi・DeepSeek にもフラグ1つで手を伸ばしたい開発者で、各ベンダーにアカウントを持つ必要のない人。
• 中国語と英語のコードベースを横断して作業するバイリンガルなチームで、リポジトリごとに最も強いモデルがどちらのエコシステムから来るかもしれず、1つのキーでアドレスできる場合。
• バッチや CI のエージェントタスクを実行するエンジニアで、キーごとの利用状況の追跡が、大量の trae-cli 実行を読みやすいコストレポートに変えてくれる人。
• エージェントモデルをベンチマークする研究者。Trae Agent はアブレーション形式の比較のために作られており、ゲートウェイはすべての候補を同じ1フラグの変更にしてくれます。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

エンドポイントを検証し、最初のタスクをデバッグする。

最初の実行の前に、エンドポイントがあなたの id を提供していることを確認してください。あなたのキーによる /v1/models 一覧が、YAML の中のすべての model フィールド(メインスロットと Lakeview スロットの両方)にとって正しい綴りの根拠です。 最初の実行の失敗はきれいに分類できます。どのリクエストの前に起きる設定解決エラーも、3つの名前の連鎖か、古い JSON ファイルが原因です。401 はプロバイダーブロックの中の api_key か、それを上書きする環境変数の問題です。すべてのリクエストでの 404 は、/v1 を失った base_url です。model-not-found エラーは、間違っているスロットを示します。エージェントのモデルか Lakeview のモデルか確認してください。そして、開始はするもののタスクの途中で止まる実行は、通常はエンドポイントの失敗ではなくモデルの迷走です。それを見るために max_steps とステップログがあります。 タスクが実行されたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。タスクごとに100ステップを踏むエージェントはすべてを乗算するため、利用ログこそが、各候補モデルで1つのタスクが実際にいくらかかるかを知る場所です。

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

よくある質問