[BUG] CLI needs to be transparent when Opus 4.1 output is degraded deliberately

Resolved 💬 4 comments Opened Aug 30, 2025 by guidedways Closed Jan 5, 2026
Claude Code v1.0.98
macOS

https://status.anthropic.com/incidents/h26lykctfnsz

Although this is bad to begin, bugs happen and that's okay. However, if we've _specifically_ specified /model to use Opus 4.1, Anthropic should either return a 5xx error when it's unable to serve requests OR should make it clear within the CLI / UI somehow that it's currently serving output from some smaller / quantized / degraded / slower model and is clearly not Opus 4.1 output. Imagine you’re being told you’re buying organic, freshly squeezed orange juice , but what you're actually drinking is watered-down concentrate from a box. Let us decide if that's okay.

According to the status above it's been happening for almost a week. And for a week I've been struggling to make Opus do anything more sensible than what Sonnet 3.5 or Haiku would do. I've repeatedly have had to rely on connecting to Gemini 2.5 Pro for almost every single query to get anything reasonably acceptable as a result, because even then Claude would go ahead and perform the most meaningless edits that I'd have to rollback and in many instances go all-in and do the old-fashioned way; myself.

There needs to be more transparency when it comes to output from CC. We need to be able to trust that within the current constraints we're willing to work under (i.e. Opus 4.1 with a 200K window) the output we're getting is at least what it says on the tin. Had I known I was wasting my time for 10 days I'd have looked at solving the problem differently.

View original on GitHub ↗

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