【2026 實查】Make 免費版每月 1,000 credits 到底夠用嗎？照官方計費規則算一次，加一個聚合器省掉 73% 用量

Make（前身 Integromat）的免費層看起來很大方：每月 1,000 credits。但很多人第一次做完流程，跑不到一週就發現額度見底、場景直接停擺。

問題不在你用得多，而在你以為的「跑一次」，在 Make 的計費規則裡不是一次。

以下全部照 Make 官方說明中心（help.make.com）的定義來拆，兩篇核心文件〈Operations〉與〈Credits〉的官方標示更新日期都是 2026-09-10，是目前最新的版本（查核日 2026-09-10）。

一、先記住這條換算：一次模組執行＝1 credit

官方對 operation 的定義只有一句話：operation 就是「一次模組執行」，用來處理資料或檢查有沒有新資料。

而 credit 是收費單位，官方寫得很清楚：

• 非 AI 的應用：1 operation ＝ 1 credit。
• 第三方 AI 應用（官方點名 OpenAI、Anthropic Claude、Gemini）：1 operation 也是 1 credit，但如果那個模組是走「自動連線的 AI 供應商」，credit 還會另外含 token 用量。

官方也解釋了為什麼要分成兩個詞：credits 是拿來看你花了多少錢，operations 是拿來看你在平台上做了什麼。

所以「一個場景跑一次要花多少」這個問題，答案不是「1」，而是這一輪裡所有模組總共被執行了幾次。

二、觸發器只算 1，不管它抓回幾筆

這是唯一對你有利的例外，也是最多人搞反的一條：

觸發器模組（trigger）只執行一次去檢查或取得資料，不管它回傳幾個 bundle。

官方舉的例子：Google Sheets 的「watch new rows」去檢查試算表有沒有新列，＝1 operation（每次檢查算一次），就算這次抓回 10 列也一樣。

換句話說：你的 credit 不是被「抓資料」吃掉的，是被「抓回來之後每一筆各做一次」吃掉的。

三、bundle 的乘數效應：一次執行變成 31 credits

Make 把資料的單位叫 bundle（一封信、一個聯絡人、一個檔案就是一個 bundle）。關鍵規則是：

模組會把每個 bundle 分開處理，也就是每個 bundle 各觸發一次模組執行。

官方直接給了一個算式範例。一個場景：監看 Google 表單新回應 → 幫每則回應建一份文件 → 下載 → 寄給填答者。這一輪觸發器回傳了 10 筆新回應：

官方原文的結論是：早期模組的 bundle 數量，會對後面所有模組的 operation 數產生乘數效應。

把這個數字放回免費層：1,000 credits ÷ 31 ≈ 32 次。也就是這種「一則回應做三件事」的流程，一個月只跑得起 32 輪。

四、官方自己示範的省法：加一個聚合器，11 降到 3

同一份官方文件裡，Make 自己示範了怎麼改。原本的場景是：Google Sheets 監看新聯絡人（1 operation，回傳 10 個 bundle）→ Gmail 對每位新聯絡人各寄一封信給業務主管（10 operations），合計 11 operations。

官方的優化做法：加一個文字聚合器（text aggregator），把 10 位新聯絡人合併成一封信的內文，改成只寄一封。 結果官方明寫：

這個調整把這一輪的總 operations 從 11 降到 3。

省掉 73%。而且信箱也乾淨了——收 1 封彙整信，本來就比收 10 封通知合理。

這條是本文最值得直接照做的一條：只要你的流程裡有「對每一筆各做一次」的動作，先問自己「這些能不能合併成一次」。彙整通知、批次寫入、合併成一個檔案，都是同一個思路。

五、免費層的排程間隔，要跟 1,000 credits 一起算

站上工具檔的查核紀錄（2026-08-28 直讀官方定價頁）記載，免費層的限制是：每月 1,000 credits、最多 2 個啟用中的場景、排程最短間隔 15 分鐘、單次執行上限 5 分鐘、檔案上限 5 MB。

把「觸發器每檢查一次算 1 operation」這條官方規則套上去推算：15 分鐘一次＝一天 96 次檢查，一個月約 2,880 次——光是空轉檢查就超過免費層 1,000 credits 的兩倍以上，後面模組還沒開始跑。（此為依官方 operation 定義推算的數字，非官方公布數據。）

所以免費層的正確用法是：

