From Copy-Paste to COSAW: Beating the Context Wall

How a development workflow evolved through four generations of tooling, hit a hard wall at 350K tokens, and solved it with context-isolated sub-agents.
Reading time: ~8 minutes

The Evolution in One Picture

Four generations. Each one fixed the previous generation’s bottleneck. The fourth one solved a problem that most people don’t even know they have.

Gen 1: The Copy-Paste Dark Ages

You know the drill. ChatGPT generates 200 lines of beautiful Rust. You copy it. You open src/main.rs. You paste. You save. You go back. Copy the next file. Open src/config.rs. Paste. Save. Repeat 15 times.

It works. But every project beyond 5 files turns into a tedious assembly line of browser tabs and editor windows. One missed closing brace costs you 10 minutes of debugging. And God help you if you need to reproduce the setup six months later.

The bottleneck wasn’t code generation — it was file transfer.

Gen 2: The Script Awakening

The solution was obvious once you saw it: make the LLM write a script that writes the files for you.

Instead of 30 copy-paste cycles, you get one:

# LLM-generated build script
mkdir -p src tests
cat > src/main.rs << 'EOF'
// ... your code ...
EOF
cat > Cargo.toml << 'EOF'
// ... your config ...
EOF
git init && git add -A && git commit -m "init"
echo "Run with: cargo run"

One copy-paste. The entire project materializes. Git history clean. Build instructions embedded. Repeatable on any machine.

This pattern scaled to ~30-file projects before the scripts themselves became unwieldy. A 500-line bash script with embedded source is not fun to debug.

Gen 3: The Agent Era — And Why It Almost Worked

Tools that can touch the filesystem directly were the next leap. Instead of generating text for me to execute, the LLM could execute it.

I went on a tool safari:

• Claude Code — Could edit files, run commands, fix compilation errors. Game-changer for the feedback loop.
• picoclaw — Minimal memory footprint, but too constrained for complex work.
• claw-code / opencode — Interesting approaches, immature integrations.
• pi.dev — The skill system was genuinely well-designed. I used it for weeks.

I circled back to Claude Code. The reasons: native sub-agent support, MCP protocol for custom tools, git worktree isolation, and a permission model that didn’t drive me insane.

There was just one problem. A big one.

The 350K Token Wall

LLM context windows are not a free resource. Every token you spend on history is a token the model can’t attend to for reasoning. The attention mechanism has O(n²) cost — as context grows, the signal-to-noise ratio flattens.

The numbers, from real usage:

The old workflow had a fatal pattern:

Session start → 50K → 150K → 300K → 500K
Quality:      ✅    ✅    ⚠️    ❌    💀

The last 40% of every project took 3x longer and had 2x the bugs. Not because the LLM got dumber — because it was drowning in its own history.

Gen 4: COSAW — Context-Optimized Sub-Agent Workflow

The insight was simple: if LLMs are excellent at ~100K context and terrible at ~500K, don’t give them 500K contexts.

Decompose. Isolate. Keep it tight.

┌─────────────────────────────────────────────────────────────────┐
│  MAIN SESSION (oversight)                                      │
│  Context: ~50K — architecture, planning, review                │
│  Model: flash (cheap)                                          │
│                                                                │
│  1. Analyze codebase → decompose into phases                   │
│  2. Write a ~15K brief per phase                               │
│  3. Launch sub-agents                                           │
│  4. Review → merge → next                                      │
└─────────────────────────┬───────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│  SUB-AGENT (implementation) × N phases                         │
│  Context: ~20K — brief only, zero history bleed                │
│  Model: flash (cheap)                                          │
│                                                                │
│  Reads brief → implements → advisor review → signals complete   │
└─────────────────────────┬───────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│  FRAO-ADVISOR (quality gate)                                   │
│  Context: ~5-10K — diff review only                            │
│  Model: pro (medium cost, high quality)                        │
│                                                                │
│  3 checkpoints: architect → code-reviewer → final consult      │
└─────────────────────────────────────────────────────────────────┘

Each sub-agent starts fresh. No conversation history, no baggage, no "actually, going back to what I said 400K tokens ago…" — just a tight brief and a focused task.

How It Actually Works

The toolchain, from the ground up:

The Flow

1. User says: "Build the dashboard"
2. Main session: Explores codebase, produces architecture plan with N phases (~50K context — efficient)
3. For each phase: Creates a git worktree (isolated branch), writes a ~15K condensed brief
4. Sub-agent starts: Fresh session, ~20K total context. Loads skills. Reads the brief. Runs advisor architecture review. Implements. Runs advisor code review. Fixes CRITICAL/HIGH findings. Signals done.
5. Main session: Reviews, merges to dev, moves to next phase
6. Result: Every phase runs at peak LLM performance. Zero context degradation.

Critical detail: the sub-agent doesn’t commit. It stages (git add -A) and prints === PHASE_COMPLETE ===. The main session handles all commits and merges. This keeps the audit trail clean.

Frao Advisor: Quality at Scale

Frao Advisor is a multi-expert review system that uses a high-reasoning model (deepseek-v4-pro) to audit every phase of development. It supports 7 specialized expert personas:

The clever part: the expensive model only runs on small review payloads (diffs, not full conversations). The cheap flash model runs everything else. ~3x cost savings vs. using premium models for everything, with premium quality where it matters. Every call is logged to advisor.db with full metadata.

Every sub-agent goes through three mandatory checkpoints:

1. Architecture review (after planning, before coding)
The advisor’s "architect" persona reviews the approach. Component boundaries. Data flow. Failure modes. If the plan is wrong, this is where it gets caught — before a single line of code is written.

2. Code review (after implementation)
The "code-reviewer" persona reads every diff. Correctness, edge cases, error handling, test coverage. CRITICAL and HIGH findings must be fixed before proceeding.

3. Final consultation (before completion)
A comprehensive check: did we build what we said we’d build? Any regressions? Any security concerns? The advisor’s verdict is included in the completion summary.

The Numbers

The Lessons, Condensed

1. Context budgeting is real. Every token spent on history is a token not spent on reasoning. A 500K context isn’t "10x more information" — it’s "10x more noise."

2. Fresh sessions are free. A new Claude session costs pennies. A production bug costs hours. Split the task.

3. The brief is the product. Sub-agent output quality is proportional to brief quality. State exactly what exists, what to build, which files to touch, and what NOT to do. Ambiguity wastes the sub-agent’s context budget.

4. Advisor reviews pay for themselves. Catching a bug in review costs ~$0.10.

5. Match the model to the task. Cheap flash models for implementation, premium pro models for review (small payloads). Using a sledgehammer for finishing nails and a finishing hammer for concrete are both wrong.

Where to Go From Here

The full COSAW infrastructure lives in the Frao Technologies development workflow. You don’t need all of it to get the benefit — the core pattern (separate planning from execution, keep contexts under 100K, review everything) works with just Claude and a text editor.

For the full architecture and implementation details, see the Environment Separation Plan document that covers the dual-stack VPN isolation that makes this kind of parallel development possible.

— Richard Primera, Frao Technologies
Last updated: 2026-07-27