[BUG] Fable 5 pixel-edits screenshots of its own live SVG instead of editing the source (hours/tokens lost)

Open 💬 0 comments Opened Jul 15, 2026 by simplysdm

Feedback ticket — Fable 5 failed to identify the source medium, burning hours pixel-editing screenshots of live SVG

Date filed: 2026-07-15
Reporter: Shawna Cason (Claude Max subscriber)
Product: Claude Code CLI (v2.1.x) · model Fable 5 (claude-fable-5) — this session is 100% claude-fable-5 · macOS (Darwin 25.5.0)
Severity: High (user-experienced) — hours of wall-clock + large token spend on an approach that was wrong from the first step; repeated failure to verify a basic assumption

---

Summary

While iterating on a design asset (the "Willa" tulip mascot), the user pasted screenshots of a locally-rendered HTML/SVG file (willa-mark-lab.html) to point out changes she wanted. Fable 5 assumed the screenshots were AI-generated raster images (Gemini output) and spent roughly a dozen attempts doing scripted pixel-manipulation (PIL/OpenCV: gap-fills, gradient fills, inpainting, despeckling) to edit them. Every attempt introduced new artifacts (row banding, streaked cheeks, corrupted leaves, red/orange ghosting). The user repeatedly said it "still needs work," "it's freaking out," and finally identified the root cause herself:

USER: "just figure out why you're not rendering it correctly. You're doing something different. Before they were opening like file:///Users/shawnacason/projects/morph-app/wireframes/willa-mark-lab.html."

i.e. the asset was live SVG in an HTML file the whole time. The correct fix (moving a petal path, rounding an eye shape) was a trivial, clean, artifact-free edit in the SVG source. The model never checked the medium before committing to raster surgery.

What went wrong (root causes)

  1. Unverified assumption about the source medium. The model assumed "painterly screenshot = AI raster generation" and never asked or checked whether the image was a screenshot of an editable local file it had itself been building. The file was open in the user's browser as a file:// URL and was named in earlier turns.
  2. No early cheap check. A single question ("is this a screenshot of the SVG lab, or a separate image?") or a grep/render of the existing HTML would have revealed the truth in seconds. Instead the model escalated into progressively more complex raster techniques (installed OpenCV, wrote inpainting code) — sunk-cost escalation.
  3. Persisting after evidence of failure. After ~5 failed raster attempts the model had strong evidence the approach was wrong, but kept trying variants instead of stepping back to re-question the premise.
  4. Introduced regressions the user had to catch. Multiple edits corrupted parts of the image the user hadn't asked to touch (leaves striped because a red-detector matched green pixels; cheeks streaked). The user, not the model, caught each one.

Impact

  • Hours of wall-clock and very large token spend (many multi-hundred-thousand-token design/edit cycles) on a fundamentally wrong approach, on a paid Max plan.
  • Trust erosion: the user had to diagnose the model's own tooling mistake and spell out the file path.
  • Compounded an already-long session's cost (see companion tickets on idle loops and agent transcript loss, same date).

Expected behavior

  • Before choosing a technique, establish the medium/source of an artifact. When a user pastes a screenshot to request an edit, check whether it corresponds to a file/render the assistant controls (especially one it has been building) before treating it as an opaque raster.
  • Prefer editing the source (SVG/HTML/vector) over retouching a rendered screenshot. Raster retouching of vector-sourced art is almost always the wrong tool.
  • Re-question the premise after 2–3 failures, rather than escalating technique complexity on the same assumption.
  • When an edit is at the pixel level on soft/anti-aliased art, recognize that as a red flag that the source medium is probably wrong.

Reproduction shape

  1. Assistant builds a local HTML file containing inline SVG art across many turns.
  2. User screenshots the browser render and pastes it to request a visual tweak.
  3. Assistant treats the paste as a standalone raster image and edits pixels, rather than editing the SVG it authored.

Evidence

  • Session UUID: 7f97147b-bc98-4424-a1af-fa3f8a54b415 (2026-07-14 → 07-15). The full raster-attempt chain and the user's correction are in this session's transcript.
  • Files created during the wrong approach: wireframes/inspiration/willa-gemini-tulip-r1..r9, -clean, -final, willa-tulip-v3 (all raster edits) vs. the actual source wireframes/willa-mark-lab.html.

Ask

  1. Strengthen the model's instinct to identify and edit the source of a visual artifact, especially one it authored, before retouching a raster.
  2. Add a self-check: "pixel-editing anti-aliased/soft art" → stop and verify the source medium.
  3. Encourage premise re-examination after a small number of same-approach failures instead of escalating tooling.

Related (same reporter, same date)

View original on GitHub ↗