Everybody loves AI until the invoice shows up!

Not the cute "we spent a few hundred dollars experimenting" invoice that gets hand-waved away as innovation spend. I mean the kind of invoice that makes finance suddenly become deeply curious about architecture decisions they previously considered engineering trivia, while operations and/or product teams insist everything is still technically a pilot, and leadership starts asking whether we can "optimize this" as though that thought had just occurred to humanity.我指的不是那种“我们花了数百美元做实验”的可爱发票，那种发票通常会被当作创新支出而一笔带过。我指的是那种会让财务部门突然对他们以前认为是工程琐事的架构决策产生浓厚兴趣的发票，同时运营和/或产品团队坚持认为一切在技术上仍处于试点阶段，而领导层则开始问我们是否可以“优化一下”，仿佛这个念头是人类刚刚才想到的。

If you have been around enterprise technology for any length of time, this probably feels familiar, because we did this exact dance with cloud. We got excited about elasticity, speed, self-service, digital transformation, and developer empowerment. Then we discovered that moving fast without an operational model produces some incredibly educational invoices. FinOps emerged because cloud economics got weird enough that traditional budgeting and governance models stopped being sufficient.如果你在企业技术领域待过一段时间，这听起来可能很熟悉，因为我们曾在云服务上经历过完全相同的过程。我们对弹性、速度、自助服务、数字化转型和赋能开发者感到兴奋。然后我们发现，没有运营模式的快速发展会产生一些令人大开眼界的账单。FinOps（云财务运营）的出现，是因为云经济变得足够复杂，以至于传统的预算和治理模式已不再适用。

AI is following the same path, except the economics are stranger, because the thing driving spend is not always infrastructure. Sometimes it is architecture. Sometimes it is workflow design. Sometimes it is application behavior. And sometimes it is a prompt that grew into an ungoverned monster because everyone kept adding "just one more helpful instruction."人工智能正在走同一条路，只是其经济逻辑更为诡异，因为驱动支出的往往不是基础设施。有时是架构，有时是工作流设计，有时是应用程序行为，还有时是一个提示词，因为每个人都不断地添加“一条有用的指令”，最终演变成了一个不受控制的怪物。

That last one happens more than people would like to admit.

AI Cost Is Not "Just Another Cloud Bill"AI 成本不仅仅是“另一张云服务账单”

One of the biggest mistakes I see right now is treating AI cost management like it is cloud FinOps with slightly different line items. That instinct makes sense, because most of us already know how to reason through cloud spend. We understand compute utilization, storage growth, idle resources, reserved pricing, licensing efficiency, network egress, and the thousand small architectural decisions that quietly evolve into larger financial problems when nobody is paying attention.我目前看到的最大误区之一，就是把 AI 成本管理当作是换了几个项目的云 FinOps。这种直觉是可以理解的，因为我们大多数人已经知道如何分析云支出。我们了解计算利用率、存储增长、闲置资源、预留定价、许可效率、网络出口，以及当无人关注时，成千上万个微小的架构决策是如何悄然演变成更大的财务问题的。

Those instincts still matter, but AI changes the shape of the problem, because cost is often driven by interaction behavior rather than static infrastructure allocation. A virtual machine is fairly honest about what it is doing. Storage accounts are not emotionally complicated (at least not yet). Network egress may occasionally feel personally insulting, but at least it behaves predictably. AI workloads can be much more chaotic, because tiny implementation decisions dramatically change cost behavior. A prompt gets longer. A context window expands. A retrieval pipeline injects more content. An agent retries failed workflows. A product team decides the assistant should feel "more conversational." Suddenly the conversation is no longer about infrastructure optimization. It is about behavioral economics hiding inside application design.这些直觉依然重要，但 AI 改变了问题的形态，因为成本往往是由交互行为而非静态基础设施分配驱动的。虚拟机在工作内容上相当“诚实”；存储账户在情感上并不复杂（至少目前如此）；网络出口虽然有时让人觉得被冒犯，但至少行为可预测。AI 工作负载则可能混乱得多，因为微小的实现决策会剧烈改变成本表现。提示词变长了、上下文窗口扩大了、检索管道注入了更多内容、智能体重试了失败的工作流、产品团队决定助手应该感觉“更像对话”。突然间，讨论的焦点不再是基础设施优化，而是隐藏在应用程序设计中的行为经济学。

