One agent run can become several billable traces when context is missing

Comparing AI gateway trace vs request pricing starts with a count, and the count depends less on your workload than on where your instrumentation draws its boundaries. The same agent run can be one trace or six on a per-trace meter, three gateway requests or four provider attempts depending on the export. The agent does not change between these counts. Where the meter draws its boundary does.

So the order matters. Before you put two plans side by side, decide what one logical run produces on each meter, under your own instrumentation. A price per trace multiplied by the wrong trace count is a confident wrong forecast.

This article runs one synthetic agent run through two instrumentation setups and writes down every counter. Then it gives you a worksheet to do the same with your own exports.

The synthetic run#

Everything below is invented to make the meters visible. Real instrumentation and real retry behavior vary, and you should replace every number with one from your own logs.

One logical run of a support agent:

1. Model request 1: the agent plans.
2. Tool step 1: it looks up an order.
3. Model request 2: it reads the result. The gateway's first upstream attempt fails, and the gateway retries once inside the same request. The second attempt succeeds.
4. Tool step 2: it checks a refund policy.
5. Model request 3: it drafts the reply.
6. Tool step 3: it writes a ticket note.

Assumptions for every case below:

• The application sends three requests to the gateway. The retry happens inside the gateway, so the application sends no fourth request.
• The gateway makes four upstream provider attempts in total: one each for requests 1 and 3, two for request 2.
• The application calls the three tools directly, so in this run the tool calls do not pass through the gateway.
• No scores or evaluations are attached.
• The gateway accepts all three requests.
• Nothing here says whether your provider charged for the failed attempt. That is between your provider's usage data and its invoice.

How many steps become recorded observations differs per case, and each case states it.

Six meters, not one#

• Logical run: what your product thinks happened. One customer question, one agent run.
• Trace ID: what the tracing system groups together. One run can carry one ID, several, or none.
• Gateway request: an HTTP request from your application to the gateway.
• Upstream attempt: a request from the gateway to the provider. A gateway-internal retry adds an attempt, not a gateway request.
• Span or observation: a recorded unit of work inside a trace.
• Billable unit: whatever the vendor's plan counts: traces, records, requests or a sum of several.

One gateway publishes this split in its own usage data. ngrok's AI Gateway documentation says its usage events list one record per upstream attempt, attempts of the same client request share a requestId, and the list returns only each request's terminal attempt unless you pass includeRetries=true. Exported with defaults, our synthetic run would show three events there; with retries included, four. That page describes ngrok's observability view, not its billing, but it shows why "how many requests" has two honest answers depending on the export flag.

Case A: one trace context on every request#

In the first setup, the application starts a trace when the run begins and passes that context on all three gateway requests. The tool steps are recorded by the application's own instrumentation as spans of the same trace. In this case all six steps become distinct recorded spans. Whether the failed upstream attempt adds a seventh record is a vendor question, so the ledger does not assume it.

Worksi's plan page documents these rules, so it serves as the worked example. A Worksi AI trace is everything with the same trace id, however many model calls, tool calls and steps it has, and the gateway reads that id from X-AIW-Trace-Id or a W3C traceparent header. It counts once, in the month it is first received, while it stays active.

The context has to be passed. The gateway cannot attach a request to a trace it was never told about. If your async workers drop context between steps, the missing spans guide covers where it usually breaks.

Case B: no trace header, same workflow#

In the second setup, nothing changes in the agent. The application sends the three model requests without a trace header. The documented behavior: a gateway request without a trace header starts its own trace. So each model request becomes its own gateway-started trace, with one model-call span each.

The tool steps are the harder part. In this run the application calls them directly, so they do not reach the gateway. Without a shared trace ID, nothing connects them to the three gateway traces, and you cannot assign them there by inference. Two separate things now decide the count: the missing propagation, which splits the model calls, and the tool instrumentation, a choice the application makes on its own. Case B therefore has three branches:

Read these against Case A. Gateway requests and upstream attempts did not move in any branch. The trace count rose from one to between three and six. The span count fell to three only in B1, and that drop comes from the tool steps not being recorded, not from the missing header itself. In B2 and B3 the same six spans exist, spread over more traces.

The same run on a per-record meter#

For contrast, take a separate, hypothetical Langfuse ledger. Langfuse documents its billing as ingested units, where units equal the count of traces plus observations plus scores.

This ledger does not assume that Langfuse represents trace propagation or the gateway retry the way the gateway example above does. It only applies the published formula to what each case is assumed to ingest, with no scores:

