VynarisEarly betaGet your API key

Blog · 2026-08-21 · Vynaris Team

LLM conversation cost: a 50-message chat bills 13.24x its transcript

A 50-message chat bills 13.24x its unique transcript. Rolling eight turns cuts the worked API bill by up to 36.5%. Prices verified 2026-08-21.

A 50-message chat containing 10,200 unique tokens bills 135,000 tokens when every request resends the full conversation. That is a 13.24x token multiplier before tools or retries. An eight-exchange window cuts the worked bill by 32.0% to 36.5%, depending on the API. Prices verified 2026-08-21.

TL;DR

Verdict table

Strategy                         Tokens per 50-message chat  GPT-5.6 Luna cost per 1,000 chats  Verdict
-------------------------------  --------------------------  ---------------------------------  -------------------------------------------------------------------------
Unique transcript only           10,200                      Not an API bill                    Content written once
Resend full history              135,000                     $34.00                             Maximum continuity, quadratic input growth
Keep eight prior exchanges       80,600                      $23.12                             Cheapest simple control in this Luna case
Summarize every eight exchanges  71,700                      $23.14                             Fewer tokens, but summary output erases Luna's last $0.02/1,000 advantage

The honest tradeoff is memory quality. Truncation can remove a constraint the user still expects the model to remember. Summaries can preserve the wrong detail. Full history costs more, but it keeps the original text available until the context window forces another choice.

What “50 messages” means here

We count 25 user messages and 25 assistant messages. Each user message causes one API response, so the workload has 25 billable requests. Some teams call that 25 turns; others call it 50 turns. The arithmetic uses message counts to remove the ambiguity.

This is a normal user chat, not an agent loop. There are no tool results, screenshots, retries, hidden reasoning tokens or parallel branches. Those would add separate billable content.

Editable assumptions

Input                     Base value                       Status
------------------------  -------------------------------  -----------------------
System prompt             200 tokens                       Editable assumption
User message              120 tokens                       Editable assumption
Assistant message         280 tokens                       Editable assumption
User/assistant exchanges  25                               Defines the 50 messages
Rolling history           Eight completed exchanges        Editable assumption
Summary cadence           Every eight completed exchanges  Editable assumption
Summary size              600 tokens                       Editable assumption
Summary instruction       100 tokens                       Editable assumption

These are round token budgets, not measured product traffic. The saved script exposes every value.

Why the bill reaches 13.24x

Request one contains the 200-token system prompt and the first 120-token user message. Request two contains those tokens again, plus the first 280-token reply and the second user message. The prefix grows by 400 tokens per exchange.

For request k, uncached input is:

input(k) = 200 + 120k + 280(k - 1)
         = 400k - 80

Summing requests 1 through 25 gives:

total input = sum(400k - 80), k = 1..25
            = 128,000 tokens

total output = 25 x 280
             = 7,000 tokens

total billed tokens = 128,000 + 7,000
                    = 135,000

unique transcript = 200 + 25 x (120 + 280)
                  = 10,200 tokens

multiplier = 135,000 / 10,200
           = 13.24x

The input sum is triangular. Doubling the number of exchanges almost quadruples history input when message sizes stay flat. Our earlier conversational tutor cost model applies the same curve to a specialized 40-turn lesson. This report isolates an ordinary chat and compares truncation with paid summaries.

Full-history, rolling-window and summary token totals for a 50-message chat
Tokens across one 50-message chat on a logarithmic scale. Derived from the editable workload model; provider documents and prices verified 2026-08-21.

Current API prices turn the same curve into four bills

We price standard synchronous API calls. DeepSeek uses its peak schedule so the table does not depend on when the chat runs. Gemini 3.7 Flash's shown rate applies through 2026-12-31.