That is a very different operational challenge, and if you approach it with only traditional infrastructure instincts, you are going to miss some very expensive patterns.这是一个非常不同的运营挑战，如果你只用传统的架构直觉去应对，你将错过一些非常昂贵的模式。

Tokens Are Tiny Budget GremlinsToken 是微小的预算“小精灵”

Let us talk about tokens, because AI conversations have a habit of casually using the term like everyone instinctively understands what it means, when in reality half the room is only quietly nodding while internally wondering if they should have asked sooner. Technically, tokens are chunks of text processed by the model. They are not exactly words and not exactly characters, and the exact implementation varies by provider. That distinction matters for precision, but from a practical FinOps perspective the important thing is much simpler: tokens are how you get billed! What you send into the model consumes tokens. What comes back out consumes tokens. Now, depending on the provider, cached interactions, tool execution, and orchestration overhead can create additional economic nuance which can turn simple assumptions into dangerously incomplete ones. It's...a lot...and confusing.让我们谈谈 Token（词元），因为 AI 讨论中人们习惯随口使用这个词，仿佛每个人都天生理解它的含义，而实际上房间里有一半人只是在默默点头，内心却在后悔没早点问。从技术上讲，Token 是模型处理的文本块。它们既不完全是单词也不完全是字符，具体实现因提供商而异。这种区别对于精度很重要，但从实用的 FinOps 角度来看，重点很简单：Token 是你被计费的方式！你发送给模型的内容会消耗 Token，模型返回的内容也会消耗 Token。此外，根据提供商的不同，缓存交互、工具执行和编排开销可能会产生额外的经济细微差别，这可能使简单的假设变得极其危险且不完整。这……确实很多……而且令人困惑。

This is where AI spending starts behaving in ways traditional infrastructure teams find deeply irritating. A short request asking for a summary may barely register. A heavily engineered enterprise prompt with role instructions, governance controls, formatting directives, prior conversation history, retrieved documents, workflow metadata, and supporting tool definitions is a very different story. Then the model responds with a wonderfully verbose answer, because apparently we have all unintentionally reinforced the belief that concise answers are somehow less intelligent.这就是 AI 支出开始以传统基础设施团队觉得极其恼火的方式表现出来的地方。一个简单的总结请求可能几乎不产生费用。但一个经过精心设计的企业级提示词，包含角色指令、治理控制、格式指令、过往对话历史、检索到的文档、工作流元数据和支持工具定义，情况就完全不同了。然后模型还会给出一个极其冗长的回答，因为显然我们所有人都无意中强化了一种信念，即简洁的回答不如冗长的回答“智能”。

The outcome is you are now paying for input, output, and potentially a collection of supporting behaviors that completely change the economics of what looked, at first glance, like a simple interaction. A poorly sized VM does not become dramatically more expensive because someone reworded a sentence, whereas an LLM absolutely can.结果就是，你不仅在为输入和输出付费，还在为一系列支持行为付费，这些行为彻底改变了起初看起来只是简单交互的经济成本。一个尺寸不当的虚拟机不会因为有人改了一个句子就变得昂贵得多，而大语言模型绝对可以。

Your Architecture Has an AI Cost Personality你的架构具有 AI 成本“人格”

If you have followed my FinOps content before, you know I like talking about architecture having a cost personality, because different design decisions create different economic behaviors. AI takes that concept and cranks the intensity levers.如果你之前关注过我的 FinOps 内容，你就知道我喜欢说架构具有“成本人格”，因为不同的设计决策会产生不同的经济行为。AI 将这一概念的强度杠杆拉到了极致。

A lightweight FAQ chatbot has one personality. A retrieval-augmented knowledge assistant has another. A proposal analysis workflow behaves differently than a coding copilot. An internal enterprise knowledge assistant behaves differently than a customer-facing support implementation. A multi-agent orchestration model, where specialized agents hand work between each other, may be technically elegant and completely appropriate for the business use case, but it does not behave economically like a straightforward prompt-response implementation.轻量级常见问题（FAQ）聊天机器人有一种人格。检索增强型知识助手是另一种。提案分析工作流的表现与编码助手不同。内部企业知识助手与面向客户的支持实现方式也不同。多智能体编排模型（其中专门的智能体相互传递工作）在技术上可能很优雅，完全适合业务用例，但在经济表现上却不像简单的提示-响应实现。

