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.
I'll add a counterpoint that in many situations (especially monorepos for complex businesses), it's easy for any LLM to go down rabbit holes. Files containing the word "payment" or "onboarding" might be for entirely different DDD domains than the one relevant to the problem. As a CTO touching all sorts of surfaces, I see this problem at least once a day, entirely driven by trying to move too fast with my prompts.
And so the very first thing that the LLM does when planning, namely choosing which files to read, are a key point for manual intervention to ensure that the correct domain or business concept is being analyzed.
Speaking personally: Once I know that Claude is looking in the right place, I'm on to the next task - often an entirely different Claude session. But those critical first few seconds, to verify that it's looking in the right place, are entirely different from any other kind of verbosity.
I don't want verbose mode. I want Claude to tell me what it's reading in the first 3 seconds, so I can switch gears without fear it's going to the wrong part of the codebase. By saying that my use case requires verbose mode, you're saying that I need to see massive levels of babysitting-level output (even if less massive than before) to be able to do this.
(To lean into the babysitting analogy, I want Claude to be the babysitter, but I want to make sure the babysitter knows where I left the note before I head out the door.)
> I don't want verbose mode. I want Claude to tell me what it's reading in the first 3 seconds, so I can switch gears without fear it's going to the wrong part of the codebase. By saying that my use case requires verbose mode, you're saying that I need to see massive levels of babysitting-level output (even if less massive than before) to be able to do this.
To be clear: we re-purposed verbose mode to do exactly what you are asking for. We kept the name "verbose mode", but the behavior is what you want, without the other verbose output.
This is an interesting and complex ui decision to make.
Might it have been better to retire and/or rename the feature, if the underlying action was very different?
I work on silly basic stuff compared to Claude Code, but I find that I confuse fewer users if I rename a button instead of just changing the underlying effect.
This causes me to have to create new docs, and hopefully triggers affected users to find those docs, when they ask themselves “what happened to that button?”
I thought I was the only person going crazy by the new default behavior not showing the file names! Please don't expect users to understand your product details and config options in such detail, it was working well before, let it remain. Or at least show some message like "to view file names, do xyz" in the ui for a few days after such a change.
While we're here, another thing that's annoying: the token counter. While claude is working, it read some files, makes an edit, let's say token counter is at 2k tokens, I accept the edit, now it starts counting very fast from 0 to 2k and then shows normal inference speed changes to 2.1k, 2.3k etc. So wanted to confirm: is that just some UI decision and not actually using 2k tokens again? If so, it would be nice to have it off, just continue counting where you left off.
Another thing: is it possible to turn off the words like finagling and similar (I can't remember the spelling of any of them) ?
Honestly, I just want to be able to control precisely what I see via config.json. It will probably differ depending on the project. This is a developer tool, I don't see why you'd shy away from providing granular configuration (alongside reasonable defaults).
I actually miss being able to see all of the thinking, for example, because I could tell more quickly when the model was making a wrong assumption and intervene.
Exactly. If a user wants a simpler experience there is now the Claude Cowork option.
That's a cool idea!
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.
Just tell people to install a fast terminal if they somehow happen to have a slow one?
Heck, simply handle the scrolling yourself a la tmux/screen and only update the output at most every 4ms?
It's so trivial, can't you ask your fancy LLM to do it for you? Or you guys lost the plot at his point and forgot the most basics of writing non pessimized code.
thanks dude. you are living my worst nightmare which is that my ultra cool tech demo i made for cracked engineers on the bleeding edge with 128GB ram apple silicon using frontier AI gets adopted by everyone in the world and becomes load bearing so now it needs to run on chromebooks from 2005. and if it doesn't work on those laptops then my entire company gets branded as washed and not goated and my cozy twitter account is spammed with "why didn't you just write it in rust lel".
o7
Why would you tailor your product for people that don’t know how to install a good terminal? Just tell them to install whatever terminal you recommend if they see tearing.
I've commented on this ticket before: https://github.com/anthropics/claude-code/issues/8477#issuec...
The thinking mode is super-useful to me as I _often_ saw the model "think" differently from the response. Stuff like "I can see that I need to look for x, y, z to full understand the problem" and then proceeds to just not do that.
This is helpful as I can interrupt the process and guide it to actually do this. With the thinking-output hidden, I have lost this avenue for intervention.
I also want to see what files it reads, but not necessarily the output - I know most of the files that'll be relevant, I just want to see it's not totally off base.
Tl;dr: I would _love_ to have verbose mode be split into two modes: Just thinking and Thinking+Full agent/file output.
---
I'm happy to work in verbose mode. I get many people are probably fine with the standard minimal mode. But at least in my code base, on my projects, I still need to perform a decent amount of handholding through guidance, the model is not working for me the way you describe it working for you.
All I need is a few tools to help me intervene earlier to make claude-code work _much_ better for me. Right now I feel I'm fighting the system frequently.
Yep, this is what we landed now, more or less: verbose mode is just file paths, then ctrl+o gives you thinking, agent output, and hook output.
Have you considered picking a new name for a different concept?
Or have ctrl+o cycle between "Info, Verbose, Trace"?
Or give us full control over what gets logged through config?
Ideally we would get a new tab where we could pick logging levels on:
etc.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.
That's perfectly reasonable, but I genuinely don't understand how "read 2 files" is ever useful at all. What am I supposed to do with this information? How can it help me redirect the model?
Like, I'm open to the idea that I'm the one using your software the wrong way, since obviously you know more about it than I do. What would you recommend I do with the knowledge of how many files Claude has read? Is there a situation where this number can tell me whether the model is on the right track?
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.
I'm a screen reader user and CTO of an accessibility company. This change doesn't reduce noise for me. It removes functionality.
Sighted users lost convenience. I lost the ability to trust the tool. There is no "glancing" at terminal output with a screen reader. There is no "progressive disclosure." The text is either spoken to me or it doesn't exist.
When you collapse file paths into "Read 3 files," I have no way to know what the agent is doing with my codebase without switching to verbose mode, which then dumps subagent transcripts, thinking traces, and full file contents into my audio stream. A sighted user can visually skip past that. I listen to every line sequentially.
You've created a situation where my options are "no information" or "all information." The middle ground that existed before, inline file paths and search patterns, was the accessible one.
This is not a power user preference. This is a basic accessibility regression. The fix is what everyone in this thread has been asking for: a BASIC BLOODY config flag to show file paths and search patterns inline. Not verbose mode surgery. A boolean.
Please just add the option.
And yes, I rewrote this with Claude to tone my anger and frustration down about 15 clicks from how I actually feel.
Hey -- we take accessibility seriously, and want Claude Code to work well for you. This is why we have repurposed verbose mode to do what you want, without the other verbose output. Please give it a try and let me know what you think.
> we take accessibility seriously
Do you guys have a screen reader user on the dev team?
Is verbose mode the same as the old mode, where only file paths are spoken? Or does it have other text in it? Because I tried to articulate, and may have failed. More text is usually bad for me. It must be consumed linearly. I need specific text.
Quality over quantity
"Is verbose mode the same as the old mode, where only file paths are spoken?" -- yes, this is exactly what the new verbose mode is.
And how to get to the old verbose mode then...?
Try Codex instead. Much greener pastures overall
I do love my subagents and I wrote an entire Claude Code audio hook system for a11y but this would be still rather compelling if Codex weren't also somewhat of an a11y nightmare. It does some weird thing with ... maybe terminal repaints or something else that ends up rereading the same text over and over. Claude Code does this similarly but Codex ends up reading like ... all the weird symbols and other stuff? window decorations? and not just the text like CC does. They are both hellish but CC slightly? less so... until now.
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.
I'm going to be paranoid and guess they're trying to segment the users into those that'll notice they're dumbing down the system via caches, limited model via quantized downgrade and those that expect the fully available tools.
Thariq (who's on the Claude Code team) swears up and down that they do not do this.
Honestly, man, this is just weird new tech. We're asking a probabilistic model to generate English and JSON and Bash at the same time in an inherently mutable environment and then Anthropic also release one or two updates most workdays that contain tweaks to the system prompt and new feature flags that are being flipped every which way. I don't think you have to believe in a conspiracy theory to understand why it's a little wobbly sometimes.
> 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!
> 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.
How can that be true, when you're deliberately and repeatedly telling devs (the community you claim to listen to) that you know better than they do? They're telling you exactly what they want, and you're telling them, "Nah." That isn't listening. You understand that, right?
I’m witnessing him respond in real time with not just feedback but also actual changes, in a respectful and constructive manner - which is not easy to do, when there are people who communicate in this rude of a manner. If that’s not listening, then I don’t know what is.
And it shouldn’t need to be said, but the words that appear on the screen are from an actual person with, you know, feelings.
interesting. they have been pretty receptive to my pull comments and discourse on issues. To each's anecdote I suppose.
boris-4.6-humble
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!
> in some terminal emulators, rendering is extremely slow.
Ooo... ooo! I know what this is a reference to!
https://www.youtube.com/watch?v=hxM8QmyZXtg
> 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.
That's why I use your excellent VS Code extension. I have lots of screen space and it's trivial to scroll back there, if needed.
I would really like even more love given to this. When working with long-lived code bases it's important to understand what is happening. Lots of promising UX opportunities here. I see hints of this, but it seems like 80% is TBD.
Ideally you would open source the extension to really use the creativity of your developer user base. ;)
@boris
Can we please move the "Extended Thinking" icon back to the left side of claude desktop, near the research and web search icons? What used to be one click is now three.
this was written with claude lmao what a disgrace not to put a disclaimer.
use your own words!
i would rather read the prompt.
This is an insanely good response. History, backstory, we screwed up, what we're doing to fix it. Keep up the great work!
would've been better to post the prompt directly IMO
Prompts can be the new data compression. Just send your friend a prompt and the heartfelt penpal message gets decompressed at their end.
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..
i thought about it being ai generated, but i don't care. it was easy to read and contained the right information. good enough for me. plus, who knows... maybe you were english as a second lang and used ai to clean up your writing. i'd prefer that.
so its the users who are dumb :-)
To be honest I think there should be an option to completely hide all code that Claude generates and uses. Summaries, strategies, plans, logs, decisions and questions is all I need. I am convinced that in a few years nobody cares about the programming language itself.
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]
ok claude