OpenCode 推奨スペック｜公式のターミナル版前提に数値要件はなく、VRAMが要るのはローカルモデルをGPUで動かすとき

OpenCode に必要なスペックは構成で二分される

OpenCode は公式ドキュメントによればオープンソースのAIコーディングエージェントで、端末のインターフェース・デスクトップアプリ・IDE拡張として使える。必要なスペックの話は、そのエージェントがどのモデルをどこで動かすかで二つに割れる。APIキーを設定して外部のLLMプロバイダを使う構成では推論が手元の機械で走らず、ローカルモデルを挿した構成では推論が手元で走り、それをGPUに載せる場合に、モデルの重みとコンテキスト長ぶんのVRAMが必要になる。

この分岐を先に踏まないまま「OpenCode の推奨スペック」を一本の数字で語ろうとすると、噛み合わない話になる。公式は APIキーを設定することで任意のLLMプロバイダを使えると記載しており、さらにプロバイダ一覧のページでは AI SDK と Models.dev を通じて 75 以上のLLMプロバイダに対応するとしている。つまり手元の機械は、既定では「どのモデルを呼ぶか」を決める側であって、モデルを載せる側とは限らない。なお個々のプロバイダが実際にどう動くかは本記事で検証していない。

構成	この構成になるのはどんな場合か	推論が走る場所	スペックとして関わってくるもの
外部プロバイダを挿す	プロバイダの認証を設定してそのまま使い始めた場合	プロバイダ側	公式がターミナル利用の前提に挙げる端末エミュレータと、プロバイダの認証
ローカルモデルを挿す	設定の baseURL に手元の推論サーバを指定した場合(本記事の実測は Ollama)	手元のCPUとGPU(実際の分かれ方は ollama ps の PROCESSOR 列で確認する)	モデルの重みと、コンテキスト長が占めるKVキャッシュ

自分がどちらになるかは、OpenCode の設定で推論先に何を指定したかで決まる。公式が挙げるローカルの選択肢は Ollama だけではなく、LM Studio・llama.cpp・Atomic Chat のローカルエンドポイントも設定例として載っている。本記事が実測で扱うのはそのうち Ollama の構成だが、判定そのものは同じで、手元の推論サーバを指していなければ前者になる。その場合に手元で動くのはエディタとエージェントのプロセス、そして端末であって、モデルの重みは載らない。

以降は、公式が前提として何を挙げているかを確認したうえで、後者の構成でVRAMがどう動くかを実測値で追う。前者の構成で使う場合は「クラウドのプロバイダを挿す構成」の節までで判断が付き、そこから先の実測表は、手元のモデルを挿す構成を検討している場合に読む箇所になる。

公式が前提として挙げているもの

公式ドキュメントの導入ページが挙げているのは、ターミナルで OpenCode を使う場合の前提である。内容はモダンな端末エミュレータと、使いたいLLMプロバイダのAPIキーの二つで、CPU・RAM・GPU の数値要件はこの二つの中に含まれない。OpenCode 自体はターミナルのインターフェースのほかにデスクトップアプリとIDE拡張も提供されているので、この二つはターミナル版を動かすための前提として読む必要がある。ハードウェアの下限が数値で示されていない以上、「何GB以上のRAMが要る」「何世代以降のCPUが要る」といった数字を公式の要件として扱うことはできない。手元の環境が足りているかどうかは、公式の要件表からは決まらない。ローカルモデルを挿す構成なら後述の消費量から逆算できるが、クラウドのプロバイダを挿す構成については本記事に手元側の実測がなく、逆算する材料もない。

公式は、Windows では WSL の利用を推奨している。パフォーマンスと機能互換が理由で、例示されている端末エミュレータのうち Ghostty と Kitty は Linux/macOS のみである。ローカルモデルを挿す構成でこれに従う場合、WSL 側で OpenCode を動かして Ollama を Windows 側で動かすと、既定のNATモードでは後述の localhost 指定ではホストに届かない(Microsoft はホストIPの指定、または mirrored モードを案内している)。

認証の形もAPIキー一択ではない。公式のプロバイダ一覧ページは、OpenAI について ChatGPT Plus/Pro を選ぶとブラウザが開いて認証する経路を挙げている。GitHub Copilot はデバイスコードでの認証、DigitalOcean と Snowflake Cortex はブラウザで完結する OAuth である。APIキーが要るという前提は導入ページの記述としては原文どおりだが、外部プロバイダを使う全構成に当てはまる条件ではない。

