Global Compute Token Ledger: Architecture for Enforcing Prepaid Compute Everywhere

Global Compute Token Ledger: Architecture for Enforcing Prepaid Compute Everywhere

A compute budget is not enforceable if some work reaches the budget ledger and other work reaches a provider directly.

That is the central architectural problem. An application may meter the LLM calls made through its chat interface while a background worker launches an unmetered export, an image-generation request bypasses the application gateway, or a third-party client calls an internal API with a service credential. Each path can appear legitimate in isolation. Together, they create a blind spot: the organization sees a partial account of consumption while remaining exposed to uncontrolled spend.

A global compute token ledger addresses that failure by imposing two conditions on every metered operation:

1. The operation must receive an approved reservation before it starts.
2. The reservation must be settled against measured usage after completion.

The design cannot guarantee this merely by creating a ledger or adding a billing function to each application. It requires a single enforcement layer placed at every trusted entry point, a single authoritative ledger, and a control model that prevents unregistered workloads from obtaining usable credentials or reaching paid compute providers.

The resulting system is closer to a financial control plane than to a usage dashboard. It must answer, before execution, whether a request is authorized and funded; during execution, which resources it may consume; and afterward, what it actually cost, who paid, and whether the work produced an accepted result.

The problem is not measurement alone

Modern AI workloads rarely consist of one model call. A single user request may invoke a language model, retrieve documents, generate embeddings, call a browser or database tool, produce an image, execute a background job, and retry after a timeout. An agent may perform several of these actions before returning one answer.

A request counter hides that structure. Even a token counter can hide it if the system records only the model provider's invoice. The cost may also include tools, retrieval, storage, GPU time, network transfer, observability, failed attempts, and human review. Kai's analysis of AI cost accounting describes this distinction directly: a token meter is an input to a cost ledger, not the ledger itself. The proposed denominator is a useful task outcome, such as an accepted code change or a resolved support case, rather than the number of API requests alone. Kai, “AI tokenomics needs a cost ledger, not another dashboard”

The practical consequence is simple:

The unit charged by the control plane should be an internal compute token, while the ledger must retain the underlying meters that explain how those tokens were spent.

An internal token does not need to equal one provider token. It can represent a normalized unit of prepaid compute capacity or monetary value. The ledger should preserve the raw evidence, including provider, model, input and output tokens, tool duration, image dimensions, GPU seconds, storage operations, and other relevant meters. The internal token deduction then becomes a policy decision based on that evidence.

This separation prevents two common errors:

• treating provider tokens as a complete measure of system cost;
• treating an internal credit balance as sufficient evidence of what happened.

The enforcement guarantee

The phrase “every operation must pass through a token deduction before it runs” sounds absolute, but its meaning depends on the boundary of control.

A system can enforce the rule for work that it owns or can place behind a controlled gateway. It cannot guarantee that an unknown machine, stolen credential, unmanaged provider account, or administrator with direct infrastructure access will never consume compute outside the ledger. The architecture must therefore define its enforcement perimeter explicitly.

Within that perimeter, the guarantee should mean:

• every metered request enters through an approved gateway, scheduler, worker broker, or provider adapter;
• the entry point requires an authorization decision from the ledger service;
• the authorization decision creates a reservation before dispatch;
• the operation receives only the scoped credentials and limits associated with that reservation;
• direct provider credentials are unavailable to application code and ordinary workers;
• completion, failure, timeout, or cancellation closes the reservation;
• unreconciled reservations are recovered by a controlled expiry process;
• all ledger mutations are durable, idempotent, and auditable.

The guarantee is therefore architectural rather than procedural. A developer guideline saying “remember to call deduct()” is not an enforcement layer. Any code path that can run paid work without first passing through the control plane is a bypass by design.

One ledger, many sources of funds

A global ledger should be the source of truth for balances, reservations, deductions, refunds, and attribution. It may interact with separate funding sources, but those sources should not independently decide whether an operation may run.

The KDCube economics model provides a useful reference pattern. It defines a four-stage lifecycle:

1. Verify the plan, funding, identity, and quota.
2. Reserve an estimated amount before work begins.
3. Run the accountable operation while emitting usage.
4. Settle the actual cost and release the unused reservation.

Its documentation also makes an important accounting distinction: there is no fixed “cost per turn.” A turn may contain model calls, embeddings, web search, tools, APIs, and other tracked work. Spending is attributed across dimensions such as tenant, project, user, application, conversation, agent, flow, provider, and model. KDCube, “Platform Economics”

A global ledger can use the same conceptual structure while supporting several funding sources:

• tenant or project budget;
• subscription allowance;
• application budget;
• user wallet;
• promotional or lifetime credits;
• approved organizational overdraft;
• emergency administrative budget.

The funding split must be determined before dispatch. A request should not begin with an ambiguous promise that “some budget” may eventually cover it. The policy engine should resolve a primary payer and any fallback source, then reserve against the selected accounts as one admission decision.

For an estimated charge \(R\), a simple model is:

\[

R = R_{\text{primary}} + R_{\text{wallet}} + R_{\text{fallback}}

\]

where the primary portion is bounded by the remaining plan quota and available primary funds. The wallet or fallback portion covers the remainder only if policy permits it. The KDCube documentation describes a similar rule in which the plan-funded portion is limited by both quota and primary funds, the wallet covers the remainder, and the project budget absorbs a residual shortfall as a last resort. It also states that subscriptions and wallets do not go negative. KDCube, “Platform Economics”

The exact hierarchy is a policy choice. The invariants are not:

• no negative balance unless an explicit overdraft policy exists;
• no reservation without an identifiable payer;
• no settlement that silently changes the payer;
• no double charging across a parent operation and its child operations;
• no untraceable transfer between budgets.

The global control plane

The control plane should contain five logically separate components.

1. Policy and identity service

This service determines whether an actor may perform an operation. It resolves:

• tenant and project;
• user, application, agent, or service identity;
• plan;
• operation type;
• allowed providers and models;
• concurrency limits;
• token or credit windows;
• per-operation caps;
• geographic or data-handling restrictions;
• funding source;
• emergency or administrative permissions.

The identity must travel with delegated work. If Open WebUI starts a background export, the export cannot appear as an anonymous system task. It needs a parent-child relationship such as:

tenant
  -> project
    -> user
      -> application
        -> conversation
          -> turn
            -> flow
              -> child operation

The child operation may have a different execution identity, but it must retain the delegating principal and the original authorization context. This allows the ledger to answer both “which worker spent the tokens?” and “which user or application caused the work?”

2. Reservation and settlement service

This is the enforcement authority. It should expose a narrow interface rather than allowing applications to mutate balances directly.

A conceptual request might contain:

{
  "operation_type": "image_generation",
  "tenant_id": "tenant_123",
  "project_id": "project_456",
  "actor_id": "user_789",
  "idempotency_key": "flow_abc:image:1",
  "estimate": {
    "input_tokens": 0,
    "output_tokens": 0,
    "image_count": 1,
    "resolution": "1024x1024"
  },
  "limits": {
    "max_compute_tokens": 120
  }
}

The service returns a reservation identifier, approved limits, expiry time, and a signed execution grant. The grant should be scoped to the specific operation. It should not be a general-purpose API key that remains usable after the reservation expires.

Settlement records the actual usage and closes the reservation:

{
  "reservation_id": "res_123",
  "usage": {
    "provider": "image-provider",
    "model": "image-model",
    "images": 1,
    "resolution": "1024x1024",
    "latency_ms": 8420
  },
  "result": {
    "status": "completed",
    "useful_task": true
  }
}

The state machine should be explicit:

requested
   |
verified
   |
reserved
   |
running
   | \
   |  \ timeout or cancellation
   |   \
settled released
   |
expired

This is a conceptual state machine, not a claim that every source implements these exact states. A reservation must not be both settled and released. Every transition requires an idempotency key and a durable record of the actor, timestamp, policy version, pricing version, and reason.

3. Metering and normalization service

The metering layer converts provider-specific usage into a common record. Model providers may expose input tokens, output tokens, cached tokens, reasoning tokens, image units, audio duration, or other measurements. Tools may report seconds, bytes, pages, characters, or successful operations.

