Continue を、カスタムの OpenAI 互換エンドポイントに向ける。

早わかり: provider openai と apiBase を持つモデルブロック。

Continue の openai プロバイダーは apiBase の上書きを受け付けます。これがあらゆる OpenAI 互換サーバー向けにドキュメント化されている経路です。config.yaml にモデルブロックを追加し、provider を openai に、apiBase を https://api.apisrouter.com/v1 に、そして正確なモデル id とあなたのキーを設定します。そのモデルは Continue のモデルセレクターに現れ、発行されるすべてのリクエストは標準の /v1/chat/completions でゲートウェイへ向かいます。 同じ仕組みが好きなだけ多くのモデルをカバーします。id ごとに1ブロック、すべてが同じ apiBase とキーを共有します。Continue はモデルフィールドを単なる文字列として扱うため、異なるベンダーの id、Claude の隣に GPT、その隣に DeepSeek が、1つの設定ファイルの中に並びます。

models:
  - name: Claude Sonnet 4.6
    provider: openai
    model: claude-sonnet-4-6
    apiBase: https://api.apisrouter.com/v1
    apiKey: sk-APIsRouter-...
    roles:
      - chat
      - edit
      - apply

Continue が作業をモデルに割り当てる仕組み: role。

Continue(GitHub 上では continuedev、スター数はおよそ34K)は VS Code と JetBrains 向けの IDE エージェントで、その設定思想の核となるのが role です。すべてのモデルブロックは roles のリストを持ち、Continue は各種の作業をその role を持つモデルに振り分けます。chat は会話パネルとエージェント作業向け、edit はインラインのコード変換向け、apply は提案された変更をファイルに統合する作業向けで、さらに autocomplete・embed・rerank がそれぞれのサブシステム向けに用意されています。 マルチベンダーのエンドポイントが Continue において特に面白くなるのは、このレバーがあるからです。chat には正当化できる範囲で最も強力なモデルが欲しく、edit と apply はより短く機械的な呼び出しなので、速い中位クラスの id で十分です。1つの apiBase があらゆるベンダーを提供している状態なら、この分割は純粋な YAML の問題になります。chat を持つ Claude の id、edit と apply を持つ速い id、そのすべてに1つのキー、という具合です。 一点はっきりさせておくべき境界があります。autocomplete は fill-in-the-middle 型のワークロードであり、Continue の autocomplete role は、その補完形式向けに訓練されたモデルを前提に組まれています。チャット補完のゲートウェイは chat・edit・apply のトラフィックには適した場所ですが、autocomplete は今使っている FIM 対応のセットアップのまま保っておき、この role をチャットモデルに割り当てて良い提案を期待しないでください。

フルセットアップ: 複数モデル・role の分割・コンテキストの宣言。

設定ファイルは ~/.continue/config.yaml にあります。各ブロックの name はセレクターに表示されるラベルで、model はゲートウェイが提供する正確な id です。defaultCompletionOptions.contextLength はそのモデルのコンテキストウィンドウを宣言し、Continue はこれを使ってリクエストにどれだけの会話・ファイル文脈を詰め込むか判断するため、長文脈モデルで控えめなデフォルトのままにしておくと、本来より早く切り詰められてしまいます。 機能は通常自動検出されますが、Continue が認識していない id については明示的に宣言できます。capabilities: [tool_use] とすれば、エージェントモードがそのモデルでツールを動かせることを伝えられます。 キーについては、YAML はリテラルな apiKey を受け付けます。一度も外に出ないローカルファイルであれば問題ありません。Continue は ${{ secrets.APISROUTER_API_KEY }} という形のシークレットテンプレート構文にも対応しており、hub 経由で管理される設定ではリテラルな値を共有ファイルから排除できます。設定ファイルがどこに置かれるかに合わせて、どちらの形式を使うか選んでください。

models:
  - name: Claude Sonnet 4.6
    provider: openai
    model: claude-sonnet-4-6
    apiBase: https://api.apisrouter.com/v1
    apiKey: ${{ secrets.APISROUTER_API_KEY }}
    roles: [chat, edit]
    capabilities: [tool_use]
    defaultCompletionOptions:
      contextLength: 200000

  - name: Claude Haiku 4.5
    provider: openai
    model: claude-haiku-4-5-20251001
    apiBase: https://api.apisrouter.com/v1
    apiKey: ${{ secrets.APISROUTER_API_KEY }}
    roles: [edit, apply]

  - name: GPT-5.5
    provider: openai
    model: gpt-5.5
    apiBase: https://api.apisrouter.com/v1
    apiKey: ${{ secrets.APISROUTER_API_KEY }}
    roles: [chat]

