Twinny 與 Continue：有哪些變化，以及現在該用哪個

Twinny 與 Continue 已不再爭奪同一項工作：Continue 是仍能執行的已完成軟體，而 Twinny 是仍在持續發布的範圍較窄工具。 continue.dev 自己的頁面標題寫著「Continue（已由 Cursor 收購）」，其 README 稱該儲存庫已不再積極維護且為唯讀；另一方面，Twinny 在同一天 2026-09-18 推出了 4.1.1、4.1.2 和 4.1.3 版本。但 Twinny 刻意不提供代理程式模式和 MCP 工具，因此它只能取代 Continue 部分功能，而不是全部功能。

先釐清一點，因為這個名稱對應到多個對象。兩家互不相關的公司都以 Twinny 的名稱營運：西班牙的企業自動化平台 twinny.es，以及韓國的機器人公司 twinny.ai；在 2026 年 9 月 19 日檢查時，兩者都仍在線上。兩者的價格或融資資訊都不屬於本頁內容。這裡介紹的產品是位於 twinny.dev 的 VS Code 擴充功能，以 rjmacarthy.twinny 的識別碼發布，來自 twinnydotdev/twinny 儲存庫，文件位於 twinny-docs。

Continue 實際發生了什麼事

簡短來說，產品結束了，但程式碼沒有。Continue 的 README 明確指出：該儲存庫「已不再積極維護，且對所有使用者皆為唯讀」。首頁的 meta description 只有一句話——Continue 已由 Cursor 收購。不過，唯讀不代表已封存，而這正是多數文章弄錯的區別。

所有列均於 2026 年 9 月 19 日檢查。在規劃任何事項之前，其中兩點值得特別強調。第一，README 表示最終的 2.0.0 涵蓋 VS Code 擴充功能、CLI 和 JetBrains 外掛程式，但已發布的成品中有兩項與其不一致：CLI 從未超過 1.5.47，JetBrains 外掛程式從未超過 1.0.67。本指南報告這項差異，而不解釋其原因，因為沒有任何一手來源說明。第二，文件網站比 hub 存活更久是一個現成陷阱：docs.continue.dev 仍教導使用 uses: <owner>/<slug> 語法，從已無法解析的主機拉取模型或規則。現在唯一保證能解析的形式，是完全本機的 config.yaml，並明確列出 provider、apiBase 和 apiKey 項目。

誰應該選哪一個

如果您在 Continue 中實際使用的是自動完成、關於程式碼的聊天、行內編輯、檢閱和提交訊息，而且希望使用仍有人維護的程式碼庫，請選擇 Twinny。其 儲存庫採用 MIT 授權，未封存；截至 2026 年 9 月 19 日，最近的提交是 4.1.1 至 4.1.3 版本升級，日期皆為 2026-09-18。如果您在自己的硬體上執行模型，尤其應選擇它：Twinny 的整體設計核心是本機伺服器，而其填空式自動完成功能與 1.5B 至 7B 的基礎模型搭配良好。

如果您依賴 Twinny 沒有的功能，請選擇 Continue，或者說繼續使用它。代理程式模式和 MCP 工具伺服器是最明顯的案例——Continue 的 MCP 文件表示，MCP「只能在代理程式模式中使用」，因此兩者必須一起成敗。CLI 和 JetBrains 外掛程式是另一個案例：Twinny 要求 Visual Studio Code 1.93 或更新版本，或 VSCodium 等相容組建，並且不提供命令列用戶端，也沒有 JetBrains 版本。凍結的 Continue 安裝仍可運作；只是不會再改進。

執行模型才是真正的分界線，而且這不是一次發布就能彌補的功能差距。Twinny 的 FAQ對「twinny 會自行執行代理程式來編輯我的檔案嗎？」的回答是：「不會。每項變更都是您要求的，而且在保留之前您都能看見：您接受的建議、您接受的差異、您確認的命令。這是刻意的設計。」如果您使用 Continue 是為了交付多步驟任務並檢閱結果，Twinny 會是您第一天就能感受到的降級。如果您在聊天和編輯模式中使用 Continue，且覺得代理程式模式令人不安，Twinny 就是相同的工作流程，只是移除了您不想要的部分。

遷移成本很低，但不是零。 Continue 將每個模型放在一個含有角色清單的 YAML 檔案中；Twinny 完全沒有設定檔，而是在側邊欄中一次建立一個工作，因此 Continue 中承載三個角色的單一項目，會變成最多三個 Twinny 供應商。Twinny 沒有任何功能會讀取 Continue 設定。請預留約一小時進行重寫，另加重建工作區索引的時間——不同嵌入模型產生的向量無法混用，因此變更嵌入模型就代表需要重新建立索引。

