Claude Opus 5.5 set up in OpenWebUI

Estimated reading time at 200 wpm: 15 minutes

These notes record a working session on Claude Opus 5.5 (hereafter O5.5), released in the third week of September 2026. The session began with a question about its new token pricing. It ended with prompt caching configured and confirmed in OpenWebUI.

If you don’t know about OpenWebUI and you’re a luddite incapable of learning, kindly depart now. I’m not explaining it again. All I know is that I get over 500 AI models for a controlled cost of about USD$10/month instead of paying around $300/month for the same heavy usage.

The aims were practical when looking at O5.5. It is no doubt in the top three of frontier AI models and could cost more, if not used efficiently. I needed to understand how input, output and cache charges changed from Opus 5, and what Opus 5.5 offers over Sonnet 5. Then I needed to check whether running Opus 5.5 through the API costs more or less than a web subscription for long document analysis. I would set up an efficient, repeatable test then decide.

The test route was OpenWebUI, connected to Opus 5.5 through OpenRouter. The benchmark was a single document of about 1,245 words, analysed over several rounds of questions.

Three findings became important. OpenWebUI added substantial hidden input until several model settings were switched off. Anthropic caching does not start by itself, unlike DeepSeek; it needs an explicit request parameter. And a five-minute cache expires too quickly for an unhurried working pace.

Costs were verified throughout by arithmetic against OpenRouter’s generation details. Figures quoted are in US dollars at published list prices as of September 2026.

1. Opus 5.5 pricing

1.1 Changes compared with Opus 5

Opus 5.5 is cheaper than Opus 5 on every price line. Base input and output fell by 20%. Cache writes fell by the same proportion, because they are fixed multiples of the input price.

Cache writes cost 1.25 times the input price for a five-minute cache and twice the input price for a one-hour cache.

On subscription plans, Anthropic states that the lower price is passed on to usage limits. These go about 25% further than on Opus 5.

1.2 The cache-read cut and why it matters for long sessions

The largest change is to cache reads. On most Claude models, a cache read costs one tenth of the input price. On Opus 5.5 it costs one twentieth. The result is a 60% cut, from $0.50 to $0.20 per million tokens.

This matters because every round of a conversation resends the whole earlier conversation. In a long session, most input becomes repeated material. If that material is read from cache, input costs fall sharply.

Anthropic’s own worked example shows the scale. A task with 2.8 million input tokens costs $11.20 with no caching, $1.62 at a 90% cache hit rate, and about $0.99 at 96%.

Output – computation – is now the dominant cost. One output token costs 100 times as much as one cache-read token. Output includes the model’s internal thinking, which is billed in full even when only a summary is shown.

1.3 Opus 5.5 against Sonnet 5: where the premium applies

Opus 5.5 costs twice as much as Sonnet 5 for fresh input and for output. Cache reads cost the same on both. Sonnet 5 keeps the standard one-tenth multiplier on a $2 base. Opus 5.5 has a one-twentieth multiplier on a $4 base. Both arrive at $0.20.

So the Opus premium shrinks in long, cache-heavy sessions. Using Anthropic’s example task, with identical token counts on both models, Opus 5.5 costs about $2.19 and Sonnet 5 about $1.36. That is about 1.6 times, not twice.

The comparison assumes both models use the same number of tokens. In practice they may not. A stronger model may finish in fewer turns. A weaker one may need more. No verified head-to-head benchmark data was available to settle this.

Anthropic positions Opus 5.5 for long-running agentic coding and knowledge work. It positions Sonnet 5 as the best balance of speed and intelligence.

2. Effort levels

2.1 Effect on output tokens

Effort controls how much the model thinks before answering. The Claude app offers five levels: Low, Medium (the default), High, Extra and Max. The app warns that Max uses 5.5 times or more of the usual allowance.

Thinking is billed as output, the most expensive line. So effort pulls the largest cost lever. It has little direct effect on input, since the prompt is the same whatever the setting.

