Repository navigation
How a Turn Is Built
Every time a character replies, Orbweaver builds one prompt and sends it to your model. The host can read all of it, before the reply and after.
If you have used SillyTavern, this will feel familiar: a preset decides the order, and the chat history sits in the middle. For the practical side of editing a preset, see Presets and prompts.
A prompt is assembled from six kinds of content. The Preview tab (below) shows them with these same names.
| Part | What it is |
|---|---|
| System | The preset's own instructions, such as the main prompt and the post-history instruction. |
| Cards | Each seated character's description, personality, scenario and dialogue examples, plus your persona. |
| World info | The entries from your world books that apply to this turn: always-on entries, plus the ones whose keywords came up in recent messages. → Lorebooks |
| Steering | Everything that nudges this one turn: memories recalled for the moment, passages from attached documents, a character card's author's note, notes the host adds under Injections in the This chat tab, and the direction you typed before pressing a reply button such as Try another reply. |
| Game state | In a game, the current state of the story: stats, trackers, the scene, quests. Only present when game mode is on. → RPG mode |
| History | The conversation itself, newest messages last. |
Memory counts as steering. It's the older part of the story, brought back when it matters. → How memory works
Memory is the Remember earlier in long chats switch under Chat behavior. It is off until you switch it on, it states its cost when you do, and it needs a Utility model to write its summaries.
The preset is a list of sections, and you can reorder it in the preset editor. The built-in order is:
- Main
- World info (before)
- Description, Personality, Scenario
- User persona
- World info (after)
- Dialogue examples
- Chat history
- Memory, Databank (attached documents) and Guided instruction
- Post-history
Chat history is the pivot. Sections above it become the system prompt, and sections below it land after the conversation, right next to where the model starts writing. That is why memory, documents and the guided instruction sit below it by default: they change every turn, and above the history they would rewrite the front of the prompt each time (see prompt caching, below).
A section can also be limited to certain kinds of turn with Fires on, such as a continue or a swipe, or placed inside the conversation at a depth. The preset editor shows how.
A turn is funded by the room host, even when a friend sent the message. The reply is written by the host's Chat model. Memory summaries run on the host's Utility model. Smart speaker selection normally uses the host's Rerank model, which runs locally by default. It uses Utility only when the host selects Use the Utility model instead. There is no per-chat model choice. To change which model a room uses, the host changes their Model roles. → Connect a model
The host can open Show details and choose the Preview tab to see what the next turn would send, before sending anything. It shows a bar of how much of the model's context window the prompt uses, split into the parts above (a part with nothing in it is left out). Open any part to read its exact text. History is the transcript you are already reading, so it shows only its cost. Under Cards, each character's share is listed separately, so you can see what each one costs.