インストール手段については、導入ページにインストールスクリプト・npm・Homebrew・Arch Linux のパッケージ・Chocolatey・Scoop などが挙げられている。npm を使う場合のパッケージ名は opencode-ai である。ここに並ぶ手段のどれが手元の環境で通るかは、本記事では検証していない。

配布元も判断材料になる。リポジトリは anomalyco/opencode で、ライセンスは MIT である(2026年8月31日 に GitHub API が返したリポジトリ情報)。MIT ライセンスであることは、社内やクライアント案件で使えるかを判断するときに最初に見る箇所になる。ライセンスの具体的な適用可否はライセンス本文にあたる必要があるが、少なくとも配布形態の確認はリポジトリで完結する。

クラウドのプロバイダを挿す構成

OpenCode は、APIキーを設定することで任意のLLMプロバイダを使える。公式のプロバイダ一覧ページでは、AI SDK と Models.dev を通じて 75 以上のLLMプロバイダに対応すると記載されている。どのプロバイダが自分の用途に合うか、料金や利用条件がどうかは各プロバイダ側の話であり、この記事はその可否を検証していない。

スペックの観点で重要なのは、この構成では生成そのものが手元の機械で走らないという一点である。モデルの重みはプロバイダ側の計算基盤に載っており、手元に載るのはエージェントのプロセスとエディタ、そして端末である。したがってVRAMの容量がボトルネックになる場面は、この構成では発生しない。この構成なら、AI推論のためにGPUを買い足す必要はない。

一方で、この構成で手元のRAMやCPUがどれだけ消費されるかについて、本記事は実測を持っていない。エージェントがファイルを走査したり差分を作ったりする処理は手元で動くため、消費がゼロになるわけではないが、その量を数値で示せる根拠がないため数字は出さない。手元側の条件を別のツールで見た記事としては、Cline 推奨スペック と Aider 推奨スペック がある。

ローカルモデルを挿すと何が変わるか

手元のモデルを使う場合、公式のプロバイダ一覧ページには前述の各ローカル実行系の設定例が載っている。以降は本記事が実測した Ollama に絞る。OpenAI互換のエンドポイントである http://localhost:11434/v1 を baseURL に指定して設定する形である。設定の書き方としてはクラウドのプロバイダと同じ経路に載るが、実際に推論を受け持つのは手元の Ollama になる。この時点で、スペックの話は前節までとまったく別の領域に移る。

ここで必要VRAMを動かす変数がコンテキスト長である。そして、いくつに置くかについて公式の記述が二つに割れている。OpenCode 側のプロバイダ一覧ページは、ツール呼び出しが動かない場合の対処として Ollama の num_ctx を上げることを挙げ、その出発点として 16k〜32k を示す。一方 Ollama 側の OpenCode 統合手順は、ローカルモデルについて 64k 以上のコンテキストを設定するよう求め、「OpenCode requires a context length of 64k or higher」と書いている(いずれも 2026年8月31日 に確認)。

前者は不調時のトラブルシューティングとして示された出発点で、後者は接続手順の要件として書かれている。同じ組み合わせについて一次情報が割れている以上、片方だけを引くと見積もりが変わる。本記事は 16k〜32k と 64k の両方でVRAMを見る。実務としては、Ollama 側の 64k を満たせる構成なら OpenCode 側の 16k〜32k は当然に満たすという包含関係で扱うのが安全になる。

ここでVRAM以前の制約が一つある。64k を満たすにはモデル自体がその長さを扱える必要がある。本記事で測った qwen3:14b は ollama.com のタグ一覧で 40K 表記で、実測でも 49,152 を指定したときに 40,960 へ丸められた。VRAM をいくら積んでも 64k には届かない。同じ一覧で qwen3.5:9b は 256K 表記である。

そのうえで num_ctx を上げると、モデルの重みとは別にKVキャッシュがVRAMを占める。ローカル構成で必要なVRAMは、重みだけでは決まらない。以降の節では、この二つがそれぞれどれだけ占めるかを実測値で分ける。

コンテキスト長がVRAMをどれだけ食うか

まず、モデルを固定してコンテキスト長だけを動かしたときの確保VRAMを見る。測定条件は次のとおり。

