Tokenless 通過五條互補策略在內容進入 LLM 上下文視窗之前削減冗餘：
-
Schema 壓縮（~57%）：精簡 Function Calling 工具定義，去除描述中的 markdown 文法、刪除 examples 和 title 欄位、截斷過長的函數與參數描述。對包含大量工具定義（數十個 Function Calling schema）的 Agent 情境效果最顯著。
-
響應壓縮（26–78%）：對 API 返回和工具執行結果應用 7 條規則——刪除 debug/trace/stack/logs 等低價值欄位（R3）、移除 null 和空值（R4/R5）、截斷超過 4096 字元的超長字串（R1）、截斷超過 32 個元素的數組（R2）、截斷超過 8 層的嵌套深度（R6）。最佳化效果最好的輸入類型：包含大量調試資訊的 API 響應（如 Kubernetes API、雲資源查詢結果）、含有冗餘欄位的 web_fetch 結果（實測 ~78%）、以及深層嵌套的 JSON 結構。
-
TOON 編碼（15–40%）：將 JSON 無損編碼為 Token 導向的緊湊格式，消除引號、逗號、花括弧等 JSON 文法開銷。對結構規整、欄位名較長的資料（如包含 description、resource_id 等長 key 的對象）最佳化效果最好。
-
命令重寫（60–90%）：整合 RTK 引擎對 70+ 種 CLI 命令輸出做智能過濾，消除進度條、ANSI 轉義碼、冗餘日誌等幹擾資訊。最佳化效果最好的輸入類型：構建工具輸出（cargo/npm/go/pytest）、包管理器輸出（dnf/yum/apt）、以及檔案清單命令（ls -la、find）的冗長結果。
-
工具就緒檢查：在工具調用前校正二進位、配置、許可權和網路依賴，自動修複缺失項並標記環境類失敗為"Skip retry"，避免 LLM 對必然失敗的命令反覆重試浪費 Token。
整體而言，Tokenless 對以下輸入輸出最佳化效果最大：含大量工具定義的 Agent 配置（Schema 壓縮）、含調試/冗餘欄位的 API 響應（響應壓縮）、結構化的 JSON 資料（TOON 編碼）、CI/CD 構建與包管理命令輸出（RTK 重寫）。