In agentic work, higher effort can also bring more tool calls and more turns. Each extra turn resends the context, which raises input and cache costs as well.

In OpenWebUI, effort is set as a text value in the Reasoning Effort field under Advanced Params. The tests in these notes used “medium”. Thinking tokens across four medium-effort runs ranged from 84 to 1,169. The model adjusts its thinking to the task, so figures vary between runs of the same question.

2.2 Limits of published information on effort-level costs

Anthropic does not publish token budgets or costs for each effort level. The only firm figures found were these:

• The Claude app warns that Max uses 5.5 times or more.
• Anthropic’s migration guidance advises setting the maximum output to at least 64,000 tokens at the two highest levels. This is a ceiling, not typical use.

It was not confirmed whether the app’s “Extra” level corresponds to the API’s “xhigh” setting.

The only reliable way to find the real cost of each level is to measure it. Running the same task at each setting and reading the token counts from the API gives figures for a specific workload.

3. API against web subscription

3.1 Metered billing against usage limits

The two routes use the same tokens but bill for them differently.

The API is metered. Every token is charged at list price. Each call reports its input, output, cache-write and cache-read counts. The user controls the cost levers directly: model, effort, maximum output, caching and the choice of cache duration. Batch processing, at half price, and fast mode are available only on the API.

The web app charges a flat monthly fee. There is no per-token bill. Instead, usage counts against a limit that resets over time. Longer conversations, larger uploads, stronger models and higher effort all use the limit faster. Caching happens automatically in the background but cannot be seen or controlled.

Anthropic does not publish plan limits in tokens. So a subscription cannot be converted into an equivalent API spend. The break-even point is simple arithmetic: divide the monthly fee by the cost of a typical session. Regular heavy use tends to favour a subscription. Occasional or bulk work tends to favour the API.

The pricing of usage credits on the Pro plan was not established.

3.2 Estimated cost of a ten-round document session

The estimate uses a real first round from testing: 3,172 input tokens and 2,873 output tokens at medium effort. Each earlier question and reply is resent in later rounds. Over ten rounds, input grows to about 133,000 tokens. Output totals about 28,700 tokens.

Output accounts for most of the cost. Replies of the same question varied from about 1,500 to 3,700 output tokens between runs. Asking for shorter replies is the simplest saving.

3.3 Session cost comparison across Opus 5.5, Kimi K3, GLM-5.3 and DeepSeek V4 Pro

The same ten-round session was priced at each model’s published rates, as of September 2026.

DeepSeek’s peak hours are 01:00 to 04:00 and 06:00 to 10:00 UTC, Monday to Friday. In British Summer Time, that is 02:00 to 05:00 and 07:00 to 11:00.

The table’s main weakness is that it assumes every model produces the same number of tokens. They will not. Kimi K3 always reasons, with maximum effort as its default, so its real output and cost are likely to be much higher. Tokenisers also differ between providers. Only running the same test on each model would give reliable figures.

On price alone, Opus 5.5 costs about seven times GLM-5.3 and about fourteen times DeepSeek V4 Pro off-peak. Whether the quality justifies the difference is a separate question, best answered by comparing outputs on the same document.

4. OpenWebUI configuration

4.1 Connecting Opus 5.5 through OpenRouter

Opus 5.5 was reached through OpenRouter, using an existing OpenRouter connection in OpenWebUI. The model appears as anthropic/claude-opus-5.5. OpenRouter routed requests to Anthropic through Claude Platform on AWS. OpenRouter’s generation details state that there is no data training on this route.

OpenRouter’s Logs page shows each request with its model, token counts and cost. Clicking an entry opens the generation details, including the Request ID and a Usage breakdown. These were used to check every figure in these notes.

The logs also show free calls to a separate small model, Ling 3.0 Flash. These are OpenWebUI’s background tasks, such as generating chat titles and tags. They cost nothing.

