DEV Community: Cyril PODER

I gave Claude Code a project-management UI

Cyril PODER — Tue, 14 Apr 2026 22:33:53 +0000

When working with Claude Code, I sometimes end up with so many plans and tasks that I lost the track of what I was doing... Especially after a computer crash or an unsolicited reboot.
So I built orchestrAI — a Rust dashboard that puts a live Claude Code terminal in any browser with all my plans and tasks tightly organized. But not just that.

That's not a screen recording of a chat UI. It's a real xterm.js terminal connected to a real Claude Code session running on my workstation. I click a task, a Claude agent spawns on a dedicated git branch, I watch it work, I type at it, and when it's done I review the diff and merge — all from the browser.

The problem

Most AI coding tools assume you're at your dev machine. That makes sense — the code is there, the credentials are there, the context is there. But it means:

You can't hand off oversight. If an agent takes 20 minutes, you can't leave your desk without losing visibility.
You can't check on agents from another device.
Scaling beyond one agent at a time gets awkward fast — you're juggling tmux panes or editor windows.

What I actually wanted was something like Linear or Jira, except:

Assignees are AI agents
Status updates come from the code and from git, not from someone typing them
"Complete a task" means: spawn an agent on a branch, watch it, review the diff, merge

What it does

Interactive agent sessions from any browser. Each task has a Start button. Click it and a Claude Code agent spawns on a dedicated orchestrai/<plan>/<task> git branch. You get a full xterm.js terminal — type at it, watch tool calls in real time, scroll back through the whole conversation.

Persistent across server restarts. Each agent runs inside a detached supervisor daemon that owns the PTY. Kill the dashboard server, restart it, the agent is still working and the terminal reattaches. No tmux required (more on that below).

Git-isolated changes with review before merge. Nothing lands on your working branch until you click Merge. The task card shows a diff tab, the branch name, and a merge banner once the agent reports done.

