Skip to main content
OpenRouter is an AI model provider and gateway. Weave connects to OpenRouter in three separate ways:
  • Analytics connection (recommended): Weave syncs usage, tokens, and cost directly from OpenRouter’s Analytics API.
  • Direct capture: Weave stores sanitized OpenTelemetry exports from OpenRouter Broadcast.
  • Harness telemetry: a supported AI harness, such as Oh My Pi, reports its own OpenRouter usage.

​
Connect OpenRouter Analytics

You need an OpenRouter organization admin to create the key and a Weave admin to connect it.
  1. In OpenRouter → Settings → Management Keys, click Create New Key, name it (for example Weave Analytics), and set an expiration. OpenRouter shows the key once and cannot extend its expiration later.
  2. In Weave, open Data → OpenRouter and click Connect OpenRouter. Enter a connection name, paste the management key, and click Save.
  3. Weave validates that the key can read Analytics before encrypting and storing it. Management keys cannot make model requests; Weave uses the key only to read Analytics.
After connecting:
  • Weave syncs the last 14 days of usage on each scheduled sync, about every 3 hours. To import older history, ask Weave support for a backfill: OpenRouter provides per-request detail for the last 31 days and daily per-model totals before that.
  • Map OpenRouter identities to members on the same page; see Analytics identity mapping. Unmapped usage still counts toward organization totals.
  • If the key expires or is revoked, the connection shows Action required. Create a new management key and use Replace key.
  • Disconnecting erases the stored key in Weave. Revoke the key in OpenRouter separately.

​
Direct capture

Confirm with Weave support that your deployment includes the capture endpoint before enabling Broadcast. Capture on its own does not populate AI reports or reconcile billing. With an OpenRouter Analytics connection, Weave uses captured traces to fill in user identities that Analytics omits, and counts file-edit lines from coding-agent tool calls in captured generations toward AI code LOC and PR attribution when the generation maps to a member.
  1. In Weave, open Data → AI Gateway and click Create API key. This Weave key authenticates the receiver; it is not your OpenRouter inference or management key.
  2. In OpenRouter Observability settings, configure an OpenTelemetry Collector destination with:
    • Endpoint: https://app.workweave.ai/api/ingest/openrouter/v1/traces
    • Custom headers: {"X-Weave-Token":"YOUR_WEAVE_AI_GATEWAY_KEY"}
    • Privacy Mode: enabled
    • Sampling: 1.0 / 100%
    • Included API keys: explicitly select the OpenRouter keys whose usage you want to capture. An empty inclusion list can export all organization traffic.
  3. Run Test Connection, then save. Do not replace an existing destination if it serves another system.
  4. Have Weave support confirm that a real export was persisted. A successful response includes an X-Weave-Inbox-ID receipt header and is returned only after the database write commits.
For self-hosted Weave, replace https://app.workweave.ai with your instance’s externally reachable URL. The receiver accepts OTLP/HTTP JSON or protobuf, including gzip, with a 32 MiB decompressed request limit. It uses the header key’s organization; a resource-level weave.token, if present, must match that header. Invalid or revoked keys return 401, malformed exports return 400, oversized exports return 413, and storage failures return a retryable 503. The inbox preserves trace/span identifiers, timing, status codes, and allowlisted model/provider/user/session attributes. Usage fields use an exact-name allowlist, not a namespace wildcard:
  • gen_ai.usage.input_tokens, output_tokens, total_tokens, reasoning_tokens, cache_read.input_tokens, cache_creation.input_tokens, cache_write.input_tokens, and cost
  • gen_ai.cost.total, input, and output
  • openrouter.usage.input_tokens, output_tokens, total_tokens, and cost
  • openrouter.cost.total
Each abbreviated name above uses its bullet’s leading namespace. Unknown fields are discarded, including attributes whose names contain customer content. Numeric strings are preserved without repricing or rounding. It removes prompts, responses, arbitrary metadata, span names, events, links, and embedded credentials before storage. Missing user identity does not prevent capture. Repeated identical sanitized exports produce the same receipt within an organization. This is batch replay protection, not cross-source usage deduplication. Captures remain in the pending inbox without automatic expiry; organization deletion removes the inbox partition. There is no automatic projection into reports yet.

​
How harness reporting flows

The OpenRouter API key stays in the harness. Weave does not need that key and does not pull OpenRouter usage directly from the OpenRouter API for this flow. For Oh My Pi, the current path is:
See Oh My Pi setup for the complete configuration.

​
What Weave needs from a harness

A harness integration must provide the following information in its telemetry: A harness’s OPENROUTER_API_KEY or an openrouter/... model name by itself is not enough for Weave to identify or report usage. The harness must send telemetry through a supported Weave integration.

​
OpenRouter costs

