OpenRouter Pricing: Fees vs Direct API, Tested in 120 Calls

OpenRouter pricing looks simple on the model pages: the per-token price is the provider’s own list price, with no markup. The catch is what that sentence leaves out. You pay a 5.5% fee when you load credits, and for many models OpenRouter does not send your request to the company that made the model. It routes it to one of up to 30-odd hosts, at that host’s price. So on 13 October we ran the same WordPress chatbot conversations two ways, straight to the provider and through OpenRouter, from our own production server, and compared what each one billed.

The short version: for OpenAI and Google models, OpenRouter cost what the provider costs plus the 5.5% fee. For DeepSeek it was cheaper even after the fee, because most of our calls landed on third-party hosts running quantized copies of the model.

• GPT-6 Luna cost $0.410 per 1,000 two-turn conversations direct and $0.446 through OpenRouter, fee included: about 9% more. OpenRouter billed every Luna call at exactly OpenAI’s list price for the tokens used.
• DeepSeek V4.1 Flash cost $1.114 per 1,000 conversations direct and $0.684 through OpenRouter, 39% less with the fee. Twelve calls went to six different hosts, most of them priced at a third or less of DeepSeek’s own $0.30 per million input tokens, and several running fp4 or fp8 weights.
• Gemini 3.8 Flash was a wash: $9.02 direct, $9.18 through OpenRouter before the fee and $9.68 after it. Almost all of that bill is thinking tokens, which Google’s OpenAI-compatible endpoint leaves out of completion_tokens.
• Adding OpenRouter’s session_id made GPT-6 Luna 55% more expensive per conversation, because none of the first-turn requests reused OpenAI’s prompt cache. Without it, half of them did.
• Latency depended on the model: OpenRouter added about 0.9 seconds to a complete Luna reply, made no measurable difference on DeepSeek, and came back faster than our direct Gemini calls.

OpenRouter pricing in one table

OpenRouter charges in two places, and neither is on the per-token bill. The token price you see on a model page is the provider’s list price. The money OpenRouter keeps comes from buying credits, and from bring-your-own-key traffic above a large monthly allowance. We read the pricing page and the FAQ on 13 October 2026:

Two of those lines are worth slowing down for. The 5.5% fee applies to the money you load, so on a pay-as-you-go chatbot it is effectively a 5.5% surcharge on every reply. And the $0.80 minimum means small top-ups are taxed harder: $5 of credits costs $5.80, which is a 16% fee.

How we tested

Every call ran from the WordPress server that hosts this site, using the same API keys our own chatbot uses, so the requests left from an ordinary US shared host rather than a laptop. We built each request the way MxChat builds one when you pick OpenRouter as the provider: the bot’s system prompt with the retrieved knowledge base appended to it, then the visitor’s question, at temperature 1, with no provider preferences and no session key.

• Three visitor questions, each with about 4,000 tokens of knowledge base pulled from our own documentation: WooCommerce order lookups, whether the knowledge base needs Pinecone, and handing a visitor to a human on Slack or Telegram.
• Two turns per conversation. After the first answer, the visitor asks whether the feature is in the free plugin or needs MxChat Pro. The second turn resends everything from the first, which is where prompt caching should pay off.
• Three routes per model: direct to the provider’s API; OpenRouter exactly as MxChat sends it; and OpenRouter with a session_id, the field OpenRouter documents for keeping one conversation on one host so its cache stays warm.
• Three models a WordPress site might run a chatbot on: OpenAI’s GPT-6 Luna ($0.10 in / $0.50 out per million tokens), DeepSeek V4.1 Flash ($0.30 / $1.20 on DeepSeek’s own API) and Google’s Gemini 3.8 Flash ($0.75 / $3.75).
• Two runs of everything: 6 conversations and 12 calls per model and route, 108 calls. We then reran the 12 direct Gemini calls to capture total_tokens, for 120 calls in all. All 120 returned HTTP 200; 119 on the first attempt and one after a single retry.

For direct calls we priced the tokens each API reported at the provider’s published rates, including cached-input and cache-write rates. For OpenRouter calls we used the cost field OpenRouter returns in each response’s usage block, then added the 5.5% card fee on top. As a check, we recomputed OpenRouter’s Luna and Gemini charges from the reported tokens at the providers’ list prices: they matched to a fraction of a cent.

The results, route by route

A conversation here is one question plus one follow-up, each carrying about 4,100 to 4,300 input tokens. A cache hit means the API reported some cached input tokens on that call. Six conversations per row is a small sample: the per-token billing is exact, but the cache and latency columns will move from run to run.

GPT-6 Luna: list price, plus the fee

