{"slug": "claude-s-new-projects-and-goal-features-a-practical-guide", "title": "Claude's New Projects and /goal Features: A Practical Guide", "summary": "Claude Code's September redesign turns Projects into an orchestration layer: the main project thread delegates work to independent sub-threads that inherit the project's instructions and memory and keep running after the laptop is closed, while connectors work only inside sub-threads, not the main conversation. Threads default to Opus at high effort, which the guide warns burns through usage limits quickly, and the /goal command loops Claude until a condition is met but its checker model only reads the conversation and never opens files or runs code, so vague goals get rubber-stamped early. The guide also cites Anthropic's published finding that retrieval accuracy drops as context windows fill, arguing for keeping reusable context at the project level and task-specific context in files loaded only when needed.", "body_md": "# Claude's New Projects and /goal Features: A Practical Guide\n\nHow Claude Code's redesigned Projects and the /goal command work, including orchestrator threads, connectors, and verification pitfalls.\n\n## What changed in Claude Code’s Projects feature?\n\nClaude Code’s Projects used to be a folder holding several separate chats with no real link between them. As of the September redesign, a project is one continuous conversation that acts like a team lead rather than doing the work itself. You brief the main thread, and it spins up multiple sub-threads underneath it to actually execute tasks. Each thread is a full Claude Code session that starts with the project’s instructions and memory already loaded, and it keeps running even after you close your laptop.\n\nThis matters because it changes what a “project” is for. It’s no longer a storage folder. It’s an orchestration layer that delegates work to independent sessions while holding the broader context (brand voice, standing rules, long-running goals) that those sessions pull from.\n\n## TL;DR\n\n- **Projects now behave as orchestrators** : the main project thread delegates to separate sub-threads instead of being the place where work actually happens.\n- **Only sub-threads can use connectors** , not the main project conversation, so anything touching outside tools has to run through a delegated thread.\n- **Threads default to Opus on high effort** , which burns through usage limits fast, so checking project settings before starting is worth the two minutes.\n- **The /goal command loops Claude automatically** until a condition is met, but the checker model only reads the conversation, it never opens files or runs code itself.\n- **Vague goals get rubber-stamped early** because the checker takes Claude’s word for it, so goals need verifiable proof inside the chat, like a script’s output.\n- **Skills should now be corrections, not manuals** , since current models already handle most step-by-step procedures that older skill packs spelled out.\n- **Default settings (Opus 5.5, medium effort) now outperform most manual tweaks** , including the common instinct to crank effort to max or switch to a cheaper model mid-task.\n\n## Other agents start typing. Remy starts asking.\n\nScoping, trade-offs, edge cases — the real work. Before a line of code.\n\n## How do orchestrator threads actually work?\n\nThe core mechanic is delegation. The main project conversation holds context and instructions but doesn’t execute tasks directly. When you give it a job, it creates one or more sub-threads, each a standalone Claude Code session that inherits the project’s memory and instructions at the moment it’s created. From there, the thread works independently, including continuing after you’ve closed the application.\n\nTwo practical constraints follow from this. First, connectors (the integrations that let Claude touch external tools and data) only work inside threads, not in the main project conversation. If your workflow depends on pulling from a connected tool, that step has to happen in a delegated thread, not at the orchestrator level. Second, threads default to Opus running at high effort, which is the most capable but also the most usage-intensive combination available. Anyone on a capped plan should check and adjust the project’s effort settings before kicking off multiple threads, or usage limits will disappear quickly.\n\nThis design lines up with a broader finding Anthropic has published about context handling: accuracy at retrieving specific details drops as context windows fill up. A model finding details scattered across a quarter of its context window performs meaningfully better than the same model searching the same details across a full million-token window. That’s the practical argument for keeping broad, reusable context (brand voice, standing rules) at the project level, and narrower task-specific context inside pointers or files that get loaded only when needed, rather than dumping everything into one giant running conversation.\n\n## What is the /goal command and how does verification work?\n\nThe /goal command is built to keep Claude working on a task until a defined condition is satisfied, removing the need to manually type “continue” after every turn. After each turn, a separate, smaller checking model reviews the conversation and decides whether the goal has been met. If not, it loops Claude back to keep working.\n\nThe limitation is in how that checker operates. It doesn’t open files, run scripts, or execute anything. It only reads the text of the conversation that’s happened so far. That means if your goal is phrased as something subjective or ambiguous, like “the report is finished,” the checker has no independent way to confirm that. It just evaluates whether Claude’s own conversation claims the report is finished, and if Claude says so, the checker will often stop the loop early, even if the report isn’t actually done.\n\nThe fix is to give /goal something it can verify from conversation text alone: a deterministic check whose output gets printed into the chat. A goal like “the check report script passes and you show me the output” works because the pass/fail result and the output itself land directly in the conversation, giving the checker something concrete to confirm rather than a claim to take on faith. Setting up that kind of check (a script with clear deterministic output) before running /goal is a necessary step, not an optional one.\n\n## Other agents ship a demo. Remy ships an app.\n\nReal backend. Real database. Real auth. Real plumbing. Remy has it all.\n\n## Are skills and manual settings still worth building?\n\nA test referenced in recent discussion ran nine popular Claude skill packs against a dummy file of similar length. Seven of the nine performed no better than the dummy file did on its own. The reason is that current models already do, by default, much of what older skills were written to instruct: avoiding generic AI-sounding writing, following basic structural conventions, applying common-sense formatting. Skills built months ago as full step-by-step manuals are now mostly redundant with what the model already knows.\n\nThe practical shift is in what a skill should contain. Rather than a standard operating procedure, a skill should now be a short list of corrections: the specific things Claude gets wrong by default, plus any niche knowledge it can’t infer on its own. Anthropic’s own guidance recommends attempting a task without a skill first, noting only what went wrong, and building the skill from that gap rather than writing out the entire process. There’s also a skill eval plugin available that runs a task both with and without a given skill, so you can directly compare outputs and decide whether the skill still earns its place in context, or whether it should be trimmed or dropped.\n\nThe desktop app’s “record a skill” feature applies the same logic in a more automated way: it watches a demonstrated task and writes a skill based on what it observed, typically picking up only the corrections and nuances a person applied, not the whole procedure. Skills built this way tend to come out short, which tracks with the idea that the model already handles the bulk of the task correctly.\n\n## Is it still worth tweaking models and effort levels manually?\n\nLargely no, according to Anthropic’s own current guidance, and the mechanics explain why. Switching to a cheaper model mid-session to save money on an easy question often backfires, because each model maintains its own cache of the conversation. Switching models forces the full conversation to be reprocessed from scratch on the new model at full price, and switching back repeats the cost again. The result can be more expensive in tokens than just staying on the stronger model throughout.\n\nCheaper models can also need more attempts to reach the same quality bar, which adds up in both tokens and time even though the per-token price is lower. One test found a smaller model needed more requests to match the larger model’s output quality and took close to twice as long on longer sessions.\n\n## Remy doesn't build the plumbing. It inherits it.\n\nOther agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.\n\nRemy ships with all of it from MindStudio — so every cycle goes into the app you actually want.\n\nAnthropic’s current recommendation is to pick a model at the start of a job and stick with it, using effort level (not model choice) as the lever for easier questions. There’s also an experimental “advisor” setting that lets a cheaper model handle routine work while calling in a stronger model for specific moments: before committing to an approach, when the same error recurs, or before declaring a task complete. This doesn’t trigger the same caching penalty that switching models outright does, though it’s still marked experimental and subject to change.\n\nOn effort levels specifically, the instinct to max out effort for better results doesn’t consistently hold. Opus 5.5 running on medium effort has been shown to match or beat Opus 5 running on high or max effort, meaning the newer model’s default setting is already tuned to outperform manual overrides in many cases.\n\n## Frequently Asked Questions\n\n### What’s the difference between a Claude project and a regular chat now?\n\nA project is a persistent, ongoing conversation that delegates tasks to independent sub-threads, each a full session with its own memory and instructions. A regular chat is a single session where you still have to manually carry context between conversations, typically by sharing links between them.\n\n### Why does /goal sometimes stop before a task is actually finished?\n\nThe model that checks whether a goal is met only reads the conversation text. It doesn’t run code or open files, so if the goal is phrased in a way that Claude can claim is “done” without proof, the checker will often accept that claim and stop early.\n\n### Do I still need plan mode in Claude Code?\n\nThe people who built Claude Code have said plan mode itself is less necessary than before, since current models can plan inside a written artifact just as effectively. The underlying practice of defining what “done” looks like and setting guardrails before starting is still considered useful, even without using the dedicated plan mode toggle.\n\n### Should I delete all my existing Claude skills?\n\nNot automatically. The recommendation is to test each skill against running the same task without it, using a side-by-side comparison, and keep only the skills that produce a measurably better result than the model’s default behavior.\n\n### Is switching to a cheaper model mid-task actually a good way to save money?\n\nUsually not. Each model keeps a separate cache of the conversation, so switching models forces a full, expensive reprocessing of the conversation history. Staying on one model for the duration of a task and adjusting effort level instead is generally cheaper and simpler.", "url": "https://wpnews.pro/news/claude-s-new-projects-and-goal-features-a-practical-guide", "canonical_source": "https://www.mindstudio.ai/blog/claude-projects-goal-feature-guide/", "published_at": "2026-10-18 00:00:00+00:00", "updated_at": "2026-10-19 16:48:04.259580+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "large-language-models", "developer-tools"], "entities": ["Claude Code", "Anthropic", "Opus", "Projects", "/goal"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/claude-s-new-projects-and-goal-features-a-practical-guide", "markdown": "https://wpnews.pro/news/claude-s-new-projects-and-goal-features-a-practical-guide.md", "text": "https://wpnews.pro/news/claude-s-new-projects-and-goal-features-a-practical-guide.txt", "jsonld": "https://wpnews.pro/news/claude-s-new-projects-and-goal-features-a-practical-guide.jsonld"}}