Giant Context builds and hosts websites, and an AI does much of the building. Tokens are the cost that moves with the product. Bought by the million, spent a few thousand at a time on every page a customer generates, and rising with use in a way a server bill does not.

Last week every tracked event gained two fields, a trace id and a token count, which is a small change with a larger consequence. Once every event carries what it cost, tokens can become the unit the rest of the business is measured in, including the parts that are billed in gigabytes and instance hours.

Two questions come up about every request eventually. Why was it slow, and what did it cost. The usual answer is two products, an APM tool for the first and a metering pipeline for the second, which puts the answers in different systems under different identifiers. Reconciling them is a project someone takes on the first time anybody asks which of the slow requests were also the expensive ones.

The event pipeline already existed, so answering both meant adding two fields rather than adding a system. A trace id that follows a request across every service it touches, and a token count that says what the event cost.

The commit that did it also rebuilt the event categories so that the way an event is classified is the way its cost is attributed. Observability and accounting stopped being two readings of the system and became one record.

The contract is short enough to read in one screen, and the two new fields sit next to the ones that were already there. Classification, cost, trace, tenant, and the resource the request touched, on one type that every service emits.

Cost tracking and distributed tracing are adjacent fields on one type. An event carries what happened, what it cost in tokens, which request journey it belongs to, which customer's organization it happened inside, and how long it took. "Which trace was expensive" is not a reconciliation project. It is a WHERE clause. So is "which organization's usage spiked," and "what does a page generation actually cost end to end."

The categories carry the cost-center alignment. The type's own comment on the ai category reads "AI operations (chat, generation, embeddings - high cost)". The schema shows which domain burns the money, and every service's events sort into a domain. When I want to know what the AI layer cost this week versus the file layer, the question is already answered by classification that happens at the moment of tracking, not by a spreadsheet built after the fact.

The platform is TypeScript on one side and Python on the other, and a trace is only a trace if it survives the boundary. It crosses as plain HTTP headers:

The Python services receive the same context the TypeScript middleware assigned, attach it to their own events, and the journey stays whole. One contract, two languages, no translation layer with opinions of its own. This is the hub doctrine paying out again. The platform was built as an API-first hub with satellites working from one description, and an event contract is just one more description every service works from.

Tokens are not the only thing this platform pays for. There are servers, storage, egress, database hours, the same bills anyone running infrastructure has. What is different is that tokens are the cost that moves with what the product actually does, and every other cost can be expressed against them.

So instead of metering each resource separately and handing a customer the sum, each fixed cost gets valued in tokens. A gigabyte of storage for a month is worth some number of tokens. A hosted page serving a thousand visitors is worth some number of tokens. The dollar figures already exist on the invoices, so the conversion is arithmetic, done once, and after it every cost in the business reads in one unit.

Internally that makes cost prediction possible for one person. Every domain's spend reads in the same unit from the same table, so I can compare what the AI layer cost this week against what the file layer cost without opening a second bill or converting anything.

The reason to carry it through to pricing is a bet about where software value is going. If building software keeps getting easier, then software on its own stops being much of a moat, and the durable position is the one closest to the infrastructure, because the infrastructure is the part nobody can route around. Compute has to be bought. Storage has to be bought. Models have to be paid for by the token.

A single currency is what that alignment looks like on an invoice. Price in a unit pegged to infrastructure cost and the margin sits in a known relationship to the thing that actually costs money, rather than floating on a seat count that has nothing to do with what a customer consumes. The customer sees one meter instead of a menu of them, and the unit is the one their own budget is increasingly denominated in.

The weak point is the customer half. Pegging my own accounting to infrastructure is a fact about my costs. Expecting buyers to want to think in tokens is an assumption about other people, and it is the part of this I am least sure of.

There was no incident behind building it this way. The reasoning is operational, and it is the reasoning of a company with one operator. Two observability systems is two systems to run, two schemas to migrate, two bills to pay, and two places a question can die. One event contract is no additional infrastructure at all. The events flow into the analytics pipeline that already existed, and the store they land in is large, immutable, and append-only. That store is becoming the platform's memory. It informs billing today. It will inform the AI itself before long, because an immutable record of everything the system did and what it cost is exactly the data an autonomous platform needs to reason about its own behavior.

If your COGS is tokens, or compute of any kind, the same shape applies. I did not buy an APM product and a metering product and a pipeline to reconcile them. I put two fields on one event, the trace that answers why it was slow and the tokens that answer what it cost, and pointed every service at the same contract. Two questions, one query. That is the entire system, and one person can run it.