DEV Community: Julian Brown

How We Cut AI Agent Token Usage by 85% with Local MCP

Julian Brown — Mon, 07 Sep 2026 17:00:01 +0000

In Part 1, we gave our coding agent infinite memory. Here is how we used that retrieval engine to eliminate 3,000-turn marathon sessions and crush our token bill.

The Problem

In How to Give Your AI Coding Agent Infinite Memory, we showed how to index session tapes into SQLite FTS5 for sub-10ms recall.

Yet even with local search tools available, we fell into the exact operational trap every developer encounters: The Marathon Session.

Our main Antigravity session reached 3,223 turns—accounting for 46% of all operational steps ever recorded across our entire studio history.

Why did we let the thread grow so large? Context-loss fear. We hesitated to close the session because we didn't want the agent to lose working agreements, file paths, and architectural nuances.

The hidden cost was catastrophic:

Context Compounding: In an agentic IDE, every turn and tool call re-transmits the active conversation history. At Turn 3,200, each inference step sent 80,000 to 120,000 tokens. A simple 4-step tool routine burned 400,000 input tokens on a single prompt.
Subagent Memory Flooding: Spawning 11 background audit subagents ran 532 steps, generating ~225,000 tokens in logs and dumping 37,000 words of raw diagnostic output directly into the parent thread's prompt window.
Full-File Ingestion: Viewing large draft files (73k+ characters) repeatedly parked massive payloads in active working memory.

The Fix

Having an MCP memory server is only half the battle; you must operationalize it to eliminate session hoarding.

Instead of keeping one giant conversation on life support, we instituted a Zero-Loss Context Protocol that rotates threads frequently and uses search-antigravity as an on-demand retrieval bridge.

┌─────────────────────────────────────────────────────────────┐
│                    The 85% Reduction Loop                   │
└─────────────────────────────────────────────────────────────┘
                               │
            ┌──────────────────┴──────────────────┐
            ▼                                     ▼
┌──────────────────────────────┐    ┌─────────────────────────────┐
│ 1. Milestone Thread Rotation │    │ 2. Silent Worker Protocol   │
│ • Retire sessions at ~40 turns│   │ • Subagents write to disk   │
│ • Context: 100k+ ➔ 5k tokens │    │ • 2-sentence summary in chat│
└──────────────┬───────────────┘    └─────────────┬───────────────┘
               │                                  │
               └──────────────────┬───────────────┘
                                  ▼
┌─────────────────────────────────────────────────────────────┐
│                 search-antigravity Engine                   │
│   (Fresh session restores exact historical context in 8ms)  │
└─────────────────────────────────────────────────────────────┘

The 3 Core Operational Shifts

1. Milestone Session Rotation (Zero-Loss Handoff)

Because our agent can call search_antigravity_conversations() to pull prior decisions in sub-10ms, there is zero risk in closing a thread.

We now retire sessions at distinct operational milestones (every 25–40 turns). A fresh session drops input context from ~110,000 tokens back down to ~6,000 tokens—an instant 90%+ drop in per-turn burn.

2. The Silent Worker Protocol

Subagents should never dump raw analysis into the parent context.

We updated our subagent orchestrator: background workers write their complete diagnostic reports and diffs directly to disk (e.g., Audits/Continuity_Report.md). They return only a two-sentence summary and clickable file paths to the main thread. This prevents 40,000-token summaries from polluting parent working memory.

3. Surgical File Slicing

We replaced monolithic file reads with ripgrep and targeted line slicing (StartLine / EndLine). Instead of ingesting a 75,000-character manuscript to check one dialogue line, the agent searches the target pattern and reads only the exact 20-line window.

The Result in Practice

When starting a clean session for a new milestone, the agent restores context on demand:

search_antigravity_conversations(query: "Book 2 continuity audit findings")

Within 8 milliseconds, SQLite returns the exact file location and rationale from the previous session for ~110 tokens:

