DEV Community: Dmitry

I got tired of Claude Code forgetting everything. So I built Glutamate.

Dmitry — Wed, 03 Jun 2026 15:34:42 +0000

Every session with Claude Code starts the same way.

You open a new terminal. You type your first message. And then you spend the next 10 minutes re-explaining what you were doing yesterday, why a certain function works the way it does, and which bugs you've already fixed.

The agent isn't dumb. It just has amnesia. Every. Single. Session.

I tried prompting my way out of it. CLAUDE.md files, detailed system prompts, elaborate context dumps at the start of each session. It helped, but it didn't scale. So I built Glutamate - an MCP toolkit that hooks into Claude Code's lifecycle and gives the agent persistent, structured memory across sessions.

What it does

Failure Memory

When the agent debugs a bug and finds the fix, Glutamate logs it. Next session, same bug - instant recall.

"This took 3 hours last time. Now 30 seconds."

Agents have a habit of re-introducing the same bugs and re-discovering the same fixes. Failure Memory breaks that loop.

Code Intelligence

Glutamate runs a local stdio MCP server that uses tree-sitter to give the agent structural code understanding across 8 languages.

Instead of reading 2000 lines of a file to find one function, the agent reads 20 lines of exactly the right symbol.

The compound effect matters: an agent reads code dozens of times per session. Each read is 20 lines instead of 2000. By the end of a long session, context isn't polluted and quality doesn't degrade.

Parallel Session Awareness

Running multiple Claude Code windows on the same project? They see each other and coordinate. No other tool solves this - existing memory systems work with one agent's memory, Glutamate coordinates between agents.

Decision Archaeology

Pass a commit hash, get every task doc written during that session. Full history of why the code looks the way it does, tied directly to git. Three months later, you won't ask "why did we do this?" - you'll know.

Post-commit Stale Detection

After every git commit, Glutamate finds docs that reference the files you just changed and flags them as stale. The agent gets a nudge: regenerate these while the context is still fresh. Documentation doesn't silently rot.

LiveDocs Task Tracking

Real-time visibility into what the agent is doing - what's open, what's done, what's next.

How it works under the hood

Two MCP servers run side by side:

Remote HTTP server (Docker) - owns the database. Handles livedocs, knowledge base, rules, failure memory, analytics, sessions, patterns. Passes project_root on each tool call, so one server handles multiple projects. New projects auto-register on first call.

Local stdio server - stateless tree-sitter tools. No database, just structural code analysis. Runs on the host machine, configured in .mcp.json.

Three Claude Code hooks wire everything together:

UserPromptSubmit - before every prompt, runs hybrid FTS5 + vector search across KB and task history, injects relevant context automatically
PostToolUse (git commit) - finds docs that went stale and tells the agent to regenerate them while the knowledge is fresh
SessionStart - loads rules, past failures, and the project boundary map so the agent starts oriented

The intent classifier (local Ollama model) tags each prompt as feature, debug, refactor, or question and loads different context profiles accordingly. A debug prompt loads failure memory. A feature prompt loads patterns and module docs.

Why "Glutamate"

Glutamate is an amino acid that acts as a neurotransmitter in your brain. Its job is to pass signals between neurons. Without it, memory doesn't form, connections don't build.

Same idea here, except for your AI dev.

What's not built yet

pip install glutamate-mcp onboarding (currently requires manual Docker setup)
Multi-tenant hosted version (currently single-user, self-hosted)

Running a closed beta now. Landing page and demo video: beta.glutamate.pro

Happy to answer questions about the architecture, the hook system, or anything else.

Stop using TTL for Ethereum contract cache — use event-driven invalidation instead

Dmitry — Mon, 11 May 2026 08:55:37 +0000

If you're building a dApp, you've probably written something like this:

const cached = await redis.get(`cdp:position:${user}`);
if (cached) return JSON.parse(cached);
const position = await cdpContract.methods.getPosition(user).call();
await redis.setEx(`cdp:position:${user}`, 60, JSON.stringify(position)); // 60s TTL
return position;

This works, but there's a hidden problem: your data is stale for up to 60 seconds by design. And you're making RPC calls every 60 seconds regardless of whether anything actually changed on-chain.

For most protocol contracts — a CDP vault, a staking contract, a price oracle, a liquidity pool — transactions are relatively rare. Most users are just reading. The contract state sits unchanged for minutes, hours, sometimes days.

The insight

Contract state only changes when a transaction is mined. A user's CDP position doesn't change on its own between blocks — it changes because that user sent a transaction.

So instead of a TTL, you can do this:

Cache forever (TTL = 0)
Watch the blockchain for transactions to your contracts
Delete the affected Redis keys the moment a tx is detected

tx mined → watcher detects it → redis.del("cdp:position:*") → next request hits RPC

Scenario	60s TTL	Event-driven (TTL=0)
No activity, 1 hour	60 RPC calls	0 RPC calls
1 tx per minute	60 RPC calls	1 RPC call
10 tx per minute	60 RPC calls	10 RPC calls

The less active your contract, the bigger the win. For a lending protocol or an oracle, this can mean zero RPC calls during quiet periods while data stays perfectly fresh.

Note: This pattern is designed for your own protocol contracts with moderate activity — not for watching global tokens like USDC or WETH, which receive thousands of transactions per block and would invalidate your cache constantly.

Introducing Blockpulse

I extracted this pattern from a production DeFi app into a standalone service: Blockpulse.

You configure which contracts to watch and which Redis patterns to delete:

// config/config.js
module.exports = {
  contracts: [
    {
      address: "0xYourCDPContract",
      name: "cdp",
      events: ["PositionOpened", "PositionClosed", "Liquidated"],
      cacheKeys: [
        "myapp:cdp:position:*",
        "myapp:cdp:stats:*"
      ]
    },
    {
      address: "0xYourOracle",
      name: "oracle",
      events: ["PriceUpdated"],
      cacheKeys: ["myapp:price:*"]
    }
  ]
};

That's it. Start it alongside your app:

docker compose up

Every time a transaction touches your CDP contract, Blockpulse deletes myapp:cdp:position:* from Redis. Your backend gets fresh data on the next request — and not a moment sooner.

What else it does

Beyond cache invalidation, Blockpulse also:

Indexes events — decoded logs stored in Redis, queryable via /api/events/:address
REST API for contract calls — /api/call/:contract/:method with Redis caching
Batch calls — /api/batch for multiple contract reads in one round-trip
Historical sync — backfills past events via Etherscan API on startup
Cache dependencies — invalidate contract B's keys when contract A changes
Multi-chain — set CHAIN_ID for Polygon, Arbitrum, Base, etc.

Architecture

  Ethereum Node (WebSocket / HTTP)
        │
        ▼
  ┌─────────────┐     tx detected
  │  Blockpulse │ ──────────────────► Redis DEL (your key patterns)
  └──────┬──────┘
         │
         ▼ REST API :3002
  /api/call · /api/events · /api/batch

Getting started

git clone https://github.com/nagor2/blockpulse
cd blockpulse
cp .env.example .env               # add your RPC URL and REDIS_URL
cp config/config.example.js config/config.js   # add your contracts
npm install && npm start

The service has been running in production on Ethereum mainnet as part of a DeFi frontend. It's MIT licensed and ~1700 lines of Node.js.

GitHub: github.com/nagor2/blockpulse

Curious if anyone's solved this differently — happy to discuss tradeoffs in the comments.