DEV Community: Tanmay Devare

DedrooM: loop detection + context compression for Claude Code (open source)

Tanmay Devare — Mon, 06 Jul 2026 10:01:00 +0000

I kept running into the same two problems with Claude Code on longer sessions: it'd get stuck retrying a failing command in a near-identical loop, and tool output (file listings, logs, diffs) would pile up in context even after it stopped being useful. Both quietly ran up the token bill.

So I built DedrooM — a small proxy that sits in front of Claude Code (and a few other agents: Codex, Aider, Cursor, Cline, OpenCode) and does two things:

Stops loops before they compound. Tracks repeated tool calls with an adaptive window, tightens up automatically once error rate climbs, and blocks a call outright if it's clearly stuck.
Compresses redundant tool output before it hits the model — truncates repetitive stuff like long file listings, dedupes logs, keeps the parts that actually matter.

It's one command to try:

bashpip install dedroom
dedroom wrap claude

dedroom unwrap claude puts things back to normal. It's Apache 2.0, source is here: https://github.com/Devaretanmay/dedroom

Being upfront about the numbers: the compression/savings figures in the README are from a handful of internal test scenarios, not a big benchmark suite — real savings depend a lot on your workload (loop-prone sessions and repetitive tool output benefit a lot more than a clean session does). I'd rather you try it and tell me it doesn't do much for your setup than oversell it here.

Would genuinely like feedback from people running long Claude Code sessions — especially if it either catches something useful or gets in your way. Happy to answer questions about how the loop detection or compression actually works under the hood.

Everyone Is Benchmarking Claude 5. They're Measuring the Wrong Thing.

Tanmay Devare — Wed, 01 Jul 2026 10:45:12 +0000

Claude 5 is here.

Every timeline is full of benchmark charts.

SWE-bench scores.

Coding comparisons.

Context windows.

Token pricing.

But after building runtime infrastructure for AI agents over the last few months, I think we're measuring the wrong thing.

The Wrong Question

Everyone is asking:

"How smart is Claude 5?"

I think the better question is:

"What happens after Claude 5 decides to call a tool?"

Because that's where production agents actually fail.

Not during reasoning.

During execution.

Reasoning Isn't The Hard Part Anymore

Today's models are incredibly capable.

They can:

Write production code
Search the web
Execute shell commands
Modify files
Query databases
Call APIs
Coordinate complex workflows

The difficult part isn't intelligence anymore.

It's execution.

A Failure I Kept Seeing

While testing coding agents, I noticed the same pattern over and over again.

The model wasn't getting dumber.

It was getting stuck.

Something like this:

write_file

write_file

write_file

write_file

write_file

Or this:

execute_shell

read_file

execute_shell

read_file

execute_shell

read_file

The reasoning wasn't changing.

Only the tool calls were.

The agent was trapped inside its own execution.

The Cost Of Runtime Failures

These aren't harmless mistakes.

I've seen agents:

Burn 40,000+ tokens
Spend 20+ minutes retrying
Rewrite the same file repeatedly
Retry impossible tasks forever

The model wasn't broken.

Nobody was supervising execution.

Prompt Engineering Doesn't Fix This

A better prompt can improve reasoning.

It cannot supervise execution after the model has already started making tool calls.

Once an agent enters a retry loop, telling it to "be careful" doesn't suddenly make it aware that it has repeated the same action ten times.

Execution needs its own runtime.

Why I Built MicroLoop

MicroLoop sits between the AI agent and every tool call.

LLM
 │
 ▼
MicroLoop Runtime
 │
 ▼
Tool Execution
 │
 ▼
Result
 │
 ▼
MicroLoop
 │
 ▼
LLM

Every action passes through the runtime.

If the agent begins spiraling into a pathological execution pattern, MicroLoop can:

Detect repeated execution trajectories
Interrupt infinite tool loops
Repair execution paths
Halt execution when necessary

The goal isn't to make models smarter.