測定環境: RTX 5060 Ti 16GB 単体 / Ollama 0.30.7 / qwen3:14b / KVキャッシュ FP16 (指定なき場合) / 実効利用可能VRAM は公称16GBに対し約14.8GiB (OS・ドライバ控除後)

コンテキスト長	確保VRAM（KV=FP16）	GPU搭載	状態
4,096	8.98GiB	100%	全載せ
8,192	9.75GiB	100%	全載せ
16,384	10.87GiB	100%	全載せ
32,768	13.39GiB	100%	全載せ
40,960（モデル上限）	必要合計15.25GiB（GPU側13.71GiB）	89.9%	CPUへあふれ

この表の限定条件: 単一機・単一モデルでの測定。ここでの『確保VRAM』は Ollama が確保した量で、GPU全体の使用量ではない。他の生成処理を止めた状態で測っている。40,960 は qwen3:14b のモデル上限で、それ以上のコンテキストは測っていない。

OpenCode 側が出発点として挙げる下限、つまり 16,384 では 10.87GiB で全載せになっている。上限の 32,768 では 13.39GiB で、実効利用可能な 14.8GiB の大半を占める。さらに 40,960 まで伸ばすと必要合計が 15.25GiB になり、GPU搭載は 89.9% に落ちてCPUへあふれた。この 40,960 は qwen3:14b のモデル上限なので、このモデルは Ollama 側が求める 64k にVRAMを積んでも到達しない。ここで注意が要るのは、num_ctx が OpenCode 側の設定では変えられないことである。公式が示す Ollama の接続例は OpenAI互換エンドポイント経由で、Ollama の OpenAI互換APIはリクエストフィールドとして num_ctx を受け付けない。Ollama 公式は「The OpenAI API does not have a way of setting the context size for a model」と明記したうえで、PARAMETER num_ctx を書いた Modelfile から ollama create で別名モデルを作る方法を案内している。サーバ側で OLLAMA_CONTEXT_LENGTH を設定する方法と、Ollama アプリの設定にあるスライダーで変える方法も公式の手段として挙げられている。既定値は空きVRAMで変わり、24GB未満なら 4k、24〜48GB なら 32k、48GB以上なら 256k である。本記事の測定機は 16GB なので既定は 4,096 トークンで、公式に出てくる二つの値(16k〜32k と 64k)のどちらも下回る。設定の手間そのものは小さいが、VRAMの占有としては数GiB単位の移動になる。詳しい測定手順と全条件は ローカルLLMで長文を扱うとVRAMはどれだけ増えるか にまとめてある。

ただし、コンテキスト長を伸ばしたときの増え方はモデルによって大きく違う。同じ機で三つのモデルを比べたのが次の表である。

モデル	ctx 8K前後	ctx 32K	より長いctx
qwen3:14b（14B, dense）	9.75GiB（8K）	13.39GiB	40K=あふれ
gemma4:12b（12B）	7.51GiB（4K）	7.85GiB	ほぼ横ばい
qwen3.5:9b（9B）	5.48GiB（8K）	6.27GiB	64K=7.63GiB（全載せ）

この表の限定条件: モデルによってコンテキスト長ぶんの増え方が大きく違うことを示す比較。3モデルとも同じ機で測っているが、量子化・モデル上限は各モデル固有。

qwen3:14b は 8K から 32K へ動かすと 9.75GiB から 13.39GiB へ増える。対して gemma4:12b は 4K の 7.51GiB から 32K の 7.85GiB までほぼ横ばいで、qwen3.5:9b は 64K まで伸ばしても 7.63GiB で全載せに収まっている。パラメータ数が近くても、コンテキストを伸ばしたときの傾きは同じにならない。KVキャッシュ自体を量子化して確保量を戻した実測は、後述の「あふれたときに戻す手」に置く。

モデル別に16GBで収まる範囲

コンテキスト側の増え方が分かったので、重み側の実測と突き合わせる。次の表は重み側のスイートで、上のKVカーブとは測定条件が異なる。

測定環境: RTX 5060 Ti 16GB 単体 / Ollama 0.23.3 / 既定のコンテキスト長 / GPU全体のVRAM使用量 / 各モデルの既定量子化。重みのサイズは測定機の Ollama が保持しているモデル層の実バイト数で、括弧内はその digest の先頭12桁である。

