Cline を、カタログの任意のモデルで OpenAI Compatible 経由に。

早わかり: Cline の設定にある3つの項目。

VS Code の Cline パネルを開き、設定の歯車アイコンをクリックします。API Provider のドロップダウンで OpenAI Compatible を選び、3つの項目を埋めます。Base URL に https://api.apisrouter.com/v1、API Key にあなたのキー、モデル欄に正確なカタログ id(例: claude-sonnet-4-6)です。 Cline は任意のエンドポイントのモデルが何をできるか知りようがないため、このプロバイダーはモデル設定のオプションを公開しており、正直に設定する必要があります。コンテキストウィンドウのサイズ、最大出力トークン数、画像対応などの機能フラグ、そして任意で Cline 自身のコスト表示を実態に合わせるための入出力価格です。ウィンドウと上限はそのモデルのドキュメントに沿って設定してください。保存すれば、エージェントは次のタスクからゲートウェイ経由で動き、id はいつでもワークフローに手を入れずに差し替え可能です。

API Provider:  OpenAI Compatible
Base URL:      https://api.apisrouter.com/v1
API Key:       sk-YOUR-APISROUTER-KEY
Model:         claude-sonnet-4-6

Model config:  context window + max output tokens
               from the model's documentation,
               image support only if the id has it

Cline が設定済みモデルをどう使うか。

Cline(GitHub スター数はおよそ65K)は VS Code 向けの自律型コーディングエージェントです。あなたのコードベースを読み、ファイルを編集し、ターミナルコマンドを実行し、失敗を繰り返し修正します。その過程では人間による承認ゲートを挟みながら進みます。このループは特有の形でモデルを大量に消費します。長い文脈(ファイルツリー、diff、ターミナル出力)が入り、ツール呼び出しとコードが出力され、1タスクあたり何ターンも続きます。 OpenAI Compatible プロバイダーは、このループを標準的なチャット補完として Base URL に送り、モデル id は単なる文字列として扱われます。ワイヤーフォーマットにベンダーは関係なく、これがここでのモデル選びを現実的なものにしています。claude-sonnet-4-6、kimi-k2.7-code、gpt-5.6-sol は、同じ3つの項目の裏で入れ替え可能なバックエンドとなり、3つのベンダーアカウントを伴う3つの別々のプロバイダー設定を用意する必要はありません。 機能フラグは、エージェントがそれに依存する分、注意深く扱う価値があります。Cline はあなたが宣言した内容をもとに計画を立てます。画像対応を有効にすると、画像を受け付けないかもしれないモデルにもスクリーンショットを送ってしまいますし、実際より大きく申告されたコンテキストウィンドウは、長いタスクの奥深くで文脈切り詰めによる失敗を招きます。モデルのドキュメントが述べている内容を宣言してください。希望的観測ではなく。

Plan と Act: 2つのモード、2つのモデル。

Cline は作業を、コードベースを探索し編集せずに戦略を立てる Plan モードと、それを実行する Act モードに分けます。API 設定もこの分割に沿っています。異なるモデルを使うオプションを有効にすると、設定画面にモードごとのタブが表示され、各モードは自分専用のプロバイダーとモデルを記憶し、モード切り替えに合わせて自動で切り替わります。 この分割の経済性こそが要点です。Plan モードは深い推論が報われる場面で、claude-opus-4-7 や gpt-5.5 がコードベースを読んで方針を書きます。Act モードはすでに存在する計画を実行する、速いツール呼び出しの多いターンの連続で、これはまさに kimi-k2.7-code や claude-sonnet-4-6 の得意な形です。どちらのモードも同じゲートウェイのキーを通じて課金されるので、この組み合わせはマルチベンダーのプロジェクトではなく単なる設定の選択です。 Issue トラッカーからの正直な注意点を一つ。モードごとのモデル選択は、特に OpenAI Compatible プロバイダー絡みで粗さが報告されており、Act モードが Plan モデルを黙って使い続けてしまう例も含まれます。この分割を設定したら、1回タスクを走らせてタスクヘッダーで実際にどのモデルが各モードを処理したかを確認し、利用ログもチェックしてください。両方の id が実際に現れるのを見て初めて、分割が検証済みだと扱ってください。

Plan mode:  claude-opus-4-7      (read, reason, strategize)
Act mode:   kimi-k2.7-code       (execute, edit, run, iterate)

verify: run one task, check which id served each mode,
then confirm both ids appear in the usage log