The goal is to stop smart models from making expensive execution mistakes.

What Existing Benchmarks Don't Measure

Most AI benchmarks answer questions like:

Can the model solve the task?
How fast is it?
How many tokens did it consume?
What's the pass rate?

Those are useful.

But they rarely answer questions like:

How many retries occurred?
Did the agent enter a loop?
Did it recover after failure?
Did it terminate gracefully?
How much execution was wasted?

Those are runtime problems.

That's What I'm Testing Next

Instead of arguing over benchmark charts, I'm putting Claude 5 through runtime scenarios that resemble real production failures.

Including:

Infinite retry loops
Impossible tasks
Recursive tool chains
Broken execution states
Tool oscillation

Not to prove the model is bad.

To understand how modern AI agents behave when execution starts going wrong.

The Bigger Picture

As models continue getting smarter, I think the bottleneck shifts.

It won't be reasoning.

It'll be execution.

The next generation of AI infrastructure won't just build smarter agents.

It'll build better runtimes.

Because in production, intelligence gets the job started.

Reliable execution gets it finished.

I'd love to hear how you're handling runtime failures in your own AI agents.

Why Prompt Engineering Isn't Enough for Production AI Agents

Tanmay Devare — Tue, 30 Jun 2026 05:25:07 +0000

TL;DR: Autonomous Agents frequently get trapped in execution loops, burning through API tokens and compute. Prompt engineering can't guarantee execution safety. I built MicroLoop, an open source runtime safety layer written in Rust, to intercept and verify every tool calling operation before it executes. Here is the architecture and why Rust was the only logical choice for modern AI infrastructure.

As AI Agents become more capable, they're being trusted with increasingly complex, multi-step workflows. They search the web, interact with APIs, execute code, query databases, and coordinate multiple tools to complete tasks.

But after building and deploying autonomous agents to production, I kept running into the same expensive problem.

The LLM wasn't failing because it lacked intelligence. It was failing because nobody was verifying what happened after the model decided to call a tool.

The Hidden Cost of Autonomous Agents

A typical AI agent architecture looks something like this:

[ User ] 
   │
   ▼
[ LLM ] ──(decides)──> [ Tool Call ]
                            │
                            ▼
                         [ Tool ]

Most popular frameworks assume that if the model decides to call a tool, the call should be executed blindly. In reality, agents often:

Call the same tool repeatedly with identical arguments.
Retry failed operations indefinitely.
Generate malformed JSON or invalid arguments.
Consume thousands of unnecessary tokens.
Get trapped in silent execution loops.

Consider a browser agent that encounters an unexpected CAPTCHA page. Instead of changing strategy, it may repeatedly execute open_page() in an infinite loop. Or a coding agent might continuously run pytest on a broken file.Nothing changes, but the agent continues spending time, tokens, and compute. These aren't model intelligence problems. They are runtime execution problems.

Why Prompt Engineering Fails at Runtime Safety

The most common solution to this is to add a system prompt
"You are an autonomous agent. Do not repeat tool calls. If a tool fails twice, change your strategy.Unfortunately, prompts aren't guarantees. They are suggestions."

A probabilistic model can still

Retry the same failing action.
Ignore previous failures due to context window degradation.
Produce malformed tool arguments.
Continue executing an unsafe trajectory.

As agents become more autonomous, relying solely on prompts becomes increasingly fragile. Runtime safety shouldn't depend entirely on model behavior.

Introducing MicroLoop: A Runtime Verification Layer
Instead of trying to make the model perfect**

I started asking a different question What if every tool call was cryptographically and logically verified before it executed? That's the idea behind MicroLoop.
MicroLoop is a lightweight runtime safety layer that sits directly between an AI agent and its tools. Rather than replacing existing frameworks, it acts as a transparent proxy alongside them.

[ Agent ]
    │
    ▼
[ MicroLoop ] ──(verifies)──> [ Allow / Block ]
    │
    ▼
[ Tool ]

