AI gateways

Connection steps are in the gateway guides, not here.

• LiteLLM
• Kong AI Gateway
• Portkey
• Manage ingest keys

What you set up

1. Create an ingest key under Settings → Ingest keys. The guides show where the gateway sends logs.
2. Give each agent its own gateway key: a LiteLLM virtual key, a Kong consumer credential, or a Portkey key. One shared key cannot be split later.
3. Map each key on Settings → Gateway key registry to an agent. You can also set a cost center and a pool id on that key. The field is labeled Pool id.
4. Create the agent under Agents & allocation first.

The gateway's own ledger is not the provider invoice. A virtual key that fans into one provider key does not, by itself, split that provider's bill. The split reaches the provider bill only when the upstream call also sets a workspace, project, tag, or label the provider records. (LiteLLM spend tracking, Kong AI Proxy, Portkey metadata)

What Meridian receives

One gateway log per request. Meridian rolls those requests up to one spend row per agent, model, UTC day, and pool id. A blank pool id stays blank. A pool id you set is part of that row.

The amount starts as the cost the gateway calculated for the request. LiteLLM prices from its own model cost map and can disagree with the provider invoice. Kong can calculate cost into its log. Portkey attributes inside Portkey by metadata. Meridian stores the usage it was sent, then ties it out when a matching provider bill exists.

How it's attributed

A key mapped to an agent is declared. The agent on the event is the one you mapped. A rule does not replace it. A person's assignment does not replace it.

An OASA cost center on the same events can still set a department when every event in that agent-day carries the same cost center. See OASA events. The agent stays the one from the key.

When a provider bill is also connected for the same vendor, model, and day, Meridian scales rows that have no pool id so they add up to the bill. The bill is the tie-out and is not booked a second time. A row that has a pool id is not scaled to that bill. It stays at the amount the gateway calculated. If there is no matching bill, the gateway amounts stay. If the model names differ, the rows are not forced together.

What lands unattributed, and how to fix it

A request whose key is not in the registry has no agent. The rollup for that traffic stays unattributed. The registry lists keys it has seen and not mapped. Map the key. New days pick up the agent. A day that already has a row is not rewritten by the next rollup.

Fix a past unattributed day from the inbox: assign the rows, or add a rule. Assignment replaces an unattributed row. It does not replace a day that was already declared. A locked month becomes an adjustment later.

If several agents share one key, every request is that one agent. Create a key per agent.

Limits

• Early access on all three gateways. Live production capture is confirmed with you on the first import.
• The gateway's calculated cost can differ from the provider invoice. The tie-out corrects days where the vendor, model, and day match and the row has no pool id. It does not invent a match. A pool id keeps the measured amount.
• LiteLLM end-user ids and request tags, Kong headers, and Portkey metadata do not, by themselves, become the agent. The mapped key does. Portkey metadata reaches the provider bill only when the upstream call stores it.
• Unmapped keys do not produce a declared agent. Spend waits for the rollup, and without an agent it stays unattributed.
• One agent serving several cost centers on the same day is not split. That limit is on the OASA page.