The Setup: What Practitioners Expected

When Anthropic rolled out Claude Projects in mid-2024, the pitch was straightforward. Persistent context. Custom instructions per workspace. Document uploads that stick across conversations. For developers already juggling long system prompts and pasted codebases, the idea of a “project” that remembers what you told it last week was the obvious next step.

On r/LocalLLaMA and the r/ClaudeAI subreddit, the early threads were cautiously optimistic. One HN commenter noted that the feature “felt like Anthropic finally admitting that chat history alone wasn’t a real workflow.” Practitioners running Claude for code review, documentation drafting, and client work had been re-uploading the same context files for months. Projects promised to end that.

The expectation going in was less re-prompting, fewer copy-paste rituals, and a tighter loop between Claude and the actual work. Several YouTube reviewers covering AI tooling framed it as “Custom GPTs but with Claude’s reasoning.” That comparison stuck, and it shaped how a lot of teams evaluated the feature. The bar wasn’t perfection. The bar was “stop making me paste the same 2,000 tokens of context every morning.”

Where Claude Projects Actually Delivers

The wins are real, and they cluster around three patterns that came up repeatedly in community discussions.

First, custom instructions per project. Practitioners on r/ClaudeAI consistently reported that setting a project-level system prompt with tone, role, and output format reduced their per-message prompt engineering by roughly 60 to 70 percent. A senior engineer running a documentation team said in a thread that they cut their “preamble” from about 400 tokens to zero once they moved their voice and style guide into the project settings. The latency impact was negligible in their testing, sitting around 200 to 400ms added to first-token time, which most teams found acceptable.

Second, document attachments for stable reference material. Teams using Projects for product specs, API docs, or onboarding guides found the upload-and-reference flow genuinely useful. One practitioner blog post tracked a team using Projects for a 180-page internal API reference. They reported Claude pulling correct citations in roughly 85 percent of queries against that corpus, with the rest requiring a rephrase or a more specific prompt. For static documentation that doesn’t change weekly, the hit rate was good enough to skip building a separate RAG pipeline entirely.

Third, the shared project model for small teams. Anthropic extended Projects to support team members viewing and editing the same workspace. Several smaller teams (3 to 8 people) on HN said this was the feature that finally made Claude viable as a team tool rather than a personal one. The cost was the same as individual seats, and the workflow gain was substantial. One team lead mentioned cutting their weekly “let me paste the context again” Slack messages from around 30 to under 5 within the first month.

Latency in practice stayed in the 800ms to 1.4s range for first-token responses with project context loaded, based on practitioner benchmarks shared in r/LocalLLaMA threads. Token costs for Sonnet-based projects ran roughly $3 per million input tokens and $15 per million output tokens at the time of those reports, with Opus-backed projects climbing to $15 and $75 respectively. Teams that stayed on Sonnet for routine work and only escalated to Opus for review cycles reported the most predictable bills.

Where It Falls Short in Real Use

The friction points showed up fast, and they were consistent across communities.

The retrieval layer has gaps. Practitioners running Projects against technical documentation kept hitting a wall. When the answer required synthesizing across more than three or four uploaded files, Claude would either miss chunks or pull from the wrong section. A developer on r/ClaudeAI described it as “RAG that works 80 percent of the time and confidently makes things up the other 20.” Several teams reported building hybrid workflows where Projects handled the easy lookups and they fell back to a dedicated vector store for anything complex. The retrieval quality simply doesn’t match what you can build with a tuned embedding pipeline.

Context window drift. Projects don’t visibly tell you how much of your context window you’ve burned. Practitioners running long sessions (50+ messages in a single project) noticed Claude losing track of earlier instructions, even when those instructions lived in the project settings. One HN commenter called it “the silent degradation problem.” The workaround most teams adopted was starting a fresh conversation every 15 to 20 turns, which defeated some of the persistence benefit. The feature promised continuity, but the practical advice from the field was to manually break continuity anyway.

Cost surprises on long-running projects. The pricing model charges per token, and a project that accumulates hundreds of uploaded documents plus long conversation history can balloon input costs without warning. A team lead on a practitioner Slack shared that their monthly Claude bill jumped from roughly $400 to $1,100 after they added a second large document corpus to an active project. They hadn’t realized the system was re-injecting the full document context on every message. Anthropic later clarified the caching behavior, but several practitioners in the threads said the documentation on this was thin at launch and the cost dashboard didn’t surface the issue until after the bill arrived.

