I Built the First Version of an AI Impact Receipt

我构建了首个 AI 影响回执（Impact Receipt）版本

An AI API usually gives you an answer. I wanted to explore what it would look like if it also returned a record of the request’s environmental impact—and how those figures were produced. That’s the idea behind the Impact Receipt: impact information should travel with the AI request, not live in a separate dashboard with no link to the work that generated it. In Part 1, I argued that carbon should travel with every AI request. Here’s what I’ve built so far—and what this first version does not do.

AI API 通常只会给你一个答案。我想探索一下，如果它同时返回该请求的环境影响记录，以及这些数据是如何产生的，会是什么样子。这就是“影响回执”（Impact Receipt）背后的理念：影响信息应该随 AI 请求一同传输，而不是存放在一个与生成该工作的任务毫无关联的独立仪表盘中。在第一部分中，我主张碳排放数据应随每个 AI 请求一同传输。以下是我目前构建的内容，以及这个初版尚未实现的功能。

The prototype flow

原型流程

A caller supplies a model or routing identifier, a prompt, a token budget, and a latency preference. The prototype returns dispatch information alongside environmental estimates. There’s an important boundary: it does not call Claude or another language-model provider. The model identifier is simulated, and the response echoes the supplied prompt. This prototype tests the shape of the dispatch and receipt—not a real model call, provider-reported usage, or physical measurement.

调用者提供模型或路由标识符、提示词（prompt）、Token 预算以及延迟偏好。该原型会返回调度信息以及环境估算数据。这里有一个重要的界限：它不会调用 Claude 或其他语言模型提供商。模型标识符是模拟的，响应内容会回显所提供的提示词。此原型旨在测试调度和回执的格式，而非真实的模型调用、提供商报告的使用量或物理测量值。

Here’s a shortened example of the response shape: 以下是响应格式的简化示例：

{
  "id": "",
  "model": "claude-sonnet",
  "tokens": 800,
  "device": {
    "region": "eu-north-1",
    "country": "Norway",
    "carbonIntensity": 68,
    "renewableMix": 0.97,
    "waterIntensity": 0.32,
    "carbonIntensitySource": "modeled",
    "waterIntensitySource": "modeled"
  },
  "energyKwh": 0.216045,
  "carbonGrams": 14.691,
  "waterMl": 69.134,
  "carbonSource": "modeled",
  "energySource": "modeled",
  "waterSource": "modeled",
  "source": "synthetic"
}

These are example prototype values—not meter readings for an individual inference. 这些是原型示例值，而非单次推理的实际计量读数。

The label matters as much as the number

标签与数值同样重要

A field like “carbonGrams”: 14.691 looks precise. Without context, a developer could read it as a physical measurement of what that request emitted. It isn’t. In this prototype, the energy, carbon, and water figures are modeled allocations based on modeled or seeded infrastructure data. They are not measured at the level of an individual request. The tokens field is dispatch data, not provider-reported usage, because no model provider is executing the request. That’s why the response labels the metrics as “modeled”. The root-level “source”: “synthetic” describes the data path; it does not turn the estimates into measurements. A number needs provenance before someone can decide how much to trust it.

像 "carbonGrams": 14.691 这样的字段看起来很精确。如果没有上下文，开发者可能会将其解读为该请求排放量的物理测量值。但事实并非如此。在这个原型中，能源、碳和水的数值是基于建模或预设的基础设施数据进行的模型分配。它们并非在单个请求层面进行测量。tokens 字段是调度数据，而非提供商报告的使用量，因为没有任何模型提供商在执行该请求。这就是为什么响应将这些指标标记为“建模”（modeled）。根级别的 "source": "synthetic" 描述了数据路径；它并不能将估算值转化为测量值。在决定信任一个数字之前，必须先了解其来源（provenance）。

What the fields are for

字段的用途

The dispatch ID gives the record an identifier. The model field records the routing label used by the prototype; it does not prove which provider ran the request. The device and region fields add location context, which matters because energy, carbon intensity, water, and latency can vary by location. Energy, carbon, and water are separate metrics, each with its own source label. A modeled estimate can still be useful—but only if it’s clear that it’s modeled, and clear about the assumptions behind it. The ID is an identifier in this response. I’m not claiming that the prototype already provides a way to retrieve a saved receipt later.

调度 ID 为记录提供了一个标识符。model 字段记录了原型使用的路由标签；它不能证明是哪个提供商运行了该请求。device 和 region 字段增加了位置上下文，这一点很重要，因为能源、碳强度、水资源和延迟会因地理位置而异。能源、碳和水是独立的指标，每个指标都有自己的来源标签。建模估算仍然是有用的，但前提是必须明确它是建模得出的，并且清楚其背后的假设。ID 在此响应中仅作为一个标识符。我并不是说该原型已经提供了后续检索已保存回执的方法。

What this first version proves—and what it doesn’t

这个初版证明了什么——以及它没能证明什么

This is an early prototype of the receipt contract, not a complete production feature. It shows one way a dispatch response can carry environmental estimates and provenance together. It does not yet demonstrate a real provider call, per-inference physical metering, or a verified record of what a live model processed. It also doesn’t include a cost figure, confidence labels, or a methodology version. Those omissions matter. A fuller receipt will need to say not only what the figures are, but also what boundaries and data sources produced them, how fresh the inputs are, and where uncertainty remains.

这是回执契约的一个早期原型，而非完整的生产功能。它展示了一种调度响应可以同时携带环境估算数据和来源信息的方式。它尚未演示真实的提供商调用、单次推理的物理计量，或已处理内容的验证记录。它也不包含成本数字、置信度标签或方法论版本。这些缺失至关重要。一份更完整的回执不仅需要说明数值是多少，还需要说明产生这些数值的边界和数据源、输入数据的时效性，以及不确定性存在于何处。

The first lesson from building this prototype is simple: an Impact Receipt isn’t just a set of numbers. It’s numbers plus context and provenance. Without those, precision can look like certainty. With them, even a modeled estimate can be interpreted honestly.

构建此原型的第一条经验很简单：影响回执不仅仅是一组数字。它是数字加上上下文和来源。没有这些，精确度可能会被误认为是确定性。有了这些，即使是建模估算也能被诚实地解读。

Next: what should a complete Impact Receipt contain? 下一步：一份完整的影响回执应该包含什么？