モデル	種別	重みのサイズ（測定した現物）	VRAM使用量（5060 Ti・GPU全体）	生成速度
Qwen3-14B	dense（約14.8B）	8.64GiB（a8cc1361f314）	9.88GiB	42.7 tok/s
Phi-4	dense（14B）	8.43GiB（fd7b6731c33c）	10.20GiB	44.0 tok/s
Codestral 22B	dense（22B）	11.71GiB（22a849aafe3d）	13.70GiB	18.2 tok/s
Gemma 4 26B-A4B	MoE（26B・活性4B）	16.75GiB（7121486771cb）	14.48GiB	31.0 tok/s
Qwen3.5-35B-A3B	MoE（35B・活性3B）	22.23GiB（900dde62fb7e）	14.54GiB	15.4 tok/s

この表の限定条件: 重み側のスイートで、上のKVカーブとは別条件の測定(Ollama の版も違う)。速度は生成トークン毎秒。同一プロンプトでの比較ではない。重みのサイズだけは実測ではなく配布物の大きさ。

配布物は更新されるので、タグ名だけでは測ったものを指定できない。2026年8月31日 時点の ollama.com の表示と突き合わせると、Qwen3-14B(9.3GB)・Phi-4(9.1GB)・Codestral 22B(13GB)・Qwen3.5-35B-A3B(24GB)は上の表と同じ大きさだが、gemma4:26b だけは 19GB 表示に変わっている(同サイトの更新表示で数日前)。本記事が測ったのは digest 7121486771cb の 16.75GiB のほうで、いまタグ名で取得できるものとは別物である。現在の配布物のほうが大きいので、16GBに収まらないという以下の結論は変わらない。

そのうえで整理すると、14B のモデルは、既定設定でロードして測ったGPU全体の使用量が 9.88GiB(Qwen3-14B)・10.20GiB(Phi-4)だった。これは重みだけの値ではなく、Ollama 既定のコンテキスト長ぶんのKVキャッシュを含む。この測定に使った 5060 Ti 16GB では、この時点で余裕をもって収まっている。一方コンテキスト側を測ったのは qwen3:14b の1モデルで、32,768 では確保VRAMが 13.39GiB、実効利用可能な 14.8GiB のほとんどを使う。OpenCode 側が出発点として挙げる上限で運用するなら、このモデルは「載るが余白は薄い」。二つは測っている量が違うので、差を取ってKVの増加分として読むことはできない。同じ 14B でも Phi-4 のコンテキスト側は測っておらず、伸ばしたときの傾きはモデルごとに違うため、14B級全体の結論としては使えない。

測った2モデルのうち gemma4:12b はコンテキストを伸ばしたときの増分が小さかった。32K でも 7.85GiB にとどまる。qwen3.5:9b は 32K で 6.27GiB、64K でも 7.63GiB の全載せである。OpenCode 側が出発点として示す 16k〜32k という一点だけを見るなら、この2モデルは 5060 Ti 16GB で余裕がある側だった。Ollama 側が求める 64k まで上げた場合に実測で全載せを確認できたのは qwen3.5:9b のほうだけで、gemma4:12b について測ったのは 4K〜32K の範囲にとどまる(それより長いコンテキストは測っていない)。ただし同じパラメータ規模でも傾きはモデルのアーキテクチャで変わるため、他のモデルへ持ち込める値ではない。

Codestral 22B は測定した重みが 11.71GiB で、既定のコンテキスト長でのGPU使用量が 13.70GiB。重みは16GBの枠の内側にあるが、コンテキストをどこまで伸ばせるかは測っていないため、32,768 や 64k で運用できるかどうかはこの記事のデータでは判断できない。Gemma 4 26B-A4B と Qwen3.5-35B-A3B は重みだけで枠を超えており、この機ではコンテキスト長を決める前からCPUへのあふれが前提になる。VRAM 16GB という枠でモデルを選ぶ全体像は VRAM 16GBで動かすローカルLLM完全ガイド に整理してある。

あふれたときに戻す手

qwen3:14b を 32,768 で回すと余白が薄い、という前節の結果に対して、KVキャッシュの量子化だけを変えた実測がある。重みの量子化は変えていない。

測定環境: RTX 5060 Ti 16GB 単体 / Ollama 0.30.7 / qwen3:14b / KVキャッシュ FP16 (指定なき場合) / 実効利用可能VRAM は公称16GBに対し約14.8GiB (OS・ドライバ控除後)

