The Ultimate Guide to Running Your Own AI Interface

Estimated reading time at 200 wpm: 35 minutes

Why Run Your Own AI Interface? What if I said that you could access over 400 AI models, and chop and change as you like for as little as $5 USD to start off. And that could last you a month! You might think – as paranoid as you are – that I’m selling something. I am not! Did you know that there a free and almost free AI models available right now that are almost as good as the frontier models like ChatGPT and Claude.ai?

Most people use AI through a provider’s website. You go to ChatGPT or Claude, type your question, and get an answer. The provider controls everything: which models you can use, how much context the model can see, what happens to your data, and what you pay. You get convenience. You give up control. If you don’t use your $20 to $30 (USD) per month, you lose it and get billed for the next month. If you overrun your allocation – tough – you are cut off, forced to use a cheaper model or stop working.

What if you could pay for what you actually use and come in several times cheaper for better quality and greater throughput?

If that interests you, there is another way. So for the cost of your time reading this guide, you could keep circa $300 to $500/yr in your pocket. You can run your own front end — a user interface on your own machine — and connect it to whichever AI models you choose. OpenWebUI is one such front end. It is a web-based application that runs inside a Docker container (a self-contained package that bundles an application with everything it needs to run, so it behaves the same on any machine). You access it through your browser, just like ChatGPT. But it runs locally, on your hardware.

From there, you decide where the thinking happens. You can connect to a remote API (Application Programming Interface — a structured way for your local software to send requests to a remote server and receive responses). DeepSeek, OpenAI, Anthropic, and others all offer APIs. You send your text out; their servers process it; the response comes back. Alternatively, you can run a model locally using tools like Ollama, where the processing never leaves your machine at all. Or you can mix both — different models for different tasks. But there is another way – read on. How about just one API key to access hundreds of AI models? If you rush through to the OpenRouter novel solution way down the page in Heading 8, you may not get the full knowledge about how to keep cost in check.

Why would you bother? Three reasons stand out.

Choice. A subscription to ChatGPT locks you into OpenAI’s models. With your own interface, you can switch between providers mid-conversation. Use a cheap, fast model for routine tasks. Use a powerful one when precision matters. Add a new provider when a better model appears. Nothing is locked in.

Visibility. When you use ChatGPT’s web interface, you have no idea what is happening behind the scenes. How many tokens (the basic units of text that the model processes — covered in the next section) did that request actually consume? What did the full request look like before it reached the model? With your own interface, you can inspect all of this. You can see exactly what you are paying for.

Cost. AI subscriptions in the UK typically cost £16–20 per month for a single provider. If you use three providers, that is £50–60 monthly. API pricing works differently — you pay only for what you use, measured in tokens. For many users, especially those who are not running queries every hour of the day, the API route is significantly cheaper. But only if you understand what drives the costs. That is what the rest of this guide is about. You have lots of reading to do! Stick around and learn, first about the ‘mechanics’ of AI.

1. What Are Tokens and Why Do They Cost Money?

When you type a message to an AI model, the model does not read your words the way you do. It breaks your text into tokens — small fragments of text, usually pieces of words rather than whole words. The word “understanding” might become three tokens: “under”, “stand”, and “ing”. Short common words like “the” or “is” are usually one token each. A rough guide: one token is about four characters of English text, or roughly three quarters of a word.

This chopping process is called tokenisation. It happens before the model does any thinking. Your sentence becomes a sequence of numerical IDs, each representing one token. These IDs are then mapped to embeddings — mathematical representations that capture something about what each token means and how it relates to other tokens. This is how the model turns your plain English into something it can work with.

Why should you care about any of this? Because tokens are the unit you are billed for.

When you use a provider’s API, you pay per token. Not per message, not per conversation — per token. And you pay twice: once for the input tokens (everything you send to the model, including your question, any background instructions, and any documents you have included) and once for the output tokens (everything the model generates in reply). Input tokens are typically cheaper than output tokens, because generating new text is more computationally demanding than reading existing text.