The normalizer should preserve both:

• the original provider-reported meter;
• the normalized quantity used for internal pricing.

A normalized event might include:

The OpenMonetize project demonstrates a simpler version of this model. Its README describes an ingestion API for tracking events, a rating engine that calculates cost from a configurable “burn table,” and a database update that deducts credits from a user's wallet. The project also describes the ingestion path as idempotent and fast, with pricing separated from the application that made the model call. OpenMonetize, README

That separation is valuable, but ingestion after the provider call is not sufficient for a hard pre-execution guarantee. Post-call tracking can explain and charge work; it cannot prevent an unfunded call from starting. A global design needs both pre-call authorization and post-call usage ingestion.

4. Execution gateways

The gateway is where the guarantee becomes real. Different operation types require different adapters, but they should all implement the same contract:

authorize -> reserve -> dispatch -> observe -> settle

Possible gateways include:

• an OpenAI-compatible LLM gateway;
• an image-generation adapter;
• an embedding service;
• a web-search or retrieval proxy;
• a background-job broker;
• an export service;
• a file-processing worker;
• a GPU scheduler;
• an API gateway for third-party applications;
• a tool-execution sandbox.

The application should not call a paid provider directly. It should call the appropriate internal gateway, which obtains or validates the execution grant and injects the provider credentials. Provider keys belong in the gateway or a tightly controlled secret broker, not in Open WebUI, arbitrary workers, browser clients, or third-party application configuration.

A real-world account of combining LiteLLM with Open WebUI illustrates why this matters. The author described multiple agents and applications calling different providers directly, with API keys scattered across environment files and no consolidated view of spend. The proposed solution placed LiteLLM between clients and providers, making it the common traffic hub while Open WebUI served as the human-facing interface. Guła, “Building an LLM hub”

A gateway can centralize routing and usage visibility. It does not automatically provide global enforcement. Background jobs, image generation, exports, and third-party API traffic must also use controlled adapters. Otherwise, the organization has a central LLM gateway but still lacks a global compute boundary.

5. Ledger database

The ledger database should be append-oriented for financial and usage events. Mutable balance fields may exist for fast reads, but they should be derived from or reconciled against immutable transactions.

At minimum, the ledger needs:

• accounts;
• reservations;
• usage events;
• settlement events;
• release and refund events;
• funding allocations;
• pricing versions;
• policy versions;
• identities;
• parent-child trace relationships;
• idempotency keys;
• reconciliation records;
• audit events.

A balance should be explainable as a sequence:

opening balance
+ grant
+ top-up
- reservation commitment
+ reservation release
- settled usage
+ refund
= current available balance

The transaction history must permit reconstruction at any point in time. A dashboard that shows only a current number cannot prove whether a deduction was valid, duplicated, or later corrected.

Reservation is the essential control

Generative workloads create a timing problem. The final output length, tool path, retry count, and provider behavior may be unknown before execution. Charging only after completion leaves a window in which concurrent requests can overspend the same balance.

The reservation solves that problem by temporarily committing an estimate. If five requests each believe they can spend the last 100 tokens, a system that checks balance without reserving can admit all five. A reservation system admits only the requests whose combined holds fit within the available balance and quota.

The estimate should be conservative enough to prevent material overruns but not so large that it blocks ordinary work. Different operation types need different estimation methods:

• LLM calls: prompt tokens plus maximum permitted output and tool allowance;
• image generation: image count, resolution, model, and variation count;
• audio generation: character count, duration, voice, and output format;
• exports: rows, pages, file size, transformation complexity, and worker time;
• background jobs: historical cost by job type plus a maximum retry budget;
• retrieval: document count, embedding writes, reranking, and storage operations;
• GPU jobs: requested accelerator type, duration limit, and storage footprint.

The reservation should also set an execution ceiling. If the operation exceeds the approved limit, the gateway should stop, pause, or request an additional reservation. It should not continue consuming and hope that settlement can repair the account later.

