「這個月的 Copilot 費用怎麼突然變高了？」

如果你是正在管理開發團隊的技術主管，這句話很快就會出現在你的 Slack 或 LINE 群組裡。2026 年 6 月 1 日起，GitHub Copilot 將全面轉向用量計費模式——不再是你熟悉的「無限暢飲」，而是根據你實際上讓 Copilot 寫了多少程式碼來收費。

這不是一個微調，而是 Copilot 商業模式自推出以來最大的一次轉變。

為什麼 GitHub 要這麼做？

如果你從 Copilot 推出第一天就開始使用，你可能還記得最初的計費方式很簡單：每月固定費用，只要不超過每小時的請求次數限制，隨便你用。

問題在於，Copilot 已經不是一年前那個只會在編輯器裡幫你補完程式碼的小工具了。

GitHub 的官方說明點出了一個關鍵事實：Copilot 已經從編輯器內的小助手，長成了一個能自主運行多步驟編碼任務的 Agent 平台。一次快速聊天提問，和一次長達數小時的全自動編程 session，現在對 Copilot 來說成本是完全不同的，但用戶付的錢卻一樣。

用最白話的方式說：GitHub 一直在補貼重度用戶的運算成本。但隨著 Copilot Agent 模式的普及——讓 AI 自己讀取整個程式碼庫、執行多步驟操作、使用最新模型——背後的推論成本已經膨脹到不能再忽視的地步。

根據 GitHub 首席產品長 Mario Rodriguez 的說法，用量計費是「建立永續 Copilot 業務」的必要一步。

具體改了什麼？

從 2026 年 6 月 1 日開始，現行的「高級請求單位」（Premium Request Units, PRU）將被「GitHub AI Credits」取代。

新的計費核心邏輯是：你的 Copilot 使用量將根據 token 消耗來計算，包含輸入 token、輸出 token 和快取 token。每個模型都有自己的 API 費率，你用哪個模型就按哪個費率扣 credits。

不過好消息是，不是所有功能都要計費。程式碼補全（Code Completions）和 Next Edit Suggestions 仍然維持免費，包含在所有方案中，不消耗 AI Credits。

也就是說，Copilot 基本的程式碼補全功能不受影響。會被計費的主要是那些需要大量運算資源的功能——比如讓 Copilot 幫你分析整個專案、執行程式碼審查、或者用 Agent 模式運行長時間任務。

方案價格不變，但內涵不同了

這裡有一個關鍵點：各方案的月費沒有調漲。

每個方案每月會配發等值於月費的 AI Credits。也就是說，Pro 方案的用戶每月會拿到 $10 美元的 Credits，Pro+ 拿到 $39 美元。

如果你用量不大，月費足夠涵蓋你的使用——你每個月繳 $10，就有 $10 的 Credits 可以用。但如果你的用量超過這個額度，就需要額外購買 Credits。

這其實和雲端服務的計費邏輯很像：AWS、GCP 都是這樣。你付一個 base fee，包含了某個額度的用量，超過的部分另外計費。

對個人開發者的實際影響

對於一般個人開發者，日常的程式碼補全完全不受影響。你可能甚至不會感覺到變化——如果你主要是偶爾用 Copilot 問問題、補幾行程式碼，每月 $10 的 Credits 綽綽有餘。

但如果你是那種讓 Copilot Agent 執行長時間任務的開發者——比如讓它分析整個程式碼庫的設計模式、批次重構程式碼、或者執行自動化程式碼審查——你的使用成本可能會顯著上升。

GitHub 還取消了一個重要的現有功能：Fallback 體驗。目前，如果你用完了 PRU，Copilot 會自動降級到成本較低的模型，讓你可以繼續工作。新的模式不再提供這個降級機制——用完 Credits 後，你的使用將完全取決於管理員的預算控制和可用 Credits。

對企業和團隊的影響更大

企業客戶的變化可能更大。雖然每月每人 $19（Business）或 $39（Enterprise）的 seat 價格不變，但 Copilot Code Review 功能現在除了消耗 AI Credits，還會額外消耗 GitHub Actions 分鐘數。

GitHub 提供了三個月的過渡期：現有 Business 和 Enterprise 客戶在 6、7、8 月會自動獲得促銷額度——Business 用戶每月 $30 Credits（比正常多 $11），Enterprise 用戶每月 $70 Credits（比正常多 $31）。