4.2 Setting Reasoning Effort and Max Tokens in Advanced Params

Model settings made in the Admin Panel apply to every chat with that model. The route is: profile icon, Admin Panel, Settings, Models, then the pencil icon on the model.

Under Advanced Params, each field shows “Default” until clicked. Clicking changes it to “Custom” and opens a text box.

• Reasoning Effort: medium
• Max Tokens: 8000

Changes are kept only after clicking Save & Update at the foot of the page. They apply to this model alone.

4.3 Capabilities and Builtin Tools that inflate input

A newly enabled model arrives with most capabilities and builtin tools switched on. Several add material to every request. Six changes were made on the Opus 5.5 model page.

Capabilities:

• Usage: on. This shows token counts, which are needed to check caching.
• File Context: off. It slices documents into chunks each round, which can vary and break caching.
• Citations: off. It adds instructions that can compete with the user’s prompt.
• Memory: off. Stored memories can contaminate document analysis.

Builtin Tools:

• Knowledge Base: off. It can trigger unwanted searches on every chat.
• Memory: off. For the same reason as the Memory capability.

File Upload must stay on. The remaining tools were left on. Each adds its definition to every request, but once caching works, that cost falls mostly to the cheap cache-read rate.

4.4 Global memory: cost, contamination and privacy

OpenWebUI’s Personalisation tab held about 3,540 words of stored memories. That is roughly 4,700 tokens. If injected into every request, it would affect every model.

There are four concerns:

• Cost: On providers without automatic caching, it is paid at full input price on every request.
• Contamination: Unrelated stored details can colour document analysis.
• Privacy: Every provider receives it.
• Drift: Old memories go stale but continue to steer answers.

The main benefit is convenience, such as a standing preference for UK English. That could sit in a short system prompt instead.

It was not established whether the memories were sent once the Memory settings were switched off on the model. The global memory store was left unchanged pending a decision.

4.5 Input reduced from 13,392 to 3,172 tokens

Before the changes in 4.3, a single question on a 1,245-word document produced 13,392 input tokens. The document itself accounts for about 1,700. The rest came from OpenWebUI.

After the changes, the same question produced 3,172 input tokens. The cost of that round fell from $0.108 to $0.070.

The tests did not isolate which of the six changes saved how much. Memory and Knowledge Base were the likeliest main contributors.

4.6 Pasting text without automatic file conversion

OpenWebUI converts long pasted text into an attached file by default. An attached file may be read by a tool rather than placed in the conversation, which is less predictable for caching.

5. Prompt caching

5.1 Why Anthropic caching is not automatic

DeepSeek, GLM and Kimi cache repeated material by themselves. No instruction is needed. Anthropic caches only when the request asks for it, using a parameter called cache_control. OpenRouter passes this parameter through but does not add it.

The early tests confirmed this. Before the parameter was added, every charge matched full-price arithmetic exactly. No cache write appeared.

Anthropic offers a simple form of the request, called automatic caching. A single cache_control field at the top level of the request caches everything up to the latest content. There is no need to mark individual messages. OpenRouter supports this form for Anthropic models.

The minimum cacheable length on Opus 5.5 is 512 tokens. A document of about 1,700 tokens clears it easily.

5.2 Adding cache_control as a custom parameter

OpenWebUI can add extra fields to each request through Advanced Params. At the foot of the Advanced Params list is a button labelled + Add Custom Parameter. Clicking it creates two boxes, shown with placeholder text:

• the upper, smaller box reads custom_param_name
• the lower, larger box reads custom_param_value

The entries are:

• in custom_param_name: cache_control
• in custom_param_value: {"type": "ephemeral"}

The two parts must go in separate boxes. Typing both into the value box leaves the name box empty and the parameter unusable. The space after the colon inside the value is harmless. A stray space after cache_control would not be, and cannot be seen on screen.

