GenerateImage dropped from Pro (~1.6MB photoreal) to Flash-class (~300KB CGI) overnight

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Same Cursor account, same Agent GenerateImage tool, same 1024x1024 output.

2026-09-09 ~00:50 CST: photoreal portraits ~1.6MB PNG / ~180k unique RGB (skin pores, peach fuzz).
Same morning: every GenerateImage call returns ~300KB / ~50-60k unique RGB (plastic/CGI faces).

Not a prompt bug. Replaying yesterday’s exact product reference images + similar prompt still yields 313KB / 56435 colors.

Changelog 2.4 says the backend is Google Nano Banana Pro. Official GenerateImage schema only has description, filename, reference_image_paths, aspect_ratio. Passing undocumented model / image_size=2K / quality=high is ignored. Grok 4.6 parent chat AND Composer 2.5 subagent both hit the cheap lane. Chat model cannot restore Pro.

Docs say “Requests are never downgraded in quality or speed” and staff said chat model does not select the image pipeline. There is no Settings toggle for Pro vs Flash. If Pro is rate-limited, this looks like a silent Flash fallback with no 429 and no UI.

Steps to Reproduce

  1. Open a folder workspace in Agent mode (not Quick Chat, not Ask/Plan).
  2. Call the built-in GenerateImage tool: aspect_ratio 1:1, 1-2 product reference images, photoreal commercial portrait prompt.
  3. Save the PNG and measure: file size + unique RGB colors (e.g. Pillow/numpy unique over RGB pixels).
  4. Repeat in a Composer 2.5 subagent.
  5. Repeat with extra undocumented args: model=gemini-3-pro-image-preview, image_size=2K, quality=high.

Expected vs this account today: always 1024x1024, ~300KB, ~50-60k unique colors. Yesterday on the same account the same tool produced ~1.6MB / ~180k unique colors at the same 1024x1024.

Expected Behavior

GenerateImage should stay on Nano Banana Pro / Gemini 3 Pro Image Preview as documented in changelog 2.4, matching yesterday’s ~1.6MB / ~180k-color photoreal 1024 PNGs.

If Pro is unavailable (preview rate limits / 429), fail visibly instead of silently returning Flash-class ~300KB CGI.

image_size / aspect_ratio should be forwarded to Gemini (known related bug: backend currently drops them, so Gemini default 1K is used). Extra tool args should not be silently discarded if Pro/2K is intended.

Operating System

Windows 10/11

Version Information

Cursor 3.19.19 (Windows user install; app package.json also reports 3.19.13)

For AI issues: which model did you use?

Chat: Grok 4.6 (parent) and Composer 2.5 (subagent). Image tool: built-in GenerateImage (Gemini 3 Pro Image Preview / Nano Banana Pro — not selectable in Settings).

For AI issues: add Request ID with privacy disabled

PASS ~1.6MB (2026-09-09 00:49 CST): e844e706-cbe3-4054-86ba-89a6f325aadb
FAIL Composer 2.5 subagent: 25b1ca25-79ba-41d1-9f6a-893f82148da3
FAIL extra 2K/quality/model params: be64b464-2400-4831-aeda-efcd5b131d20
FAIL replay of yesterday refs (313KB): 04766b3e-9c07-4fb2-83a8-863c3f505ab5

Additional Information

Measured 1024x1024 PNGs on disk:

  • Yesterday PASS: 1687010 bytes (1647KB), unique RGB=185619
  • Today extra-params FAIL: 333177 bytes (325KB), unique=60424
  • Today replay of yesterday refs FAIL: 320930 bytes (313KB), unique=56435
  • Today Composer 2.5 FAIL: 305701 bytes (299KB), unique=50396

Resolution did NOT change (always 1024). This is texture/model-tier collapse, not the 1376x768 vs 1536x1024 size lock.

Related existing threads (titles only; new-user link limit):

  • Image Generation Only Has Fixed Resolution (staff: backend does not pass size/aspect to Gemini; default 1K)
  • Use model native image gen (staff: separate image models; chat model does not pick image gen)
  • Image generation models not showing up (staff: Nano Banana is not user-selectable)
  • Image editing regression + repeated 400 errors (recent quality regression reports)

Google names Flash (gemini-2.5-flash-image / 3.1-flash-image) vs Pro (gemini-3-pro-image). Today’s 1024 / ~300KB outputs match Flash-class defaults. Please confirm whether GenerateImage silently routed to Flash after a Pro rate limit, and restore Pro or fail loudly.

Please tag image-gen.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report and measurements. It really helps us figure this out.

What you’re seeing isn’t a rate limit fallback or a quiet downgrade to Flash. Your requests didn’t hit any limits. The model behind the GenerateImage tool is chosen on our side and can’t be selected in the app, and the default model can change over time. The difference in file size and texture detail you measured reflects a change in the default model, not your prompts and not the chat model. Earlier images went through the old default, and roughly everything from 09 September around 08:00 Beijing time went through the new one.

