开跑前，先写清这次准备改什么
让模型帮你修一个报错，和让它读完整个项目再重构，费用很可能不同。估价的起点不是“我要聊多久”，而是它需要读多少内容、写多少内容，以及来回处理多少轮。
先把任务写成一句能验收的话，例如：“修复登录表单的空值报错，补上相关测试，不改其他页面。”再列出准备提供的文件、报错信息和测试结果。边界越清楚，预算越容易估，也越容易发现会话何时偏离了目标。
把账单拆成读入和写出两部分
模型通常按令牌计费。你可以把令牌理解为文字被拆分后的计量单位，但它不等于汉字数或代码行数。中文、代码、标点的拆分方式不同，不宜用固定比例直接换算。
- 输入令牌：模型读到的问题、文件内容、历史对话和工具返回结果。
- 输出令牌：模型生成的解释、修改方案、代码及其他计费输出。
查看目标模型当前的输入、输出单价，并确认计价单位。若价格按每百万令牌展示，估算公式就是：输入令牌数除以一百万，再乘输入单价；输出部分同样计算，最后相加。
用六轮修改，算一笔示例账
以下数字仅用于演示，不代表实际报价。假设输入每百万令牌十元，输出每百万令牌五十元。你预计进行六轮交互，每轮平均输入一万二千令牌、输出两千令牌。
- 总输入为七万二千令牌，估算费用为零点七二元。
- 总输出为一万二千令牌，估算费用为零点六零元。
- 两项合计一点三二元，再留出约一半余量，可把本次预算暂定为两元。
这里的关键是每轮平均输入。不能只统计首次贴入的代码：后续请求可能继续携带历史内容，也可能加入新的文件和测试日志。
为重复读取和失败重试留出余量
编程助手不一定一次就完成修改。它可能先查文件，再改代码，接着读取测试错误并继续修复。一次看似简单的任务，也可能包含多次模型请求。
因此，最好估一个区间：顺利完成需要几轮，遇到测试失败又需要几轮。缓存命中可能降低部分输入费用，但要以实际计费规则为准；还不确定能否命中时，不要先把折扣算进基础预算。
先做一次小任务，再校准整场预算
如果工具提供令牌预估，可以先检查准备发送的内容；没有预估功能，就选一个范围很小的同类任务试跑，记录实际输入、输出和费用。这笔记录通常比凭文件大小猜测更有参考价值。
在 SwiftRelay 上按量使用模型时，可以结合当前价格和试跑用量估算下一次会话。你可以注册账户，用新账户的小额赠送额度完成一次小范围试跑，再决定后续预算。
亮绿灯前，设一个人工检查点
开始前确认三件事：任务边界写清了，所选模型的单价核对了，预算里留有重试余量。随后约定一个检查点，例如完成首轮修改和测试后，先查看累计费用，再决定是否继续。
预算不是精确预言，而是及时停下来检查的依据。如果工具没有明确提供自动费用上限，就不要把心里的预算当成自动停机开关。用实际用量不断修正估算，下一次开跑时就会更有把握。