Every single tool invocation is inspected in real-time before execution is permitted.

Under the Hood: How MicroLoop Works

Each tool call passes through a strict, low-latency verification pipeline

History Tracker: Detects repeated execution patterns (identical tool calls, repeated arguments, error loops, excessive retries). If a dangerous trajectory is detected, execution is blocked before the tool runs.
Rule Engine: Performs deep validation using JSON Schema, Regex rules, exact value matching, and per-tool execution policies.

This allows MicroLoop to enforce strict AI Agent Security and runtime policies without requiring you to rewrite your agent's core logic.

Why Rust?

Building High-Performance AI Infrastructure
Because verification happens synchronously before every tool call, latency is the enemy.If your safety layer adds 50ms of overhead per tool call, your agent becomes unusable.

This is why MicroLoop is written entirely in Rust with a lightweight no_std core, making it suitable for highly performance-sensitive environments and edge deployments.

Current Benchmarks:

~17 μs average verification time
~375 ns adversarial loop rejection
~58,000 verifications per second

To ensure it plays nicely with the broader Python-heavy AI ecosystem, the project exposes a C ABI. This allows seamless integration from virtually any language, with native Python adapters already available for LangChain, LangGraph, CrewAI, and AutoGen.

# Example: Wrapping a LangChain tool with MicroLoop
from microloop import Guardrail
from langchain.tools import tool

guard = Guardrail(policy="strict_loop_detection")

@tool
@guard.verify
def query_database(sql: str) -> str:
    """Executes a SQL query. MicroLoop intercepts repetitive calls."""
    return db.execute(sql)

Beyond Loop Detection The Future of AI Agent Security

Loop detection is only the first step in runtime safety. The same execution layer architecture is perfectly positioned to support

Prompt Injection Detection (analyzing tool outputs before they hit the context window)
Tool Permission Enforcement (RBAC for agents)
Dynamic Budget Limits (hard halts on token/compute spend)
Secret Protection (blocking PII or API keys from leaking into tool payloads)
Audit Logging & State Repair

As AI Agents transition from weekend demos to mission-critical production infrastructure, I believe runtime verification will become as fundamental as logging, authentication, and observability.

Final Thoughts
Prompt engineering tells an agent what it should do.
Runtime safety verifies what it is actually doing.
That's the gap I'm exploring with MicroLoop. The project is fully open source, and I'd love feedback from the community on the architecture, API design, and runtime approach.

👇 I'd love to hear from you: If you're building autonomous agents in production, how are you handling execution safety and infinite loops today? Let me know in the comments!

Devaretanmay / microloop

Microloop

A zero-dependency drop-in infinite loop detector for autonomous coding agents.

Microloop prevents autonomous AI agents from falling into infinite loops by intercepting redundant trajectories.

30-Second Quick Start

Microloop acts as a middleware. To use it as an upstream proxy in front of an LLM:

# 1. Start the proxy
cargo run --release --bin microloop-proxy

# 2. Point your agent to the proxy
export TARGET_API_URL="http://127.0.0.1:20128/v1"

Architecture

sequenceDiagram
    participant Agent as Autonomous Agent
    participant Microloop as Microloop Core
    participant LLM as LLM Provider
    
    Agent->>Microloop: Step 1: Tool Execution
    Microloop->>Microloop: Hash Trajectory State
    Microloop-->>Agent: Proceed (Unique state)
    Agent->>LLM: Generate next step
    
    Agent->>Microloop: Step 2: Identical Tool Execution
    Microloop->>Microloop: Hash Trajectory State
    Microloop-->>Agent: BLOCK (Loop Detected)
    Note over Agent: Agent is forced to pivot

Demonstration

(GIF Placeholder)

Installation

Microloop is a C-compatible shared library no_std core.

Rust

Add this to your Cargo.toml:

[dependencies]
microloop = "

…

View on GitHub

If you found this architectural breakdown helpful, consider leaving a ❤️ and following for more deep dives into AI infrastructure and Rust!