Token counts here are estimates made by Orbweaver. The provider's own count, after the reply, is the real one. If Orbweaver can't read the model's window size, the tab says window unknown rather than drawing a ratio it can't back up. The preview doesn't see a message you haven't sent yet, so world info that message would trigger doesn't show until you send.
When a chat grows past what the model can read, the oldest messages drop out of the prompt first and the newest message always stays. Memory exists to bring back what dropped out. You can also set a lower limit than the model's own with Max context tokens in the preset.
Every generated reply keeps the prompt that was built for it, one per swipe. Open the reply's menu and choose View wire trace... to read the swipe you're on: the Static prefix (the stable front), the Dynamic suffix (the per-turn part), the notes spliced into the history, and the generation settings used. The conversation itself isn't copied in, because it's already in the chat. It answers "why did it say that", even after you've changed the preset or the characters since.
Like the Preview tab, this is for the host, because a prompt contains every character's full card. A greeting or an imported message says no prompt was captured, because none ran. Your own messages don't offer it.
Some providers reuse the front of a prompt if it is exactly the same as last turn's, which makes long chats faster and cheaper. Orbweaver keeps the fixed parts (system, cards) at the front, and the built-in order puts the parts that change every turn after the history.
Content that changes between turns can reduce reuse of the prompt after it. The preset editor warns about changing content before Chat history, such as memory or a time macro. World-info sections are not warned about just because they exist. For a particular room, the host's Preview names the dynamic lore entries that actually enter that turn's prompt.
Prompt-prefix caching reuses part of the input; the model still writes a new answer. Whether a prefix qualifies depends on the route and its upstream provider. A matching prefix alone does not guarantee a hit.
OpenRouter can separately replay an identical complete response when you request it. A changed turn normally misses; fresh generation actions bypass replay rather than clearing an existing entry. An observed replay hit is free, but unknown token counts remain unknown. Connect a model shows where to review the connection and preset choices.
In a group chat, the host's How the characters reply setting decides what a round produces.
- Narrator: one message voices all the seated characters. There is no speaker to pick, so the Smart speaker picker makes no call.
- Per-speaker: each character replies in their own message, with a prompt built for that speaker. Cards are merged by default, so everyone sees everyone. Under Advanced, switch on Each character sees only their own card so a character's prompt carries only their own card. Personal per-character memory needs this switch too.
{{user}} resolves by where the text came from. This is the persona pin, which started as the PersonaPin SillyTavern extension; the hook and where to see it are on Characters and personas.
-
Card text (description, personality, scenario, first message, example messages, and the card's own lore book):
{{user}}is the pinned persona, the one that opened the chat. A set pin never follows a mid-chat persona swap. If the card says{{user}} is my brotherand John opened the chat, "my brother" stays John after you swap to Sarah. -
Preset and user-authored text (the main prompt, your injections, your own lines):
{{user}}is the active persona, the one the chat's anchor human has on their seat right now. On a Draft your line, it's whoever pressed the button. - Lore books go by scope. A character's book follows the pin. A chat book or a global book follows the active persona. A persona's book is that persona.
flowchart LR
Card["Card text: description, scenario, greeting, examples, the card's lore"] --> Pinned["Pinned persona (opened the chat)"]
Preset["Preset text, injections, your own lines"] --> Active["Active persona (on your seat now)"]
What else it does:
- Swaps are handled. Once you've swapped, the pinned persona's description goes into the prompt as a fixed card-context block, so the character still knows who the card's "you" is while a different persona is speaking.
- No pin set, or the pinned persona is gone: card text falls back to the active persona, so card macros never collapse to a literal "User".
- Forks. The pin carries over if you own that persona. Otherwise it clears.
- Rooms. With several humans in a room, the host picks which present player's persona the card means, and can re-pin it any time. Every player still plays as their own persona, and each present member's persona description goes into the shared prompt. → Rooms and group chats
The game panel changes through checked tool calls or a separate structured state reply: updates to trackers, inventory, the party, the scene and the journal. Nothing is scraped out of the story text, so if the narrator writes "you now have 50 gold" without recording a state change, the panel doesn't change. Trackers are addressed by key, never by label, so renaming one can't orphan its value. Locks hold, and a scene character has to be on stage before anything can be written to them. Without tool support the game goes read-only, you steer it by hand, and the app says so. → RPG mode
When a rule needs the model to read the story (the analyst behind the needle, pacing analysis and the rest), that's one pass where the model fills in a form the app defines and the app checks the answer. What comes back is data. It can only land in a fixed set of output slots, and any macro in it is neutralized, so a model can't write {{getglobalvar}} into your chat and have it run. → Automation
Replies stream in live. Each open tab keeps a single live connection that carries every chat, notification and update. If it drops, it reconnects and each chat catches up on what it missed.
Something wrong or out of date on this page? Open an issue and say which page.
Get started
Guides
- Characters and personas
- Lorebooks
- Presets and prompts
- Rooms and group chats
- RPG mode
- Automation
- Images
- Refinery
- Stats and Insights
- Plugins
- Themes
- Share with friends
- Back up and restore
How it works
Help