OpenRouter makes it easy to access models from OpenAI, Anthropic, Google, Meta, and many other providers through a single API.

That convenience creates a new cost management problem: once a meaningful amount of production traffic is flowing through OpenRouter, how do you figure out what is actually responsible for the spend?

Knowing that you spent $20,000 on Claude or $8,000 on Gemini only gets you so far. Most teams eventually want to answer questions like:

• How much does each customer cost us in AI inference?
• Which product or feature generates the most OpenRouter spend?
• How expensive is a single agent invocation?
• Which agents are driving our costs?
• How much are production workloads costing relative to development?
• Are we using expensive models for tasks that could run on cheaper ones?

Fortunately, OpenRouter provides several tools that make more granular cost allocation possible. This blog post is meant to be an overview of these concepts to help teams manage the associated costs.

Tag OpenRouter requests with trace

The best method for allocating OpenRouter costs is to use trace. If you’re familiar with cost allocation tags on providers like AWS or Datadog, trace is the equivalent tool for OpenRouter. OpenRouter's trace field is essentially an object for arbitrary key-value pairs to identify or allocate various invocation requests.

An example is below:

{
  "model": "anthropic/claude-sonnet-4",
  "messages": [
    {
      "role": "user",
      "content": "Summarize this document..."
    }
  ],
  "trace": {
    "customer_id": "customer_123",
    "agent": "research_agent",
    "feature": "document_summary",
    "environment": "production",
    "invocation_id": "run_456"
  }
}

The important point here is: If your application already knows a cost allocation dimension, explicitly record it rather than trying to infer it later. Your application probably knows which customer made the request. It knows which agent is running. It knows whether a request came from production or development.

That information can be much harder to infer after the fact. To properly allocate traces, you’ll want to identify where in your application calls to OpenRouter are being made, then inject the trace properties accordingly.

What should you put in trace?

The exact dimensions depend on your application, but some useful examples include:

customer_id
organization_id
product
feature
agent
environment
invocation_id
workflow

For a multi-tenant SaaS application, customer_id may be the most important dimension to be able to see what impact each of your customers is having on your infrastructure costs.

Allocate costs by invocation, not just individual model requests

AI applications increasingly make multiple model calls to accomplish one unit of work.

Imagine a research agent that receives one request from a user but makes four OpenRouter requests before returning its final answer. An example is below, where a single invocation request is making calls out to multiple models in parallel, each with their own token-specific pricing.

Research Agent Invocation #8729

Claude Sonnet             $0.041
Gemini Flash              $0.008
Claude Sonnet             $0.057
GPT                       $0.032
                         -------
Total invocation cost     $0.138

Looking at each model request individually tells you something about infrastructure consumption. But $0.138 per research job is often the more useful business metric.

This distinction becomes increasingly important with agents, where one user action can trigger dozens—or eventually hundreds—of model and tool calls.

One way to handle this is to give every agent run or workflow an invocation_id and attach it to every OpenRouter request generated during that invocation.

{
  "trace": {
    "customer_id": "customer_123",
    "agent": "research_agent",
    "invocation_id": "inv_8729"
  }
}

You can then aggregate the cost of all requests sharing that invocation ID.

Use session_id to group related OpenRouter requests

OpenRouter also supports a top-level session_id for grouping related requests.

{
  "model": "anthropic/claude-sonnet-4",
  "session_id": "agent-run-8729",
  "messages": [...]
}

OpenRouter currently supports session IDs of up to 256 characters. It also uses session_id for sticky routing, allowing related requests to stay on the same provider when possible, which can improve prompt-cache utilization.

That means you shouldn't necessarily treat session_id as a generic tagging field. It has routing semantics in addition to observability semantics.

A good general rule is:

Use session_id for a real conversation or agent session. Use trace for arbitrary cost-allocation dimensions.

Get the actual cost of each request

Metadata only gives you one side of the equation. You also need the cost associated with the request.

OpenRouter can return token and cost information directly in the response by including:

{
  "usage": {
    "include": true
  }
}

The resulting usage object can contain fields including prompt tokens, completion tokens, reasoning tokens, cached tokens, and the actual request cost.

