Skip to content

What Metergraph is

Metergraph is two things: a capture SDK for Python and TypeScript, and a server that prices what the SDK captures. You wrap the provider client you already built, and every model call lands as a row carrying the function that made it, the route it belongs to, its token counts, its latency, its status, and its cost in dollars.

It is not a proxy and not a gateway. Nothing is rerouted, no key of yours is held, and the provider’s response and exceptions reach your code exactly as they did before. Capture runs on a background queue, so a slow or unreachable Metergraph never becomes a slow or failing model call.

There are two destinations, and they differ in what they can see and what they can do for you.

The open-source server is Apache-2.0, runs on one docker compose up, and gives you the spend dashboard. It is content-blind by construction: it projects every incoming row through a strict column allowlist, so prompts and completions are discarded at ingest even when the SDK is configured to send them. There is no column for them to land in.

The hosted cloud stores the scrubbed request and response, which is what makes analysis possible. Because it can replay your recorded traffic, it can test candidate models against your real workloads and tell you which ones hold quality for less. It also runs the alert detectors and, if you install MetergraphBot, can prepare a pull request for a change you have approved.

Moving between them is one environment variable, METERGRAPH_INGEST_URL, in either direction. See choosing a deployment for the full comparison, including running the commercial build inside your own AWS account.

Metergraph does not discover your LLM calls. It sees exactly the seams you give it, and nothing else.

  • Wrap every client. An unwrapped client, a raw HTTP request, or a second client constructed in a background worker produces no row at all. It does not error. It is simply invisible.
  • Set the token in the process that makes the calls. With METERGRAPH_APP_TOKEN unset, the SDK initializes, logs one warning, and does nothing else forever after. That is deliberate, so the same code is safe to ship to an environment you have not configured yet. It is also the most common reason people see no data.
  • Name your routes. Capture works without them, but a route is the unit the analysis engine evaluates, and an unnamed one shows up in the dashboard as a template fingerprint rather than a name you recognize.
  • Flush before a short-lived process exits. Batches leave on a timer, and a process that exits first takes its queue with it.