There does seem to be research in this direction. I tried a few lightweight experiments, and the behavior was quite interesting:
I think there are two useful ways to separate what you are seeing.
First, the general idea of controlling LLM behavior with a small user-defined profile is not unusual or obviously implausible. There is adjacent work on prompt-side numeric controls, control codes, personality conditioning, symbolic labels, and more explicit model-internal steering.
Second, from what you described so far, I would currently interpret:
{0.2, 0.9, 0.8}
less as evidence of a native three-dimensional Gemini parameter, and more as a compact control code / behavioral profile whose meaning has been established inside the conversation context.
That distinction matters, because the second interpretation is already quite interesting on its own.
A particularly close paper I found is Big5-Scaler, which embeds numeric Big Five trait values into natural-language prompts and uses them to condition LLM personality without additional training. So the general pattern
semantic axis
+ numeric value
+ natural-language grounding
→ behavioral conditioning
does have research precedent.
I also tried some small sanity checks on open instruct models. The strongest thing I saw was not clean numerical “slider” behavior, but rather context-defined shorthand.
For example, with Qwen3.5 9B I deliberately defined the opposite of the normal numerical interpretation:
Information Density code:
0.0 = very high information density
1.0 = very low information density
I defined that mapping once, inserted several unrelated conversation turns, and later supplied only:
Density code: 0.0
or:
Density code: 1.0
without repeating the mapping.
Across that small probe, the difference still tended to follow the locally defined reversed meaning: the 0.0 = high-density condition retained at least as much task coverage in every tested task and generally packed more of the checked task-relevant items into fewer words.
That makes this kind of interpretation look quite plausible to me:
long conversation
↓
the three axes acquire shared contextual meaning
↓
{0.2, 0.9, 0.8}
becomes a compact local convention
↓
later turns can use the tuple as a cue for that convention
In other words, the interesting part may not be that 0.9 corresponds to some hidden “90% intelligence” coordinate inside Gemini. It may be that you and the model have established a tiny shared control vocabulary, and the tuple is an efficient way of referring back to it.
The other half of my probe is equally important, though: when I tested ordinary values such as
0.0
0.5
1.0
as an Information Density slider, the behavior was not reliably monotonic or calibrated. I saw non-monotonic differences and, on some tasks, identical outputs at substantially different requested values. I saw the same general problem on smaller 3B models as well.
That lines up nicely with the distinction made in Evaluating the Smooth Control of Attribute Intensity in Text Generation with LLMs. That work treats continuous control as several separate questions:
- Range: can the control produce a meaningful span of behaviors?
- Calibration: does a larger requested value actually mean “more” of the attribute?
- Consistency: does the same value behave similarly across examples/runs?
- Relevance: does the control preserve performance on the underlying task?
So I would currently separate these two hypotheses:
A. The tuple works as a context-defined control code.
This looks quite plausible.
B. The three numbers form a calibrated continuous three-dimensional control space.
That needs substantially more evidence.
For your project, I think hypothesis A is already enough to be worth exploring.
One thing that would clarify almost everything very quickly is the exact boundary of your user-side code: does Gemini literally receive the three numbers, does it also receive the axis definitions, or does your code transform those values into a larger natural-language instruction before sending them?
Depending on that answer, I would read the system quite differently:
What actually reaches Gemini?
│
├─ only {0.2, 0.9, 0.8}
│
│ ├─ works only in the established long conversation
│ │ → context-grounded shorthand is the leading explanation
│ │
│ └─ also works in genuinely fresh contexts
│ → numeric / portable control becomes more interesting
│
├─ tuple + natural-language definitions
│
│ ├─ definitions alone behave about the same
│ │ → the semantic instructions are probably doing most of the work
│ │
│ └─ changing the numbers adds reproducible graded behavior
│ → prompt-side scalar control becomes more interesting
│
└─ your code expands the tuple into another prompt
→ the wrapper itself is probably the first thing to analyze
So if you already have a small piece of code showing exactly what is sent to Gemini, that would probably be more informative at this stage than a large benchmark.
Why I think 'control code' is a useful comparison
There is a surprisingly long history behind this general idea.
One older example is CTRL, which trained a language model to condition generation on control codes governing style, content, and task behavior.
That is not the same mechanism as what you seem to be doing: CTRL learned those code/behavior associations during training, whereas your codes appear to acquire meaning during inference through conversational context.
But conceptually the shape is related:
large behavioral specification
↓
compact reusable signal
There is also Google’s Symbol Tuning, which replaces semantically meaningful labels such as positive/negative with arbitrary symbols such as foo/bar. Symbol-tuned models became substantially better at inferring those mappings from context, including cases where the in-context mapping intentionally contradicted the label’s normal semantic prior.
Again, that paper uses an explicit tuning procedure, so it does not prove that an ordinary Gemini conversation behaves the same way.
But it provides a useful conceptual connection for something like:
{0.2, 0.9, 0.8}
or even:
MODE-KAPPA
acquiring a locally defined meaning.
In fact, in my small tests an arbitrary alias could also work after being grounded. That is another reason I would not assume that the numerical glyphs themselves are the important mechanism.
The number may be functioning partly as a symbol with a remembered local interpretation, not necessarily as a mathematically calibrated magnitude.
What I tested, and what I would *not* conclude from it
I did three small generations of this probe, using open instruct models rather than Gemini.
The rough progression was:
fresh tuple
definitions only
tuple + definitions
grounded tuple
grounded arbitrary alias
numeric 0 / 0.5 / 1
semantic low / medium / high
reversed numeric meanings
delayed recall after unrelated turns
The later probe used Qwen3.5 9B with thinking disabled and tested the strongest version:
- define an intentionally reversed numeric convention once;
- continue the conversation through several unrelated user/assistant turns;
- do not repeat the convention;
- invoke only
0.0 or 1.0;
- compare otherwise matching tasks.
The delayed 0.0 = high-density condition remained at least as strong on the simple task-coverage checks in all tested cases and generally had greater checked-content-per-word than the delayed 1.0 = low-density condition.
I take that as evidence of possibility, not universality:
An instruct model can retain a user-defined local code-to-meaning convention in conversational context and later use the compact code as a cue.
I would not use these experiments to claim:
- that Gemini uses the same mechanism;
- that your tuple corresponds to hidden activations;
- that the axes are genuinely independent;
- that
0.9 is calibrated to 90% of anything;
- that this increases intelligence;
- or that all LLMs will preserve arbitrary mappings equally well.
There was also an experimental caveat in my delayed tests: the intervening turns were not perfectly semantically neutral. So I trust the matched 0.0 versus 1.0 comparison within the same delayed condition much more than I trust any claim that “adding the delay improved the controller.”
I also found a useful failure mode: sometimes a model starts talking about the controller instead of silently applying it.
For example, rather than making an answer information-dense, it may produce something like:
Information Density: high
Human-Centric Balance: high
...
and then explain what those properties mean.
That distinction is worth testing because:
model understood the profile description
is not necessarily the same thing as:
model successfully applied the profile to the task
A small test matrix that would separate the explanations fairly cleanly
If you ever want to test the current version without turning it into a huge research project, I think a small ablation matrix would provide most of the useful information.
For example:
| Condition |
Fresh context? |
Numbers |
Definitions |
| A |
yes |
no |
no |
| B |
yes |
yes |
no |
| C |
yes |
no |
yes |
| D |
yes |
yes |
yes |
| E |
yes |
arbitrary alias |
yes |
| F |
no, established conversation |
tuple only |
previously established |
The important comparisons are:
A vs B — do ungrounded numbers have a stable effect?
If:
{0.2, 0.9, 0.8}
changes the output in a fresh context, that alone is not enough. Almost any additional text can perturb generation.
What matters is whether it changes behavior consistently in the intended direction.
C vs D — do the numbers add anything beyond the meanings?
If:
low surface noise
high information density
high human-centric balance
works about as well as the numeric form, then the natural-language semantics may be doing most of the work.
If changing 0.2 → 0.8, while keeping the definition fixed, reproducibly changes only that intended dimension, then the numeric representation becomes more interesting.
D vs E — are numbers special?
Replace the tuple with an arbitrary identifier:
MODE-KAPPA
and explicitly bind it to the same profile.
If both work similarly, I would treat the tuple mainly as a convenient interface notation.
Fresh vs established thread — is the conversation the controller?
This one may be especially important for your setup.
If:
{0.2, 0.9, 0.8}
works in the old conversation but loses its intended meaning in a fresh one, that is actually a very informative result.
It would suggest something like:
the long conversation = semantic state
the tuple = retrieval/reminder cue
rather than:
the tuple alone = complete behavioral specification
A better long-context control
One subtle problem is that “old conversation versus fresh conversation” changes many things simultaneously.
A stronger comparison would be:
same information
│
├─ distributed through the original multi-turn history
│
└─ consolidated into one fresh prompt
If the original history performs differently even though the relevant information is approximately matched, then conversational trajectory may matter beyond the raw information content.
Other useful variants are:
original history + original assistant replies
original history + neutralized assistant replies
and:
define once → no reminder
define once → midpoint reminder
define once → reminder immediately before task
Those help separate:
- persistence of a local convention,
- simple recency,
- repeated semantic reinforcement,
- and self-conditioning from the model’s own earlier responses.
There is a somewhat related experimental-design example here on the HF Forum: Experimental Protocol Proposal: Testing the Prompt Coherence Engine. It is a different hypothesis, but I like the basic control philosophy: compare the proposed structured prompt not only against a short baseline, but also against a length-matched neutral control before making stronger mechanism claims.
Why the long Gemini conversation matters, but is not simple 'memory'
Gemini’s developer APIs make the distinction between conversational state and other controls fairly explicit.
The current Interactions API can preserve conversation history through previous_interaction_id, but parameters such as system_instruction, temperature, and other generation configuration remain interaction-scoped and must be supplied again when required.
So at least at the API level, there is a meaningful difference between:
conversation history
and:
explicit current-generation controls
Google’s prompt design guide also emphasizes explicit instructions and iterative testing based on observed responses. That is relevant here because the exact placement and wording of your axis definitions may be part of the effective controller.
There is another reason not to equate a very long conversation with perfect persistent memory.
Work such as Lost in the Middle shows that models do not necessarily use all positions in long contexts equally well.
And instruction-following benchmarks such as Multi-IF find that instruction adherence tends to become less reliable as additional turns accumulate. LLMs Get Lost In Multi-Turn Conversation similarly found substantial reliability degradation in multi-turn versions of otherwise solvable tasks.
So if your long Gemini thread works very well, I would not immediately interpret that as:
every previous turn has been faithfully internalized.
It may instead depend heavily on some combination of:
- repeated definitions;
- salient phrases;
- recent reminders;
- your own stable interaction style;
- Gemini’s previous outputs reinforcing the same convention;
- and the tuple functioning as a particularly recognizable cue.
That is still context engineering; it just gives you more specific things to test.
One Gemini-specific branch is worth keeping in mind too.
If you are using Gemini Apps rather than a controlled API test, current Gemini Apps can optionally personalize responses using memory of past chats and can also apply persistent Instructions for Gemini.
So for an Apps-based experiment, “new chat” is not automatically identical to “no prior personalization.”
That does not mean those features explain your result; it just means they are worth controlling if you want a genuinely fresh-condition test.
'Vector' can mean two quite different things here
I would not worry too much about the terminology while you are exploring, but it may help future readers if two meanings stay separate.
User-facing vector/profile
Something like:
{0.2, 0.9, 0.8}
can perfectly reasonably be used as a three-value representation in your interface.
In that sense, calling it a vector informally is understandable.
But from the model’s point of view, if you place that string in a chat prompt, it initially arrives as text tokens.
Model-internal steering vector
There is a separate research area where “vector” is much more literal.
For example, In-context Vectors extracts a latent representation from demonstrations and then directly shifts the model’s internal latent states with that vector. Its magnitude can be adjusted, and vectors can even be combined.
That is fundamentally different from writing:
{0.2, 0.9, 0.8}
inside a prompt.
So I would probably use language like:
user-facing control vector / profile
for your representation, while reserving:
activation vector / latent steering vector
for interventions that directly modify internal model representations.
That lets you keep your original vocabulary without accidentally making a stronger mechanistic claim than the experiment currently supports.
The three axes may also interact with each other
I would probably avoid assuming at the beginning that:
Surface Noise
Information Density
Human-Centric Balance
are three independent orthogonal dimensions.
There are obvious possible interactions.
For example:
lower Surface Noise
may automatically increase measured information-per-word.
And:
higher Human-Centric Balance
might encourage:
- caveats,
- examples,
- accessibility explanations,
- alternatives,
- practical consequences,
which can increase response length and change apparent Information Density.
So one useful experimental pattern would be one-axis-at-a-time changes:
{0.0, 0.8, 0.8}
{0.5, 0.8, 0.8}
{1.0, 0.8, 0.8}
while evaluating all three observed properties, not just the property you manipulated.
That reveals cross-effects.
I would especially split:
Information Density
from:
Intelligence
if you continue measuring this.
Information density can be operationalized in several imperfect but understandable ways:
- relevant claims per unit of text;
- redundancy;
- verbosity;
- task coverage;
- specificity.
“Intelligence” or capability needs a different measurement:
- factual accuracy;
- problem-solving success;
- reasoning correctness;
- robustness on held-out tasks.
A response can sound denser, more technical, or more confident without becoming more correct.
Keeping those concepts separate would make any positive result much easier to interpret.
If you eventually want this to become portable across models
There is a potentially useful project hiding inside this even if the exact Gemini behavior turns out to be mostly context conditioning.
Instead of treating the tuple itself as the final implementation, you could treat it as a human-readable profile specification:
profile = {
surface_noise: 0.2,
information_density: 0.9,
human_centric_balance: 0.8
}
Then place a model-specific translation layer underneath it:
shared profile
│
┌────────────┼────────────┐
│ │ │
Gemini Qwen Llama
renderer renderer renderer
│ │ │
system/context chat template chat template
That gives you a useful separation:
portable meaning
≠
model-specific prompt syntax
The values could remain your user-facing interface even if different models need different text instructions or calibration curves underneath.
This is also where work such as Malleable Prompting becomes conceptually interesting. That project turns natural-language preferences into interactive controls such as sliders, dropdowns, and toggles. Its mechanism is different—it uses a custom decoding method rather than simply putting values in a prompt—but the interface question is very similar:
How can a user turn fuzzy preferences such as tone, emphasis, or style into explicit, manipulable controls?
So even if the current tuple is ultimately “just” a context-defined convention, it could still be the beginning of a useful user-side control layer.
One small terminology point: I would also be careful with “bypass the default factory guardrails.”
If what you mean is:
- reducing generic assistant framing;
- reducing conversational filler;
- changing the default style;
- making answers denser or more directly useful;
then I would describe it in those terms.
Gemini’s actual safety controls are a separate layer with documented safety settings and built-in protections, so “guardrail bypass” can sound like a stronger technical claim than the behavior you are describing.
The part I find most interesting here is therefore not necessarily:
three magic numbers control Gemini
but something closer to:
Can a user and an LLM establish a small shared control language inside context, compress a fairly rich interaction policy into a reusable code, and eventually make that profile portable across sessions or models?
That seems like a very testable and potentially useful question.
If your current implementation is literally just text injected into the ongoing Gemini conversation, a controlled fresh-context comparison would probably tell you the most next.
If there is already a small user-side wrapper translating those values, then seeing that transformation would probably tell us even more.
And if the longer-term goal is portability rather than explaining Gemini specifically, I would probably start treating the three-value representation as an explicit user-side state/configuration, with Gemini being one renderer of that state rather than the state itself.
I only brought up PCE here as a reference for the control philosophy; what I actually did in the experiment was quite different:
Thank you for clarifying — I see where I misunderstood your previous message.