deepseek-v4.1-flash: 10–60 s to first token once images are in context; deepseek-v4.1-flash-fast is unaffected (3–4 s) #1009

Summary

With deepseek/deepseek-v4.1-flash, once the agent has read an image, every later model request in the session waits 10–60 s before the first token. Text-only requests in the same session take 2–4 s. The wait gets worse as more images accumulate in context.

deepseek/deepseek-v4.1-flash-fast does not have the problem: the same sessions, with the same images, get their first token in 3–4 s.

In day-to-day use this makes the regular V4.1 Flash feel hung after the agent reads one or two screenshots, because images stay in context and are re-sent on every turn.

Measured with the CLI in headless mode (cmd -p --output-format json), timing each model request from its model_request_start event to the first thinking_* / text_delta event.

Time to first token, by number of images already in context

Wall-clock time for the same "read six images one by one" task: 118 s and 149 s on V4.1 Flash, 26 s and 27 s on V4.1 Flash Fast.

In the single-image runs both models read the text in the image correctly, and both count about 1,020 input tokens per image, so this does not look like a difference in what the model receives.

Cache reads do not grow past the images on V4.1 Flash

Usage reported by model_request_end in one six-image run of each model:

On V4.1 Flash Fast, cache reads grow by 1,024 tokens with each image. On V4.1 Flash they stay at about 16.4K no matter how many images are in context. My guess is that V4.1 Flash reprocesses every image on every turn, which would explain why the delay grows as images accumulate. That part is an inference, not something I measured.

Expected Behavior

• Time to first token on deepseek/deepseek-v4.1-flash with images in context should be in the same range as deepseek/deepseek-v4.1-flash-fast (3–4 s here), not 10–60 s.
• Cache reads should extend past image content on V4.1 Flash the way they do on V4.1 Flash Fast.
• During a long wait, some heartbeat or progress signal would help the client tell "still working" from "connection dead".

Actual Behavior

• Before any image is read: 2.0–4.4 s to first token.
• With one image in context: 9.6–22.4 s.
• With four or five images: 20–60 s.
• Nothing is streamed during the wait.
• Cache reads stay flat at about 16.4K tokens while input grows from 17.5K to 21.6K.
• The same runs on deepseek/deepseek-v4.1-flash-fast stay at 2.7–4.4 s.

Steps to reproduce the issue

1. Create an empty directory and put six PNG files in it, 1.png to 6.png. Mine are 1223×1286 infographics of about 2.3 MB each (one image plus flipped and rotated copies). The CLI's read_file converts them to JPEG before sending; it reported the first one as 507.8 KB at 1141×1200.

2. Run in that directory:

   cmd -p "Read 1.png, 2.png, 3.png, 4.png, 5.png and 6.png in the current directory, one at a time, finishing each read before starting the next. When all are read, answer with one sentence: how many images did you read. Do nothing else." -m deepseek/deepseek-v4.1-flash --output-format json --no-session --skip-onboarding --no-auto-update -t --max-turns 6

   (I used the equivalent prompt in Chinese.)

3. Timestamp the NDJSON events as they arrive. For each model_request_start, record the time until the first thinking_start, thinking_delta or text_delta, and the usage in model_request_end.

4. Repeat with -m deepseek/deepseek-v4.1-flash-fast and compare.

5. For a baseline, run a text-only prompt on both models with the same flags.

With --max-turns 6 the run stops after five images are in context, which is enough to see the trend.

Command Code Version

1.79.2

Operating System

macOS (Tahoe 26.5.1, arm64)

Terminal/IDE

Headless (cmd -p)

Shell

zsh

Session file (optional)

None. The runs used --no-session.

Additional context

• Measured on Saturday 2026-10-10, at about 07:00 UTC, so outside the weekday peak windows. Runs on the two models were interleaved.
• Sample sizes are small: two runs per model for the six-image task, plus a few single-image runs. Treat the numbers as a trend, not a precise curve.
• I did not keep session or trace IDs. I can re-run and provide them if that helps.
• Possibly related: Provider API: unstable and frequently very long time-to-first-byte on streaming requests (commonly 20s+, up to 146.8s measured) — deepseek/deepseek-v4.1-flash from mainland China #978 (V4.1 Flash time-to-first-token often 20 s or more, up to 146.8 s) and Provider API: severe queueing during evening peak (UTC+8) — minimal requests take 5–60s to first byte, some never complete #999 (5–60 s to first byte on minimal requests at the evening peak). If the sessions in Provider API: unstable and frequently very long time-to-first-byte on streaming requests (commonly 20s+, up to 146.8s measured) — deepseek/deepseek-v4.1-flash from mainland China #978 had images in context, this may be the same cause. 502 Stream ended unexpectedly repeatedly when context is image-heavy (~23 MB request payload) #997 and Recurring 502 "Stream ended unexpectedly before completion" on large sessions — turns lost after retry exhaustion (macOS, v0.1.47) #991 report image-heavy sessions failing with 502, which also points at accumulated image payloads.