Hey, Boris from the Claude Code team here. I wanted to take a sec to explain the context for this change.
One of the hard things about building a product on an LLM is that the model frequently changes underneath you. Since we introduced Claude Code almost a year ago, Claude has gotten more intelligent, it runs for longer periods of time, and it is able to more agentically use more tools. This is one of the magical things about building on models, and also one of the things that makes it very hard. There's always a feeling that the model is outpacing what any given product is able to offer (ie. product overhang). We try very hard to keep up, and to deliver a UX that lets people experience the model in a way that is raw and low level, and maximally useful at the same time.
In particular, as agent trajectories get longer, the average conversation has more and more tool calls. When we released Claude Code, Sonnet 3.5 was able to run unattended for less than 30 seconds at a time before going off the rails; now, Opus 4.6 1-shots much of my code, often running for minutes, hours, and days at a time.
The amount of output this generates can quickly become overwhelming in a terminal, and is something we hear often from users. Terminals give us relatively few pixels to play with; they have a single font size; colors are not uniformly supported; in some terminal emulators, rendering is extremely slow. We want to make sure every user has a good experience, no matter what terminal they are using. This is important to us, because we want Claude Code to work everywhere, on any terminal, any OS, any environment.
Users give the model a prompt, and don't want to drown in a sea of log output in order to pick out what matters: specific tool calls, file edits, and so on, depending on the use case. From a design POV, this is a balance: we want to show you the most relevant information, while giving you a way to see more details when useful (ie. progressive disclosure). Over time, as the model continues to get more capable -- so trajectories become more correct on average -- and as conversations become even longer, we need to manage the amount of information we present in the default view to keep it from feeling overwhelming.
When we started Claude Code, it was just a few of us using it. Now, a large number of engineers rely on Claude Code to get their work done every day. We can no longer design for ourselves, and we rely heavily on community feedback to co-design the right experience. We cannot build the right things without that feedback. Yoshi rightly called out that often this iteration happens in the open. In this case in particular, we approached it intentionally, and dogfooded it internally for over a month to get the UX just right before releasing it; this resulted in an experience that most users preferred.
But we missed the mark for a subset of our users. To improve it, I went back and forth in the issue to understand what issues people were hitting with the new design, and shipped multiple rounds of changes to arrive at a good UX. We've built in the open in this way before, eg. when we iterated on the spinner UX, the todos tool UX, and for many other areas. We always want to hear from users so that we can make the product better.
The specific remaining issue Yoshi called out is reasonable. PR incoming in the next release to improve subagent output (I should have responded to the issue earlier, that's my miss).
Yoshi and others -- please keep the feedback coming. We want to hear it, and we genuinely want to improve the product in a way that gives great defaults for the majority of users, while being extremely hackable and customizable for everyone else.
I can’t count how many times I benefitted from seeing the files Claude was reading, to understand how I could interrupt and give it a little more context… saving thousands of tokens and sparing the context window. I must be in the minority of users who preferred seeing the actual files. I love claude code, but some of the recent updates seem like they’re making it harder for me to see what’s happening.. I agree with the author that verbose mode isn’t the answer. Seems to me this should be configurable
I think folks might be crossing wires a bit. To make it so you can see full file paths, we repurposed verbose mode to enable the old explicit file output, while hiding more details behind ctrl+o. In effect, we've evolved verbose mode to be multi-state, so that it lets you toggle back to the old behavior while giving you a way to see even more verbose output, while still defaulting everyone else to the condensed view. I hope this solves everyones' needs, while also avoiding overly-specific settings (we wanted to reuse verbose mode for this so it is forwards-compatible going fwd).
To try it: /config > verbose, or --verbose.
Please keep the feedback coming. If there is anything else we can do to adjust verbose mode to do what you want, I'd love to hear.
FWIW I mentioned this in the thread (I am the guy in the big GH issue who actually used verbose mode and gave specific likes/dislikes), but I find it frustrating that ctrl+o still seems to truncate at strange boundaries. I am looking at an open CC session right now with verbose mode enabled - works pretty well and I'm glad you're fixing the subagent thing. But when I hit ctrl+o, I only see more detailed output for the last 4 messages, with the rest hidden behind ctrl+e.
It's not an easy UI problem to solve in all cases since behavior in CC can be so flexible, compaction, forking, etc. But it would be great if it was simply consistent (ctrl+o shows last N where N is like, 50, or 100), with ctrl+e revealing the rest.
Yes totally. ctrl+o used to show all messages, but this is one of the tricky things about building in a terminal: because many terminals are quite slow, it is hard to render a large amount of output at once without causing tearing/stutter.
That said, we recently rewrote our renderer to make it much more efficient, so we can bump up the default a bit. Let me see what it feels like to show the last 10-20 messages -- fix incoming.
How do you respond to the comment that; given the log trace:
“Did something 2 times”
That may as well not be shown at all in default mode?
What useful information is imparted by “Read 4 files”?
You have two issues here:
1) making verbose mode better. Sure.
2) logging useless information in default.
If you're not imparting any useful information, claude may as well just show a spinner.
It's a balance -- we don't want to hide everything away, so you have an understanding of what the model is doing. I agree that with future models, as intelligence and trust increase, we may be able to hide more, but I don't think we're there yet.
Not only what files, but what part of the files. Seeing 1-6 lines of a file that's being read is extremely frustrating, the UX of Claude code is average at best. Cursor on the other hand is slow and memory intensive, but at least I can really get a sense of what's going on and how I can work with it better.
> saving thousands of tokens and sparing the context window
shhh don't say that, they will never fix it if means you use less tokens.
There are so many config options. Most I still need to truly deeply understand.
But this one isn't? I'd call myself a professional. I use with tons of files across a wide range of projects and types of work.
To me file paths were an important aspect of understanding context of the work and of the context CC was gaining.
Now? It feels like running on a foggy street, never sure when the corner will come and I'll hit a fence or house.
Why not introduce a toggle? I'd happily add that to my alisases.
Edit: I forgot. I don't need better subagent output. Or even less output whrn watching thinking traces. I am happy to have full verbosity. There are cases where it's an important aspect.
You want verbose mode for this -- we evolved it to do exactly what you're asking for: verbose file reads, without seeing thinking traces, hook output, or (after tomorrow's release) full subagent output.
More details here: https://news.ycombinator.com/item?id=46982177
So in a nutshell Claude becoming smarter means that logic that once resided in the agent is being moved to the model?
If that's the case, it's important to asses wether it'll be consistent when operating on a higher level, less dependent on the software layer that governs the agent. Otherwise it'll risk Claude also becoming more erratic.
> this resulted in an experience that most users preferred
I just find that very hard to believe. Does anyone actually do anything with the output now? Or are they just crossing their fingers and hoping for the best?
Have you tried verbose mode? /config > verbose. It should do exactly what you are looking for now, without extraneous thinking/subagent/hook output. We hear the feedback!
Boris! Unrelated but thank you and the Anthropic team for Claude code. It’s awesome. I use it every day. No complaints. You all just keep shipping useful little UX things all the time. It must be because it’s being dogfooded internally. Kudos again to the team!
This is an insanely good response. History, backstory, we screwed up, what we're doing to fix it. Keep up the great work!
it reads like AI generated or at least AI assisted... those -- don't fool me!
fwiw, I wrote it 100% by hand. Maybe I talk to Claude too much..
would've been better to post the prompt directly IMO
ok claude
In what terminals is rendering slow? I really think GPU acceleration for terminals (as seen in Ghostty) is silly. It's a terminal.
Edit: I can't post anymore today apparently because of dang. If you post a comment about a bad terminal at least tell us about the rendering issues.
VSCode (xterm.js) is one of the worst, but there's a large long tail of slow terminals out there.
Not really using VS Code terminal anymore, just Ubuntu terminal but the biggest problem I have is that at some point Claude just eats up all memory and session crashes. I know it's not really Claude's fault but damn it's annoying.
As someone who's business is run through a terminal, not everyone uses ghostty, even though they should. Remember, that they don't have a windows version.
[dead]