エージェントループ向けのコーディングモデルの選び方。

エージェントループはチャットとは違う形でトークン消費を増幅させます。1つの Cline タスクだけでも、ファイル文脈を伴う何十ものリクエストになり得ます。だからこそモデル選びは計測可能です。同じ種類のタスクを2つの id で1週間走らせ、モデルごとの支出と、どれだけ介入が必要だったかを並べて読んでみてください。

• claude-sonnet-4-6 は Act モードの作業に対する既定の答えです。頼れるツール呼び出し、堅実な diff、失敗したコマンドから立ち直る十分な判断力を備えています。
• kimi-k2.7-code は長いエージェントセッション向けのボリューム枠です。コーディングに特化し、速く、Cline が実際に走らせる多ターンのループに合わせた価格設定です。
• gpt-5.6-sol は、ターンごとのレイテンシがセッションの体感を左右する、素早く範囲の限定された編集やテスト修正の作業で活躍します。
• claude-opus-4-7 は難しいタスクの Plan モードに向いています。アーキテクチャ変更、複数ファイルにまたがるリファクタリング、全体像が必要なデバッグなどです。
• gpt-5.5 は、あなた自身のコードベース上で(ベンチマークではなく)Plan モードの Claude と比較するに値する、強力な汎用モデルです。

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

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

Cline に特有の失敗パターン。

タスクの奥深くで文脈が切り詰められた、あるいは忘れっぽい挙動が出るのは、コンテキストウィンドウの申告が原因です。モデルがドキュメントで公開しているウィンドウに設定してください。そして Cline はファイル文脈を積極的に詰め込むので、実際より大きく申告されたウィンドウは、まさに一番大きく厄介なタスクで破綻します。 ツール呼び出しのおかしな挙動、壊れた編集、あるいは行動する代わりにナレーションばかりするエージェントは、たいてい選んだ id がファンクションコールに弱いことを意味します。claude-sonnet-4-6 に切り替えて、設定の問題なのかモデル選びの問題なのかを切り分けてから、セットアップを責めてください。 ハードエラーはきれいに対応します。認証エラーはキー欄、モデル未検出は /v1/models のリストに対する id のスペル、そしてすべてのリクエストで 404 が出るのは Base URL に /v1 が欠けているか二重になっているかです。プロバイダーは、与えたベースにルートパスを付け足します。 そしてモードごとの注意点をもう一度。見落とすと実際にお金がかかるからです。Plan モデルと Act モデルを別々に設定したなら、両方の id が実際にそのモードを処理しているか、実タスクで検証してください。すべての Act ターンで高価な Plan モデルに黙ってフォールバックしてしまうようなことは、利用ログなら初日に気づけますが、カードの明細なら月末にしか気づけません。

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

• Anthropic との請求関係を持たずに Claude をエージェントに使わせたい開発者。カード不要で始められる前払い残高で。
• 自分のコードベースの実タスクでコーディングモデルを比較するモデル選びの人。候補ごとにモデル欄を1行変えるだけです。
• 高価な Plan モデルと高速な Act モデルをペアにして、計画の質を落とさずに長いセッションを手頃に保ちたいヘビーな Cline ユーザー。
• エージェントの支出を開発者ごと、プロジェクトごとに計測したいチーム。共有のベンダー請求から推測するのではなく。
• すでにターミナルやエディターのツールをゲートウェイ経由にしていて、VS Code のエージェントも同じキーとログに乗せたい開発者。

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

まずモデル一覧と1回のチャット補完を、設定しようとしている正確な id で curl してください。両方通れば、ゲートウェイ側は完了で、残る症状はすべてプロバイダー設定の側にあります。 次に Cline に小さな実タスクを与えます。1ファイル、明確な目標、そして最初の数ターンを見守ってください。きれいなツール呼び出しと妥当な編集が出るなら、id と機能フラグは合っています。エラーは3つの項目のいずれかに対応し、おかしなエージェントの挙動はモデル選びか申告した機能に対応します。モードごとのモデルを有効にしたなら、この最初のタスクがその分割の検証も兼ねます。 タスクが流れ始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。エージェントループはモデルの使い方の中でもっともトークンを消費する形態であり、キーごとの利用状況ビューこそが、Cline の1週間分がモデルごと、1日ごと、モードごとに具体的な数字になる場所です(キーを分けていれば、モードごとに分かります)。

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

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"kimi-k2.7-code",
       "messages":[{"role":"user","content":"ping"}]}'

よくある質問