コンテキスト長	KV=FP16	KV=q8_0	KV=q4_0
8,192	9.75GiB	9.16GiB	8.85GiB
16,384	10.87GiB	9.70GiB	9.07GiB
32,768	13.39GiB	11.08GiB	9.83GiB
40,960（モデル上限）	あふれ	11.78GiB（全載せ）	10.22GiB（全載せ）

この表の限定条件: KVキャッシュの量子化のみを変えた比較。重みの量子化は変えていない。出力品質への影響は測っていない。

OpenCode 側が挙げる上限の 32,768 では、FP16 の 13.39GiB が q8_0 で 11.08GiB、q4_0 で 9.83GiB になった。短いコンテキストでは差が小さく、8,192 では 9.75GiB に対して q8_0 が 9.16GiB、q4_0 が 8.85GiB にとどまる。KVキャッシュの量子化はコンテキストが長いほど戻る量が大きくなる操作で、短い設定で試しても差は見えにくい。

FP16 ではあふれた 40,960 も、q8_0 で 11.78GiB、q4_0 で 10.22GiB となり全載せに戻っている。ただしこの測定は確保量だけを見たもので、出力品質への影響は測っていない。量子化の粒度と確保量の関係は VRAM 16GBでローカルLLMのコンテキスト長はどこまで伸ばせるか で条件を変えて追っている。

なお、あふれへの対処としてはモデルを小さい階級に替える、量子化の粒度を落とす、GPUを増やすといった手も一般には存在するが、この記事の測定範囲はKVキャッシュの量子化までである。それ以外の手段が確保量をどれだけ戻すかは、ここのデータからは言えない。

この記事が測っていないこと

ここまでの数値がカバーしていない範囲を明示する。判断に使う前に、この範囲外に自分の用途が入っていないかを確認する箇所になる。

• OpenCode 本体が常駐するときのメモリ消費とCPU使用率。数値を持っていないため、この記事では扱っていない。
• エージェントがビルドやテストを実行するときのCPU・RAM。コーディングエージェントの実運用では無視できない負荷になり得るが、測っていない。
• クラウドのプロバイダを挿した構成での手元側の実測。この構成でRAMがどれだけ必要かは、この記事のデータでは答えられない。
• 他のGPU・他の実行エンジンでの挙動。掲載した数値はすべて RTX 5060 Ti 16GB 単体での測定であり(コンテキスト長のカーブは Ollama 0.30.7、重み側のスイートは 0.23.3)、他の環境の値として一般化しない。
• KVキャッシュを量子化したときの出力品質。確保VRAMの変化だけを測っており、生成結果の変化は測っていない。
• 個々のLLMプロバイダの動作と、各インストール手段の動作。公式の記載を確認しただけで、実行して検証していない。
• 重みだけで16GBを超えるモデルを、CPUへあふれさせたまま使ったときの実用性。生成速度は測っているが、コーディングエージェントの相手として成立するかは判断していない。

構成別の推奨スペック

ここまでの公式の記述と実測を、構成別に一枚へまとめる。数値を出せるのはローカル構成のVRAMだけで、CPUとRAMは公式に要件がなく本記事にも実測がないため、この表に入れていない。

構成	用意するもの	この記事で示せる根拠
外部プロバイダを挿す	モダンな端末エミュレータと、使うプロバイダの認証(APIキー、またはプロバイダによってはブラウザ認証)。AI用GPUは要らない	公式がターミナル利用の前提として挙げる2つ。CPU・RAM・GPU の数値要件は挙げられていない
ローカルモデルを挿す / Ollama 側が言う 64k 以上に合わせる	VRAM 16GB クラスのGPUと qwen3.5:9b	64K で確保 7.63GiB・GPU搭載100%(5060 Ti 16GB・Ollama 0.30.7)。測った3モデルで 64K を実測できたのはこれだけ
ローカルモデルを挿す / OpenCode 側の 32,768 で足りる場合	VRAM 16GB クラスのGPUと qwen3.5:9b・gemma4:12b・qwen3:14b のいずれか	32K の確保VRAM が 6.27GiB・7.85GiB・13.39GiB。qwen3:14b は実効 14.8GiB に対して余白が薄い
16GB のまま 26B・35B 級を載せる	この記事のデータでは成立しない	重みが 16.75GiB・22.23GiB で搭載VRAM(約15.9GiB)を超え、CPUへあふれた状態でしか動かない