How to fix LangGraph GraphRecursionError without losing your checkpointed state

Tanmay Devare — Fri, 19 Jun 2026 17:47:59 +0000

We’ve all been there. You leave your LangGraph agent running overnight. It hits a 403 Forbidden on a scraping tool, or a REQUIRES_SINGLE_PART_NAMESPACE error on a SQL query.
Instead of failing gracefully, the agent asks the LLM for help. It gets stuck in a ReAct loop, burning through your API credits. Eventually, the native recursion_limit finally kills it.
But here is the worst part: the native recursion_limit is a blunt instrument.
When it hits the limit, LangGraph throws a GraphRecursionError. It crashes the run, wipes your checkpointed state, and returns a 500 error to your frontend user. You lose whatever partial data the agent did gather, and you get a surprise $4,000 API bill on Tuesday morning.
I spent the last month digging into why agents do this, especially with open-weight models (Qwen/Llama) that lack native self-correction. I realized that just throwing a raw RuntimeError or a "BLOCKED" string at an agent just confuses it, and it loops again.
Here is how we solved it using Pre-Model Intervention and Atomic Transcript Surgery.
The Architecture: Intercepting Before the Crash
Most guardrails wrap the entire graph or monkey-patch the HTTP client. This adds latency and breaks framework internals.
Instead, we use LangGraph’s native pre_model_hook and ToolNode APIs. This allows us to intercept the agent before the next LLM call, mutate the ephemeral prompt, and force a strategy pivot without corrupting the user's checkpointed state.
We call it the Progressive Intervention Protocol:
Nudge: Injects an ephemeral warning into the tool result.
Override: Safely strips the failing tool_calls from the prompt (preventing OpenAI/Anthropic 400 Bad Request validation errors) and forces a text-based strategy pivot.
Hard Stop: Halts the graph but preserves the checkpointed state so you get partial results instead of a crash.
The 1-Line Fix
We open-sourced this engine as TokenCircuit. It uses zero-dependency semantic shingling (stdlib regex + hashlib) to catch paraphrased loops at <20µs latency.
Here is how you wrap your LangGraph agent:

from langgraph.prebuilt import create_react_agent
from tokencircuit.adapters.langgraph import tc_pre_model_hook, TokenCircuitToolNode
from tokencircuit import TokenCircuitConfig

# 1. Configure the intervention engine
config = TokenCircuitConfig(
    max_repeats=3,
    window_size=3,
    telemetry_enabled=True, # Logs interventions locally or to Supabase
    agency_id="my-org",
    client_id="my-app"
)

# 2. Wrap your tools with TokenCircuit's transaction tracking
safe_tool_node = TokenCircuitToolNode(tools)

# 3. Inject the pre-model hook for transcript surgery
agent = create_react_agent(
    model,
    tools=safe_tool_node,
    pre_model_hook=tc_pre_model_hook(config=config, node_name="agent"),
)

# Run your agent exactly as before
result = agent.invoke({"messages": [HumanMessage(content="Get me the stock price for AAPL")]})

Why This Matters for Production
When you deploy autonomous agents for clients, you can't afford silent loop failures.
With TokenCircuit V8.1, we achieved zero core dependencies. We swapped pydantic for @dataclass(slots=True) and tiktoken for stdlib shingling. This means:
Zero supply-chain vulnerabilities.
<20µs overhead per turn.
100% local execution. No prompts or PII ever leave your RAM.
We also built a local CLI report generator. When an intervention happens, it logs to a local NDJSON file. You can run tokencircuit report --file events.json to generate a board-ready table showing exactly how many tokens and dollars your guardrail saved.
The Code is Open Source
If you are tired of watching your agents burn money on infinite loops, check out the repo.
GitHub: https://github.com/Devaretanmay/TokenCircut
PyPI: pip install "tokencircuit[langgraph]"
Question for the builders: What’s the most money an agent has burned for you in a single night? Drop your war stories in the comments. 👇