To give you a sense of scale: this section you are reading now is roughly 900 words. That is about 1,200 tokens. At DeepSeek V4 Flash’s current rates, sending that as input would cost a fraction of a penny. The costs are small per request. They add up over thousands of requests, and they add up fast when you start including large documents — which is exactly what many users want to do.

There is one more concept you need before moving on: the context window. This is the total number of tokens a model can hold in its working memory at one time. It includes everything — your system prompt (standing instructions that shape the model’s behaviour), the conversation history from earlier turns, any documents or retrieved text, and the model’s own reply. Think of it as a desk. Everything the model is working with has to fit on that desk. When the desk is full, something has to come off before anything new can go on. DeepSeek’s current models offer a context window of one million tokens. That is a very large desk. But a long conversation with large documents attached can fill even that.

The rest of this guide is about what lands on that desk, how much of it you are paying full price for, and what you can do about it.

2. How the Pieces Fit Together

When you use ChatGPT’s website, everything happens somewhere else. Your browser is just a window onto OpenAI’s servers. You type, the text goes to them, the reply comes back. You have no idea what sits between your words and the model’s response.

With OpenWebUI, the work is split between your machine and the provider’s servers. Understanding who does what is worth a few minutes of your time, because it determines what leaves your machine, what stays private, and where you have room to make things more efficient.

Your machine runs three things. First, the interface itself — OpenWebUI, running inside a Docker container on your computer, served through your browser on a local address like localhost:3000. This is what you see and interact with. Second, text extraction — when you upload a PDF or a Word document, your machine pulls the raw text out of that file. The document never leaves your computer for this step. Third, the embedding model — a small, specialised model that converts text into numerical representations used for document retrieval. More on this in the next section. The key point: the embedding model typically runs locally. It is a different model from the one that generates your replies.

The provider’s servers do the heavy lifting. When you send a message, OpenWebUI packages everything up — your instructions, any document context, the conversation history, and your question — into a structured API request (a JSON payload, which is a standard text format for sending structured data between systems). That package travels over the internet to the provider. Their hardware runs inference (the process of the model reading your input and generating a response). The reply travels back. Your machine displays it.

This split means two things you should keep in mind going forward.

First, the thinking is remote but the preparation is local. Your machine decides what goes into the package. How it assembles that package — what it includes, in what order, and how much — directly affects what you pay and how well the provider’s cost-saving mechanisms work. Much of this guide is about getting that assembly right.

Second, everything in that package crosses the internet. If you upload a sensitive document and your setup sends the full text to an external API, that text is now on someone else’s servers. The provider processes it, may cache parts of it temporarily for efficiency, and their data retention policies apply. This is not a reason to avoid the setup. It is a reason to know exactly what you are sending and to whom. Section 9 covers this in detail.

3. What Happens When You Upload a Document

Uploading a document to OpenWebUI is one of the first things most people try. You have a PDF — a report, a contract, a set of guidelines — and you want the model to read it and answer questions about it. Simple enough in principle. What happens behind the scenes is worth understanding, because it directly affects the quality of the answers you get and what you pay for them.

The first step is text extraction. Your machine pulls the raw text out of the PDF. This happens locally — the file itself is not sent anywhere at this stage. A 130KB PDF might yield 50 to 80 kilobytes of actual text once the formatting overhead is stripped away. In token terms, that is roughly 12,000 to 25,000 tokens, depending on the density of the content. Not a trivial amount, but well within a modern model’s capacity.

What happens next depends on a choice OpenWebUI gives you. There are two paths, and they work very differently.

Path one: chunked retrieval (the default). OpenWebUI breaks the extracted text into chunks — smaller segments, typically around 1,000 tokens each. Each chunk is then processed by the embedding model (that small, usually local model mentioned in the previous section) to create a numerical fingerprint of its meaning. These fingerprints are stored in a vector database (a specialised store designed to find text by meaning rather than by exact keyword match). When you ask a question, your question is also converted into an embedding, and the system retrieves the chunks whose fingerprints are closest in meaning to your query. Only those chunks — not the entire document — are sent to the remote model along with your question.