1. 把排程拉長。不是每個流程都需要 15 分鐘一次；每小時、每天一次的流程，credit 消耗差好幾倍。
2. 能用 webhook 就別用輪詢。有事情發生才被叫醒，比每 15 分鐘去問一次省。
3. 兩個啟用中的場景是硬限制。免費層只能同時開 2 個，做實驗記得把用不到的關掉。

⚠️ 待查核：本站工具檔早期紀錄寫「含 filter、router 都計費」，但 2026-09-10 這次直讀官方〈Operations〉與〈Filtering〉兩份文件，官方把 operation 定義為「模組執行」，而 filter 是加在兩個模組之間連線上的條件，官方文件並未把它列為會產生 operation 的項目。兩邊說法不一致，在拿到官方明確說明前，本文不對 filter 是否計費下結論。

六、真正的吃 credit 大戶：AI 模組

如果你打算在免費層跑 AI 流程，這段一定要看。官方把 credit 消耗分成兩種：

• 固定用量（fixed）：預設 1 operation ＝ 1 credit，不管資料多大。官方舉例：Google Drive 上傳檔案，不論檔案大小都是 1 credit。但有例外——官方明寫某些 Make AI Content Extractor 的模組因為處理複雜度較高，一次會吃超過 1 credit（官方示意圖裡出現 2 credits 與 10 credits 的模組），這類模組在介面上會有專屬標籤。
• 動態用量（dynamic）：依實際消耗計算，最常見的變因是 token。官方也列出其他變因：檔案大小、頁數、處理時間。

更關鍵的是連線方式決定計費方式，而這裡藏著一道方案門檻：

看懂了嗎：「自備金鑰只吃 operation」這個最省 credit 的玩法，官方明講是付費方案才有。 免費層要用 AI，只能走 Make 自家供應商，credit 直接跟著 token 走。

官方公布的換算率（節錄，官方註明會隨新模型調整）：

差距非常大：同樣的字數，用 Sonnet 5 燒掉的 credit 大約是 GPT-5 nano 的 60 倍。 官方另外提醒英文約「4 個字元＝1 token、100 tokens ≈ 一個段落」。

免費層的實務建議：AI 步驟先用小模型跑通流程，確定邏輯對了再考慮換大模型；別在免費層直接拿最大模型做長文處理。

七、額度用完之後，免費層沒有補血選項

官方的〈Extra credits〉寫得很直白，重點三條：

1. 加購額度只有付費方案能買。 免費層用完就是等下個月重置（站上查核紀錄：credits 每月重置、未用完不累積）。
2. 加購要加價 25%。 官方算例：US$9 的方案含 10,000 credits，1 credit 成本是 US$0.0009；加購 1,000 credits 要 US$1.125、10,000 credits 要 US$11.25。
3. 加購額度會過期。 月繳方案：加購的額度到當期帳單週期結束就失效（官方例子：帳期 1 號到 31 號，20 號買的額度 31 號到期）。年繳方案的加購額度也是隨每月重置一起消失。

官方自己的建議也很誠實：如果你經常超用，換到更適合的方案比一直加購划算，因為高階方案的單位 credit 成本更低。

八、免費層省 credit 檢查清單

1. 先算一輪要幾 credits：觸發器 1 ＋（每個後續模組 × bundle 數）。
2. 凡是「每筆各做一次」的動作，先想能不能合併——官方示範的聚合器一招就省 73%。
3. 排程間隔拉長，或改用 webhook；免費層 15 分鐘一次的輪詢，光空轉就撐不完一個月。
4. AI 步驟先跑小模型；免費層沒有「自備金鑰只算 operation」這個選項。
5. 注意有專屬標籤的高耗模組（一次吃 2 或 10 credits 的那種）。
6. 用完不能加購，所以月中就要盯用量，別等停擺才發現。

資料來源

• Make 官方說明中心〈Operations〉：https://help.make.com/operations（官方標示更新日 2026-09-10）
• Make 官方說明中心〈Credits〉：https://help.make.com/credits（官方標示更新日 2026-09-10）
• Make 官方說明中心〈Extra credits〉：https://help.make.com/extra-credits
• Make 官方說明中心〈Filtering〉：https://help.make.com/filtering
• 免費層額度與限制數字來自本站工具檔查核紀錄（2026-08-28 直讀 make.com 官方定價頁）；2026-09-10 本次複驗時 make.com/en/pricing 回應 403 擋爬，無法一手複驗，故牌價與免費層數字標示為沿用前次一手查核。

同類流程工具的免費額度比較，可看〈n8n 社群版與雲端試用怎麼選〉。Make 的方案與免費額度現況見 Make 工具檔案，另可對照 n8n 工具檔案。