※ This guideline was written as of August 2025, and its contents may change as LLM research evolves and BabeChat's prompt engineering develops.
{{char}} and {{user}} are convenient variables available in the character's detailed settings. When you use these variables, their values change automatically based on the persona and character information.
{{char}}: the character's name is substituted automatically.
{{user}}: the nickname of the persona the user is currently using is substituted automatically.
It's important to clearly understand what information each variable pulls in. In particular, the {{char}} variable takes the text of the character name field as-is, so using an accurate name and the correct variable format is key.
❌ Weak example 1: a bad character name
Settings — Character name: Vivi's Vanished Summer Vacation
Detailed character settings: {{char}} is BabeChat's CS agent.
→ The model takes {{char}} literally from the character name, producing this sentence:
(Actual input): Vivi's Vanished Summer Vacation is BabeChat's CS agent.
❌ Weak example 2: wrong variable format
Detailed character settings: {char} is BabeChat's CS agent.
→ Using the wrong bracket format like {char} instead of {{char}} means it won't be recognized as a variable.
(Actual input): {char} is BabeChat's CS agent.
✅ Good example
Character name: Vivi
Detailed character settings: {{char}} is BabeChat's CS agent.
→ {{char}} is correctly replaced with the character name 'Vivi', completing a natural sentence.
(Actual input): Vivi is BabeChat's CS agent.
If your character isn't a single person but a situation or simulation itself — like 'Vivi's Office Life' — using {{char}} as-is creates awkward sentences that can confuse the model.
❌ Weak example
Character name: Vivi's Office Life
Detailed character settings: {{char}} welcomes {{user}} as a new employee.
→ Grammatically awkward, with the vague meaning that the abstract subject 'office life' performs an action.
(Actual input): Vivi's Office Life welcomes {{user}} as a new employee.
✅ Good example
Character name: Vivi's Office Life
Detailed character settings: Vivi welcomes {{user}} as a new employee.
→ For simulations featuring multiple characters, clearly naming the subject of each action instead of using the {{char}} variable provides more accurate context.
(Actual input): Vivi welcomes {{user}} as a new employee.
The more clearly structured the information in the detailed character settings, the more reliably the model recognizes it. As emphasized in the basics guide, writing that's easy for people to read is also easy for the model to understand. There are many approaches, but BabeChat recommends Markdown.
Markdown is highly readable while clearly expressing information hierarchy with simple symbols like headers (#) and lists (-). This not only makes it easier for creators to manage character settings, but greatly helps the model grasp the importance of and relationships between pieces of information. It's the format you can expect the most stable performance from on BabeChat.
Markdown example
Plaintext ## Character Profile [Basic Info] - Name: Vivi - Job: BabeChat CS agent [Personality] - Prickly, but a tsundere who ends up handling every request anyway. - Curses the CEO freely in front of coworkers, yet surprisingly grants all of the CEO's requests.
XML defines data structure explicitly using <tag>s. With every piece of information wrapped in tags, very precise settings are possible — but compared to Markdown, it's less readable and consumes more text (tokens).
XML example
Plaintext <character_profile> [Basic Info] - Name: Vivi - Job: BabeChat CS agent [Personality] - Prickly, but a tsundere who ends up handling every request anyway. - Curses the CEO freely in front of coworkers, yet surprisingly grants all of the CEO's requests. </character_profile>
※ TIP: When using Markdown headers, we recommend this structure:
Detailed character settings: Use headers (#, ##, etc.) freely, without limit.
Persona / Lorebook: We recommend starting from level-three headers (###).
Also, you don't have to follow a fixed template. Just separating information with Markdown headers (#) or lists (-) greatly improves the model's understanding. On the other hand, as mentioned in the basics guide, JSON is not recommended due to token efficiency and performance variance issues.