另外一個值得注意的改進是：組織層級的 Credits 池化。以前每個用戶的未使用額度是相互隔離的，用不完就是浪費。新模式下，Credits 可以在整個組織內共享使用，這對大型團隊來說更能避免「這個人用不完，那個人不夠用」的資源浪費。

管理員還可以設定多層級的預算控制——從企業層級、成本中心到個別用戶——當 pooled credits 用完後，可以選擇是否允許繼續使用（按標準費率計費）或直接上限停止。

從開發團隊的角度看這件事

如果你在台灣的新創公司或中小企業擔任技術主管，這項變化可能讓你重新思考 Copilot 的導入策略。

過去幾年的經驗告訴我們，很多團隊習慣把 Copilot 當作「全體員工吃到飽」的福利來推廣。這在固定費率時代完全合理——每個人的費用都一樣，用多用少公司都付同一筆錢。

但用量計費改變了這個邏輯。重度使用者的成本會明顯高於輕度使用者。你可能會需要思考幾個問題：

如何預估 Copilot 的月度成本？ 過去很簡單：人數 × 月費。現在你需要先估算團隊的實際使用模式——每天有多少程式碼審查？有沒有人會讓 Copilot 長時間執行 Agent 任務？這些都會直接影響最終帳單。

要不要限制個人用量？ 新的預算控制功能可以幫助你設定上限，但這也意味著開發者可能因為用量超標而中斷工作流程。你需要找到一個平衡點。

程式碼審查成本翻倍？ 注意 Copilot Code Review 同時消耗 AI Credits 和 Actions 分鐘數——這個雙重計費可能會讓你的 CI/CD 成本意外增加。

台灣開發者可以做的具體準備

距離 6 月 1 日的正式轉換還有大約一個月，這段時間你可以做的準備：

第一步：追蹤你的實際用量。 GitHub 將在 5 月初推出預覽帳單體驗——登入 github.com 就能看到預估成本。如果你是管理員，現在就開始關注團隊的用量模式，找出哪些人、哪些功能消耗最多資源。

第二步：教育團隊成員。 很多開發者可能還不知道這個變化。確保團隊了解哪些功能會消耗 Credits（Agent 任務、程式碼審查、長時間對話），哪些不會（程式碼補全、基本補完）。這會幫助他們養成更有效率的 Copilot 使用習慣。

第三步：評估年度合約 vs 月度方案。 如果你目前是年度訂閱用戶，你的方案將維持以 PRU 為基礎的計費直到合約到期。但從 6 月 1 日起，年度方案也會有模型倍率調整——雖然方案價格不變，但同一個模型消耗的 Credits 倍率可能會因年度方案而有不同。你可以選擇在到期前轉換為月度方案，GitHub 會提供按比例計算的 Credits 退還。

深入一點： 年度方案的使用者在轉換時要注意一個細節——模型倍率。目前 GitHub 公布了不同模型的倍率表，一些較昂貴的模型（如 GPT-4 系列或 Claude 系列）消耗 Credits 的速度會比基本模型快。如果你習慣使用高階模型進行複雜任務，同樣的 Credits 會用得更快。這是很多人在第一時間容易忽略的成本陷阱。

第四步：設定預算警報。 利用新的管理員控制功能，為團隊設定分層預算。不需要讓每個人都有無限預算——根據角色和需求合理配置，避免月底收到意外的帳單。

第五步：開始實驗 Agent 模式的新工作流程。 用量計費雖然聽起來像是成本增加，但它也意味著你不再需要擔心「我每個月只能用這麼多次高級請求」。想跑大型重構任務？想做深度的程式碼分析？只要願意付費，你就能得到對應的運算資源。從這個角度來看，這其實釋放了 Copilot 的全部潛力。

費用模式背後的真實成本

讓我們算一筆簡單的帳。假設你是一個小型團隊的技術負責人，團隊有 10 個人使用 Copilot Business 方案：

如果團隊每天平均進行 5 次 Copilot Agent 任務，每次消耗約 $0.50 的 Credits（假設使用中等模型，任務時間約 5 分鐘），一天就是 $2.5，一個月（22 個工作日）約 $55。再加上程式碼審查消耗的 Actions 分鐘數，每個月大約 $30-50。

