fix: make blind-mode describe prompt unique per image #15

Merged

bjoern merged 1 commit from fix/alt-text-provider-cache-bust into main

2026-08-13 06:23:57 +02:00

scarlet commented

2026-07-06 17:20:24 +02:00

Member

Problem

During the July 6 timer session, every blind-mode alt text after the first generation described the first image, even though the generated images on disk were all correct and distinct. The assistant concluded generate_image was broken (it wasn't) and persisted that false conclusion into its knowledge files.

Investigation showed the whole client pipeline was correct: the sha256 hashes logged by ImageDescriptionService match the files on disk exactly, so the correct bytes were sent on every request. The stored alt texts for images 2–7, however, all describe image 1 — each with fresh wording, meaning the vision model genuinely attended to image 1's pixels on every call.

Root cause

An upstream provider bug: DeepInfra (serving moonshotai/kimi-k2.7-code via OpenRouter) keys its prompt cache on the text prefix only. Since every describe call used the identical text "Describe this image in detail.", subsequent requests hit the cache including the previous request's image tokens (cached_tokens covered the full prompt) and returned a description of the wrong image. Reproduced and confirmed by pinning providers: Novita, Inceptron, and SiliconFlow behave correctly; DeepInfra reliably serves the stale image.

Fix

Embed the image's sha256 (already computed for the alt-text cache key) in the prompt text, so no two describe requests share a text prefix. Verified against the affected provider: with the nonce, cached_tokens drops to the shared system-prompt prefix only and the correct description is returned.

The nonce is not part of the cached alt text, so existing cache rows stay valid. Note: the wrong descriptions persisted in image_alt_texts during the affected session (hashes a02348…, 4b1bf9…, f76ba0…, bd838b…, 908ee2…, b3fe2e…) still need a one-off cleanup on the server — this PR only prevents new poisoning.

🤖 Generated with Claude Code

## Problem During the July 6 timer session, every blind-mode alt text after the first generation described the *first* image, even though the generated images on disk were all correct and distinct. The assistant concluded `generate_image` was broken (it wasn't) and persisted that false conclusion into its knowledge files. Investigation showed the whole client pipeline was correct: the sha256 hashes logged by `ImageDescriptionService` match the files on disk exactly, so the correct bytes were sent on every request. The stored alt texts for images 2–7, however, all describe image 1 — each with fresh wording, meaning the vision model genuinely attended to image 1's pixels on every call. ## Root cause An upstream provider bug: DeepInfra (serving `moonshotai/kimi-k2.7-code` via OpenRouter) keys its prompt cache on the text prefix only. Since every describe call used the identical text `"Describe this image in detail."`, subsequent requests hit the cache *including the previous request's image tokens* (`cached_tokens` covered the full prompt) and returned a description of the wrong image. Reproduced and confirmed by pinning providers: Novita, Inceptron, and SiliconFlow behave correctly; DeepInfra reliably serves the stale image. ## Fix Embed the image's sha256 (already computed for the alt-text cache key) in the prompt text, so no two describe requests share a text prefix. Verified against the affected provider: with the nonce, `cached_tokens` drops to the shared system-prompt prefix only and the correct description is returned. The nonce is not part of the cached alt text, so existing cache rows stay valid. Note: the wrong descriptions persisted in `image_alt_texts` during the affected session (hashes `a02348…`, `4b1bf9…`, `f76ba0…`, `bd838b…`, `908ee2…`, `b3fe2e…`) still need a one-off cleanup on the server — this PR only prevents new poisoning. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

scarlet added 1 commit

2026-07-06 17:20:25 +02:00

fix: make blind-mode describe prompt unique per image 6cbedc6861

Upstream providers can key their prompt cache on the text prefix only
and wrongly reuse the cached image tokens of an earlier request
(observed with moonshotai/kimi-k2.7-code served by DeepInfra via
OpenRouter: cached_tokens covered the full prompt including the image,
and the model described the previously sent image). Every blind-mode
describe call used the identical text "Describe this image in detail.",
so a whole session of distinct generated images could come back with
descriptions of the first one.

Embed the image's sha256 (already computed for the alt-text cache key)
in the prompt text so no two describe requests share a text prefix.
Verified against the affected provider: with the nonce the stale cache
is bypassed and the correct description is returned.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>