This process is called RAG (Retrieval Augmented Generation). The name describes exactly what it does: it augments the model’s generation by retrieving relevant context first. With a typical configuration — say, five chunks of 1,000 tokens each — you are sending roughly 5,000 tokens of document context per request. Not 25,000. The saving is obvious.

The trade-off is precision. The system is guessing which chunks are relevant to your question. Sometimes it guesses well. Sometimes the answer spans two chunks that the retrieval did not connect, or sits in a chunk that did not score highly enough. You may get incomplete or slightly off-target answers — not because the model is incapable, but because it never saw the relevant text.

Path two: full context injection. You can toggle this per file in OpenWebUI. When enabled, the entire extracted text is sent to the model with every message. No chunking, no retrieval, no guessing. The model sees everything. For a single document under fifty pages with a large-context model like DeepSeek V4, this often produces better answers because there are no retrieval gaps.

The trade-off is cost and capacity. Every turn of the conversation includes the full document. If the document is 20,000 tokens and you have a ten-turn conversation, you are sending that same 20,000 tokens ten times. As you will see in Section 6, caching can reduce the cost of those repeated tokens dramatically — but only if the setup is right.

Which path should you choose? There is no universal answer. For a short, dense document where every section might be relevant — a contract, a clinical guideline, a legal statute — full context usually wins. For a large collection of documents or a lengthy report where your questions target specific sections, chunked retrieval makes more sense. The point is that this is a decision you should make deliberately, not one you should leave to the default without understanding what the default does.

4. What Happens When You Send a Message

You type a question and press Enter. From your perspective, one thing happens: you get a reply. Behind the scenes, quite a lot more is going on. Understanding the full picture is the single most useful thing you can learn about controlling your costs.

The main request

When you press Enter, OpenWebUI assembles a structured package of text and sends it to the provider’s API. That package is not just your question. It contains several layers, stacked in a specific order.

At the top sits the system prompt — a set of standing instructions that tell the model how to behave. This might be as simple as “You are a helpful assistant” or as detailed as a page of rules about tone, format, and what to include. If you have configured a custom system prompt for your model in OpenWebUI, its full text is sent with every single request.

Below that comes any injected context. If you have uploaded a document, this is where the document text appears — either as a handful of retrieved chunks (if you are using RAG) or as the full extracted text (if you are using full context mode). If OpenWebUI’s Memory feature is enabled (a store of persistent facts the model has learned about you across conversations), those stored facts are also injected here. If you have Tools enabled (plugins that give the model extra capabilities, such as web search or code execution), their definitions are included too, so the model knows what tools are available and how to call them.

Next comes the conversation history — every message you have sent and every reply the model has generated in the current conversation, from the very first turn to the one just before your latest. On turn one, this is empty. By turn ten, it may be thousands of tokens. By turn thirty, it can be substantial.

Finally, at the bottom, sits your actual message. The thing you just typed.

All of these layers are bundled into a single API request and sent to the provider’s servers. The model processes the entire bundle as one continuous sequence of tokens. You are billed for every token in that bundle — system prompt, context, history, and your question — as input tokens. The model’s reply is billed separately as output tokens.

This means a short question like “What does clause 7 say?” is never really a short request. By the time the system prompt, the document context, and fifteen turns of conversation history are included, your five-word question might be riding on top of 30,000 tokens of input. You pay for all of them.

The requests you do not see

Here is where it gets interesting. Your one press of the Enter key does not always produce one API call. By default, OpenWebUI triggers several background tasks alongside your main request.

Title generation fires on your first message in a new conversation. OpenWebUI sends a separate API call asking the model to generate a short title for the chat. Tag generation does the same — another call to produce category tags. If follow-up question suggestions are enabled, that is another call. If autocomplete is active in the input box, the model may be called with every few keystrokes as you type.

