模型提供商请求是运行框架与模型提供商之间的一次往返。运行框架发送当前上下文，提供商返回一个响应（一次工具调用或最终答案）。如果智能体调用工具，一条用户消息就可能产生许多个模型提供商请求——每个工具结果都会触发下一个请求。
每个请求都会携带全部内容：系统提示词、截至当前的完整对话和每个工具结果。模型是无状态的，因此提供商不会在请求之间保留任何内容——第 40 个请求会重新发送第 39 个请求发送的全部内容，再多加一个工具结果。前缀缓存正是为了降低这种重复的成本。
请求也是计费单位。输入 Token、输出 Token和缓存折扣都按请求计算。这就是为什么一个看起来无害的问题可能产生出乎意料的费用：成本并不与你的消息长度成正比，而取决于请求数量乘以每个请求携带的上下文大小。
应当把请求与轮次区分开。轮次是与你的一次交互，而单个轮次——“修复失败的测试”——可能展开成一连串请求：
| 请求 | 模型返回 | 运行框架随后 |
|---|---|---|
| 1 | 工具调用：运行测试 | 运行测试，并追加失败输出 |
| 2 | 工具调用：读取测试文件 | 追加文件内容 |
| 3 | 工具调用：读取源文件 | 追加文件内容 |
| 4 | 工具调用：编辑源文件 | 应用编辑，并追加结果 |
| 5 | 工具调用：再次运行测试 | 运行测试，并追加通过输出 |
| 6 | 最终回答：“已修复，测试通过” | 向你展示结果 |
一个轮次产生了六个请求——每个请求都会重新发送完整上下文。当你想知道 Token 都花到哪里去了，应当数请求，而不是数轮次。
用法：
“一个问题就消耗了四万个 Token？”
“看看工具调用——12 次 grep、8 次读取、4 次编辑。每个工具结果都会产生新的模型提供商请求，而且每次都会重新发送整个会话前缀。”