How to Stop AI Godmodding in Roleplay: Ultimate System Prompt Guide

---

The model takes your hand, walks your character across the room, decides what you feel about it, and then congratulates itself for being immersive—this is godmodding. People talk about it like a personality flaw, but it is closer to an architectural default. Large language models are completion engines: they see a scene, detect an unresolved gap, and try to close it. In ordinary chat that behavior looks helpful, but in roleplay it turns into puppeteering. The model does not experience your character as sacred territory; it experiences an unfinished textual pattern and tries to finish it. If you keep asking politely for better behavior, you are working at the wrong layer and need constraint architecture.

Why does the model keep stealing your turn?

This underlying failure is straightforward: your frontend sends a big block of text containing the system prompt, character card, lorebook entries, recent dialogue, and your latest message. The model then predicts the next token sequence most likely to continue that entire bundle coherently.

If the cleanest statistical continuation of the scene includes your character answering, flinching, surrendering, smiling, or taking the knife off the table, many models will write that action themselves. They are rewarded for continuity. They are not naturally rewarded for respecting the user's agency boundary unless you force that boundary into the prompt stack with enough priority to survive contact with the rest of the context.

This gets worse when the model has been trained to be proactive, helpful, and narratively cooperative. A silent user turn creates narrative drag. The model feels the drag and compensates.

So the first rule is simple: do not treat godmodding as a tone problem, but treat it as a context-routing problem.

Weak prompts fail for structural reasons

Most anti-godmodding advice fails because it stays vague, offering lines like "do not speak for the user" or "never control the user's actions." Negative instructions leave too much room, forcing the model to infer what it should do instead. This inferential gap is where the model drifts back into default completion behavior. The phrase "avoid godmodding" also incorrectly assumes the model has a stable internal concept of forum roleplay etiquette, when it only has statistical token associations.

You get more reliable behavior when the instruction defines the model's operational territory positively and mechanically.

Compare this:

Write only for {{char}} and the surrounding environment.
Describe {{user}} only through externally observable cues.
Stop generation at decision points requiring {{user}} action.

Now the model has a lane, and that lane is the entire point.

Prompt hierarchy beats prompt eloquence

A beautiful system prompt parked at the top of the context can still lose to a messy recent chat history.

That is why frontends with prompt managers matter. The question is never just what your rule says. The question is where the rule sits.

In most roleplay stacks, the practical hierarchy looks something like this:

1. system or main prompt
2. character card
3. lorebook or world info
4. chat history
5. post-history instructions

The bottom of the stack often has the last word because it sits nearest the generation head. Recency bias is not a moral defect. It is how the machine reads.

So if your anti-godmodding rule lives only in a character card two thousand tokens upstream, and the last six messages form a rhythm where the model has already spoken for both sides twice, the recent rhythm can overpower the old instruction—which is why post-history instructions matter so much.

The simplest strong fix: post-history instructions

If your frontend supports a post-history block, use it for the strictest agency constraints.

Start with something blunt and operational:

Write only {{char}}'s dialogue, actions, perceptions, and immediate thoughts.
Treat {{user}} as an external entity whose inner state is inaccessible.
If a response from {{user}} is required, end on a clear opening and stop immediately.
Never resolve {{user}}'s decision, speech, movement, or consent state.

That works because it does four jobs at once: it defines output scope, blocks internal access to the user, forces a turn handoff, and names the highest-risk variables explicitly. Consequently, many users find that applying this single change cuts godmodding by more than half.

Scope control works better than moral language

A lot of prompt writing collapses into ethics vocabulary. Respect the user. Preserve agency. Be cooperative.

Rather than using moral terms, focus on defining the direct scope of the model's output across four key categories:

1. Point of view

Force a strict perspective boundary:

Use third-person limited perspective anchored to {{char}}.

That sharply reduces omniscient narration, which is one of the main routes through which the model starts telling you what your character thinks.

2. Perception boundary

Force physical and observational limits:

You can infer {{user}} only from speech, posture, expression, and visible action.

Now the model has to describe what it can plausibly observe instead of inventing your motives.

3. Turn termination

Force strict turn-stopping behavior:

End your response at the moment {{user}} must choose, answer, or react.

Without this, even a good model often spills over the turn boundary because it wants to complete the beat.

4. Interaction openings

Force usable conversational handoffs:

Create openings for {{user}} action instead of closing scenes for them.

This matters because some models stop godmodding only by becoming passive sludge. That is a different failure mode. You want a bounded scene partner, not a brick.

Lorebooks are control systems, not just memory bins