Each of these background calls sends its own bundle of tokens to the API. And here is the part that catches people out: by default, these tasks use the same model you are chatting with. If you are using DeepSeek V4 Pro for your main work, your title generation — a task that needs no more intelligence than a pocket calculator — is also running on DeepSeek V4 Pro, at DeepSeek V4 Pro rates.

The fix is straightforward. In OpenWebUI’s admin settings, under the Tasks section, you can assign a separate task model — a smaller, cheaper model dedicated to these housekeeping jobs. You can also disable any background features you do not need. Title generation is useful. Tag generation may not be. Follow-up suggestions are a matter of taste. Each one you disable is one fewer API call per turn.

The real cost of a conversation

Take a practical example. You upload a 20,000-token document using full context mode. Your system prompt is 500 tokens. You have a ten-turn conversation. By the tenth turn, the conversation history contains roughly 5,000 tokens of your questions and the model’s replies. Each request is now sending approximately 25,500 input tokens. Over ten turns, you have sent around 200,000 input tokens in total — the document alone accounting for most of that, repeated ten times.

Add the background calls. Title generation on turn one. Tags on turn one. Perhaps follow-up suggestions on every turn. That could be another 30,000 to 50,000 tokens, depending on configuration.

This is not meant to alarm you. As the next section explains, providers have mechanisms that dramatically reduce the cost of those repeated tokens. But those mechanisms only work if the structure of your requests stays stable. And that is where configuration starts to matter.

5. How Providers Keep Your Costs Down

By now you might be thinking this sounds expensive. Every turn of a conversation sends the system prompt, the document context, and the entire conversation history — all billed as input tokens. A ten-turn conversation with a 20,000-token document could mean 200,000 input tokens before you have even considered the replies. At full price, that adds up.

Providers know this. They also know that most of those tokens are identical from one turn to the next. Your system prompt does not change between turns. Your document does not change. The conversation history from turns one through nine is exactly the same when you send turn ten as it was when you sent turn nine — just with one more exchange appended at the end. Reprocessing all of that from scratch every time would be wasteful for everyone.

This is where prompt caching comes in.

How it works

DeepSeek uses a mechanism called automatic prefix caching. The principle is straightforward. When the API receives a request, it looks at the sequence of tokens starting from the very beginning of the payload. If it recognises that sequence from a recent request — because it has stored the computational results from processing those tokens before — it retrieves those stored results instead of recomputing them. This is called a cache hit. The stored results are kept on disk (DeepSeek calls this “Context Caching on Disk”), not in high-speed GPU memory, which is part of what makes the discount so large.

The word “prefix” is critical. The matching starts at the very first token and continues for as long as the sequence is identical to what was cached. The moment a token differs from the cached version, the match stops. Everything after that point is a cache miss and is processed from scratch at the full rate.

Think of it like a book the provider has already read. If you hand them the same book with one new page added at the end, they do not re-read the whole book. They pick up where the new material starts. But if you change a word on page one, they have to start over from the beginning — even if the rest of the book is unchanged.

What it costs

Cache hits are not free, but they are close. The provider still has to retrieve the stored results from disk and load them into the processing pipeline. That incurs a small charge. How small depends on the model.

To put concrete figures on this (current as of August 2026 — check DeepSeek’s pricing page for the latest rates):

For DeepSeek V4 Flash, input tokens that hit the cache cost $0.0028 per million tokens. Input tokens that miss the cache cost $0.14 per million tokens. That is a 98% discount on cached tokens. Output tokens — the model’s reply — cost $0.28 per million tokens regardless of caching, because output is always freshly generated.

A worked example

Take the scenario from the previous section. You upload a 20,000-token document using full context mode. Your system prompt is 500 tokens. You have a ten-turn conversation. Each of your messages averages 50 tokens, and each reply averages 400 tokens.

Turn one. The payload contains: system prompt (500) + document (20,000) + your message (50) = 20,550 input tokens. Nothing has been cached yet. This is all a cache miss. The model replies with 400 output tokens.

