Tag: Claude Context Window

  • The Context Stack: How I Give Claude Memory Across 27 Sites and 6 Businesses

    The Context Stack: How I Give Claude Memory Across 27 Sites and 6 Businesses

    Last refreshed: May 15, 2026

    The most common question I get from people who read the Split-Brain Architecture piece is some version of: how does Claude actually know what it’s working on? If you are managing 27 sites, 6 businesses, and hundreds of ongoing tasks, how do you avoid spending the first ten minutes of every session re-explaining your entire operation to an AI that has no memory of yesterday?

    The answer is what I call the Context Stack. It is not a single file or a single tool — it is a layered system where each layer handles a different time horizon of memory, and Claude reads exactly what it needs for the task at hand without being overwhelmed by everything else.

    The Problem With AI Memory

    Claude does not have persistent memory across sessions by default. Every conversation starts blank. For someone running a simple use case — drafting an email, summarizing a document — this is fine. For someone running a content network across 27 WordPress sites with different brand voices, different SEO strategies, different clients, and different publishing schedules, a blank slate every session is an operational catastrophe.

    The naive solution is to paste a giant context document at the start of every conversation. I tried this. It doesn’t work. Not because Claude can’t read it — it can — but because a 5,000-word context dump at the start of every session is cognitively expensive for the human, slows down the first response, and buries the relevant information under a pile of irrelevant information.

    The right solution is a stack: different layers of context loaded at different times, for different purposes.

    Layer One — The Global Layer (Always Loaded)

    The global layer is the context that is true across everything I do, all the time. It lives in a CLAUDE.md file at the workspace root and in a persistent system prompt inside Claude’s project settings.

    What goes here: my name, my email, the fact that I manage a network of WordPress sites, the Notion workspace structure, the proxy URL and authentication pattern for WordPress API calls, and a handful of behavioral rules that apply universally — brevity preferences, how I want work logged, what “done” means to me.

    What does not go here: anything site-specific, client-specific, or task-specific. The global layer is 200 lines maximum. Anthropic’s own guidance on CLAUDE.md length is right — longer files reduce adherence. I treat the 200-line limit as a hard constraint, not a guideline.

    Layer Two — The Site Layer (Loaded Per Project)

    Each WordPress site I manage has its own Claude Project, and each project has its own knowledge files. These files contain everything Claude needs to work on that specific site without me having to explain it: the brand voice, the target audience, the top-performing content, the internal linking structure, the credentials, the publishing cadence, and the current content roadmap.

    I generate these files programmatically when I onboard a new site. They pull from the WordPress REST API, the site’s GA4 data, and the Notion database for that client. A site knowledge file for an established site runs about 800–1,200 words. Claude reads it at the start of any session for that project and immediately knows the difference between how to write for a Houston restoration contractor versus a New York luxury lender.

    The site layer is why I can switch from working on a restoration contractor to a luxury lender to a live comedy platform in the same afternoon without losing context. The context travels with the project, not with me.

    Layer Three — The Task Layer (Loaded On Demand)

    The task layer is ephemeral. It is the specific context for the thing I am doing right now: the article brief, the GA data from this session, the list of posts that need refreshing, the client’s feedback on last week’s content.

    This layer lives nowhere permanent. I paste it into the conversation, Claude uses it, and when the session ends it is gone. The task layer is intentionally disposable. If it matters beyond this session, it gets promoted to the site layer or the global layer. If it doesn’t matter beyond this session, it doesn’t need to be stored.

    Most AI users try to make everything permanent. The discipline of the context stack is knowing what deserves permanence and what doesn’t.

    Layer Four — The Second Brain (Asynchronous)

    The second brain layer is Notion. It is not loaded into Claude’s context window directly — it is queried via the Notion MCP when Claude needs specific information.

    What lives here: every session log, every publish log, every piece of competitive intelligence, every client preference that has emerged over time, the Promotion Ledger for autonomous behaviors, the Second Brain database of extracted knowledge from prior sessions.

    The key distinction: Notion is not context I push into Claude. It is context Claude pulls from Notion when it needs it. The MCP connection means Claude can search the Second Brain mid-session, find a relevant prior session log, and use it — without me having to remember that the prior session happened.

    This is the layer that makes the system feel like it has long-term memory even though it doesn’t. Claude doesn’t remember. But it can look things up, and the things worth looking up are stored.

    What This Looks Like In Practice

    A typical session for me starts with a project context already loaded (site layer). Within thirty seconds Claude knows which site it’s working on, what voice to use, and what the current priorities are. I drop in the task layer — a GA report, a list of post IDs, a brief — and we are working within two minutes of starting.

    When something important happens — a new client preference, a site credential change, a strategy decision — I say “log this to Notion” and Claude writes it to the Second Brain. I don’t maintain the second brain manually. Claude maintains it as a byproduct of doing the work.

    When I need to recall something from months ago — what we decided about the internal linking structure for a specific site, what the client said about their brand voice in March — Claude searches Notion and finds it. The retrieval is imperfect but it is dramatically better than my own memory.

    The Honest Constraints

    This system took months to build and it is still not finished. The site knowledge files need updating when strategies change and I don’t always remember to update them. The Second Brain has gaps where sessions weren’t logged properly. The global CLAUDE.md drifts toward bloat and needs periodic pruning.

    The bigger constraint is that this architecture assumes you are operating at a certain scale — multiple sites, multiple clients, recurring workflows. If you are running one site for one business, the overhead of building and maintaining this stack is probably not worth it. A well-written CLAUDE.md and a single Notion page of context will get you most of the way there.

    But if you are scaling past three or four sites, or if you find yourself re-explaining the same context in every session, the stack pays for itself quickly. The ten minutes you spend building a site knowledge file saves you two minutes per session indefinitely.

    The goal is not to give Claude everything. The goal is to give Claude exactly what it needs, when it needs it, at the right layer of permanence.

    Building Your Own Context Stack?

    Email me what you are managing and I will tell you which layers you actually need.

    Most people over-engineer the global layer and under-invest in the site layer. Five minutes of conversation usually fixes it.

    Email Will → will@tygartmedia.com

  • Claude Context Window Size 2026: What 1 Million Tokens Actually Means

    Claude Context Window Size 2026: What 1 Million Tokens Actually Means

    Last refreshed: May 15, 2026

    Looking for quick answers? The FAQ version covers every common question directly.

    → Context Window FAQ

    Claude’s context window is one of those specs that sounds simple until you actually need to use it. “1 million tokens” means almost nothing without a frame of reference. This is the guide we wish existed when we started building on Claude — written from our own experience running it in production, with numbers pulled directly from Anthropic’s official documentation.

    Quick Definition

    The context window is Claude’s working memory for a conversation. It holds everything Claude can see and reason about at once: your messages, Claude’s responses, any documents you’ve shared, and system prompts. When the window fills up, earlier content drops out.

    Current Context Window Sizes by Model (May 2026)

    These numbers come directly from Anthropic’s official models page, fetched May 9, 2026. Model strings are exact API identifiers:

    Model API String Context Window Max Output
    Claude Opus 4.7 claude-opus-4-7 1,000,000 tokens 128,000 tokens
    Claude Sonnet 4.6 claude-sonnet-4-6 1,000,000 tokens 64,000 tokens
    Claude Haiku 4.5 claude-haiku-4-5-20251001 200,000 tokens 64,000 tokens

    Opus 4.7 and Sonnet 4.6 both have the full 1M token context window. Haiku 4.5 is 200K. The key difference between Opus 4.7 and Sonnet 4.6 in this table is the max output — Opus 4.7 can write up to 128K tokens in a single response, Sonnet 4.6 caps at 64K.

    What Does 1 Million Tokens Actually Hold?

    Token counts are an abstraction. Here’s what 1 million tokens translates to in practical terms:

    • About 750,000 words of English text — roughly 10 full-length novels, or 1,500 average blog posts
    • A full mid-size codebase — a 50,000-line Python project with comments fits comfortably
    • Hours of meeting transcripts — a full workday of recorded calls, transcribed, fits in one context window
    • Multiple large documents simultaneously — 10 research PDFs at 30 pages each, all in the same conversation
    • Long conversation histories — hundreds of back-and-forth exchanges before anything starts dropping off

    We’ve loaded entire Notion exports, full project histories, and multi-document research packs into a single Claude session. At 1M tokens, you’re unlikely to hit the ceiling in a normal working session. You hit it when you’re doing things like: loading your entire codebase plus documentation plus conversation history and then asking Claude to do a full architectural review.

    Context Window vs. Memory: What’s the Difference?

    This is where a lot of people get confused. The context window and memory are not the same thing:

    • Context window: What Claude can see right now, in this session. Once a session ends, it’s gone.
    • Memory (in claude.ai): A separate system that extracts and stores key information from past sessions. It surfaces relevant facts into future conversations as a snippet in the context.
    • Managed Agents memory stores: A developer-layer construct where agents maintain and update knowledge bases across sessions — distinct from both the context window and the consumer memory feature.

    The 1M token context window is your working memory for one session. It doesn’t persist. Memory systems are what carry information across sessions — but they work by injecting a summary into the context window of the new session, not by giving Claude access to the full history.

    Does a Bigger Context Window Mean Better Performance?

    Mostly yes, with one important nuance. More context means Claude has more information to reason about, which generally produces better outputs for tasks that benefit from full context — code reviews, document synthesis, long-form writing, multi-document comparison.

    The nuance: performance can degrade on tasks involving specific information buried deep in a very long context. This is sometimes called the “lost in the middle” problem — models tend to pay more attention to the beginning and end of a long context than the middle. Anthropic has worked on this with Claude’s architecture, and it performs well on long-context tasks, but it’s worth structuring important information at natural reference points rather than burying it in the middle of a 500-page document.

    How We Actually Use the 1M Token Window

    We run Claude in production for content operations, site management, and agentic coding workflows. Here’s where the 1M context window makes a concrete difference in our work:

    • Full site audits: Loading every post from a WordPress site (200+ posts worth of content) into one session for comprehensive SEO analysis — without having to chunk and re-prompt
    • Cross-session context: Pasting in long Notion briefings, prior session transcripts, and the current task in one go. The window is large enough that we don’t have to decide what to leave out.
    • Codebase-wide reasoning: In Claude Code, having the full project context means Claude can make changes that account for how files interact rather than reasoning only about the current file
    • Multi-document synthesis: Research projects where we load 10-15 source documents and ask Claude to synthesize across them — something that was impossible at 100K context windows

    The practical shift from 200K to 1M tokens wasn’t just “more room.” It changed what we could ask Claude to do in a single session.

    Context Window on the API: Batch Output Extension

    For API users: on the Message Batches API, Opus 4.7, Opus 4.6, and Sonnet 4.6 support up to 300K output tokens using the output-300k-2026-03-24 beta header. This is relevant for batch generation tasks where you need very long outputs — documentation generation, large codebases, book-length content.

    Frequently Asked Questions

    What is Claude’s context window in 2026?

    Claude Opus 4.7 and Claude Sonnet 4.6 both have 1,000,000 token (1M token) context windows as of May 2026. Claude Haiku 4.5 has a 200,000 token context window. These are the current generally available models.

    How many pages can Claude read at once?

    At 1M tokens, Claude can hold roughly 750,000 words of English text — equivalent to approximately 3,000 average pages. In practice, a typical 20-page PDF is roughly 10,000-15,000 tokens, so you could load 60-100 such documents in a single session before approaching the limit.

    Does the context window reset between messages?

    No — the context window accumulates across an entire conversation session. Every message you send and every response Claude gives adds to the total. The window doesn’t reset between individual messages; it resets when you start a new conversation.

    What happens when Claude hits the context window limit?

    When a conversation reaches the context window limit, earlier messages begin to drop out of the active context. Claude can no longer reference information from those earlier messages — it effectively forgets that part of the conversation. In the claude.ai interface, you’ll see a notification when you’re approaching the limit.

    Is the 1M context window available on the free plan?

    The model available to free plan users has access to the 1M context window. However, free plan usage limits mean long-context sessions hit rate limits faster than paid plans. The window is technically available, but sustained heavy use of it is more practical on paid tiers.

    What’s the difference between Claude Opus 4.7 and Sonnet 4.6 context windows?

    Both have the same 1M token input context window. The difference is max output: Opus 4.7 can generate up to 128,000 tokens in a single response; Sonnet 4.6 caps at 64,000 tokens. For most tasks this distinction doesn’t matter, but for very long document generation or large code outputs, Opus 4.7 has the higher output ceiling.

  • The claude_delta Standard: How We Built a Context Engineering System for a 27-Site AI Operation

    The claude_delta Standard: How We Built a Context Engineering System for a 27-Site AI Operation

    The Machine Room · Under the Hood

    What Is the claude_delta Standard?

    The claude_delta standard is a lightweight JSON metadata block injected at the top of every page in a Notion workspace. It gives an AI agent — specifically Claude — a machine-readable summary of that page’s current state, status, key data, and the first action to take when resuming work. Instead of fetching and reading a full page to understand what it contains, Claude reads the delta and often knows everything it needs in under 100 tokens.

    Think of it as a git commit message for your knowledge base — a structured, always-current summary that lives at the top of every page and tells any AI agent exactly where things stand.

    Why We Built It: The Context Engineering Problem

    Running an AI-native content operation across 27+ WordPress sites means Claude needs to orient quickly at the start of every session. Without any memory scaffolding, the opening minutes of every session are spent on reconnaissance: fetch the project page, fetch the sub-pages, fetch the task log, cross-reference against other sites. Each Notion fetch adds 2–5 seconds and consumes a meaningful slice of the context window — the working memory that Claude has available for actual work.

    This is the core problem that context engineering exists to solve. Over 70% of errors in modern LLM applications stem not from insufficient model capability but from incomplete, irrelevant, or poorly structured context, according to a 2024 RAG survey cited by Meta Intelligence. The bottleneck in 2026 isn’t the model — it’s the quality of what you feed it.

    We were hitting this ceiling. Important project state was buried in long session logs. Status questions required 4–6 sequential fetches. Automated agents — the toggle scanner, the triage agent, the weekly synthesizer — were spending most of their token budget just finding their footing before doing any real work.

    The claude_delta standard was the solution we built to fix this from the ground up.

    How It Works

    Every Notion page in the workspace gets a JSON block injected at the very top — before any human content. The format looks like this:

    {
      "claude_delta": {
        "page_id": "uuid",
        "page_type": "task | knowledge | sop | briefing",
        "status": "not_started | in_progress | blocked | complete | evergreen",
        "summary": "One sentence describing current state",
        "entities": ["site or project names"],
        "resume_instruction": "First thing Claude should do",
        "key_data": {},
        "last_updated": "ISO timestamp"
      }
    }

    The standard pairs with a master registry — the Claude Context Index — a single Notion page that aggregates delta summaries from every page in the workspace. When Claude starts a session, fetching the Context Index (one API call) gives it orientation across the entire operation. Individual page fetches only happen when Claude needs to act on something, not just understand it.

    What We Did: The Rollout

    We executed the full rollout across the Notion workspace in a single extended session on April 8, 2026. The scope:

    • 70+ pages processed in one session, starting from a base of 79 and reaching 167 out of approximately 300 total workspace pages
    • All 22 website Focus Rooms received deltas with site-specific status and resume instructions
    • All 7 entity Focus Rooms received deltas linking to relevant strategy and blocker context
    • Session logs, build logs, desk logs, and content batch pages all injected with structured state
    • The Context Index updated three times during the session to reflect the running total

    The injection process for each page follows a read-then-write pattern: fetch the page content, synthesize a delta from what’s actually there (not from memory), inject at the top via Notion’s update_content API, and move on. Pages with active state get full deltas. Completed or evergreen pages get lightweight markers. Archived operational logs (stale work detector runs, etc.) get skipped entirely.

    The Validation Test

    After the rollout, we ran a structured A/B test to measure the real impact. Five questions that mimic real session-opening patterns — the kinds of things you’d actually say at the start of a workday.

    The results were clear:

    • 4 out of 5 questions answered correctly from deltas alone, with zero additional Notion fetches required
    • Each correct answer saved 2–4 fetches, or roughly 10–25 seconds of tool call time
    • One failure: a client checklist showed 0/6 complete in the delta when the live page showed 6/6 — a staleness issue, not a structural one
    • Exact numerical data (word counts, post IDs, link counts) matched the live pages to the digit on all verified tests

    The failure mode is worth understanding: a delta becomes stale when a page gets updated after its delta was written. The fix is simple — check last_updated before trusting a delta on any in_progress page older than 3 days. If it’s stale, a single verification fetch is cheaper than the 4–6 fetches that would have been needed without the delta at all.

    Why This Matters Beyond Our Operation

    2025 was the year of “retention without understanding.” Vendors rushed to add retention features — from persistent chat threads and long context windows to AI memory spaces and company knowledge base integrations. AI systems could recall facts, but still lacked understanding. They knew what happened, but not why it mattered, for whom, or how those facts relate to each other in context.

    The claude_delta standard is a lightweight answer to this problem at the individual operator level. It’s not a vector database. It’s not a RAG pipeline. Long-term memory lives outside the model, usually in vector databases for quick retrieval. Because it’s external, this memory can grow, update, and persist beyond the model’s context window. But vector databases are infrastructure — they require embedding pipelines, similarity search, and significant engineering overhead.

    What we built is something a single operator can deploy in an afternoon: a structured metadata convention that lives inside the tool you’re already using (Notion), updated by the AI itself, readable by any agent with Notion API access. No new infrastructure. No embeddings. No vector index to maintain.

    Context Engineering is a systematic methodology that focuses not just on the prompt itself, but on ensuring the model has all the context needed to complete a task at the moment of LLM inference — including the right knowledge, relevant history, appropriate tool descriptions, and structured instructions. If Prompt Engineering is “writing a good letter,” then Context Engineering is “building the entire postal system.”

    The claude_delta standard is a small piece of that postal system — the address label that tells the carrier exactly what’s in the package before they open it.

    The Staleness Problem and How We’re Solving It

    The one structural weakness in any delta-based system is staleness. A delta that was accurate yesterday may be wrong today if the underlying page was updated. We identified three mitigation strategies:

    1. Age check rule: For any in_progress page with a last_updated more than 3 days old, always verify with a live fetch before acting on the delta
    2. Agent-maintained freshness: The automated agents that update pages (toggle scanner, triage agent, content guardian) should also update the delta on the same API call
    3. Context Index timestamp: The master registry shows its own last-updated time, so you know how fresh the index itself is

    None of these require external tooling. They’re behavioral rules baked into how Claude operates on this workspace.

    What’s Next

    The rollout is at 167 of approximately 300 pages. The remaining ~130 pages include older session logs from March, a new client project sub-pages, the Technical Reference domain sub-pages, and a tail of Second Brain auto-entries. These will be processed in subsequent sessions using the same read-then-inject pattern.

    The longer-term evolution of this system points toward what the field is calling Agentic RAG — an architecture that upgrades the traditional “retrieve-generate” single-pass pipeline into an intelligent agent architecture with planning, reflection, and self-correction capabilities. The BigQuery operations_ledger on GCP is already designed for this: 925 knowledge chunks with embeddings via text-embedding-005, ready for semantic retrieval when the delta system alone isn’t enough to answer a complex cross-workspace query.

    For now, the delta standard is the right tool for the job — low overhead, human-readable, self-maintaining, and already demonstrably cutting session startup time by 60–80% on the questions we tested.

    Frequently Asked Questions

    What is the claude_delta standard?

    The claude_delta standard is a structured JSON metadata block injected at the top of Notion pages that gives AI agents a machine-readable summary of each page’s current status, key data, and next action — without requiring a full page fetch to understand context.

    How does claude_delta differ from RAG?

    RAG (Retrieval-Augmented Generation) uses vector embeddings and semantic search to retrieve relevant chunks from a knowledge base. Claude_delta is a simpler, deterministic approach: a structured summary at a known location in a known format. RAG scales to massive knowledge bases; claude_delta is designed for a single operator’s structured workspace where pages have clear ownership and status.

    How do you prevent delta summaries from going stale?

    The key_data field includes a last_updated timestamp. Any delta on an in_progress page older than 3 days triggers a verification fetch before Claude acts on it. Automated agents that modify pages are also expected to update the delta in the same API call.

    Can this approach work for other AI systems besides Claude?

    Yes. The JSON format is model-agnostic. Any agent with Notion API access can read and write claude_delta blocks. The standard was designed with Claude’s context window and tool-call economics in mind, but the pattern applies to any agent that needs to orient quickly across a large structured workspace.

    What is the Claude Context Index?

    The Claude Context Index is a master registry page in Notion that aggregates delta summaries from every processed page in the workspace. It’s the first page Claude fetches at the start of any session — a single API call that provides workspace-wide orientation across all active projects, tasks, and site operations.