That matters, because I still hear people talk about "AI spend" like it is a meaningful single category. Know it's not. To me, that's like talking about "cloud spend" without distinguishing between ephemeral development workloads, enterprise ERP infrastructure, serverless event processing, and data lake analytics. The architecture underneath determines the economics, and pretending all AI workloads behave similarly leads to terrible optimization decisions.这一点很重要，因为我仍然听到人们将“AI 支出”当作一个有意义的单一类别来谈论。要知道它不是。对我来说，这就像在不区分临时开发工作负载、企业 ERP 基础设施、无服务器事件处理和数据湖分析的情况下谈论“云支出”一样。底层的架构决定了经济性，假装所有 AI 工作负载的表现都相似，会导致糟糕的优化决策。

If you're building a simple assistant answering short transactional questions, your economic expectations should look very different than if you're building an agentic workflow that reasons, retrieves information, invokes tools, validates outcomes, retries failures, and refines results before responding. If you're embedding copilots into employee productivity workflows, your cost model should look different than a customer-facing conversational experience handling thousands of interactions.如果你正在构建一个回答简单事务性问题的助手，你的经济预期应该与构建一个能够推理、检索信息、调用工具、验证结果、重试失败并优化结果后再响应的智能体工作流完全不同。如果你将 Copilot 嵌入到员工生产力工作流中，你的成本模型应该与处理数千次交互的面向客户的对话体验不同。

Architecture shapes spend and always has...AI just makes that relationship noisier.架构塑造支出，这一点一直没变……AI 只是让这种关系变得更加嘈杂。

Context Windows: Where Good Intentions Go Shopping上下文窗口：好意去向何方

One of the easiest ways teams accidentally build expensive AI systems is through context accumulation, because every contributing decision sounds perfectly reasonable in isolation. You want the assistant to feel conversational, so you preserve chat history. You want better answers, so you implement retrieval-augmented generation and inject supporting documentation. You want stronger governance, so you add system instructions around acceptable use, formatting, tone, and policy controls. You want personalization, so user context gets appended. You want tooling, so orchestration metadata and function definitions are included. Product wants a smarter experience. Security wants stronger guardrails. Ultimately everyone wants their enhancement to make the system better. This has all the makings of what I like to call enterprise architecture drama. Taken individually, these are not reckless decisions. Collectively, they can (and often) get hilariously expensive.团队无意中构建昂贵 AI 系统最简单的方式之一就是通过上下文堆积，因为每一个贡献决策在孤立看时听起来都非常合理。你想让助手感觉像在对话，所以你保留聊天记录；你想获得更好的答案，所以你实施检索增强生成并注入支持文档；你想加强治理，所以你添加了关于可接受使用、格式、语气和政策控制的系统指令；你想实现个性化，所以你附加了用户上下文；你想使用工具，所以你包含了编排元数据和函数定义。产品部门想要更智能的体验，安全部门想要更强的护栏。最终，每个人都希望他们的改进能让系统变得更好。这具备了我所说的“企业架构闹剧”的所有要素。单独来看，这些决策并不鲁莽。但加在一起，它们往往会变得极其昂贵。

A user asks something simple like "what changed in this contract draft?" and what actually gets sent to the model includes system instructions, governance rules, previous conversation history, retrieved content, metadata, tool definitions, formatting expectations, workflow state, and the actual question hanging out near the bottom wondering how its life got so complicated. Every time that request runs, you pay for the whole payload, not just the visible question.用户问了一个简单的问题，如“这份合同草案有什么变化？”，而实际发送给模型的内容包括系统指令、治理规则、之前的对话历史、检索到的内容、元数据、工具定义、格式预期、工作流状态，以及悬在底部、想知道自己的生活为何变得如此复杂的问题本身。每次执行该请求，你都要为整个负载付费，而不仅仅是那个可见的问题。

