We intermittently see
Hi
We are investigating this issue and will update this thread once the fix is rolled out
Thank you, Mustan!
Can you please let me know what the underlying issue was once rolled out?
Facing the same issue. We are processing a lot of table to extract some information and funnily enough, the error only happens for 2 of them. Even changing a bit the main prompt or some formatting element, it is always the same 2 runs that trigger this error
same issue. using Files API. Description from my testing
- Interactions API Per-Turn Input Token Cap (Critical Limitation)
12.1 The Problem
The Interactions API enforces a strict, undocumented per-turn input token cap that is far lower than the model’s advertised context window. This cap applies to Files API URIs passed via interactions.create() and causes silent truncation — no error is raised, the call succeeds, but the model only sees the first portion of the file.
This is a confirmed, known issue on the Google AI Developer Forums affecting Gemini 3, 3.1, and 3.5 models. Developers hitting the limit receive errors such as:
“The input token count (135538) exceeds the maximum number of tokens allowed (131072).”
“Unable to submit request because the input token count is N but model only supports up to 32768.”
The gateway enforces caps of either 131,072 tokens (128K) or 32,768 tokens (32K) depending on model and tier. The stateful, server-side nature of the Interactions API makes large per-turn inputs expensive — the server must persist conversation state and process the file on every turn — so Google caps inputs aggressively regardless of the model’s raw context window.
12.2 The Math
For cfm_gui.py (334.2 KB, 7,413 lines, ~342,200 characters):
- At 4 chars/token → ~85,550 tokens (exceeds both caps)
- At the 32K cap: 32,768 tokens × 4 chars/token = 131,072 chars
- At ~66 chars/line average: 131,072 ÷ 66 ≈ 1,985 lines
- Observed truncation point: 1,980 lines — near-perfect match for the 32K cap
The file uploads completely (full bytes on server), passes the PROCESSING→ACTIVE transition, and the interactions.create call returns status=completed with no error. The truncation is entirely silent.
12.3 Affected Scenarios
- Any file where the token count exceeds the per-turn cap
- The cap appears to be 32K tokens for flash-preview and flash-lite; 128K for larger models (unconfirmed — treat as dynamic and model-dependent)
- The PROCESSING→ACTIVE fix (§3.4) does not address this — it is a separate, independent issue
12.4 Size Threshold
Approximate safe file size before hitting the 32K cap:
| Chars/token | 32K cap | Safe file size |
|---|---|---|
| 4 | 32,768 tokens | ~128 KB / ~2,000 lines of Python |
| 4 | 128K tokens | ~512 KB / ~8,000 lines of Python |
These are estimates. Actual limits vary by model and may change without notice.
12.5 Mitigations
Google’s official guidance (from developer forums and web search) suggests two primary architectural workarounds. Note the correction to Workaround 1 below — it does not apply to our infrastructure.
Workaround 1 (NOT applicable here): Use Files API instead of inline text. Google’s advice is to upload via client.files.upload() and pass the URI rather than inline text, as “the backend handles file URIs differently, often mapping them directly to persistent or cached context layers that bypass the aggressive inline text token throttling.” This is what cti_g.py already does. The cap applies to Files API URIs in interactions.create just as it does to inline text. This workaround does not bypass the 32K token gate for the Interactions API path — confirmed empirically: cfm_gui.py uploaded via Files API, URI passed to interactions.create, still truncated at ~1,980 lines.
I’m getting a suggestion that the problem is Interactions. and that generate_content could handle it (after the upload)
is this possibly true?
Workaround 2: Fall back to the stateless generate_content API
The strict per-turn input throttling is a limitation of the Interactions API gateway (which manages server-side state, background execution, and tool orchestration), not the underlying Gemini models.
If you bypass the Interactions API and use the standard, stateless generate_content endpoint, the model’s full, native context window (1M tokens for Flash, 2M tokens for Pro) becomes fully available.
How to implement it in your code:
Instead of calling client.interactions.create(), you call client.models.generate_content(). You can still upload the file via the Files API, but passing it to generate_content will allow Gemini to read all 7,413 lines.
from google import genai
client = genai.Client()
# 1. Upload the file via Files API (already what cti_g.py does)
file_ref = client.files.upload(file="cfm_gui.py")
# 2. Use generate_content instead of interactions.create
# This bypasses the Interactions API gateway and unlocks the full 1M+ context window
response = client.models.generate_content(
model="gemini-2.5-flash", # or gemini-3.5-flash
contents=[
file_ref,
"Analyze the entire cfm_gui.py file and do a line count (wc -l) to verify."
]
)
print(response.text)
# This will output the correct, full line count (7,413) because the 32K gate is bypassed.
The Trade-off
By switching from interactions.create to generate_content for this specific file-reading task, you lose:
- Server-side state management: You cannot use
previous_interaction_idto chain conversations automatically on Google’s servers. You must manage the conversation history manually in your client code if you want to keep chatting about the file. - Managed Agent features: Background execution and sandboxed environments are exclusive to the Interactions API.
When to use which:
- Use
generate_contentwhen your primary task is ingesting, analyzing, or refactoring large monolithic files (likecfm_gui.py) where the model must see the entire codebase to understand the architecture. - Use
interactions.createfor lightweight, multi-turn, stateful agent operations where you are executing commands, calling tools, or working with smaller, modular files.