在成本方面，兩個用戶端都免費，而且都不是帳單來源。 Continue 完全沒有價格：continue.dev 不再提供定價頁面，而其 FAQ 對軟體唯一提到的是，Apache-2.0 原始碼和文件仍保留在 GitHub 上。Twinny 的擴充功能採 MIT 授權且免費，但其團隊閘道才是出現金額的地方，而這兩部分很容易混淆。

功能與授權並列比較

資料於 2026 年 9 月 19 日取自兩個 Marketplace 列表、儲存庫及各專案的文件。安裝數每天都會變動，反映的是歷史，而非目前使用情況——Continue 作為受維護產品，三年來累積了其數字。另請注意，Twinny 的 Marketplace 簡介（「適用於 vscode 的本機託管 AI 程式碼完成外掛程式」）和 GitHub 說明都比 twinny.dev 上的定位更舊；目前 twinny.dev 以團隊閘道為主要訴求。描述 Twinny 點對點「Symmetry」網路的舊文章所指的是已移除的功能；其 FAQ 表示 Symmetry 已移除並由 Devices 取代，而 Devices 只會連結您自己的機器。

各自的費用

Twinny 的方案價格於 2026 年 9 月 19 日取自其 授權與席位頁面；Continue 的定位則取自 continue.dev 本身。兩點需要如實說明。席位是有效的存取金鑰，而不是人員；撤銷金鑰會立即釋放席位。此外，這些是公布的價格，不是本指南實際結帳驗證的價格——網站將 rjmacarthy.xyz 列為授權發行者，但未調查其背後的賣方實體。Twinny 自己的首頁比較也引用託管助理每個席位「通常為 $19–39」的數字；那是其行銷說法，不是本頁驗證過的數字。

任一用戶端可透過 OpenAI 相容閘道存取的功能

這是兩個工具停止互換的地方，而且任何功能表都無法呈現這一點。兩者都將工作拆分成不同任務，但只有部分任務能與聊天完成閘道通訊。

聊天在紙面上可行。 Twinny 的 供應商總覽指出，聊天 API 路徑是基礎路徑，而 Twinny 會附加 /chat/completions，因此對 api.kunavo.com使用 /v1的 API 路徑，與 Kunavo 自己的路徑一致。問題在於要選哪個預設設定：Twinny 的 託管 API 頁面表示，使用託管 API 的聊天「會透過供應商的 SDK 傳送至其固定端點，因此主機名稱、連接埠和路徑欄位會被隱藏」。OpenAI 和 Anthropic 預設設定仍會要求金鑰——它們會將金鑰傳送給該供應商，而不是您選擇的地址，這就是為什麼閘道金鑰不應填入其中。使用本機伺服器預設設定時，地址欄位會保持可見；而通用的「OpenAI-compatible server」預設設定，正是用於 Twinny 沒有提供專用預設設定的伺服器。將 https://api.kunavo.com/v1 貼入 Hostname，表單會自動為您拆分為通訊協定、主機、連接埠和路徑；金鑰則會以 Authorization: Bearer 標頭傳送。

自動完成無法適用，原因有兩個且彼此獨立。 Twinny 的 通用預設設定會透過 /v1/completions 型路徑驅動完成，而 Kunavo 沒有此類路徑——其 API 沒有舊版文字完成端點，只有 /v1/chat/completions 和其他聊天型介面。另一方面，Twinny 的 支援模型頁面明確表示，只有以填空式 Token 訓練的模型，才能在游標前後內容之間完成文字；指令模型「往往會閒聊或解釋，而不是完成內容」。Kunavo 的目錄是指令模型和聊天模型；其中沒有任何填空式基礎模型。任一項阻礙單獨存在就足以得出結論。Continue 自己的 自動完成指南也得出相同方向，只是未使用 Twinny 的術語：針對該角色，它建議使用 Codestral 和 Qwen2.5-Coder 1.5B 與 7B，並警告思考型模型不適合此用途。請使用小型本機模型提供自動完成——這本來就是兩個專案共同建議的設定。

Kunavo 完全不提供嵌入功能。目錄中沒有任何模型具備嵌入端點，因此 /v1/embeddings 會解析到模型並拒絕請求。請將 Twinny 的嵌入供應商，或 Continue 的 embed 角色，指向本機伺服器或外部嵌入供應商。Twinny 的文件建議使用 nomic-embed-text。