Turn five. The payload now contains: system prompt (500) + document (20,000) + four previous exchanges (4 × 450 = 1,800) + your message (50) = 22,350 input tokens. If the prefix is stable — if the system prompt and document sit in exactly the same position with exactly the same content — then 20,500 tokens hit the cache. Only the new conversation history and your latest message (roughly 1,850 tokens) are a cache miss.

Turn ten. The payload is: system prompt (500) + document (20,000) + nine previous exchanges (9 × 450 = 4,050) + your message (50) = 24,600 input tokens. The cached prefix is now larger — it includes the earlier conversation history from turns that have not changed. Roughly 22,550 tokens hit the cache. About 2,050 are a cache miss.

Over ten turns, with caching working properly, the total input token cost on V4 Flash works out to roughly $0.004 — less than half a penny. Without caching — if something in your configuration had broken the prefix on every turn — the same conversation would cost roughly $0.03. Still modest in absolute terms, but seven to eight times more expensive. Scale that up to dozens of conversations a day over weeks and the difference becomes real money.

The catch: “best effort”

DeepSeek describes its caching as “best effort.” There is no guarantee that any particular request will hit the cache. Cache entries are stored on disk and expire after a period — typically hours to days, depending on server load. If you leave a conversation idle overnight and return the next morning, the cache may have cleared. Your next turn will be a full cache miss, even if nothing in the payload has changed.

The first repeat of a prefix is also not always enough to trigger caching. In some cases, DeepSeek needs to observe two requests with the same prefix before it persists a cache entry for that sequence. This means the second turn of a new conversation may still miss, with the discount kicking in from the third turn onwards.

None of this changes the strategy. Structuring your payload for stable prefixes is still the right thing to do. It just means you should verify rather than assume. The next section covers what can break the cache. Section 8 shows you how to check whether it is actually working.

6. What Breaks the Cache

The previous section showed how prefix caching can cut your input costs by 98%. It also showed that the discount depends entirely on one thing: the beginning of your API payload must be identical from one turn to the next. Token for token, from the very first one, with no variation.

In practice, several things can break that sequence without you realising. Most of them are OpenWebUI features that are either enabled by default or easy to turn on without understanding the consequences. None of them are bad features. They just need to be understood.

Dynamic variables in the system prompt

If your system prompt contains placeholders that change with every request — a current date stamp, a time, a username injected automatically — then the very first tokens in the payload are different every time. The cache cannot match a prefix that keeps changing. A system prompt that reads “You are a helpful assistant. Today’s date is 27 August 2026” will produce a different token sequence tomorrow. The entire cached prefix is lost — not just for the date line, but for everything that follows it, including your 20,000-token document.

The fix is simple: keep your system prompt static. If you need the model to know the date, put that information in your message at the end, not in the standing instructions at the top.

Memory injections

OpenWebUI’s Memory feature stores facts about you across conversations — your preferences, your name, things you have told it to remember. When enabled, these stored facts are injected into the prompt payload. If they appear before your document text, they become part of the prefix. Every time a new memory is added or an old one changes, the prefix shifts and the cache breaks.

This is not hypothetical. If you have Memory enabled and you tell the model something new about yourself mid-conversation, the next turn may inject an updated memory block, altering the prefix and forcing a full cache miss on everything downstream.

Tool definitions

When Tools are enabled for a model — web search, code execution, or any custom tools — their definitions are included in the payload so the model knows what capabilities it has. These definitions describe each tool’s name, purpose, and parameters. If you add, remove, or reorder tools between turns, the prefix changes.

In practice, tools tend to stay stable within a conversation. But if you are experimenting with different tool configurations across sessions, be aware that each configuration produces a different prefix.

RAG context shifting position

This one is subtle and specific to chunked retrieval (RAG). When you ask a question, OpenWebUI retrieves the most relevant chunks from your document and injects them into the payload. When you ask a different question on the next turn, it retrieves different chunks — or the same chunks in a different order. The injected context has changed. If that context sits within the prefix, the cache breaks.