Plans as YAML, not parsed markdown. Each plan lives in ~/.claude/plans/*.yaml with phases, tasks, dependencies, file paths, acceptance criteria. Inline-editable from the UI. When you click "New Plan" and describe what you want, an agent turns your description into structured YAML.

Cost tracking. Per-agent USD reported by the CLI, aggregated per task and per plan. Budget limits per task.

"Is this actually done?" agents. Every task has a Check button that spawns a read-only agent to verify the code meets the acceptance criteria. No heuristics, no "the file exists so it must be done" — a real AI reads the diff and replies with a verdict.

A bit of architecture

It ships as a single ~15 MB Rust binary. No Node, no Docker, no daemon to install separately. The frontend (React + Vite + xterm.js) is embedded via rust-embed.

The interesting part was replacing tmux. My first version used tmux for session persistence — it works on Linux and macOS, but it's not available on Windows, and requiring users to install it separately was friction.

So I built a mini-supervisor: ~300 lines of Rust that forks into a detached daemon (fork + setsid on Unix, DETACHED_PROCESS on Windows) and owns one PTY per agent via the portable-pty crate. The daemon exposes the session over a Unix domain socket on Linux/macOS or a named pipe on Windows, using the interprocess crate. The dashboard server talks to the daemon over that socket. PTY output is mirrored to a log file so reconnecting clients get the full transcript.

Same persistence story as tmux, cross-platform, no external binary required.

Try it

Requires Rust 1.85+, Node.js 20+, pnpm, and Claude Code authenticated on the host machine. Git for branch isolation — orchestrAI auto-inits repos that don't have one. Or just download and run from the latest releases, available for Mac, Linux and Windows.

# build
pnpm --filter @orchestrai/web build
cd server-rs && cargo build --release

# run
./target/release/orchestrai-server
# open http://<host>:3100 in any browser on your network

Repo and full docs: github.com/cpoder/orchestrAI

What's next

Three things I'm working on:

Multi-AI via a driver abstraction. An AgentDriver trait lets me ship drivers for Aider, Codex CLI, and Gemini CLI alongside Claude Code. Binary name, prompt format, auth detection, and cost parsing are all per-driver. So you can run an Aider agent for one task and a Claude agent for another, from the same dashboard.

MCP server. Instead of agents running curl -X PUT .../status to report back to the dashboard, they'll use proper Model Context Protocol tools like update_task_status and get_task_context. The dashboard exposes itself as an MCP server, and spawned agents get it wired in automatically.

Remote runners for SaaS. The hosted version can't run agents directly — that requires the customer's code and credentials. So there's a lightweight agent-runner binary that runs on the customer's machine, connects to the SaaS over an authenticated WebSocket, and executes agents there. Outbox + ACK pattern for reliability across reconnects, no broker needed.

If you've tried running Claude Code at scale — or just want to watch an agent work from your phone while you're getting coffee — I'd love feedback. Issues and PRs welcome.

How to Prevent Your AI Agent from Burning $50 in a Loop

Cyril PODER — Fri, 20 Mar 2026 10:51:12 +0000

If you've built AI agents with LangChain, MCP, or the OpenAI Agents SDK, you've probably had this experience: your agent works great 90% of the time. The other 10%, it goes haywire — retrying the same failing API call endlessly, stuck in a reasoning loop, or burning through API credits with increasingly verbose prompts.

The scary part? Each individual step looks perfectly reasonable. It's only when you look at the sequence over time that the problem becomes obvious.

The Problem: Temporal Blindness

Current tools for AI agent reliability fall into two categories:

Observability tools (LangSmith, Braintrust, Langfuse) show you beautiful traces and dashboards — after the damage is done. By the time you see the trace of your agent calling the same API 47 times, you've already burned $50.

Static guardrails (Guardrails AI, NeMo Guardrails) validate individual inputs and outputs. They can catch PII in prompts or malformed JSON in responses. But they can't detect patterns over time — they see each step in isolation.

Without something better, the typical fix is a hardcoded max_iterations=10 and a prayer.

What's missing is real-time detection of behavioral patterns: sequences of agent actions that indicate something has gone wrong.

Six Failure Modes You've Probably Seen

Pattern	What Happens	Real-World Example
Retry Storm	Same tool call with identical params, over and over	Agent keeps searching for "weather in paris" because the API returns an error and the LLM regenerates the same call
Circular Reasoning	Agent alternates between tools without progressing	search → read_file → search → read_file, forever
Budget Runaway	Cumulative token/cost spend spirals	Agent generates increasingly long prompts trying to "think harder"
Error Spiral	Tool error → reformulate → tool error → reformulate	API is down, agent tries different formulations but they all fail
Stuck Agent	Many steps without producing output	30 rounds of "let me think about this" without an answer
Token Velocity Spike	Sudden increase in tokens per step	Agent switches from efficient queries to dumping entire documents into context

The Solution: Regex for Event Streams

We built Varpulis Agent Runtime, an open-source library that detects these patterns in real-time. Think of it as regex for event streams, applied to AI agent behavior.

The runtime is built on the Varpulis CEP engine — an NFA-based pattern matching engine with Kleene closure support, written in Rust. It compiles to WASM for JavaScript or a native Python extension via PyO3. Runs in-process with sub-millisecond latency — no network calls, no infrastructure. ~1MB WASM bundle.

Each behavioral pattern is a Kleene closure expression — the + operator matches one or more repetitions:

retry_storm:         same_tool_call{3+} within 10s
error_spiral:        tool_error{3+} within 30s
stuck_agent:         step{no_output}{15+}, reset on final_answer
circular_reasoning:  A → B → A → B (cross-event name matching)
budget_runaway:      llm_call{+} within 60s where sum(cost) > threshold

The Kleene closure is backed by Zero-suppressed Decision Diagrams (ZDD) to avoid exponential blowup. When 20 events match a Kleene pattern, there are naively 2^20 (~1M) possible combinations. The ZDD represents all of them in ~100 nodes — not 1M explicit states.

It Caught Itself: Self-Correcting Agents

We didn't just build a monitoring library — we built a feedback loop.

We wired Varpulis into Claude Code (Anthropic's CLI agent) using its native HTTP hook system. The monitor runs as a tiny Flask daemon, receives every tool call, feeds them through the CEP engine, and injects detections back into the agent's context.

The setup is three lines of config:

{
  "hooks": {
    "PreToolUse": [{ "hooks": [{ "type": "http", "url": "http://localhost:7890/event" }] }],
    "PostToolUse": [{ "hooks": [{ "type": "http", "url": "http://localhost:7890/event" }] }]
  }
}

When a pattern fires, the monitor returns additionalContext in the hook response — and the agent receives it as guidance on its next turn. For kill-level detections, it returns permissionDecision: "deny" which blocks the tool call entirely.

And it caught a real pattern during its own development. The CEP engine detected:

[WARNING] circular_reasoning: Circular pattern: Edit → Bash → Edit → Bash
Suggestion: You are alternating between the same tools in a loop. Break the cycle by trying a completely different approach.

The agent was in an edit-restart-edit-restart cycle — a legitimate development workflow, but the engine correctly identified the repeating sequence. In a production scenario with a misbehaving agent, this same detection would break the loop and redirect the agent before it wastes time and money.

This is the real promise: agents that monitor their own behavior and self-correct in real-time. The Claude Code monitor example includes the full setup with a live web dashboard.

Integration in 10 Lines

Python

pip install varpulis-agent-runtime

from varpulis_agent_runtime import VarpulisAgentRuntime, Patterns

runtime = VarpulisAgentRuntime(patterns=[
    Patterns.retry_storm(min_repetitions=3, kill_threshold=5),
    Patterns.budget_runaway(max_cost_usd=0.50),
    Patterns.stuck_agent(max_steps_without_output=10),
])

@runtime.on("budget_runaway")
def handle(detection):
    if detection["action"] == "kill":
        raise SystemExit("Budget exceeded")

JavaScript/TypeScript

npm install @varpulis/agent-runtime

import { VarpulisAgentRuntime, Patterns } from '@varpulis/agent-runtime';
import { WasmAgentRuntime } from '@varpulis/agent-runtime/wasm';

const wasm = new WasmAgentRuntime();
const runtime = new VarpulisAgentRuntime(wasm, {
  patterns: [
    Patterns.retryStorm({ min_repetitions: 3, kill_threshold: 5 }),
    Patterns.budgetRunaway({ max_cost_usd: 0.50 }),
    Patterns.stuckAgent({ max_steps_without_output: 10 }),
  ],
});

runtime.on('budget_runaway', (d) => {
  if (d.action === 'kill') {
    console.error('Budget exceeded — stopping agent');
    process.exit(1);
  }
});

LangChain

from varpulis_agent_runtime.integrations.langchain import VarpulisCallbackHandler

handler = VarpulisCallbackHandler(runtime)
agent.invoke({"input": "..."}, config={"callbacks": [handler]})

The handler translates LangChain events into Varpulis events automatically. When a kill-worthy detection fires, it throws VarpulisKillError to stop the agent.

Custom VPL Patterns

The built-in patterns ship as .vpl files — readable, auditable, forkable. You can also add your own at runtime:

runtime.add_patterns_from_vpl("""
    pattern GoalDrift = SEQ(
        ToolCall as first,
        ToolCall+ where name != first.name as drift
    ) within 60s
""")

VPL (Varpulis Pattern Language) is a declarative language for event patterns. The parser compiles VPL into NFA-based matchers at runtime — no code generation, no build step.

What's Next

We're building this in the open at github.com/varpulis/varpulis-agent-runtime. The library is Apache 2.0 licensed and has 103 tests including Playwright e2e tests that run the full engine in a real Chromium browser.

We'd love to hear which failure modes matter most to you and what patterns are missing. Open an issue or drop by the repo.

Why Does Detecting A -> B+ -> C Still Take 40 Lines of Code?

Cyril PODER — Wed, 04 Mar 2026 11:05:23 +0000

Complex Event Processing has a dirty secret: detecting a simple sequence like "transaction opens, processes through multiple steps, then closes" requires absurd amounts of boilerplate in most engines. Let's compare.

The problem: match `A → B+ → C` and compute aggregates over the run

A common pattern in transaction monitoring: detect a transaction that opens, goes through one or more processing steps, and closes — then compute statistics across those steps.

Simple enough, right?

Apama (MonitorScript)

The classic approach uses nested on listeners in a monitor:

monitor TransactionMonitor {
    action onload() {
        on all TransactionOpen() as open {
            sequence<ProcessingStep> steps := new sequence<ProcessingStep>;

            on all ProcessingStep(tx_id=open.tx_id) as step
                and not TransactionClose(tx_id=open.tx_id) {
                steps.append(step);
            }

            on TransactionClose(tx_id=open.tx_id) as close {
                float totalDuration := 0.0;
                integer maxErrors := 0;
                float totalThroughput := 0.0;

                ProcessingStep s;
                for s in steps {
                    totalDuration := totalDuration + s.duration;
                    if s.error_count > maxErrors {
                        maxErrors := s.error_count;
                    }
                    totalThroughput := totalThroughput + s.throughput;
                }

                float avgDuration := totalDuration / steps.size().toFloat();

                emit TransactionSummary(
                    open.tx_id, avgDuration, maxErrors,
                    totalThroughput, steps.size()
                );
            }
        }
    }
}

Three nested on blocks. Manual accumulation. Manual aggregation. And if you forget the and not guard on the middle listener, you get duplicate matches.

Apama does have a more declarative paradigm — stream queries with from clauses support windowed aggregation, joins, and partitioning. But stream queries operate on individual streams with retention windows. They have no sequence operator and no Kleene closure. You simply cannot express "A then B+ then C" in a from query. For sequential patterns with accumulation, the nested on listener approach above is what you're stuck with.

Esper (EPL)

@Name('TransactionStats')
insert into TransactionSummary
select
    open.tx_id as tx_id,
    avg(steps.duration) as avg_duration,
    max(steps.error_count) as max_error_count,
    sum(steps.throughput) as total_throughput,
    count(steps) as step_count
from pattern [
    every open=TransactionOpen
    -> steps=ProcessingStep(tx_id=open.tx_id) until TransactionClose(tx_id=open.tx_id)
]
group by open.tx_id;

Better. Esper's until operator handles the Kleene-like repetition. The collected events are materialized as indexed properties — steps[0], steps[1], etc. — and aggregation functions operate over that array. The every keyword placement matters more than you'd think: move it inside the pattern and the semantics change silently.

Flink CEP

Pattern<Event, ?> pattern = Pattern.<Event>begin("open")
    .subtype(TransactionOpen.class)
    .followedBy("steps")
    .subtype(ProcessingStep.class)
    .oneOrMore()
    .greedy()
    .until(new SimpleCondition<Event>() {
        public boolean filter(Event e) {
            return e instanceof TransactionClose;
        }
    })
    .followedBy("close")
    .subtype(TransactionClose.class);

CEP.pattern(stream, pattern)
    .select(new PatternSelectFunction<Event, TransactionSummary>() {
        public TransactionSummary select(Map<String, List<Event>> pattern) {
            TransactionOpen open = (TransactionOpen) pattern.get("open").get(0);
            List<Event> steps = pattern.get("steps");

            double avgDur = steps.stream()
                .mapToDouble(e -> ((ProcessingStep) e).getDuration())
                .average().orElse(0);
            int maxErr = steps.stream()
                .mapToInt(e -> ((ProcessingStep) e).getErrorCount())
                .max().orElse(0);
            double totalTput = steps.stream()
                .mapToDouble(e -> ((ProcessingStep) e).getThroughput())
                .sum();

            return new TransactionSummary(
                open.getTxId(), avgDur, maxErr, totalTput, steps.size()
            );
        }
    });

The fluent API is verbose but readable. The real cost is the PatternSelectFunction: you're back to manual aggregation over a Map<String, List<Event>> with type casting everywhere. And this doesn't even include the KeyedStream partitioning boilerplate.

Varpulis

stream TransactionStats = TransactionOpen as open
    -> all ProcessingStep as steps
    -> TransactionClose as close
    .within(30m)
    .partition_by(tx_id)
    .trend_aggregate(
        avg_dur:    avg_trends(steps.duration),
        max_errors: max_trends(steps.error_count),
        total_tput: sum_trends(steps.throughput),
        step_count: count_events(steps)
    )
    .emit(
        event_type: "TransactionSummary",
        tx_id: open.tx_id,
        avg_duration: avg_dur,
        max_error_count: max_errors,
        total_throughput: total_tput,
        steps: step_count
    )

The pattern is the query. -> is sequence. all is the Kleene closure — one or more repetitions of ProcessingStep. The VPL compiler translates this into a SASE+ automaton with Kleene closure states, and .trend_aggregate() computes statistics directly over all matching trends using the Hamlet algorithm — O(n) per event instead of enumerating every possible subsequence.

No callbacks. No manual accumulation. No type casting. The engine handles partitioning, windowing, and aggregation as part of the pattern itself.

What about just detection?

Sometimes you don't need aggregates — you just want to catch slow steps inside a transaction. Here's the same pattern in Varpulis, this time as a simple SASE+ detection query:

stream SlowTransactionStep = TransactionOpen as open
    -> all ProcessingStep where duration > 5000.0 as slow_step
    .within(30m)
    .partition_by(tx_id)
    .emit(
        event_type: "SlowStepAlert",
        tx_id: open.tx_id,
        step_name: slow_step.step_name,
        duration: slow_step.duration
    )

Two lines of pattern plus a window constraint, and you get an alert the instant a slow step occurs — no need to wait for the transaction to close. Try that in a PatternSelectFunction.

The 2^n problem that nobody talks about

There's a deeper issue with Kleene closures that syntax alone doesn't solve. When you match A → B+ → C and 10 events match B, there are 2^10 - 1 = 1,023 possible trend combinations. With 20 events, that's over a million. With 30, over a billion.

This isn't a theoretical concern — it's an operational one, though it manifests differently in each engine. Esper's until operator collects matched events into an in-memory array. The array itself is O(n), but for long-running patterns with hundreds of intermediate steps, the accumulation keeps growing until the terminator arrives or the window expires — and there's no backpressure mechanism to limit it. Flink CEP buffers matched events in its SharedBuffer keyed state backend. The buffer stores individual events with versioned links for concurrent partial matches. Under high cardinality — many concurrent transactions with many steps each — state size grows with every new partial match, leading to checkpoint failures, back-pressure cascades, and ultimately OOM kills. Apama's approach of manually collecting events into a sequence<> has the same linear accumulation problem, and since the correlator processes events single-threaded within each context partition, one runaway pattern can starve other monitors.

The exponential blowup hits when you need aggregates over Kleene matches. If you want "average duration across all possible subsequences of B events," you're asking about 2^n combinations. Most engines don't even attempt this — they either aggregate over the flat event list (ignoring subsequence semantics) or force you to enumerate matches yourself. Most production deployments work around it by keeping Kleene windows short, limiting the number of intermediate events, or simply avoiding Kleene closures altogether. That's not a solution — that's giving up on the expressiveness that CEP was supposed to provide.

Varpulis tackles this at the engine level with two complementary approaches, chosen automatically at compile time based on the query:

Detection mode (SASE+ with ZDD) — When you need the actual matches, like in the SlowTransactionStep example, the engine uses Zero-suppressed Decision Diagrams (ZDD) to represent all 2^n match combinations as a compact boolean function. The full match space is encoded in O(poly(n)) nodes through structure sharing, rather than allocating memory for each combination individually.

Aggregation mode (Hamlet) — When you only need statistics over the matches, like in TransactionStats, the engine doesn't enumerate trends at all. Hamlet computes aggregates — count, sum, avg, max, min — directly in O(n) per event using propagation coefficients. It answers "what's the average duration across all possible trends?" without ever building the match set.

The engine picks the right strategy automatically. If your query has .trend_aggregate(), it uses Hamlet. If not, it uses SASE+ with ZDD. Same -> all Kleene pattern, different execution path — zero configuration from the developer.

Mode	Engine	What it does	Complexity
Detection	SASE+ with ZDD	Represents all Kleene matches compactly	2^n matches in O(poly(n)) memory
Aggregation	Hamlet	Computes aggregates without enumerating	O(n) per event — skips the match set entirely

This is the kind of optimization that's invisible in the query language but makes the difference between "works on a demo" and "works on a million events per second." A transaction with 50 processing steps produces 2^50 — over a quadrillion — possible trends. Hamlet computes the aggregate in 50 operations.

Beyond detection: forecasting

Varpulis also supports something none of the engines above offer natively — pattern forecasting. By appending .forecast() to a sequence pattern, the engine builds a Prediction Suffix Tree (PST) online and predicts the probability and expected time of pattern completion before the full sequence has been observed:

stream FraudForecast = Login as login
    -> all Transaction where amount > 10000 as tx
    -> Withdrawal as withdrawal
    .within(1h)
    .forecast(confidence: 0.7, horizon: 5m, warmup: 500)
    .where(forecast_probability > 0.85)
    .emit(
        event_type: "FraudWarning",
        user_id: login.user_id,
        probability: forecast_probability,
        expected_time: forecast_time
    )

The PST learns transition patterns incrementally — no pre-training, no batch step. After the warmup period, it starts emitting ForecastResult events with probability estimates and expected completion times that flow through the normal .where() / .emit() pipeline.

Why this matters

CEP is not a new problem. SASE was published in 2006. Kleene closures over event streams have been well-understood for almost two decades. Yet most production engines still force developers to express these patterns through nested callbacks, manual state management, or verbose APIs that obscure the intent.

Worse, most engines split event processing into two disconnected worlds: stream queries for windowed aggregation, and pattern listeners for sequence detection. In Apama, you can't use a Kleene closure in a from query. In Flink, stream processing and CEP are separate APIs. This means developers end up stitching two paradigms together for problems that are fundamentally one thing.

Varpulis doesn't make that distinction. Sequential patterns, Kleene closures, trend aggregations, joins (join, left_join, right_join, full_join, merge) — it's all the same stream construct. The pattern is the query. The engine picks the execution strategy.

Varpulis is open-source, built in Rust, and early-stage — but the pattern language is stable.

GitHub: github.com/varpulis/varpulis

Feedback, stars, and issues welcome.