oterm：把 Ollama 與多家 LLM 供應商收進終端機的 Python 客戶端

終端機裡的多供應商切換，而不是又一個 Ollama 前端

README 開頭對 oterm 的定位是「the terminal client for Ollama, OpenAI, Anthropic, and any pydantic-ai-supported provider」。這句話在 0.23 前後意義不同：早期版本是 Ollama 專用客戶端，現在它把供應商抽象交給 pydantic-ai，自己負責終端介面與對話狀態。

目標使用者因此很明確。一種是本機跑 Ollama、不想為此開瀏覽器的人；另一種是手上同時有多家雲端 API key、想在同一個終端視窗裡切換模型的人。README 列出的供應商包含 OpenAI、Anthropic、Google 的 AI 與 Vertex、Groq、Mistral、Cohere、AWS Bedrock、DeepSeek、Cerebras、Grok、Hugging Face，以及走 OpenAI 相容介面的 vLLM、LM Studio、llama.cpp、OpenRouter、LiteLLM。這份清單很長，但它的來源是 pydantic-ai 的支援範圍，不是 oterm 自己逐一實作的整合。

反過來說，如果你的需求是團隊共用一份可審計的對話紀錄、或需要瀏覽器端的協作功能，oterm 的終端定位就是錯的工具。它解決的是個人操作路徑太長的問題，不是協作或治理問題。

供應商抽象交給 pydantic-ai，oterm 自己管介面與串流

從 README 能確認的機制有兩層。第一層是供應商接入：oterm 不再自行維護各家 API 的差異，而是採用 pydantic-ai 支援的供應商清單。README 對操作方式的描述很簡短，只說設定對應的 API key，該供應商就會出現在新增對話的下拉選單裡。也就是說供應商的可用性來自金鑰是否存在，而不是來自一份需要手動編輯的供應商設定檔。

第二層是終端渲染。README 的更新說明提到，Markdown 現在是在 delta 抵達時就更新，而不是每個 token 重新渲染一次，理由是長回覆不該隨著內容變長而拖慢終端。這是一個具體的取捨：增量更新換來的是串流期間的穩定度，代價是渲染路徑要維護增量狀態，而不是每次拿到完整字串重畫。

