Claude’s 1M Context Window and WordPress: What Actually Changes for Developers

Anthropic made 1 million token context generally available for Claude Opus and Sonnet. I have been using it for WordPress plugin development for the past few weeks. The marketing copy talks about reading entire codebases, that is accurate, but the specific value for someone building WordPress products is more concrete than that framing suggests.

This post is what I actually learned from running 1M context on real work: which tasks it changes, where it genuinely matters, and where it does not help.

What 1M Tokens Means in WordPress Terms

One million tokens is roughly 750,000 words. For WordPress code specifically:

• A small plugin (5,000 lines): ~12,500 tokens
• A medium plugin (20,000 lines): ~50,000 tokens
• A large plugin (80,000 lines): ~200,000 tokens
• WordPress core: ~1,000,000 tokens, just fits
• WooCommerce: ~800,000 tokens

The previous context limit was 200,000 tokens on higher models. For a single plugin, that is fine. But real WordPress work is never just one plugin. It is the plugin plus the BuddyPress integration layer, plus the WooCommerce compatibility code, plus the theme template overrides, plus test fixtures, plus the conversation itself. The old limit forced constant tradeoffs about what to include. With 1M tokens, many of those tradeoffs disappear.

Cross-Plugin Conflict Analysis

I maintain over 100 WordPress plugins. The most common support tickets I get are not bugs within individual plugins, they are conflicts between plugins that each work correctly in isolation but interact unpredictably when both are active.

Before 1M context: I could analyze one plugin at a time. When debugging a conflict, I described how one plugin worked while Claude analyzed the other. Claude was reasoning from my description, not from actual code.

After 1M context: I load both plugins and ask Claude to map every shared hook, shared data store, and shared execution path.

Loaded: buddypress-hashtags (~18,000 lines)
Loaded: buddypress-polls (~24,000 lines)

Find every WordPress hook registered in both plugins.
Flag any case where both plugins hook to the same action at the same priority,
especially where they write to overlapping data stores.

Claude found three conflicts. One was a timing issue, both plugins wrote to the same activity meta key at hook priority 10. Neither plugin was wrong individually. Together, the result depended on plugin activation order, which no developer documents as a requirement.

That analysis took four minutes. A manual audit of both codebases would have been a half-day of work, with real risk of missing the activation-order dependency entirely.

Full Refactor Planning Across the Entire Codebase

I recently migrated a plugin from custom admin-ajax.php handlers to proper REST API endpoints. The plugin had been using the AJAX pattern since 2015, with 14 separate handlers across 27 PHP files and 8 JavaScript files.

With the old context limit, I would have analyzed handlers in batches, held the picture in my head across multiple sessions, and manually tracked which JavaScript files needed updating. With 1M context:

Loaded: entire plugin (27 PHP + 8 JS files)

Before writing any code, give me:
1. Every AJAX action registered, in PHP and JS
2. Required capability for each
3. Input/output shape for each
4. Which JS files reference each action
5. Any handler missing a capability check

The response covered all 14 handlers, and flagged one missing a capability check entirely. A security issue I had not noticed in years of maintaining this plugin. That one finding justified the entire context cost of the analysis session.

Git History as Context

This is the use case that surprised me most. You can load the complete git log for a file alongside the current code and ask why something is the way it is.

git log --all --follow -p includes/class-hashtag-parser.php > parser-history.txt
# 3 years of active development: ~50,000 tokens

Loaded: parser-history.txt + current class-hashtag-parser.php

The regex in parse_hashtags() is more complex than it looks like it needs to be.
Based on the full commit history:
- Why was it written this way?
- Which commits added complexity and what problem were they fixing?
- What can be safely simplified without reintroducing old bugs?

Claude traced the evolution across 18 commits. The complexity had three distinct layers, each added for a real reason. One layer was still necessary. One was still necessary but could be simplified. One had been made redundant by a BuddyPress core fix two years ago and was pure dead code. I simplified the regex with confidence because I knew exactly what each part was protecting against.

