A short personal blog post became one of the most discussed Claude Code stories of the week. On October 6, 2026, developer Zohaib Ansari wrote "The smartest Claude Code feature is not for its users," arguing that the suggested next message Claude Code now pre-fills in your prompt box is really a cheap way to harvest preference data for training. The Hacker News thread reached 190 points and 104 comments, and an Anthropic engineer replied that it is not.
This post sets out the argument, the strongest objections from the thread, what is actually verifiable, and practical advice. We have no inside knowledge of Anthropic's training pipeline, and neither did the author, who said so himself.
TL;DR: the questions people are asking
| Question | Short answer |
|---|---|
| What is the feature? | A grayed-out suggested next message in the Claude Code prompt box. |
| What is the claim? | It doubles as a way to collect RLHF-style preference data. |
| What does Anthropic say? | Not used to collect preference signals; only acceptance counts, to measure usefulness. |
| Can it be proven either way? | Not from outside. Both positions are statements. |
| Can I turn it off? | Yes, per Anthropic, in settings. |
| Does my plan affect training use? | Yes. Check your plan's data terms and settings. |
The argument
The post makes a clean, plausible case in five steps.
- Feedback is hard to get. Every AI product has thumbs-up and thumbs-down buttons, few people click them, and those who do skew annoyed. Paid annotators are expensive and have to guess what a developer wanted in a codebase they do not know.
- Each suggestion is a prediction. The suggestion is the model's guess at your next turn, conditioned on the whole session.
- You grade it without noticing. Sending it untouched is a positive label. Editing it is worth more, because the original and your edit form a preference pair, and the diff shows where the guess went wrong. The author's example: a suggestion of "run the tests" edited to "run only the auth tests, the full suite takes ten minutes."
- This is the raw material for RLHF. The usual recipe collects human preferences between outputs and trains a reward model. Here the labels come from real repositories and real work, so they are in distribution.
- Predicting the next user turn is also a useful objective. A model that guesses what a competent developer asks next learns how work is sequenced: refactor, test, commit.
He ends with a caveat that matters: "I should say that I am guessing."
The strongest objections
The Hacker News thread produced several sharp rebuttals, and a few are worth taking seriously on their own.
You do not need to show the suggestion to get the data. Several commenters made this point: a lab could take existing conversations, truncate them before a user message, have the model predict the user's turn and compare it with what the user actually wrote. That yields the same supervision without influencing anyone. One commenter argued that showing the suggestion actually contaminates the signal, because users now react to model output instead of writing their own prompt.
Counter to the counter. Other commenters replied that a thread can have many reasonable follow-ups, so penalizing the model for not matching the one the user typed is unfair, while acceptance of a shown suggestion is cleaner evidence that a suggestion was acceptable. That is a real difference between passive comparison and active selection, though it still does not show anyone is using it.
The model gets this for free. A commenter noted that a language model trained to predict tokens already produces plausible user turns if you end a prompt at the start of a user message, so the feature may simply be exposing something the model does naturally, not building a data pipeline.
Most users are not experts. Another objection: the premise assumes users are competent developers who know the project better than the model and correct it. Many users accept the "recommended" next step like "commit," which would be a weak training signal.
It is a product feature. Some commenters see an onboarding aid for novices facing an empty prompt, or a reminder for people returning to a session. Others use it constantly during implementation to avoid typing "yes, go ahead."
What Anthropic said
An engineer who works on Claude Code, posting under the handle edwinarbus, replied in the thread:
Prompt suggestions aren't being used to collect preference signals. We built this feature purely to help you stay in the flow, or for people who are returning to the session after a while and may need a little reminder on what a next step could be. We do see how many suggestions are accepted, but that's only so we know how helpful this feature is overall! ... It can always be toggled on/off in settings if you don't like it.
Two things to note. First, it is a clear, specific denial: no preference-signal collection, with acceptance rate tracked as a product metric. Second, it is a comment by one employee on a forum, not a published policy, and it does not address broader training use of session data, which is governed by account terms. A fair reading is that the denial is credible and worth taking at face value, and that it does not settle the larger question every user should ask: under my plan, what happens to my sessions?
The author updated his post to include the reply, which is the right way to handle a correction.
What you can actually verify
| Claim | Can you check it? |
|---|---|
| The feature exists and is on by default | Yes, in your own Claude Code |
| It can be toggled | Yes, in settings |
| Acceptance rates are measured | Anthropic says so; not independently checkable |
| Suggestions are used for preference training | Denied by Anthropic; not checkable from outside |
| Sessions are used for training in general | Depends on plan and settings; check current terms |
The honest conclusion is that this is an unresolved disagreement between a plausible theory and a plausible denial, with no outside evidence either way. The theory is useful as a reminder of how feedback is gathered in AI products. It is not evidence of what Anthropic does.
The broader privacy question
The part of the thread with the most practical value was not about suggestions at all. Several commenters raised the question of whether paid plans train on prompts, and others noted that if you submit feedback, the session may be collected. Specific points:
- Training use of conversations varies by plan: consumer, team, enterprise and API terms differ, and they change. Do not rely on a forum comment, including ours. Read the current terms.
- Giving explicit feedback can attach a session to that feedback. The "How is Claude doing?" prompt is one such channel.
- Enterprise and zero-retention arrangements exist for organizations that need stronger guarantees. We covered Anthropic's 30-day retention and enterprise ZDR options and the privacy design choices in Instinct's data retention approach.
- If your code is sensitive, treat any cloud agent as a data-processing relationship and configure it accordingly.
One commenter also pointed out that a separate system generates the suggestion and the main Claude Code agent cannot control it, which is a design detail worth knowing if you try to instruct the agent to stop suggesting.
Practical advice
- Decide if you want it. Many users like the Tab-to-accept flow during implementation, others find it breaks their focus. Neither is wrong.
- Toggle it in settings if you do not want it. Anthropic says the option exists, and commenters also mention pressing space to hide a suggestion.
- Check your data settings and plan terms for training use, regardless of this feature.
- Mind context size. One commenter noted that "staying in flow" tends to extend long sessions, which grows context and cost. Running
/clearperiodically is still good hygiene, as in our Claude Code commands reference. - Be careful with blind acceptance. A suggested "commit this" or a risky command is one keystroke away. Our guides to permission modes explain how to keep a human check in the loop.
- Do not feed poison on purpose. Some commenters joked about answering suggestions with destructive commands or giving deliberately wrong thumbs ratings. That is a bad idea for your own repository and your own session, and it harms other users' signal quality without proving anything.
What this means for what you build or pay
For users, nothing changes except awareness: understand which of your interactions are feedback, and what your plan says about training. For builders of AI products, the episode is a lesson in how any feature that predicts a user's next action can be read as a data-collection mechanism. If you ship one, say plainly what you do and do not do with the signal, put the toggle where people can find it and publish the policy, not only a forum reply. Trust in agent tools is built or lost on exactly this kind of clarity, a theme running through our recent posts on agent permissions and disputed agent incident claims.
Related reading
- Claude Code commands: complete reference
- Claude Code permission modes explained
- Claude Code function hooks and ant apply
- Anthropic's 30-day retention and enterprise ZDR
- Instinct: agent privacy and data retention
- What is AI distillation?
- RLHF, constitutional AI and scalable oversight
- Claude memory heist: exfiltration research
Primary: Zohaib Ansari, "The smartest Claude code feature is not for its users" (October 6, 2026) · the Hacker News discussion, including the reply from an Anthropic engineer working on Claude Code
Details are accurate as of October 7, 2026 and come from the blog post and public comments. We have no inside knowledge of Anthropic's training practices. The Anthropic reply is one employee's public statement, not a policy document; check current data terms for your plan.