The Doubao API is served through Volcengine Ark, and the bill is not a fixed fee charged once per call. It is determined by input tokens, output tokens, caching, inference mode, and reserved resources. Many teams build a budget from a single unit price, then find costs running high after launch. The reason is often not a price increase, but an input structure, cache hit rate, and calling pattern that differ from the estimate.

This article breaks Doubao API billing into parts you can check one by one, then gives an order for estimation and cost reduction. Specific unit prices are governed by the on-site model pricing page and the official Volcengine Ark price page; prices and rules may change.

Note: Doubao, Volcengine Ark, and Volcengine are trademarks of their respective owners. This article is for technical explanation only and does not imply any partnership. Billing and invoicing rules are governed by the official pages.

1. What the bill is made of

Volcengine Ark online inference is billed per token on a pay-as-you-go basis, but the complete bill may also include cache storage, batch inference, guarantee packages, and fine-tuning fees.

Billing item When it is incurred Unit Notes
Input (cache miss) The prompt enters the context for the first time Token Corresponds to prompt_tokens
Input (cache hit) A previously cached prefix is reused Token Corresponds to cached_tokens, usually at a lower unit price
Cache storage After context caching is enabled Token × hour Billed on the maximum stored volume within a natural hour
Output The model generates text or structured results Token Corresponds to completion_tokens
Batch inference Offline batch jobs Token Priced separately, usually not covered by free quota
TPM guarantee package Reserved throughput per minute Purchase duration Billed even when not used
Model unit Dedicated compute Purchase duration Billed even when not used
Fine-tuning Training stage Token × epoch or compute Separate from inference fees

Separate "pay for what you use" from "pay for what you reserve" first, so the budget has no missing lines. The former fluctuates with traffic; the latter is a fixed cost.

2. How input and output are counted

Input is everything that enters the context in a request: system prompt, message history, tool definitions, retrieved documents, images, and other multimodal content. All of it is converted to tokens and billed at the input unit price. Output is what the model actually generates, billed at the output unit price, which is usually higher.

A few details that are easy to overlook:

  • If a multi-turn conversation sends the full history every time, input tokens accumulate with each turn rather than counting only the latest sentence.
  • Tool schemas and function descriptions also consume input tokens; the more tools, the larger the fixed overhead.
  • Images, audio, and other multimodal inputs are converted according to rules and cannot be estimated from text length alone.
  • Thinking content produced by reasoning models is usually counted as output; the exact treatment is governed by the official billing documentation.

So the budget question is not only "what do input and output cost" but also "what share of my request is input versus output". A customer support bot has heavy input and short output; long-form generation is the opposite. Their cost structures are completely different.

3. Context caching: it saves money and also costs money

Context caching works by reusing a stable prefix. When the beginning of two requests is identical, the matched part is billed at the lower cache-hit unit price, and only the new content is billed as regular input. But caching is not free:

  1. Cache hits are billed through cached_tokens; the price is lower than regular input, but not zero.
  2. Cache storage is billed hourly, usually settled on the maximum number of tokens stored within each natural hour.
  3. Caching is best-effort and does not guarantee a hit; when the hit rate is low, storage fees may exceed the input fees saved.

To make caching actually save money, put stable content at the start of the request: a fixed system prompt, fixed tool definitions, a fixed knowledge prefix. Put timestamps, random IDs, user nicknames, and dynamic retrieval results at the end. If every request is genuinely different, turn caching off first and decide after watching the bill.

4. Choosing online inference, batch inference, and guarantee packages

Volcengine Ark offers several inference modes with different prices and use cases:

  • Online inference, pay per token: suits workloads with uncertain traffic and ordinary latency requirements; nothing is charged when idle, and new users usually receive a deductible free quota.
  • Batch inference: suits offline labeling, content moderation, bulk summarization, and other tasks that do not need real-time results; prices are usually lower, but free quota cannot be applied.
  • TPM guarantee package: suits production workloads with predictable traffic and a need for stable throughput; purchased by day or hour and billed even when not called.
  • Model unit: provides dedicated compute for fine-tuned models or special concurrency needs, and is a fixed cost.