name: My Config
version: 0.0.1
schema: v1
models:
  - name: Claude Sonnet 4.6
    provider: openai          # the protocol, not the vendor
    model: claude-sonnet-4-6
    apiBase: https://api.kunavo.com/v1
    apiKey: <your Kunavo key>
    roles: [chat, edit, apply, summarize]
    capabilities: [tool_use]  # only if agent mode stays unavailable

這個區塊有兩點需要注意。provider: openai指的是線路通訊協定，而不是供應商，因此適用於任何實作 /v1/chat/completions 的端點。而 capabilities 列是其中不明顯的部分：Continue 的 能力文件表示，它會根據供應商和模型名稱偵測 tool_use，而且「您無法覆寫自動偵測——只能新增能力」。如果閘道提供的 ID 不在 Continue 的表格中，Continue 就不會取得 tool_use；能力頁面列出的結果正是代理程式模式不可用。新增該列會將其啟用，而沒有任何設定會再將其停用。另請注意，Kunavo 自己的 Continue 設定頁面還提供了第二個項目，在 autocomplete 角色中使用聊天模型。該設定沒有任何公開紀錄顯示經過執行階段測試，而 Continue 自己的自動完成指南為該角色指定的是程式碼完成模型，而非聊天模型——請以本節所述的謹慎態度看待它，不要將其視為已驗證的配方。

聊天型工作的 Token 估算範例

由於自動完成無法連線至閘道，任一用戶端對 Kunavo 產生的 Token 費用僅來自聊天流量：聊天回答、行內編輯、程式碼檢閱和提交訊息。這使得計算量小於以完成為主的助理，在選擇模型前先看看規模是有價值的。假設一個工作日有 12 次聊天或編輯回合，每次平均包含 18,000 個未快取輸入 Token 和 1,200 個輸出 Token——總計 216,000 個輸入 Token 和 14,400 個輸出 Token。這些假設僅供說明；在制定預算前請替換為您自己的數值。費率是即時的 Kunavo 目錄每百萬 Token 價格。

這些是說明性 Token 計算，不是實際測量的任務成本，也不是帳單上限。列出的最低費率與完成任務的最低成本是不同的說法：需要第二次嘗試才能完成檢閱的模型，成本可能高於一次就完成的較昂貴模型。Kunavo 的目錄金額是計費下限，而不是上限——上游回報費用時，帳單金額是目錄成本與上游成本乘以適用加成兩者中的較高者。快取費用以及您在本機執行的任何內容不包含在此範例中。最低加值金額為預付額度 $10，這是資金最低額度，而不是任務費用或訂閱費；請參閱 計費詳細資訊。

設定方式

Kunavo 發布了 Continue 的設定指南，但沒有發布 Twinny 的；而已發布的設定參考並不等於相容性測試——兩個用戶端都尚未針對此端點進行執行期測試。嘗試其中一個時，請保留一條可正常運作的路徑，先執行一項有明確範圍的單一任務，再讀取帳戶為該任務記錄的費用。使用 Continue 時，請從 Continue 整合指南 開始，並搭配閱讀上述注意事項。使用 Twinny 時，請採用此處說明的通用 OpenAI 相容提供者，以及 Twinny 自有的 Test provider 按鈕；該按鈕會針對該提供者的工作傳送一個小型請求，並顯示成功結果，或顯示伺服器錯誤及其呼叫的 URL——這是辨別路徑錯誤與金鑰錯誤最快的方法。準備好為金鑰儲值時，請建立 Kunavo 帳戶。

想進一步比較其他選項？OpenAI 相容 API 說明該通訊協定能傳遞及不能傳遞哪些內容；如果 Continue 的代理模式是你無法捨棄的部分，Cline 與 Claude Code 則會比較兩個代理。

常見問題

於 2026 年 9 月 19 日直接擷取並檢查：兩個 GitHub 儲存庫 API 與提交清單、兩個 VS Code Marketplace 頁面、@continuedev/cli 與 twinny-server 的 npm 項目、JetBrains 外掛頁面、continue.dev 及其 README、hub.continue.dev 的 DNS 查詢、docs.continue.dev 的 OpenAI 提供者、功能與 MCP 頁面，以及 Twinny 的介紹、提供者、託管 API、支援模型、授權與 FAQ 頁面。未檢查：任一用戶端向 Kunavo 發出的執行期請求，以及 Twinny 的結帳流程。Kunavo 的權杖費率來自即時目錄；本文每個美元範例都只是說明性的權杖算術。