gateway-402: generateContent/streamGenerateContent return 500 challenge_generation_failed on the Gemini host

[eladmint]

Context

We're Sippar (production consumer, same account behind #394 and pay-kit#212/#213). We pay generativelanguage.google.gateway-402.com server-side with @solana/pay-kit's client.fetch, settling real USDC on mainnet — this has worked since 2026-07-04 (our generateContent vision-critic call, proven live).

As of today (2026-07-07) the same call fails before any payment step.

Problem

generateContent and streamGenerateContent on this host return a bare 500 with no 402 at all:

$ curl -s -i -X POST "https://generativelanguage.google.gateway-402.com/v1beta/models/gemini-2.5-flash:generateContent" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"role":"user","parts":[{"text":"hi"}]}]}'

HTTP/2 500
content-type: application/json

{"error":"challenge_generation_failed"}

Reproduced consistently (30+ calls) across:

• two networks (our own machine and our production VPS)
• curl and Node's native fetch
• every model we tried (gemini-2.5-flash, gemini-2.5-pro, gemini-2.0-flash, gemini-1.5-flash)
• both generateContent and streamGenerateContent
• with and without a tools/toolConfig body, with and without a body-level model field, with vision (inlineData) and text-only content

Meanwhile the same host's embedContent and countTokens endpoints work correctly right now — embedContent returns a clean 402 with a full MPP challenge, countTokens returns 200 with no payment required. So the gateway and its payment stack are up; this looks specific to the two content-generation methods.

Why we think this is new, not a known limit

• gateway-402: expose an MPP session challenge on the Gemini host for channel reuse #394 (which we filed 2026-07-02) shows generateContent's x402-upto challenge decoding fine that day.
• Our own generateContent vision-critic call has been live in production since 2026-07-04.

So this is a regression inside the last few days, not a documented constraint.

Possible cause (unconfirmed, just a lead)

The proxy was rewritten onto Pingora in #385 (merged 2026-06-29). That PR's own "Deferred" section lists "response-side session byte-metering" as not yet done. generateContent/streamGenerateContent are the two methods whose price depends on the output size, which is unknown until generation completes — unlike embedContent's flat, input-only pricing. That split lines up with what we're seeing, but we haven't looked at the proxy internals to confirm it.

Ask

Is this a known issue on your end, or something scoped to our traffic? We're blocked on wiring tool-calling through this host until generateContent issues a challenge again — checked your docs and GitHub issues first, didn't find an existing report.

[lgalabru]

hi @eladmint! thanks for opening this issue, we're actively working on wiring mpp:sessions / x402:upto.
this endpoint should be stabilize in the next 1-2 days 🙏

[koriyoshi2041]

Quick readback from a no-wallet/no-payment probe on 2026-07-11 07:21 UTC: the original challenge_generation_failed symptom looks resolved at the challenge layer for me.

Commands were unauthenticated curl POSTs with the same minimal text body shape from the issue. Results:

• gemini-2.5-flash:generateContent -> HTTP/2 402, body payment_required, payment.schemes: ["x402-upto"], with input/output token pricing.
• gemini-2.5-flash:streamGenerateContent -> HTTP/2 402, body payment_required, payment.schemes: ["mpp", "x402-upto"], with request pricing.
• text-embedding-004:embedContent -> HTTP/2 402, body payment_required, payment.schemes: ["mpp"].
• gemini-2.5-flash:countTokens -> HTTP/2 200, returned totalTokens: 2.

I did not settle a payment or test the post-payment Gemini response path, so this only confirms that challenge generation is back for the two content-generation methods.