That is what makes this category of waste so sneaky. Nobody believes they are making irresponsible architectural decisions. They are making incremental product and operations improvements. The problem is that incremental improvements accumulate, and context windows are remarkably indifferent to your intentions.这就是这类浪费如此隐蔽的原因。没人认为自己在做不负责任的架构决策。他们是在进行渐进式的产品和运营改进。问题在于，渐进式改进会累积，而上下文窗口对你的意图完全无动于衷。

Agents: Tiny Distributed Systems Wearing Friendly Faces

This is where things get especially entertaining, so pull out the popcorn!

A straightforward chatbot interaction is easy to reason about. A user sends a request, the model processes request, and a response comes back. Costs scale in a reasonably understandable way.简单的聊天机器人交互很容易理解。用户发送请求，模型处理请求，然后返回响应。成本以一种相当可理解的方式扩展。

Agents are fundamentally different, because they transform what looks like a simple interaction into a potentially complex backend workflow. Instead of simply answering, the system may reason through the request, decide which tools to invoke, query external systems, validate outputs, retry failed actions, refine conclusions, and then finally produce a response. That entire exchange can be incredibly useful, but it can also become financially spectacular in all the wrong ways if no one is paying attention.智能体则从根本上不同，因为它们将看起来简单的交互转换成了可能复杂的后端工作流。系统不仅是在回答，还可能通过推理请求、决定调用哪些工具、查询外部系统、验证输出、重试失败的操作、优化结论，最后才产生响应。整个交换过程可能非常有用，但如果无人关注，它也可能在财务上变得极其夸张。

From the user's perspective, they asked one question. From the backend's perspective, that request may have triggered multiple reasoning passes, tool calls, data lookups, validation logic, retries, re-evaluations, and formatting steps. That is not one interaction. That is a tiny, distributed workflow wearing a friendly conversational interface and quietly helping itself to your budget.从用户的角度看，他们只问了一个问题。从后端的角度看，该请求可能触发了多次推理过程、工具调用、数据查找、验证逻辑、重试、重新评估和格式化步骤。那不是一次交互，而是一个微小的、分布式的、披着友好对话界面的工作流，正在悄悄地蚕食你的预算。

To be clear, this is not Shannon's argument AGAINST agents. Agentic architectures absolutely have legitimate business value. This is an argument for understanding their economics. If you assume one user interaction equals one billable event and your architecture actually behaves like a multi-step autonomous workflow, your financial assumptions are already wrong.需要明确的是，这不是 Shannon 反对智能体的论点。智能体架构绝对具有合法的商业价值。这是一个关于理解其经济性的论点。如果你假设一次用户交互等于一次可计费事件，而你的架构实际上表现得像一个多步骤的自主工作流，那么你的财务假设就已经错了。

Here's my rule of thumb: Autonomy is powerful. Autonomy is also expensive when left unsupervised.这是我的经验法则：自主性很强大。但如果无人监管，自主性也很昂贵。

Traditional FinOps vs AI FinOps传统 FinOps 与 AI FinOps

Traditional FinOps asks infrastructure-centric questions. Which workloads are expensive? Which resources are underutilized? Can we right size? Should we shift to reserved pricing? Are we retaining too much storage? Can licensing be optimized? These are useful questions, but AI introduces a different category of investigation, because inefficiencies often hide inside application behavior rather than obvious infrastructure waste.传统 FinOps 问的是以基础设施为中心的问题。哪些工作负载昂贵？哪些资源未被充分利用？我们可以调整规模吗？我们应该转向预留定价吗？我们的存储保留太多了吗？许可可以优化吗？这些都是有用的问题，但 AI 引入了另一类调查，因为低效往往隐藏在应用程序行为中，而不是明显的基础设施浪费中。

Now the questions get more interesting. Why is one workflow dramatically more expensive than another? Why is a simple assistant generating enough output to qualify as serialized fiction? Why are prompt payloads growing over time? Why is an agent retrying failed operations with the confidence of someone who has never encountered diminishing returns? Why is one business unit consuming dramatically more tokens than another for what appears to be the same use case?现在问题变得更有趣了。为什么一个工作流比另一个昂贵得多？为什么一个简单的助手生成的输出足以写成连载小说？为什么提示词负载在随时间增长？为什么一个智能体在重试失败操作时表现得如此自信，仿佛从未遇到过收益递减？为什么一个业务部门在看似相同的用例下消耗的 Token 比另一个多得多？