Onboarding friction for non-technical teammates. The Projects UI assumes you understand what a system prompt is and what context means. Practitioners rolling it out to product managers or designers reported a 2 to 3 week adoption curve, with several people reverting to plain chat because the project model felt like overhead. One product lead on LinkedIn wrote that “the people who got the most out of Projects were the people who already knew how to prompt. The rest found it confusing.” The mental model of “project as workspace” doesn’t translate cleanly for users who think in terms of documents and folders.

No real version control. If a teammate edits the custom instructions or replaces a document, there’s no audit trail and no rollback. Several engineering teams flagged this as a dealbreaker for any workflow touching production documentation. The workaround was treating Projects as ephemeral and snapshotting instructions manually in a shared doc, which is the kind of duct tape that breaks at the worst moment.

Who It Fits (And Who It Doesn’t)

The pattern from the community signal is fairly clear.

It fits solo developers and small teams (1 to 8 people) running Claude for repeated work against stable reference material. Documentation drafting, code review against a known codebase, client-specific writing, research synthesis against a fixed corpus. These are the workflows where the persistence actually pays off and the cost math works.

It fits less well for fast-moving codebases where the reference docs change weekly. Practitioners working on active product engineering reported that Projects went stale fast, and the manual refresh overhead ate the time savings. If your API surface or product spec is in flux, you’ll spend more time re-uploading than you save.

It fits poorly for teams that need shared governance. If you need to know who changed what, when, and why, Projects doesn’t give you that. Teams in regulated industries (healthcare, finance, legal) consistently flagged this in practitioner threads and tended to skip Projects in favor of self-hosted RAG with proper audit logs.

It also doesn’t fit workflows that require sub-500ms latency. The added context loading pushes first-token time above what real-time IDE integrations need. Practitioners building coding assistants or live chat tools reported sticking with raw API calls rather than the Projects UI for that reason.

Common Pairings and Replacements

The most common pairing mentioned in r/ClaudeAI and HN threads was Projects alongside Cursor or VS Code with the Claude API. Developers used Projects for planning, documentation, and review conversations, then dropped into their IDE for the actual code work. The two workflows complemented each other rather than overlapping, and several teams described it as the only setup where Projects “felt like a real tool rather than a chat client.”

For teams that needed more control, the typical replacement was a custom RAG setup using something like LangChain or LlamaIndex with a vector database. Pinecone, Weaviate, and Qdrant showed up most often in the threads. The build cost was higher, roughly 2 to 4 weeks of engineering time for a working pipeline, but the retrieval quality and audit trail justified it for production use cases. Teams that went this route generally reported 90 to 95 percent retrieval accuracy on technical corpora, compared to the 80 to 85 percent they saw with Projects.

Custom GPTs on OpenAI’s side were the most frequently cited competitor. Practitioners who had access to both generally reported that Claude Projects had better reasoning quality and longer context, while Custom GPTs had a more polished sharing model and better action integrations. Several teams ran both, picking the tool per task. The split was usually Projects for anything requiring careful reasoning and Custom GPTs for anything requiring tool use or external API calls.

A smaller group of practitioners replaced Projects with a plain Claude API plus a lightweight memory layer they built themselves. The motivation was cost control and the ability to swap models without re-uploading context. This worked well for teams with engineering capacity and less well for non-technical users. The recurring comment in those threads was that the DIY route only paid off once you had a real corpus (50+ documents) and a real team (5+ users) hitting it daily.

The Bottom Line

Claude Projects solved a real problem that practitioners had been complaining about for months: the constant re-pasting of context. For solo work and small teams with stable reference material, the feature genuinely delivers. The custom instructions, document uploads, and shared workspace model are useful, and the latency and cost profile on Sonnet is reasonable for the value provided.

The gaps are real too. The retrieval layer isn’t production-grade for complex queries. Context window drift shows up in long sessions. Cost surprises hit teams that didn’t model the input token math. Onboarding isn’t smooth for non-technical teammates. There’s no version control.

If you’re a solo developer or a small team running Claude for documentation, review, or research work against a stable corpus, Projects is worth the time to set up. If you’re running a fast-moving codebase, need audit trails, or require sub-500ms latency, you’ll outgrow it quickly.

The honest read from the community: Projects is a useful productivity layer, not a foundational infrastructure piece. Treat it accordingly.

If you’re working through which tools belong in your stack, book a 60-min Omni Audit — https://calendly.com/sam-mckay/discovery-call