[BUG] present_files rendering silently degraded on Sonnet models — Opus still works, no changelog

Resolved 💬 3 comments Opened Apr 16, 2026 by jcb93fr Closed May 27, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

present_files rendering has been silently downgraded on Sonnet 4.5
and Sonnet 4.6 between late March and mid-April 2026 on the
claude.ai web interface.

Note: I'm posting here because there is no dedicated public repo
for claude.ai web UI bugs. Following the pattern of other users
(e.g. issues #17807, #23705, #27155) who reported claude.ai web
bugs here.

Images that used to render in the full-size right-side panel now
only appear as a grey "Download" cartouche in the Artifacts
section. Same tool call, same files, same browser session still
works perfectly on Opus 4.6.

This is a regression. No changelog entry. No status page mention.
Core visual workflow broken on the most commonly used model line.

What Should Happen?

When calling present_files on an uploaded image from a Sonnet
conversation on claude.ai web, the image should render in full
size in the right-hand side panel, as it did consistently a few
weeks ago and as it still does today on Opus 4.6.

Error Messages/Logs

No error. The tool call returns successfully. The image file is 
present in the conversation logs. Only the frontend rendering is 
degraded.

Steps to Reproduce

  1. Open a new conversation on claude.ai web UI (not Claude Code)
  2. Upload a standard .jpeg image file
  3. Select Sonnet 4.5 or Sonnet 4.6 (Extended or not)
  4. Ask Claude to display the image via present_files
  5. Observe: image appears only as grey "Download" cartouche in

Artifacts section, no full-panel rendering

  1. Switch the same conversation context to Opus 4.6
  2. Repeat the exact same request
  3. Observe: image now renders correctly in full-size right panel

The difference is reproducible 100% of the time across multiple
test sessions.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

claude.ai web UI, late March 2026 (approximately)

Claude Code Version

N/A - this is a claude.ai web UI bug, not Claude Code

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Quick recap before the argument

  • Feature affected: present_files rendering in right-side panel
  • Models affected: Sonnet 4.5 and Sonnet 4.6
  • Model unaffected: Opus 4.6 (still works correctly)
  • Regression window: late March to mid-April 2026
  • Communication from Anthropic: none

Why this matters — to paying customers

Let me put this in plain words, because the support team has
already told me this looks like a minor implementation detail on
your side.

From where I'm sitting, it is not.

Every subscription fee I pay, every additional credit I've
purchased, contributes to Anthropic's ability to develop more
advanced models, more powerful reasoning, more ambitious
capabilities. That is great — I'm genuinely glad to support it.
But the fundamental contract goes both ways: in exchange for my
money, the basic features I rely on should keep working, or at
the very least I should be informed when they change.

Right now, the opposite is happening. I pay, Anthropic grows,
and a core visual feature that worked perfectly for me on Sonnet
— yes, on base Sonnet 4.5, the standard model, the one most
paying users are on — is now silently broken. Not "a bit slower",
not "a bit different". Simply no longer rendering in the side
panel it used to render in, every single time, for weeks,
without fail, for months.

The workflow I built around this feature, the images I
generated specifically to be displayed this way, the time and
money spent designing my usage around it — all of it was based
on a feature you delivered consistently. And now that feature is
Opus-only, with no announcement, no explanation, and no option
to keep using Sonnet as before.

For your engineering and product teams, this may read as a
"minor frontend implementation change" on a single tool. For
paying users, especially those of us who use Claude daily for
creative, educational, or professional workflows, this is
exactly the kind of silent regression that erodes trust. Not the
model's intelligence. Not the benchmark scores. Trust in the
product as a stable, reliable tool we can invest our time and
money into.

Customer loyalty and reputation are not built on benchmarks.
They are built on the small, boring, day-to-day reliability of
features that people come to depend on. Break those quietly,
and no amount of LMArena ranking will keep users from switching
to the next option.

I'm not writing this to be dramatic. I'm writing it because
when support tells me "this is a model-specific implementation
change", what I hear is: "your use case is not important enough
for us to preserve or communicate about". That is the message
that comes through, even if it's not the one intended.

Please — whoever reads this from the engineering or product
team — take a moment to consider that the feature you changed
silently was, for some of us, the reason we subscribed in the
first place. A one-line changelog entry would have been enough.
A clear choice to keep or restore the behavior on Sonnet would
have been better. Silence, followed by three rounds of template
support responses, is the worst of all options.

To other users reading this: if you've noticed the same behavior
on your Sonnet conversations, please comment or thumbs-up this
issue. The more of us who confirm, the faster this gets
prioritized.

Note: This is a claude.ai web UI bug, not a Claude Code terminal
bug. The Terminal/Shell field was required so I selected an
option, but it is not applicable here.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