LiteLLM Bedrock Spending Shows $0: What to Check Before Trusting Budgets

If LiteLLM reports zero spending for a paid Bedrock request, check the deployment's pricing resolution before trusting its budget controls. AWS's November 12 gateway walkthrough highlights this failure mode, but current LiteLLM releases include inference-profile pricing fixes. The right repair depends on your deployed version and configuration.

A working response proves that authentication, routing and inference succeeded. It does not prove that the gateway assigned a cost to the request. Those are separate acceptance tests, particularly when teams depend on virtual-key budgets to contain spending.

Separate a missing record from a zero-priced record

Start with one known request and its identifier. Find its spend entry, then compare the recorded usage, deployment and price with the provider response. If the row is absent, investigate logging first. If token usage is present but spending is zero, investigate accounting rather than repeatedly changing Bedrock permissions.

LiteLLM's spend-tracking documentation describes warnings for requests that have usage but resolve to zero despite a non-zero pricing entry. They identify the deployment and missing pricing fields. The litellm_zero_cost_requests_total Prometheus counter separates reasons including missing_pricing_key, pricing_not_applied and cost_calculation_error.

Treat those reasons as diagnostic clues. A missing field and a calculation failure do not necessarily have the same fix. Also, the warning excludes intentionally free models and requests without usage, so the absence of a warning is not proof that every paid request was accounted for.

Inference-profile pricing is version-dependent

The AWS gateway example maps model aliases to Bedrock application inference-profile ARNs and explicitly supplies token prices. It warns that an unpriced ARN can leave spending at zero, undermining spend-based enforcement.

However, LiteLLM's 1.106.2 release notes describe a fix for inference-profile deployments logging zero or losing charges, including output charges when only an input override was configured. That release uses the profile's catalog pricing and applies custom prices individually to the fields supplied.

Do not turn an example's workaround into a universal rule for every version. Record the exact image or package version, inspect its pricing behavior and review the relevant release notes before adding overrides. Nor should you assume a price-data refresh replaces a code fix. Resolving a model to its rate and applying that rate correctly are different operations.

For a candidate upgrade, replay a small representative request in staging and inspect both input and output charges. A non-zero total can still hide one missing component.

Check the units before adding custom rates

The model cost-map documentation specifies USD per billable unit. For token prices, divide a provider's per-million figure by one million. It also distinguishes ordinary input, output, cache and service-tier rates; identifying a model does not guarantee that every rate your request needs is present.

For an illustrative deployment priced at $4 per million input tokens and $12 per million output tokens, the ordinary token fields would be:

model_info:
  input_cost_per_token: 0.000004
  output_cost_per_token: 0.000012

These are invented teaching rates, not prices for a named Bedrock model. A request with 2,000 ordinary input tokens and 500 output tokens would cost $0.014 under those assumptions: $0.008 plus $0.006. Cache usage, regional premiums or other billable components would require their applicable rates instead.

This small calculation makes a useful reconciliation check. Compare the expected components with the actual spend row before testing a budget threshold. Do not copy a tutorial's historical model prices into production because its YAML happens to parse.

Verify enforcement separately from accounting

Use an isolated staging key and a deliberately small test budget. First establish that a known paid request changes the intended key's recorded spend. Then check that crossing the configured limit produces the expected behavior for subsequent requests. Keep production keys and existing spend history untouched while doing this.

Include the request shapes your application actually uses. If it streams, retries or uses prompt caching, a single ordinary completion is not enough evidence. Record expected versus observed spending for each case, rather than declaring the gateway correct after one green response.

This is a documentation-based troubleshooting workflow, not a report of a deployed gateway test. The point is to make the failure observable before it becomes a billing surprise. A budget attached to incomplete spending data is a policy with an unreliable measuring instrument.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help teams explain complex AI infrastructure and operating trade-offs clearly to developers and enterprise buyers.

Book a 30-minute call