Meter

Meter is the record of every request that goes through the gateway: what was called, which model answered, how many tokens the provider reported, and what that costs at a published price. It is on for every plan and needs nothing from your code beyond the base URL change in the quickstart.

What the request carries

Nothing extra. A request metered by the gateway is the request your SDK already sends, with your Recovea key and the Recovea base URL.

Two optional headers label a request for your own reporting:

The values are opaque: the gateway stores them as you sent them and never interprets them. Both headers are removed before the request is forwarded, so they never reach your provider. Tags has the rules.

What the gateway does

It forwards the request to your provider and streams the response back byte for byte, including streamed chunks. The request is forwarded as sent, with one exception made so that streams can be metered: a streaming /v1/chat/completions request that says nothing about stream_options is sent with "stream_options":{"include_usage":true} added, and the usage chunk it produces comes back to you unchanged. A request that sets stream_options in any form is left alone, and if it turns usage off, its tokens go unreported and its cost is null. After the last byte of the response, the gateway writes one metering event for the request:

• the request id, your organization and the key the request used;
• the provider, the model that answered and the route (/v1/chat/completions, /v1/messages, and so on);
• the input, output and cached token counts your provider reported on its own response;
• the status, the timings and the sizes;
• your tags and project, if you sent them.

There is no field in the event, and no column in the record, that can hold a prompt, a completion or a tool argument. The metering is content-free by schema: nothing about what was said can be recorded, because there is nowhere to record it.

The event is then priced against the reference price list, and the version of the list that priced it is written beside the cost. A published version of the list is never edited; a correction ships as a new version, so an old receipt still prices to the same figure. A count your provider did not report, or a model the list has no price for, is stored as null and never estimated.

A request to a declared upstream is metered the same way. Its cost is the one your destination reported, or null where it reports none.

What comes back

Your provider's response, unchanged, with one header added:

x-recovea-request-id: req_0192f3a4b5c6d7e8f9a0b1c2d3e4f5a6

That id is the metering event's id and the receipt's request_id. In the platform, the request is on the Requests page; Attribution cuts spend by key, project and tag; and the Ledger page exports every receipt in a period. The receipt, and how to re-derive it, is Prove.

What it records, and what it cannot

• The token counts are your provider's. The gateway reads them from the provider's own response. A receipt records that report and that it has not been changed since; it is not an independent count of tokens.
• Only routed traffic is metered. A call your code makes to a provider directly never reaches the gateway, and nothing records it.
• No content is recorded, for any plan, on any path.