OpenCode 接本地模型：不付訂閱費寫程式，實際能用嗎

雲端 AI 寫程式的訂閱費，一個月 20 到 200 美金。如果你已經有一台跑得動模型的機器，把 agent 指向本地推論，這筆錢就歸零。

我花了一個週末把 OpenCode 接到 Ollama，結論先講：

設定很簡單（20 分鐘），但「能用」和「好用」是兩件事。 本地模型能處理小任務，遇到需要多步工具呼叫的 agentic 工作就會明顯掉漆。

這篇是完整設定，加上我認為值得知道的限制。

---

一、為什麼選 OpenCode

	OpenCode	Claude Code / Codex
授權	開源	閉源
供應商	任意（雲端或本地）	綁定自家模型
費用	只有模型成本（本地＝0）	訂閱制
資料	可完全不出機器	送到雲端

如果你在意「程式碼不要離開內網」，或只是不想再付一份訂閱，OpenCode 是目前最直接的選擇。

---

二、前置條件（先確認這個，不然後面白做）

OpenCode 要求模型 context 至少 64k。

這是最多人卡住的地方。Ollama 預設的 context 常常是 4k 或 8k，模型拉下來能跑，但 OpenCode 一接上去就出錯或行為怪異。

# 確認 Ollama 版本
ollama --version

# 全域提高 context（重啟 Ollama 生效）
export OLLAMA_CONTEXT_LENGTH=65536

要永久生效，寫進 systemd：

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=65536"

sudo systemctl restart ollama

硬體門檻：64k context 很吃記憶體。一個 30B 的模型用 q4 量化，加上 64k KV cache，大約需要 24–32GB 記憶體或 VRAM。如果你只有 16GB，實際可用的模型會小到不太好用。

---

三、安裝與設定

1. 安裝 OpenCode

curl -fsSL https://opencode.ai/install | bash
# 或
npm install -g opencode-ai

2. 拉模型

# 程式碼專用的模型，先挑一個能塞進你記憶體的
ollama pull qwen3-coder:30b

3. 設定 provider

全域設定檔在 ~/.config/opencode/opencode.json；專案層級可以在 repo 根目錄放 opencode.json 覆蓋。

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": {
        "baseURL": "http://127.0.0.1:11434/v1"
      },
      "models": {
        "qwen3-coder:30b": {
          "name": "Qwen3 Coder 30B (local)"
        }
      }
    }
  }
}

三個細節：

• baseURL 要用 /v1 結尾（Ollama 提供 OpenAI 相容端點）
• models 的 key 必須完全等於 ollama list 顯示的名稱，包含 tag
• 如果 Ollama 在另一台機器，改成那台的 IP，並確認 11434 沒有對外開放

4. 驗證

opencode
# 在 TUI 裡輸入 /models，應該看到 Ollama (local) 與你的模型

---

四、實測：什麼任務能跑，什麼會炸

可以（表現接近可用）

• 單檔重構：把一個 200 行的函式拆開、改命名、補型別
• 寫測試：給定明確輸入輸出，生 unit test
• 解釋程式碼：讀一個檔案回答「這段在做什麼」
• 小範圍修 bug：錯誤訊息明確、範圍限縮在一個檔案內

明顯不行

• 跨檔案重構：需要先讀 10 個檔案再決定怎麼改 → 本地模型容易「忘記」前面讀過什麼
• 多步工具呼叫：agent 需要連續 5 次以上 read → edit → test 迴圈時，成功率掉很快
• 不明確的需求：需要反問、需要自己找線索的任務，小模型會直接開始亂改
• 大型 repo：context 塞不下，它會只看到一部分，然後自信地改錯地方

為什麼會這樣

agentic coding 的瓶頸不是「寫得出來」，是 tool calling 的穩定性。每多一次工具呼叫，就多一次格式錯誤、參數錯、或忘記目標的機會。雲端前沿模型在這種連續決策上領先很多，這也是它們貴的原因。

換句話說：本地模型省的是錢，付的是你的時間。

---

五、我的實際配置建議

混合策略（我認為最合理）

規劃 / 大重構  → 雲端前沿模型（值得花錢）
小修小補 / 樣板 → 本地模型（免費）
敏感程式碼     → 本地模型（不出機器）

OpenCode 可以同時設多個 provider，用 /models 切換。你不需要「全部在地端」或「全部在雲端」，混著用才是現實解法。

如果真的想全本地

• 優先加大記憶體／VRAM，而不是換更大的模型（context 不足比模型小更致命）
• 選 tool calling 有特別訓練 的模型，不是選參數最多的
• 把任務切小：一次只要求改一個檔案
• 保留 git，讓它可以亂改，你隨時 git checkout

---

六、常見錯誤

症狀	原因	解法
模型有回應但行為怪	context 不足 64k	設 OLLAMA_CONTEXT_LENGTH
/models 看不到模型	name 與 ollama list 不一致	逐字對，含 tag
速度快但一直改錯檔案	模型太小、tool calling 不穩	換模型或縮小任務範圍
第一次回應正常，後面全亂	context 爆掉	降 context 用量：少讀檔、切任務
接不上	baseURL 少了 /v1	補上

---

七、結論

值不值得做，取決於你的目的：

• 想省訂閱費 → 值得，但要有心理準備它只處理得了 50% 的任務
• 想資料不外流 → 值得，這是唯一可行的路線
• 想完全取代雲端 agent → 目前不行，差距在 tool calling 而不是「會不會寫程式」

我現在的用法是：本地模型跑日常小改，雲端模型處理需要想清楚的重構。兩邊都開著，切換成本只有一個 /models。

延伸閱讀：如果你還沒決定要不要自架這些工具，先看買 3C 前先問的 12 個問題——同樣的判斷邏輯適用於軟體服務。