role ごとのモデル選び。

role の割り当ては比較の手段でもあります。edit と apply を固定したまま、chat ブロックだけを2つの候補 id の間で1週間ずつ入れ替え、キーごとの利用状況ビューにあなたの実際のワークロードでの差を語らせてください。候補ごとに必要なのは、同じエンドポイントに対する YAML 3行だけです。

• chat はエージェントループと長い会話を担います。ファイルを読み、編集を計画し、実際の文脈をもとに質問に答えます。フロンティア級のモデル(claude-sonnet-4-6、gpt-5.5)がここにふさわしく、トークンの大半もここに流れます。
• edit はハイライトされたコードの変換を担当します。呼び出しは chat より短く機械的なので、claude-haiku-4-5-20251001 や gpt-5.4-mini のような速い id が、結果を落とすことなく edit ループを軽快に保ちます。
• apply は提案された変更をファイルに統合します。3つの role の中で最も機械的で、最も安価で有能なモデルの候補としてはっきりしており、deepseek-v4-flash も含まれます。
• embed と rerank はコードベースの検索を担う別のサブシステムで、それぞれ独自のモデル形状を持ちます。chat のトラフィックをゲートウェイに移しても、これらに手を入れる必要はありません。

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

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

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

/v1 のない apiBase。Continue は与えられたベースに /chat/completions のようなルートパスを付け足すので、https://api.apisrouter.com/v1 が正しく、素のホストでは動きません。初回利用での 404 らしきエラーは、ほぼ常にこれが原因です。 YAML のインデントが設定を静かに歪める。models はブロックのリストであり、インデントがずれた apiBase は誤ったエントリに、あるいはどこにも属さなくなります。あるモデルは動くのに隣のモデルが認証できないときは、ゲートウェイを疑う前に両者のインデントを diff してください。 レガシーな completions トグル。openai プロバイダーはデフォルトで /chat/completions を使い、これはゲートウェイが提供しているものです。useLegacyCompletionsEndpoint: true にすると、そのブロックはレガシーな /completions ルートにリダイレクトされ、設定していると、そのモデルの chat 形式のリクエストが動かなくなります。 GPT 系 id に対する Responses API の期待。Continue の一部の経路は、特定の OpenAI モデル名に対して新しい responses プロトコルを試すことがあります。チャット補完のゲートウェイはこのプロトコルを提供していないため、GPT 系のブロックがルート絡みの形でエラーになる場合は、そのブロックに useResponsesApi: false を設定して /chat/completions のままにしてください。 古びた contextLength。Continue は defaultCompletionOptions.contextLength に従って文脈を詰め込みます。モデルが実際に受け付けられる量ではなく、です。200k のモデルに 32k を宣言しても目に見えて壊れるわけではありませんが、支払い済みの文脈を静かに捨てているだけです。そのモデルが本当にサポートする値を宣言してください。

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

• ベンダーごとに1組の認証情報を維持するのではなく、VS Code や JetBrains の中で Claude・GPT・DeepSeek を選択可能にしたい、IDE 中心の開発者。
• コストプロファイルごとに role を分けたいチーム。フロンティア級の chat、速い edit と apply、それぞれの role にふさわしい id を割り当て、すべてを1つの請求面にまとめます。
• 実際の作業で chat モデルを比較するエンジニア。候補ごとに必要なのは同じ apiBase に対する YAML ブロック1つで、新しいプロバイダー統合ではありません。
• オンボーディングを標準化したいチームリード。config.yaml のテンプレート1つと APISROUTER_API_KEY 1つがベンダーごとの鍵チェックリストを置き換え、キーごとの利用状況が各席の支出を示します。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

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

YAML を編集する前に、ゲートウェイが何を提供しているかを一覧してください。/v1/models が返す id は、モデルフィールドが一致すべき文字列そのものです。 最初のリクエストの失敗にはパターンがあります。401 はその特定のブロックのキーが誤っているか、シークレット参照が解決されていないことを意味します。ファイル全体ではなく失敗したブロックを確認してください。キーはブロックごとなので、失敗もブロックごとに起きます。モデル未検出エラーは、バージョンサフィックスも含めた id のタイプミスです。GPT 系 id でのルート絡みのエラーは、上で扱った Responses API のトグルを指しています。そして拡張機能にカスタムモデルがまったく表示されない場合は、YAML がパースされていません。まずファイル構造を検証してください。 リクエストが流れ始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。Continue は作業を role ごとに分けるため、この利用状況ビューは、あなたの実際のワークロードにおける chat 対 edit のトラフィック比率を最初に見られる場所でもあり、それこそがモデル選びが実際に効いてくる数字です。

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

よくある質問