Where RAG context is injected matters. By default, OpenWebUI injects retrieved content into the user message. As conversation history grows, each new turn pushes earlier messages — including their injected RAG content — further up the payload. The prefix grows, but it grows with content that was specific to earlier queries. If the next request reconstructs that history with even slightly different retrieval results, the prefix is no longer identical.

Full context mode avoids this problem entirely. The document text is the same every time, injected in the same position. This is one of the reasons full context mode pairs well with caching for single-document work.

Context Compaction

You may have noticed this setting in your admin panel: “Summarise older chat history when the conversation context grows large.” When enabled, OpenWebUI will automatically compress earlier parts of the conversation history to keep the total payload within the model’s context window.

The compression changes the token sequence. What was previously a verbatim record of turns one through five becomes a summary. The prefix that the cache had stored no longer matches. Every token after the summarised section is a cache miss.

Context Compaction is useful when you are hitting context window limits in very long conversations. But it is directly opposed to prefix caching. You cannot have both. If cost efficiency through caching is your priority, leave this switched off and manage conversation length yourself — by starting a new chat when a conversation gets unwieldy, rather than relying on automatic compression.

The common thread

Every one of these issues has the same root cause: something changed in the early part of the payload between one turn and the next. The cache does not care why it changed. A single different token at position 100 invalidates the cache for positions 101 through 25,000, even if all of those later tokens are identical to what was cached.

The principle is worth stating plainly: put things that never change at the top. Put things that change on every turn at the bottom. Your system prompt should be static. Your document should come next. Dynamic content — conversation history, your latest message — belongs at the end. The more stable material you can keep at the front of the payload, the more of it the cache can cover.

7. Keeping It Lean

The previous sections explained how the system works and what can go wrong. This section is about what to do about it. These are practical steps you can take in your OpenWebUI instance to keep token usage efficient and caching working in your favour.

Set a dedicated task model

This is the single easiest cost saving available to you. By default, every background task — title generation, tag generation, follow-up question suggestions, retrieval query rewriting, web search query generation — uses the same model you are chatting with. If you are running DeepSeek V4 Pro for your main work, those throwaway tasks are running on V4 Pro too.

In your admin panel, under Experience > Interface, the very first section is labelled “Tasks.” You will see two dropdowns: Local Task Model and External Task Model. Both will say “Current Model” unless you have changed them. Set the External Task Model to something cheap or free. A lightweight model with minimal capability is all these jobs need — they are generating three-word titles, not analysing contracts.

While you are there, look at the toggles below. Title Generation and Tags Generation are enabled by default. Follow Up Generation too. Decide which of these you actually use. Every one you disable is one fewer API call per turn.

Disable what you do not need per model

In the model editor (Admin > Models), each model has capability toggles. If you are not using web search on a particular model, switch it off. If you are not uploading files to a particular model, switch File Upload off. Each enabled capability adds tool definitions to the payload — and tool definitions sit in the prefix. Fewer tools means a smaller, more stable prefix.

Be deliberate. A model you use for document analysis needs File Upload on and probably Tools off. A model you use for general conversation might need neither. Configuring each model for its actual purpose, rather than leaving everything enabled, keeps payloads tight.

Choose your document mode deliberately

Do not rely on the default upload mode without understanding what it does. In your admin panel, the Default Upload Mode setting (under Experience > Interface > File) determines whether uploaded files use focused retrieval (RAG) or full context injection by default. You can also toggle this per file after uploading it.

For single-document work with a large-context model, full context mode usually produces better answers and pairs well with prefix caching. For multi-document work or very large files, chunked retrieval keeps the payload manageable.

The wrong default wastes money or degrades quality. If you mostly work with single documents under fifty pages, setting the default to full context and switching to focused retrieval when you need it is a reasonable starting point.

Keep your system prompt static

If you have written a custom system prompt for a model, check it for anything dynamic. Dates, times, usernames, session-specific references — anything that changes between turns will break the prefix cache. Move variable information into your messages instead.

A good system prompt is one you could send a thousand times without changing a word. That is what makes it cacheable.