These are not classic infrastructure questions, rather they are application behavior questions. That distinction matters, because traditional FinOps gives you a strong foundation but not a complete operating model for AI economics.这些不是经典的架构问题，而是应用程序行为问题。这种区别很重要，因为传统的 FinOps 为你提供了强大的基础，但不是 AI 经济学的完整运营模式。

The optimization target should be shifting from infrastructure efficiency toward interaction efficiency.优化目标应该从基础设施效率转向交互效率。

Unit Economics Are the Adult Conversation单位经济效益才是成年人的谈话

This is the part executives usually understand immediately once the conversation is framed correctly. Nobody actually cares about AI spend in isolation. Rather, they care whether the spend creates value.一旦对话方向正确，高管们通常能立即理解这一点。没人真正在意孤立的 AI 支出。他们在意的是这种支出是否创造了价值。

A $20,000 monthly AI bill might be entirely justified if it meaningfully reduces support costs, accelerates engineering productivity, shortens proposal generation cycles, or improves customer outcomes. A much smaller bill may be wasteful if it powers something nobody meaningfully uses.如果每月 20,000 美元的 AI 账单能显著降低支持成本、加速工程生产力、缩短提案生成周期或改善客户成果，那么它就是完全合理的。而如果账单金额较小，但支持的是没人真正使用的东西，那也是浪费。

That means mature AI FinOps conversations need to move quickly toward unit economics:这意味着成熟的 AI FinOps 对话需要迅速转向单位经济效益：

• What is the cost per support interaction?每次支持交互的成本是多少？

• What is the cost per contract review?每次合同审查的成本是多少？

• What is the cost per proposal generated?每次生成的提案成本是多少？

• What is the cost per engineering productivity assist?每次工程生产力辅助的成本是多少？

• What is the cost per knowledge retrieval?每次知识检索的成本是多少？

• What is the cost per customer workflow completed?每个完成的客户工作流成本是多少？

Those are useful business conversations. "AI is expensive" is usually just budget anxiety masquerading as strategy. Budget anxiety usually also kills any and maybe all innovation.这些才是有效的商业对话。“AI 很贵”通常只是披着战略外衣的预算焦虑。而预算焦虑通常会扼杀任何乃至所有的创新。

Making This Operational: Provider Dashboards Help...实现运营化：提供商仪表板有帮助……

...but they are not governance.……但它们不是治理。

Provider-native telemetry matters, and you absolutely need it to tell the tale appropriately. OpenAI exposes usage reporting. Azure OpenAI provides monitoring telemetry through Azure observability tooling. Anthropic exposes detailed usage data through SDK responses, including the prompt caching fields that change the economics in ways naive counting misses. Google returns usage metadata on every Gemini response. That is useful operational visibility, but it is not governance.提供商原生的遥测数据很重要，你绝对需要它来准确讲述故事。OpenAI 提供使用报告；Azure OpenAI 通过 Azure 可观测性工具提供监控遥测；Anthropic 通过 SDK 响应提供详细的使用数据，包括改变经济性的提示词缓存字段，这是单纯计数所忽略的；Google 在每次 Gemini 响应中返回使用元数据。这些是有用的运营可见性，但它们不是治理。

Provider dashboards tell you what the service consumed, but they generally do not tell you which business workflow created the cost, which application feature is responsible, which team owns the spend, or whether the interaction produced meaningful business value. Without that attribution, you are effectively staring at infrastructure telemetry while trying to answer business questions.提供商仪表板告诉你服务消耗了什么，但它们通常不会告诉你哪个业务工作流产生了成本、哪个应用程序功能负责、哪个团队拥有支出，或者交互是否产生了有意义的商业价值。没有这种归因，你实际上是在盯着基础设施遥测数据，试图回答商业问题。

That is why application instrumentation matters.

Instrument the Application Like a Grown-Up像成年人一样对应用程序进行仪表化

