Most chat requests carry a block of text that never changes: the system prompt, the house style rules, the same reference document, the same tool instructions. You send it again on every call, and on every call you pay for it as fresh input. Prompt caching is the provider-side answer to that waste, and the fix on your side is mostly about how you order the prompt.

What WebWright documents about caching

The live FAQ states that Wren R1 supports cache hits at $0.10 per 1M input tokens for Standard tier users, and that frequently used prompts are automatically cached. There is no flag to set and no separate endpoint: caching happens on the provider side for prompt content that recurs.

The published rates make the size of the effect easy to see. On Standard, fresh input is $0.40 per 1M tokens and a cache hit is $0.10 per 1M tokens, so a cached token is billed at one quarter of a fresh input token, a 75% reduction on the cached portion. On Premium the same ratio holds, $0.80 fresh input against $0.20 cached.

Structure the prompt so the stable part repeats

Caching rewards repetition of a stable prefix. The practical rule is: put everything that stays the same at the front of the prompt, in the same order, and put the part that changes at the end.

  • Keep the system prompt identical across calls. Rewording it per request, or interpolating a timestamp or request id into it, breaks the repetition that earns a cache hit.
  • Move fixed reference material ahead of the variable question. A long document, a schema, or a policy block belongs before the user's question, not after it.
  • Do not reorder stable sections between calls. Same content, same order, same place.
  • Keep the variable part last. The user's actual question, or the fresh data to act on, is the only part that should change call to call.

None of this changes the model or the quality of the answer. It changes how much of the prompt the provider can serve from cache.

A minimal OpenAI-compatible example

The client change is the same one-line swap used everywhere else on an OpenAI-compatible endpoint: a new base URL and the model name.

from openai import OpenAI

client = OpenAI(
    base_url="https://webwright.ai/v1",
    api_key="www_v1_YOUR_API_KEY",
)

# Stable prefix: keep this byte-for-byte identical across calls.
SYSTEM = (
    "You are the support assistant for Acme Cloud. "
    "Answer in at most three sentences. "
    "Cite the relevant section of the policy below. "
    "If the policy does not cover the question, say so and offer to escalate."
)

def answer(question: str) -> str:
    resp = client.chat.completions.create(
        model="wren-r1",
        messages=[
            {"role": "system", "content": SYSTEM},
            {"role": "user", "content": question},  # variable part, last
        ],
        max_tokens=300,
    )
    return resp.choices[0].message.content

The system block is the cacheable part. The question is the only thing that changes, so the leading context recurs and can be served from cache.

How to check it is working

Read the usage object on each response and track input tokens over time rather than estimating them yourself. When a large stable prefix is reused across calls, the effect shows up as lower input cost for the same work in your bill. Compare a period of stable-prefix calls against a period where the prefix changed on every call; the difference is the caching effect on your workload. The published rates are on the pricing page, and the cost-model guide shows how to turn token counts into a cost per request.

Where this fits

Caching is one of three levers that move a chat bill, alongside output length and picking the right tier for the work. It is the cheapest one to adopt because it is a prompt-structuring change, not a model or architecture change. If you resend the same instructions on every call, you are already paying for the cache you are not using.

If you want a second pair of eyes on your prompt structure and cost profile, we run a 30-minute working session. Bring one real request shape and we will look at the input, the output, and where cache reuse would land. Book one using the link below.

The WebWright Team