Manage conversation length yourself

Long conversations accumulate tokens. With caching working, the cost of repeated history is heavily discounted. But the context window is still finite. When a conversation grows to the point where you are nearing the limit, start a new chat rather than relying on Context Compaction. Compaction saves space but destroys the cache. A fresh conversation with the same document attached gets the best of both — a clean payload with a cacheable prefix.

There is no hard rule for when to start fresh. If you notice responses becoming less focused or if the model starts losing track of earlier context, that is usually a sign the window is getting crowded.

Turn off Memory for document analysis

OpenWebUI’s Memory feature injects stored personal facts into your prompt. For general conversation, this is useful — the model remembers your preferences. For focused document analysis, it is noise. Those injected memories sit in the prefix, they change whenever a new fact is stored, and they add tokens that have nothing to do with the document you are working on.

If you have a dedicated workspace model for document analysis, disable Memory on that model specifically. Your general-purpose model can keep it on.

Verify that caching is actually working

Everything above is preparation. The proof is in the numbers. When DeepSeek’s API returns a response, it includes a usage object in the JSON payload (the structured data that comes back with every reply). Two fields tell you what you need to know:

• prompt_cache_hit_tokens — the number of input tokens that were served from the cache at the discounted rate.
• prompt_cache_miss_tokens — the number of input tokens that were processed from scratch at the full rate.

On the second or third turn of a conversation with a stable prefix, the hit number should be large and the miss number should be small — roughly equal to the new tokens added since the last turn. If the hit number is zero, something is breaking your prefix. Go back through the list above and check each item.

OpenWebUI does not show these fields natively in the chat interface, but community plugins exist that display token usage and cost breakdowns beneath each response. The “Token Usage & Cost Display” plugin is one such option. Installing it gives you visibility without needing to inspect raw API responses.

8. The OpenRouter Solution

OpenRouter has rapidly emerged as a game-changer in the artificial intelligence landscape, functioning as a unified API gateway to the world’s most advanced language models. Instead of juggling dozens of separate accounts, billing systems, and API keys across providers like OpenAI, Anthropic, Google, and Z.ai, OpenRouter consolidates everything into a single, elegant interface. With access to over 400 models—ranging from cutting-edge frontier models to highly efficient, virtually free options like Z.ai’s GLM-4.7-Flash—it allows developers and researchers to seamlessly route their prompts to the perfect model for the job. See also: Accessing DeepSeek V4-Pro via API on Windows 11 Using OpenWebUI – The Captain’s Watch.

One of the most refreshing aspects is its frictionless onboarding. Upon creating an account and adding a nominal starting balance—just $5—the platform automatically generates a single fully functional API key. There is no waiting for approval; you are instantly ready to connect.

This is incredibly powerful when paired with Open WebUI running on Docker in Windows 11. Open WebUI provides a beautiful, local, browser-based interface for your AI interactions, and connecting it to OpenRouter transforms your local Docker setup into a centralised hub for hundreds of models.

Setting it up is remarkably straightforward and requires zero coding. First, grab your auto-generated API key from the OpenRouter dashboard. Next, launch your Open WebUI instance in your Windows 11 browser and log in as an Admin. Navigate to the Admin Panel, click on Settings, and select the Connections tab.

Here, you will add a new connection. Set the connection type to OpenAI API. For the URL, enter https://openrouter.ai/api/v1. In the API Key field, paste your OpenRouter key. Click Save, and then refresh your browser page.

Once reloaded, Open WebUI will automatically fetch the available models from OpenRouter. You can now seamlessly switch between models directly from the Open WebUI chat dropdown. OpenRouter handles the complex routing and billing behind the scenes, allowing you to focus entirely on exploring different AI models and optimising your local Windows 11 Docker environment without the administrative headache of managing multiple provider ecosystems.

Ultimately, OpenRouter democratizes access to AI. By stripping away the overhead of managing multiple provider ecosystems, it allows you to focus entirely on what matters: experimenting with different models, optimising for cost and performance, and building incredible applications.

