Stop Wasting Tokens. Here's the Context Strategy That Actually Scales

You're loading everything into project files.

Every conversation. Every request. Claude is processing 50,000 tokens of context you uploaded once and never changed. Your company knowledge base. Your style guide. That PDF from three weeks ago you forgot about.

You're paying for it. Every single time.

And worse? Your AI is slower. Less accurate. Drowning in irrelevant context it has to wade through to find what actually matters.

There's a better way.

Five different approaches to passing context to Claude. Each with different token costs. Different use cases. Different breaking points.

Most people pick one and dump everything into it. Or mix all five randomly and wonder why nothing works right.

Here's when to use what—and how to stop bleeding tokens on context that doesn't matter.

The Token Problem Nobody's Talking About

Context isn't free.

Every piece of information you give Claude counts toward your token limit. Hit that limit and one of three things happens:

1. Your conversation breaks. Claude can't fit everything and starts dropping context.

2. You pay more. Higher plans. More usage. Compounding costs.

3. Performance tanks. Too much irrelevant context = slower, worse responses.

The real problem? Most people don't know they have options.

They think it's "upload everything to project files" or "explain it all in every message."

Both waste massive amounts of tokens.

Here's what you should actually do.

The 5 Context Approaches (And What They Cost You)

1. Project Files (.md files in Claude Projects)

How it works: Upload .md files to a project. Claude loads ALL of them into EVERY conversation in that project.

Token cost: High and constant. Every file, every conversation, whether needed or not.

What it's good for:

• Static reference docs (style guides, company info)

• Information that applies to 80%+ of conversations

• Small file counts (under 10 files)

What breaks:

• Token bloat at scale. 10 files? Fine. 50 files? You're burning thousands of tokens per message on docs you'll never reference.

• No dynamic loading. Can't selectively load what you need. It's all or nothing.

• Changes require manual updates. Every edit means updating the file.

When to use it: Reference documentation that's relevant to most conversations and doesn't change often.

When NOT to use it: Dynamic data. Large knowledge bases. Anything you only need occasionally.

Token efficiency: ⭐⭐ (2/5)

2. Claude's Native Memory

How it works: Claude automatically synthesizes memories from your conversations. Remembers your preferences, context, and patterns.

Token cost: Low. Memory is compressed and only relevant facts are loaded.

What it's good for:

• Personal preferences and communication style

• Context about who you are and how you work

• Facts that apply across all projects

• Information that doesn't change frequently

What breaks:

• Synthesizes once every 24 hours. Not real-time. Changes take a day to appear.

• You can't control what it learns automatically. (You can manually edit, but synthesis is automatic.)

• Not for structured data. It's great at "Shubham prefers concise responses" but terrible at "here are our 47 product SKUs."

• No programmatic updates. Can't push updates via API multiple times per day.

When to use it: Personal context that should apply everywhere. Preferences. Your role. Communication style.

When NOT to use it: Time-sensitive data. Structured knowledge. Procedural workflows. Things that change multiple times daily.

Token efficiency: ⭐⭐⭐⭐ (4/5)

3. Skills

How it works: Modular packages of knowledge and procedures. Claude only loads a skill when it's relevant to the task. Progressive disclosure.

Token cost: Very low. Each skill is summarized in ~20 tokens until needed. Full details load only when relevant.

What it's good for:

• Repeatable workflows ("here's how we write blog posts")

• Procedural knowledge ("here's how to process invoices")

• Organization-specific processes

• Knowledge that needs consistency across use cases

What breaks:

• Not for conversation history. Skills are for "how to do X," not "what happened last week."

• Setup overhead. You need to package knowledge into the SKILL.md format.

• Works best for procedures, not facts. Great for "follow these 5 steps," less useful for "here are 100 data points."

When to use it: Repeatable processes. "How we do things here." Multi-step workflows that need consistency.

When NOT to use it: Conversation memory. Dynamic retrieval. One-off tasks. Simple facts.

Token efficiency: ⭐⭐⭐⭐⭐ (5/5)

4. MCP (Model Context Protocol)

How it works: Connect Claude to external data sources in real-time. Claude queries your database, API, or service when it needs information.

Token cost: Dynamic. Only loads what's queried. But queries themselves cost tokens.

What it's good for:

• Real-time data (current inventory, live metrics)

• Connecting to existing systems (your CRM, database, internal tools)

• Large datasets you can't fit in context

• Information that changes constantly

What breaks:

• Requires server setup. You're running infrastructure.

• Query overhead. Each database call uses tokens for the query + response.

• More complex than built-in options. Only worth it when built-ins won't work.

• Rate limits. External systems have their own constraints.

When to use it: Real-time data access. Connecting to existing infrastructure. Large, frequently-changing datasets.

When NOT to use it: Static knowledge. When project files or Skills would work fine. Simple use cases.

Token efficiency: ⭐⭐⭐⭐ (4/5) when used correctly

5. RAG + Database (Custom Build)

How it works: Build your own system. Store everything in a database. Use embeddings for semantic search. Retrieve only what's relevant.

Token cost: You control it completely. Can be extremely efficient or extremely wasteful depending on your retrieval logic.

What it's good for:

• Cross-LLM memory (works with Claude, ChatGPT, Gemini, anything)

