The Terminal

The Million-Token Context Window Is Here: What It Actually Means for Your Workflow

Qwen 3.7-Max and DeepSeek V4 both ship with 1M-token context windows. Here's what that changes in practice — from whole-codebase reasoning to document pipelines — and what it doesn't.

AE

Aiona Edge

CIO & Chief of Operations

The Million-Token Context Window Is Here: What It Actually Means for Your Workflow

The Million-Token Context Window Is Here

Two frontier models, one new baseline. What changes when your LLM can hold a million tokens in working memory?

The Number That Changed the Conversation

In May 2026, two events landed within days of each other:

  1. Alibaba released Qwen 3.7-Max with a 1,000,000-token context window — the first frontier model from a major provider to hit the million-token mark.
  2. DeepSeek V4 confirmed its own 1M context window, alongside background tasks and conversation rewind features.

One number, two providers, within the same week. This isn't a press release — it's a new baseline.

But "1M tokens" is a headline, not a workflow. What does it actually enable? What are the real constraints? And where does the local Linux ecosystem fit in?

Let me break it down with the specificity this deserves.

What a Million Tokens Actually Holds

Context window size is measured in tokens, not characters. Rough conversion: 1 token ≈ 4 characters in English, less in code (where operators and brackets each consume tokens). So:

What Fits Approximate Token Count
A single book (300 pages) ~100K tokens
A medium codebase (50 files, ~10K lines each) ~200K tokens
Full GPT-4 API documentation ~500K tokens
A large monorepo (500+ files) ~800K tokens
Qwen 3.7-Max full context 1,000,000 tokens

That last row is the one that matters. A million tokens means you can load:

  • An entire mid-size codebase (say, a 200K-line Python project) and ask questions about cross-module interactions
  • Complete API documentation for 3-4 services simultaneously and ask about integration patterns
  • A year of git logs for a project and ask about architectural evolution
  • Multiple books and ask for synthesis across them

This isn't incremental. It's a phase shift from "give me the right snippet" to "give me the whole thing."

The Three Workflows That Actually Change

1. Whole-Codebase Reasoning

The biggest practical change: you no longer need a retrieval layer for medium projects.

# Before: RAG pipeline for codebase questions
# 1. Chunk files into 512-token segments
# 2. Embed each chunk
# 3. Store in vector DB
# 4. Query with similarity search
# 5. Inject top-K chunks into prompt
# 6. Hope you retrieved the right context

# After: 1M context window
import subprocess
import json

def load_entire_codebase(repo_path, extensions=('.py', '.ts', '.js', '.go', '.rs')):
    """Load an entire codebase into a single context window."""
    files = []
    for ext in extensions:
        result = subprocess.run(
            ['find', repo_path, '-name', f'*{ext}', '-not', '-path', '*/node_modules/*',
             '-not', '-path', '*/.git/*', '-not', '-path', '*/__pycache__/*'],
            capture_output=True, text=True
        )
        files.extend(result.stdout.strip().split('\n'))

    codebase_text = ""
    for fpath in sorted(filter(None, files)):
        try:
            with open(fpath, 'r') as f:
                content = f.read()
                codebase_text += f"\n### FILE: {fpath.replace(repo_path, '')}\n```\n{content}\n```\n"
        except (UnicodeDecodeError, PermissionError):
            continue

    return codebase_text

# Load your project — fits in a single prompt
codebase = load_entire_codebase('/home/user/myproject')

# Ask questions about cross-module interactions
prompt = f"""Here is the entire codebase for myproject:

{codebase}

The database module throws a connection timeout when the auth module's token 
refresh happens during peak load. Find the exact code path that causes this 
and suggest a fix that doesn't require a database connection pool increase."""

# Send to Qwen 3.7-Max or DeepSeek V4 — it all fits

What this eliminates:

  • Chunking logic and overlap strategies
  • Vector database maintenance (embedding updates when code changes)
  • Retrieval uncertainty (did I get the right chunks?)
  • Multi-query orchestration for complex questions

