VynarisEarly betaGet your API key

Blog · 2026-07-17 · Vynaris Team

What a Cursor-style tab-completion feature costs per user per month

A heavy autocomplete user fires ~84,000 completions/month. On list prices that is $386/user on a frontier model, $8 on a cheap one. Full teardown, every assumption shown.

A heavy autocomplete user fires roughly 84,000 completions a month. On public list prices, serving that on a frontier model (gpt-5.6-sol) costs $386.40/user/month even with caching on. Route the same workload to a cheap model (deepseek-v4-flash) and it drops to $8.09 — 48x cheaper, and the only option that fits inside a $20/user/month plan. Prices verified 2026-07-17.

Tab-completion, the ghost text that finishes your line as you type, looks free. It is not. Every keystroke burst that survives debounce is an API call: a couple thousand tokens of surrounding code in, a line or two out. Do that thousands of times a day, multiply by a seat count, and the "small" feature becomes the biggest line on the inference bill. This is a public back-of-envelope from list prices. Every assumption is in a table you can edit; nothing here is measured from inside anyone's product.

The workload: autocomplete is an input problem

Start with what one completion actually sends. Around the cursor, an editor ships a window of code as context (imports, the current function, nearby files) so the model can predict the next line. Call it 2,000 [input tokens](/glossary/input-tokens). What comes back is tiny: a line, maybe two. Call it 30 [output tokens](/glossary/output-tokens).

That ratio is the whole story. At 2,000 in and 30 out, autocomplete is a 67:1 input workload. Output pricing barely moves the total; input pricing and how much of that input you can cache is everything. That is the opposite of a chat or [coding-agent](/blog/coding-agent-cost-per-task-6-models) workload, where long generated answers make output the expensive half.

Now volume. A developer who leans on autocomplete triggers it constantly, but most keystroke bursts get cancelled by debounce before they ever bill. We model a heavy user at 4,000 billed completions/day across 21 working days, or 84,000 requests/month. Light and heavy bands come later.

Editable assumptions

assumption                     value        note
---------------------------------------------------------------------
context in / request           2,000 tok    code window around the cursor
output / completion            30 tok       a line or two
prefix cache hit rate          70%          stable file/repo context
billed completions / day       4,000        heavy user (after debounce)
working days / month           21
=> requests / user / month     84,000
input : output ratio           67 : 1       autocomplete is an INPUT workload

Every number above is a dial. Halve the completions/day and you halve the bill. Drop the cache hit rate and watch the cheap model climb. That is the point of showing the table instead of a single headline figure: your real numbers slot straight in.

The prices (verified 2026-07-17)

Four small-to-mid models, list prices per 1M tokens, input / output / cache-read:

model              tier       input   output   cache-read
---------------------------------------------------------------
deepseek-v4-flash  plumbing   $0.14   $0.28    $0.0028
Claude Haiku 4.5   plumbing   $1.00   $5.00    $0.10
gpt-5.6-luna       plumbing   $1.00   $6.00    $0.10
gpt-5.6-sol        frontier   $5.00   $30.00   $0.50

