slot79 (MODE_CATEGORY) is ignored upstream: gemini-3.1-pro returns "3.7 Flash" with no thinking

[qcsunny]

Summary

Selecting gemini-3.1-pro always comes back labelled 3.7 Flash upstream, with zero thinking
markers in the response. slot79 (MODE_CATEGORY) in the request payload is no longer honoured by
the backend, so this project's model selection is effectively inert — every request gets the account's
default model regardless of which model the caller asked for.

The account is a paid Google AI Pro subscription, the cookie is valid, and the same conversations show
up in the Gemini web UI sidebar.

Environment

Item	Value
Base commit	2bb988b feat(models): 新增 gemini-3.7-flash 并调整 3.6 版本描述 (#77)
Python	3.11.2
gemini_bl	boq_assistant-bard-web-server_20260816.12_p0, then refreshed to 20260817.02_p0 (both tested)
auth_user	0
Endpoint	/u/0/_/BardChatUi/data/assistant.lamda.BardFrontendService/StreamGenerate

All logs below are redacted. Cookies, SAPISID, XSRF tokens, conversation/response IDs and account
geo context are replaced by placeholders or reduced to a byte length. gemini_bl is kept as-is
because it is a public build ID, not a credential.

Reproduction

Send a genuinely hard reasoning problem (not something answerable in one token) to gemini-3.1-pro,
then read slot42 of the final upstream frame — that field is the model name the web UI itself displays.

[05:39:33] fetching account page WIZ tokens (not a generation request)
[05:39:35] page tokens keys=['at', 'f_sid', 'pctx', 'push_id'] at=yes f_sid=yes image_model=None
[05:39:35] resolve_model -> name=gemini-3.1-pro mode(slot79)=3 think(slot17)=0 extra=None err=None
[05:39:35] gemini_bl=boq_assistant-bard-web-server_20260816.12_p0  auth_user=0  xsrf_token=present
[05:39:35] [t1_stream_pro] POST .../StreamGenerate  slot79=3 slot17=0
[05:39:37] [t1_stream_pro] HTTP 200
[05:39:37] [t1_stream_pro] TTFB (first byte)      = 2.01s
[05:39:51] [t1_stream_pro] TTFT (first text frame) = 16.20s
[05:39:56] [t1_stream_pro] total=21.18s  raw=296210B

### t1_stream_pro model-label scan (raw 296210B)
  version+tier strings: [('3.7 Flash', 36)]
  tier keyword hits:    [('Flash', 36)]

[05:39:56] === sleeping 200s to stay under rate limiting ===
[05:43:16] [t2_plain_pro] non-streaming _generate_raw  slot79=3 slot17=0
[05:43:34] [t2_plain_pro] total=17.49s  raw=179856B

### t2_plain_pro model-label scan (raw 179856B)
  version+tier strings: [('3.7 Flash', 33)]
  tier keyword hits:    [('Flash', 33)]

Controlled experiment: 4 real upstream generations

A different question each time, ≥200s apart to avoid rate limiting.

#	Mode	slot79	gemini_bl	upstream slot42	thinking markers
1	streaming	3 (PRO)	20260816.12 (stale)	3.7 Flash	0
2	non-streaming	3 (PRO)	20260816.12 (stale)	3.7 Flash	0
3	non-streaming	3 (PRO)	20260817.02 (refreshed)	3.7 Flash	0
4	non-streaming	6 (FLASH_LITE)	20260817.02	3.7 Flash	0

Run 4 is the decisive one. Switching slot79 from 3 (PRO) to 6 (FLASH_LITE) — two entirely
different tiers — produced the identical label. slot79 is not participating in routing at all; the
backend just serves the account default.

Ruled out

• Stale BL — run 3 used that day's newest 20260817.02_p0. slot42 did not change.
• Invalid / ineffective cookie — the response frames carry account geo context and real
  c_ / r_ conversation IDs, and the conversation is visible in the web UI. The session is authenticated.
• "TTFT < 5s therefore no thinking" is a flawed premise — measured TTFB (first byte) is 2.01s, which
  is just HTTP headers plus padding; TTFT (first real text frame) is 16.20s. The latency is fine; what
  is genuinely missing is thinking — 0 markers in the response, matching what the web UI shows.

Final upstream frame (redacted)

=== non-empty slots of the final frame (redacted) ===
  slot[ 1] = <redacted: conversation / response IDs>
  slot[ 4] = <redacted: answer body container>
  slot[ 5] = <redacted: account geo / personalization context>
  slot[14] = true
  slot[19] = "zh"
  slot[23] = true
  slot[26] = [[[[null, [null, 0, "结论：存在这样的填法。", …     <- text delta, truncated
  slot[42] = "3.7 Flash"                                     <- authoritative model label
  slot[43] = true
  slot[44] = [[[[1004, "Longer", 5, …                         <- length-option chips
  slot[46] = 2
  slot[58] = 1
  slot[59] = 1

Root cause

Model selection appears to have moved from a payload slot to a request header:
x-goog-ext-525001261-jspb. It is JSPB-encoded (a protobuf message serialized as a positional JSON
array), and index 4 holds a 16-hex internal model ID:

[1,null,null,null,"<16-hex model id>",null,null,0,[4,5,6,8],null,null,<capacity>,null,null,<category>]

This repository already builds that header — _build_model_headers() / _image_model_headers() in
gemini.py — but only the image path sends it. The text path's _build_headers() sends no model
header at all and relies solely on slot79, which the backend now ignores. That also explains why image
generation does reach a non-default model while text is always pinned to the account default.

Two more observations:

• The account page enumerates the currently available model IDs as feature-flag lists
  (e.g. sylssb / flag 45749278), so the valid IDs are discoverable at runtime rather than hardcoded.
• The MODE_CATEGORY enum quoted in models.py comes from an old JS bundle (028-6eb337387583.js).
  That enum is most likely no longer the routing key.

Proposed fix (not yet verified)

Send x-goog-ext-525001261-jspb on the text path too, selecting the tier by real model ID instead of
slot79.

I have not confirmed this experimentally yet. I am currently sweeping the candidate model IDs one at
a time — a different question per request, >3 minutes apart to stay clear of rate limiting — to see
whether slot42 follows the ID in the header. I will follow up in this thread with the result.

Related

• 如何验证 cookie 是否真正生效？Pro 模型无 thinking 延迟 #13 "如何验证 cookie 是否真正生效？Pro 模型无 thinking 延迟" — same symptom, slot79 breakage was not identified at the time
• 是否支持gemini 3.7 flash #76 "是否支持 gemini 3.7 flash"

[qcsunny]

Follow-up: the proposed fix is wrong — that header is echo-only

I said I would report back after sweeping the model header. Result: x-goog-ext-525001261-jspb
does not steer the text path. My proposed fix in the original post is disproven. Details, so nobody
else spends time on it.

Three generations, same transport (curl_cffi Chrome impersonation), same slot79=3, a different
hard reasoning prompt each time, >=210s apart:

run	model header sent	response slot39	response slot42	wall time
baseline	none	empty	3.7 Flash	9.7s
candidate	56fdd199312815e2	echoed 37x	3.7 Flash	13.2s
garbage	ffffffffffffffff	echoed 25x	3.7 Flash	41.6s

The header value lands in a previously unnoticed response slot, three positions before the label:

… ,"<the id I sent>",null,null,"3.7 Flash",true,[[[[1004,"Longer",…
     ^ slot[39]                  ^ slot[42]

Run 2 looked like a hit at first — the ID coming back 37 times reads like acceptance. Run 3 kills that:
ffffffffffffffff is not a real model ID and it is echoed just the same, with a normal, complete
answer. So the backend copies that field into slot39 and neither validates it nor routes on it.
Which also means the echo in run 2 proves nothing about whether 56fdd199312815e2 is a real ID.
Enumerating candidate IDs through this header is futile.

One correction to my own reasoning in the original post. I argued "only the image path sends this
header, and only the image path reaches a non-default model." That inference was unsound: image
generation is a capability of the current default model, not a different tier. There was never
evidence that any path here reaches a non-default model.

Where this leaves it

Text tier selection is not reachable through any field this project controls:

• slot79 (MODE_CATEGORY) — ignored (mode 3 and mode 6 return identical labels).
• slot17 (think depth) — unverifiable while the tier itself is ignored.
• x-goog-ext-525001261-jspb — echoed into slot39, not honoured.
• slot31 / slot80 (gemini-3.1-pro-enhanced) — same label as plain gemini-3.1-pro; slot80 is
  set on every file-bearing request regardless of tier, so it is an attachment flag.

The account page's model-ID flag table (sylssb/45749278, plus 12 single-value flags) is byte-identical
across two days, so it carries no per-selection state either.

Next hypothesis, for anyone who wants to dig: tier is server-side session/account state. Picking a
model in the web UI probably fires a separate RPC that persists the choice, and StreamGenerate merely
inherits it — which would explain why nothing in the generate request can override it. Cheap test:
switch the model in the web UI by hand, then send one API request and see whether slot42 follows. If it
does, the fix is to find and replay that preference RPC rather than to add anything to StreamGenerate.

slot39 is at least a useful new diagnostic: it echoes whatever model ID the caller claims, so it can be
used to confirm a header is reaching the backend even when it changes nothing.

All figures above come from real upstream responses; credentials, conversation IDs and account context
are redacted as in the original post.

[qcsunny]

Correction: the model header is authoritative — I had this backwards

In my earlier comment on this issue I wrote that x-goog-ext-525001261-jspb is
"echo-only, neither validated nor used for routing." That is wrong, and I'm retracting it.
The header is exactly what selects the model. Payload slot79 alone does not select anything —
when the header is absent, upstream ignores slot79 and serves the account default, which is
why every model name in MODELS comes back as the same model.

The proof (an alias natural experiment)

Two unclaimed model IDs found in the account page HTML, sent with an identical payload and an
identical slot79 = 2, differing only in index 4 of the header:

header idx 4 (model ID)	payload slot79	served slot39	served slot42	served slot58	latency / size
9d8ca3786ebdfbea	2	e6fa609c3fa255c0	3.1 Pro	3	23.9 s / 162 KB
797f3d0293f288ad	2	fbb127bbb056c959	3.6 Flash	1	11.7 s / 197 KB

Same slot79, two different served models and two different served categories. The header ID
decides; slot79 does not.

The contract

x-goog-ext-525001261-jspb:
[1,null,null,null,"<model_id>",null,null,0,[4,5,6,8,4,5,6,8],null,null,2,
 null,null,<category>,<extended>,"<fresh UUID>"]

• idx 4 — model ID (the actual selector)
• idx 8 — feature list; all eight browser captures send this doubled form
• idx 11 — always 2
• idx 14 — category, and it must equal payload slot79
• idx 15 — Extended toggle, and it must equal payload slot80
• idx 16 — a fresh UUID per request, independent of any other ID in the payload

Both invariants hold in every capture I have (8 HARs across 3 models × Extended on/off). Sending
no header at all is a valid state and means "account default" — worth keeping deliberately for an
auto entry, but it should be named honestly, since it is not routing.

Verified IDs, stable across every capture so far: 56fdd199312815e2 = 3.7 Flash (cat 1),
e6fa609c3fa255c0 = 3.1 Pro (cat 3), 8c46e95b1a07cecc = 3.5 Flash-Lite (cat 6).

A second, independent cause — and it fails silently

Adding the header is necessary but not sufficient. A stale cookie also downgrades Pro, and it
does so without any error: you still get a complete, plausible answer, just from a cheaper
model. The gate is the short-lived rotating family (__Secure-1PSIDTS, __Secure-3PSIDTS,
SIDCC), which a real browser keeps renewing from Set-Cookie. Measured on one account, one
unchanged cookie file, Pro requested every time:

cookie age	served	latency / size
5 min	3.1 Pro	116.1 s / 880 KB
11 min	3.1 Pro	164.5 s / 2.0 MB
30 min	3.1 Pro	23.9 s / 162 KB
19.6 h	downgraded	20.9 s / 2.1 MB
fresh re-export	3.1 Pro	68.6 s / 547 KB

I also suspected the gemini_bl version and it is not the variable: pinning BL back to the
exact version that had served Pro, cookie untouched, still downgraded — and the newest BL served
Pro fine once the cookie was refreshed. Account-side quota is ruled out by the last row.

Diagnostic marker, useful regardless of the cookie question: when upstream refuses a model it
silently substitutes and reports slot39 = cf41b0e0dd7d53e5. That ID is not the real
Flash-Lite ID (8c46e95b1a07cecc), even though slot42 labels it "3.5 Flash-Lite". So assert on
slot39, never on the label. Latency is a good second signal: Pro is 24–165 s and 137 KB–2 MB
raw; a "Pro" answer that returns in 8 seconds did not run on Pro.

Two concrete suggestions:

1. Honour Set-Cookie. Nothing in the project reads it today, so it replays one frozen
   snapshot forever and Pro decays to a silent downgrade within hours. Writing the rotated values
   back would remove the manual re-export loop.
2. Add a served-model assertion comparing slot39 against the requested model ID. It would
   have caught both root causes here immediately, instead of surfacing as "the model name is
   ignored."

On the "no thinking" half of the title

Related finding, since this issue also reports no thinking output: slot17 is [[0]] in all
eight browser captures, including Pro with Extended on — the highest-quality request the web UI
can produce. The browser never sends a second value, so I could not reproduce a 0–4 depth scale.
The docs here are also self-inconsistent on this point: cloudflare/worker.js:438-441 describes a
two-value enum (0 = deep thinking, 4 = AUTO / model decides), while README.md and
README_CN.md describe a continuous scale (0 deepest, 2 medium, 4 shallowest). @think=2
appears in no model entry anywhere. Worth reconciling, or documenting slot17 as browser-parity
only.