A developer changes one sentence in a prompt. The next release sends the customer’s entire conversation history twice.
Both versions answer the test question correctly. The regression appears later, when someone notices that a routine request has become much larger. Looking at the sentence the developer edited will not explain it. Looking at the complete input sent by the application will.
The Gemini API gives you a way to investigate before generating another answer: count the input for the old request and the new request, then change one component at a time. This guide uses Gemini 4 Argon and a deliberately small support application to show how.
The result is a report you can attach to a pull request: what changed, how many input tokens it added, and whether that increase was intentional.
Start with the model you can actually call
Google lists gemini-4-argon in its Gemini model catalog. Use the exact model ID for your test. A product family name is too broad for a reproducible comparison.
If you arrived here while searching for “Gemini 4 Carbon API,” first read the 4SAPI guide to checking Carbon API access. Do not substitute a search term for a documented endpoint. The procedure below targets Argon.
A model’s context capacity answers one question: how much information can the model accommodate? Your application budget answers another: how much information should this particular feature send? A support widget that identifies a shipment does not need to consume the available window simply because it can.
For background on the model’s capacity, see how Gemini 4 Argon’s context window works. Here, the unit of analysis is a single application request.
Reproduce the input your application assembled
Consider a shipment-support feature. Its final input contains four sections:
| Section | Example |
|---|---|
| Instructions | Answer using the supplied shipment record. |
| Customer history | The latest relevant exchange about the order |
| Retrieved record | Shipment number, carrier, and current status |
| Current question | Has the replacement left the warehouse? |
A developer adds a history helper to improve follow-up answers. The older request builder already included that history. The new builder now inserts it twice.
Reading the prompt template will not expose the problem if the duplicate is added after the template is rendered. Capture the assembled input at the boundary immediately before the SDK call. Use synthetic or appropriately sanitized content for the comparison.
Save three files:
before.txt: the input produced by the previous version.after.txt: the input produced by the candidate version.after-without-duplicate.txt: the candidate with only the suspected duplicate removed.
Keep the customer question, retrieved record, and model identical. Otherwise you are measuring a different workload.
Count the three versions without generating answers
Install the Google Gen AI SDK in your development environment:
The following example uses a Google API key via GEMINI_API_KEY. The SDK’s counting method is described in Google’s token-counting guide.
This example measures plain-text inputs. It intentionally does not create a model answer. The counts are remote API results, not estimates obtained by dividing characters by four.
If production uses structured conversation turns, tools, images, or separate system instructions, preserve that structure using the counting interface documented for your route. Counting a flattened text export does not establish the size of a different production request.
Read the delta as evidence, not as a bill
Suppose your report produced these illustrative numbers:
| Version | Input tokens |
|---|---|
| Previous release | 2,400 |
| Candidate release | 4,100 |
| Candidate without the suspected duplicate | 2,550 |
The total increase is 1,700 tokens. Removing the suspected duplicate reduces the candidate by 1,550 tokens. That accounts for most of the increase, but the remaining 150 tokens still deserve an explanation.
Perhaps the new instructions describe a legitimate product rule. Perhaps a second helper added a date or a longer field label. The report narrows the investigation without pretending to identify a cause that was never tested.
Do not multiply the delta by a public list price and present the result as verified savings. Actual charges can depend on the service, route, caching, and other billing conditions. The count also excludes an answer that has not yet been generated.
When evaluating a 4SAPI route, reconcile the eventual generation with the usage information and billing terms for that route. A Google counting request made with a Google credential is a reference measurement, not a 4SAPI billing record.
Decide what can be removed without losing the answer
The cheapest request is not useful if it omits the distinction the customer is asking about.
In the shipment example, the customer originally ordered a product and later requested a replacement. Removing the whole conversation may leave the model with two tracking numbers and no indication of which shipment matters.
Use paired questions to check whether the smaller request still does its job:
| Question | What the answer must distinguish |
|---|---|
| “Has my order shipped?” | Original order versus replacement, if ambiguous |
| “Has the replacement shipped?” | Replacement record specifically |
| “Which carrier has it?” | Carrier associated with the selected shipment |
| “When will it arrive?” | An actual delivery estimate versus missing information |
Count first, then generate answers for the candidate you intend to ship. Retain the smaller version only when it still carries the information needed to answer correctly.
One useful optimization is to remove repeated text while retaining a short, explicit relationship: “The customer is asking about replacement shipment R-204.” That preserves more business meaning than truncating the oldest characters at an arbitrary boundary.
Set a budget that catches accidental growth
An application can apply two independent review conditions:
- An absolute limit for this feature’s assembled input.
- A change threshold relative to the previous approved version.
For example, a team might review any change that adds more than 20% to a known test case. That percentage is an engineering policy, not a Gemini limit or a universal recommendation.
Use multiple fixtures. A short support exchange may pass while a long-running conversation doubles in size. Include an empty history, a typical history, and a long history containing repeated order details.
Also record the request-builder version. If the same fixture changes next week, you need to know whether the prompt, retrieval code, model route, or counting method changed.
What changes when you use an API gateway?
There are two different capabilities to verify: generating with the selected Gemini model and counting the corresponding input. A gateway can expose one without exposing the other through the same interface.
Use the 4SAPI integration documentation to identify the supported protocol. Do not send a gateway key to Google’s endpoint or assume that changing the hostname makes every SDK method available.
If native counting is available on your selected route, repeat the comparison there. If it is not, label the direct count as a reference and use the gateway’s returned usage from a small generation to understand what the production integration reports. If the figures differ, inspect request transformations before assuming that either measurement is incorrect.
Try this with one prompt you own: open the 4SAPI console, confirm the Gemini model and protocol available to your account, and send the approved candidate through that route. Keep its response and usage next to the before-and-after report. You will have an integration decision based on your application rather than a generic claim about context size.




