Aider を、OpenAI 互換の API ベースに向ける。

早わかり: 環境変数2つとモデルプレフィックス。

Aider がドキュメント化している OpenAI 互換の経路はまさにこれです。OPENAI_API_BASE にエンドポイントを、OPENAI_API_KEY にそのキーを export し、モデル名の先頭に openai/ を付けて、Aider にそのベースへ向けてチャット補完プロトコルを話させます。プレフィックスの後ろの文字列はそのままエンドポイントに渡されるので、ゲートウェイが提供する id なら何でも使えます。Claude や DeepSeek の id も含めてです。 これで接続は完了です。Mac と Linux では export を、Windows では setx を使い、setx は現在のセッションには効かないため新しいシェルを開いてください。同じ値は、シェルの状態の代わりに Aider の設定ファイルや .env ファイルに置いても構いません。プロジェクトごとの設定を好むならその方が向いています。

export OPENAI_API_BASE=https://api.apisrouter.com/v1
export OPENAI_API_KEY=sk-APIsRouter-...

aider --model openai/claude-sonnet-4-6

Aider がモデルとプロバイダーをどう解決するか。

Aider(GitHub の Aider-AI、スター数はおよそ47K)は元祖ともいえるターミナル型ペアプログラマーです。あなたの git リポジトリをマッピングし、チャットで変更依頼を受け、ファイルを直接編集し、結果をコミットします。裏側ではモデル呼び出しを litellm 経由でルーティングしており、だからこそ openai/ プレフィックスが重要になります。litellm はこのプレフィックスを読んでプロバイダーのプロトコルを選び、openai/ は「OPENAI_API_BASE が示す先へチャット補完で話す」ことを意味します。プレフィックスのないモデル名は、代わりにその綴りからプロバイダーが推測され、Claude の id なら Anthropic のネイティブ API と、あなたのゲートウェイではなく ANTHROPIC_API_KEY の方へルーティングされてしまいます。 初回セッションの前に知っておく価値のある、Aider 特有の挙動が一つあります。Aider は独自のモデル機能レジストリを持っており、認識していないモデルに対しては「Unknown context window size and costs, using sane defaults」という警告を出します。その後 Aider はコンテキストウィンドウが無制限でコストがゼロだと想定します。セッション自体は動作しますが、2つの有用なサブシステムが劣化します。トークン予算管理は実際のコンテキスト上限を超える前に警告できなくなり、セッション中のコスト表示はゼロのままになります。対処法は小さなメタデータファイルで、下記で扱っており、2分の手間をかける価値があります。 Aider は1セッションで複数のモデルも動かします。メインモデルが実際のコーディングを担い、ウィークモデルがコミットメッセージやチャットの要約を処理し、アーキテクトモードでは別のエディターモデルが計画を適用します。いずれも同じ openai/ プレフィックスを受け付けるので、3つすべてを1つのキーでゲートウェイ経由に通せます。

フルセットアップ: 接続に加えてモデルメタデータ。

接続自体は上記の2つの環境変数だけです。仕上げは、Aider がゲートウェイのモデルを既知のものとして扱えるよう、メタデータを登録することです。ホームディレクトリ、git リポジトリのルート、あるいは作業ディレクトリ(または --model-metadata-file の指定)のいずれかに .aider.model.metadata.json を作成し、openai/ プレフィックスを含む完全修飾名をキーにします。litellm_provider フィールドはそのプレフィックスと一致させてください。max_input_tokens を登録しておけば、Aider のコンテキスト予算管理は無限だと仮定するのではなく、モデルの実際のウィンドウに対して機能します。 もう一つ任意のファイル .aider.model.settings.yml で、モデルごとの挙動を調整できます。edit_format は Aider がどのようにコード変更を依頼するかを制御し(diff 系のバリエーションを扱えるモデルにはそれを、扱えないモデルにはファイル全体を)、use_repo_map はリポジトリ文脈の含め方を制御します。Aider は認識していないモデルに最適な編集形式を推測できないため、これを明示的に宣言するかどうかが、あるモデルが平凡に見えるか本来の実力を発揮するかの分かれ目になります。

{
  "openai/claude-sonnet-4-6": {
    "max_input_tokens": 200000,
    "max_output_tokens": 64000,
    "litellm_provider": "openai",
    "mode": "chat"
  },
  "openai/deepseek-v4-pro": {
    "max_input_tokens": 128000,
    "max_output_tokens": 16000,
    "litellm_provider": "openai",
    "mode": "chat"
  }
}

メイン・ウィーク・エディターモデルの選び方。

Aider のセッションは長く反復的なので、モデル比較が意外なほど正直に現れます。同じ機能ブランチを2つのメインモデルで別々の日に走らせれば、その差は /undo をどれだけ打ったかに表れます。1つのエンドポイントにまとめておけば、候補ごとの切り替えはフラグの変更だけで済み、キーごとの利用状況が各実験の値段を教えてくれます。