Documentation decays. Comments get deleted or drift from the code. Git history does not lie, and now Claude can read all of it at once.

Support Triage With Full Codebase Context

For my most complex plugins, I now maintain a support context that includes: full plugin code, full documentation, and the last 30 closed support tickets. When a complex ticket comes in, Claude reasons against all three simultaneously.

The quality difference is significant. Instead of “we are investigating,” the response can be: “this is caused by the regex in class-hashtag-parser.php line 45, which does not handle UTF-8 encoded sequences in BuddyPress group descriptions. The same issue appeared in ticket #234 six months ago. Temporary workaround is X. Permanent fix is adding the u flag to the regex on line 45.” That is a different level of response for your support team to work from.

Loading WooCommerce Core Alongside Your Extension

WooCommerce extension development has a chronic problem: you never know which internal methods are stable versus likely to change in the next major version. Knowing which hooks are public API and which are implementation details requires deep familiarity that most developers build slowly through trial and error.

With 1M context, I can load the relevant WooCommerce core files alongside my extension code. For a custom checkout field integration: includes/class-wc-checkout.php, templates/checkout/form-checkout.php, and my extension. I ask Claude to implement the feature using only WooCommerce’s public hook API and to specifically flag any approach that relies on internal implementation details.

That guidance, do not use that protected method, use this public hook instead, is the difference between extensions that survive major WooCommerce updates and ones that break every six months.

Where 1M Context Does Not Help

Speed. Processing 1M tokens takes time. For a single function fix or a question about one file, tight scoping is faster. My threshold: if the task requires understanding more than four files and their interactions, load the full codebase. For anything smaller, scope tightly.

Cost. More tokens costs more money. I run two Max plans plus API tokens for site integrations. Even with that capacity, I am deliberate about when 1M context is warranted versus when a scoped 50K token session is sufficient. For cross-plugin conflicts, refactor planning, and git history analysis, the full context earns its cost. For single-function fixes, it does not.

WordPress core. WP core is ~1M tokens, it just barely fits, leaving no room for your plugin or the conversation. Load specific WP core files when relevant to your task, not the whole thing.

Hallucination does not disappear with more context. Better grounding improves Claude’s reasoning. It does not eliminate confabulation. Verify outputs for anything security-critical regardless of how much context you loaded.

Practical Setup: Codebase Snapshots

For my most complex plugins, I generate a single concatenated snapshot file that I can load at the start of complex sessions:

#!/bin/bash
OUTPUT="codebase-snapshot.txt"
echo "" > $OUTPUT
find . -name "*.php" \
  -not -path "*/vendor/*" \
  -not -path "*/node_modules/*" \
  | sort | while read file; do
  echo "=== FILE: $file ===" >> $OUTPUT
  cat "$file" >> $OUTPUT
  echo "" >> $OUTPUT
done
echo "Snapshot: $(wc -l < $OUTPUT) lines"

This runs in seconds and produces a predictable, versioned snapshot. The filesystem MCP can provide real-time access to live files, but for analysis sessions where I want a static snapshot of a specific state, before a refactor, before a release, the concatenated file is more reliable.

Combined with the MCP server approach I use for complex migrations, this gives me the full picture: real-time file access for active development work, plus controlled snapshots for analysis and planning.

How This Changes the Work

Before 1M context, Claude was useful for discrete tasks. Write this function. Review this file. Fix this bug. The context limit enforced that model, work had to fit.

With 1M context, I use Claude more like a collaborator who has read the entire codebase. The conversation shifts from “here is the problem in isolation” to “here is everything, what do you see?” The advice is more grounded. Edge cases get caught before they become support tickets. Architectural suggestions account for real constraints instead of imagined ones.

This does not change the fundamentals of WordPress development. It removes one constraint that was artificially limiting how useful AI assistance could be on complex, interconnected codebases. Use the space when the task justifies it, and when it does, the difference is substantial.