For example:

{
  "usage": {
    "prompt_tokens": 194,
    "completion_tokens": 2000,
    "total_tokens": 2194,
    "cost": 0.2
  }
}

You can now combine the two sides:

Cost                   $0.20
Customer               Acme Corp
Agent                  Support Agent
Feature                Ticket Analysis
Environment            Production
Invocation             inv_8729

At scale, this becomes the foundation for much richer AI cost analysis.

What if you don't know how to categorize a request?

Explicit metadata works extremely well for dimensions known by the application.

But not every useful dimension is known ahead of time.

Consider questions like:

• Was this request coding, research, or summarization?
• Was the task simple or complex?
• Which business department does this usage belong to?
• Is an expensive frontier model being used for work that a cheaper model could handle?

This is the problem OpenRouter's new Classifiers feature is designed to address.

Using OpenRouter Classifiers for inferred cost allocation

OpenRouter introduced Classifiers in beta in July 2026.

Classifiers allow you to create a taxonomy and have another model automatically categorize OpenRouter generations after they occur. OpenRouter currently supports taxonomies with up to eight dimensions, a configurable classification model, and a sampling rate. Classification happens asynchronously, so it doesn't add latency to the original inference request. However, classification consumes tokens and therefore adds to your overall spend.

For example, you could define:

Task Type
├── Coding
├── Research
├── Summarization
├── Customer Support
└── Data Analysis

Complexity
├── Simple
├── Moderate
└── Complex

A request could then automatically receive classifications such as:

task_type = coding
complexity = complex

OpenRouter also provides preset Classifier templates for dimensions including department, task type, engineering work, agent complexity, audience, and potentially capitalizable software expense.

This creates another useful layer of cost attribution.

From AI cost allocation to AI unit economics

The end goal of cost allocation isn't tagging for the sake of tagging. It's connecting infrastructure consumption to the economics of the application.

Once OpenRouter costs can be attributed to customers, agents, features, and invocations, you can start answering much more important questions.

For example:

Acme Corp

Monthly revenue                   $10,000

AI inference costs
  Research Agent                     $410
  Support Agent                      $205
  Document Processing                $110
                                    -----
Total AI cost                        $725

AI gross margin                     92.8%

Or, at the product level:

Research Agent

Invocations                         84,210
Total AI cost                      $12,430
Cost / invocation                    $0.15

Cost by task
  Research                          $7,100
  Summarization                     $3,400
  Data extraction                   $1,930

You could go one step further and look for optimization opportunities:

Frontier model spend                $8,200

Classified task complexity
  Complex                           $5,900
  Moderate                          $1,500
  Simple                              $800

That last $800 is particularly interesting. Why are simple requests reaching an expensive frontier model at all?

AI cost allocation is becoming more granular

Traditional cloud cost allocation usually follows infrastructure boundaries:

Account → Service → Resource → Tag

AI applications introduce an entirely new set of economic boundaries:

Organization
  → Product
    → Customer
      → Agent
        → Invocation
          → Task
            → Model
              → Provider

The further AI applications move toward agents and autonomous workflows, the less useful raw token consumption becomes on its own.

A company ultimately doesn't care that it consumed 10 billion tokens.

It cares that its Research Agent costs $0.14 per invocation, Customer A has an 82% gross margin, or a particular feature is spending $50,000 per month without generating corresponding revenue.

OpenRouter's trace metadata, sessions, usage reporting, and Classifiers provide useful building blocks for answering those questions.

The next step is connecting that infrastructure data with the rest of the company's cloud costs and business metrics.

Vantage can help

Vantage helps companies understand and allocate their infrastructure spend across cloud and AI providers. By combining provider costs with application-level dimensions such as customers, products, and business metrics, teams can move from simply monitoring AI spend toward understanding the unit economics of their AI applications.

Vantage now has a native integration with OpenRouter and will automatically import your OpenRouter costs and expose the various trace labels as cost allocation tags for easier, out-of-the-box reporting. To get started, log in to your Vantage account and head to the integrations page to get OpenRouter connected.