Dify 和 n8n 並不算真正的競爭對手——它們提供的是不同的產品。Dify 是用來建構 LLM 應用程式本身的平台：聊天應用程式、代理或由 RAG 支援的助理。n8n 是通用工作流程自動化平台，模型呼叫只是其中一個節點，與數百個連接器、排程和 webhook 並列。 如果交付成果是 AI 產品，請從 Dify 開始；如果交付成果是偶爾向模型提問的業務流程，請從 n8n 開始。反過來搜尋——n8n 與 Dify——答案也一樣，因為選擇取決於你要建構什麼。
真正容易讓人混淆的部分是費用。Dify 按AI 回應計費，n8n 按工作流程執行計費，而模型供應商按token計費。這三種單位無法彼此換算，因此這一對工具的大多數並列價格表在第一列之前就已經具有誤導性。
先說兩個版本事實，因為網路上許多關於這一對工具的索引內容已經過時。n8n 目前位於2.x系列：最新版本是n8n@2.39.9，發布於 2026 年 9 月 21 日。Dify根本沒有 2.x 發布系列——目前主要系列是 1.x，最新版本為 1.17.1，發布於 2026 年 9 月 10 日。兩個儲存庫都仍在維護且未封存（Dify 和 n8n 最新版本頁面，於 2026 年 9 月 21 日重新確認；n8n 發布頻繁，因此預期修補版本號可能又已變動）。
誰應該選哪一個
| 您的情況 | 選擇 | 原因 |
|---|---|---|
| 你要交付的產品是聊天應用程式、代理或由 RAG 支援的助理 | Dify | 提示詞工作台、知識庫和已發布的應用程式就是產品，而不是由節點組合而成的某個東西 |
| AI 步驟位於較長的流程中——CRM、電子郵件、試算表、webhook、排程 | n8n | 模型節點與連接器位於同一個畫布上，因此模型並非核心 |
| 非管理員可以建構應用程式，但不得接觸供應商金鑰 | Dify | 只有工作區擁有者和管理員可以管理供應商，而新增的任何金鑰都會在整個工作區中生效，並計費至新增者自己的供應商帳戶 |
| 你需要獨立環境和 git 版本控制 | n8n，自 Business 層級起 | 「不同環境」和「使用 Git 進行版本控制」首次出現在 n8n 定價頁面的 Business 方案專屬功能清單中；Starter 和 Pro 沒有列出這些功能 |
| 你想自行執行，不使用供應商帳戶 | 兩者皆可，但請先閱讀授權條款 | Dify Community 是修改版 Apache 2.0，含有禁止多租戶的條款；n8n Community 屬於 fair-code，僅限內部商業用途或非商業用途 |
| 你已經付費使用其中一個，並想整合到另一個 | 兩者都不行，至少無法低成本完成 | 兩個專案都沒有記載可匯入對方格式的匯入工具，因此應預留重新建構而非轉移的成本，並根據適配度做選擇 |
表格背後有兩個結構性差異，值得直接說明。權限：Dify 的供應商設定是僅限管理員、且涵蓋整個工作區的操作——其文件明確表示，只有擁有者和管理員可以管理供應商，而且你新增的金鑰「會計費至你在該供應商的帳戶」；這可能正是你想要的治理方式，也可能正是你不想要的瓶頸。n8n 則以專案為中心組織共享，而其定價頁面依層級計量專案數：Starter 一個共享專案、Pro 三個、Business 六個、Enterprise 不限。執行模型：無論其中發生多少次模型呼叫，n8n 執行一次就是一次工作流程執行；Dify 則每次模型呼叫計費一次，因此相同邏輯在兩種計量方式下會產生截然不同的結果。
已發布的方案與價格
Dify Cloud 按工作區計價。以下年度價格字串就是定價頁面實際呈現的內容；該頁面也提供「按年計費，節省 17%」的切換開關。
| Dify 方案 | 價格 | 訊息額度 | 成員／應用程式 | 知識庫 |
|---|---|---|---|---|
| 沙箱 | 免費 | 200（一次性，不是每月） | 1 位成員、5 個應用程式 | 50 份文件、50MB、30 天日誌 |
| Professional | 每個工作區每月 $59，或每個工作區每年 $590 | 每月 5,000 | 3 位成員、50 個應用程式 | 500 份文件、5GB、無限日誌 |
| Team | 每個工作區每月 $159，或每個工作區每年 $1,590 | 每月 10,000 | 50 位成員、200 個應用程式 | 1,000 份文件、20GB、無限日誌 |
| 社群版（自行託管） | 免費 | 無——你支付自己的模型費用 | 單一工作區 | 你自己的基礎架構 |
| Enterprise | 自訂，聯絡銷售團隊 | 未公開 | 未公開 | 未公開 |
於 2026 年 9 月 19 日讀取自 dify.ai/pricing 和 dify.ai/pricing/dify-cloud。比較表也顯示 Sandbox 有「5,000 API Rate Limit/month」，而付費層級沒有這項限制。Dify Premium（AWS Marketplace 機器映像）是獨立 SKU；此處未列出價格，因為本次查核期間未能在 Dify 官方第一方頁面上確認其數字。
n8n Cloud 按方案計價，配額計算的是執行次數，而不是模型呼叫。貨幣注意事項：n8n.io/pricing 在 2026 年 9 月 19 日這次查核中以歐元呈現，未確認其他地區的買家是否會看到其他貨幣——請在結帳時確認。
| n8n 方案 | 價格，按年計費 | 每月執行次數 | 並行數 | AI（Gateway）額度 |
|---|---|---|---|---|
| 入門版 | €20／月 | 2,500 | 5 | 每月 2,300 次 |
| Pro | €50／月 | 10,000 | 20 | 每月最多 13,700 次 |
| Business | €667／月 | 40,000 | 方案卡片未說明 | 方案卡片未說明 |
| Enterprise | 自訂，聯絡銷售團隊 | 自訂 | 200+ | 方案卡片未說明 |
| 社群版（自行託管） | 免費 | 不以配額形式販售——上述執行額度附加於 Cloud 方案 | 你自己的硬體 | 自行託管時無法使用 Gateway 額度 |
所有列出的付費層級中，使用者和工作流程皆不限量；Business 以上則提供自行託管選項。免費試用宣傳為 Pro 等級功能，包含 1,000 次執行和 5 次並行執行。
有三種不同的項目都稱為額度
這是聚合頁面略過的部分，而且它決定你的預算。
| 單位 | 一個單位代表什麼 | 它忽略什麼 |
|---|---|---|
| Dify 訊息額度／AI 額度 | 「單次模型呼叫（一次輸入和一次輸出），無論使用多少 token，都計為一次回應」 | 完全忽略 token 數量——200 token 的回覆和 200,000 token 的回覆都算一次回應，不過較大的模型會消耗更多額度 |
| n8n 執行 | 「完整工作流程的一次執行。工作流程中有多少步驟，或其處理多少資料，都不重要」 | 節點數量、資料量，以及執行中發生多少次模型呼叫 |
| 供應商 token | 輸入和輸出 token，按每百萬 token 計價 | 什麼都不忽略——這是實際追蹤模型完成多少工作的計量方式 |
Dify 對同一個單位使用兩種名稱：定價頁面稱為「訊息額度」，而目前的文件稱為「AI 額度」。Dify 自身的文件將每個模型每次回應所需的額度數量交由定價頁面說明，而該逐模型表格無法逐字擷取到本頁，因此此處不列印逐模型額度數字。
n8n 的配額比表面看起來更寬鬆，對你有利。其執行文件指出，「只有正式環境執行會計入此配額」，並排除編輯器中的手動執行、由Execute Sub-workflow呼叫的子工作流程執行（只計算父工作流程）、錯誤工作流程執行、沒有回傳資料的輪詢，以及格式錯誤或遭拒的 webhook 請求。文件也從另一面提醒：Schedule Trigger 每次觸發都會計算一次執行，不論結果如何；Webhook Trigger 則會為每個啟動它的入站請求計算一次，包括空白主體。
誠實的比較不能迴避另一件事：n8n 現在本身也販售模型存取權。Gateway 額度「自 n8n 2.36.0 起提供」，僅限 n8n Cloud Starter 和 Pro，「n8n Cloud Enterprise 或自行託管的 n8n 無法使用」，按「服務定價頁面列出的費率，以每次請求計費」，而加購額度「會在購買後 12 個月到期」。這與閘道所做的工作相同，只是整合在產品內販售。文件指向 n8n Cloud 應用程式內的服務定價頁面，但該頁面在 2026 年 9 月 21 日以未登入方式擷取時沒有提供可讀取的費率表，因此此處不公布每美元可兌換的額度數字，也不與其進行成本比較。可確認的是適用範圍：Gateway 額度不適用於自行託管或 Cloud Enterprise；同一份文件也指出，目錄以外的服務「仍可按照 n8n 的一般方式運作：使用自己的 API 金鑰建立憑證」。Dify 的等效功能較弱，而且它自己也如此說明——金鑰與 AI 額度「可以共存」，由 Usage Priority 開關決定優先扣用哪一項。
將任一者指向你自己的模型端點
兩者都接受第三方 OpenAI 相容端點，也都接受 Anthropic 相容端點；在這兩種情況下，界線都不是「能不能設定 base URL」——該欄位存在於各專案原始碼所提供的憑證和外掛結構描述中，而且兩者的定價頁面都沒有顯示方案限制。真正的界線在於端點預期回應的協定，以及哪些能力旗標一開始處於關閉狀態。
| 問題 | n8n | Dify |
|---|---|---|
| 端點放在哪裡 | Credentials → OpenAI，一個預設為 https://api.openai.com/v1 的 Base URL 欄位；或 Credentials → Anthropic，預設為來源 https://api.anthropic.com，不含 /v1 | 安裝官方 OpenAI-API-compatible 外掛，接著選擇 Model Provider → Add Model，並填寫必填的 API Base URL 欄位 |
| 模型探索 | 下拉選單會呼叫 GET {base}/models；當 base URL 不是 api.openai.com 時，僅限聊天的 id 篩選器會被移除，因此該端點的 /models 回傳什麼，就會提供什麼，無論是聊天模型與否 | 沒有。該外掛只有 customizable-model，因此每個模型都必須手動輸入，每列一個 |
| 通訊協定 | OpenAI Chat Model 節點上的 Use Responses API 開關——請參閱下方尚未解決的預設值 | 一個 api_type 開關，default: chat_completions，替代選項為 responses |
| 工具呼叫 | 透過 AI Agent 節點搭配聊天模型使用 | 預設關閉。function_calling_type 預設為 no_call，因此能在聊天中運作的 gateway，在 Agent 節點中會靜默失敗，直到你設定它為止 |
| 無法重新指向其他位置的端點 | OpenRouter 憑證將其 URL 固定為 type: 'hidden' | 每個自訂模型都綁定自己的金鑰：刪除唯一的金鑰就會刪除模型 |
| BYOK 本身的方案限制 | 未找到——Base URL 欄位是在 n8n 原始碼的憑證結構描述中宣告，且定價頁面沒有列出其方案層級條件 | 未找到新增供應商的限制；在多個金鑰之間分散請求的 Load Balancing，在 Cloud 文件中標示為 Professional 和 Team 功能 |
原始碼檔案，於 2026 年 9 月 19 日擷取：OpenAiApi.credentials.ts、AnthropicApi.credentials.ts、OpenRouterApi.credentials.ts 和 Dify 的 openai_api_compatible.yaml。值得注意的是：n8n 的官方 OpenAI 憑證頁面仍只記載 API 金鑰和組織 ID，從未提及 Base URL 欄位；而新增該欄位的社群提取請求（n8n-docs#5146）已在未合併的情況下關閉。這條路徑最重要的欄位沒有文件說明，因此改為引用原始碼檔案。
一個確實尚未解決的預設值
n8n 的兩個官方來源對新加入的 OpenAI Chat Model 節點會呼叫哪個端點一事說法不一致。master 上的節點原始碼宣告了responsesApiEnabled，並設定default: true；這出現在節點版本 1.3 及以上，而 1.3 是該節點版本清單中的最新項目——這看起來表示 Responses API 已開啟。節點文件則表示相反：「否則，OpenAI Chat Model 節點預設會使用 Chat Completions API。」兩者都在 2026 年 9 月 19 日擷取，而且不可能同時適用於今天新增的節點。本頁不判定哪個正確。請開啟節點查看開關，並知道該設定決定請求會打到/responses還是/chat/completions——對只提供其中一個端點的服務而言，這決定了能否運作，或每次呼叫都收到 404。Kunavo 同時實作兩條路徑，因此這裡任一位置都可運作，但請確認設定，不要自行假設。
自訂端點在 n8n 中無法跨越的兩道界線。內建的 Responses 工具——Web Search、File Search 和 Code Interpreter——是由 OpenAI 託管的功能，文件還補充說，它們「只有在 OpenAI Chat Model 節點與 AI Agent 節點搭配使用時才受支援」。此外，在節點層級設定的 base URL（而非在憑證上設定）會在使用前根據憑證的網域限制進行檢查——節點原始碼會對它呼叫assertOpenAiCredentialAllowsUrl，當 URL 位於那些網域之外時就會擲出錯誤。
在 Dify 方面，預設值就是關鍵。除了function_calling_type: no_call之外，手動新增的模型會以structured_output_support: not_supported和vision_support: no_support作為初始值，而且每一項都是由你設定、以符合端點實際行為的手動開關。stream_include_usage 預設啟用是有原因的：如果端點未在最後一個串流區塊中回傳使用量，Dify 就會改用本機估算，而該估算只計算第一則提示訊息，會低估多訊息提示。相同檔案也為 gateway 提供明確的替代方案——可以省略頂層user欄位，因為「某些 OpenAI 相容 gateway 會拒絕它」；另有token_param_name開關，以及嚴格與擴充相容性模式——這是很好的證據，顯示 gateway 路徑是持續維護的使用案例，而不是權宜之計。
對於 Anthropic 風格的存取，Dify 的官方 Anthropic 外掛屬於predefined-model和customizable-model，並提供選用的anthropic_api_url欄位，因此你可以將其內建的 Claude 清單指向其他端點。如果要這樣做，請注意 id：Dify 的內建資料夾將claude-opus-5、claude-sonnet-5、claude-opus-4-8、claude-opus-4-7、claude-opus-4-6和claude-sonnet-4-6等無日期 id，與claude-sonnet-4-5-20250929等有日期的 id 混在一起。第一組中的無日期項目是 Kunavo 目錄 slug；有日期的形式不是，而且 Dify 資料夾中的每個 id 都不一定對應到目前上架中的項目。使用你的金鑰呼叫GET /v1/models，並從回傳結果中選取——該清單已經排除任何未提供服務的項目。Kunavo 的 base URL 完全遵循兩種慣例：OpenAI 風格欄位使用https://api.kunavo.com/v1，Anthropic 風格欄位使用不含路徑的來源https://api.kunavo.com（請參閱base URL 文件，了解為何在此處新增/v1會產生 404）。
n8n 的 Anthropic 憑證有一項特有細節，這是閱讀兩個專案的程式碼所得，而非測試結果：該憑證使用x-api-key進行驗證，並使用GET {base}/v1/models進行測試；Kunavo 的/v1/models和/v1/messages一樣，會在該標頭中接收金鑰，因此憑證測試和模型下拉選單應該都能正常回應。下拉選單會以每個模型的display_name標示，並在缺少該欄位時退回使用 id；Kunavo 的清單沒有display_name，因此會顯示 id——而且會顯示目錄中的每個模型，不僅是 Messages 端點提供的claude-模型，因此請從前者選取。以上內容都未在本頁進行執行時測試。純 OpenAI 相容路徑才是快速入門文件所記載的路徑。
Dify 中閘道金鑰無法涵蓋的範圍
Dify 的工作區有五個預設模型欄位——其模型供應商文件列出了這些欄位——而它們正是檢驗任何模型供應商實際涵蓋範圍的依據。Kunavo 金鑰會填入其中一個欄位；其餘四個欄位不會解析到 Kunavo 執行的任何服務。
| Dify 預設欄位 | 它的作用 | Kunavo 目前提供 |
|---|---|---|
| 系統推理模型 | 一般 LLM 任務的預設模型 | 已涵蓋——聊天目錄就是用於此用途 |
| 嵌入模型 | 建立索引並擷取知識庫內容 | 未提供服務。目錄中沒有嵌入模型，因此此步驟會在本機執行，或連線至外部供應商 |
| 重排序模型 | 依相關性重新排列擷取結果 | 未提供服務。Dify 的重排序類型會向 {base}/rerank 發送請求，而 Kunavo 沒有此路由 |
| 語音轉文字模型 | 將音訊轉換為文字 | 未提供服務。目錄中未列出語音轉文字模型 |
| 文字轉語音模型 | 將文字轉換為音訊 | 未提供服務。目前目錄中未啟用文字轉語音模型，因此此欄位也會指向其他位置 |
在規劃遷移前，請先正視這一點：Dify 知識庫或 RAG 管線仍需要從其他來源取得嵌入模型，通常也需要重排序模型。閘道金鑰涵蓋的是推理欄位，而不是整個工作區。RAG 實作指南說明了這種拆分通常如何配置。
一份實際的成本估算
這是說明性的權杖算術，不是實測任務成本，也不是帳單上限。假設有一個每月在正式環境中執行2,000 次的分類工作流程，而且每次執行會進行兩次模型呼叫——一次用於分類，一次用於起草——每次分別傳送4,000 個輸入權杖並回傳400 個輸出權杖。這總計為 4,000 次模型呼叫、1,600 萬個輸入權杖和 160 萬個輸出權杖。費率採用每百萬權杖的即時Kunavo 目錄價格。
| 模型 | 每 1M 的輸入／輸出 | 本月預估權杖成本 |
|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $16.80 |
| GPT-5.6 Terra | $0.70 / $4.20 | $17.92 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $50.40 |
| Claude Opus 5 | $3.50 / $17.50 | $84.00 |
現在將平台的計量方式放在旁邊比較。同一工作量在 n8n 上是2,000 次正式環境執行——低於 Starter 的 2,500 次——因為兩次模型呼叫都包含在一次執行中。在 Dify 上則是4,000 次 AI 回應，因為 Dify 會計算每次模型呼叫，因此會立即超過 Sandbox 的 200 次一次性額度，並落在 Professional 的每月 5,000 點額度內。僅模型選擇就會讓相同 4,000 次呼叫的權杖成本從 $16.80 變為 $84.00，這通常比方案層級更具影響力。列出的最低費率與完成工作的最低成本仍是兩個不同問題：需要重試的較便宜模型，成本可能高於不需要重試的較昂貴模型。
Kunavo 的目錄金額是計費下限，而非上限：當上游回報其費用時，帳單金額取目錄成本與上游成本乘以適用加成兩者之較高者。快取費用與外部工具不包含在此範例中。最低加值金額為預付額度中的 $10——這是資金最低門檻，不是任務費用或訂閱費。請參閱計費詳細資訊，以及AI 成本最佳化，了解如何衡量自己的工作量，而不是相信這類估算。
同時執行兩者，以及改變選擇的成本
對「Dify 還是 n8n」最常見的實際答案是兩者並用，但分屬不同層級：Dify 建立並託管 AI 應用程式，n8n 觸發它，並將結果串接至業務的其他部分。兩項產品都沒有禁止這種用法，而且能讓每個工具負責其設計用途。代價是兩套計量方式與兩組憑證，因此在將其視為低成本選項前，請先檢查兩者。
它不是遷移路徑。兩個專案都沒有說明可匯入對方格式的工具，因此請預期重新建立邏輯，而不是搬移邏輯。這也是應依適配性而非價格做選擇的最有力理由：方案帳單下個月可以改變，重建卻無法恢復。如果你選擇的是模型路由而非平台，OpenAI 相容 API 指南說明了這兩項工具所期待的端點，而LLM 閘道指南說明了閘道能購買及不能購買的內容。
兩個用戶端都尚未針對 Kunavo 進行執行時測試。以上內容全部取自目前的原始碼與目前的官方文件，而 Kunavo 沒有為任一工具發布設定指南——設定方式就是標準的 OpenAI 相容設定。嘗試時請保留一條可運作的路由，先執行一項受限任務，再讀取帳戶實際記錄的費用。準備為金鑰儲值時，請建立 Kunavo 帳戶；或瀏覽整合索引，查看已有文件化設定方式的用戶端。
常見問題
Dify 比 n8n 好嗎？
一般而言，不能說哪個比較好，因為兩者提供的是不同的產品。Dify 是 LLM 應用程式平台：其儲存庫將自身描述為一個可在同一個協作工作區中，搭配模型與工具支援來建構代理工作流程和 RAG 管線的地方，而交付成果是 AI 應用程式。n8n 是通用工作流程自動化平台，模型呼叫只是其中一種節點，與連接器、webhook、排程和資料庫並列，而交付成果是一個流程。當 AI 產品本身就是重點時，選擇 Dify；當 AI 步驟位於較長的業務流程中時，選擇 n8n。反過來問 n8n 與 Dify，答案也一樣——選擇取決於你要交付什麼，而不是哪個工具比較強。
Dify 和 n8n 可以搭配使用嗎？
可以，而且這是常見的配置，不是權宜之計。Dify 文件說明，你發布的每個應用程式都同時會成為可由自有後端搭配 API 金鑰呼叫的 REST API；n8n 則提供 HTTP Request 節點。因此，Dify 應用程式可以作為 n8n 工作流程中的推理步驟，而 n8n 負責觸發程序、連接器和重試。如果這樣做，請將兩種計量都納入預算：Dify 會為其應用程式進行的每次模型呼叫計算一次 AI 回應，而 n8n 會為呼叫該應用程式的整個工作流程執行計算一次正式環境執行。兩個專案都沒有記載可匯入對方格式的匯入工具，因此 Dify 應用程式和 n8n 工作流程會維持為兩個成品，而不是在工具之間遷移成一個成品。
Dify 和 n8n 哪個比較便宜？
不能只從方案價格回答這個問題，因為兩種方案計量的是不同項目，而且都沒有計量通常成本最高的那個項目。Dify Cloud 按工作區計價並計算訊息額度，其中一次 AI 回應就是一次模型呼叫，不論使用多少 token。n8n Cloud 按方案計價並計算正式環境執行，其中一次執行就是一次完整的工作流程執行，不論其中包含多少步驟或模型呼叫。模型 token 的費用是兩者之外的第三筆帳單，除非你一直使用方案所含的額度。自行託管任一者都會移除訂閱費，留下基礎架構費與模型費用，但仍受各專案授權條款限制。
Dify 或 n8n 哪個更適合 RAG？
依設計而言是 Dify。它將知識庫作為一級物件提供，並依方案設定文件與儲存空間限制；其工作區也為嵌入和重排序配置專用的預設模型欄位，與推理模型並列。n8n 可以利用向量儲存和嵌入節點建構檢索管線，但需要由你組合並維護。無論選哪一個，都要注意模型端的影響：檢索需要嵌入模型，通常也需要重排序模型，而 Kunavo 目前兩者皆不提供，因此無論選擇哪個平台，Dify 或 n8n RAG 堆疊的這部分都要在本機執行或使用外部供應商。
我可以在 Dify 和 n8n 中使用自己的 API 金鑰嗎？
兩者都提供這個欄位，而且兩者的定價頁面都沒有顯示該功能受方案限制。在 n8n 中，OpenAI 憑證有可編輯的 Base URL，預設為 https://api.openai.com/v1；Anthropic 憑證也有一個欄位，預設為來源 https://api.anthropic.com，不含 /v1；OpenRouter 憑證則將 URL 固定為隱藏欄位，無法重新指向其他位置。在 Dify 中，你可以安裝官方 OpenAI-API-compatible 外掛並手動新增各個模型，或將官方 Anthropic 外掛指向自訂 API URL。Dify 也允許金鑰與自身的 AI 額度共存，由供應商卡片上的 Usage Priority 開關決定優先扣用哪一項。
Dify 是開放原始碼嗎？n8n 是開放原始碼嗎？
兩個答案都需要加上限定條件，而且 GitHub 的儲存庫 API 對兩者的授權條款都回報 NOASSERTION。引用 github.com/langgenius/dify 和 github.com/n8n-io/n8n 中的兩個 LICENSE 檔案：Dify 使用修改版 Apache License 2.0：允許商業用途，但若要從原始碼營運多租戶環境，需要取得書面授權，其中一個租戶代表一個工作區；此外，不得移除或修改前端中的標誌和著作權資訊。n8n 屬於 fair-code，並非 OSI 意義上的開放原始碼：Sustainable Use License v1.0 僅允許將其用於或修改為自己的內部商業用途，或非商業用途與個人用途；檔名含有 .ee. 或目錄名稱含有 .ee 的檔案需要付費的 n8n Enterprise License，而 master 以外的分支則明確未獲授權。
截至 2026 年 9 月 19 日檢查並於 9 月 21 日重新檢查：透過 GitHub API 查閱兩個 GitHub 儲存庫及其最新版本；兩個授權檔案；dify.ai/pricing、dify.ai/pricing/dify-cloud 與 n8n.io/pricing；Dify 模型供應商文件；n8n 執行、Gateway credits 與 OpenAI Chat Model 文件；以及 n8n 的 OpenAI 與 Anthropic 憑證、其 OpenAI Chat Model 節點，和 Dify 的 OpenAI 相容與 Anthropic 外掛 manifest 原始碼。兩項產品都未安裝，也未指向 Kunavo，因此本文沒有任何測試結果。Kunavo 權杖費率來自即時目錄，所有美元數字都是說明性算術。