Cursor 的疊代次數上限不是預算上限：一堂價值 90 美元的慘痛教訓

開發者分享血淚教訓：指出 Cursor 迭代次數上限（iteration cap）與費用預算上限（budget cap）的本質差異，血淋淋的踩坑經驗對控制 API 成本有極大幫助。

• 作者在使用 Cursor 進行自動化開發時，發現設定相同的 20 次疊代上限，卻因影響檔案數量與上下文的多寡，導致費用出現高達 8 倍的巨大差異（分別為 90 美元與 11 美元）。 • 核心觀念在於：疊代次數上限僅代表迴圈執行的次數，完全無法控制每次 API 呼叫的實際成本。 • 市面上的監控工具通常只能在 「事後」 告知花費金額，此時金錢已經流失，無法阻止帳單暴衝。 • 為了真正控制預算，作者在 Node.js 中為 OpenAI 客戶端撰寫了一個 成本防護網（Cost Guard），在每次 HTTP 請求發送前攔截並檢查累積花費。 • 該防護機制透過評估模型與訊息大小來計算預估成本，若超過設定的預算上限即會直接阻斷請求，確保 「沒有呼叫就沒有花費」。 • > 「監控告訴你已經花費了多少，而強制執行決定了你接下來被允許花多少。」 • 當 AI 代理程式以自動化方式運行時，這兩者的落差就是整張帳單的金額，事前阻斷機制成功攔截了後續的超支危機。