Claude Code Features: Which Ones Are Worth Turning On

The question is adoption, not availability

Release notes answer what exists. They do not answer what belongs in your setup, and the two get conflated because trying a new capability is cheap and living with it is not.

A better rule: adopt a capability when it removes work you are currently doing by hand, repeatedly, and when you can state what it costs.

The costs are real and mostly invisible. A connected server adds tool schemas to every request for the whole session. A hook changes behavior in ways that are hard to trace when something goes wrong six weeks later. A subagent adds a boundary where context is lost. None of that shows up while you are evaluating the feature in isolation on a task you chose because it demonstrates the feature.

So the useful framing for anything new is: what does this replace, what does it cost on every request, and how would I notice if it were making things worse.

What each capability actually buys

Permissions. Configure these first, always. They decide what the agent can do without asking, which is the only control that survives a model being confused or manipulated. Everything else on this list is a convenience by comparison.

Project instructions. A file of standing context about the repository. Cheap, high value, and the most common thing teams under-invest in. Keep it to policy and conventions rather than facts that will go stale.

Skills. Packaged instructions for a recurring task, loaded when relevant. This is the best cost profile available: nothing is carried on turns where the task does not come up. Anything conditional belongs here rather than in standing instructions.

MCP servers. Access to systems the agent cannot otherwise reach. Genuinely necessary when access is missing, and expensive when it is not: every connected server registers tool schemas on every request, and a large tool surface degrades selection accuracy across all of them.

Subagents. Useful for real parallelism on independent tasks and for isolating tool permissions. Less useful as a context management trick than they were, and every boundary costs a cold start plus the reasoning that does not survive the handoff.

Hooks. Deterministic actions around agent events. Powerful, and the fastest way to build a setup nobody else on the team can debug. Use them for enforcement you would otherwise forget, such as running a formatter or blocking a commit, and document each one.

Background execution. Genuinely useful for long-running commands. Mostly free, since it changes when you wait rather than what is in the window.

A sane adoption order

Start with permissions, since they are the control layer. Then project instructions, kept short and limited to policy.

Then add a skill for the task you explain most often. If you find yourself repeating the same setup or the same review standard in conversation, that is the signal, and it is a better one than any feature announcement.

Then connect one MCP server, for a system the agent genuinely cannot reach. Use it for a week. Notice whether tool selection stayed sharp. Only then consider a second.

Hold hooks until you have a rule you keep forgetting to apply manually, and write down what each one does where a teammate will find it.

And audit periodically. Disconnect servers you connected once for a specific task, delete skills that never load, and reread your standing instructions for facts that have gone stale. Configuration accumulates the same way a system prompt does, and nobody removes anything unless it is somebody's job.

The capability that is not on the list

Most of what makes an agent effective on a real codebase is not a feature you enable. It is what the agent knows when it starts.

Pointed at an unfamiliar project, an agent spends its opening moves rediscovering the same facts: the module layout, the test command, the conventions, the reasoning behind an old decision. That work is identical every session and you pay generation prices for it every time. No amount of tool configuration removes it, because it is a knowledge problem rather than an access problem.

This is the layer RDK covers. Files from local vaults, docs, and code are indexed as encrypted private chunks, and agents search those chunks before querying a model. Token spend drops 80 to 90 percent on repeated or reference-heavy work because the answer is retrieved instead of regenerated. Stacked retrieval sets the proportions: a private vault answers 40 to 65 percent of queries, the public network adds 15 to 20 percent, and the model handles the remaining 5 to 10 percent.

A small, well permissioned setup with good retrieval beats a heavily configured one without it, and it stays comprehensible to the next person who has to work in it.