Cursor 公開 程式碼託管服務Origin的底層Git儲存系統Continuity，採用S3相容物件儲存中的預寫日誌（WAL）保存每次推送的資料，本機Git儲存庫則成為可隨時重建的快取。新架構主要因應兩種負載，一是企業持續擴大的大型單一儲存庫，另一種則是AI代理大量建立但很少使用的小型儲存庫。

Git託管服務通常會把同一個儲存庫複製到多台伺服器，以提高可用性並分擔讀取流量。不過副本越多，開發者推送程式碼時需要同步的伺服器也越多，可能拖慢寫入速度，而小型儲存庫要是固定保存多份副本，又會佔用不必要的運算與儲存資源。Cursor指出，AI代理開始大量操作Git後，使得這兩種擴充問題更加明顯。

Continuity因此將S3上的預寫日誌作為資料的最終依據，當開發者推送程式碼後，系統先將資料完整寫入S3，再回覆操作成功。本機仍使用標準Git儲存庫和高速NVMe儲存裝置處理日常操作，但伺服器上的副本不再是資料的最終依據，即使副本遺失，也能從S3重新建立，不必固定追蹤每個儲存庫存放在哪幾台伺服器。

副本數也能跟著使用量調整，大型單一儲存庫可增加更多副本分擔讀取工作，AI代理建立而且很少使用的小型儲存庫則可只保留一份，閒置一段時間後甚至能從伺服器磁碟移除，需要時再從S3重建。

Cursor公佈的合成壓力測試顯示，Continuity增加至100個副本時，唯讀Git操作仍能隨副本數增加而擴充，未觀察到程式碼推送速度下降。使用S3 Standard時，每秒最多可處理120次推送，而改用延遲較低的S3 Express One Zone後則超過300次，相關數字均為Cursor自行測試結果。

GitHub近期也面臨程式碼託管容量快速成長的壓力，8月17日因美國中部資料中心關鍵元件無法隨流量擴充， 服務中斷7小時47分鐘 。官方表示，今年4月至今每月程式碼提交數已從14億增至29億，目前Azure約承擔GitHub 58%的平台負載及一半Git操作，後續還將先從大型單一儲存庫開始，導入可隨讀取端數量增加而擴充處理能力的新架構。