For OpenAI models OpenRouter behaves like a reseller with a card fee. All 24 of our Luna calls through OpenRouter were served by OpenAI itself and billed at OpenAI’s list rates for the input, cached-input, cache-write and output tokens the response reported. Over a full conversation that came to $0.423 per 1,000 against $0.410 direct, a 3% gap that sits inside the noise of how long each answer happened to be. The 5.5% credit fee is the real difference, and it takes the total to about 9% above going direct.

Caching behaved the same on both routes when we sent the request the way MxChat does. Every follow-up reused the cached first turn, and half of the first turns reused the system prompt cached by the conversation before. The plain OpenRouter route gave up nothing on caching.

The session key did. With session_id set, not one first-turn Luna request reported cached tokens, against 3 of 6 without it, and the conversation cost rose from $0.423 to $0.655 per 1,000. Follow-ups still hit the cache. Our best explanation, which we have not confirmed with OpenRouter, is that the session key also partitions OpenAI’s cache, so each new conversation starts cold instead of sharing the system prompt every conversation on the site has in common. Whatever the mechanism, the practical advice for OpenAI models is the same: do not add a session key to save on caching. OpenAI’s own cache routing already does that job.

DeepSeek V4.1 Flash: cheaper, because someone else served it

DeepSeek is where OpenRouter’s routing changes the bill. OpenRouter lists 32 endpoints for DeepSeek V4.1 Flash, from $0.044 to $0.60 per million input tokens, and the model page shows the cheapest of them. DeepSeek’s own endpoint is one of the 32, at $0.30. With no preferences in the request, OpenRouter spread our 12 calls across six hosts, none of them DeepSeek: Wafer, CoreWeave, InferenceNet, Relace, Decart and OpenInference.

OpenRouter billed those 12 calls $0.00389. The same tokens at DeepSeek’s own rates would have cost $0.01057, so the routed price was 63% lower before the fee. Over a full conversation, with the fee, the saving was 39%: $0.684 per 1,000 conversations against $1.114 direct. The gap is smaller than the token prices suggest because DeepSeek’s own API cached our repeated system prompt on 5 of 6 first turns, while hopping between hosts on OpenRouter cached it on 2.

The trade-off is in the brackets on the chart. Two of the hosts that served us run the model at fp4 and two at fp8; three do not disclose a quantization. A quantized copy is a smaller, cheaper version of the same weights, and it can answer slightly differently from DeepSeek’s own deployment. We read the answers side by side and could not tell the routes apart: on the Pinecone follow-up, for example, every DeepSeek route said the knowledge base is part of the free plugin, and most added that the Migration Tool is a Pro add-on. That is a spot check, not a quality benchmark. If your bot answers precise questions about prices, policies or stock, test it on the hosts you will actually get.

Adding session_id did what OpenRouter says it does on DeepSeek. Each conversation stayed on one host (DigitalOcean for three, InferenceNet for two, Wafer for one) and every follow-up hit that host’s cache, 6 of 6 against 4 of 6 without it. It still cost slightly more per conversation, $0.718 against $0.649, because sticking to a host also meant sticking to DigitalOcean’s higher price for half the sample.

You can control the routing per request. OpenRouter accepts a provider object: order with allow_fallbacks: false pins a host such as DeepSeek itself, quantizations excludes fp4 hosts, and sort: "price" asks for the cheapest. MxChat does not send any of these today, so a site using MxChat with OpenRouter gets OpenRouter’s default load balancing.

Gemini 3.8 Flash: the same bill either way, and a hidden token count

All 24 Gemini calls through OpenRouter were served by Google, at Google’s list price, and the totals landed within 2% of each other before the fee: $9.18 per 1,000 conversations through OpenRouter, $9.02 direct. Gemini 3.8 Flash thinks by default, and thinking is most of the cost. A typical first answer was about 60 words of visible text on top of roughly 470 thinking tokens billed as output.

The trap is in how those tokens are reported. On Google’s OpenAI-compatible endpoint, completion_tokens counted only the visible answer: about 60 tokens on a first turn. The thinking tokens appeared only in total_tokens. Our first pass priced the direct calls from completion_tokens and came out at $6.79 per 1,000 conversations, which made going direct look 26% cheaper than OpenRouter. It was a quarter too low; the real figure, with thinking tokens, is $9.02. OpenRouter, by contrast, counts thinking inside completion_tokens and reports it separately as reasoning tokens. If you track chatbot costs from Gemini’s OpenAI-compatible responses, price output as total_tokens minus prompt_tokens.

