どの無料LLMがコーディングに最適かを知りたいのであれば、率直な答えは、実行したいコーディングエージェントによって異なります。
Cline と Roo Code では、無料LLM APIの最初の選択肢としては通常、Gemini の OpenAI互換エンドポイント経由が最適です。これは、ファーストパーティの無料枠、ドキュメント化された OpenAI 風の base_url、そして料金を払う前に実際のエージェントプロンプトを試せる十分な互換性を備えているためです。Claude Code では答えが異なります。無料の OpenAI互換APIは、そのままでは直接差し替えできません。Claude Code はサポートされた Anthropic 形式のゲートウェイ経路を想定しており、Anthropic のドキュメントでも、ゲートウェイ経由で Claude Code を非Claudeモデルへルーティングすることはサポートしていないとされています。
この違いは、ランキングのスコアよりも重要です。コーディングエージェントは、単発の丁寧なチャットプロンプトを送るわけではありません。ツール呼び出しをストリーミングし、ファイルを確認し、エラー後に再試行し、無料枠をすぐに消費します。コーディングに最適な無料LLMモデルとは、実際に使うエージェントプロトコルを最後まで通せるものです。
このガイドでは、Claude Code、Cline、Roo Code 向けの無料LLM API経路を比較し、さらに、うっかりクォータの罠の上に構築してしまわないように、コーディングエージェントを試したい開発者向けの実用的な意思決定マトリクスを示します。
コーディングに最適な無料LLMはどれ?短い答え
どの無料LLMがコーディングに最適か について1つのデフォルト回答が欲しいなら、次のとおりです。
| ユースケース | 最適な無料の出発点 | 理由 |
|---|---|---|
| Cline のコーディングエージェント検証 | OpenAI互換性を通した Gemini API の無料枠 | ファーストパーティの無料枠に加え、ドキュメント化された OpenAI互換チャットエンドポイントがある |
| Roo Code のコーディングエージェント検証 | OpenAI互換性を通した Gemini API の無料枠 | Roo はカスタムの OpenAI互換プロバイダーをサポートするが、モデルはネイティブのツール呼び出しに対応している必要がある |
| Claude Code のゲートウェイ検証 | 汎用の無料 OpenAI API ではなく、Anthropic互換のゲートウェイ経路 | Claude Code のゲートウェイドキュメントは Anthropic 形式のエンドポイントとサポート対象の Claude トラフィックを中心にしている |
| 複数の無料モデルを素早く試す | OpenRouter の無料モデルバリアント | モデルのサンプリングには便利だが、無料バリアントには明示的なリクエスト上限と 429 の挙動がある |
| 速度の実験 | Groq の無料プラン | アカウント単位のレート制限と、プレビュー/本番モデルの区別があり、レイテンシ実験に役立つ |
| ローカルまたはエッジでの実験 | Cloudflare Workers AI またはローカルの Ollama/LM Studio | 既にその環境上でスタックが動いている場合に有効だが、「無料」でも日次割当、ハードウェア、またはプラットフォーム制限はある |
重要なルール: コーディングエージェント向けの無料LLM APIは、単一のコーディングプロンプトに対する回答品質だけでなく、ツール呼び出し、コンテキスト処理、再試行の挙動、クォータの可視性で判断すべきです。
何をテストしたか
この記事での「テスト済み」とは、開発者が実際に設定しなければならない3つのエージェント面に対するセットアップ準備テストを意味します。
- 拡張機能やCLIをパッチせずに、エージェントをカスタムAPIエンドポイントへ向けられるか?
- プロバイダーが、エージェントに一致する OpenAI互換または Anthropic互換の経路を公開しているか?
- そのモデル経路は、エージェント的なコーディングに必要なツール呼び出しの挙動をサポートしているか?
- 長いコーディングタスクを始める前に、レート制限、無料枠の上限、本番利用時の注意点が見えるか?
- チームが無料テストから、各ローカルエージェント設定を再変更せずに、ルーティングされ可観測なAPI構成へ移行できるか?
これは合成ベンチマーク表ではありません。正確な無料枠のクォータは変わり、アカウント階層も異なり、コーディングエージェントの挙動はツールの進化とともに変化します。役立つ比較は、無料経路が安全に試せるかどうか、そして最初に何が壊れるかです。
コーディングエージェントごとの互換性
Claude Code
Claude Code は、汎用の無料 OpenAI互換APIに対して最も扱いにくい対象です。
Anthropic は、ANTHROPIC_BASE_URL のような変数を介した Claude Code 用のゲートウェイ経路を文書化していますが、そのゲートウェイはサポートされたAPI形式を公開している必要があります。同じドキュメントでは、Anthropic はゲートウェイを通じて Claude Code を非Claudeモデルにルーティングすることをサポートしていないとも説明しています。また、ゲートウェイクレデンシャルを使うと、保存済みの Claude サブスクリプションログインではなくゲートウェイクレデンシャルがリクエストに使われるため、課金と利用上限の挙動が変わることも説明されています。
そのため、実務上の答えはシンプルです。Claude Code でコーディングに最適な無料LLMはどれかという問いに対しては、いきなりランダムな OpenAI互換の無料エンドポイントを差し込むのはやめましょう。まず Claude 互換の経路から始め、ゲートウェイは認証情報の扱い、課金、サポートされるプロトコルの挙動を理解してから使ってください。
Flatkey 自身のクイックスタートもこの違いを反映しています。Flatkey は、1つのキー、1つの残高、1つのモデルカタログ、SDK/API 用の OpenAI互換ルーター、そして Console 経由の Codex と Claude Code 向けの別設定経路を文書化しています。これにより、チームはエージェント設定を各ノートPCにプロバイダーキーをばらまく作業ではなく、インフラとして扱えます。
Cline
Cline は、無料API実験においてはかなり直接的です。
Cline の OpenAI互換プロバイダー設定では、Base URL、API Key、Model ID の3つの主要フィールドを求めます。また、最大出力トークン、コンテキストウィンドウ、画像サポート、computer use、入出力の価格想定といったモデル詳細も設定できます。
そのため、Gemini の OpenAI互換エンドポイントは Cline の強力なデフォルトになります。Google は、OpenAI互換の Gemini API ベースURLを次のように文書化しています。
https://generativelanguage.googleapis.com/v1beta/openai/したがって、Cline のテストは「OpenAI Compatible」を選択し、Gemini 互換のベース URL を貼り付け、Gemini API キーを追加し、コーディング対応モデルを選ぶだけで十分です。注意点はクォータです。エージェントのループは無料枠をすぐに消費してしまうため、モデルが悪いと決めつける前に、タスクを短く保ち、エラーを確認する必要があります。
Roo Code
Roo Code も OpenAI 互換プロバイダーをサポートしていますが、コーディングエージェントにとって重要な、より厳しい要件が追加されます。それが ネイティブのツール呼び出し です。
Roo のドキュメントでは、OpenAI 互換プロバイダーは Base URL、API Key、Model ID を使うと説明されていますが、Roo Code はネイティブのツール呼び出しのみを使用すると明記されています。モデルが OpenAI 互換の tool calling をサポートしていない場合、Roo Code では使用できません。
これにより、Roo における コーディングに最適な無料 LLM の答えが変わります。単体では良いコードを書けるモデルだけでは不十分です。Roo がファイルを読み取り、編集を適用し、ツールイベントを確実にストリーミングできるよう、function-calling/tool schema を十分にサポートしている必要があります。
Roo では、Gemini か、OpenAI 互換の tool calling を文書化している別のプロバイダーから始め、最初のタスクは小さく保ち、プロンプト調整に時間を費やす前にツール呼び出しのエラーを確認してください。
コーディングエージェント向けの無料 LLM API オプション
1. Gemini API の無料枠
Gemini は、多くの Cline と Roo Code のユーザーにとって最初に試すべき無料 LLM API です。Google が無料で始められる経路と OpenAI 互換の両方を文書化しているためです。料金ページでは、制限付きで無料で開発を開始でき、その後プリペイドまたは従量課金にスケールできると説明されています。OpenAI 互換のドキュメントでは、Gemini API が OpenAI ライブラリと chat/completions ルートで動作することが示されています。
次の場合はまず Gemini を使ってください:
- サードパーティのモデルルーターではなく、ファーストパーティのプロバイダーを使いたい。
- Cline または Roo Code 用に OpenAI 互換の base URL が必要。
- 無料テスト後の明確なアップグレード経路が欲しい。
- 一般的なコーディングタスク、リファクタリング、ドキュメント作成、小さなバグ修正をテストしている。
Gemini の無料枠を、運用環境のエージェントが安いことの証明として使わないでください。無料枠のトラフィックはテスト用のレーンです。長時間動作するコーディングエージェントには、有料のクォータプラン、リトライ方針、使用量追跡が必要です。
2. OpenRouter の無料モデルバリアント
OpenRouter は、作業がモデル探索である場合に役立ちます。:free で終わる ID を持つ無料バリアントを含め、多数のモデルバリアントを公開しています。制限に関するドキュメントでは、無料モデルのリクエスト上限、アカウントのクレジット履歴に応じた日次リクエスト上限、429 の挙動、現在の制限を確認するためのキー確認エンドポイントが説明されています。
次の場合は OpenRouter の無料バリアントを使ってください:
- 複数のオープンモデルまたはホスト型モデルをすばやく比較したい。
- リクエスト上限を受け入れられる。
- プロバイダーを決める前に、プロンプトとの相性を素早くテストしたい。
429、402、およびプロバイダー側の制限エラーを適切に処理できる。
長いリファクタリングでコーディングエージェントに予測可能なスループットが必要な場合、OpenRouter はあまり適していません。無料ルートは探索には十分ですが、本番のキャパシティ計画ではありません。
ここがボトルネックであれば、この記事を Flatkey の OpenRouter レート制限ガイドと組み合わせてください: OpenRouter Rate Limits: Why They Happen and How to Fix Them。
3. Groq の無料プラン
Groq は速度が実験の中心である場合に魅力的です。レート制限のドキュメントでは RPM、RPD、TPM、TPD、および関連する制限タイプが説明されており、モデルのドキュメントでは本番モデルとプレビューモデルが区別されています。これは、プレビューモデルは評価には役立つものの、安定した本番依存として扱うべきではないため重要です。
次の場合は Groq を使ってください:
- テストしているのがレイテンシである。
- コーディングタスクが無料プランの制限内で収まるほど短い。
- コーディングエージェントのツール要件に合う有効なモデルを選べる。
- より大きなモデルに課金する前に、「十分に速い」と「十分に賢い」を比較したい。
エージェントループには注意してください。高速な無料モデルは、低速なモデルよりも早くリクエストやトークンの制限に達することがあります。
4. Cloudflare Workers AI
Cloudflare Workers AI は、すでに Workers 上で構築している場合や、エッジに近い推論を望む場合に興味深い選択肢です。料金ドキュメントでは、Workers AI neurons の無料の日次割り当てと、その割り当てを超えた場合の Workers Paid での有料利用が説明されています。また、コーディングに近い Qwen や DeepSeek のオプションを含む LLM モデルも सूचीされています。
次の場合は Workers AI を使ってください:
- 製品がすでに Cloudflare 上で動作している。
- アプリのインフラに近いサーバーレスな AI 呼び出しを使いたい。
- コーディングエージェントのテストが、最上位のモデル品質よりも統合に関するものである。
「無料」という言葉があるからという理由だけで選ばないでください。日次リセット、モデルの利用可否、一部モデルに対する有料プラン要件、そしてエージェントが適切な API 形状を話せるかどうかを理解する必要があります。
5. Ollama または LM Studio 経由のローカル LLM API
ローカルモデルは、トークンごとのプロバイダー請求が発生しないという狭い意味では「無料」です。ただし運用面では無料ではありません。ローカルハードウェア、レイテンシ、メモリ、セットアップ時間、そして小型マシンではモデル品質が下がるというコストを支払います。
次の場合はローカル API を試す価値があります:
- コードをマシンの外に出せない。
- タスクが小さく反復的である。
- 最大の推論品質ではなく、エージェントの仕組みをテストしている。
- 遅いパフォーマンスや、ときどき弱い編集を受け入れられる。
強力な自律的な複数ファイル変更が必要な場合、ローカルモデルは通常、コーディングに最適な無料 LLM の答えにはなりません。プライバシー重視の基準とフォールバックとしては有用です。
判断マトリクス
無料 LLM のコーディング設定を日常業務に組み込む前に、このマトリクスを使ってください:
| 質問 | 確認すべきこと | 重要な理由 |
|---|---|---|
| エージェントはこのプロバイダー形式を受け入れますか? | Claude Code には対応する Anthropic 形式のゲートウェイ経路が必要で、Cline と Roo は OpenAI 互換プロバイダーを使用できます | モデルの品質を考慮する前に、プロトコルが違うと失敗します |
| モデルは tool calling をサポートしていますか? | 特に Roo Code では重要です | コーディングエージェントには、チャットテキストだけでなく、ファイルの読み書きやツールイベントが必要です |
| 開始前にクォータを確認できますか? | プロバイダーダッシュボード、キー確認エンドポイント、アカウント制限ページ、または使用ログ | 長いコーディング作業は、クォータが見えないと大きく失敗します |
429 のときはどうなりますか? | Retry ヘッダー、指数バックオフ、キューイング、フォールバック | 無料枠の制限は例外ではなく、通常のことです |
| 有料/ルーティングされた利用へスムーズに移行できますか? | 同じ base_url、同じモデル ID の規則、集中管理されたキー管理 | 最適なテスト環境が移行負債になってはいけません |
2行以上の回答が不明確なら、コーディングエージェント内で信頼する前に、無料 LLM API を手動で試してください。
Cline と Roo Code のための実践的なセットアップ手順
コーディングエージェント向けに無料 LLM API を評価するときは、次の安全な手順を使ってください:
- 小さなタスクを1つ選びます。README の更新、スタックトレースの説明、1ファイルのリファクタリングなどです。
- プロバイダーが文書化した base URL、API キー、モデル ID でエージェントを設定します。
- タスクを再現する最小のコンテキストから始めます。
- 複数ファイルの編集を依頼する前に、tool call が動作するか確認します。
- レート制限エラー、tool-call サポートの欠如、model-not-found エラーに注意します。
- 正確なプロバイダー、モデル、base URL、エラーメモを保存します。
- その後でのみ、より長いタスクを試します。
Cline では、これは主にプロバイダー設定の作業です。Roo Code では、tool calling を厳格な必須条件として扱ってください。Claude Code では、プロトコル互換性を厳格な必須条件として扱ってください。
無料テスト後に Flatkey が入る位置
無料 API は「このエージェントは動くか?」に答えるのに優れています。一方で、「このチームは毎日これを運用できるか?」に答えるのは苦手です。
Flatkey は後者の問いのために作られています。Flatkey の公開クイックスタートでは、API、SDK、CLI、コーディングエージェントのセットアップをまたいで1つのキーを使う方法と、次の OpenAI 互換ルーターを文書化しています:
https://router.flatkey.ai/v1また Usage Logs も文書化しており、チームはリクエスト後にモデル、トークン数、レイテンシ、コストを確認できます。製品概要では、公式モデルと従量課金ツールの間で1つのバランスを保ち、使用量が1つの台帳に記録される構成として Flatkey を位置づけています。
これは、無料の LLM コーディングテストが次の段階に成長したときに役立ちます:
- 異なるローカルエージェントを使う複数の開発者、
- 複数のモデルプロバイダー、
- 再試行とフォールバックのポリシー、
- 使用量の帰属、
- 支出制御、
- そしてプロバイダーキーが散在するのを避ける必要性。
移行の原則はシンプルです。学習中は無料モデルを直接試し、本格的なエージェント利用は、ローカル設定が管理不能になる前に、1つの可観測なゲートウェイの背後へ移してください。
設定の詳細は、Flatkey API クイックスタート: router.flatkey.ai 経由で最初の呼び出しを行う と マルチモデルのプロンプトテストのための1つの OpenAI 互換 base URL から始めてください。
よくある間違い
間違い1: すべての OpenAI 互換 API をエージェント互換だとみなすこと
OpenAI 互換のチャットは、コーディングエージェント互換と同じではありません。tool calling、streaming、model ID、max output の設定は異なる場合があります。
間違い2: 最も賢い無料モデルを選んでクォータを無視すること
リファクタリングの途中で失敗するなら、最高の無料 LLM モデルでもコーディングには役立ちません。エージェントループを始める前にレート制限を確認してください。
間違い3: Claude Code を Cline や Roo Code のように扱うこと
Claude Code は異なるゲートウェイモデルを持っています。Cline で動く一般的な無料の OpenAI 互換エンドポイントは、Claude Code でサポートされる経路ではない場合があります。
間違い4: 「無料」はしばしば「評価専用」を意味することを忘れること
プロバイダードキュメントでは、無料枠、プレビューモデル、本番モデルが区別されることがよくあります。タスクが重要なら、自動化する前にそれらの違いを読んでください。
FAQ
全体として、コーディングに最適な無料 LLM はどれですか?
多くの開発者が Cline や Roo Code を試す場合、OpenAI 互換エンドポイント経由の Gemini の無料枠が最良の出発点です。Claude Code では、一般的な無料の OpenAI 互換 API は適切なデフォルトではありません。Claude Code のゲートウェイ対応は Anthropic 互換の動作を中心にしているためです。
コーディングエージェントに最適な無料 LLM API は何ですか?
コーディングエージェントに最適な無料 LLM API は、エージェントのプロトコルに一致し、tool calling をサポートするものです。Gemini は OpenAI 互換のエージェントテスト向けの最有力なデフォルトです。OpenRouter は無料モデルの試用に便利で、Groq は速度テストに便利です。ローカルモデルはプライベートな実験に便利です。
実際には、コーディングに最適な無料 LLM はどれかという問いは、モデルのランキングごとではなく、常にエージェントごとに答えるべきです。
OpenRouter の無料モデルは Cline や Roo Code で使えますか?
はい。OpenAI 互換の base URL、キー、モデル ID を正しく設定し、選択したモデルがエージェントに必要な動作をサポートしている場合です。無料モデルのリクエスト上限があることを想定し、429 エラーを処理してください。
無料の OpenAI 互換モデルを Claude Code で使えますか?
一般的な差し替えとしては使えません。Claude Code のゲートウェイドキュメントは、サポートされる API 形式と Anthropic 互換のゲートウェイ動作に焦点を当てており、Anthropic は、いかなるゲートウェイを通じても Claude Code を Claude 以外のモデルへルーティングすることをサポートしていないと述べています。
ローカルLLMはコーディングエージェントに十分使えるのでしょうか?
小さな修正、説明、プライベートな実験には十分使えることがあります。一般的には、強力なローカルハードウェアと、エージェントのツールプロトコルをサポートするモデルがない限り、長い複数ファイルにまたがるエージェントタスクでは性能が劣ります。
最終的な推奨
本当に知りたいのがどの無料LLMがコーディングに最適かであれば、まずはエージェントから始めてください:
- Cline: まずはGeminiのOpenAI互換エンドポイントを試してください。
- Roo Code: まずはGeminiを試し、ただしネイティブのツール呼び出しをすぐに確認してください。
- Claude Code: 汎用の無料OpenAI APIを無理に使うのではなく、対応しているClaude互換の経路を使用してください。
- モデルの選定: OpenRouterの無料バリアントを使ってみてください。ただし、利用上限があることを想定してください。
- レイテンシの実験: Groqを試してください。
- プライベート/ローカルのテスト: OllamaまたはLM Studioを試してください。
無料LLMでのコーディングは、テスト用のハーネスとして使うのが最適です。ワークフローが日々の開発ループの一部になったら、可観測なルーティング、使用ログ、フォールバックポリシー、そして1つの管理されたキーの背後に移してください。