A couple notes about the tool itself:

  • The GenerateImage schema only accepts description, filename, reference_image_paths, and aspect_ratio. Extra args like model, image_size, quality aren’t forwarded and are just ignored. You spotted that correctly.
  • The chat model Grok 4.6, Composer 2.5, or a subagent doesn’t affect which image model serves the request.
  • aspect_ratio does get passed to the provider. A separate issue with output size and shape for some ratios is something we’re already tracking here: Image Generation Only Has Fixed Resolution

I’ve shared your before and after comparison with the team that owns image generation as feedback on the new default. If you can attach one or two side by side examples, same prompt and reference images, old output vs new output, that would help them a lot.

6

@deanrie Side-by-side as requested.

Same Cursor account, same GenerateImage tool, same SKU (6208), same slot (set-1 male 01), same 1024x1024 PNG. Same product reference images. BEFORE did not use extra tool args (model / image_size / quality). AFTER is a same-morning replay after the ~08:00 CST default change.

BEFORE (~00:50 CST, old default)

  • 1,687,010 bytes (~1.65MB)
  • ~185,619 unique RGB
  • photoreal skin / peach fuzz
  • Request ID: e844e706-cbe3-4054-86ba-89a6f325aadb

AFTER (same morning, new default)

  • 320,930 bytes (~313KB)
  • ~56,435 unique RGB
  • CGI / wax-figure skin
  • Request ID: 04766b3e-9c07-4fb2-83a8-863c3f505ab5

Resolution did not change. The drop is texture / unique-color / file-size, not 2K vs 1K.

Attaching one labeled contact sheet (BEFORE left, AFTER right) plus the two original PNGs.

6208-BEFORE-AFTER-side-by-side
6208-BEFORE-AFTER-side-by-side1920×1013 436 KB

8

@deanrie Follow-up: the new default is still in place this morning (2026-09-10 CST). No staff reply after the side-by-side in #6.

I ran GenerateImage again on the same account. Output is still the lower-tier model: 1024x1024, wax/CGI look, unusable for commercial product photos.

This morning’s stills (same tool, product 45-degree SKU shots, not portraits):

  • 1024x1024 PNG ~179KB
  • unique RGB only ~7k–11k (yesterday’s cheap portraits were already ~50–56k; the old Pro default was ~185k)

Please revert GenerateImage to the previous default (the ~1.6MB / ~180k-color Pro look from 2026-09-09 ~00:50 CST), or expose a user-selectable Pro image model. Right now there is no toggle and extra tool args are ignored, so we cannot get back to yesterday’s quality.

9

Hey, thanks for the side-by-side and follow-up, I got the files. I can see the contact sheet and both measurements.

What you measured file size, unique colours, texture is the result of a default change, not a rate-limit fallback and not anything in your settings or prompts. So this isn’t on your side.

On your two requests, honestly:

  • For an individual account right now there’s no lever, no Settings toggle and no tool argument to pin a specific image model. Extra args like model, image_size, quality aren’t in the schema and get ignored, which you correctly noticed.
  • I passed the request to bring back the previous default and or add a user-selectable image model to the team that owns image generation, along with your before and after. This is useful signal for them. I can’t give an exact date or a promise on a revert.

Separate note, we’re tracking the output size and shape issue for some aspect ratios separately, thread here: Image Generation Only Has Fixed Resolution

I’ll reply here if there’s an update on the default or on a selectable model.

10

Same Problem

11

Same problem started like 2 weeks ago, got confirmed by support and they keep promosing they are tracking and know about it, still no update or explenation or public admission. This was hte one feature that kept on Ultra and meant my sub has been useless. And how this has been communicated and handled is just the worst.

13

Hey, thanks for reaching out. And yeah, I can see this is seriously affecting your workflow, especially if image generation was the main reason to stay on Ultra.

I’ll be direct so it doesn’t sound like a generic “we’re monitoring it” reply. What you’re seeing is a change to the default model behind the GenerateImage tool on our side. It’s not a rate limit fallback, and it’s not anything in your settings or prompts, so it’s not on your end. The model used by GenerateImage is picked on the backend right now, not in the app, and the default has changed over time. That’s why you’re seeing differences in file size and unique colors in your measurements.

On the two requests from this thread, bringing back the previous default and or adding a user-selectable image model, I’ve forwarded both to the team that owns image generation, along with the before and after measurements from here. At the moment there’s no lever for a specific account. There’s no toggle in Settings, and there’s no tool argument to pin a specific model. Extra args like model, image_size, quality aren’t in the schema and get ignored.

On timing, I want to be honest. I can’t give an exact date or a promise for when the default will be reverted. As soon as there’s an update on the default or on making the model selectable, I’ll post it directly in this thread.

@shxhe01 I’ve also noted your confirmation.