Cue 的聽寫功能有一個潤飾步驟：原始逐字稿中充滿贅字且缺少標點，此步驟會將其轉換為能表達說話者原意的文字。該步驟在哪裡執行是由一項測量決定的，而該測量是公開的。本篇文章依據 Google DeepMind 的個案研究，數據截至 2026 年 5 月，且未添加該頁面未說明的任何內容。
原始設計
此步驟的建構是為了使用雲端模型，並以本機模型作為備援，其假設是較大的模型能更準確地潤飾。團隊為此步驟設定的目標是，產生的文字讀起來像使用者本人，而非像一個模型：恢復標點、分段、移除贅字，而不強加一種內部風格。
測量
團隊在 227 個真實語音樣本上對此步驟進行了基準測試，涵蓋英語、其他語言和混合語言輸入。在該基準測試中，透過 Ollama 在 Apple Silicon 上本機執行的 Gemma 4 E4B 被選為首選模型。潤飾步驟的延遲中位數從 876 ms 降至 488 ms，該頁面描述這在團隊為此步驟設定的預算之內，因為它必須感覺比打字更快。
逆轉
基準測試後，架構被反轉：本機模型成為預設，雲端模型成為備用。桌面應用程式在啟動時會檢查 Ollama 是否正在執行；如果沒有，潤飾步驟會轉送至雲端模型，聽寫會繼續進行。
根據頁面說明，使用者有哪些改變
- 在轉換前後的四週內，活躍 beta 版使用者的平均聽寫量增加了約 30%；原本聽寫短訊息的使用者開始聽寫更長的訊息。
- 該步驟的邊際推論成本降至零，頁面說明這就是為什麼所有方案（包括免費方案）的聽寫功能都沒有限制的原因。
聲明的範圍
只有潤飾步驟移動了。在潤飾步驟之前，逐字稿是由雲端語音轉文字服務完成的，而 Cue 的智能體模式則依賴雲端模型。該頁面報告了對 Gemma 4 用於獨立智能體任務的函式呼叫的早期評估，並稱其為早期階段。因此，我們的首頁說明潤飾在使用者機器上執行，但未提及智能體在本機執行；平台頁面也記錄了相同的界線。