A new open-source tool called unalloc shows how accounting choices can change recorded AI spending and each team's share of a bill, even when the workload stays the same. It joins Kubernetes costs, gateway logs and model-provider charges, then exposes money that has no owner, appears twice or moves between teams when the allocation rule changes.
AI services often leave separate accounting trails. OpenCost estimates the cost of workloads running in Kubernetes. LiteLLM can log requests passing through a model gateway. OpenAI and Anthropic provide their own organization-level billing data. A company may need all of them to understand total spending, but the records use different labels and can describe the same request more than once.
Timothy Urista built unalloc to turn those records into one ledger. Each adapter converts a source into the same cost-row format, while a normalization step reconciles labels such as a Kubernetes cost center, a LiteLLM team ID and a provider project ID. The command-line tool then reports which rows lack the chosen owner label, which rows were assigned only through a fallback label and whether totals reconcile with an invoice.
Two accounting shortcuts produce opposite errors
One case study ran the unmodified tool against mock OpenCost, LiteLLM, OpenAI and Anthropic services. Enabling every source counted gateway traffic again when the same provider charges arrived through both LiteLLM and the provider billing interfaces. In the study, that added $11,800 to the ledger. At the other extreme, reading only the first page of a provider billing API returned 25 percent of OpenAI spending and 24 percent of Anthropic spending in the constructed dataset.
A separate synthetic month of Kubernetes allocations tested distributed inference. Labels placed only on the leader pods of a LeaderWorkerSet left 66 percent of that deployment's GPU cost without a team. Falling back to a generic name reduced the headline unallocated share to 4 percent, but 61 percent of the cost was then assigned to a Helm chart name rather than an actual owner. The lower missing-cost number therefore hid a worse attribution decision.
The meter changes who pays for a shared H100
The paper also reports a validation run using vLLM 0.29 and the Qwen2.5-7B model on one NVIDIA H100. A token-based meter assigned a retrieval-heavy tenant 12 to 14 percentage points more of the shared bill than an equal time-share meter across the tested loads. The configured arrival rates ranged from 2 to 16 requests per second, while completed throughput ranged from 3.7 to 26.9 requests per second because the configured rate counted only the first request in each session.
GPU utilization stayed between 97 and 99 percent, so that familiar metric did not explain the difference between tenants. Token metering charged according to processed tokens; time sharing divided cost by how long requests occupied the server. Neither is a ground-truth measure of the energy or compute caused by one tenant, and the author compares both with more computationally demanding attribution methods based on Shapley values.
The Kubernetes and provider examples use synthetic allocations and mock services rather than a company's observed invoice. The hardware result comes from one H100 configuration and one workload mix. The paper is a new arXiv preprint, and the PyPI package is marked alpha.
