3
points
bcherny
Joined 2,455 karma
- bcherny parentWe wanted to share more about why this was so difficult, how the fix works and how we used Claude Code to fix it
- Try to keep it under 1k tokens or so. We will show you a warning if it might be too big.
Ours is maybe half that size. We remove from it with every model release since smarter models need less hand-holding.
You can also break up your CLAUDE.md into smaller files, link CLAUDE.mds, or lazy load them only when Claude works in nested dirs.
- Hey, Boris from the Claude Code team here. A few tips:
1. If there is anything Claude tends to repeatedly get wrong, not understand, or spend lots of tokens on, put it in your CLAUDE.md. Claude automatically reads this file and it’s a great way to avoid repeating yourself. I add to my team’s CLAUDE.md multiple times a week.
2. Use Plan mode (press shift-tab 2x). Go back and forth with Claude until you like the plan before you let Claude execute. This easily 2-3x’s results for harder tasks.
3. Give the model a way to check its work. For svelte, consider using the Puppeteer MCP server and tell Claude to check its work in the browser. This is another 2-3x.
4. Use Opus 4.5. It’s a step change from Sonnet 4.5 and earlier models.
Hope that helps!
- Fair feedback — commented https://github.com/anthropics/claude-code/issues/3648#issuec...
- We started by using Ink, and at this point it’s our own framework due to the number of changes we’ve made to it over the months. Terminal rendering is hard, and it’s less that we haven’t modified the renderer, and more that there is this pretty fundamental tradeoff with terminal rendering that we have been navigating.
Other terminal apps make different tradeoffs: for example Vim virtualizes scrolling, which has tradeoffs like the scroll physics feeling non-native and lines getting fully clipped. Other apps do what Claude Code does but don’t re-render scrollback, which avoids flickering but means the UI is often garbled if you scroll up.
- Hey, Boris from the Claude Code team here. We try hard to read through every issue, and respond to as many issues as possible. The challenge is we have hundreds of new issues each day, and even after Claude dedupes and triages them, practically we can’t get to all of them immediately.
The specific issue you linked is related to the way Ink works, and the way terminals use ANSI escape codes to control rendering. When building a terminal app there is a tradeoff between (1) visual consistency between what is rendered in the viewport and scrollback, and (2) scrolling and flickering which are sometimes negligible and sometimes a really bad experience. We are actively working on rewriting our rendering code to pick a better point along this tradeoff curve, which will mean better rendering soon. In the meantime, a simple workaround that tends to help is to make the terminal taller.
Please keep the feedback coming!
- Boris from the Claude Code team here.
We actually don't train on this survey data. It's just for vibes so we can make sure people are having a good experience.
See https://code.claude.com/docs/en/data-usage#session-quality-s...
- Hey HN, Boris from the Claude Code team here. Sharing a bit about why we have this survey, how we use it, and how to opt out of it-
1. We use session quality feedback as a signal to make sure Claude Code users are having a good time. It's helpful data for us to more quickly spot & prevent incidents like https://www.anthropic.com/engineering/a-postmortem-of-three-.... There was a bug where we were showing the survey too often, which is now fixed (it was annoying and a misconfiguration on our part).
2. Giving session quality feedback is totally optional. When you provide feedback, we just collect your numerical rating and some metadata (like OS, terminal, etc.). Giving feedback doesn't cause us to log your conversation, code, or anything like that. (docs: https://code.claude.com/docs/en/data-usage#session-quality-s...)
3. We don't train on quality feedback data. This is documented in the link above.
4. If you don't want to give feedback, you can permanently turn it off for yourself by setting CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 in your env or settings.json file. (docs: https://code.claude.com/docs/en/settings)
5. To permanently turn off the feedback survey for your whole company, set CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 in the settings.json checked into your codebase, or in your enterprise-managed settings.json (docs: https://code.claude.com/docs/en/settings)
6. You can also opt out of both telemetry + survey by setting CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1, or you can more granularly opt out with DISABLE_ERROR_REPORTING=1, DISABLE_TELEMETRY=1, etc. (also documented in the settings docs)
Security and privacy are very important, and we spend a lot of time getting these right. You have full control over data usage, telemetry, and training, and these are configurable for yourself, for your codebase, and for all your employees. We offer all of these options out of the box, so you can choose the mechanism that makes the most sense for you.
If there is a setting or control that is missing, or if anything is unclear from the docs, please tell us!
- Fast dev tools are awesome and I am glad the TS team is thinking deeply about dev experience, as always!
One trade off is if the code for TS is no longer written in TS, that means the core team won’t be dogfooding TS day in and day out anymore, which might hurt devx in the long run. This is one of the failure modes that hurt Flow (written in OCaml), IMO. Curious how the team is thinking about this.
- Thanks everyone for all your questions! The team and I are signing off. Please drop any other bugs or feature requests here: https://github.com/anthropics/claude-code. Thanks and happy coding!
- Good idea! Tracking here: https://github.com/anthropics/claude-code/issues/16
- When you are prompted to accept a bash command, we should be giving you the option to not ask again. If you're not seeing that for a specific bash command, would you mind running /bug or filing an issue on Github? https://github.com/anthropics/claude-code/issues
Thinking and not thinking is actually the same model! The model thinks automatically when you ask it to. If you don't explicitly ask it to think, it won't use thinking.
- We wanted to bring the model to people where they are without having to commit to a specific tool or radically change their workflows. We also wanted to make a way that lets people experience the model’s coding abilities as directly as possible. This has tradeoffs: it uses a lot of tokens, and is rough (eg. it shows you tool errors and model weirdness), but it also gives you a lot of power and feels pretty awesome to use.
- The blog post also talks about how privacy is preserved in more concrete terms:
> These four steps are powered entirely by Claude, not by human analysts. This is part of our privacy-first design of Clio, with multiple layers to create “defense in depth.” For example, Claude is instructed to extract relevant information from conversations while omitting private details. We also have a minimum threshold for the number of unique users or conversations, so that low-frequency topics (which might be specific to individuals) aren’t inadvertently exposed. As a final check, Claude verifies that cluster summaries don’t contain any overly specific or identifying information before they’re displayed to the human user.