How usage-based LLM billing works: tokens, ledgers and 402s

The shift from subscription to usage-based LLM billing

Most software you use charges a flat monthly fee—Netflix, Slack, your cloud storage. You pay the same whether you use it for five minutes or five hours. LLM APIs work differently. They charge per token, which is the atomic unit of text that a model processes. This usage-based pricing model aligns cost directly with value received, but it introduces concepts that can be confusing at first: token counting, prepaid ledgers, and the dreaded HTTP 402 error.

Understanding these mechanics helps you budget effectively, avoid service interruptions, and design applications that handle billing gracefully. This article explains how usage-based LLM billing works under the hood, using concrete examples from an OpenAI-compatible pay-as-you-go API.

What is a token and how is it counted?

A token is not a word. It's a chunk of text that the model processes as a unit. For English text, one token is roughly 0.75 words, but this varies by language and character set. A typical response like "Hello, how can I help you?" might be 7 tokens. A longer prompt of 500 words might be around 670 tokens.

The total cost of an API call is calculated as:

cost = (input_tokens × input_price_per_token) + (output_tokens × output_price_per_token)

Most providers charge different rates for input (prompt) and output (completion) tokens because generating text requires more computation than processing existing text. For example, on TokenShop, the Qwen3 32B model costs $0.30 per million input tokens and $0.90 per million output tokens.

Here's how you can check token usage from an API response using the OpenAI Python SDK:

from openai import OpenAI

client = OpenAI(base_url="https://tokshop.xyz/v1", api_key="your-api-key")

response = client.chat.completions.create(
    model="alibaba/qwen-3-32b",
    messages=[{"role": "user", "content": "Explain token billing in 20 words."}]
)

usage = response.usage
print(f"Input tokens: {usage.prompt_tokens}")
print(f"Output tokens: {usage.completion_tokens}")
print(f"Total tokens: {usage.total_tokens}")

# Calculate cost in USD
input_cost = usage.prompt_tokens * 0.0000003   # $0.30 per million
output_cost = usage.completion_tokens * 0.0000009  # $0.90 per million
print(f"Estimated cost: ${input_cost + output_cost:.6f}")

The prepaid ledger: micro-USD accounting

Unlike cloud services that bill you monthly for what you used, most LLM APIs operate on a prepaid model. You deposit money into an account, and each API call deducts from your balance in real time. This is called a prepaid ledger.

The ledger tracks your balance in micro-USD (millionths of a dollar). When you sign up for an API like TokenShop, you receive a trial credit of $0.50. Each request then deducts a tiny fraction of a cent. For instance, a short query might cost $0.00003, leaving your balance at $0.49997.

This micro-accounting is necessary because individual API calls cost fractions of a cent. Traditional payment processors can't handle sub-cent transactions efficiently, so the ledger accumulates small charges and only interacts with payment systems when you top up.

To check your remaining balance, you might use an endpoint like:

curl -X GET "https://tokshop.xyz/api/account/balance" \
  -H "Authorization: Bearer your-api-key"

The response typically shows your balance in USD, along with usage history for the current billing period.

HTTP 402: the payment required error

HTTP status code 402 is defined as "Payment Required" but was rarely used in practice—until LLM APIs revived it. When your prepaid balance drops below a minimum threshold (typically $0.001), the API returns a 402 error instead of processing your request.

This is different from a 403 Forbidden (you're authenticated but not authorized) or a 429 Too Many Requests (rate limited). A 402 specifically means: "You have an account in good standing, but your balance is too low to complete this request."

Here's how to handle it gracefully in your application:

import time
from openai import OpenAI, APIError

client = OpenAI(base_url="https://tokshop.xyz/v1", api_key="your-api-key")

def safe_chat_completion(messages, retries=3):
    for attempt in range(retries):
        try:
            response = client.chat.completions.create(
                model="alibaba/qwen-3-32b",
                messages=messages
            )
            return response
        except APIError as e:
            if e.status_code == 402:
                print("Balance too low. Please top up.")
                # Trigger a top-up flow or notify the user
                raise
            elif e.status_code == 429:
                wait = 2 ** attempt
                print(f"Rate limited. Retrying in {wait}s")
                time.sleep(wait)
            else:
                raise

Best practice: check your balance periodically (e.g., every 50 requests) rather than waiting for a 402 error in the middle of a user interaction.

Comparing models: context windows and pricing trade-offs

Usage-based billing means you pay for every token, including those in the context window. A model with a larger context window (like GLM-4.6 at 202,752 tokens) can process more information per request, but each request costs more because you're sending more tokens.

Consider three models available on TokenShop:

Model	Context (tokens)	Input price/M	Output price/M
Qwen3 32B	131,072	$0.30	$0.90
DeepSeek V3.2	131,072	$0.40	$0.80
GLM-4.6	202,752	$0.80	$2.40

If your application typically sends 50,000 input tokens and generates 1,000 output tokens per request:

• Qwen3 32B: (50,000 × $0.30/M) + (1,000 × $0.90/M) = $0.015 + $0.0009 = $0.0159
• DeepSeek V3.2: (50,000 × $0.40/M) + (1,000 × $0.80/M) = $0.02 + $0.0008 = $0.0208
• GLM-4.6: (50,000 × $0.80/M) + (1,000 × $2.40/M) = $0.04 + $0.0024 = $0.0424

GLM-4.6 costs 2.7× more per request than Qwen3 32B for this workload, but offers 55% more context. The trade-off is clear: only use large-context models when your application genuinely needs them.

For a full breakdown of current pricing across available models, visit the pricing page.

Practical tips for managing usage-based billing

1. Set token limits per request. Most SDKs let you cap the max_tokens parameter. This prevents runaway costs from unexpectedly long responses.

response = client.chat.completions.create(
    model="alibaba/qwen-3-32b",
    messages=[{"role": "user", "content": "Write a 5000-word essay on..."}],
    max_tokens=500  # Limits output to ~375 words
)

2. Monitor usage programmatically. Log token counts from every response and aggregate them hourly to detect anomalies.

3. Use streaming for long responses. Streaming lets you start processing output before the model finishes, and you can stop mid-generation if costs exceed expectations.

4. Cache frequent prompts. If many users ask similar questions, cache the response server-side. You pay for tokens once instead of every time.

5. Understand the data policy. Usage-based billing requires tracking token counts, but reputable providers like TokenShop only store metering metadata—your prompt contents are not persisted. This is important for privacy-sensitive applications.

For detailed API documentation on streaming, caching, and error handling, see the TokenShop docs.

Conclusion

Usage-based LLM billing is elegant but unforgiving. You pay only for what you use, but every token has a cost, and a depleted balance means a 402 error. Understanding token counting, prepaid ledgers, and model pricing trade-offs lets you build applications that are both cost-effective and resilient.

Start small: monitor your first 100 requests, calculate the average cost per call, and set a budget. The math is straightforward, but the savings—or surprises—are in the details.