Giant Context builds and hosts websites, and an AI does much of the building. My cost of goods is tokens. Not servers, not seats, not bandwidth in any way that matters. Tokens, bought by the million, spent a few thousand at a time on every page a customer generates.

Last week the platform got its observability layer, and it landed as one thing, not two. Every tracked event now carries a trace ID that follows a request across every service it touches, and a token count that says what the event cost. Same event, same pipeline, same store.

Two questions eventually come up about every request. Why was it slow, and what did it cost. The industry default is to answer them with two products (an APM tool for the first, a billing pipeline for the second), which means the answers live in different systems, keyed by different IDs, reconciled by hand when someone finally asks the question that matters. Which of the slow ones was also the expensive one?

Here both answers ride the same event:

The event categories were rebuilt so that the way events are classified is the way costs are attributed. Observability and accounting stopped being two views of the system. They became one record.

The event contract itself is short enough to read. Its core fields:

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.

The deeper reason to put cost on every event is that tokens are the only honest unit I have.

An AI-core product has a tangible unit cost and an intangible product cost. I know exactly what a token costs me. I cannot tell you in any natural unit what "a website" costs me, because a website is some generations, some embeddings, some file processing, some hosting, some uptime. So the accounting works backwards from the intangible. Anchor everything against the unit you actually buy. A token costs us this much. How many tokens does hosting cost us? How many tokens is analytics? Uptime? Every tangible cost in the business gets expressed against the one unit that already flows through every event.

There is also a bet in this about where software pricing is going. The seat-and-subscription model looks, from here, like it is dying. Buyers with AI in their stack have started budgeting in tokens, because everything in their stack has a token cost now. And a company slated to be AI-only has exactly one hard cost, cycles, whether those cycles are a Node server handling a request or a Gemini call composing a page. Align what you charge to cycles and prompts and two things happen. Your pricing sits as close to your infrastructure cost as pricing can sit. And you speak the unit the next generation of clients already budgets in, instead of renting them seats in a model they may be trying to leave.

That gives the whole operation a single currency. Internally it makes cost prediction possible for a one-person company, because every domain's spend reads in the same unit from the same table. And on the customer's side it means billing can eventually speak one unit too, instead of handing people a menu of different meters, so much per seat, per gigabyte, per build minute, per API call. One currency, predictable in both directions.

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.