So a record-based count can go up, down or stay close to flat when context is missing. It rises when the same records land under more roots, because roots are billed too. It falls only when records stop being ingested. A per-trace meter rises in every branch; a per-record meter moves with what you actually ingest.

The same Langfuse page says records created by its own features, such as LLM-as-a-Judge, annotation queues or experiments, count as billable units too. Attach one evaluator score per run in Case A and the run is eight units. None of these counts says which plan costs less until each is multiplied by that vendor's own rates and allowances.

What the count does at a quota#

The fragmentation in Case B is not only a forecasting error. Under Worksi's documented rules it changes what happens when the monthly allowance runs out.

At the limit, the gateway answers new traces with 429 plan_quota_exceeded, while calls and spans of traces already started keep going, until the next calendar month in UTC or a larger plan.

In Case A, a run that has started keeps its trace. Its second and third model calls belong to a trace that already exists, so they continue. In Case B, every model call starts a new trace. Once the allowance is used, the second call of a run already in progress is a new trace and is refused. The run can stop mid-workflow unless the application handles that refusal, for example by deferring the work.

An illustrative month, with all of these assumptions stated:

• 10,000 runs, all within one UTC calendar month, executed one after another.
• No other traffic in the organization, and no upgrade during the month.
• No pause long enough to re-count a trace.
• The organization's owner has verified their email.
• The free Developer plan, 25,000 AI traces a month, from the pricing page.
• Case B as branch B1, three traces per run.
• The synthetic application aborts a run when it receives the quota error.

Case A uses 10,000 AI traces, 30,000 gateway requests and, on its six-span assumption, 60,000 spans. Case B would require 30,000 AI traces to complete all 10,000 runs. It cannot get them: 8,333 runs consume 24,999 traces, the first model request of run 8,334 takes the last available trace, and its second request is refused. Under the abort assumption, run 8,334 stops halfway, and every later run is refused at its first request.

Boundaries that change the count#

Pauses. A trace that resumes after a pause counts again: after 6 hours without activity for a trace your application or the SDK started, and after 10 minutes for a trace the gateway started. An agent that waits overnight for a human approval inside one application trace counts as two AI traces for that run, while it keeps one trace ID. List every step that can idle, and how long.

Month boundaries. A trace counts in the month it is first received. A run that starts on 31 January and resumes after a long pause on 1 February counts once in each month. If you forecast across a month, say which month each run lands in.

Backstops, not cutoffs. Worksi's fair use says each AI trace may average up to 100 spans and 100 gateway requests, and the plan page says these are enforced only as monthly backstops of 100 times the plan's monthly AI traces. On Developer that is 2.5M spans and 2.5M gateway requests a month. A single trace with 300 spans is not refused for that reason. The documentation does not say whether gateway-internal retry attempts count toward the gateway-request backstop, so put that in the confirmation column.

Before email verification. Until an owner verifies their email, an organization on the trial or the free plan is limited to 1,000 AI traces, 1,000 gateway requests and 10,000 traced spans a month. Here the binding counter changes. In Case A the gateway-request cap binds first, at about 333 runs, three requests each, while the trace cap alone would allow 1,000 runs. In Case B1 traces and requests both bind at about 333 runs. A forecast built on traces alone would be wrong by a factor of three for Case A in this state.

The worksheet#

Fill this in per workflow before comparing plans. Leave a cell empty, and move the question to the last column, rather than guess.

Then check the forecast against reality. Run a few hundred real runs, export distinct trace IDs, spans, gateway requests and attempts, and divide each by the number of logical runs from your own product events. If distinct trace IDs per run exceed your forecast, investigate context propagation, deliberately created roots and linked traces. Compare the carrier, the extracted context, the selected parent and any links before diagnosing a break. Keep inactivity re-counts separate: they can raise metered AI traces without adding a distinct trace ID. If two vendors' exports disagree, check first whether they count the same thing: terminal attempts against all attempts, gateway-started traces against application traces, observations with or without scores.

Where this leaves a plan comparison#

Count with your own exports before you multiply by any price. On per-trace plans, context propagation decides the trace count; on per-record plans, what you ingest decides the record count.

Provider tokens stay outside all of this. On Worksi you bring your own key and your provider bills you directly, with no mark-up; plans cover the control plane only. The trial gives 3 days of Scale features with no card, then the organization stays on the free Developer plan. Read Worksi's plans and limits for the exact trace rules used in this article.