If you care about AI economics, the application needs to participate in the observability story. At minimum, I would want telemetry capturing application name, environment, feature name, workflow identifiers, model selection, token usage (broken out by input, output, cache, and reasoning where the provider exposes that level of information), estimated cost, latency, tool invocation counts, response outcomes, and enough user or session correlation to tie activity back to meaningful business workflows.如果你关心 AI 经济学，应用程序需要参与到可观测性中。至少，我希望遥测数据能捕获应用程序名称、环境、功能名称、工作流标识符、模型选择、Token 使用情况（按提供商暴露的输入、输出、缓存和推理进行细分）、预估成本、延迟、工具调用次数、响应结果，以及足够的关联用户或会话信息，以便将活动与有意义的业务工作流联系起来。

This is where the conversation shifts from "the AI bill feels weird" to "we can actually explain what happened."这就是对话从“AI 账单感觉很奇怪”转变为“我们可以解释发生了什么”的地方。

Capture Real Usage, Not Vibes捕获真实使用情况，而不是“感觉”

A generic token estimator is fine for explaining the concept, but if you are building something real, you want actual provider-returned usage data. Each of the three major providers expose this information, and each one exposes nuance that naive token counting completely misses. Caching changes the math. Reasoning and "thinking" tokens get billed as output. Cached input tokens are usually a subset of your reported input, not a separate line, so you have to subtract before you multiply (a mistake I have watched double a cost estimate).通用的 Token 估算器对于解释概念还可以，但如果你在构建真实的东西，你需要提供商返回的实际使用数据。三大提供商都暴露了这些信息，且每一个都暴露了单纯的 Token 计数所忽略的细微差别。缓存改变了数学逻辑。推理和“思考”Token 按输出费率计费。缓存的输入 Token 通常是你报告输入的一部分，而不是单独的一行，所以你必须在相乘之前减去它们（我曾见过一个错误将成本估算翻了一倍）。

Here is the quick version for each provider. The full, repo-ready version with shared pricing tables and a structured telemetry emitter is linked at the bottom of this blog.以下是每个提供商的简要版本。包含共享定价表和结构化遥测发射器的完整、可直接使用的代码库链接在本博客底部。

Claude (Anthropic)Claude (Anthropic)

Anthropic returns input_tokens, output_tokens, cache_creation_input_tokens, and cache_read_input_tokens as separate fields, which is exactly the kind of granularity AI FinOps needs.Anthropic 将 input_tokens、output_tokens、cache_creation_input_tokens 和 cache_read_input_tokens 作为单独的字段返回，这正是 AI FinOps 所需的粒度。

import anthropic

# === pick your model here ===
MODEL = "claude-opus-4-8"   # current Anthropic flagship (Opus 4.8)

MODEL_PRICING = {
    # USD per 1M tokens. Verify against current Anthropic pricing before billing.
    "claude-opus-4-8": {
        "input": 5.00,
        "output": 25.00,
        "cache_write_5m": 6.25,   # 1.25x input
        "cache_read": 0.50,       # 0.1x input
    }
}

def estimate_claude_cost(model: str, usage) -> float:
    p = MODEL_PRICING[model]
    input_tokens = getattr(usage, "input_tokens", 0) or 0
    output_tokens = getattr(usage, "output_tokens", 0) or 0
    cache_write = getattr(usage, "cache_creation_input_tokens", 0) or 0
    cache_read = getattr(usage, "cache_read_input_tokens", 0) or 0
    return round(
        (input_tokens / 1_000_000) * p["input"]
        + (output_tokens / 1_000_000) * p["output"]
        + (cache_write / 1_000_000) * p["cache_write_5m"]
        + (cache_read / 1_000_000) * p["cache_read"],
        6,
    )

client = anthropic.Anthropic()
resp = client.messages.create(
    model=MODEL,
    max_tokens=512,
    messages=[{"role": "user", "content": "Summarize this contract change."}],
)
print(estimate_claude_cost(MODEL, resp.usage))

Note that with Claude, input_tokens already excludes cached reads and cache writes, so you add the four buckets together rather than subtracting. That is the opposite of how OpenAI and Gemini report it, which is exactly the kind of detail that wrecks a spreadsheet built on assumptions.注意，对于 Claude，input_tokens 已经排除了缓存读取和缓存写入，因此你需要将这四个桶加在一起，而不是减去。这与 OpenAI 和 Gemini 的报告方式正好相反，这正是那种会摧毁基于假设构建的电子表格的细节。