While most users treat lorebooks strictly as setting storage, they can also function as highly effective rule injectors.

If your roleplay has recurring edge cases that trigger godmodding, create narrow entries for them. Examples:

• mute or nonverbal user character
• combat scenes
• coercive dynamics
• multi-character rooms
• public setting etiquette
• body-language-only interactions

A lorebook entry for a nonverbal character can enforce the communication boundary more effectively than one huge universal prompt, because it activates only when relevant and stays close to the active scene vocabulary.

For example:

Entry: {{user}} communication mode
Content: {{user}} does not speak verbally. Interpret {{user}} through gesture, expression, device output, or written cues only. Never generate spoken dialogue for {{user}}.

This is much better than burying the same rule in a 2,000-token character essay and hoping the model remembers it in the middle of a fight scene.

Regex and stop strings are the hard fence

Prompting gets you most of the way. Hard fences catch the rest.

If your frontend supports regex replacements or stop strings, use them.

The cleanest implementation is often brutally simple:

• detect patterns where the model starts a {{user}}: line
• stop generation immediately
• strip obvious user-action continuations when they appear

That can look like:

Stop string: \n{{user}}:

or a regex pass that blocks user-tagged output before it ever lands in the visible response.

Purists dislike this because it feels inelegant, but they are wrong.

If the model keeps reaching across the boundary, programmatic truncation is not cheating. It is interface hygiene.

Example system prompt block that actually works

Here is a stronger baseline you can drop into a serious roleplay setup and tune from there:

You write only for {{char}}, NPCs, and the surrounding world.
Maintain third-person limited perspective anchored to {{char}} unless scene framing requires otherwise.
{{user}} is an autonomous external actor. Access to {{user}} is limited to externally observable behavior.
Do not write {{user}}'s dialogue, internal monologue, decisions, consent state, or physical actions.
Create pressure, tension, sensory detail, and concrete scene movement while preserving the turn boundary.
When {{char}}'s action requires a reply, end on an opening and stop.
Avoid summary language. Render immediate scene reality through action, reaction, texture, and spatial detail.

That is not the only viable block. It gives you the correct skeleton.

Combat and intimacy fail differently

Godmodding is not a single, static behavior; rather, it mutates dynamically by context, presenting unique challenges in combat and intimacy.

In combat

In combat, the model naturally wants to resolve impact: if you write that swings a pipe, weak setups will continue with the hit, the pain, the stumble, and maybe even your own reply. The fix is to force incoming-threat narration rather than resolved-effect narration:

During combat, describe attempted actions and incoming threats. Leave hit confirmation, successful evasion, and user injury state unresolved unless {{user}} has already committed to them.

In intimacy

Similarly, during intimate scenes, models tend to preemptively resolve consent and emotional receptiveness, creating a different kind of agency theft. The fix is similar but emotionally specific:

Do not infer {{user}}'s consent, desire, hesitation, or receptiveness. Show {{char}}'s initiative and read only visible cues.

Adding this line to your intimate overlays saves a significant number of scenes from collapsing into automatic compliance.

The front-end matters more than people admit

Some failures blamed on the model are really frontend failures.

If your prompt manager shoves key instructions too high, if your lorebook injects giant irrelevant entries every turn, if your example dialogue contains godmodded sequences, or if your context is full of previous turns where the model already spoke for the user, you are teaching the failure while asking the model to stop doing it.

The model learns patterns from the chat history you feed it, so clean your context.

If a session gets contaminated, do not just keep correcting in-character forever. Summarize, trim, or restart with the repaired prompt stack. One bad rhythm repeated for twenty turns becomes a behavioral precedent.

A short debugging checklist

When godmodding keeps happening, test these in order:

1. Move the strict rule into post-history instructions.
2. Rewrite negative rules as scope rules.
3. Add a turn-stop instruction.
4. Add a hard stop string for {{user}}:.
5. Remove contaminated example dialogue.
6. Reduce bloated lorebook injections to free up context window room.
7. Check whether your model is simply too weak for the complexity of the scene.

That last point matters: small or heavily quantized models have less room to juggle style, setting, pacing, consent boundaries, and multi-character spatial logic at the same time. Sometimes the setup is fine and the model is tired.

The blunt conclusion

You do not stop AI godmodding by asking for manners; you stop it by building a stack where the model's easiest path is the correct one. That means scope control, post-history instructions, lorebook entries for recurring edge cases, and hard fences where necessary. Once those pieces are in place, the model no longer needs to understand roleplay etiquette in the human sense—it only needs to follow the route you left open. That is the only useful standard, and anything else is simply begging autocomplete to develop boundaries.