介面元件也在同一份說明裡列出：無邊框、以強調色驅動的版面、會自動長高的輸入框、行內的 [Image #N] 附件標記、可折疊的思考區段，以及取代轉圈動畫的即時 token 用量頁腳。這些是介面層的變動，但 [Image #N] 這種行內標記意味著附件在送出前是以文字形式存在於提示中，而不是獨立的附件欄位。

安裝路徑：uvx 一行，speak 額外元件要 Python 3.11

README 給的安裝指令只有一行：

uvx oterm

它同時指向官方文件站 https://ggozad.github.io/oterm/ 作為完整安裝方式、設定與用法的來源。值得注意的是 README 本身沒有列出 pip install 或系統套件安裝步驟，也沒有說明不同平台的差異，這些都留給文件站處理。

朗讀功能是額外元件，指令形式不同：

uvx "oterm[speak]"

README 明確說明這個額外元件需要 Python 3.11 或更新版本，而且基礎安裝不受影響，能力只有在額外元件存在時才會出現。這是一個乾淨的設計：不裝 speak 的人不會被拖進 piper 的依賴。README 也提到語音是透過 piper 產生，並以 GLaDOS 的聲音朗讀，回覆是邊串流邊讀。

設定方面，README 只具體提到一個區塊名稱：mcpServers。它說這個區塊改採 pydantic-ai 的標準 schema，與 Claude Desktop、Cursor 相容，完整遷移說明在 docs/mcp。除此之外的設定鍵，README 沒有列出，我不會憑空補上。

0.23 與 0.24 之間的破壞性變更，是採用前最該算的成本

README 的更新說明把兩項標為 breaking。第一項是多供應商化：oterm 不再是 Ollama 專用，這個轉變本身改變了設定的前提。第二項是 MCP 重寫：mcpServers 設定區塊改用 pydantic-ai 的標準 schema。

對既有使用者來說，這代表升級不是換個版本號就好。如果你的 mcpServers 是按舊格式寫的，升級後需要對照 docs/mcp 的遷移說明改寫。README 沒有說明是否提供自動轉換工具，也沒有說明舊格式會被忽略還是直接報錯。這一點在實際導入前必須自己驗證，不能假設。

從版本節奏看，0.23.0 在 2026-07-31、0.23.1 在 2026-08-06、0.24.0 在 2026-09-02，三個版本落在約一個月內。這個密度本身不代表品質，但對想鎖定版本的團隊來說，意味著設定格式還處於會動的階段。若你的流程依賴固定的設定檔，就要把每次升級都當成需要讀 release notes 的事件。

什麼情況下 oterm 是錯的選擇

第一種情況是依賴圖形化協作。oterm 是終端客戶端，README 描述的介面元素全部圍繞單一使用者的終端工作階段：輸入框、思考區段、token 用量頁腳。它沒有提到共享對話、權限或稽核紀錄。需要這些的團隊應該去找別的層級的工具。

第二種情況是不能接受破壞性變更的環境。README 自己把多供應商化與 MCP 重寫標為 breaking，這等於承認設定介面還在收斂。如果你的部署要求設定檔長期不動，oterm 目前的節奏不適合。

第三種情況是想用朗讀功能但環境卡在舊版 Python。speak 額外元件要求 Python 3.11 以上，README 沒有提供替代路徑。

還有一個不能從 README 確認的點：供應商的實際可用程度取決於 pydantic-ai 對該供應商的支援，而不是 oterm 自己的整合。README 列出十幾個名字，但沒有說明每個供應商在工具呼叫、圖片輸入或串流上的行為是否一致。這需要針對你要用的那一家單獨驗證。

與 Ollama 內建互動模式的差別在哪

最直接的替代方案是 Ollama 自己的命令列互動。兩者的差異在抽象層的位置：Ollama 的 CLI 綁定 Ollama 執行環境，對話與模型都來自同一個本機服務；oterm 把供應商抽象往上提一層，交給 pydantic-ai，於是你可以在同一個介面裡切換本機模型與雲端模型。

這個差別不是介面美觀問題，而是設定模型不同。用 Ollama CLI，你不需要管理 API key，也不需要處理供應商欄位；用 oterm，供應商的出現取決於對應的 API key 是否設定好，README 就是這樣描述下拉選單的行為。代價是你多了一層依賴，也多了一個會隨版本變動的設定面。

如果你只用 Ollama、也不需要圖片附件或思考區段折疊，那多出來的抽象對你沒有回報，反而增加升級時要讀的文件量。反過來說，若你本來就在多個供應商之間來回切換、每次都要開不同工具，oterm 把這件事收進一個終端視窗，這才是它真正的用途。

授權與後續維護的實際考量

專案採用 MIT License，README 與 repository 資訊一致。MIT 屬於寬鬆授權，允許修改與再散布，具體條款與你所在組織的合規要求仍需自行確認，這裡不提供法律意見。

維護成本主要落在兩處。一是追蹤破壞性變更：README 已經在 0.23 週期標示兩項 breaking，未來是否還有同類變更需要看 release notes。二是供應商面：因為整合來自 pydantic-ai，當上游新增或調整供應商支援時，oterm 的行為可能跟著變動，而這部分不會出現在 oterm 自己的說明裡。

從 repository 資訊看，主要語言是 Python，預設分支為 main，最近一次推送時間與 0.24.0 的發布時間相同，README 也帶有測試與覆蓋率徽章。這些只說明專案有持續活動與測試流程，不能推論它在你的情境下穩定。實際採用時，先把你要用的供應商與 MCP 設定在一個乾淨環境裡跑過一次，比讀任何版本說明都可靠。

編輯結論

如果你長時間待在終端機、手上同時有本機 Ollama 與雲端 API key，而且願意跟著 0.23 之後的破壞性變更調整設定，oterm 值得裝來試；若你需要穩定的團隊共用介面、或不想處理 mcpServers 區塊的遷移，就先別導入。動手前先確認三件事：你的 Python 版本是否達到 speak 額外元件要求的 3.11、pydantic-ai 是否支援你要接的供應商、以及既有 mcpServers 設定能否對應到 Claude Desktop 相容的新 schema。

官方來源

1. ggozad/oterm on GitHub
2. Issues
3. License: MIT
4. README
5. Releases