Caching was patchy on both routes. Direct calls picked up Google’s implicit cache on 4 of 6 first turns and none of the follow-ups; through OpenRouter, 1 call in 24 reported cached tokens. Gemini’s cache entries live for a few minutes, so a busy site will see more hits than our small test did.

Speed

OpenRouter is an extra hop, and on GPT-6 Luna it showed: the median complete reply took 2.68 seconds through OpenRouter against 1.82 seconds direct. On DeepSeek the two routes were level, which is what you would expect when OpenRouter’s hosts are at least as fast as DeepSeek’s own. Gemini was faster through OpenRouter, 4.67 seconds against 6.25, but the direct Gemini calls ran later in the session and their thinking varied, so we would not read that as OpenRouter speeding Gemini up. Visitors see the first words sooner when replies are streamed, so all of these numbers overstate the wait a visitor feels.

What the 5.5% fee costs on a small site

Because the fee is charged on credit purchases, the size of each top-up matters more than the percentage. The $0.80 minimum means any top-up under about $14.55 pays more than 5.5%:

For a typical small WordPress chatbot the absolute numbers are tiny. At 3,000 two-turn conversations a month, our measured rates come to about $1.23 a month on GPT-6 Luna direct and $1.34 through OpenRouter, or $3.34 on DeepSeek direct and $2.05 through OpenRouter. A $20 top-up would last a Luna site more than a year, which runs into the other line in OpenRouter’s FAQ: it reserves the right to expire unused credits a year after purchase. Top up in amounts you will spend.

There is a way to keep OpenRouter’s single integration without the fee. With bring-your-own-key, you add your own OpenAI, Google or DeepSeek key to OpenRouter and the provider bills you directly. OpenRouter charges nothing on the first $25,000 of list-price inference a month and 5% above that, which no small site will reach.

When OpenRouter is worth it for a WordPress chatbot

Using OpenRouter with MxChat

MxChat supports OpenRouter as a chat provider alongside direct OpenAI, Anthropic, Google, DeepSeek and xAI keys. You paste an OpenRouter key into the API key settings, pick OpenRouter as the model, and then choose any model from OpenRouter’s catalogue. Requests go out exactly as we tested them above: system prompt plus knowledge base, then the conversation, with no session key and no provider preferences, so OpenRouter’s default load balancing decides who serves each reply. Knowledge-base embeddings are separate and still use your OpenAI, Voyage or Gemini key. Setup is covered in the MxChat documentation, and the add-ons and paid plans are on the MxChat Pro page.

If you are choosing the model rather than the route, our measured posts on GPT-6 Luna pricing and reasoning effort, DeepSeek V4.1 Flash pricing and Gemini 3.8 Flash and its thinking tokens go further on each one. Our OpenAI prompt caching test explains the cache-write charge that shows up in every Luna row above, and the Mistral Large 4 test was run entirely through OpenRouter.

FAQ

Does OpenRouter charge more than OpenAI?

Not per token. OpenRouter billed our GPT-6 Luna calls at exactly OpenAI’s list price. You pay 5.5% more overall because of the fee on buying credits ($0.80 minimum), which put our Luna conversations about 9% above going direct.

Is OpenRouter cheaper than the provider’s own API?

Sometimes. For open-weight models served by many hosts, OpenRouter’s default routing often picks hosts that charge less than the lab. DeepSeek V4.1 Flash cost us 39% less through OpenRouter, fee included. For closed models served only by their maker, it costs the same plus the fee.

What is OpenRouter’s fee?

5.5% on credit purchases by card on the Standard plan, with a $0.80 minimum, and 8% on the Business plan. Inference itself is not marked up. Bring-your-own-key traffic is free up to $25,000 of list-price usage a month, then 5%.

Can I run a website chatbot on OpenRouter’s free models?

Only for testing. Free models are limited to 20 requests a minute and 50 a day, or 1,000 a day once you have bought at least $10 of credits. A chatbot that answers a few dozen visitors a day would hit the lower cap by lunchtime.

Does prompt caching work through OpenRouter?

Yes. In our test OpenAI’s caching worked exactly as it does direct. For models served by many hosts, each host has its own cache, so OpenRouter’s session_id helps by keeping a conversation on one host; on DeepSeek it lifted follow-up cache hits from 4 of 6 to 6 of 6. On GPT-6 Luna the same field stopped first-turn cache hits entirely and raised the cost 55%, so use it only for multi-host models.

Is OpenRouter slower?

It adds a hop. On GPT-6 Luna the median complete reply was 0.86 seconds slower through OpenRouter; on DeepSeek V4.1 Flash it was no slower. Streaming the reply hides most of the difference from visitors.