ChatGPT (OpenAI)ChatGPT (OpenAI)

OpenAI reports total prompt_tokens (which already includes any cached tokens) plus a cached_tokens breakdown, and reasoning tokens roll into completion_tokens. So cached input is a subset you have to back out before pricing.OpenAI 报告总的 prompt_tokens（已经包含任何缓存的 Token），加上 cached_tokens 的细分，推理 Token 会计入 completion_tokens。因此，缓存的输入是一个你必须在定价前扣除的子集。

from openai import OpenAI

# === pick your model here ===
MODEL = "gpt-5.5"   # current OpenAI flagship (GPT-5.5)

MODEL_PRICING = {
    # USD per 1M tokens. Verify against current OpenAI pricing before billing.
    "gpt-5.5": {
        "input": 5.00,
        "output": 30.00,
        "cached_input": 0.50,   # 0.1x input
    }
}

def estimate_openai_cost(model: str, usage) -> float:
    p = MODEL_PRICING[model]
    prompt = usage.prompt_tokens or 0
    completion = usage.completion_tokens or 0  # reasoning tokens included here
    details = getattr(usage, "prompt_tokens_details", None)
    cached = getattr(details, "cached_tokens", 0) or 0
    uncached_input = prompt - cached
    return round(
        (uncached_input / 1_000_000) * p["input"]
        + (cached / 1_000_000) * p["cached_input"]
        + (completion / 1_000_000) * p["output"],
        6,
    )

client = OpenAI()
resp = client.chat.completions.create(
    model=MODEL,
    messages=[{"role": "user", "content": "Summarize this contract change."}],
)
print(estimate_openai_cost(MODEL, resp.usage))

Gemini (Google)Gemini (Google)

Google's current SDK is google-genai (the older google-generativeai package is on its way out). Usage comes back on response.usage_metadata. Google 目前的 SDK 是 google-genai（旧的 google-generativeai 包即将停用）。使用情况在 response.usage_metadata 中返回。

Two things to watch: cached_content_token_count is a subset of prompt_token_count, and thoughts_token_count (thinking) is billed at the output rate, so it gets added to your output bucket, not your input one. One more for the Pro tier: Gemini 3.1 Pro uses context-tier pricing, where rates step up once input crosses 200K tokens (the quick snippet below shows the standard tier; the repo handles the step-up).需要注意两点：cached_content_token_count 是 prompt_token_count 的子集；thoughts_token_count（思考）按输出费率计费，因此它会被加到你的输出桶中，而不是输入桶中。对于 Pro 层级还有一点：Gemini 3.1 Pro 使用上下文分层定价，当输入超过 200K Token 时费率会上升（下面的简短片段显示的是标准层级；代码库处理了分层上升的情况）。

from google import genai

# === pick your model here ===
MODEL = "gemini-3.1-pro"   # current Gemini flagship (3.1 Pro)

MODEL_PRICING = {
    # USD per 1M tokens, standard context (<=200K). Verify before billing.
    "gemini-3.1-pro": {
        "input": 2.00,
        "output": 12.00,
        "cached_input": 0.20,   # 0.1x input
    }
}

def estimate_gemini_cost(model: str, usage) -> float:
    p = MODEL_PRICING[model]
    prompt = usage.prompt_token_count or 0
    cached = getattr(usage, "cached_content_token_count", 0) or 0
    candidates = usage.candidates_token_count or 0
    thoughts = getattr(usage, "thoughts_token_count", 0) or 0
    uncached_input = prompt - cached
    billable_output = candidates + thoughts  # thinking billed as output
    return round(
        (uncached_input / 1_000_000) * p["input"]
        + (cached / 1_000_000) * p["cached_input"]
        + (billable_output / 1_000_000) * p["output"],
        6,
    )

client = genai.Client()
resp = client.models.generate_content(
    model=MODEL,
    contents="Summarize this contract change.",
)
print(estimate_gemini_cost(MODEL, resp.usage_metadata))

