定價最容易犯的錯是「憑感覺」。我把它變回一道算術題：先把成本結構攤開，再看每個數字該落在哪裡。 今天把推導過程完整寫出來，包含算完之後我必須接受的風險。

先看數字家族

價格頁上跟額度有關的數字只有四個：3、31、8,191、131,071，再加上價格本身 $31。

前四個都是 2 的次方減一：

為什麼挑這個家族？這種數字一眼就認得出是「人為設定的上限」，不會跟某個自然產生的量搞混；而且 8,191 和 131,071 剛好差 16 倍，這個比例後面會用到。

免費檔：3 與 8,191 是兩種不同的煞車

這兩個數字管的是不同的事：

• 3 req/s 是突發煞車。 防的是「一支腳本在幾秒內把你打爆」。
• 8,191／日 是總量煞車。 防的是「慢慢跑一整天」。

一天的秒數是 86,400：

8,191 ÷ 86,400 ≈ 0.095 req/s

你不能用 3 req/s 連跑一整天。 真的這樣跑，大約 45 分鐘就會撞到日上限（3 × 2,700 秒 = 8,100）。

所以免費檔的形狀是「短時間內夠快，長時間內夠省」——這正是「評估一個 API」的用量形狀：你不會 24 小時掛著，你會在某個下午把想試的東西試完。

為什麼需要一個「共享池」

131,071／日 這個數字特別的地方是——它不是每一把 key 的，而是全體免費使用者共用的。

理由很簡單：單 key 上限擋不住「換一個 email 再拿一把」。 如果只有 8,191 這條線，想繞過它的人只要註冊十個信箱，額度立刻變十倍，成本卻全部落在我身上。共享池是那條全域的煞車。

再算一個比例：

131,071 ÷ 8,191 = 16

一把免費 key 再怎麼刷，最多也只能吃掉整個免費池的十六分之一。

付費檔：賣的不是速率，是「不用排隊」

付費檔的兩個數字是 31 req/s 和 131,071／日。

每日上限跟免費池的總量是同一個數字——差別在於免費使用者的 131,071 是共用的，付費使用者的 131,071 是專屬的。

這才是付費檔真正賣的東西。 免費檔在別人用量大的時候，你的可用量會被壓縮（池子是共用的）；付費檔不會。這也是為什麼我在價格頁上老老實實寫了「shared by all free users」——與其讓使用者某天自己發現變慢，不如一開始就講清楚。

至於 $31 配上 31 req/s：我刻意讓價格和速率用同一個數字——沒有精妙的定價心理學，純粹是「看過一次就會記得」。真正決定價格的是下一節。

成本推導：$5/月 與 $31/年

先把平台側的成本攤開：

$5／月 ≈ $60／年，比 $31／年 還貴。如果把「每個付費使用者」都乘上 $60，這價格根本不夠——但這樣算不對：$5 是帳號層級的固定成本，不是每人成本，多一個使用者的邊際成本接近零，直到請求數撞到「每月 1,000 萬」那條線。來算那條線：

付費檔每日上限      131,071 次
一個月（30 天）   ×      30
                = 3,932,130 次 ≈ 393 萬次／月

方案內含          1,000 萬次／月
1,000 萬 ÷ 393 萬 ≈ 2.5

兩個把額度跑到滿的付費使用者，就會吃掉整個方案附的請求量。

所以我的定價其實建立在一個假設上：正常使用的付費者，用量遠低於上限。

如果有人真的 24 小時跑在 31 req/s 上，$31／年 是不夠的——這個風險我接受。財報是低頻資料：一家公司一年就發那幾份，正常人不會一天抓 13 萬次。額度設得寬，是為了讓「批次下載」這種合理但突發的用法不會撞牆。

為什麼是年費，不是月費

三個理由，第一個最實際：

一、手續費會吃掉小額月費。 手續費裡有一部分是「每筆固定」的。$31 一年收一次，這筆固定成本只付一次；拆成月費，同樣的成本要付十二次。定價越低、頻率越高，手續費的傷害越大。

二、對帳成本。 一個人做，十二筆小額入帳比一筆難對得多，每筆還要處理退款、爭議、失敗重試。

三、資料的節奏本來就是年。 財報是年度文件，需求跟著財報季來，不是每月平均分布——月費的收費節奏跟資料的節奏是錯開的。

誠實的缺點：年費對「只想用三個月」的人不公平。 我接受——因為免費檔就是為他設計的：8,191／日 對「評估」綽綽有餘，真的只需要短期抓一批，用免費檔分批跑就好。

這也是為什麼我沒把免費檔做得很小氣：它是這套定價的緩衝墊。 免費檔越能用，那 $31 就越像「支撐服務繼續跑」，而不是「付贖金解鎖功能」。

明天

第一週結束。明天（Day 7）回顧這一週的四個技術取捨——三個到現在都不後悔的，和一個我現在會改的。

本文為 2026 iThome 鐵人賽連載第 6 篇。系列主題：把東亞財報 PDF 煉成 LLM 讀得懂的 Markdown。