也就是說，對於一個正常使用的中型團隊，日常運作仍然落在方案額度內。但如果團隊開始大量使用 Agent 模式——比如讓 Copilot 每天分析多個倉庫的架構設計、批次執行重構腳本——成本就會快速爬升。

這不是要嚇唬任何人，只是想做一個誠實的估算。因為用量計費最大的挑戰不是費用本身，而是不可預測性。過去你很清楚每個月要付多少，現在你需要更了解團隊的實際使用模式。

社群怎麼看？

這項公告在 HackerNews 上引起了熱烈討論，獲得了超過 500 票和近 400 則留言。社群的反應大致可以分為幾種：

一種聲音認為這是合理的商業決定。畢竟大型 AI 模型的運算成本是真實存在的，GitHub 需要找到可持續的商業模式。從這個角度來看，用量計費比暗中調漲月費更透明。

另一種聲音則擔心這會扼殺創新。特別是在開源社群和個人開發者群體中，有些人認為用量計費會讓開發者「不敢放手用 Copilot」——每次打字前都要想一下「這個會不會消耗 Credits」。

還有一群人的觀點更務實：他們指出程式碼補全仍然是免費的，日常使用的成本不會明顯增加。真正被影響的是那些把 Copilot 當作「AI 同事」來用的重度使用者——而這些人的生產力提升也確實對得起額外的費用。

這不僅是計費變革

如果你仔細看 GitHub 的官方公告，你會發現這不只是一次計費方式的調整。它反映了 AI 開發工具更深層的趨勢。

Copilot 正在從「一個在編輯器裡補完程式碼的輔助工具」轉變為「一個能獨立完成複雜開發任務的 AI 工程師」。這個轉變不是突然發生的——過去一年，我們已經看到 Copilot 陸續加入 Agents、程式碼審查、專案分析等功能。但用量計費的引入，正式宣告了這個轉型已經進入成熟階段。

想像一下，五年前你很難想像一個 AI 工具能讀懂整個程式碼庫、自己寫測試、自己審查 PR。而現在 GitHub 需要用量計費來管理這一切——因為運算成本已經大到不能忽視。

這也意味著，如果你還只把 Copilot 當成「更聰明的自動補完」來用，你可能錯過了它真正的潛力。用量計費或許會促使更多開發者去認真探索 Copilot Agent 的能力——畢竟既然都要付錢了，不如讓它做點真正有價值的事。

觀察家的話

老實說，用量計費對大多數開發者來說不會是壞消息。如果你的工作流程沒有劇烈變化，你的 Copilot 帳單不會變高。程式碼補完全部免費，日常聊天提問消耗的 Credits 也不多。

真正的變化發生在邊緣——那些讓 Copilot 跑大型任務的人、那些深度整合 Agent 模式的團隊、那些把自動化程式碼審查當作日常的企業。他們會看到成本上升，但同時也會獲得過去無法想像的生產力。

這讓人不免想到多年前雲端服務的轉型過程——從固定費率的虛擬主機到按用量計費的雲端運算。最初大家都覺得「變貴了」，但最終每個人都發現，按用量計費其實釋放了更多可能性。你可以只用一點點，也可以臨時需要大量資源——按需付費，不用被固定方案綁住。

回到台灣開發者的處境。我們的團隊規模通常不比美國的大型企業，預算也相對有限。用量計費對我們來說，既是挑戰也是機會——挑戰在於需要更精細的成本控管，機會在於不再被固定方案限制。你可以讓團隊中的核心開發者使用更進階的模型，同時讓偶爾使用的成員維持基本方案，而不是所有人都捆綁在同一個吃到飽方案裡。

GitHub 在這個時間點的轉換，其實也反映了一個更深層的現實：AI 開發工具已經從「有趣的新玩具」變成了「不可或缺的基礎設施」。而基礎設施，就是需要可持續的商業模式。

GitHub 選擇在 6 月 1 日這個時間點轉換，剛好給了開發者一個月的緩衝期。趁這段時間登入 GitHub、打開 Billing Overview、看看你的 Copilot 到底在用多少資源——你很可能會發現，你以為的「偶爾用一下」實際上的使用量比你想像的多很多。

這不是壞事。知道自己在用什麼，才有辦法用得更有意識。