Opus 5 regression: model ignores its own memory and prior session transcripts before acting — repeated multi-hour losses on tasks already solved in past sessions

Summary

Over a single working day (2026-08-03/04), Claude Code (models claude-opus-5 and claude-fable-5) repeatedly failed to consult its own persistent memory files and prior session transcripts before acting, despite (a) standing user instructions to do so, (b) the answers being present in those sources, and (c) the harness surfacing those memories in-context. Each task was solved correctly within minutes once the prior sessions were finally read. Estimated cost to the user: 6+ hours of wasted work in one day, on top of a separate credit-drain incident described at the end.

This is a regression in behavior the user reports did not occur with earlier Opus versions ("Opus 4.8 handled the same requests correctly from a rough prompt").

Reproducible failure pattern

The model does not read what it already knows before acting. In each case below the correct answer existed in (1) a memory file loaded into context, (2) the application's own documented op catalog in the repo, or (3) a prior session transcript searchable via the session-management tool.

Case 1 — hair detail task (~3 hours wasted)

• User asked to bring out hair strand detail on an illustration layer.
• Model attempted four wrong approaches in sequence: inpaint_hires, hires_upscale, a hand-written frequency-separation compositing script, and tile_upscale_4096.
• The correct answer — detail_up(part="hair") — was documented verbatim in the application's own operation catalog in the repo ("머리카락 디테일 올려줘 = hair"), and the model's own memory file said "always use existing app functions first, do not hand-roll scripts."
• Root technical cause the model failed to discover for hours: inpaint_hires only upscales the crop when scale > 1, so on large crops it silently processes at reduced resolution and produces no visible change.

Case 2 — knee/thigh shading task (~3 hours, 5 failed attempts)

• User asked to add anatomical rendering to a flat cel-shaded leg.
• Attempts 1–5 all failed: strong settings destroyed the specular highlight that defines the form; weak settings produced max pixel delta of 4/255 (invisible).
• The model repeatedly tuned magic numbers instead of investigating.
• The correct recipe existed in a prior session from 2026-07-24: call generate_remote directly with company LoRA enabled (lora_weights={'1':0.3,'2':0.3,'3':0.3}), apply_base_prompts=True, denoise=0.30, cfg=5.5, and crucially the negative prompt tokens flat plastic skin, oversmooth.
• Root cause the model never checked: the detail_up helper it kept calling runs with lora_weights={} (company LoRA OFF) by design, which makes it a no-op on already-clean flat shading.
• The user had explicitly instructed in a previous session to "apply the LoRA and model, and analyze all sessions so this situation doesn't repeat." It repeated.

Case 3 — proposing abandonment against standing instruction

• The user has a standing instruction never to give up on a task.
• After the 5th failure the model proposed dropping the task ("shall we set this aside and do something more urgent?"). The user had to override this.

Case 4 — destroyed user-designated working files

• The user supplied a file path as the base to work from. The model misread this as a complaint about file naming and deleted that file (plus 9 others) during a self-initiated "cleanup."
• Recovered only because an off-drive backup happened to exist.

Case 5 — verification performed on the wrong image

• For transparent PNGs the model built its before/after comparisons with convert("RGB"), which discards the alpha channel. It therefore verified against an image that differs from what the user sees, and reported success on output where the feature in question had in fact been destroyed.
• It also reported a numeric verification as passing (silhouette IoU 1.0, tone preserved) while the visually decisive element — a specular highlight — had been wiped out and was not part of any check.

Case 6 — output geometry not matched to input

• The user supplied a full-canvas layer (3648×5764) expecting a drop-in replacement. The model returned a cropped region three times, making the result unusable for paste-back, and had to be told each time.

Impact

• ~6 hours of the user's working day lost across two tasks that each took one step once prior context was consulted.
• The user runs a commercial art studio with employees depending on this tooling; they state they cannot currently trust the assistant with remote support sessions scheduled for the coming week.

Separate incident, same day — unnoticed API credit drain

A remote-control admin panel the model had designed in earlier sessions contained a defect: a global "block all usage" switch was enforced client-side only, while a per-employee "apply directive" feature silently wrote enabled: true for that employee, which the server merged over the global setting. Result: the owner pressed "block all," believed usage was stopped, and 5 of 7 employees retained full access for roughly two weeks. Google Gemini and Anthropic API credits were drained to $0. The owner is requesting information on any refund or goodwill channel for model-caused loss. (Fixed today: global block now takes absolute precedence and the proxy hard-rejects paid routes with 503 while blocked.)

What would fix the behavior

1. Before acting on a task in a repo/domain with persistent memory, search prior session transcripts and memory for the same task type — especially after a first attempt fails.
2. Treat a failed attempt as a signal to investigate, not to retune parameters. Three of these cases involved 4–5 consecutive parameter tweaks without ever inspecting why the underlying helper was a no-op.
3. Never propose abandoning a task where the user has a standing instruction against it.
4. Never delete user files as part of unrequested cleanup.
5. Verify against the artifact as the user will see it (composite alpha), and include the visually decisive feature in the check, not only aggregate metrics.

Environment

• Claude Code desktop app, Windows 11.
• Models: claude-opus-5 (primary), claude-fable-5 (earlier in session).
• Session-management and memory tooling available and populated throughout; the relevant memory files were present in context.