API model                                                                    Input / 1M  Cache write / 1M  Cache hit / 1M                       Output / 1M
---------------------------------------------------------------------------  ----------  ----------------  -----------------------------------  -----------
[gpt-5.6-luna](https://vynaris.com/models#gpt-5-6-luna)                      $0.20       $0.25             $0.02                                $1.20
[Claude Haiku 4.5](https://vynaris.com/models#claude-haiku-4-5)              $1.00       $1.25             $0.10                                $5.00
[Gemini 3.7 Flash](https://vynaris.com/models#gemini-3-7-flash)              $0.75       Not listed        $0.075 plus $0.50/MTok-hour storage  $3.75
[DeepSeek-V4-Flash-0731](https://vynaris.com/models#deepseek-v4-flash) peak  $0.44       No separate line  $0.014                               $1.32

OpenAI and Anthropic both price a five-minute write at 1.25x base input and a read at 0.1x. DeepSeek's off-peak input, hit and output rates are half the peak rows: $0.22, $0.007 and $0.66 per million tokens.

Model                        Full history / 1,000 chats  Rolling eight  Summarize every eight  Best reduction
---------------------------  --------------------------  -------------  ---------------------  --------------
gpt-5.6-luna                 $34.000                     $23.120        $23.140                32.0% rolling
Claude Haiku 4.5             $163.000                    $108.600       $106.900               34.4% summary
Gemini 3.7 Flash             $122.250                    $81.450        $80.175                34.4% summary
DeepSeek-V4-Flash-0731 peak  $65.560                     $41.624        $39.292                40.1% summary

Put your actual token counts into the Vynaris calculator before changing architecture. The absolute dollars scale linearly with chat volume. The history multiplier does not care which model processes the request.

Truncation pays back on request 10

The rolling strategy sends the system prompt, the current user message and at most eight completed exchanges. Requests one through nine match full history. Request 10 would contain nine prior exchanges, so the window drops the oldest 400 tokens.

Across all 25 requests, rolling input is:

25 x (200 + 120) + 400 x [0 + 1 + ... + 8 + 16 x 8]
= 73,600 input tokens

The 7,000 response tokens do not change. Total volume becomes 80,600 tokens, 40.3% below full history. Dollar savings are smaller because output keeps its full price.

Truncation has no extra API call, so its financial break-even is immediate at request 10. Its semantic break-even is unknowable without an evaluation. If request 10 needs a promise made in exchange one, the saved 400 tokens bought a worse answer.

A 600-token summary repays itself in two or three requests

After exchange eight, the first summary reads 3,200 conversation tokens plus a 100-token instruction. It writes a 600-token summary. Requests nine through 16 send that summary instead of the 3,200 raw tokens, saving 2,600 input tokens on each chat request.

summary call cost
= 3,300 x input price + 600 x output price

savings per later request
= 2,600 x input price

At DeepSeek's 3:1 peak output/input price ratio, two later requests recover the summary call. Cumulative savings turn positive on request 10. The 5:1 ratios for Claude Haiku 4.5 and Gemini 3.7 Flash need three requests, so they cross on request 11. gpt-5.6-luna's 6:1 ratio also crosses on request 11.

We repeat the summary after exchanges 16 and 24. The three summarizer calls add 11,100 input and 1,800 output tokens. Even with that second bill, the final total is 71,700 tokens, 46.9% below full history.

The result is not “summaries always win.” On Luna, rolling history costs $23.120 per 1,000 chats and summaries cost $23.140. Expensive generated summary tokens cancel the lower input count. On DeepSeek peak pricing, summaries win by $2.332 per 1,000 chats because output costs only three times input.

Prompt caching changes dollars, not the token curve

Prompt caching discounts repeated prefixes when the provider records a cache hit. It does not make the prior messages disappear from usage accounting or the model's active context.

For OpenAI and Anthropic's listed rates, a write costs 0.25x more than ordinary input. The first successful read saves 0.9x. One read therefore recovers the write premium and leaves a net 0.65x-input saving for the reused prefix.

That is the price break-even, not a hit guarantee. Prefix eligibility, exact message ordering, expiry and provider routing still matter. Check the returned cached-token fields. Our production prompt-caching guide covers those controls and failure modes.

Caching and truncation solve different problems. Caching reduces the cost per token of a repeated prefix. Truncation reduces how many tokens remain in the prompt. A long cached chat can still hit a context limit or carry irrelevant instructions forward.

Stored conversation state does not erase the invoice

OpenAI's Responses API can chain turns with previous_response_id. That removes client-side history assembly. OpenAI's conversation-state documentation also states that prior input tokens in the chain remain billable.

Use stored state to simplify code. Do not book it as a context-cost reduction. Server-side compaction, explicit summaries and rolling windows change the content retained. A response ID alone changes how the content is referenced.

What this means for routing

Do context control before model routing. Sending 135,000 tokens to a cheaper model may cost less, but the quadratic shape remains. Cutting the workload to 71,700 tokens helps every eligible model and reduces pressure on latency and context capacity.

A practical policy has three checks:

  1. Keep verbatim messages that contain unresolved requirements or commitments.
  2. Summarize closed portions of the conversation and retain source-message IDs for recovery.
  3. Route only after the retained context passes a task-specific quality evaluation.

Do not route a summary to a weaker model merely because it is cheap. A factual omission can create retries that resend the whole conversation again.

Where this model can be wrong

Real messages are not flat. Code blocks, uploaded files and tool results can make one exchange larger than the other 24 combined. Reasoning-token billing can add output that is absent from this model. Tokenizers also produce different counts for the same text.

The summary is assumed to stay at 600 tokens and preserve all needed state. Neither is guaranteed. A strict support workflow may need verbatim audit history. A casual assistant may tolerate a four-exchange window.

The model also assumes every request succeeds once. Retries multiply the current request's full retained context. Measure accepted outcomes, not only the token line.

FAQ

Does a 50-message chat always cost 13.24x its transcript?

No. The multiplier follows the worked message sizes and 25-request sequence. Longer system prompts raise the repeated fixed cost. Larger late messages shift more content toward fewer re-sends. The script is the claim.

Should every chat keep only eight exchanges?

No. Eight is an editable cost scenario, not a quality recommendation. Pick the smallest window that passes an evaluation on your own conversations.

Is summarization better than truncation?

It preserves more semantic state in fewer tokens, but it adds a paid generation and can omit facts. In this model it is $0.020 per 1,000 chats more expensive than rolling history on Luna, yet $2.332 cheaper on DeepSeek peak pricing.

Does prompt caching prevent context-window overflow?

No. It can discount repeated input. The cached tokens still form part of the prompt presented to the model.

Sources