History Rode Along. The Whole Bill Jumped.

1. The window remembers. The API does not.

Qwen multi-turn conversation opens with the constraint: the API is stateless and does not keep the chat. Multi-turn means you send the history on every request. You keep a messages array, append the newest user turn and the model's reply, and submit the whole array as the next input. The second question can be one short line. The payload is still the first question, the first answer, and that new line.

The product UI hides the array. The user sees bubbles. The bill sees the array. "I only added one sentence" is not "this request's input is one sentence." Earlier turns were already billed when they happened. Pasting them back does not refund those tokens. It makes them input again. The same page says that in a multi-turn request the messages are calculated and billed again.

Volcengine Ark names the same meter differently. In the Ark Chat API, usage.prompt_tokens is the token count of the content given to the model. Whatever history you placed in the messages is in that column. Ark also has a session-cache API where you can send only the latest turn and point at a context_id. That is a different call. It does not make history you pasted into Chat free, and its cache-input and storage meters are not a credit against this column. Reconcile the API you actually called.

2. Past the line, the whole request reprices.

A longer history does not only add a few hundred tokens at the old rate. The Bailian price page says some models use tiers. The unit price depends on the input-token total of that single request. Every token in the request settles at the tier that total falls in. The page's own example uses two brackets, above 0 up to 32K and above 32K up to 128K. An input of 100K is in the second bracket, so all of those tokens settle at the second unit price. The first 32K do not stay on the cheap rate.

That is how a short follow-up lifts the whole bill. The previous turn may still have sat in the lower bracket. You attach those messages again, add one short line, and the total crosses. The history that could have stayed cheap is priced at the higher tier for this request. Bracket edges move by model. Read the current edges and unit prices on the price page. This article keeps the rule: the tier follows this request's input total, and crossing it applies to every token in the request.

The same page separates two discounts that do not stack. If a model supports batch calls, input and output can be half the realtime price. If it supports context cache, the discount is on input only. The two do not apply together. The half-price batch article is about successful rows and thinking tokens. It does not pull a realtime request back under a bracket it has already crossed. Reasoning tokens sit on the output side. They do not change which input total picks the tier.

3. A hit changes the unit, not the total.

The multi-turn page tells you to prefer models with context cache, and it names qwen-max and qwen3.8-max among them. Cache is described as automatic, with no code change, and as a way to lower cost and latency. Lower is not delete. The messages are still calculated and billed again. The hit portion uses a cache unit price. The price page says the input prices in its table do not include cache prices. You cannot multiply the cheap-tier input price onto the hit, and you cannot read a hit as "this turn is only the new line, so it is still on the low tier."

Read two columns. The first is the input total you submitted, which picks the tier. The second is the cached token count, which picks a cache unit price instead of the table's standard input price. Tokens that missed the cache stay on that tier's input price. Explicit cache can also charge a creation premium and a storage clock. The rates, the model exceptions, and the hourly storage are already split across the context-cache article and the explicit-cache article. This one only holds the line: a hit does not take history out of messages, and it does not change "the whole request settles on its tier" into "only the new sentence is billed."

Streams hide both columns unless you ask. The multi-turn examples turn on include_usage, and usage arrives on the chunk with empty choices. Without it you see the answer and not this turn's input total, and not how much of that total hit the cache. Dividing the last sentence by a rule of thumb will keep coming in under the bill.

4. Truncation and a summary are not refunds.

The production advice on the multi-turn page is to keep the array short, not to wait for the API to remember. Truncation keeps the last N turns. The next submission is smaller and may fall back under a bracket. The turns you dropped do not come off requests that already settled. You trade early context the model can no longer see for a smaller total next time.

A rolling summary costs more, because it is another call. The documented move, once history is around 70 percent of the context limit, is to take the earlier half, send it as its own API call, and replace that half with the "memory summary" plus the recent turns. That summary call has its own input total and its own output. It can sit on a tier of its own. It shortens the next chat request. It does not reverse earlier turns that already settled on the tier they were in. Details the summary drops are not remembered for free on the next turn.

Vector recall is the third path. After each turn you store the exchange, and on the next question you retrieve a few related pieces and concatenate them with the latest input. Those pieces are still this request's input. They still count toward the total, and they still help pick the tier. The store's idle hours belong to the knowledge-base article. Recall avoids pasting the entire linear history every time. It does not avoid billing the content you actually submit.

5. A top-up does not shorten the history.

Reconcile in four columns. First, whether this messages payload still contains history, not only the new sentence on screen. Second, which tier this input total falls in, and that a crossing reprices the whole request rather than only the overflow. Third, cache hits: they change a unit price, they do not delete history, and the batch half-price does not stack on the same request. Fourth, whatever you used to shrink the next turn: truncation drops early context, a summary is another call, and recall bills the snippets you attached.

Topping up a Bailian or Ark balance happens before the charge. Swapping stablecoins into assets that can fund the account does not shorten messages, does not pull a request back under a bracket it crossed, and does not turn a summary call into a refund. When that swap is the step you need, a no-signup, non-custodial AllSwap exchange is enough to move the asset. A completed swap only means the asset changed hands. The tier for this turn still follows the history you submitted.