The KDCube model explicitly treats reservation as protection against concurrent oversubscription and states that denial occurs before paid work runs, with no leftover money hold. KDCube, “Platform Economics” The DeepWiki page for ii-agent describes the same pattern: quote a price before the call, reserve credits, calculate the actual cost from returned usage, and release excess credits afterward. DeepWiki, “LLM Billing Service & Usage Tracking”

Failure handling determines whether the system is trustworthy

A prepayment system fails in two opposite ways.

It can fail open, allowing unfunded work to run. Or it can fail closed so aggressively that crashes and network partitions permanently lock user balances.

The correct design distinguishes authorization failure from execution failure.

Before dispatch

If policy verification or reservation fails, no provider call should occur. The request should receive a structured error, such as an insufficient-credit, quota, concurrency, or policy response. A zero-cost denial must leave no hold behind. The KDCube documentation supports this behavior for its described economics flow. KDCube, “Platform Economics”

After reservation but before dispatch

If the worker crashes or the gateway cannot dispatch, the reservation should be released or marked failed. This transition must be idempotent because the client may retry after losing the response.

During execution

The operation should emit heartbeats or progress events when it can run for a long time. The reservation has a lease and an expiry policy. A worker that loses contact should not retain funds indefinitely.

After provider completion but before settlement

This is the most difficult interval. The provider may have completed the work while the gateway timed out. A retry can create a duplicate model call or image generation. The execution grant and idempotency key should therefore be carried through the provider adapter whenever the provider supports idempotency. Where the provider does not support it, the system must record uncertainty and apply a retry policy that favors reconciliation over blind repetition.

Stale reservations

A recovery job should identify reservations that exceed their permitted age and move them to expired, released, or a manual-review state. The DeepWiki page for ii-agent describes a cleanup job that releases or expires reservations left in the reserved state beyond a threshold, giving 45 minutes as a typical example in that implementation. DeepWiki, “LLM Billing Service & Usage Tracking”

That duration should not be copied blindly. A short image request and a multi-hour GPU job need different leases. The policy must specify:

• maximum execution time;
• heartbeat interval;
• grace period;
• who may extend a lease;
• whether an expired operation may continue;
• how uncertain provider outcomes are reconciled;
• when manual review is required.

Open WebUI is an entry point, not the enforcement layer

Open WebUI can serve as a user-facing interface, but a user interface cannot be the global authority. It is one client among many.

The enforcement boundary should sit below the interface:

Open WebUI
     |
     v
Global API and policy gateway
     |
     v
Reservation and ledger service
     |
     v
LLM, image, embedding, search, tool, and job adapters
     |
     v
External providers or internal compute

This arrangement is intended to ensure that:

• Open WebUI calls are metered;
• API clients follow the same path;
• background work receives a child reservation;
• image generation cannot bypass the LLM accounting path by using a separate credential;
• exports and scheduled jobs are admitted through the same policy;
• the ledger sees the whole flow rather than only the front-end turn.

The system should also prevent the interface from creating unmetered work indirectly. For example, if a chat message queues a document export, the export service must validate a signed child grant. A queue message containing only “run export for user 123” is insufficient because a malicious or stale message could be replayed without a valid reservation.

Third-party applications require an explicit trust boundary

A third-party application hitting an API is not automatically trustworthy because it has a valid API key. Its key must identify an account, application, environment, and spending policy.

Per-key attribution is a practical control. Router One describes a model in which each request records the model, input and output tokens, computed cost, latency, status, and route; usage rolls up by model and API key; and individual keys can carry spend caps, rate limits, and token ceilings. Router One, “Track LLM costs per request, model, and key”

Those controls should exist at the global gateway even if a provider also offers them. The organization needs its own account of spend and its own admission decision. Provider-side limits are useful defense in depth, but they are not a substitute for the internal ledger because they may be delayed, differently defined, or unavailable across providers.

Each external application should receive:

• a scoped key or signed token;
• allowed operation types;
• project and tenant binding;
• maximum reservation;
• concurrency limit;
• rate limit;
• approved models or providers;
• expiration and rotation policy;
• audit identity;
• optional human or business outcome association.

A leaked key should hit a bounded policy, not an unlimited wallet. A service that needs more capacity should request a policy change rather than bypassing the ledger.

Background jobs and exports need the same treatment

Teams often protect synchronous API calls but overlook asynchronous work. That creates a predictable bypass:

1. A user request passes the ledger.
2. The application queues a background job.
3. The worker uses provider credentials directly.
4. The resulting cost never receives a reservation.

The queue must become part of the enforcement boundary. The correct sequence is:

user request
   -> reserve parent flow
   -> authorize child job
   -> reserve child operation
   -> enqueue signed job
   -> worker validates grant
   -> execute
   -> settle child
   -> settle or update parent

The parent reservation may cover orchestration overhead, while each child operation receives its own reservation. The ledger should avoid double counting by defining whether parent cost includes child cost or merely records aggregation.

Exports create a related problem because they may consume database, CPU, storage, network, and third-party services without using an LLM. If the policy concerns all compute, the term “token” must be an accounting unit for all metered work, not a synonym for model tokens.

An export might be charged based on:

• records processed;
• CPU seconds;
• memory allocation;
• compressed output size;
• storage writes;
• network transfer;
• worker class;
• external transformation calls.

A single universal conversion rate may be operationally convenient but analytically weak. The ledger should retain the physical or service-specific meters and convert them into internal tokens through versioned price tables.

The ledger must distinguish cost from value

A global compute ledger can control spending without proving that the work was useful. Those are separate questions.

The ledger should record outcome references such as:

• accepted;
• rejected;
• retried;
• escalated;
• policy-blocked;
• stale-data;
• manually repaired;
• user-abandoned;
• completed without review.

The business outcome itself may live in another system. The ledger should join to it using stable identifiers rather than copying sensitive content into finance tables. Kai's analysis recommends separating restricted traces from the cost ledger and using IDs, meters, hashes, classifications, and outcome references for financial analysis. Kai, “AI tokenomics needs a cost ledger, not another dashboard”

This separation supports privacy and access control. A finance reader can determine how much a tenant spent without receiving the tenant's prompts, documents, or generated content.

A useful cost metric might be:

\[

\text{cost per accepted task}

=

\frac{

\text{model usage}

+

\text{tools}

+

\text{retrieval}

+

\text{embeddings}

+

\text{storage}

+

\text{GPU and platform cost}

+

\text{failed runs}

+

\text{human review}

}{

\text{accepted useful tasks}

}

\]

This is an analytical measure, not necessarily the deduction formula. The deduction must happen before execution, whereas the useful-task denominator becomes available afterward.

Policy authority must be unambiguous

A global ledger becomes unreliable if several systems claim authority over the same policy.

The KDCube documentation distinguishes descriptor-edited policy from database-backed operational policy. Its economics descriptor defines reservation defaults, price tables, reference services, quota policies, plans, and overdraft behavior, while operational updates may be stored in PostgreSQL and managed through an administrative interface. KDCube, “Platform Economics”

That distinction is useful, but the architecture must define precedence precisely. For each policy family, specify:

• source of truth;
• update mechanism;
• propagation delay;
• effective timestamp;
• rollback method;
• audit requirements;
• behavior during database or configuration outages.

A possible division is:

A configuration file should not silently override a live budget row. Conversely, an administrator dashboard should not change a price table without a versioned record that explains which settlements used the old and new prices.

Availability and fail-closed behavior

The ledger sits on the critical path of every paid operation. That creates an availability tradeoff.

If the ledger is unavailable and the system allows work to continue, it cannot guarantee funding. If it blocks all work, an outage becomes a service outage. The default for a hard-control environment should be fail closed for paid operations, with carefully defined exceptions for already reserved work.

Useful resilience measures include:

• replicated ledger storage;
• synchronous or strongly consistent balance updates;
• local verification of short-lived signed grants;
• durable queues;
• bounded offline allowances only where explicitly authorized;
• reconciliation after recovery;
• separate read paths for dashboards;
• circuit breakers that stop new reservations without corrupting existing ones.

An offline grant can preserve availability only if it was issued before the outage and contains a finite budget, expiry, operation scope, and replay protection. It must not become a general bypass token.

The distinction between an unavailable ledger and a delayed dashboard also matters. A dashboard may lag while enforcement remains correct. A provider invoice may arrive later while the reservation and usage event already establish an internal account. The system should label provisional, reconciled, corrected, and disputed costs separately.

Why dashboards are not enough

A dashboard is a view. A ledger is an authority.

Router One's description of gateway metering captures the operational benefit of a request-level trace: each request can show model, tokens, cost, latency, status, and route, while usage aggregates by model and API key. Router One, “Track LLM costs per request, model, and key”

That visibility helps operators act before a bill grows, but visibility does not prevent a request. A dashboard that reports an overrun after the fact cannot undo provider consumption. Similarly, OpenMonetize's post-call tracking and wallet updates improve accounting but do not, by themselves, establish a pre-dispatch admission guarantee. OpenMonetize, README

The global architecture needs three separate properties:

1. Admission control: unfunded work does not start.
2. Usage accounting: actual work is measured and charged.
3. Reconciliation: internal records can be matched to provider and infrastructure records.

A system that has only one or two of these remains incomplete.

Security controls that make bypass difficult

The strongest enforcement layer can be defeated by credentials or network paths outside it. Security architecture must therefore support the accounting architecture.

Required controls include:

• remove provider keys from application and worker environments where possible;
• route egress to paid providers through controlled network paths;
• restrict outbound network access by workload identity;
• issue short-lived, operation-scoped credentials;
• require mutual authentication between clients and gateways;
• bind reservations to tenant, project, actor, operation type, and expiry;
• prevent replay through idempotency keys and nonce validation;
• separate administrative bypass from ordinary application permissions;
• log every policy decision, including denials;
• rotate third-party credentials;
• detect direct-provider traffic;
• reconcile provider invoices against internal usage;
• alert on unrecognized providers, models, routes, or service identities.

Network controls are defense in depth, not proof of correctness. A privileged administrator may still be able to bypass them. The system should record that possibility as part of its threat model instead of claiming an absolute guarantee that the infrastructure cannot provide.

What should be measured

A global ledger should report more than remaining balance.

Operational metrics should include:

• reservation approval and denial rate;
• reservation-to-settlement latency;
• stale reservation count;
• settlement failure rate;
• usage-to-reservation ratio;
• percentage of work with a valid reservation;
• direct-provider traffic detected;
• unrecognized service identity count;
• duplicate idempotency attempts;
• provider invoice reconciliation variance;
• spend by tenant, project, user, application, agent, model, provider, and operation;
• cost by accepted, failed, retried, and escalated task;
• average and tail cost per useful task;
• percentage of costs still provisional or unreconciled.

The most important control metric is coverage:

\[

\text{enforcement coverage}

=

\frac{

\text{metered operations with valid pre-run reservations}

}{

\text{all detected metered operations}

}

\]

A reported coverage rate of 100 percent means little if the detection system cannot see direct provider traffic or unmanaged GPU jobs. Coverage must therefore be tested through independent reconciliation, not inferred from the ledger's own records.

A staged implementation path

The architecture should be introduced in stages, but the final control point must remain global.

Stage one: define the accounting model

Create the operation taxonomy, internal token unit, funding hierarchy, identity model, reservation states, pricing versions, and ledger schema. Decide which services are in scope and which remain outside the enforcement perimeter.

Stage two: protect the main synchronous path

Put the LLM gateway between Open WebUI, APIs, and providers. Remove direct provider keys from the clients. Implement verify, reserve, dispatch, and settle with idempotency and audit records.

Stage three: add asynchronous work

Require every queue message that triggers paid work to contain a signed child grant. Make workers reject jobs without valid grants. Add lease expiry and recovery.

Stage four: cover non-LLM compute

Add adapters for image generation, embeddings, search, exports, file processing, and GPU jobs. Preserve operation-specific meters while charging through the shared ledger.

Stage five: enforce network and credential boundaries

Restrict egress, rotate keys, detect direct calls, and compare provider invoices with internal records. Treat reconciliation variance as a control failure, not merely a reporting issue.

Stage six: connect cost to outcomes

Join ledger events to accepted-task, quality, escalation, and human-review records. Use those measures to change routing, quotas, and model policies.

Unresolved design questions

Several questions cannot be settled by the ledger alone.

What is a token?

If one internal token represents a dollar, the system resembles prepaid billing. If it represents normalized compute capacity, it may be more stable across providers but harder to explain. If it combines both, the pricing model must disclose how conversions work.

The answer should be explicit and versioned. A token that silently changes value destroys trust in historical comparisons.

Should all compute share one balance?

A common balance is simple and flexible, but an unconstrained image job could consume the budget intended for critical support operations. Separate sub-budgets, priority classes, or reserved pools may be necessary.

How should failed work be charged?

A provider call that returns an error may still incur cost. A failed export may consume substantial compute. The ledger should distinguish provider cost, user-visible failure, retry cost, and remediation cost rather than treating “failure” as “free.”

What happens when provider usage is missing?

Some providers return incomplete or delayed usage data. The system needs provisional settlement rules, later correction, and a visible discrepancy state. It should not silently invent precise usage.

Can the organization guarantee global coverage?

Only within a defined control perimeter. The honest claim is that every operation routed through the controlled environment must pass through pre-run authorization, while independent infrastructure and privileged bypasses require separate controls and reconciliation.

Conclusion

A global compute token ledger is not primarily a wallet, a dashboard, or an SDK. It is a control plane that makes authorization, funding, execution, measurement, and settlement part of one state machine.

The strongest design has three properties:

• one authoritative ledger for balances, reservations, usage, and attribution;
• one enforcement contract implemented by every gateway, scheduler, worker broker, and provider adapter;
• one auditable chain of identity connecting a paid operation to its tenant, project, user, application, task, and outcome.

The reservation must happen before work begins because post-call accounting cannot prevent overspend. The settlement must happen afterward because estimates cannot know the actual path or cost. The ledger must preserve raw meters because an internal token alone cannot explain the bill. And the system must acknowledge its boundary because no software component can control compute that bypasses its network, credentials, or execution environment.

The decisive test is not whether a dashboard can display a balance. It is whether an image job, export worker, API client, background agent, or Open WebUI request can begin with no valid reservation. If the answer is yes, the environment does not have global token enforcement. It has several local meters.

Sources/References

1. KDCube Docs. “Platform Economics.” KDCube. Accessed 25 August 2026. https://kdcube.tech/docs/economics.html

1. OpenMonetize. “OpenMonetize.” GitHub repository, openmonetize/openmonetize. Accessed 25 August 2026. https://github.com/openmonetize/openmonetize

1. DeepWiki. “LLM Billing Service & Usage Tracking.” Intelligent-Internet/ii-agent documentation index. Last indexed 6 April 2026. Accessed 25 August 2026. https://deepwiki.com/Intelligent-Internet/ii-agent/7.2-llm-billing-service-and-usage-tracking

1. Guła, Wojciech. “Building an LLM hub: LiteLLM proxy meets Open WebUI (and 9 bugs meet me).” Accessed 25 August 2026. https://gulasz101.github.io/posts/building-an-llm-hub-litellm-openwebui/

1. Router One. “Track LLM costs per request, model, and key.” Last updated 25 July 2026. Accessed 25 August 2026. https://router.one/llm-cost-tracking

1. Kai. “AI tokenomics needs a cost ledger, not another dashboard.” mubibai.com, 9 August 2026. Accessed 25 August 2026. https://mubibai.com/ai-tokenomics-needs-a-cost-ledger-not-another-dashboard/

Appendix: Live Web Sources Retrieved for This Paper

The following 6 sources were retrieved from the live web during generation and provided to the model as grounding material:

• Platform Economics — KDCube Docs
• openmonetize/openmonetize
• LLM Billing Service & Usage Tracking | Intelligent-Internet/ii-agent | DeepWiki
• Building an LLM hub: LiteLLM proxy meets Open WebUI (and 9 bugs meet me) | Wojciech Guła
• LLM Cost Tracking per Request, Model & API Key
• AI tokenomics needs a cost ledger, not another dashboard - mubibai.com