この表の限定条件: 数値はすべて本文で出した実測の再掲で、条件は各節の測定環境に従う。VRAM の欄が「16GB クラス」なのは測った機がそれだからで、より小さいVRAMで足りるかは測っていない。CPU・RAM・ストレージ・電源はこの記事の測定範囲外。

まとめ

OpenCode のスペックを決めるとき、決める順序は次のようになる。最初に決めるのは構成であって、パーツではない。外部プロバイダを挿すのか、手元のモデルを挿すのかで、その後に見る指標が入れ替わる。

手元のモデルを挿す側を選んだ場合、次に決めるのは num_ctx をいくつで運用するかである。ここは一次情報が割れている箇所で、OpenCode 側はツール呼び出しが動かない場合の出発点として 16k〜32k を挙げ、Ollama 側の OpenCode 統合手順は 64k 以上を求めている。どちらに合わせるかで必要VRAMが変わるため、本記事は両方の値で見た。実際に必要な長さは扱うファイルの量でも変わる。

その値が決まってはじめて、載せられるモデルが決まる。5060 Ti 16GB・Ollama 0.30.7 という条件下では、qwen3:14b は 32,768 で余白が薄くなり、KVキャッシュの量子化が余白を作る手として残った。ただしこのモデルは上限が 40K なので、64k 側に合わせる場合はVRAMを積んでも選べない。64K まで伸ばして全載せを確認できたのは qwen3.5:9b で、gemma4:12b は 32K までの範囲で増分が小さかった。いずれも測ったモデルについての結果で、同じパラメータ帯の他モデルに置き換わる値ではない。必要VRAMが「重み+コンテキスト長ぶん」で決まるという順序自体はGPUが変わっても変わらないので、手元のVRAMから重みぶんを引いた残りがコンテキストに使える枠になる。数値はその環境で測り直す必要がある。

よくある質問

クラウドのプロバイダだけで使うなら、GPUは必要か

公式がターミナル利用の前提として挙げているのはモダンな端末エミュレータと使いたいLLMプロバイダのAPIキーで、GPUの数値要件は挙げられていない(プロバイダによってはAPIキーの代わりにブラウザ認証も選べる)。この構成では推論がプロバイダ側で走るため、手元のVRAMが上限になる場面は生じない。ただし手元のRAM・CPUの消費量については、この記事は実測を持っていないため数値では答えられない。

num_ctx は常に 32,768 にしておくのか

OpenCode 側が 16k〜32k を挙げているのは、ツール呼び出しが動かない場合に試す出発点としてである。全モデルで 32,768 が必須という記述ではない。ただし Ollama 側の OpenCode 統合手順は 64k 以上を求めており、一次情報は割れている。そのうえ 64k を選ぶにはモデル自体がその長さを扱える必要があり、qwen3:14b は上限が 40K なので選択肢に入らない。値を上げるとVRAMの確保量は確実に増える。qwen3:14b の実測では 16,384 の 10.87GiB に対し 32,768 で 13.39GiB だった(RTX 5060 Ti 16GB 単体・Ollama 0.30.7)。動作を確認しながら必要な側へ寄せる値であって、既定で最大にしておく値ではない。

VRAM 16GB のGPUで qwen3:14b を 32,768 で回せるか

KV=FP16 の実測では 13.39GiB で全載せになっており、実効利用可能な 14.8GiB の内側には収まっている。ただし余白は薄い。KVキャッシュを量子化すると q8_0 で 11.08GiB、q4_0 で 9.83GiB まで下がる。いずれも RTX 5060 Ti 16GB 単体・Ollama 0.30.7・qwen3:14b での値で、出力品質への影響は測っていない。

ライセンスと配布形態はどうなっているか

リポジトリは anomalyco/opencode で、ライセンスは MIT である(2026年8月31日 時点で取得したリポジトリ情報)。インストール手段としては、インストールスクリプト・npm・Homebrew・Arch Linux のパッケージ・Chocolatey・Scoop などが導入ページに挙げられている。各手段が手元の環境で通るかどうかは、この記事では検証していない。

参考資料

• OpenCode 公式ドキュメント
• OpenCode 公式ドキュメント: Providers
• OpenCode リポジトリ (anomalyco/opencode)
• Ollama 公式ドキュメント: OpenCode 連携
• Ollama 公式ドキュメント: Context length
• Ollama 公式ドキュメント: OpenAI compatibility
• Ollama 公式ドキュメント: FAQ