Add routes

A route is the workload a developer says a call belongs to, independent of which function made it. It controls the initial grouping for cost, monitoring, alerts, and opportunity analysis. If a route uses different models, Metergraph can analyze those model-specific groups as separate workloads. This is the highest-value follow-up pass after instrumenting a repository.

Paste the block for your language into a coding agent, from inside the repository.

Tip

Routes are a judgement call about your product, not a mechanical transform. The prompt asks the agent to group by what the user is getting rather than by which module the code lives in, and to report anything it deliberately left unrouted. Read that list: it is usually where the disagreements are.

Python

This Python repository already uses the Metergraph SDK. Add route names.

A route is the workload a developer says a call belongs to, independent of
which function made it: "ticket-classifier", "invoice-summary", "search-rerank".
It controls the initial grouping for cost, monitoring, alerts and opportunity
analysis. If a route uses different models, Metergraph can analyse those
model-specific groups as separate workloads.

    with metergraph.route("ticket-classifier"):
        client.chat.completions.create(...)

Read the code and group calls by what the user is getting, not by which
module they live in. Two functions serving the same surface share one
route. One function serving two surfaces needs two.

Use lowercase, hyphenated, stable names. Do not invent a route per
function. Do not put a version or a model name in a route name.

Where a workflow makes several model calls that belong together, wrap it
in metergraph.trace("name") as well, so they are grouped as one unit of
work.

Route, trace, function, session and tags are five different labels
answering five different questions. If you are unsure which one a piece
of information belongs on, read
https://www.metergraph.dev/docs/concepts/identity-model/
before choosing.

Change nothing else. Do not refactor, rename or reformat code you are
not routing, and do not add a dependency.

When done, list every route you introduced, which call sites it covers,
and any call you deliberately left unrouted with the reason.

TypeScript

This TypeScript repository already uses the Metergraph SDK. Add route
names.

A route is the workload a developer says a call belongs to, independent of
which function made it: "ticket-classifier", "invoice-summary", "search-rerank".
It controls the initial grouping for cost, monitoring, alerts and opportunity
analysis. If a route uses different models, Metergraph can analyse those
model-specific groups as separate workloads.

    mg.route("ticket-classifier", () => client.chat.completions.create(...))

Read the code and group calls by what the user is getting, not by which
module they live in. Two functions serving the same surface share one
route. One function serving two surfaces needs two.

Use lowercase, hyphenated, stable names. Do not invent a route per
function. Do not put a version or a model name in a route name.

Where a workflow makes several model calls that belong together, wrap it
in mg.trace("name", fn) as well, so they are grouped as one unit of work.

Note that route() and track() are different things and you need both:
track() names the function, route() names the workload.

Route, trace, function, session and tags are five different labels
answering five different questions. If you are unsure which one a piece
of information belongs on, read
https://www.metergraph.dev/docs/concepts/identity-model/
before choosing.

Change nothing else. Do not refactor, rename or reformat code you are
not routing, and do not add a dependency.

When done, list every route you introduced, which call sites it covers,
and any call you deliberately left unrouted with the reason.

What makes a good route name

The naming rules in the prompt exist because a route name is a join key across time. Renaming one splits its history in two.

• Lowercase and hyphenated, so it reads the same everywhere it appears.
• Named after the surface, not the implementation. invoice-summary survives a rewrite. summarize_v2_handler does not.
• No version and no model name. Swapping the model is the thing routes exist to measure, so a route named after a model cannot measure it.
• Stable. Prefer an imperfect name you keep to a perfect one you change.

Name a route walks through the same decision by hand, and Explore Metergraph shows where routes surface in the product.

Audit coverageOnce routes are in, find the calls that are still invisible.

Connect a coding agentGive a coding agent bounded access to one Metergraph workspace.