[Match 1 | Session: f40f-22... | Step #3248]
"All 11 Book 2 continuity audits written to disk in The Armor We Keep/Audits/..."

Per-turn input footprint: Slashed from ~105,000 tokens to ~7,800 tokens (85%+ reduction).
Parent thread bloat: Eliminated (subagents write to disk).
Context loss: 0% (exact tape recall via MCP).

Grab the Code

The complete implementation and parser scripts are open source on GitHub:

👉 github.com/kingjulian24/search-antigravity (Includes setup instructions, indexer script, and MCP configuration).

Stop letting context fear trap you in 3,000-turn marathons. Give your agent local recall, enforce silent subagents, and keep your active context lean.

How to Build a Solo Developer Studio with Composable MCP Servers

Julian Brown — Mon, 07 Sep 2026 13:35:22 +0000

Combine local session memory and community distribution into a closed-loop workflow that turns your daily engineering into living documentation.

The Problem

Most developers use the Model Context Protocol (MCP) as a collection of disconnected utilities: one tool for querying a database, another for checking weather, or a script for running shell commands.

When your tools live in silos, you still carry the cognitive burden of manually bridging the gaps. You finish a feature, but when it’s time to document or share what you learned, you have to reconstruct past decisions from memory, search the web to see what’s already been written, and manually format code blocks. The friction often means valuable architectural lessons stay trapped in your terminal history.

The Fix

Compose multiple local MCP servers inside a single agent session to create a closed-loop studio.

By pairing an inward memory server (search-antigravity) with an outward platform server (dev.to-mcp), your agent gains both self-awareness and ecosystem context. In a single conversational turn, it can retrieve exact past benchmarks from your local session logs, check community discussions to see where those lessons add value, and stage clean documentation—all without you leaving your editor.

The Architecture

┌─────────────────────────────────────────────────────────────┐
│                      AI Coding Agent                        │
└──────────────┬──────────────────────────────┬───────────────┘
               │ [stdio]                      │ [stdio]
               ▼                              ▼
┌──────────────────────────────┐┌─────────────────────────────┐
│      search-antigravity      ││         dev.to-mcp          │
│       (Inward Memory)        ││    (Outward Distribution)   │
├──────────────────────────────┤├─────────────────────────────┤
│ • Incremental MTime Parser   ││ • Community Discussion Scan │
│ • SQLite FTS5 BM25 Engine    ││ • Zero-Switch Draft Staging │
│ • Historical Turn Retrieval  ││ • Post-Ship Comment Triage  │
└──────────────┬───────────────┘└─────────────┬───────────────┘
               │                              │
               ▼                              ▼
     [ Local Session Tapes ]          [ DEV.to Community ]

The 3 Pillars of Composable MCP

1. Inward Memory Meets Outward Context

In Part 1, we indexed past session logs with SQLite FTS5 for sub-10ms recall. In Part 2, we connected the agent to DEV.to.

Composing them unlocks the flywheel: the agent pulls the exact rationale of an edge case you solved yesterday and maps it directly to a problem a developer is asking about today.

2. Grounded in Real Evidence, Not Guesswork

You never have to draft technical write-ups from vague memory. Because the agent queries indexed session tapes, every code snippet, error message, and benchmark cited in your documentation reflects what actually ran on your machine.

3. Zero-Overhead Developer Experience

There are no cloud vector databases to configure, no monthly SaaS subscriptions, and no background daemons eating RAM. Both servers run locally over standard input/output (stdio) and activate only when queried.

The Workflow in Practice

Here is the complete loop executing inside a single session:

# 1. Retrieve exact benchmark from historical session tapes
memory = search_antigravity_conversations(query="SQLite FTS5 BM25 benchmark")

# 2. Check community conversations for relevant discussions
discussions = devto_search_articles(query="AI agent memory", per_page=5)

# 3. Synthesize and stage the post directly from local evidence
devto_create_article(
    title="How to Give Your AI Coding Agent Infinite Memory",
    body_markdown=synthesize_post(memory, discussions),
    published=False,
    tags=["ai", "mcp", "python", "sqlite"]
)

Execution Time: <5 seconds
Browser Tabs Opened: 0
Data Fidelity: 100% (Directly sourced from verified local session logs)

Grab the Code

Both servers are modular, lightweight, and open source on GitHub:

👉 Memory Server: github.com/kingjulian24/search-antigravity
👉 Platform Server: github.com/kingjulian24/dev.to-mcp

When your agent has memory of what you’ve built and connection to the community you build for, sharing your work stops being a separate chore—it becomes an automatic byproduct of doing the work.

How to Write Better Technical Posts with MCP

Julian Brown — Mon, 07 Sep 2026 13:35:03 +0000

Research community discussions, stage drafts from your terminal, and keep your articles in sync with your code.

The Problem

Writing good technical articles is difficult when the writing happens in a vacuum.

Most developers write posts long after the code is finished. By the time you switch to a browser to format markdown and set tags, the immediate context is cold, and you're left guessing which parts of your solution the community actually cares about.

When writing is disconnected from the development environment, posts either don't get written or end up outdated the moment the underlying code changes.

The Fix

Bring the publishing platform directly into your development workflow.

By connecting your AI coding agent to DEV.to using a lightweight FastMCP server over stdio, you turn your agent into an active editorial assistant. Instead of just pushing markdown, the agent can research active community discussions to see where your experience adds value, stage clean drafts while the code is fresh, and keep your published posts updated as your repository evolves.

The Architecture

┌─────────────────────────────────────────────────────────────┐
│                      Coding Agent                           │
└──────────────────────────────┬──────────────────────────────┘
                               │
                      [stdio transport]
                               │
                               ▼
┌─────────────────────────────────────────────────────────────┐
│               dev.to-mcp (FastMCP Server)                   │
├──────────────────────────────┬──────────────────────────────┤
│      Community Research      │       Draft & Content Sync   │
│  • devto_search_articles     │  • devto_create_article      │
│  • devto_list_articles       │  • devto_update_article      │
│  • devto_get_comments        │  • devto_get_my_articles     │
└──────────────────────────────┴──────────────────────────────┘
                               │
                     [HTTPS / DEV.to API]
                               │
                               ▼
                    [ DEV.to Community ]

3 Ways an MCP Server Improves Your Writing

1. Discover What the Community Actually Needs

Before drafting, have your agent check recent discussions: "Search DEV.to for articles on agent memory." It surfaces what developers are actively asking, helping you focus your writing on unresolved questions rather than repeating well-trodden ground.

2. Draft While Context Is Fresh

The best time to document a pattern is right after you build it. When your session wraps, the agent can take your working notes, format the technical diffs, attach tags (#ai, #mcp, #python), and stage a private draft via devto_create_article. You capture the rationale without ever leaving your editor.

3. Keep Articles Living with Your Code

Technical posts decay when repositories change. With devto_get_comments, your agent can monitor reader feedback and edge cases. When you update the project, devto_update_article pushes fresh benchmarks and code adjustments straight to the post.

The Result in Practice

# 1. Check existing discussions to find open angles
devto_search_articles(query="MCP server memory", per_page=5)

# 2. Stage a verified draft directly from your session
devto_create_article(
    title="How to Give Your AI Coding Agent Infinite Memory",
    body_markdown="...",
    published=False,
    tags=["ai", "mcp", "python", "sqlite"]
)

Output:

🎉 Article Successfully Saved as Draft!
Title: How to Give Your AI Coding Agent Infinite Memory
Article ID: 4593622
Status: Draft (Private)
URL: https://dev.to/julianbrown/how-to-give-your-ai-coding-agent...

Staging Latency: <2 seconds
Context Switches: 0 (Everything stays in the terminal)

Grab the Code

The complete implementation is open source on GitHub:

👉 github.com/kingjulian24/dev.to-mcp (Includes setup instructions, FastMCP server script, and sample agent prompts).

Connecting your coding agent to the developer community makes technical writing a natural part of writing code.

How to Give Your AI Coding Agent Infinite Memory

Julian Brown — Mon, 07 Sep 2026 13:34:59 +0000

Stop blowing context windows on historical chat logs. Index your agent's local session tapes with FastMCP and SQLite FTS5 for sub-10ms recall.

The Problem

AI coding agents are stateless. Once a session closes, the context window resets, and the agent forgets every architectural trade-off, rejected alternative, and subtle debugging edge case you worked through.

Cramming 100k-token transcripts into prompt context causes latency spikes, attention dilution, and cost bloat. Naive automated summaries strip away the exact chronological rationale and specific trade-offs you actually need.

The Fix

Don't stuff context. Index your past trajectories locally and let the agent query them on demand.

Think of it as giving your agent an active retrieval reflex instead of asking it to carry its entire life history in working memory. By connecting a lightweight FastMCP server to an embedded SQLite FTS5 database, the agent can search its own historical conversations in sub-10ms and pull exact past decisions using fewer than 120 tokens.

The Architecture

~/.gemini/antigravity/brain/
            │
  [<session-id>/transcript.jsonl]
            │
            ▼
┌───────────────────────────────────────┐
│ Incremental MTime Parser              │
│ (Filters noise, diffs & shell stdout) │
└───────────────────┬───────────────────┘
                    │
                    ▼
┌───────────────────────────────────────┐
│ SQLite + FTS5 BM25 Engine             │
│ (conversations.db — local keyword FTS)│
└───────────────────┬───────────────────┘
                    │
                    ▼
┌───────────────────────────────────────┐
│ FastMCP Server (stdio transport)      │
│ (Exposes search tools to the agent)   │
└───────────────────┬───────────────────┘
                    │
                    ▼
          [ Antigravity Agent ]

How to Build It

1. Configure at the Global MCP Tier

In Google Antigravity, place the server in your global configuration (~/.gemini/config/mcp_config.json), rather than the scoped workspace config (.agents/mcp_config.json).

Why: The agent gains cross-project memory across all branches, repositories, and writing workspaces without dragging unrelated source code or context into the active project tree.

2. Filter the Noise Before Indexing

Raw agent transcripts (transcript.jsonl) contain megabytes of raw terminal output, file overwrite diffs, and status pings. Blindly indexing this breaks BM25 search relevance.

The ingestion parser applies three strict filters:

Index only discourse: Captures USER_INPUT (steering/prompts) and PLANNER_RESPONSE (reasoning/decisions). Discards binary payloads, file scrapes, and transient tool poll steps.
Truncate tool bloat: Strips multi-thousand-line stdout outputs. Indexes only the tool name and target file reference (e.g., write_to_file: target.py).
Clamp content length: Enforces a hard ceiling (MAX_CONTENT_CHARS = 10_000) on individual messages to prevent catastrophic index bloat.

3. Index with SQLite FTS5

Store records in a local SQLite virtual table using FTS5, Porter stemming, and Unicode-61 tokenization. An mtime cache tracks file modification timestamps so incremental re-indexing across dozens of sessions takes less than 20 milliseconds.

4. Expose the Search Tools

The FastMCP server exposes two primary tools over stdio:

search_antigravity_conversations(query="..."): Returns BM25-ranked matches with conversation IDs, timestamps, and highlighted snippets.
get_antigravity_step(conversation_id, step_index): Pulls the surrounding dialogue window for full contextual fidelity.

The Result in Practice

When the agent hits friction, needs historical context, or conducts a post-mortem on earlier decisions, it calls the MCP tool directly:

search_antigravity_conversations(query="Observer Stance negative assertions")

Instead of guessing or re-reading giant raw files, SQLite returns the exact turn where the decision was made:

[Match 1 | Session: 8f2a-e1... | Date: 2026-09-02 14:18]
Role: PLANNER_RESPONSE
Snippet: "...decided to cut redundant negative assertions from Chapter 1. 
The observer stance works best when physical actions imply boundaries 
rather than explicitly stating what didn't happen..."

Query Latency: <10 ms
Context Overhead: ~120 tokens (a >99.8% reduction vs. reading raw transcripts)

Grab the Code

The complete implementation is open source on GitHub:

👉 Memory Server: github.com/kingjulian24/search-antigravity

Stop starting from scratch every time you open a terminal. Let your agent inspect the tape.