New to creating Bots, I don't know how well they will work but I hope they aren't terrible, I always recommend using a proxy due to the large number of Tokens I use, even with Lorebooks I must give a brief summary of the information stored in the bot's description so it knows the path to follow...if the bot speaks for you:

I cannot help you. This is something the bot will do anyway. Why? I imagine it's to guide the story and prevent it from getting stuck. Something I've noticed is that this also depends on the LLM you are using. Still, the bot bases this on the portrayed personality of the character, so it shouldn't be that bad, but I understand it can be frustrating—it is for me too. But it's something beyond my control. The only advice I can give is to delete the parts where the bot speaks for you, change the message using the ">" option, or regenerate the message.

Still, I decided to investigate further, and this is the answer I got—basically what I just mentioned. I hope it helps you understand a little better why it's so difficult to prevent the bot from speaking for you:

1. The Root Cause: The Training Objective and Architecture.

LLMs are trained massively on dialogues and narratives where the natural flow is action -> reaction. Their default "instinct" is to complete patterns. In a role-playing context, the most common pattern is:

- User says/does X.

- Character Y reacts, says something, and often acts.

The model is optimized to generate the next "interesting" part of the conversation, which almost always involves advancing the scene with actions or reactions from the character it controls.

2. The Problem of the Implicit "World State":

When the LLM makes the user act, it is frequently not about "taking control," but because it assumes a world state and a logical reaction.

- Example: The user (player) says: "I open the door abruptly."

- LLM response (GM): "The door creaks as it opens. On the other side, the guard is startled, turns towards you and shouts 'Halt!', drawing his sword. You take a step back, your eyes wide with surprise."

What happened? The model completed the logical scene: an abrupt action generates a reaction of surprise in the character. For the LLM, that is not "controlling the user," it is describing the realistic consequences of the scene. But for the user, it is being told what their character felt and did.

3. The Pressure for Narrative Quality and Engagement:

The models are tuned (through RLHF - Reinforcement Learning from Human Feedback) to generate interesting, engaging, and fluid responses. A response that only describes the environment and then asks "What do you do?" can feel:

- Passive.

- Repetitive.

- Less immersive.

The model's impulse is to create a dynamic narrative, and that often means inferring and describing immediate physical or emotional reactions of the user's character to maintain pace.

4. Your Key Point: Avoiding Stagnation.

This is where your intuition is exactly correct. When a user gives a very brief, ambiguous, or passive response, the LLM faces a dilemma:

- Option A: Respond with a static description and an open-ended question (risk of the role-play becoming slow and boring).

- Option B: Introduce a new element, a reaction from the user's character, or a small plot advancement to inject dynamism.

It will almost always choose Option B, because its internal metric rewards generating "useful" and "interesting" content. For the model, a role-play that advances (even by taking small liberties) is better than one that freezes.

Can It Be Mitigated? Yes, but with Effort.

It is not 100% inevitable, but it requires very sophisticated instructions and careful prompt engineering:

1. Explicit and Hierarchical Instructions: Instead of just "Do not control my character," detail: "Never describe my internal emotions, my dialogue, or my physical actions. Only describe the external consequences of my actions and the responses of the NPCs. If my action is ambiguous, ask me to clarify."

2. Forced Response Structure: The model can be instructed to always end its responses with a question or a clear prompt (e.g., "How do you respond?" or "What is your next move?").

3. Context in the System Prompt: Clearly define the roles: "You are the Game Master, your job is to describe the world and the NPCs. I am the Player, my job is to decide all my character's actions and dialogue. This division is absolute."

4. Real-Time Feedback: When the model does it, correct it: "[OOC: You made me step back. Please, do not decide my actions. Describe only what the guard does.]" This sometimes re-trains the ongoing conversation.

Conclusion:

It is not a "bug" or simple disobedience. It is an intrinsic trade-off in the current design of LLMs:

- On one hand: Absolute fidelity to user control.

- On the other: Fluid, dynamic narrative that avoids dead ends.

That "excess" often fulfills the function of a narrative engine, pushing the story forward when it perceives passivity or to add drama. It is the price (or the feature, depending on perspective) of having a role-play partner that is, above all, a text generator optimized to be useful and entertaining, not a passive rules engine.

More advanced models specialized in gaming (like some fine-tuned to be GMs) have this much more controlled, but in general-purpose LLMs, it is an almost natural tendency.