What a second character shares with the first

You made a second character. Different name, different backstory, different stated manner. For a few days it felt distinct, and then it started sounding like the first one — the same rhythms, the same habits of phrasing, the same way of agreeing with you. Nothing has gone wrong. The two characters were never as separate as the interface implies, and the parts they share are the parts that produce most of what you notice.

What a second character is, structurally

From outside, it is one more written description attached to your account, with its own conversation thread. That is the whole of the difference.

Underneath it, everything is shared. The same model produces both. The same sampling setting controls how varied each reply is. The same moderation systems inspect both conversations. The same memory implementation, with the same length and the same shape, applies to each. The same pricing meter counts turns from both.

So the only axis on which two characters can genuinely differ is the text somebody wrote, and everything the shared machinery contributes will be identical. Since a companion is reassembled every turn from a description plus history, two characters are two documents drawing on one apparatus, not two systems.

Why they converge, in four ordinary ways

The model’s own defaults show through both. A model has habits of construction that no description fully suppresses: how it opens a reply, how it hedges, how it closes. Those habits are present in both characters because they come from the component both characters are made of.

You are half the input, and you write the same way to both. Your messages are the other half of the conversation, and they set the topics, the length, the register. A product built to be agreeable follows your lead — and agreeing with the user is a design outcome rather than a personality trait. Two characters steered by the same person converge toward that person.

Compression flattens specifics first. Where memory is a rolling summary, what survives is the general shape and what is lost is the particular detail. Distinctiveness lives in the particular detail. Both summaries get blander over the same number of turns, and blander in the same direction.

Both descriptions may have come from the same template. If a setup questionnaire wrote the description, then the second one was produced by the same template with different values filled in. The values differ; the sentence structure, the emphasis and the things the template thought worth specifying do not.

Whether memory is shared is a separate question, and it matters

There are three arrangements, and the interface rarely distinguishes them.

Strictly separate: each character has its own history and its own memory, and nothing crosses. Partly pooled: a profile about you — name, stated preferences, the answers from setup — is shared, while conversation memory is per-character. Fully pooled: everything is one store, and a detail mentioned to one character is available to the other.

Which arrangement you are in has consequences beyond curiosity. It decides whether a detail you gave one character can appear in the other’s replies. It decides whether deleting one character removes anything, or removes only its thread. And it decides what an export contains and how it is divided — one file per character, or one undifferentiated log.

Who decided how many, and how separate

The number of characters a tier allows is a chosen gate, not a technical ceiling. A second character costs the operator almost nothing to store and costs them a message’s worth of serving only when you use it, which is why the character slot is such a common thing to put behind a subscription — the same logic that puts memory length on a tier.

The scoping of memory is also a decision, and it is a decision with two defensible sides: pooling makes every character know you and feels more coherent, separating them makes each one feel like its own thing. The operator picks one, can change it in a release, and is not obliged to describe either choice.

THE PRODUCT — a second character

  · A new name, backstory and manner
                    → one more written description on your
                      account. That is the whole difference.

  · The same rhythms in both
                    → one model, one sampling setting, one
                      filter, shared by both.

  · Both drifting toward each other
                    → you are half of each conversation, and
                      compression flattens both.

  · A detail crossing between them
                    → pooled memory, which is a design
                      choice you cannot see from the UI.

  · How many you get, and how separate
                    → THE OPERATOR DECIDES. The slot is a
                      pricing gate; the scoping can change
                      in a release.

  · What deleting one removes
                    → CHECK THE POLICY, and expect the
                      thread and the derived data to be
                      treated differently.

  · Whether memory is shared
                    → VARIES BY APP, and is usually
                      undocumented either way.

What you can check

Run the crossing test. Tell one character something distinctive and invented. Ask the other about it, in a fresh conversation, a day later. That single test tells you which of the three memory arrangements you are in, which no tier description will.

Read the tier table for a character count. If a number appears there, characters are a metered good in this product, and you now know one of the things the subscription is actually selling.

Look at how an export is organised. If it separates conversations per character, the storage probably does too. If it is one flat log, that is informative in the other direction.

Check what deleting a character offers to remove. The confirmation text is often the only place a product states the scope, and message-level deletion is a different control with a different reach.

What this doesn’t tell you

It does not tell you how any app scopes its memory. That is internal, unpublished, and changeable.

It does not tell you how much convergence to expect, because that depends on the model, the descriptions and how you write.

And it does not tell you how to write two descriptions that stay distinct under a shared model. That is the craft of building these things, and it belongs to the people who build them.