OpenWebUI’s documentation confirms that structured values of this kind are sent to the provider as intended. The setting applies to the Opus 5.5 model only.

5.3 Verifying cache writes through cost arithmetic

OpenRouter reports total cost but not always the split between input and output. The split can be worked out by subtracting the output cost from the total, then comparing what remains with the possible input rates.

First round after adding the parameter: 3,172 input and 3,664 output tokens, charged $0.0891.

• Output: 3,664 × $20 per million = $0.0733
• Input at the plain rate of $4 would give a total of $0.0860
• Input at the write rate of $5 gives a total of $0.0891, an exact match

So the input was written to cache.

A later round, 17 minutes after the previous one: 6,858 input and 1,537 output tokens, charged $0.065.

• Output: $0.0307
• Input: $0.0343, which matches all 6,858 tokens at the write rate

So everything was written again. Nothing was read.

A cache write costs slightly more than no caching. The saving comes only from later reads.

5.4 Reading Request ID timestamps to check the five-minute window

Each OpenRouter Request ID begins with a number, such as req-1790277391. The number is a timestamp in seconds. Subtracting one Request ID number from another gives the time between two requests.

Round 3.1 fell outside the five-minute window, so the cache had expired. Round 3.2 fell inside it.

The same method identified a screenshot that appeared to be a later round but carried an earlier Request ID. A genuine later round always has a higher number, and usually higher input, since it carries earlier material with it.

A new chat with an identical document and identical question also produces an identical prefix. Sent within the window, it should read from the cache in the same way as a follow-up question.

5.5 First confirmed cache read and a 73% input saving

Round 3.2 was the first to show a cache read. OpenRouter marked it with a Cached badge.

Charge: $0.0566 for 8,425 input and 2,369 output tokens.

• Output: 2,369 × $20 per million = $0.0474
• Input by subtraction: $0.0092

Expected input with caching:

• 6,858 tokens read from cache × $0.20 per million = $0.0014
• 1,567 new tokens written × $5 per million = $0.0078
• Total: $0.0092, an exact match

Without caching, the same input would have cost $0.0337. The input cost fell by about 73% for that round. The saving grows with each round, as more of the conversation sits in the cache.

6. Next steps

6.1 Switching to the one-hour cache

The five-minute cache expires too quickly for an unhurried pace. Pauses for reading, checking and screenshots can run past five minutes. When that happens, each round pays the write premium without the benefit of a read. That is slightly worse than no caching.

The one-hour cache writes at $8 per million instead of $5. Reads stay at $0.20. Compared with no caching, it pays for itself after two reads.

The change is made on the Opus 5.5 model page:

1. Profile icon, Admin Panel, Settings, Models, then the pencil icon on Opus 5.5.
2. Advanced Params, then Show.
3. Click the value line beneath cache_control.
4. Press Ctrl + A and type exactly: {"type": "ephemeral", "ttl": "1h"}
5. Leave cache_control itself unchanged.
6. Save & Update.

6.2 Test: two questions, five to sixty minutes apart

The test is to ask two questions in the same chat, with a gap longer than five minutes but shorter than one hour.

The one-hour setting is working if the second request shows:

• the Cached badge in OpenRouter’s generation details
• an input cost, found by subtraction, well below the full-price figure

Open items for later consideration:

• whether to trim or retire the global memory store
• a side-by-side comparison of Opus 5.5 and DeepSeek V4 Pro on the same document, to judge whether the quality justifies the price
• measuring real token use at each effort level on a typical task

Conclusions

Opus 5.5 is undoubtedly very powerful. Its an option from among 500+ models via one PAYG package in OpenRouter. It’s there for when I need ‘brute force’ in a rush. This article is not about saying that ‘everybody’ should use Opus 5.5.

The main focus was on cost, how to reduce it when that brute force is needed.

There are other very good models with brute force that are cheaper. Stay tuned.