Hacker News Reader

Comment by bcherny | Hacker News Reader

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.

View on HN

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?”

Yeah, in hindsight, we probably should have renamed it.

It's not too late.

This verbose mode discussion has gotten quite verbose lol

You can call it “output granularity” and allow Java logger style configuration, e.g. allowing certain operations to be very verbose while others being simply aggregated

If we're going there, we need to make the logging dynamically configurable with Log4J-style JNDI and LDAP. It's entirely secure as history has shown - and no matter what, it'll still be more secure than installing OpenClaw!

(Kidding aside, logging complexity is a slippery slope, and I think it's important, perhaps even at a societal level, for an organization like Anthropic to default to a posture that allows people to feel they have visibility into where their agentic workflows are getting their context from. To the extent that "___ puts you in control" becomes important as rogue agentic behavior is increasingly publicized, it's in keeping with, and arguably critical to, Claude's brand messaging.)

They don’t have to reproduce it literally. It’s an UX problem with many solutions. My point is, you cannot settle on some „average“ solution here. It’s likely that some agents, some operations will be more trustworthy, some less, but that will be highly dependent on context of the execution.

> 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.

Verbose mode feels far too verbose to handle that. It’s also very hard to “keep your place” when toggling into verbose mode to see a specific output.

I think the point bcherny is making in the last few threads is that, the new verbose mode _default_ is not as verbose as it used to be and so it is not "too verbose to handle that". If you want "too verbose", that is still available behind a toggle

Yeah, I didn't realize that there's a new sort of verbose mode now which is different than the verbose mode that was included previously. Although I'm still not clear on the difference between "verbose mode" and "ctrl + o". Based on https://news.ycombinator.com/item?id=46982177 I think they are different (specifically where they say "while hiding more details behind ctrl+o".

Feels like you aren’t really listening to the feedback. Is verbose mode the same as the explicit callouts of files read in the previous versions? Yes, you intended it to fulfill the same need, but, take a step back. Is it the same? I’m hearing a resounding “no”. At the very least if you hace made such a big change, you’ve gotten rid of the value of a true “verbose mode”.

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) ?

> Another thing: is it possible to turn off the words like finagling and similar (I can't remember the spelling of any of them) ?

Big +1 on that. I find the names needlessly distracting. I want to just always say a single thing like “thinking”

I remember they shipped a feature so that’s configurable.

You should be able to do something like this:

    "spinnerVerbs": {
      "mode": "replace",
      "verbs": ["Thinking"]
    }

https://code.claude.com/docs/en/settings#available-settings

Thank you for the config and the link, that's very much appreciated!

How absurd this is an option, but I’ll be using this config too.

I replaced my spinner verbs with thought-provoking Yodaese so my claude sessions are constantly making me think about my life decisions. Loving it. https://gist.github.com/topherhunt/b7fa7b915d6ee3a7998363d12...

> I want to just always say a single thing like “thinking”

As a counterview, I like the whimsical verbs. I'll be sticking with them. But nice to see there is an option.

I don't want my tools to make jokes, I want them to work.

We don’t want verbose mode. We don’t want the whole file contents. We are not asking for that. What is not clear here?

All we want is the file paths. That is all. Verbose mode pulls in a lot of other information that might very well be needed in other contexts. People who want that info should use verbose mode. All we want is the regular non-verbose mode, with paths.

I fail to see how it is confusing to users, even new users, to print which paths were accessed. I fail to see the point of printing that some paths were accessed, but not which.

Verbose mode does exactly what you want as of v2.1.39, you are confusing it with the full transcript which is a different feature (ctrl+o). You enable verbose mode in /config and it gives you files read and search patterns and token count, not whole file contents.

Please don’t change what these modes do! I have scripts that call into the agent SDK with verbose mode output for logging purposes. Now I guess I need to recreate the old verbose mode for that application? Why?

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.

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".

Your worst nightmare. For me this is the cool part.

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.

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.

I'm with you on this one. "Terminals are too slow to support lots of text so we had to change this feature in unpopular ways" is just not a plausible reason, as terminals have been able to dump ~1Mb per second for decades.

The real problem is their ridiculous "React rendering in the terminal" UI.

> It's so trivial, can't you ask your fancy LLM to do it for you?

They did. And the result was a React render loop that takes 16ms to output a hundred characters to screen and tells them it will take a year to rewrite: https://x.com/trq212/status/2014051501786931427

What's extra funny is that curses diffs a virtual "current screen" to "new screen" to produce the control codes that are used to update the display. Ancient VDOM technology, and plenty fast enough.

Do you have any examples of slow terminals, and what kind of maximum characters per second they have?

> because many terminals are quite slow, it is hard to render a large amount of output at once without causing tearing/stutter.

Only if you use React as your terminal renderer. You're not rendering 10k objects on screen in a few milliseconds. You're outputting at best a few thousand characters. Even the slowest terminal renderer is capable of doing that.

Terminals already solved how to do this decades ago: pagers.

Write the full content to a file and have less display it. That's a single "render" you do once and write to a file.

Your TUI code spawns `less <file>` and waits. Zero rendering loop overhead, zero tearing, zero stutter. `less` is a 40-year-old tool that exists precisely to solve this problem efficiently.

If you need to stream new content in as the session progresses, write it to the file in the background and the user can use `less +F` (follow mode, like tail -f) to watch updates.

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?

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.

That's a cool idea!

Honestly Tmux, vim, kitty, almost every terminal, shell, script is configurable. It’s what we’re used to. I wouldn’t know why you wouldn’t start allowing more config options.

I do not use CC (yet) but I think this is the right direction. We are hackers. We love hacking. We love to tinker about and configure! Please allow us.

(And yeah, I would love the verbose mode myself, but there could be various levels to it.)

Exactly. If a user wants a simpler experience there is now the Claude Cowork option.

ok, I will be the dumbass here - I am a retired software engineer who has not used any of these tools, but when I as working on high volume web sites, all I wanted and needed was access to the log files. I would always have a small terminal session open to tail and grep for errors for the areas I was interested in. Had another small window to tail and monitor specific performance values. Etc.

I do not know how this concept would work in these agentic environments, but would seem useful, in an environment that has a lot of parallel things going on, with a lot of metrics that could be useful, you would want to have multiple monitors that can be quickly customized with standard linux utilities. Token usage, critical directory access, etc.

This, in conjunction with a config file to define/filter out the log stream should be all that's needed to provide as much or as little detail that would be needed to monitor how things are going, and to alert when certain things are going off the rails.

Maybe during onboarding you could ask for output preference? That would at least help new users.

I find this decision weird due to claude _code_, while being used by _some_ non-technical users, is mostly used by technical users and developers.

Not sure why the choice would be to dumb the output down for technical users/developers.

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:

  - Thoughts
  - Files read / written
  - Bashes
  - Subagents

etc.

One use I have for seeing what exactly it is doing is to press Esc quick when I see it's confused and starts searching for some info that eg got compacted away, often going on a big quest like searching an entire large directory tree etc. What would actually wish is if it would ask me in these cases. It clearly know that it lacks info but thinks it can figure it out by itself by going on a quest and that's true but takes too long. It could just ask me. There could be some mode settings of how much I want to be involved and consulted, like just ask boldly for any factual info from me, or if I just want to step away and it should just figure everything out on its own.

Have you considered keeping the old behavior available as "legacy mode"? I don't want verbose mode. I don't want to spend time configuring a mutli-state verbose mode that introduces new logging in future versions so I have to go and suppress things to get just file names. I just want to see the file names. I don't consider that verbose.

Reply on news.ycombinator.com