• メインモデルはすべての編集を担います。リポジトリマップを読み、あなたのファイルについて推論し、diff を生成します。だからこそ claude-sonnet-4-6 や gpt-5.5 の出番であり、diff の構文でつまずくモデルは、変更のたびにレビューの手間としてコストを払うことになります。
• ウィークモデル(--weak-model)はコミットメッセージを書き、チャット履歴を要約します。頻繁に実行される一方コードには一切触れないので、これを他の何かにデフォルトのまま任せるのではなく、同じゲートウェイ経由の速く安価な id にルーティングしましょう。
• アーキテクトモードは計画と編集を分離します。メインモデルが計画し、エディターモデル(--editor-model)がそれを適用します。強力な推論モデルが計画し、kimi-k2.7-code のようなコーディング特化 id が適用する組み合わせは、単一ベンダーのキーでは表現できません。
• deepseek-v4-pro と gpt-5.4 は、リファクタリングの多い作業で日常使いのメインモデルとしてベンチマークする価値があります。セッションあたりのトークン量が多いため、価格差が積み重なって効いてきます。

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

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

Aider 特有の失敗パターン。

「妥当なデフォルト」を信用してしまう。未知モデルへのフォールバックは、コンテキスト無制限・コストゼロを仮定します。実際には、長いセッションがモデルの実際のウィンドウを超えて膨らみ続け、ゲートウェイがリクエストを拒否するか、モデルが静かに初期の文脈を失うまで気づかず、その間コストトラッカーは何も表示しません。メタデータを登録すれば、どちらの問題も解消します。 openai/ プレフィックスを外してしまう。これがないと litellm はモデル名からプロバイダーを推測します。Claude の id は Anthropic の API 側にルーティングされ、ANTHROPIC_API_KEY が見つからず失敗します。これは一見キーの問題に見えますが、実際はプレフィックスの問題です。 メタデータの不一致。.aider.model.metadata.json のエントリは、プレフィックスを含む完全修飾名をキーとし、litellm_provider はそのプレフィックスと一致させる必要があります。素の id をキーにしたり、provider フィールドが食い違っていたりすると、エラーも出ないままデフォルトに戻ってしまいます。 Windows のシェル状態。setx は今後開くシェルにのみ変数を書き込みます。setx を実行したのと同じターミナルで aider を走らせると古い環境のままで、その結果生じる 401 はシェルのライフサイクルの問題であって、認証情報の問題ではありません。 編集形式の不一致。未登録のモデルは、そのモデルが最も得意とする形式とは限らないデフォルトの編集形式を割り当てられます。強力なモデルが Aider に拒否される編集を出し続けるなら、そのモデルがコーディングできないと結論づける前に、.aider.model.settings.yml で edit_format を明示的に設定してください。

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

• 毎日 Aider を使い、Claude・GPT・DeepSeek を --model でセッションごとに切り替えたい、しかしモデルファミリーごとにベンダーアカウントを維持したくない開発者。
• フロンティア級のメインモデルと高速なウィークモデルをペアにして、コミットメッセージ作成まで含めて1つのキーに集約し、セッションごとの可視性を得たい開発者。
• 異なるベンダーの計画モデルと編集モデルを同一セッション内で組み合わせる、アーキテクトモードのユーザー。
• ベンダーごとの鍵チェックリストではなく、1つのシークレットでエンジニアをオンボーディングしたいチーム。キーごとの利用状況がそのまま支出レポートになります。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

エンドポイントを検証し、最初のセッションをデバッグする。

開始前にゲートウェイのモデル一覧を確認してください。openai/ の後ろに続く id は、バージョンサフィックスも含めて、提供されている id と正確に一致している必要があります。 初回セッションの失敗は素早く切り分けられます。401 は、aider を起動したシェルから OPENAI_API_KEY が見えていないことを意味します(Windows では setx 後は新しいシェルのみ有効。同じターミナルで echo して確認してください)。ゲートウェイからのモデル未検出エラーは id のタイプミスです。別ベンダーのキーに言及するエラーは、プレフィックスなしのモデル名がネイティブルーティングされたことを示します。そして起動時の未知モデル警告はエラーではありませんが、長いセッションが実際のコンテキスト上限にぶつかってからではなく、その前にメタデータファイルを追加すべきというサインです。 セッション中は、メタデータを登録すれば Aider 自身のトークン・コスト表示も正確になり、APIsRouter コンソールは同じセッションをエンドポイント側から表示します。リクエストごとのモデル、トークン数、支出です。1日中動かすペアプログラマーにとって、このキーごとの view こそが、Aider の1週間分が実際にいくらかかったかへの正直な答えです。

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

よくある質問