Three providers, three slightly different ways of reporting the same idea, and three different places where a naive estimate could potentially go wrong. The pattern that scales is the same regardless of provider: wrap the SDK call, capture the actual usage metadata, enrich it with application context (feature, workflow, team, environment), and emit a structured telemetry event.三个提供商，三种略有不同的报告同一概念的方式，以及三个可能导致简单估算出错的地方。无论提供商是谁，可扩展的模式都是一样的：封装 SDK 调用，捕获实际的使用元数据，用应用程序上下文（功能、工作流、团队、环境）丰富它，并发出结构化的遥测事件。

Azure Teams: KQL Is Still Your FriendAzure 团队：KQL 依然是你的好朋友

If you are an Azure-heavy shop, this becomes operationally straightforward, because AI telemetry can land in Log Analytics alongside broader application observability. Emit a custom event per call and the queries write themselves.如果你是 Azure 重度用户，这在运营上会变得很简单，因为 AI 遥测数据可以与更广泛的应用程序可观测性一起存入 Log Analytics。为每个调用发出一个自定义事件，查询语句就自动生成了。

customEvents
| where name == "AIUsageEvent"
| extend Provider = tostring(customDimensions.provider)
| extend Feature = tostring(customDimensions.feature)
| extend Model = tostring(customDimensions.model)
| extend TotalTokens = todouble(customDimensions.total_tokens)
| extend EstimatedCost = todouble(customDimensions.estimated_cost_usd)
| summarize
    Requests = count(),
    TotalTokens = sum(TotalTokens),
    EstimatedCost = sum(EstimatedCost)
    by Provider, Feature, Model, bin(timestamp, 1d)
| order by EstimatedCost desc

Now you can identify expensive workflows instead of staring vaguely at provider billing reports and hoping insight arrives.

Useful Tools Worth Exploring值得探索的有用工具

If you are building this seriously, several platforms are worth a look:

• Langfuse for tracing, prompt analytics, and cost attribution.Langfuse：用于追踪、提示词分析和成本归因。

• Helicone for request visibility, caching, and spend tracking - note Helicone has moved into maintenance mode following its aqcquisition by Mintlify, so check whether it still fits before building using this tool.Helicone：用于请求可见性、缓存和支出跟踪——注意，在被 Mintlify 收购后，Helicone 已进入维护模式，因此在使用此工具构建之前，请检查它是否仍然适用。

• OpenLIT for OpenTelemetry-native AI observability. The GitHub repo is located here.OpenLIT：用于 OpenTelemetry 原生的 AI 可观测性。GitHub 仓库位于此处。

• LiteLLM for proxy-based routing, provider abstraction, and budget controls. Docs are located here. The GitHub repo is located here.LiteLLM：用于基于代理的路由、提供商抽象和预算控制。文档位于此处。GitHub 仓库位于此处。

• OpenAI Cookbook for practical implementation examples. The GitHub repo is located here.OpenAI Cookbook：用于实际实现示例。GitHub 仓库位于此处。

• FinOps Foundation because AI economics are increasingly part of the broader FinOps conversation.FinOps Foundation：因为 AI 经济学正日益成为更广泛的 FinOps 对话的一部分。

Final Thought最后一点想法

AI does not need less experimentation, rather it needs fewer surprise invoices. The organizations that handle this well will not be the ones that panic when spend appears. They will be the ones who architect observability, attribution, and economic accountability into the solution from the beginning. AI 不需要减少实验，而是需要减少意外账单。能够妥善处理此问题的组织，不会是在支出出现时感到恐慌的那些，而是那些从一开始就将可观测性、归因和经济责任纳入解决方案架构的组织。

Because remember...your LLM may have a spending problem. But...more often than not...your architecture does!

Repo with runnable cost-capture code for all three providers, a shared pricing module, and a structured telemetry emitter is available at github.com/sbkuehn/llm-cost-telemetry. Pricing tables verified June 2026; always check the provider pricing pages before you bill anything to anyone.包含所有三个提供商的可运行成本捕获代码、共享定价模块和结构化遥测发射器的代码库可在 github.com/sbkuehn/llm-cost-telemetry 获取。定价表核实于 2026 年 6 月；在向任何人收费之前，请务必查看提供商的定价页面。