Initially you will be flooded with hundreds of models to pick from in say an OpenWebUI interface. Do not batch disable them – they’ll all disappear – and it’s a real pain to get them back. That’s how OpenWebUI works. It’s not a fault of OpenRouter. Instead manually switch off several per day that you will not use.

9. Your Data and Where It Goes

Everything in this guide so far has been about efficiency — getting better answers for less money. This final section is about something different. When you send text to an external API, that text leaves your machine. Where it goes, what happens to it there, and how long it stays matters. Especially if the text contains anything you would not want on someone else’s server.

What leaves your machine

When you use OpenWebUI with an external API, the full content of every API request crosses the internet. That includes your system prompt, any document text (whether injected as full context or as retrieved chunks), the entire conversation history, your latest message, and any tool definitions. If you uploaded a PDF and are using full context mode, the extracted text of that document is sent to the provider’s servers on every single turn.

The text extraction itself happens locally. Your PDF is never uploaded as a file to the provider. But the extracted text — which may contain everything the PDF contained — is sent as part of the prompt payload. The distinction between “the file” and “the contents of the file” is not a meaningful privacy boundary.

What stays local

Some things do not leave your machine. The embedding model, if you are running one locally for RAG, processes your document text on your hardware. The vector database that stores those embeddings sits on your machine. OpenWebUI’s own data — your chat history, your settings, your stored memories — lives in a local Docker volume. If you are using a local model through Ollama for any tasks (including as a task model for title generation), those requests never leave your network.

The boundary is clear: anything processed by the external API leaves. Anything processed locally stays.

Where it goes

This depends on your provider. For DeepSeek specifically — since that is the provider used throughout this guide — there are several things worth knowing.

DeepSeek is operated by Hangzhou DeepSeek Artificial Intelligence Co., Ltd. Their privacy policy states that personal data is processed and stored on servers in the People’s Republic of China. This applies to API usage as well as their web interface.

DeepSeek’s automatic prefix caching stores computational results from your prompts on disk on their servers. Their documentation states that unused cache entries are “usually cleared within a few hours to a few days.” This is not a fixed retention period or a deletion guarantee. It is a description of typical behaviour.

DeepSeek’s privacy policy states that user inputs may be used for model improvement. An opt-out mechanism exists, but the specifics and the scope of that opt-out are worth reading in their own policy rather than taking secondhand. Policies change. The version current at the time of writing may not be the version current when you read this.

What this means in practice

None of this is unique to DeepSeek. Every external API provider — OpenAI, Anthropic, Google, and others — processes your data on their servers, subject to their own policies and the legal frameworks of their jurisdictions. The trade-off between cost, capability, and data control is the same across all of them. What differs is the specifics: where the servers sit, what the retention terms say, what legal regime applies, and whether those terms meet your own requirements.

If you work with material that is genuinely sensitive — client data, personal information, legally privileged content, clinical records — you need to make your own assessment of whether sending that material to any external API is appropriate. This guide cannot make that assessment for you. The relevant considerations include your professional obligations, any regulatory requirements that apply to your work, the provider’s data processing terms, and your own judgement about acceptable risk.

There are ways to reduce exposure without giving up the setup entirely. You can redact or anonymise documents before uploading them. You can use a local model for sensitive work and reserve the external API for material that carries no confidentiality concern. You can run DeepSeek’s open-weight models locally if you have the hardware, which keeps everything on your machine at the cost of needing substantial computing power. OpenWebUI supports all of these configurations. The choice is yours to make.

A note on caching and residual data

One point connects this section back to the rest of the guide. Prompt caching means the provider is storing derived data from your inputs on disk for a period of time. The cached data is not your raw text — it is the mathematical representation (the KV cache) generated during processing. But it is derived from your text, it sits on the provider’s infrastructure, and its retention is governed by their policies, not yours. If the content of your prompt is sensitive, the cache of that prompt is also sensitive. Keep this in mind when deciding what to send.