Do not compare only unit prices when choosing. Batch inference is cheaper but results are delayed; a guarantee package is stable but burns money during idle periods. Split workloads by "real-time versus offline" and "predictable versus unpredictable traffic", then match billing modes. That is usually more effective than simply switching models.

5. Run a real estimate with the usage field

Do not guess tokens from character counts. Record the usage returned by every call and observe it for a week; you will get the real structure of your workload.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ARK_API_KEY"],
    base_url="https://ark.cn-beijing.volces.com/api/v3",
)

resp = client.chat.completions.create(
    model=os.environ["ARK_ENDPOINT_ID"],  # endpoint ID or model ID, per the console
    messages=[
        {"role": "system", "content": "You are a support assistant. Answer in no more than three sentences."},
        {"role": "user", "content": "Can the shipping address still be changed after the order ships?"},
    ],
)

print(resp.usage)  # record input, output, and cache fields

Estimate in this order:

  1. Fix the recording format: time, project, model, input tokens, output tokens, cache hits, whether streaming, and retry count.
  2. Sample one week and calculate average input and output per scenario, not the site-wide average.
  3. Calculate cost per call as input × input unit price + output × output unit price, with cache hits calculated separately at the lower price.
  4. Multiply by average daily calls, then by 30, to get the monthly inference cost.
  5. Add fixed items such as cache storage, batch jobs, guarantee packages, or model units.
  6. Reserve a buffer for retries, peaks, and price changes.
  7. Once a month, work backwards from the actual bill and correct the estimation model.

If the response does not return cache breakdown fields, record total input and total output, then infer from the bill or usage page. The key is consistency: do not compare data from different entry points or different dates.

6. The order of cost control matters

  1. Quantify first: break real token structure down by project, model, and scenario, and find the three most expensive call types.
  2. Then raise cache hits: put stable prefixes first, reduce dynamic content, and watch how the hit rate changes.
  3. Then reduce input: retrieve only relevant passages, summarize history, and keep only necessary fields from tool results.
  4. Limit output: set a reasonable max_tokens, request JSON or fixed fields, and reduce repeated explanations.
  5. Route by model: send classification, extraction, and rewriting to lightweight models, and escalate only complex reasoning.
  6. Move offline tasks to batch: put non-real-time work into batch inference and avoid peak hours.
  7. Negotiate unit price last: if input is unmanaged and cache misses dominate, switching to a cheaper model will not bring costs down.

7. Managing budgets and bills

  • One key per project, with test and production separated, so they do not compete for quota.
  • Set spending limits and balance alerts on keys to stop losses quickly when calls go wrong.
  • Reconcile weekly by project, model, and scenario, and find the fastest-growing call types.
  • Record savings from caching, batch, and model routing separately; otherwise you cannot prove the optimization worked.
  • Teams that need RMB payment, unified billing, and invoices can use the OpenAI-compatible ZSQH AI Gateway; prices and billing are governed by model pricing.

FAQ

Does the Doubao API have a free quota?

Online inference usually has a new-user free quota that can offset pay-per-token usage; batch inference and fine-tuning generally do not accept free quota. The amount and validity period are governed by the Volcengine Ark console.

Why is cache storage charged as well?

Caching consumes server-side storage, so in addition to token fees for cache hits, there is a charge based on stored volume and duration. When the hit rate is low, optimize the prefix structure first and disable caching if necessary.

Is batch inference always cheaper?

The token unit price for batch inference is usually lower, but results are not returned in real time and free quota does not apply. It suits offline jobs, not low-latency scenarios such as online customer support.

Are retried requests billed?

As long as the server completes inference and produces tokens, the request is usually billed, even if the client times out before receiving the result. Whether failed requests are billed is governed by the bill and official documentation; retry logic needs backoff and a cap.

Why does my estimate not match the bill?

Common missing items include message history, tool definitions, multimodal conversion, cache storage, retried requests, and fixed guarantee-package fees. Match request IDs against usage logs to locate the difference.

Next step

Create a test key on ZSQH AI Gateway, run real tasks for a week, record input, output, and cache hits, then convert the budget using model pricing. Model availability and prices are governed by the pricing page.

Related reading: