The block of text that tells the model who to be, re-sent with every single message. The fields, the hidden PNG format, and what actually changes the output.
Short answer: a persona prompt, usually called a character card, is the block of text that tells the model who to be, and it is re-sent with every single message you write. It is not a setting the character remembers; it is the character. In a hosted AI girlfriend app it is the description you filled in at signup. In the open ecosystem it is a formal file format with named fields, and it travels around the internet hidden inside a PNG. This page covers what is in one, what actually changes the output, and the trade nobody mentions: every word you add is paid for on every reply, forever.
Language models have no memory between requests. Everything the character knows about being that character has to be re-supplied each time, which is why the app assembles a block of text and puts it in front of your message before sending it off. The persona prompt is the part of that block describing the character: name, appearance, personality, how she talks, what she is to you.
Two consequences follow immediately, and both surprise people. The character cannot "learn" a trait you mention once in conversation, because conversation is transient while the card is permanent. And nothing in the card is private from the model in the way you might assume: it is instruction text, not a database, so a model can be talked into paraphrasing it. The full assembly, and what else rides along with the card, is set out in how AI girlfriends actually work.
Hosted apps hide the structure behind a form. The open ecosystem wrote it down, in a community specification for character cards that was validated in May 2023 and is still what the tooling implements. The fields are worth knowing even if your app never shows them to you, because they are the shape of the thing every app is building underneath.
| Field | What it holds | What it decides |
|---|---|---|
| name | What she is called | Less than you think. It is one token in a wall of text. |
| description | Appearance, situation, hard facts | The bulk of the card, and the bulk of the cost. |
| personality | Traits, in shorthand | Tone, when it is specific. Nothing, when it is adjectives. |
| scenario | The situation you are both in | Where the first exchanges go. |
| first_mes | Her opening message | More than any other field. It sets the register the model imitates. |
| mes_example | Sample exchanges, written as dialogue | Speech style. This is the highest-leverage field in the whole card. |
| system_prompt | Instructions that can replace the app's own | Who wins when instructions conflict. See below. |
| character_book | A per-character lorebook, injected only when a keyword matches | How you get depth without paying for it every message. |
That last one is the clever part of the format and it is the answer to the cost problem further down: a lorebook entry sits outside the permanent block and is pulled in only when the conversation mentions its trigger. Detail on demand instead of detail always.
This is the detail that surprises even people who use these things daily. Character cards are traded as ordinary PNG portraits, and the entire character definition rides along inside the image file itself.
The mechanism is a standard PNG feature: a file is a series of labelled chunks, and one chunk type holds plain text. The V3 specification states that the object "MUST be embedded in the PNG or APNG file as a tEXt chunk", that the chunk "MUST be named ccv3", and that its value is the JSON of the card, base64 encoded. The previous generation used a chunk named chara, which is why most tools still read both.
So the portrait you downloaded is the character. Save it, send it to a friend, and the personality, the example dialogue and the lorebook travel with the picture. It also means a card can carry instructions you never read, which is the practical reason to be careful with cards from strangers: you are running someone else's text with your account, on your bill.
Every token in the persona is re-sent on every message. Not once at setup: every time, for the lifetime of the relationship. Two things follow.
The first is money. A fat card costs the operator more per reply than a lean one, forever, which is why hosted apps cap the length of what you can write and why they are quietly right to.
The second matters more to you. The model can only consider a fixed amount of text at once, and everything shares that space: the persona, the retrieved memories of your actual conversations, the rolling summary, and your message. Every paragraph you add to her description is a paragraph less of room for her to remember you. That is the real cost of the four-hundred-word backstory, and it is why a tight card usually beats an elaborate one after the second week. The forgetting mechanics behind that are in the mechanics guide, and memory is the criterion we weight hardest in how we test precisely because this trade-off is invisible from the outside.
The most common mistake in a persona prompt is telling the model what not to do. Negative instructions are unreliable, and there is a body of research on why.
MIT researchers reported in May 2025 that vision-language models systematically fail on queries containing negation words, performing markedly worse when the request is phrased as an absence. The pattern is not limited to images: the Inverse Scaling Prize, collected in "Inverse Scaling: When Bigger Isn't Better", documented tasks where larger models do worse than smaller ones, negated questions among them. Scale does not fix it.
The intuitive explanation is close enough to the truth: "not" is one small token attached to a vivid one, and the vivid one dominates. Write "don't be shy" and you have put "shy" in the character's description. Write "never mention work" and you have raised the topic. Say what you want instead: "answers quickly and starts new topics herself". Positive, behavioural, present tense.
The card is not the only instruction in the block, and this is where hosted apps and open frontends genuinely diverge.
In the open ecosystem the card can outrank the application: the specification says a card's system prompt field replaces what the user understands as the global system prompt, with the app's original text available as a placeholder if wanted. The card author has authority.
In a hosted app it is the reverse and it is not negotiable. The operator's instructions sit above whatever you typed, they carry the content policy, and they are the reason a persona that says "will discuss anything" still refuses. No wording in your description overrides the layer above it, which is the middle of the three layers we map in what "uncensored AI" actually means. On a character platform, where every character is written by another user under one shared policy, the effect is even starker: the card changes the voice, never the limits. That contrast is the subject of AI girlfriend vs Character.AI.
These are the same instincts behind the five ten-minute probes in the mechanics guide, applied to the one part of the system you control.
A persona prompt is the character, re-sent to the model on every message. Its fields are standardised in an open specification, and cards travel as PNG images with the definition base64-encoded in a text chunk inside the file. Write example dialogue rather than adjectives, phrase everything positively because negation is unreliable, and keep it short, because every word competes for space with the memory of you. And remember that in any hosted app the operator's instructions sit above yours, so the card sets the voice and never the limits. What the rest of the block does is in how AI girlfriends work, and the apps whose personas actually hold up are ranked in our tested rankings.
The adult apps we test are for 18+ only.