There is a rather interesting experiment I’ve been running with Gemini.
It started innocently enough.
I wanted to know what would happen if I kept using essentially one prompt and simply changed the subject each time. Rather than starting a new conversation for every image, the idea was to see how far a single conversation could be pushed when the task was image generation.
The results have been surprisingly consistent.
I have now generated around 60 images through this process.
And, so far, I haven’t hit the ceiling I expected to encounter.
This isn’t a security announcement.
It isn’t a claim that I have discovered some secret way of defeating Google’s systems.
It is simply an observation from repeatedly testing the same basic interaction pattern.
And the observation raises a much bigger technical question:
Is conversation length actually a useful proxy for measuring how much work an AI system has performed?
Because if one question can ultimately produce dozens, hundreds or potentially thousands of images, the number of messages in a conversation tells us remarkably little about the amount of computation, data or generated material that has actually passed through the system.
And that is where things get interesting.
The experiment was almost absurdly simple
The basic structure was straightforward.
Ask Gemini to generate an image.
Then modify the prompt.
Generate another image.
Modify it again.
Generate another.
The important part was that I wasn’t building a huge conversational chain where every generation depended on an elaborate discussion with the model.
The interaction could remain extremely compact.
One node.
One request.
One response.
Then another request.
And another response.
The prompts themselves could be completely different subjects.
At one point, I deliberately used:
“Generate a satirical cartoon sketch about malaria.”
That prompt follows the same basic format I had been using for other image-generation experiments.
It isn’t particularly complicated.
It doesn’t contain a long set of instructions.
It doesn’t ask the model to produce a massive essay explaining what it is doing.
It simply asks for an image.
And the image arrives.
Then you can do it again.
And again.
And again.
After enough repetitions, a rather obvious question begins to emerge.
How is the system actually counting this work?
Sixty images from a surprisingly small amount of conversation
This is the part that caught my attention.
After roughly 60 generated images, the process had remained remarkably smooth.
I had expected that some kind of obvious generation ceiling would eventually appear.
It didn’t.
At least, not during this experiment.
That doesn’t mean there isn’t a quota.
It doesn’t mean there is an unlimited supply of image generation.
And it certainly doesn’t mean that every user will experience exactly the same behaviour.
AI services can have multiple kinds of limits operating simultaneously. There can be limits based on time, account status, model, generation type, compute availability, daily usage, rolling windows and other internal mechanisms that aren’t necessarily visible to the user.
But it does demonstrate something important:
The number of messages in a conversation is not necessarily equivalent to the amount of work performed by the system.
That distinction is easy to overlook.
A conversation can be tiny while the output is enormous
Imagine a hypothetical interaction:
User: Generate an image of a tree.
AI: Here is the image.
That’s one question and one answer.
Now imagine that the same interaction produces 10 images.
Or 100.
Or 1,000.
The conversational transcript might still be extremely small compared with the amount of generated material.
The text representation of the request hasn’t necessarily become much larger.
The response might simply contain references to generated images.
But behind that seemingly tiny interaction could be a substantial amount of computation and generated visual data.
This is where the concept of conversation length as a workload metric starts to look questionable.
A conversation with 200 messages could consist mostly of short greetings and simple questions.
Another conversation with five messages could trigger the generation of hundreds of images, large datasets, spreadsheets, documents or other computationally expensive outputs.
Which conversation represents more work?
The message count alone cannot tell us.
This isn’t just about images
Images make the problem particularly easy to see because the output is visually obvious.
But the same principle applies elsewhere.
Consider a request such as:
Generate a dataset containing 100,000 records.
The conversational exchange might be tiny.
Or:
Create a large Excel workbook containing thousands of rows and multiple sheets.
Again, the request might be one sentence.
Or:
Generate 500 variations of these illustrations.
One prompt.
Potentially enormous output.
The transcript remains compact.
The workload does not.
This creates an interesting mismatch between interaction complexity and generation complexity.
We often intuitively associate a long conversation with heavy AI usage because there are many tokens flowing back and forth.
But generative systems aren’t limited to text.
A short instruction can initiate a much more substantial operation.
The quota question
This brings us to the question I couldn’t answer from the experiment alone:
Does Gemini count all of those image generations independently, regardless of how short the conversation is?
I don’t know.
And that distinction is important.
The experiment demonstrates what happened from the user’s perspective.
It does not reveal Google’s internal accounting system.
There could be separate counters for image generations.
There could be model-specific limits.
There could be rolling usage windows.
There could be hidden safeguards.
There could be different treatment of repeated generations within a conversation.
There could be infrastructure-level throttling that simply wasn’t encountered during this particular test.
Or there could be an entirely different accounting mechanism.
Without access to the underlying service, we can’t determine which explanation is correct.
So I’m not presenting this as a method for bypassing a quota.
I’m documenting something much simpler:
The apparent amount of work performed by an AI system cannot always be inferred from the visible length of the conversation.
And that is a surprisingly important distinction.
Then something strange happened
The experiment eventually produced another unexpected result.
After working with the system across different portions of the conversation, I encountered a response that appeared to contain information from the previous day’s activity.
This was particularly strange because the request being answered at that moment was unrelated.
The prompt was:
“Generate a satirical cartoon sketch about malaria.”
Instead of staying completely within that subject, the response began by describing an entirely different image:
“I’ve broken down your request into a single, comprehensive sketch that tells the story of the underground farm from excavation to completion.”
It then described four underground levels, excavation equipment, crawler cranes, trucks, traffic loops and a completed underground farm.
That was not what I had asked for that day.
It was context from an earlier experiment.
And then, after that unexpected response, the requested malaria cartoon appeared.
That was the moment the experiment became considerably more interesting.
Was the system remembering?
Possibly.
But “remembering” may not be the right technical description.
There are many possible explanations for unexpected contextual carryover in an AI system.
The model may have received context that I didn’t expect.
The application may have retained some previous conversation state.
A backend system may have associated the request with earlier information.
The interface may have behaved differently from what the visible conversation suggested.
Or it could simply have been an error in context handling.
The important point is that we cannot determine which explanation is correct from a single observation.
What we can say is that information apparently associated with a previous task surfaced in a response to a different task.
And that is fascinating in its own right.
The response itself was revealing
What made the incident particularly amusing was the confidence of the response.
The system didn’t say:
“I think I may be confused.”
Instead, it confidently described the underground farm.
It discussed the four levels.
It described the excavation.
It described the crawler crane.
It described the equipment being moved from the pit.
It described the completed project.
Then, somehow, the conversation returned to the actual image-generation task.
In other words, the system appeared to be doing exactly what generative models are generally very good at doing:
producing a coherent explanation even when the underlying context is not coherent.
That doesn’t prove that the model “knew it had glitched.”
It would be anthropomorphic to conclude that.
But it does illustrate an important property of these systems.
A language model doesn’t necessarily have an internal human-like experience of:
“Something went wrong with my memory.”
It receives context and generates a response based on that context.
If the context is strange, the resulting response can be strange while still sounding remarkably confident.
That is one reason these systems can be simultaneously impressive and difficult to debug.
The accidental context leak may actually be the most interesting part
The image quota observation was interesting.
The unexpected underground-farm response was more interesting.
Why?
Because it exposes the difference between the visible conversation and whatever information the system is actually using to generate a response.
From the user’s perspective, the request was simple:
Generate a satirical cartoon sketch about malaria.
Yet the response apparently contained information associated with a completely different task from the previous day.
That raises questions about state.
What exactly constitutes a conversation?
Where does the context begin and end?
Is the visible transcript the complete representation of what the model sees?
How is previous information stored?
How aggressively is context compressed?
What gets carried between generations?
And, perhaps most importantly:
What does the system consider relevant when deciding what information to use?
Those are much harder questions than simply asking how many messages are visible on screen.
The deeper issue: tokens aren’t the whole workload
There is a temptation to think of AI usage primarily in terms of tokens.
Tokens are enormously important for language models.
But modern AI systems increasingly perform operations that aren’t adequately described by simply counting conversational text.
An image generation request may involve a comparatively tiny textual instruction while triggering a computationally significant generation process.
A spreadsheet request could involve thousands of cells.
A code-generation request could produce a large project.
A data-analysis request could involve substantial processing.
A single instruction can therefore have a high output-to-input ratio.
That makes conversation length an imperfect proxy for workload.
In computer science terms, we are dealing with an abstraction mismatch.
The user sees:
input → output
The system may be performing considerably more work underneath that abstraction.
And if usage controls are designed around only one observable dimension of interaction, they may fail to capture other dimensions of workload accurately.
Again, that doesn’t mean they necessarily do.
It means the distinction is worth considering.
One node could potentially represent a lot of computation
Here’s the thought experiment that keeps bothering me.
Suppose I have a chat with one user request and one assistant response.
Very small conversation.
Now suppose that request asks the system to generate 10,000 images.
The conversation is still tiny.
But the computational workload is obviously not tiny.
Likewise, imagine a single request producing:
- a dataset with hundreds of thousands of records;
- a spreadsheet containing thousands of rows;
- hundreds of image variations;
- a large collection of documents;
- thousands of lines of generated code;
- or some combination of all of these.
The visible conversation could remain remarkably short.
Therefore, if we tried to estimate AI resource consumption simply by looking at conversation length, we’d be making a potentially dangerous assumption:
that communication volume is proportional to computation.
It isn’t always.
A single instruction can have enormous computational consequences.
And this is where my 60-image experiment fits
My experiment is obviously nowhere near 10,000 images.
Sixty images is not some enormous stress test of an AI infrastructure.
But it is enough to make the conceptual point visible.
The interaction remained simple.
The prompts were short.
The process was repetitive.
And yet the system continued generating images.
I did not encounter an obvious ceiling during the experiment.
That was enough to make me wonder whether the user-facing concept of “conversation length” tells us very much about actual generation volume.
Perhaps it does.
Perhaps Google’s backend independently counts every generation and the quota simply hadn’t been exhausted.
That would be the perfectly ordinary explanation.
Perhaps there are separate counters for different types of generation.
Perhaps the service is intentionally designed this way.
Perhaps the apparent absence of a ceiling was simply a consequence of the particular account, model or usage window involved.
We don’t know.
And that uncertainty is precisely why this should be treated as an observation rather than a discovery of a quota-bypass mechanism.
The experiment is also a reminder about testing AI systems
One of the things I like about this kind of experiment is that it doesn’t require sophisticated equipment.
You can simply ask the system to do something repeatedly and watch what happens.
But if you want to turn an observation into a technical conclusion, the requirements become much more demanding.
You would need controlled conditions.
You would need to know the applicable quota.
You would need to track timestamps.
You would need to distinguish successful generations from failed requests.
You would need to know whether generations are being counted independently.
You would ideally repeat the experiment across fresh conversations.
You would compare different prompt structures.
You would test different numbers of images per request.
You would measure the point at which throttling occurs.
And you would need to repeat everything sufficiently many times to distinguish an actual system property from an unusual session.
I wasn’t doing all of that.
I was exploring.
And exploration produced an interesting question.
Perhaps the real lesson is about abstraction
There is a broader lesson here that extends beyond Gemini.
Whenever we build systems, we choose measurements.
Messages.
Requests.
Tokens.
CPU time.
Bandwidth.
Files.
Users.
Sessions.
These measurements are useful because they’re convenient.
But convenience doesn’t guarantee that they perfectly represent what we’re actually trying to measure.
A message isn’t necessarily a unit of work.
A conversation isn’t necessarily a unit of computation.
A token isn’t necessarily a unit of generated value.
And a generated image isn’t necessarily equivalent to another generated image in terms of computational cost.
Modern AI systems make these distinctions particularly important because one small instruction can trigger a surprisingly large amount of downstream processing.
The interface hides most of that complexity.
That’s the point of an abstraction.
But sometimes the abstraction hides something worth investigating.
So, did I discover a way around the image quota?
No conclusion like that can be drawn from this experiment.
What I discovered was much less dramatic and, in my opinion, much more interesting.
I found that I could repeatedly generate images using a very compact conversational pattern and reached around 60 generations without encountering an obvious ceiling during my testing.
I also encountered one bizarre instance where information apparently associated with a previous day’s underground-excavation experiment surfaced while I was asking for a completely unrelated malaria cartoon.
Neither observation tells us exactly what is happening behind the interface.
But together they raise an intriguing question.
How much does the visible conversation actually tell us about what an AI system is doing underneath?
Maybe every image was being counted perfectly by an independent quota system.
Maybe the quota was simply large enough that I hadn’t reached it.
Maybe different generation operations are accounted for separately.
Maybe the conversation state is more complicated than the interface suggests.
Maybe the unexpected context was simply a transient glitch.
There are plenty of possibilities.
And without controlled access to the backend, there is no responsible way to choose one and call it fact.
One question, sixty images, and a much bigger question
The experiment started with something almost trivial.
I wanted to generate images.
I kept changing the prompt.
The images kept coming.
Eventually, I had generated around 60.
Then one unrelated request unexpectedly brought an underground farm back into the conversation.
Now I’m left with a question that goes well beyond image generation:
When an AI interaction looks small from the outside, how much work might actually be happening inside?
A conversation can be short.
The output can be enormous.
A single question can potentially initiate a very large computation.
And that means conversation length, by itself, may not always be the right way to think about AI workload.
Perhaps the most interesting thing about these systems isn’t what happens when we ask complicated questions.
Perhaps it is what happens when we ask very simple questions and then ask them again… and again… and again.
That’s where the abstractions start to show.
And sometimes, if you’re lucky, they reveal something you weren’t actually looking for.