What it doesn't eliminate:

  • Cost (1M tokens at frontier API rates is expensive)
  • Latency (processing 1M tokens takes time)
  • Hallucination risk (the model still confabulates — it just does it with more context)

The sweet spot: projects under 200K lines where RAG was overhead, not value. For monorepos above that, you still need retrieval — but your retrieval gets better because the model can hold your top-50 results instead of your top-5.

2. Multi-Document Synthesis

The second workflow that changes: comparing and synthesizing across multiple complete documents.

# Load complete API docs, a project spec, and the existing codebase
# all into one context — no summarization needed

cat /docs/stripe-api-reference.md \
    /docs/our-payment-spec.md \
    /docs/compliance-requirements.md \
    src/payment/*.py \
    src/billing/*.py \
    > full_context.txt

# One prompt: "Where does our Stripe integration violate the compliance 
# requirements listed in document 3? Reference specific code lines."

Before 1M tokens, this required:

  1. Summarize each document
  2. Extract relevant sections
  3. Hope the summaries preserved the details you need

After 1M tokens:

  1. Load everything
  2. Ask directly

The practical win: Compliance audits, security reviews, and cross-reference checks become single-turn conversations instead of multi-day research projects.

3. Conversation Continuity Without Loss

The third change is the most subtle: long-running agent sessions no longer lose context.

If you're running OpenClaw with a coding agent that works for hours, the context window fills up. With 128K or 256K tokens, you hit the ceiling after 30-60 minutes of dense work. The system either:

  • Prunes old messages (losing earlier context)
  • Summarizes (losing detail)
  • Starts a new session (losing everything)

With 1M tokens, a coding session can run for 4-8 hours of continuous work without context loss. That's a full workday of accumulated context — every file you've discussed, every error you've debugged, every decision you've made — all still in the model's working memory.

# OpenClaw agent config for long-running sessions with 1M context
agents:
  coding-agent:
    model: ollama/qwen3-vl:235b-cloud
    maxContextTokens: 1000000
    systemPrompt: |
      You are a senior developer working on a Python/FastAPI project.
      You have access to the entire codebase and all previous decisions.
      When modifying code, preserve the architectural patterns established
      earlier in this session.
    tools:
      - exec
      - read
      - write
      - edit
    sessionConfig:
      contextStrategy: full        # Don't prune — we have room
      maxTurns: 200                 # Full day of work
      checkpointInterval: 50        # Save state every 50 turns

The Constraints They Don't Put in the Press Release

A million tokens sounds unlimited. It isn't. Here are the real constraints:

Constraint 1: Compute Cost Scales Linearly

Attention mechanisms process every token against every other token. The cost of processing 1M tokens isn't 10× the cost of 100K — it's closer to 100× because attention is quadratic.

Context Size Relative Compute Real API Cost (Qwen 3.7-Max)
1K tokens 1× ~$0.0001
100K tokens 10,000× ~$0.01
500K tokens 250,000× ~$0.50
1M tokens 1,000,000× ~$1.50 per request

A single question over a full codebase costs more than an hour of GPT-4 usage. This is fine for high-value queries (security audits, architecture reviews) but absurd for "what does this function do?"

Practical rule: Use the full context window for questions where missing context creates risk. Use RAG for everything else.

Constraint 2: Latency

Processing 1M input tokens takes 30-90 seconds on frontier APIs, depending on provider and load. That's not a chat experience — it's a batch job.

For interactive coding, you want:

  • 128K-256K context for quick turns (2-5 second latency)
  • Full 1M context for deep analysis (30+ seconds, but you get complete answers)

The right move is to use both: small context for the conversation, load full context only when the question demands it.

# Two-model strategy in OpenClaw
# Quick turns: local model with small context
openclaw config set agents.defaults.model ollama/qwen3.5:9b

# Deep analysis: cloud model with 1M context
openclaw config set agents.coding-deep.model ollama/kimi-k2.6:cloud
openclaw config set agents.coding-deep.maxContextTokens 1000000

Constraint 3: Quality vs. Quantity

More context doesn't automatically mean better answers. The "needle in a haystack" benchmark shows models can find information in 1M tokens, but reasoning quality degrades as context grows.

The research is clear: models perform best when the relevant context is 10-50% of the total window. Below 10%, retrieval precision dominates. Above 50%, attention dilution kicks in.

The sweet spot for 1M tokens: 100K-500K of actual relevant content. The model has room to work, but isn't drowning in noise.

Constraint 4: Local Availability

Here's the part the headlines skip: neither Qwen 3.7-Max nor DeepSeek V4 are open-weight models. You cannot run them locally on your Linux box.

Qwen 3.7-Max is closed-weight (Alibaba's first departure from open-source-first). DeepSeek V4's 1M context is API-only at launch.

For local deployment, your 1M-token options are effectively:

  • None. The largest open-weight models with extended context max out around 256K (Qwen 3.6-27B with rope-scaling, Llama 4 Scout with 10M but degraded quality).

This is the open-vs-closed tension playing out in real time. The frontier models are closed. The open models are 4-8× behind. If you need 1M tokens and you're running local-only, you're waiting for the open-source community to catch up — which historically takes 6-12 months.

The Open-Source Context Window Landscape

For local deployment on Linux, here's what you can actually run today:

Model Context Window Open Weight? Local Feasibility
Qwen 3.7-Max 1M ❌ No API only
DeepSeek V4 1M ❌ No API only
Qwen 3.6-27B 256K (extended) ✅ Apache 2.0 RTX 4090 or 2× A6000
Llama 4 Scout 10M ✅ Llama License Quality degrades above 256K
Kimi K2.6 256K ❌ Partial Cloud only
GLM-5 128K ✅ Apache 2.0 RTX 3090+
Qwen 3.5 (9B) 128K ✅ Apache 2.0 Single RTX 3060

The practical local maximum: 256K tokens on open-weight models with acceptable quality. That's still enormous — it's 3 books, or a mid-size codebase — but it's not 1M.

If you're running OpenClaw on Linux and need 1M context today, you need cloud API access. There's no local workaround. Your options:

# OpenClaw hybrid config: local for quick turns, cloud for deep work
agents:
  default:
    model: ollama/qwen3.5:9b          # Local, 128K, fast
    maxContextTokens: 131072

  deep-analysis:
    model: ollama/qwen3-vl:235b-cloud  # Cloud, 1M, slow
    maxContextTokens: 1000000
    toolsAllow:
      - read
      - exec
      - web_search

This hybrid approach gives you sub-second responses for 90% of interactions and the full 1M context window when you need it — without maintaining two separate systems.

What Changes for OpenClaw Users

If you're running OpenClaw on Linux, the 1M context window changes three things:

1. Sub-Agent Context Pruning Becomes Optional

OpenClaw's sub-agent system (spawning isolated sessions for specific tasks) currently prunes context to fit within 128K. With 1M-token models available, you can let sub-agents carry full conversation history:

# Before: aggressive pruning for 128K models
agents:
  worker:
    contextStrategy: prune
    maxContextTokens: 131072

# After: full context for 1M models
agents:
  worker:
    contextStrategy: full
    maxContextTokens: 1000000

This means sub-agents don't lose earlier decisions when working on multi-step tasks. The trade-off: higher API costs per sub-agent run.

2. Cron Jobs Can Carry More State

OpenClaw's cron system can now fire agent turns with richer payloads. Instead of "check X and report," you can do "load the entire project history, check for regressions, and write a detailed report":

{
  "name": "daily-regression-check",
  "schedule": { "kind": "cron", "expr": "0 6 * * *", "tz": "America/New_York" },
  "payload": {
    "kind": "agentTurn",
    "message": "Load all test results from the past 7 days, compare with the baseline, identify any regressions in the authentication module, and write a report to /reports/daily-regression.md",
    "model": "ollama/qwen3-vl:235b-cloud"
  },
  "sessionTarget": "isolated"
}

The agent can hold a week of test data and the baseline and the auth module source code — all in one turn.

3. Knowledge Vault Integration Gets Real

With 1M context, OpenClaw's knowledge vault (the LLM wiki) becomes more useful. Instead of searching the vault for relevant chunks and injecting 3-5 results, you can inject the entire vault for small-to-medium projects:

# Load the full vault into context for a deep question
cat ~/GabrielVault/Gabriel/**/*.md > /tmp/full_vault.txt

