文章作者主張，開發者若僅依賴供應商提供的前端介面（如 TUI、GUI 或語音通話）與訂閱服務來使用大型語言模型（LLM），將難以獲得足夠的工程級別數據以進行決策。作者批評現有供應商提供的分析面板往往只是干擾項，缺乏具備時間序列的 Token 使用統計數據，無法滿足工程師的需求。

作者提出自行運行 LLM 代理（Proxy）的五個主要理由： 1. 在單一受控端點整合多供應商與多模型。 2. 記錄詳細日誌，包括哪個 API 金鑰、透過哪個客戶端、在何時呼叫了哪個模型及其狀態。 3. 使用虛擬 API 金鑰，避免在主工作、代理（Agents）和測試框架中混用單一主金鑰。 4. 基礎設施完全由使用者掌控。 5. 能夠極速切換模型與供應商，無需重新配置整個環境。

作者強調，重點不在於推薦特定的代理服務商，而在於使用者應在受控環境中自行運行並根據需求修改代理。例如，作者透過自訂的代理獲得了更好的洞察、自訂 MCP 伺服器端點及其他功能。當編碼會話出現快取未命中（cache miss）時，作者能在 20 秒內手動定位原因，且由於其使用的代理具備 API，未來可實現自動化。作者總結認為，擁有基礎設施、應用可見性、數據路徑和存儲的控制權是做好工作的必要條件，即使無法完全理解 LLM 的底層原理，也應確保其在提供推理服務時被妥善監控（instrumented）。

尚待確認：作者提到的 'Labubu'、'McRib' 等具體應用場景為個人舉例，非普遍事實。

尚待確認：社群評論中關於特定工具（如 Codex, Claude Code, OpenCode）的技術細節僅為用戶觀點，未經原文來源驗證。

社群觀察

社群討論中出現了對作者觀點的反駁與補充：

1. **無需代理的替代方案**：用戶 CharlieDigital 認為不需要也不應該使用代理，因為這會在生產力路徑上引入單點故障。他指出 Codex 和 Claude Code 等工具已輸出 OpenTelemetry (OTel) traces，其他框架如 OpenCode、Pi 也可透過插件架構實現 OTel 數據發射，建議直接託管 OpenTelemetry collector。

2. **訂閱制與 API 計費的成本爭議**：用戶 NeutralWanted 表示難以理解使用 API 金鑰相對於訂閱制的成本合理性。該用戶測試發現，雖然 Claude Max ($200/月) 訂閱能接近或達到每週限額，但使用 API 金鑰僅需 2-3 天就會耗盡 $200 的額度。

3. **開源工具分享**：用戶 gbdubs 分享了一個名為 Pharos 的開源 Mac App，用於跨供應商處理並詳細檢查使用情況。

4. **訂閱制下的數據收集方式**：用戶 jakozaur 指出，若支付 API 價格則代理是有用的；但對於訂閱制用戶，直接從 `~/.claude/projects/` 等目錄收集 JSONL 文件更容易，且這些文件比代理看到的數據組織得更好（例如包含子代理資訊）。不過，該用戶也強調跨整個組織收集代理會話數據價值最高，需注意憑證清理與安全性。

5. **Tailscale Aperture**：用戶 passive 提到 Tailscale 免費提供的 Aperture 工具，雖然不是完全自有的基礎設施，但位於使用者的 tailnet 中，提供了一定程度的控制權。該工具能清晰展示代理行為，具備高度可配置性與擴展性，且團隊持續更新。