• Full control over what's stored and retrieved

• Building feedback loops (learn from corrections over time)

• Custom retrieval logic

• Your data on your infrastructure

What breaks:

• You build and maintain everything. Database. Embeddings. Retrieval logic. UI.

• Complexity compounds fast. More moving parts = more things that break.

• Slower to ship. Takes weeks to build what Claude's built-ins give you in minutes.

• Cost overhead. Infrastructure, embedding API calls, storage.

When to use it: Building a product. Need cross-LLM support. Require feedback loops. Full control is essential.

When NOT to use it: Quick projects. Personal use. When Claude's built-in options work. Time constraints.

Token efficiency: ⭐⭐⭐⭐⭐ (5/5) if built well

The Strategy That Actually Scales

Here's the truth: you need 2-3 of these, not all 5. Not just one.

Stop asking "which is best?" Start asking "what problem am I solving?"

The Decision Framework

For personal preferences and style: → Claude's native memory

For "here's how we do X" workflows: → Skills

For static reference docs in a specific project: → Project files (but keep it under 10 files)

For real-time data from external systems: → MCP

For cross-LLM memory with custom logic: → RAG + Database

For orchestrating multiple systems: → N8N (not covered here, but combines with any of the above)

What Most People Actually Need

Solo user, personal productivity:

• Claude's memory (preferences, style)

• 2-3 Skills (for your common workflows)

• Maybe 1-2 project files (if you have static reference docs)

Token cost: Minimal. You're loading only what's relevant.

Small team, specific project:

• Claude's memory (personal preferences)

• Skills (team workflows)

• Project files (project-specific context, under 10 files)

Token cost: Low. Context is scoped to what matters.

Enterprise, complex workflows:

• Claude's memory (individual preferences)

• Skills (company procedures)

• MCP (connect to internal systems)

• Maybe RAG if you need cross-LLM or feedback loops

Token cost: Higher, but optimized. You're not loading everything everywhere.

How I Actually Use This

I built Memoria—a personal AI memory system—and tested all five approaches.

V1 (earlier this year): MongoDB + RAG + Framer UI. Full custom build. Worked, but slow to iterate and complex to maintain.

V2 (now): Hybrid approach. Each tool for its job.

Claude's native memory: Personal facts. Who I am. How I communicate.

Skills: How I write blogs. How I process information. Procedural knowledge.

Project files: Reference docs for specific projects. Neoflo context in one project. Memoria context in another.

Custom RAG + MongoDB: Cross-conversation memory. "What did I discuss last week" queries. Facts that need dynamic retrieval.

N8N: Orchestration between systems.

The result? Token usage dropped by ~60%. Response quality improved. Each conversation loads only what it needs.

The Feedback Loop Problem

Here's something most people miss: memory needs to improve over time.

Built-in options (Memory, Skills, Project Files):

• Manual updates only

• You edit, system updates

• No automatic learning from corrections

Custom RAG + Database:

• You can build feedback loops

• Track what gets retrieved and used

• Learn from corrections

• Update based on patterns

This is why I kept custom RAG for Memoria. Not because it's easier—it's not. Because I need the system to get smarter based on how I actually use it.

Claude's memory learns naturally. But my custom layer learns strategically from explicit feedback.

Stop Wasting Tokens. Do This Instead.

If you're reading this and burning tokens on bloated context:

• [ ] Audit what you're loading. Look at your project files. How many are actually referenced in each conversation? Delete what's not used 80%+ of the time.

• [ ] Move static knowledge to Skills. If it's "how we do X," package it as a skill. It'll load only when needed instead of always.

• [ ] Use Memory for personal context. Stop repeating "I prefer concise responses" in every prompt. Let Memory handle it.

• [ ] Test progressive loading. If you're loading 50,000 tokens of context for a 500-token question, something's wrong. Skills and MCP both support "load only what's needed."

• [ ] Measure your token usage. Most people have no idea what they're actually spending. Track it for a week. You'll be shocked.

Start with built-in options. Add complexity only when simple approaches break.

Key Takeaways

• Every piece of context costs tokens. Loading everything everywhere is expensive and slow.

• You need 2-3 approaches, not all 5. Match the tool to the problem. Don't dump everything in project files.

• Progressive disclosure is your friend. Skills and MCP load only what's relevant. Use them.

• Built-in > Custom for most use cases. Claude's memory, Skills, and project files cover 80% of needs. Only go custom when you need cross-LLM support or feedback loops.

• Token efficiency = better AI. Less irrelevant context = faster responses, better accuracy, lower costs.

The difference between wasting tokens and using them strategically? About 60% of your context budget. And significantly better results.

Stop loading everything. Start loading what matters.

Keep Reading

If this clicked, these connect directly:

• The Prompt Is Dead. Here's What Replaced It - Deep dive into Skills and progressive disclosure

• Building AI for Finance Teams - Why It's Harder Than It Looks - How we use Skills + Memory at Neoflo for finance workflows

More on AI & Product

I write about what I'm building and learning at heyshubh.com.

Connect with me on LinkedIn - always up for talking about AI architecture challenges.

Next week: I tested Claude's Chrome integration, Comet, and Dia side-by-side for a week. One emerged as the clear winner. The results surprised me.