在修改代理配置之前，必须理解提示词 token 的使用情况，尤其是工具模式的分配。作者指出，由于缺乏明确的责任归属，大多数团队无法回答这些基础问题。Pi 1.0 引入了延迟工具加载（deferred tool loading）和 Codemode 功能，将工具可见性调整为按工具级别的设置，这是一项重大变更。此前，Pi 抵制 MCP，但 1.0 版本因需要关于工具暴露的元数据而添加了原生支持。该元数据决定了工具是直接对模型可见、按需加载，还是仅在 Codemode 中可调用。工具模式会产生成本，在每次请求的系统提示或工具块中消耗 token，无论其是否相关。这种成本体现为财务支出、模型注意力资源的消耗以及可复现性的降低。一个供应商的示例显示，通过上述变更，请求的提示词 token 数量减少了约 40%。Pi 的新元数据允许工具被直接暴露、延迟加载，或仅限 Codemode。直接暴露适用于频繁使用的工具，延迟加载适用于极少使用的工具，而 Codemode 仅在需要过滤输出或组合工具时使用。Codemode 方法（模型在沙箱中编写代码以调用工具）尤其引人注目，因为它改变了进入上下文窗口的内容。然而，作者警告称，Codemode 并不能解决服务器端的问题，例如服务器可能低效地返回文本块而非结构化数据。在调优之前，建议进行审计，分别测量加载和不加载工具时的冷启动提示词 token 数量。将工具归类为三种暴露模式有助于澄清使用模式并识别不必要的模式膨胀。工具是否需要通过名称选择决定了其放置位置；若不需要，则应归入 Codemode 或延迟加载。使用频率决定了在直接暴露（频繁）和延迟加载（罕见）之间进行选择。虽然 Codemode 可以减少 token 数量，但服务器端效率仍是一个关注点。作者强调，应使用提供商的 tokenizer 测量 token 数量，并对固定任务进行调优前后的对比。可见性是一种安全措施，因为模型无法看到的工具不会被错误选择。最后，审计有助于识别利用率不足的连接器，这些连接器会膨胀提示词大小。