账单只给你一个总数，而总数唯一能支撑的决定是「少用一点」——那不是优化。
把用量按场景贴进来（名称、请求数、输入/输出/缓存 token），代码算四件人估不准的事：每个场景的真实成本与占比（多数系统里八成成本集中在一两个场景）、缓存到底省了多少钱、按当前速率的月度推算与预算余量、以及单次请求均价。
单价这里不给你：各家每百万 token 的价格每个月都在变，写死一定过期，还会让你拿着错的数字做决定。去账单页抄三个数填进来就行——工具不需要知道你用的是谁家。
还会点出三处账单上看不出来、但每次都在漏的：重试（解析失败率 5% 就是成本多 5%，而多数人从没量过）、上下文累积（多轮对话的成本是轮数的平方级，不是线性）、拿大模型做小事。
A bill gives you one number, and one number only supports one decision — use less. That isn't optimisation.
Paste usage per scenario (calls, input, output, cached tokens) and the code computes what people estimate badly: true cost and share per scenario (in most systems 80% sits in one or two), what caching actually saved, monthly projection and budget runway, and cost per call.
No prices are provided here: per-million rates change monthly, and hard-coding them guarantees they'll be wrong. Copy three numbers off your own bill — the tool doesn't need to know whose API it is.
It also names three leaks a bill can't show: retries (a 5% parse-failure rate is 5% more cost, and almost nobody measures it), context accumulation (multi-turn cost is quadratic in turns, not linear), and using a large model for small jobs.
按你的场景排出降本动作的性价比顺序（改动量 vs 省下的钱）、缓存前缀的具体改法、模型分档建议、以及一份可持续跑的成本监控口径。Cost-reduction actions ranked by effort versus saving for your actual scenarios, how to restructure prompt prefixes for caching, model-tier routing, and a monitoring scheme you can keep running.
所有结果都由你自己填写的用量与单价算出，本工具不连接任何 API、不读取账单、不存储数据，也刻意不提供任何厂商的价格——价格随时变动，且各家的计费口径不同（缓存写入费、批处理折扣、最低计费单位、思考 token 是否计费等）。月度推算是线性外推，用量增长时会低估。请以你的服务商账单为准。
Everything is computed from the usage and prices you enter. This connects to no API, reads no bill, stores nothing, and deliberately publishes no vendor pricing — rates change and billing models differ (cache-write fees, batch discounts, minimum units, whether reasoning tokens bill). Monthly projection is linear extrapolation and under-estimates growth. Your provider's invoice governs.