Skip to main content

Level 2: Read the shadow bill

Subscription traffic feels free at the margin, which is exactly why nobody can say what it is worth. The gateway prices every request from the resolved model's per-token pricing even when billing goes to a subscription, so traffic routed in passthrough mode accumulates a shadow bill: the amount the same usage would have cost at API list prices. This level surfaces that number in fifteen timed minutes, and it tends to be the moment an evaluation stops being abstract.


Persona: Developer or engineering leader working in the Developer Console.

Estimated time: 15 minutes, played against a timer.

Progression: Level 2 of 3 in the usage analytics onboarding path. Requires Level 1; completing it unlocks Level 3: Profile agent efficiency.

Outcomes

By the end of this level:

  • Subscription (passthrough) traffic has been isolated on its own key in the monitoring surfaces.
  • The list-price cost of individual subscription-billed requests has been read from Request Logs.
  • The shadow bill for a chosen window has been totalled and set against the subscription's flat price.
  • A month-scale projection has been written down.

Prerequisites

  • Level 1 of this path completed.
  • A personal provider subscription connected in passthrough mode, on its own API key, as set up in Use Your Own Provider Credentials.
  • At least a few hours of real traffic through that key; a working day is better.

Step 1 (minutes 0--3): isolate the subscription lane

  1. Start the timer.
  2. Open Monitoring → Request Logs and filter by the passthrough key.
  3. Confirm the traffic shown is the subscription-billed workload and nothing else.

The one-key-per-purpose pattern from Monitor Traffic and Usage is what makes this filter meaningful; if subscription and API-billed traffic share a key, split them before continuing.

Time check, minute 3: the filtered view shows only subscription traffic.

Step 2 (minutes 3--8): price a single free-feeling request

  1. Open the detail panel of a recent request.
  2. Read its cost calculation: tokens multiplied by the resolved model's per-token pricing.

That figure was not billed to anyone; the subscription absorbed it. It is one line of the shadow bill.

Time check, minute 8: the list-price cost of one subscription-billed request can be stated in dollars.

Step 3 (minutes 8--12): total the window

  1. Switch to Monitoring → Usage and apply the same key filter.
  2. Select the window with real traffic (last 24 hours or last 7 days).
  3. Read Total Spend for the filtered view: that is the shadow bill for the window.

Time check, minute 12: the shadow bill for the chosen window is written down, next to the number of requests that produced it.

Step 4 (minutes 12--15): the reveal

  1. Scale the window to a month (a 24-hour figure times working days, or a 7-day figure times 4.3).
  2. Write the projection next to the subscription's flat monthly price.
  3. Record which is larger, and by how much.

Either outcome is a finding. A shadow bill above the subscription price quantifies the subscription's value; one below it flags a subscription that may not be earning its fee.

Time check, minute 15: the sentence "this subscription is worth $X per month against list prices" can be completed with a real number.

Level complete

  • Subscription traffic isolated on its own key.
  • One request's list-price cost read and understood.
  • The window's shadow bill totalled.
  • The monthly projection written next to the subscription price.
  • Elapsed time recorded.
Bonus challenges

Break-even: compute the daily traffic level at which the shadow bill exactly pays for the subscription, and check which side of it the current usage sits on. Streak: log the shadow bill at the end of each workday for five consecutive days; a five-day streak turns a one-off reveal into a trend line, and the trend is what convinces the rest of the team.