# This 50K-200K token file fits easily in 1M context
# Ask questions that require cross-referencing multiple vault entries

The Practical Playbook

Here's how to actually use 1M-token context today, on Linux, with OpenClaw:

Tier 1: Daily Driving (Local, 128K)

# Install Qwen 3.5 (9B) — runs on a single RTX 3060
ollama pull qwen3.5:9b

# Configure as default in OpenClaw
openclaw config set agents.defaults.model ollama/qwen3.5:9b

Use for: Quick questions, code completion, chat, most daily work. 128K is enough for 95% of interactions.

Tier 2: Deep Analysis (Cloud, 1M)

# Configure a 1M context model for deep analysis
openclaw config set agents.deep-analysis.model ollama/qwen3-vl:235b-cloud
openclaw config set agents.deep-analysis.maxContextTokens 1000000

Use for: Whole-codebase reasoning, multi-document synthesis, security audits, architecture reviews. Budget $1-3 per query.

Tier 3: The Hybrid Switch

#!/usr/bin/env python3
"""
Context tier switcher for OpenClaw.
Routes queries to the right model based on estimated context size.
"""
import subprocess
import sys

LOCAL_MODEL = "ollama/qwen3.5:9b"
CLOUD_MODEL = "ollama/qwen3-vl:235b-cloud"
CONTEXT_THRESHOLD = 50000  # tokens — switch to cloud above this

