Anthropic 把 Claude 背後的 Messages API 從 Python 整體遷移到了 Rust。負責工程的 Katelyn Lesse 和負責產品的 Angela Jiang 在 Latent Space 播客中談了這次遷移的經過：切換後 CPU 用量下降約 40% 至 50%，首個 token 的回應時間縮短約 10% 至 20%，長時間執行的任務改善更明顯。依來賓的說法，Rust 版 API 在錄製前一週已經全面上線。
Messages API 是開發者呼叫 Claude 的主要入口。Angela Jiang 回憶，她大約一年前加入時，這套系統還是一個 Python 單體服務，只跑在一個 GCP 區域裡。
卡住它的是 CPU
外界談大型語言模型公司的瓶頸，通常盯著 GPU，這次訪談中反覆出現的卻是 CPU。用量快速成長之後，API 服務、產品後端、程式碼沙箱和持續整合都在搶 CPU，程式碼寫得越多，CI 跑得越頻繁。依來賓的描述，研究團隊和產品沙箱分的是同一份 CPU 配額，一邊多用，另一邊就得少用。Python 版服務在這種環境下顯得格外耗資源。
選用 Rust 在內部有爭議，原因很直接：
“we don't have a single Rust developer in the room.”
（會議室裡一個 Rust 開發者都沒有。）
團隊後來才陸續招進有 Rust 經驗的工程師。
人畫架構，Claude 寫實作
分工是這樣安排的：工程師負責分散式系統的設計與驗證，大部分實作程式碼交給 Claude 撰寫，Claude 也被用來幫工程師補齊需要的 Rust 知識。來賓強調，規劃和驗證這兩件事比寫程式本身更重要。
驗證的做法偏傳統。團隊先做出一份完整的 Rust 版 API 分支，把線上流量影子複製過去，逐筆比對新舊兩套系統的輸出是否一致，再透過功能開關和負載平衡一點一點把真實流量切過去。遷移由一個專責小組負責，其他工程師照常開發新功能；為了不讓兩邊越拉越遠，團隊用靜態分析標出那些在 Python 裡新增、Rust 版還沒有對應實作的功能，移植小組則盡量拒絕在遷移期間加入新需求。
來賓的估計是，依照常規做法一塊一塊漸進遷移，可能要花上好幾年，這次屬於一次性整體移植。實際用了多長時間、Claude 產生的程式碼占多大比例，訪談中沒有給出數字，外界目前也無法查證。
同類改寫放在一起看
這類「模型主寫、人來把關」的大規模改寫，最近已經出現過幾次。GitHub 先前揭露用 Copilot 把自家執行環境改寫成約 83 萬行 Rust；Opus 5.5 發表前後，也有團隊用它花兩週把 TypeScript 編譯器搬到 Rust。這幾件事的共同點是目標語言都選了 Rust，驗證都靠新舊輸出比對或完整測試集來把關。
差別在於出錯的代價。編譯器和開發工具出問題，影響的多半是開發者的本機環境；Messages API 承接的是全部對外呼叫，行為一旦不一致，就會直接落到客戶的正式環境上。Anthropic 能在這條路徑上做整體移植，靠的是影子流量和逐筆比對這套老方法，光靠模型寫得快是撐不起來的。
對其他公司來說，能借鏡的部分大概是驗證流程，未必是程式語言的選擇。沒有影子流量和輸出比對的條件，模型一次產出的大量程式碼，很難判斷是否和舊系統行為一致。
下一步動對話狀態
團隊透露，之後會進行架構層面的調整，其中一個方向是把對話狀態存在伺服器端，用戶端不必每輪都重傳完整歷史。在長對話情境下，這能省掉大量重複傳輸和重複處理。這項改動何時上線、會不會影響現有介面和計費方式，Anthropic 目前沒有公布。
參考來源：Latent Space 播客訪談、CocoLoop、Anthropic 開發者文件；訪談中查證了 CPU 降幅、首個 token 延遲改善區間與全面上線狀態。