When Oh My Pi routes a request through OpenRouter and receives OpenRouter’s reported request cost, Pi includes that value in its cumulative cost metric. Weave converts the repeated cumulative observations into positive cost deltas before adding them to aggregate Pi cost reporting. The normal cost path is:
The metric does not include gen_ai.conversation.id or gen_ai.response.id. Consequently, this path reports cost by person, model, provider, and time period; it does not assign metric-derived cost to individual requests or sessions. Provider-reported cost should still be reconciled against the organization’s OpenRouter usage records for billing-sensitive reporting. Credits, discounts, negotiated rates, taxes, and account-level adjustments may not be represented in an individual response cost.

​
Visibility in Weave

Usage that a harness reports appears under the AI harness source. Usage synced through the Analytics connection appears under the separate OpenRouter source. For requests sent by Oh My Pi:
  • Data → Pi — create and manage the Weave telemetry key and generate setup instructions
  • AI reports — view activity by person, team, date range, model, and AI tool
  • AI tool costs — view aggregate Pi costs and cost fidelity
  • Token usage — view input, output, and cache-token totals from Pi traces
  • Session views — view conversation activity from Pi traces when the harness supplies a session ID; metric-derived cost is not assigned to sessions
Use the model and source dimensions together when you need to identify OpenRouter usage. A model identifier may preserve a provider/model prefix, but the stable Weave source is the harness—in this case, Pi. Weave does not currently provide a standalone OpenRouter dashboard or direct OpenRouter invoice reconciliation in this integration.

​
Analytics identity mapping

When an OpenRouter Analytics connection is configured under Data → OpenRouter, Weave records the identities that OpenRouter reports on each generation: the OpenRouter user email, the external_user value the caller sent, and the API key. Admins map those identities to Weave members on the same page. Weave maps some identities automatically during each sync. When a request’s external_user (the user field your tools send to OpenRouter) is exactly a member’s email, Weave maps it to that member. When your organization’s requests come from two or more OpenRouter accounts, each account email that exactly matches a member’s email is mapped to that member too. A single OpenRouter account shared by the whole team is never auto-mapped, and neither is an API key, because either can carry everyone’s traffic. Weave never changes an identity an admin has already mapped or unmapped. What mapping does:
  • Attributes OpenRouter usage, tokens, and cost to a Weave member for reporting.
  • Accepts several identities per member (an email, an external user ID, and one or more API keys).
  • Records an effective window per mapping. Rotate a key by ending the old key’s mapping and mapping the new key; usage before the cutoff keeps the old attribution and usage after it follows the new mapping.
  • Lets you mark an API key as shared or as a service account with a label so its usage is reported as unattributed or as that service rather than as a person.
What mapping does not do:
  • It never assigns shared-key traffic to the administrator who connected OpenRouter or created the mapping. Unmapped and shared identities stay unattributed.
  • It does not convert OpenRouter token counts into lines of code. The only OpenRouter lines of code come from file-edit tool calls captured through direct capture, which Weave credits in AI code LOC and PR attribution to the member that the generation’s identity maps to.
  • It does not infer identity from the connection creator, display names, or model names. Only the stable user_email, external_user, and api_key values are mapping keys.
If two mappings for one identity overlap in time, Weave treats that identity as ambiguous and leaves it unattributed until an admin ends one of them.

​
Setup responsibilities

​
Weave administrator

  1. Open Data → Pi.
  2. Create one organization-wide Pi telemetry key.
  3. Give the key to the team through your normal secret-management process.
  4. Do not give the team a Weave OpenRouter key—there is no such key.

​
Each harness user

Each user must configure their own identity. For Oh My Pi:
The telemetry key can be shared, but the email cannot. If users share one email, their usage is attributed to that one Weave account. If they omit identity, Weave accepts the telemetry but cannot attribute the requests and drops them before reporting.

​
Each harness owner

Configure OpenRouter authentication in the harness itself, then configure the harness’s supported Weave telemetry integration. For Oh My Pi, use the Oh My Pi setup instructions. For a different AI harness, confirm with Weave support whether it has a supported integration before deploying it across the organization. Sending arbitrary OTLP data to the endpoint does not automatically make a new harness reportable.

​
Validation checklist

Before a broad rollout, validate one request in both systems:
  • The harness request reaches OpenRouter successfully.
  • The harness sends OTLP traces and metrics to Weave and receives successful ingest responses.
  • The telemetry includes the user’s own Weave email.
  • The requested and served model values are present in the traces.
  • Input, output, and cache-token counts match the trace data.
  • A populated pi.omp.agent.chat.cost.estimated_usd metric is present when the request has cost.
  • Repeated cumulative metric exports do not double-count cost.
  • The aggregate OpenRouter-reported cost matches the Pi metric and Weave cost report.
  • The request appears under the Pi source in Weave after asynchronous processing and the next reporting refresh.
  • Metric-derived cost is not presented as an exact session or request cost.
Last modified on October 17, 2026