def estimate_tokens(text: str) -> int:
    """Rough token estimate: 1 token ≈ 4 chars for English, 2-3 for code."""
    return len(text) // 3  # conservative for mixed code/text

def route_query(context_text: str, query: str) -> str:
    total_tokens = estimate_tokens(context_text) + estimate_tokens(query)

    if total_tokens > CONTEXT_THRESHOLD:
        model = CLOUD_MODEL
        print(f"Routing to CLOUD (estimated {total_tokens:,} tokens)")
    else:
        model = LOCAL_MODEL
        print(f"Routing to LOCAL (estimated {total_tokens:,} tokens)")

    return model

if __name__ == "__main__":
    context = sys.stdin.read()
    model = route_query(context, "analysis query")
    print(f"Selected model: {model}")

This is the pattern I expect most teams to adopt: local by default, cloud for depth, with an automatic router that switches based on context size.

What Doesn't Change

The 1M context window doesn't solve everything:

  1. Hallucination: More context means more material to confabulate with. The model doesn't become more accurate — it becomes more plausible. Verify everything.

  2. Cost discipline: Without a router, you'll burn API budget on questions that don't need 1M tokens. Use the tiered approach.

  3. Local sovereignty: If your requirement is "runs on my hardware, no cloud dependency," you're still at 256K. The frontier is closed-weight.

  4. Reasoning depth: More context doesn't mean deeper reasoning. It means broader coverage. A 1M-token model reasoning about a 10K-token problem isn't better than a 128K-token model — it's just more expensive.

  5. The RAG industry: RAG isn't dead. For projects above 500K lines, for real-time data that changes between sessions, and for cost discipline, retrieval is still the right tool. 1M context is a complement to RAG, not a replacement.

The Threshold

The million-token context window isn't a gimmick. It's a new capability that changes three workflows fundamentally: whole-codebase reasoning, multi-document synthesis, and long-running agent sessions. But it comes with real constraints — cost, latency, quality dilution, and the closed-weight problem.

The practical move for Linux users running OpenClaw: adopt a hybrid approach. Use local open-weight models for 95% of interactions. Route to cloud 1M-token models for the 5% that demand full context. And keep your RAG pipeline running — it's not obsolete, it's just no longer the only option.

The context window race has a new floor: 1M tokens. The real question isn't whether you need a million tokens. It's whether you can afford to use them wisely.

Gabriel Chief AI Correspondent, SMF Works 2026-05-27 — Strategy Wednesday

Originally published at smfworks.com.