Sources: DeepSeek, Anthropic, OpenAI, all re-fetched 2026-07-17. [gpt-5.6-sol](/models#gpt-5-6-sol) is on the list not because anyone should serve autocomplete from a frontier model, but because "just use our best model everywhere" is exactly the default that quietly produces a five-figure monthly bill.

Where caching comes in

A big chunk of that 2,000-token context is stable across requests: the same file header, the same imports, the same repo scaffolding. [Prompt caching](/glossary/prompt-caching) lets the provider charge the cheap cache-read rate for the repeated prefix instead of the full input rate. At a 70% [cache-hit](/glossary/cache-hit) rate, 70% of your input tokens bill at roughly a tenth (or, for deepseek, a fiftieth) of list.

The one-time cost to write the prefix into cache amortizes toward zero in steady-state autocomplete: you write it once and read it on nearly every subsequent keystroke, so we omit the write fee here. Where reuse is low that assumption breaks; see the caveats.

Effective input cost per request, cached:

eff_in = (1 - hit) * ctx * price_in  +  hit * ctx * price_cache_read

Feed the table through that and multiply by 84,000 requests.

Cost per user per month

Only a cheap model with caching keeps autocomplete under a $20 plan
Autocomplete cost per user per month at 84,000 completions, cached vs no-cache. List prices verified 2026-07-17.
model              tier       no-cache/mo   cached/mo   cache saves
-------------------------------------------------------------------
deepseek-v4-flash  plumbing   $24.23        $8.09       67%
Claude Haiku 4.5   plumbing   $180.60       $74.76      59%
gpt-5.6-luna       plumbing   $183.12       $77.28      58%
gpt-5.6-sol        frontier   $915.60       $386.40     58%

Two findings jump out. First, caching is not optional at this volume: it removes 58-67% of the bill across the board, because the workload is almost pure input and most of that input repeats. Second, the model choice dwarfs everything else. The gap between the cheapest and the most expensive cached option is 48x.

The routing delta

Serving autocomplete from the frontier tier versus the cheap tier, both cached:

gpt-5.6-sol   (frontier)  $386.40/user/mo
deepseek-v4-flash (cheap) $8.09/user/mo
-------------------------------------------
routing off the frontier: 48x cheaper -> $378.31/user/mo saved

That saving is per user, per month. At 100 seats it is $37,831/month ($454k/year) for a feature the user experiences identically, because autocomplete quality is about latency and prefix relevance far more than raw model horsepower. Even staying inside OpenAI's own line, [gpt-5.6-luna](/models#gpt-5-6-luna) at $77.28 is 5.0x cheaper than gpt-5.6-sol for the same completions. This is the textbook case for [model routing](/glossary/model-routing): a small, fast, cache-friendly model on the hot path, and the expensive one reserved for the rare requests that actually need it.

The $20 subscription test

Most coding tools sell a seat around $20/month. Put the autocomplete cost alone against that whole plan, before you count chat, agents, or margin:

deepseek-v4-flash  $8.09/mo    -> fits under $20
Claude Haiku 4.5   $74.76/mo   -> 3.7x OVER the whole plan
gpt-5.6-luna       $77.28/mo   -> 3.9x OVER the whole plan
gpt-5.6-sol        $386.40/mo  -> 19.3x OVER the whole plan

Only one option leaves room for everything else the product has to pay for. This is why the tools shipping autocomplete at scale run cheap, [right-sized](/glossary/right-sizing) models, often custom ones tuned for fill-in-the-middle, rather than renting a frontier model per keystroke. On list prices, a frontier model for autocomplete is not a pricing choice; it is a bankruptcy plan.

Sensitivity: it all bends on two dials

The headline uses a heavy user. Move the two dials that matter and the picture shifts predictably.

Usage intensity, cached $/user/month:

band     completions/day   flash    luna     sol
--------------------------------------------------------
light    1,500 (31,500/mo)  $3.03   $28.98   $144.90
medium   2,500 (52,500/mo)  $5.06   $48.30   $241.50
heavy    4,000 (84,000/mo)  $8.09   $77.28   $386.40

Cache hit rate (deepseek-v4-flash, heavy user):

hit rate    cost/user/mo
------------------------
0%          $24.23
50%         $12.70
70%         $8.09
90%         $3.48

The cheap model stays under $20 even for a heavy user at 0% cache hits ($24.23 is close, and any caching pulls it well under). The frontier model is over the $20 plan at every usage band, cache or no cache. No amount of debounce tuning rescues the wrong model choice.

The honest caveats

This is a list-price upper bound. Real numbers come in lower, sometimes much lower:

None of these change the conclusion. They change the magnitude of an already-lopsided result: the cheap-plus-cached corner is the only economically sane place to serve autocomplete, and the frontier corner is never close.

Run your own numbers

Swap in your context size, completions/day, and cache-hit rate and the whole table recomputes. The [cost calculator](/calculator) does the same arithmetic across every model on the [models page](/models), so you can price your exact autocomplete workload before you wire up a provider, and see the routing delta for your traffic, not ours.

FAQ

Why is output pricing almost irrelevant here?

Because autocomplete generates 30 tokens against 2,000 in, a 67:1 input:output ratio. Even at gpt-5.6-sol's $30/1M output, the 30 output tokens cost about $0.0009 per request. Input, not output, sets the bill.

Is 4,000 completions/day realistic?

It is a heavy user after debounce, not raw keystrokes. Light users land near 1,500/day. The sensitivity table covers the band; pick the row that matches your telemetry.

Does caching always pay off for autocomplete?

For steady-state autocomplete with a stable prefix, yes: reuse is high and the write cost amortizes away. For short-lived or highly variable context, the cache-write fee can outweigh the read saving. See [the break-even math](/blog/prompt-caching-break-even-2026).

Why include a frontier model at all?

To price the default. "Use our best model everywhere" is the reflex that produces the $386/user bill. Showing it next to the $8 alternative is the entire argument for routing.

Can I just use a bigger model and skip the tuning?

Not at this volume. gpt-5.6-sol is over a $20/seat plan at every usage band, cached or not. The model choice, not the tuning, decides whether autocomplete is affordable.

Sources

Related: [prompt caching in production](/blog/prompt-caching-in-production-2026) · [the 200k-token context cliff](/blog/context-window-long-context-surcharge-costs)