AI roleplay context length: how much your chat actually remembers

Quick answer: context length is what gets resent, not what gets remembered.

Context length, also called the context window, is the maximum number of tokens a model can take in on a single request, counting your prompt and its reply together. A token is roughly three quarters of an English word, so a 200,000-token window holds very roughly 150,000 words, a long novel's worth of text. Roleplay platforms such as JanitorAI, SillyTavern, RisuAI, Agnai, and Chub-style frontends do not send messages incrementally. Every single turn resends the character card, your persona, any active lorebook or World Info entries, the system prompt, and the full chat history so far, then appends your newest message. Nothing about that changes as the chat grows except the size of what gets sent, which means both the memory ceiling and the per-message price are set by the same number: how many tokens currently sit in the window. Context windows across this catalog range from 200,000 tokens up to 1,050,000 tokens depending on the model. Bigger is not automatically better: a window you never fill costs nothing extra, and a window that outgrows your actual chats just sits idle. The rest of this page works out how fast a real chat fills that window, what happens once it does, and how to pick a size that matches how you actually play.

How context fills up in a real chat.

Two numbers matter here and they are not the same thing. The nominal context window is the maximum a provider publishes, the number in a spec sheet or the comparison table below. The effective context is how much of that window a model actually uses well, and it is a model-quality question rather than a spec-sheet question: some models keep track of a detail established 40,000 tokens back, others start blending characters together well before the nominal limit. Nothing in this guide can tell you a model's effective context with precision, since it is not a published figure and depends on your specific card and story, but it is why two models with an identical 1,000,000-token window can feel very different by message 300.

• Character card and persona: loaded once at the start of a chat and resent on every turn afterward, typically a few hundred to a couple thousand tokens depending on how detailed the card is.
• Lorebook or World Info entries: SillyTavern and similar frontends inject any entry whose trigger words match the recent conversation, so an active lorebook can add anywhere from a few hundred to several thousand tokens per turn without you seeing it happen.
• System prompt and formatting instructions: usually smaller than the card, but still resent every single turn for the life of the chat.
• Message history: every prior exchange, resent verbatim until a frontend trims or summarizes it. This is the part that grows without bound as a chat continues.
• The reply itself: output tokens count against the same window as input, so a long, detailed response leaves less room for the next turn's history.

Worked example: how fast a chat fills the window.

Assume a fairly typical setup: about 1,500 tokens of character card, persona, and system prompt combined, plus roughly 250 tokens added per exchange, your message and the reply together. That is a conservative estimate; a dense card or a very chatty character pushes the real number higher. The table below runs that estimate out from a first session to a genuine marathon, and prices the single next message at deepseek-v4-flash's catalog input rate to show what the growing window actually costs, not just how large it gets.

Why context problems catch people off guard.

None of this is a bug. It is the direct consequence of resending the whole window on every turn, and understanding it turns a confusing moment, the companion suddenly acting different, into a predictable one: the window filled up.

• The advertised context window is a maximum, not a guarantee your companion remembers chapter six. Recall can soften well before the nominal limit, and no spec sheet publishes that number.
• Frontends usually trim or summarize quietly when a chat nears the window, so nothing errors. The story just starts skipping details, which reads as a personality shift rather than a technical limit.
• A lorebook with fifty entries is additive: every active entry rides along on every turn, and a heavy lorebook can eat a large share of the budget before the actual conversation even starts.
• Bills creep silently. A message that costs a fraction of a cent at turn 10 costs many times more at turn 500, purely because the context itself grew, with no change to any setting you touched.
• Switching models mid-chat can look broken when it is really a smaller context window. The new model truncates history the old one was still holding, so earlier plot points vanish immediately.

Context window size, model by model.

The table below lists the nominal context window for models commonly used for roleplay in this catalog, next to the catalog input price per million tokens. Read window size as a ceiling on story length and price as what filling that ceiling actually costs; the two do not move together, and a large window on a cheap model is a different trade-off than the same window on a flagship one.

Practical fixes once the window becomes the problem.

That last lever compounds with everything above it: trimming history reduces how many tokens you send, and a lower per-token rate reduces what each of those tokens costs. APIsRouter is an OpenAI-compatible gateway that carries several 1,000,000-token-context models, deepseek-v4-flash and deepseek-v4-pro among them, priced 20% below official list for global models, with Chinese models priced below their official rates, pay-as-you-go billing, and a no-signup checkout at /topup that emails the key. Testing whether a bigger window is worth it on your own chat then costs whatever that chat actually burns, not a subscription tier picked in advance.

• Trim persona and lorebook entries to what the current scene needs. SillyTavern's World Info panel lets you toggle entries off instead of deleting them, so an unused subplot stops costing tokens without losing your notes.
• Turn on a summarization extension, or write your own periodic recap, once a chat crosses a few hundred messages. A two-paragraph summary of the first act costs far fewer tokens than resending the original chapter, and it is a choice you make rather than the frontend quietly dropping the oldest turns for you.
• Start a new chat for a new story. One thread that spans a year of real time is the single biggest driver of both context size and cost; splitting into arcs keeps each one small.
• Match the model's window to how long your chats actually run. A 200K-token model is plenty for most single campaigns; reach for a 1M-class model only once your history genuinely grows past that, since a bigger window does not cost more by itself, filling it does.
• Watch for a context-length error instead of assuming a request just failed. It usually names the limit, and the fix is trimming or summarizing history, not retrying the same request unchanged.
• If cost, not the window itself, is the real constraint, the same large-context model can be billed at different per-token rates depending on the endpoint; routing through a cheaper OpenAI-compatible endpoint keeps the same context ceiling at a lower price per refill.

Config example: trim history before you hit the wall.

The trimming logic below is provider-agnostic: it keeps your character card intact, estimates roughly how many tokens the rest of the history costs, and drops the oldest turns once the budget runs out, a deliberate version of what a frontend does silently anyway. The token count it produces is an estimate; every provider tokenizes text slightly differently, so treat the number as a ballpark for deciding when to trim rather than an exact reservation. The examples below assume an OpenAI-compatible endpoint; the trimming function itself works against any provider's chat completions API.

import tiktoken

# Approximate; every provider tokenizes slightly differently, so treat this as a ballpark.
enc = tiktoken.get_encoding("cl100k_base")

def trim_history(character_card, messages, max_context_tokens, reserve_for_reply=500):
    budget = max_context_tokens - reserve_for_reply - len(enc.encode(character_card))
    kept, used = [], 0
    for msg in reversed(messages):  # walk newest to oldest
        cost = len(enc.encode(msg["content"]))
        if used + cost > budget:
            break
        kept.append(msg)
        used += cost
    return list(reversed(kept))  # oldest-to-newest, ready for the next request

FAQ