DEV Community: Don Karter

Waiting Is Not a Tool Call: Making an MCP Server's Shell Event-Driven

Don Karter — Wed, 02 Sep 2026 12:37:56 +0000

One of our agents ran a test suite. The suite takes four minutes. The MCP client's idle timeout is sixty seconds.

You can see where this is going. At second sixty the client cancelled the call. The process kept running — nobody told it to stop — while the model, holding a cancellation where its test results should be, did the reasonable thing and ran the suite again. Two test suites, same directory, racing each other over the same build artifacts. The second one failed with a locking error, the model reported the tests as broken, and the tests were fine.

In another session the same model, burned before, developed a workaround: run the build, then call sleep 240, then look. A tool call that does nothing, held open for four minutes, so that a different tool call might have something to show. The model had reinvented polling, badly, because we hadn't given it anything better.

I build octofs, an open-source MCP filesystem server, and this incident set the agenda for eleven releases in two weeks (0.10.1 through 0.14.1). The principle behind them is one I keep coming back to: an MCP server's real interface is every string it hands back to the model. These releases apply it to the slowest string of all — the one the model waits for. The shell is now event-driven. Commands start in the foreground, move to the background on their own if they outlast ten seconds, and the client gets a notification when they finish. Nothing blocks, nothing gets killed, nothing runs twice.

First fix: prove the call is alive

The sixty-second cancellation had a shallow cause and a deep one. The shallow one: a shell call is silent by nature. A build that's compiling says nothing on the wire for minutes, and to an MCP client silence is indistinguishable from a hung server. So 0.10.2 added liveness heartbeats — while a command runs in the foreground, octofs emits a progress notification every ten seconds, well below any sane idle timeout, so a single missed beat can't cancel the call.

That stopped the killings. It did not touch the deep problem: the call still blocked. A four-minute test suite still cost four minutes of session time in which the model could do nothing — not read the failing file, not prepare the next edit, not think. Heartbeats make waiting survivable. They don't make it useful.

Second fix: background jobs — and the flag we had to delete

0.11.0 introduced background execution: run a command as a job, get a handle back immediately, collect the output later. Each job is an MCP resource with a URI like octofs://jobs/17342-1, readable at any time for its status and output.

It shipped with a background flag on the shell tool, and that flag was a mistake we recognize in hindsight as a familiar one. In 0.9.0 we deleted a --line-mode switch because safety that ships behind a flag is safety most people never turn on. The background flag was the same bug in a different costume: it asked the model to predict the duration of a command before running it. Models are bad at this in exactly the way you'd expect — cargo build is instant on a warm cache and takes six minutes cold, and the flag turned that unknowable fact into a required decision. Guess background for a fast command and you've added a pointless round trip. Guess foreground for a slow one and you're back to the blocked call we started with.

So 0.13.0 deleted the flag and replaced the prediction with a measurement. Every command starts in the foreground. If it's still running at ten seconds, it is automatically promoted to a background job — the same process, not killed, not restarted. Output capture is durable from the first byte, so crossing the deadline loses nothing: whatever the command printed in its foreground life is sitting in the job's log when you read it later.

The tool call returns immediately at promotion, with a resource link carrying the command as its name — so a client can render "make test … still running" without re-deriving what the job was, even after a context compaction. When the process exits, octofs emits notifications/resources/updated for the job's URI. The client reads the resource once and gets the exit code and the output tail. No polling, no held-open call, no orphaned process.

Two details in that flow earned their place the hard way:

The tail, not the head. A resource read returns at most the last 30 KB of output. Build logs run long, and the verdict — the error, the final test summary — lives at the end. Feeding a model the first 30 KB of a log whose last line says FAILED is how you get a confident report that everything passed.

Two delivery paths. Clients on the 2026-07-28 MCP revision that opened a subscription stream get the completion on it; older clients get the unsolicited push the earlier spec allowed. And since 0.13.0, a client that subscribes late — after the job already exited — gets the completion replayed instead of waiting forever on a notification that fired before anyone was listening.

The foreground window also shrank from thirty seconds to ten in 0.13.0, and that's the auto-promotion paying for itself: when crossing the boundary costs nothing — same process, durable output, a notification at the end — there's no reason to hold the session hostage for half a minute just in case the command finishes at second twenty-five.

Third fix: let jobs run next to each other

0.11.0 was conservative: one job per directory, full stop. Safe, and too blunt — it serialized a build and a log tail that had no business waiting on each other.

0.14.0 narrowed the guard to the one case that's actually a bug: the identical command already running in the same directory. That's not concurrency, that's the double-fired test suite from the opening story, and instead of racing it, octofs rejects it and tells the model precisely what to do:

The same shell command is already running as background job
octofs://jobs/17342-1 (`cargo test`). Wait for its completion — you will
get a resources/updated notification with its output — instead of
starting a duplicate. Independent commands may run concurrently in this
directory.

Distinct commands run side by side. The duplicate gets an error that is, once again, the recovery instruction.

A hard line under all of it

With the server doing the waiting, a model burning a tool call on sleep 240 stopped being a clever workaround and became pure waste. So 0.10.4 added it to the shell misuse list, next to watch and top:

Waiting with a bare `sleep` is forbidden — it burns the whole tool call
doing nothing.

  To wait for a condition, poll it in a loop (sleep inside a loop body
  is allowed):
    until <check>; do sleep 2; done
  To wait for a command you started, run it normally; long-running
  commands automatically move to the background and notify you when
  they finish.

Same policy as 0.9.0's grep rejection: don't hint, fail — and put the correct move in the error. Octofs rejects a bare sleep; a sleep inside an until loop is a legitimate condition poll and passes. watch and top get rejected because they never exit, which in an event-driven shell means they'd hold a promotion slot forever and never deliver a completion.

Fewer places to hallucinate

Around the shell work, five smaller releases kept pulling the 0.9.0 thread — closing gaps where a model could mistake silence or ambiguity for information.

Empty search results say so out loud. A model handed an empty string doesn't reliably conclude "no matches." Sometimes it concludes "the tool failed" and retries; sometimes, worse, it fills the silence with what it expected to find and proceeds as if it had. So the no-match case is a sentence stating what was searched and that zero matches exist.

Tool schemas dropped their null variants (0.10.3). Optional-as-nullable in a JSON schema reads fine to a human and is an attractive nuisance to a model — "path": null is a call that validates nowhere good. Optional now means absent.

Stale line IDs report better (0.10.5). Listing and search got faster (0.10.1) — newline counting on raw bytes, file types from the directory walker, a whole-buffer prefilter. Latency in a tool the model calls hundreds of times per session is a tax on everything.

The remote box, without ceremony

Octofs has spoken SSH/SFTP since 0.8.0 — point a tool at ssh://user@host/path and the agent gets the same verified filesystem on a remote machine. 0.14.0 resolves targets through ~/.ssh/config. Host aliases, a ProxyJump bastion, IdentityFile, IdentityAgent, per-host users and ports — the configuration you already wrote for your own fingers now applies to the agent's connections. The test is simple: if plain ssh box works in your terminal, ssh://box/path works in octofs, bastion and all. (One hop, honestly: we reject multi-hop ProxyJump chains and ProxyCommand with a clear error rather than half-supporting them.)

0.14.1 made misuse detection read inside ssh commands. The grep-rejection story had a remote-shaped hole: ssh box 'grep -r TODO src/' sailed past a detector that respected quotes too politely to look inside them. It now parses the remote command through SSH's options and nesting and applies the same rules. Pipelines stay allowed, interactive SSH stays untouched.

What this means for your MCP server

If you build MCP tools, the takeaways transfer directly:

A blocked tool call is a liability, not a wait. Return a handle and notify on completion.
Don't make the model predict durations — measure them. Auto-promotion beat a flag.
Errors should contain the recovery instruction, not just the failure.
Silence is ambiguous — say "nothing found" out loud.
Safety behind a flag is safety nobody turns on. Delete the flag and make the right behavior the only behavior.

Nothing in octofs depends on our agent runtime, by the way. The job resources, the links, the notifications are all plain MCP — any client that follows the protocol gets the event-driven shell for free.

Try it

# Homebrew
brew upgrade muvon/tap/octofs

# Cargo
cargo install octofs --version 0.14.1

# npm
npm install -g @muvon/octofs

No config changes required. One behavioral note: if your prompts or client code passed a background flag to the shell tool, remove it — the flag is gone and promotion is automatic.

Octofs is open source (Apache 2.0) at github.com/Muvon/octofs. The full write-up lives on the Muvon blog: Waiting Is Not a Tool Call.

Most tools strip your image and answer anyway. I built mine to refuse.

Don Karter — Tue, 01 Sep 2026 08:24:13 +0000

Attach an image to a model that can't see.

The industry-standard behavior is to remove it and answer anyway. You get a confident reply to a question the model never received.

I hate that. So octomind refuses instead. By name. Before the machine wakes and before anything is charged.

That's the whole stance behind what I just shipped: images and voice, live. Attach or paste a screenshot and the agent looks at it. Hold the mic and talk instead of typing. Send a photo or a voice note from Telegram, Slack, or WhatsApp and it lands in the same session your browser has open.

Nothing gets silently dropped

This is the part I care most about. Because it's where every other product fails.

If your model can't see, the attach button is already disabled. The tooltip names one that works.

If your machine is running an older image that predates attachments, the turn is refused too. Never sent and hoped for. Because an older agent would accept the frame, drop the picture, and reply as though nothing were missing.

Your upload stays valid through all of it. So retrying after a model switch never costs a second upload.

Refusing feels harsh. Silently dropping feels fine, right up until you're acting on an answer to a question that was never asked. I'd rather be the tool that says no up front.

Same session, same machine

Nothing here is a separate mode. That's the point.

A screenshot pasted at your desk at 09:14 and a voice note sent from your phone at 12:40 are the same session. On the same machine. With the same files. Open the tab again at six and all of it is still there.

Not a phone app that syncs to a web app that syncs to a bot. One session. One machine.

Voice you can fix before it sends

Speak, and the words arrive in the composer as text you can still edit. Nothing sends until you press send.

Transcription is very good and not perfect. The failure mode of auto-send is that a misheard word becomes an instruction. So I put guards in:

Recording stops itself after 15 seconds of silence.
It hard-stops at two minutes.
A recording that comes out shorter than three words never wakes a machine.

You talk. You read it back. You fix it. Then it goes.

Replies can talk back

Replies can come back spoken in Telegram and WhatsApp, where a voice message is a real thing you can play with the phone in your pocket.

I don't read markdown out loud. A fenced block is announced as "a 12-line code block," not as a mouthful of backticks.

Spoken replies are off until you switch them on in Settings. And the text always comes too. Never instead.

What it costs

Images are on every plan, at no extra cost. No per-attachment charge. No storage charge. The disk is already part of your machine. Images cap at 5 MB, audio at 8 MB, four attachments to a message.

Voice is on paid plans. $0.010 a minute to listen. $0.025 a minute to speak. On top of the model, in the same spend view as everything else.

Routines from your chat apps

/routines now lists your routines, runs one immediately, pauses and resumes — from Telegram, Slack, or WhatsApp.

Completed runs deliver the full report into the chat rather than a bare "done." Long output is clamped to fit the platform instead of cut at a byte boundary. Times render in the routine's own timezone, not ours.

Each routine carries its own notification preference now. So an hourly check and a weekly report don't have to shout equally.

Machines are on octomind 0.47.0

0.46 was a deletion release. Verifier recovery tracking and mutation outcome contracts in. A net −1,884 lines of supervisor surface out. The benchmark said those mechanics weren't paying for themselves, so they went.

0.47 is the release that carries attachments on the wire.

Config format moves 5 → 7 → 8 across the two. The CLI migrates an existing machine's config on first run. There's nothing for you to edit.

New machines are on 0.47.0 now. Existing ones pick it up on their next rebuild, with files, sessions, and settings untouched. Voice doesn't wait on the upgrade at all. Transcription runs on my side, so the machine only ever receives text.

Fixed

A routine whose turn never started could settle early and report a run that hadn't happened. Endpoint routing also tightened how it validates domains.

The part I want argued

The refusal thing is the hill I'll die on. Every tool that strips your image and answers anyway is training you to distrust it. You can't tell it dropped anything. You just get a smooth, confident, wrong-shaped reply.

Refusing by name costs me a little friction up front. It buys you the one thing a silent drop never can: knowing your input actually arrived.

Full write-up: https://octomind.run/blog/images-and-voice

The 11-Day Silence: What Scheduled Agents Taught Me About Building Routines That Don't Die

Don Karter — Fri, 28 Aug 2026 06:23:32 +0000

There is a specific kind of disappointment that comes from scheduled agents, and it always arrives the same way. You set one up. It works when you test it. Three weeks later you notice it hasn't done anything in eleven days, and there's nowhere to look to find out why.

That experience — the eleven-day silence — is why I built Routines into Octomind the way I did.

What Actually Shipped

A routine is a standing instruction with a trigger attached. Pick an agent, pick when, and it wakes a computer in the cloud, does the work, and tells you what came of it. Nothing of yours has to be switched on.

That's the elevator pitch. The engineering reality is messier, because scheduled systems have four failure modes documented in the original post.

The Four Ways Scheduled Agents Fail

1. It didn't run and nobody said so. The config file says what should run and has no opinion about what is running. Claude Cowork has an open issue where tasks skip on a timezone offset and simply don't appear. You don't know it failed. You just notice the silence.

2. It ran, spent money, produced nothing. Silent failure. No crash, no signal, just a charge. Telerik has a taxonomy of agents returning status: ok having done nothing useful. Your credit card gets charged. Your problem stays unsolved.

3. Cost runs away. An agent loop costs roughly 3.2× a chatbot turn at five steps and over 30× at fifty, and a polling schedule pays full price on every run where nothing happened. Context accumulation is the dominant cost driver, and it compounds silently.

4. Time is the only trigger. If something breaks at 15:00 and your check runs at 23:00, you find out at 23:00. You're at the mercy of the schedule you set.

Routines is designed to fail differently.

Scheduling Is a Sentence You Complete

The scheduling UX is a sentence you complete: "Every weekday at eight." There's a cron option with plain-English readback, because the failure mode of a cron field is not rejection, it's silently scheduling something else.

Times are stored with an IANA timezone, never an offset, and the next fire is recomputed after each run rather than incremented. That is the whole reason daylight saving doesn't drift: a local time that doesn't exist in spring fires at the next real instant, and a local time that happens twice in autumn fires once, on the first. Both are pinned by tests with fixed clocks.

Pick Who Does It

Routines run as specialist agents — same roster as tasks. Assistant picks if you don't want to choose. The point is: you know what's running your job.

Every Non-Run Is a Row

This matters more than it sounds. Refusals — routine off, out of budget, cold storage, previous run still going — become run rows with status. "Didn't run — machine was in cold storage." "Hit its cost cap."

Header totals show: "7 runs · $0.63 · typically 3m 8s". It's a heartbeat list view, one tick per run coloured by outcome. And after five consecutive failures, a routine disables itself and tells you, because a broken routine must not bill forever.

Silence is the bug we're building against.

Cost Controls That Actually Work

Fresh conversation each run by default. There's a checkbox for long conversation labelled honestly: "keeps context between runs, costs more over time". No marketing spin, just the truth.

Optional zero-token check command — shell runs first, non-zero exit = "nothing to do" with no model call:

git fetch && git log --oneline @..@{u} | grep .

We deliberately did not make this a natural-language condition: an LLM condition costs a model call to decide whether to make model calls. That's backwards.

Per-run cost cap. Always.

State Is a File, Not a Black Box

~/routines// with state.md. Read state.md before you start, write what the next run needs to know before you finish. Persistent disk, openable in Files or terminal, edit to correct memory, delete to reset.

State is a file, not a vendor black box. You can touch it. You can fix it.

Run It Now

There's a button that fires the real queue, the real runner, the real billing lane. Not a preview. A routine you have never watched run is a routine you cannot trust.

Machine Sleep

Free machines suspend after 5 idle minutes, Pro after 15. Your computer sleeps, costs nothing, and gets up when the routine says so. Wake goes through the same admission door; refusal = visible skip with reason, never an overdraft. Machines with enabled routines are exempt from cold storage.

/schedule vs Routines

Agent-internal timers die with the session. A schedule living inside the box cannot wake the box. Routines fire from outside and start the machine. That's the architectural difference.

The Architecture

PRODUCERS (timer, webhook, connector, workflow)
    ↓
QUEUE (routine_fires, dedup/claim)
    ↓
RoutineRunner

Nothing in the runner knows what caused a run. Timer + manual ship today. Webhook, connector, and workflow land without migrations — the queue and seam are built, the part that's expensive to retrofit is the trigger sources themselves.

Notifications

Panel bell plus Telegram, Slack, or WhatsApp mirror. Default notify-on-change. Failures always ring. Silence is the bug we're building against.

Plans

Free: 1 routine, once a day.
Pro: 10 routines, down to every 15 min.
Max/Team: 30 routines, down to every 5 min.

What's Not There (Yet)

Webhook triggers aren't built yet. The queue and seam are ready, but the part that's expensive to retrofit is the trigger sources. Timeouts and cost caps end our turn rather than killing the agent mid-thought, which is a real limit we'd rather name than paper over.

The Advice I'd Give Myself

Open Routines and start with one. Watch it run once before you schedule it — that's the whole advice.

This is a personal retelling of the Routines launch post. The original company-voice version is at octomind.run/blog/routines-scheduled-agents.

From Chat to Pipeline: Running Octomind Non-Interactively in CI and Scripts

Don Karter — Mon, 24 Aug 2026 16:33:59 +0000

How to take an AI agent out of the terminal and into automation – non-interactive runs, JSON Lines output, structured output with JSON Schema, and multi-step workflows. A practical guide to Octomind in CI, cron jobs, and scripts.

An AI agent that only works when you're typing at it is a tool. An AI agent that works inside a pipeline is infrastructure. Octomind is built to run non-interactively from day one, but pinning the right capabilities is what keeps your CI job from flaking.

I've put Octomind into CI checks, cron jobs, and deploy scripts. This is what I wish I'd known the first time, from the basic "run it without a terminal" up to structured output you can pipe into other tools. Sharing this here because the dev.to community asked practical questions about agent automation, and these patterns might save you a few CI failures.

The Core Idea: Pipe In, Read Out

Interactively, you type and Octomind answers in a styled terminal. Non-interactively, you give it the prompt on stdin and it runs once and exits. The switch is the --format flag:

echo "Review the changes in this PR and flag anything risky" \
  | octomind run developer:general --format plain

Pass a --format value, or pipe stdin instead of attaching a terminal, and the session runs once, reads its input from stdin, and exits when done. That's the whole non-interactive contract. plain keeps the human-readable, terminal-decorated output; for anything a machine consumes, you want jsonl.

JSON Lines: Output a Pipeline Can Parse

--format jsonl emits structured JSON Lines regardless of whether a terminal is attached. One object per event, easy to parse, stable to depend on:

echo "List the three highest-risk files in this diff" \
  | octomind run developer:general --format jsonl

Use this format in CI. Pipe it into jq, grep it for the events you care about, store it as a build artifact. Every line carries a type – assistant, tool_use, tool_result, cost, status, and so on – so the model's answer is one filter away: jq -r 'select(.type == "assistant") | .content'. Because each line is a complete JSON object, you can stream and process it as the run goes rather than waiting for the end.

A reliability note that has bitten me: pin down the environment the agent runs in. In CI you want deterministic behavior, not whatever tools happen to match your prompt. Octomind normally loads capabilities on demand by matching your message – great interactively, slightly unpredictable in a pipeline. Force-load the tools you need at boot instead:

echo "Audit src/ for hardcoded secrets" \
  | OCTOMIND_CAPABILITIES=codesearch-semantic,filesystem-read \
    octomind run developer:general --format jsonl

Everything in that list is loaded before the first turn, regardless of what the automatic matching thinks of your prompt. Matching still runs on top of it, though – if you want the surface to be exactly that list and nothing else, also set auto_capabilities = false in your config. Same tools on every run is exactly what you want when a green check depends on it.

Structured Output: Make the Agent Return Data, Not Prose

Structured output turns an agent into a pipeline stage. Pass --schema with a JSON Schema file and the model's output is constrained to match it. Instead of a paragraph you have to parse with fragile regex, you get clean, typed JSON:

echo "List the top 3 TODOs in this codebase" \
  | octomind run developer:general --format jsonl --schema todos.schema.json

Every assistant reply for that run conforms to your schema, while tool calls still flow normally underneath – only the final text is constrained. This is how you wire an agent into a larger system: have it emit { "issues": [...] } and feed that straight into the next step, no scraping required. A ready-to-use example ships in the repo at config-templates/todos.schema.json.

Structured output needs a model that supports it. Most providers do – OpenAI, Google, xAI, DeepSeek, Groq, OpenRouter, and more. Anthropic models don't, and the run fails fast with a clear message if you pick one that can't. Like --model, the schema is a runtime override that isn't persisted, so pass it again on each run.

Multi-Step Workflows

For multi-step flows, use octomind workflow. It runs a TOML-defined pipeline, reading input from stdin:

echo "Build a JSON-to-CSV CLI in Rust" | octomind workflow build-flow.toml --format jsonl

With --format jsonl it emits one assistant event per step as it completes, each tagged with a step field (the last one is the final result), followed by a single aggregated cost event. Per-step progress and cost stay on stderr for a human to watch, so stdout is clean for your parser. Use --dry-run first to print the execution plan and validate the flow without spending a token.

Guardrails Are Even More Important Here

When a human is watching, a wrong move gets caught. In an unattended pipeline, nobody's watching – which makes guardrails and the sandbox mandatory, not optional. For any automated run I do two things by reflex:

# restrict writes to the working directory — OS-enforced (Landlock on Linux, Seatbelt on macOS)
octomind run developer:general --sandbox --format jsonl < prompt.txt

I also set spending limits in config so a runaway loop can't run up a bill while I'm asleep:

max_session_spending_threshold = 2.0
max_request_spending_threshold = 0.5

Interactively the session cap asks before continuing; in a pipeline there's nobody to ask, so it stops the run. A pipeline that can't write outside its directory and can't spend more than two dollars is a pipeline you can actually trust to run on a schedule. When a guardrail fires it shows up in the JSONL stream as an injected event with source_kind set to guardrail_hook or guardrail_validator, so you can assert in CI that a rule fired (or didn't) as part of your test.

A Real CI Shape

Put together, a PR-review check looks like this:

#!/bin/sh
set -e
git diff origin/main... > /tmp/diff.txt

echo "Review the diff in /tmp/diff.txt. Return findings as JSON matching the schema." \
  | OCTOMIND_CAPABILITIES=filesystem-read \
    octomind run developer:general \
      --sandbox --format jsonl --schema review.schema.json \
  | tee review.jsonl

# downstream: parse review.jsonl, post comments, fail the build on severity >= high

Deterministic tools, sandboxed, structured output, cost-capped. The agent does the judgment; your script does the plumbing. (If you specifically want code review on every GitHub PR, we package this exact pattern as a ready-made Action so you don't have to assemble it yourself.)

What Changes When Nobody's Watching

Once an agent runs cleanly without a terminal, you stop thinking of it as a thing you use and start thinking of it as a thing you deploy. Cron jobs that triage issues overnight. CI checks that flag risky diffs. Scripts that summarize a day's commits. Same binary, same models – just pointed at stdin instead of a keyboard, emitting JSON instead of prose.

Start with one echo ... | octomind run --format jsonl. Add a schema when you need structured data, a sandbox and spending cap when it runs unattended, and a workflow when one prompt isn't enough. The same binary that answers in your terminal can run your pipeline at 3 AM. That's the difference between a tool and infrastructure.

Get Octomind – and put your agent on the pipeline.

Octomind 0.44.2: I Removed the Agent's Ability to Grade Its Own Homework

Don Karter — Thu, 20 Aug 2026 08:55:00 +0000

The Lie That Bugged Me

I was building a feature last month when Octomind told me it was done. Five files needed editing based on the task I gave it. I checked – three were changed, two were untouched. The agent had marked the task complete anyway.

Worse, I caught it verifying its own work by reading back the edit it just made and essentially admiring it. The model was saying "the code looks correct" because it had written the code itself. That isn't verification. It's the model grading its own homework.

I got tired of my own tool lying to me. So in 0.44.2, I removed that ability entirely.

This isn't a minor tweak. It's a philosophical shift about what an AI coding agent should actually do. I'm choosing honesty over the appearance of competence. An agent that says "I couldn't do this" is more useful than one that says "done!" and leaves you to find the gaps.

What Actually Changed

Three pillars. All of them aimed at making the agent honest about what it's done and what it hasn't.

Per-Condition Verification

The verify gate no longer accepts a holistic "looks good" verdict. Every task derives evidence conditions. The verifier must address each one. An unmatched condition beats a holistic PASS, every time.

Before, the model could say "yeah, this looks solid" and move on. Now it has to prove each condition is met. If your task requires "function X exists" and "test Y passes", both get checked individually. One fails, the gate stays closed. No hand-waving.

This came from watching the agent skip over edge cases. It would verify the happy path and call the task done. Now every condition you specify – or that the planner derives – gets its own verification moment. The verifier can't gloss over gaps.

External Planning

Planning left the model's hands entirely. The model-callable plan tool is gone. An external plan manager – running its own cheap model – owns the checklist now.

This matters because the main model was using planning as procrastination. It would generate a plan, call it done, and treat the plan like the work. Finishing paperwork isn't doing the work. I'd see tasks where the agent spent tokens generating a detailed plan but hadn't actually touched the code.

The external planner is cheaper, faster, and doesn't confuse bureaucracy with progress. It's a separate model that only does planning – no code writing, no verification. Just the checklist. This separation means the main model can't hide behind a plan and pretend it made progress.

Persisted Verification Policy

Verification policy persists with the session and survives restarts. It's folded into the governance hash.

I was losing my verification rules every time I restarted my session. That's fixed. Your policy travels with the session now, encoded into the governance hash that tracks the session's integrity. Restart your terminal, restart your machine – your verification rules come back.

This sounds minor until you've had to re-specify your verification standards for the fifth time. It's not minor. It's the difference between a tool that remembers your standards and one that makes you retrain it constantly.

What You'll Notice Day-to-Day

You'll see fewer false positives. The agent will tell you "I couldn't verify condition 3" instead of "done!" when it's not. That might feel slower, but it's actually honest. You're getting accurate status instead of premature completion.

The model can't grade its own homework anymore. When verification runs, it runs with no fallback model. If verification fails, the gate stays closed. No silent downgrade to a weaker check.

This was a hard call. I could've let verification fail over to a cheaper model when the primary verifier struggled. That would've kept the gate moving. But it would've also meant weaker verification on the hard cases – exactly when you need it most. Now, if verification fails, you know. The gate stays closed. You get notified. You decide what's next.

You'll also notice the planner is snappier. That's because it's a separate, cheaper model doing only planning – not trying to write code and plan at the same time. The separation of concerns actually shows up in latency.

Upgrade Notes

This one's not entirely smooth. A few things to know before you upgrade:

Config auto-migrates to version 5 with backup. Your existing config will be migrated automatically on first run, and the old version is backed up. You won't lose anything. The migration handles the structural changes required by the new verification and planning architecture. If something goes wrong, your backup is there.

The plan MCP tool is gone. This is breaking for embedders who called plan(command=...). If you built something on top of that tool, you'll need to adjust. I know – breaking changes suck. I'd rather ship this now than live with the debt. The tool was enabling the wrong behavior – letting external code trigger planning in ways that bypassed the new external plan manager. If you're an embedder, reach out. I can help you migrate.

Tap and schedule moved to a new orchestration server. If you use scheduled runs or tap functionality, they're now handled by a separate orchestration layer. Functionally the same from your end, just cleaner under the hood. The orchestration server is purpose-built for timing and coordination, which means the main agent process doesn't carry that weight anymore.

Installation

If you're on macOS:

brew install muvon/tap/octomind

Fresh install or upgrade, you'll get 0.44.2. The config migration happens on first run. Check the backup it creates – it'll be in your config directory with a timestamp.

On other platforms, pull the latest from the repo. The release tags are up to date.

Why I'm Writing This

I could've just shipped it with a changelog. But these aren't minor tweaks – they're philosophical shifts about what an AI agent should be.

The old behavior felt like progress. The agent moved fast, checked boxes, told me it was done. But I was doing the actual verification myself, which meant the agent wasn't earning its keep. I was just paying for automation that still required my full attention.

These changes came from me getting burned by the old behavior, not from a roadmap meeting. Your agent should tell you the truth, even when the truth is "I didn't finish."

The full technical breakdown is in the release post on the Octomind blog if you want the deeper dive on governance hashes and the orchestration split.

I use Octomind on my own projects every day. These changes make it more honest, more useful, and ultimately more trustworthy. That's the release. Install it, break it, let me know what else needs fixing.

I wrote a browser in 25k lines of Rust because every AI browser is lying to you

Don Karter — Tue, 18 Aug 2026 08:50:55 +0000

This post originally appeared on the Muvon blog. I'm cross-posting it here because the dev.to crowd is exactly who I built this for.

Every browser suddenly has AI in it. And every one of them did it the same way: take Chrome, bolt a chat panel onto the side, call it an AI browser. The browser doesn't know the agent exists. The agent can't touch the browser. Two strangers sharing a window.

I spent this year building agents — a runtime, memory, code search, a filesystem layer — and at some point the question became unavoidable: what would a browser look like if it were designed for AI from the first commit? Not AI added. AI as a citizen — in both directions. The agent lives in the browser and can see what you see. And the browser is a tool the agent can pick up and use.

So I built it. Octoweb is a WebKit browser written in Rust — no Electron, no Chromium, about 25,000 lines — made for two overlapping audiences: people who live on the keyboard, and people who work with agents all day. I'm both, and five months later it's the browser I start every morning in: reading docs, debugging my own web apps, handing the boring browser chores to Octomind while I keep reading.

It just hit 0.10.0, and I figured the dev.to crowd would care about the engineering decisions more than the product announcement. So here's the build story.

First, the geek part: no mouse required

Before the AI does anything, Octoweb has to earn its place as a browser for people who think in keystrokes. The design rule was simple: every action has a shortcut, nothing requires a click.

The center of it is the command palette (⌘⇧P) — type a URL, a search query, or any fragment of a page you've visited, and it fuzzy-matches across open tabs and history, ranked by match quality and visit frequency. One more keystroke opens, switches, or searches. And because muscle memory is sacred, the palette speaks readline: ⌃A/⌃E to jump, ⌃K/⌃U to kill, ⌃N/⌃P to move. If your fingers know Emacs or a shell, they already know Octoweb.

The rest of the vocabulary:

Fast-access slots — ⌘⇧1–⌘⇧0 pins the current page to a numbered slot; ⌘1–⌘0 jumps back from anywhere. Ten pages, one keystroke each, persisted across restarts. It's the browser equivalent of Vim marks. New in 0.10.0: ⌘⇧N pins the current page to the first free slot — and unpins it if it's already there.
MRU tab cycling — ⌃N/⌃P walks tabs in most-recently-used order, the way you actually switch between two pages, not the order they happen to sit in the tab bar.
Vim-style scrolling — ⌃D/⌃U for half pages, ⌃T/⌃B for top and bottom.
Screenshots to clipboard — ⌘S viewport, ⌘⇧S full page. No save dialog, no file to clean up later.
⌃R in the AI prompt box — reverse incremental search through your prompt history. Yes: I put readline's history search in the browser's AI input, because once you've had it in a shell you want it everywhere.

Global shortcuts run through CGEventTap, macOS-native and configurable. And here's why Octoweb is macOS-only for now — it leans on the platform (WKWebView, AppKit, CGEventTap) instead of shipping a second operating system in a zip file. That's also why the whole browser is a single lean binary instead of a 300 MB Electron app.

The agent in the sidebar — running on Octomind

Press ⌘⇧A and an agent slides in over the page. Not an iframe with a chat website in it — a real agent process, running locally, connected over the Agent Client Protocol.

The agent is Octomind, my plug-and-play agent runtime — the same one that powers my terminal sessions and CI reviews. And here's the part you don't do: start it. Octoweb launches octomind acp octoweb:assistant itself — a sandboxed subprocess per session, restarted if it dies, resumed with your conversation intact on the next launch. Install Octomind once, and the sidebar takes it from there.

That octoweb:assistant tag is a manifest from the community tap registry: model, system prompt, and tools, fetched and assembled automatically. Zero config files written by hand. From then on you can ask about the page you're reading, get code on it explained, or summarize a thread you don't have time for — with responses streaming in, sessions that persist and resume, and slash commands with rich output cards.

And because it's a real agent, the sidebar isn't a chat box with opinions — it works. Swap the tag to developer:rust and you can code from the browser: the agent edits files in its sandboxed workspace, tool calls show up as clickable rows with live status, and when it wants to show you something richer than prose — a form, a table, a small interactive UI — it renders an A2UI surface right in the sidebar. I've fixed bugs in Octoweb, from Octoweb, while the failing page sat in the next tab.

Three details I sweated:

The agent tag is editable. The sidebar header shows octoweb:assistant by default, but type any tag your Octomind knows — developer:rust, your own custom agent — and the sidebar reconnects to it on the spot. The browser doesn't care which brain it's talking to.
The browser never calls an AI provider. Every model call is made by Octomind, outside the browser process, with the agent's filesystem access sandboxed to its workspace. No data leaves your machine unless your agent sends it somewhere — and which agent that is, with which provider, is entirely your call.
The session is a two-way street. Since 0.10.0, messages injected by the Octomind runtime — a specialist replying from the tap, a scheduled job finishing, a webhook firing — arrive in the sidebar as their own labeled bubbles, mid-conversation. Your browser becomes the place where your agents report back.

There's also a smaller door: select text on any page, press ⌘⇧E, and an inline edit modal transforms the selection — rewrite, summarize, translate. It runs its own dedicated agent from the same tap — octoweb:editor — with its own prompt history, ⌃R and all.

The browser as a tool: MCP from the inside

This is the direction nobody else builds, and it's my favorite part. Octoweb runs an MCP server inside the browser — localhost:3434/mcp. Any MCP client — Claude Desktop, an Octomind session, your own script — can connect and drive it: twenty-six tools covering navigation, tabs, clicking, typing, scrolling, screenshots, content extraction, console output, and network activity.

You've seen browser automation before. The difference here is that the agent isn't driving a headless Chromium in a datacenter with no cookies and a bot-detection target on its back. It's driving your browser — your sessions, your logins, your tabs — while you watch. And the tool design takes "while you watch" seriously:

Navigation never steals focus. browser_navigate always opens in the background. Exactly one tool — browser_switch_tab — is allowed to change what you're looking at. An agent can research in ten tabs behind your back without ever yanking the page out from under your cursor. It browses beside you, not instead of you.
Clicks that don't lie. browser_click retries until the element is present, stable, and unobstructed — and if something is covering it, the error says what. browser_snapshot returns a map of interactive elements with stable @N refs that pierces iframes, shadow DOM, and listener-only clickables. browser_wait knows about SPA readiness, not just page load.
Eyes included. browser_console_messages and browser_network_requests give the agent the page's console errors and fetch/XHR activity with statuses and timings — the two things you'd open DevTools for, as tools.
Guard rails at the boundary. Text that flows out through snapshots and page content passes a sanitizer — card numbers get redacted before they ever reach a prompt.
Tokens are the budget. Every tool answer is shaped for a model, not for a debugger: browser_snapshot returns a compact element map instead of raw HTML (I deleted the get_html tool on purpose), console and network logs come capped and filterable, and @N refs mean the agent never burns half a context window guessing CSS selectors. An agent's turn is priced in tokens; the browser respects that.

And if your agent runtime is Octomind, wiring it up is one line inside a session:

/mcp add octoweb http://localhost:3434/mcp

The agent you were already talking to can now open docs, read them, fill forms, and check what a page's console is screaming about — mid-conversation, no restart. This is how browser chores leave my to-do list: the agent reproduces a bug in a background tab, reads the console, and comes back with the failing request; it walks an admin panel I didn't feel like clicking through; it checks that a deploy actually rendered — in my logged-in browser, with my sessions, while I keep reading in the foreground tab.

The browser that learns with you

One more experiment: proactive learning. On an interval — 30 minutes by default — Octoweb wakes a second, fully independent agent, the octoweb:learning tag, which looks at your open tabs and recent history and distills what you're working on into Octomind's memory. Next session, the sidebar assistant already knows the docs you've been circling for three days.

It's on by default — one toggle in Settings turns it off — it's local, the interval is yours to set, and the two agents are fully independent: run either without the other. I think ambient memory is where browser AI actually gets interesting, and I'd rather ship the honest v1 of it than a demo.

Yes, it's also just a good browser

None of this matters if the browsing is worse than what you left. The fundamentals are there, and a few are better than there:

Smart tab hibernation — background tabs freeze under memory pressure, with RAM-aware thresholds. Fifty tabs is a lifestyle, not a leak. And since 0.10.0 there's a cap on open tabs (500 by default, configurable) that quietly closes the least-recently-used ones past it — an airbag for tab hoarders.
Content blocking built in — trackers and ads via WebKit's native content rule lists, no extension needed.
Cold starts stay cold — favicons are cached as data-URIs, so launching the browser makes zero network requests until you do.
Session restore, WebAuthn passkeys, PDF and DOCX viewing, find-in-page on the CSS Custom Highlight API, native fullscreen, proper popup-window handling.

What about extensions? Honest status: the Safari Web Extensions integration (for 1Password, Bitwarden, and friends) is fully implemented in the code — and blocked on Apple's com.apple.developer.web-browser entitlement, an approval only Apple can grant. Until it lands, content scripts don't inject. I'd rather tell you that than pretend extensions are a roadmap item.

Five months, 0.1.0 to 0.10.0

Octoweb started in late March as an experiment: could a keyboard browser with an ACP sidebar be usable in a week? By 0.6.0 it had tab hibernation and the first MCP automation tools. 0.7.0 brought persistent chat sessions, passkeys, and slash commands. 0.8.0 was the big one — the actionability harness, the e2e suite that tests the browser through its own MCP server, agent sandboxing, configurable keybindings, A2UI surfaces. 0.9.0, cut in late July, moved to ACP v1.2.0 with account authentication and a long tail of stability work. And today's 0.10.0 is what daily use does to a roadmap: pinned tabs, the open-tab cap, account quota status that refreshes itself, specialist messages landing in the sidebar — plus fixes for a memory leak and orphaned agent processes, the kind of thing you only find by leaving it running for weeks.

What started as an experiment is now the browser I actually live in. It won't replace my main browser this year — it might become the one I reach for when I want to think.

Get it

One line on any Mac, Apple Silicon or Intel:

brew install --cask muvon/tap/octoweb

Or grab a prebuilt archive from GitHub Releases, or build from source with a Rust toolchain:

git clone https://github.com/muvon/octoweb
cd octoweb
./build.sh --dev        # ad-hoc signed, no cert needed
open dist/Octoweb.app

For the sidebar, install Octomind and sign in:

curl -fsSL https://raw.githubusercontent.com/muvon/octomind/master/install.sh | bash
octomind login

octomind login is a device-code sign-in to Octomind Cloud — the subscription includes model access, so there's nothing else to configure, and the sidebar shows your account and quota status. Prefer your own keys? Skip the login and export any provider key instead (OPENROUTER_API_KEY, ANTHROPIC_API_KEY, …) — BYOK is a first-class path. Either way, that's the whole setup: launch Octoweb, press ⌘⇧A, and say hello — the browser starts and manages the agent process itself. Config is one TOML file at ~/Library/Application Support/octoweb/config.toml; Settings is ⌘,.

Octoweb is on GitHub under Apache-2.0, like everything else I ship. If you live on the keyboard, or your agents deserve a real browser instead of a headless one — try it, and tell me what's missing. The features requested by early users are the reason 0.10.0 looks nothing like 0.1.0.

— Don

Muvon / octoweb

Dead simple AI-loaded browser for geeks

Octoweb — the keyboard-first AI browser for macOS

The browser you reach for when you want to think. macOS only, by design.

Built on WebKit and Rust. No Electron. No Chrome. No mouse required.

Why Octoweb?

Most browsers are built around the mouse. Octoweb is built around the keyboard — and around the idea that your browser should amplify your thinking, not interrupt it. Every action has a shortcut. The AI assistant lives in a sidebar, not a tab. And your AI tools can drive the browser directly via MCP. No extensions. No config. Just open it and go.

Three things it does differently:

Keyboard-first navigation — Every action has a shortcut. Nothing requires a click. The command palette (⌘⇧P) fuzzy-searches tabs and history. Pin any page to a fast-access slot with ⌘⇧1–⌘⇧0 and jump back with ⌘1–⌘0 from anywhere.
AI assistant built in…

View on GitHub

(Octoweb is open source under Apache-2.0, developed by Muvon Un Limited. It runs on Octomind, my plug-and-play AI agent runtime.)

DeepSeek V4 Flash on 50 Real Pull Requests: Two Harnesses, One Ceiling

Don Karter — Sat, 15 Aug 2026 08:16:05 +0000

Two harnesses. Same model. Two tasks apart.

We ran deepseek-v4-flash through octomind and opencode on 50 real-PR tasks — same model, same prompt, sealed network. 45/50 vs 43/50, three judge points apart, three cents a task either way. The model is strong enough to be harness-neutral; what separates clients now is who finishes.

The Model Won't Make It Dramatic

Two weeks ago we published a same-model A/B where the harness decided everything: 24 of 25 tasks solved in octomind, 19 of 25 in opencode, at double the cost. We just re-ran that experiment with DeepSeek V4 Flash, on a stricter benchmark, twice the tasks – and the model refused to make it dramatic. 45 versus 43.

On 50 real pull requests harvested from merged fixes across C++, JavaScript, PHP, Python and Rust, deepseek-v4-flash solved 45/50 in octomind and 43/50 in opencode – same model, same system prompt, sealed network, about three cents a task either way. The model is strong enough to be harness-neutral. What's left for a harness to prove is how often it finishes.

What We Ran: Real Bugs, Not Puzzles

octobench cases aren't synthetic puzzles. Each one is a real bug or feature that a maintainer actually merged, replayed at the parent commit, and graded by the project's own held-out tests plus a judge panel scoring 0–100. Fifty cases, ten per language.

Since the glm-5.2 run, we rebuilt the methodology, because the first version had a hole you could drive a truck through: the bench is built from merged PRs, and nothing stopped an agent from going and reading the merged PR. In early rounds opencode fetched the upstream fix from raw.githubusercontent.com in 13 of 49 cases and copied it. octomind's stock role was subtler but worse in spirit – it ordered the agent to websearch the upstream issue and "mirror its approach and API contracts EXACTLY." On a benchmark made of merged PRs, that's an instruction to read the answer key.

So this campaign runs clean: One shared system prompt for both harnesses, distilled from octomind's role with the client-specific parts stripped. A sync script fails the build if they drift. No route to the answer. Web search and web fetch disabled in both clients; GitHub unreachable from the agent's container once setup finishes. Same model, same endpoint – official deepseek-v4-flash on api.deepseek.com, deepseek:deepseek-v4-flash in octomind, deepseek/deepseek-v4-flash in opencode. One measurement note that changed our read of things: we started on a third-party token-plan endpoint and switched to the official API mid-campaign. The official endpoint is roughly 3× faster per request. A chunk of what we'd previously logged as "slow client" turned out to be slow provider.

The Scoreboard

Metric	octomind	opencode
Solved	45/50 (90.0%)	43/50 (86.0%)
Judge average	88.59	85.59
Total cost	≈$1.59 ($0.032/case)	≈$1.53 ($0.031/case)
Agent runtime	10.4h (12.5m/case)	8.7h (10.4m/case)
Tokens	4.4M (1.9M in / 1.5M out / 1.0M thinking)	4.0M (2.1M in / 573K out / 1.3M thinking)
Cache read	224.2M	254.3M

Two tasks and three judge points apart. For calibration: our measured judge noise on this suite is about 1.7 points, so the gap is real but roughly double the noise floor – not the five-task blowout the glm run produced. Costs are a coin flip.

The New Flash in Numbers

The official V4 Flash went live July 31, and the release is the real thing: DeepSeek's own GA numbers have it beating the V4 Pro preview on agentic benchmarks – Terminal Bench 2.1 at 82.7, DeepSWE at 54.4, Toolathlon verified at 70.3 – from a Mixture-of-Experts with 284B total and 13B activated parameters and a 1M-token context window. What that translates to on real-PR work: twelve minutes and three cents per landed fix, a ~94 judge average on cases it passes, in either harness. No babysitting, no mystery timeouts. For the routine 90% of maintainer work, this model at flash pricing is simply a solved problem.

And here's the interesting part – it's harness-neutral. The glm-5.2 run showed a five-task gap between the same model in two harnesses. V4 Flash lands two tasks apart. Two. Part of that is the model carrying more of its own discipline: fewer wasted reads, fewer early victory laps, less need for a supervisor to keep it honest. Part of it is that this benchmark is stricter with both clients – we sealed the answer key, and that cut against octomind's stock role as much as anyone's web access. We made the test harder for ourselves and the gap narrowed anyway. Both things are true.

One Ceiling, Five Walls

The five cases octomind fails are the same five opencode fails: yaml-cpp's binary emit styles, pino-pretty's control stripping, commonmark's fence tabs, rustls's misplaced extensions, and React's hidden hydration hang. Identical walls across harnesses is what a model blind spot looks like – not a harness artifact. These are the composition-heavy fixes where the model keeps missing a sibling path or a per-message rule no matter how it's prompted. Four instrumented reruns of pino-pretty all missed the same sibling. That's the model, not the steering. The honest read of the 86–90% band: the last 10% is where model quality ends and everything else begins.

What the harness still decides is the finish: octomind has zero unique failures. opencode's two extra losses are both finishes that never landed: Guzzle's cookie prefixes, where opencode spent 17 minutes and failed while octomind passed in 4; Monolog's trace length, where opencode bailed in 3 minutes with a judge score of 36 while octomind landed a 94.67 in 2.

The React case is the same story at maximum volume. It's a hang-by-design bug – every wrong attempt blocks instead of failing – on a giant repo. opencode stopped at 63 minutes and 394 steps, scoring 36.67. octomind ground for 271 minutes and 1,322 steps – for the same $0.32 – to a fix that passes 66 of 67 hidden tests. We record it as a failure, because it is one, but the judge scored the near-miss at 41.67. (One run died at minute 213 on a provider quota error and was resumed from a restored session to finish at all.)

That's finalization: not better luck, more refusal to stop early. Strip the React outlier and octomind also averages about 7 minutes a case to opencode's 9.

The Token Tax

The tax is real, though. octomind wrote 2.6× the output tokens – 1.5M versus 573K. It talks more. And on the React-sized repos its fine-grained tool loop against a fat per-call context is a genuine speed ceiling; coarser steps and context slimming are next on our own list. A harness that finishes everything will still cost you in words.

The Ceiling and Floor Thesis

The model sets the ceiling. The harness sets the floor. After the glm run we wrote that model quality is table stakes and the harness is where the edge is. V4 Flash tightens that into something more precise: a model this good raises the ceiling for everyone – pick the model you like, the ceiling barely moves between harnesses. What the harness decides is how often you actually reach it, and whether the last five percent lands or gets declared done at minute 63.

What's Next: GLM-5.3

glm-5.3 just dropped. Same bench, next question. Yesterday Zhipu released GLM-5.3: same base model as 5.2, with the gains coming from post-training alone. Zhipu claims a 50% coding improvement over 5.2 and calls it the strongest open-weights coding model. It's live through their coding plan now. Open weights are promised in about two weeks, behind a safety review. This matters to us more than most releases, because glm-5.2 is the model that started this story. In the first run, glm-5.2 in octomind beat Claude Code running claude-opus-5 (24/25 solved against 23/25, $63 against $82, 3.6 hours against 6.7) – while paying full freight: that run went through an endpoint with no prompt caching, so every turn re-bought its whole context at list price. So the next campaign writes itself. glm-5.3 versus glm-5.2 on the same sealed 50-case bench, in both harnesses, answer key locked. A claimed 50% post-training jump is exactly the kind of number vendor benchmarks love and real pull requests interrogate. And there's a sharper question underneath: V4 Flash just showed that a strong model narrows the harness gap to two tasks. If 5.3 really is that much better than a model already beating Opus, does the floor rise with the ceiling – or does the last 10% stay exactly right where it was? Worth finding out.

Reproduction steps and the raw per-case artifacts are pinned at the commit this post describes. GLM-5.3 versus 5.2 is next on the calendar, with Claude Code and Codex columns on the same sealed bench right behind it.

Benchmarking AI Coding Agents on Real Pull Requests

Don Karter — Sat, 01 Aug 2026 17:25:42 +0000

No synthetic puzzles, no contaminated suites: 25 tasks harvested from PRs merged in 2026 across five languages, graded by each project's own held-out tests. Four agents at stock settings. octomind with an open model solved 24/25 - ahead of Claude Code with Opus - while the same model in another harness solved 19 at double the cost. Here's how we built the benchmark and what it taught us.

We wanted one number we could actually trust: if you hand a coding agent the kind of task a maintainer faces on a normal Tuesday - a real bug, a real feature request, in a real codebase - how often does it deliver a fix the project's own test suite accepts?

None of the public benchmarks could give us that number, so we built octobench. This post is the story of how, what broke along the way, and what the scoreboard says.

Why not an existing benchmark

Two problems kept biting us with the popular suites.

Contamination. The well-known benchmarks are old enough that frontier models have seen the fixes - sometimes literally, commit by commit - in training data. At one point we caught a model running git show on a commit hash it had no business knowing about. Whatever that measures, it isn't problem-solving.

Taste-grading. Many benchmark tasks are graded by tests that assert an implementer's arbitrary choices: an internal variable name, the exact wording of an error message. An agent can write a maintainer-grade fix and fail because it phrased an error differently than the original author. That measures mimicry, not engineering.

So the design goals were: real tasks, fresh tasks, fair grading.

25 tasks, 5 languages, mostly newer than the models

We harvested every task from a real, recently-merged pull request in a respected open-source project: werkzeug, click, anyio, pydantic, twig, carbon, symfony, guzzle, commonmark, uuid, rayon, chrono, bytes, serde-json, fmt, yaml-cpp, catch2, spdlog, eslint, fastify, undici, pino, pino-pretty.

That list is deliberate on two axes. Languages: five of them - python, php, rust, c++, js - because an agent that's great at python and lost in a CMake build is not a general coding agent. Freshness: every fix was merged in 2026, mostly after current model training cutoffs - several within days of harvesting. One case, chrono's reversed date iterators, was merged the same morning we picked it. A benchmark you can re-harvest as cutoffs advance is a benchmark that can't go stale.

The scenario mix runs from one-line crash fixes to multi-file features, and each case reconstructs the moment before the fix existed:

setup.sh checks out the repository at the commit before the fix - as a single-commit shallow clone, so the answer isn't hiding in the git object store - prepares the toolchain, and removes the git remote so the agent can't just fetch the upstream fix.
The agent gets a task prompt and works in the repo like a hired contractor.
validate.sh runs after the agent finishes: it fetches the merged fix's test files - which the agent has never seen - overwrites whatever the agent may have done to the test suite, and runs exactly those tests. The project's own tests, written by the project's own maintainers, decide pass or fail.
An LLM judge separately grades work quality from the diff and logs.

Before any case entered the benchmark it had to prove itself fail-to-pass: held-out tests must fail on the pre-fix code and pass with the real merged fix applied. No proof, no case.

Writing prompts that don't cheat - in either direction

For 20 tasks we ran a dedicated agent (octomind's developer:reverse-spec) over each merged commit to reconstruct the request that plausibly produced it, then curated by hand with one rule - the derivability rule: everything the hidden tests assert must be derivable from the prompt. Bug fixes got a short informal prompt, because any correct fix passes. Features whose tests pin public API names or exact output formats got a spec-tight version, because a real requester would state a wire format.

For the other 5 - one per language - we used the actual GitHub issue text, verbatim, trimmed only of fix-leaking sections (one author had helpfully written "I have a PR ready that does X"). That tests something different: turning a user-shaped bug report, sometimes with a screenshot instead of expected output, into a maintainer-grade fix.

A few favorites, by the skill they isolate:

anyio's cancel-scope spin - a 4-line fix that requires understanding why an asyncio event loop pins a CPU core. Tiny diff, deep async reasoning.
guzzle's cookie prefixes - 27 lines with three independent traps; the naive startsWith("__Secure-") && !secure fix fails half the tests.
commonmark's fenced-code tabs - a user reported "code blocks sometimes lose their first character" with a screenshot. The held-out fixtures include cases the issue never mentions - only a true root-cause fix passes, a symptom-patch fails.
pino-pretty's control characters - two hidden tests exist purely to punish over-broad sanitizing: they pass on the broken code and fail any fix that doesn't respect the trust boundary.

Eating our own dogfood

Before the final run, three reviewers read every held-out assertion against every prompt. The audit caught real problems - in our benchmark, not the agents. One case's tests asserted the exact prose of an error message the issue never quoted; two frontier agents produced perfect fixes (one even picked the same error-code number as the maintainer) and both failed on wording. We replaced the case. Another case's hidden tests contradicted its own issue text. A third had its held-out tests inside a source file, so restoring gold tests wholesale would silently revert a correct fix.

The meta-lesson: benchmark infrastructure fails in ways that look exactly like model failures. Every anomaly we chased - a judge scoring 0 on a passing run, a "solved" case with an empty diff - deserved a real root-cause, and about half were ours.

The scoreboard

Four agents, each at its stock, out-of-the-box single-agent invocation. No tuning, no custom prompts.

Agent	Solved	Judge Σ / 2500	Cost	Wall Time
octomind + glm-5.2	24/25	2264	$63.43	3.6h
claude code + claude-opus-5	23/25	2262	$81.79	6.7h
codex + gpt-5.6-sol	21/25	2127	$14.86	1.0h
opencode + glm-5.2	19/25	2093	$129.54	3.3h

Four things the table says:

The harness matters as much as the model. octomind and opencode ran the same model on the same endpoint at the same prices - a pure harness A/B. octomind solved 24, opencode 19, at half the cost. The difference is context discipline (opencode pushed 30M input tokens through one task where octomind needed 8M) and supervision: the cases opencode dropped are exactly the deep-root-cause, multi-trap ones where an unsupervised agent declares victory too early.
An open model beat Opus while paying full price for every token. glm-5.2 ran via Ollama cloud, which has no prompt caching - every agent turn re-bought its full context at list price. Opus, meanwhile, billed ~97% of its context re-reads at 1/10 cache rates. glm's dollar figure is its worst case, and it still came out ahead on solves, cost, and time. On any cache-enabled endpoint the cost gap becomes a chasm.
Speed has a thoroughness tax. Codex is remarkable - 2-4 minutes per case, $0.59 median - but all four of its failures are cases that punish not checking one more caller, one more surface, one more trap.
No task was impossible. Every case was solved by at least one agent, and the failure classes were clean: the trust-boundary case caught opus, codex, and opencode; the deep root-cause parser case caught everyone except octomind; and the one case both glm harnesses failed identically is a genuine model blind spot, not a harness artifact.

Where the harness edge comes from

A big share of "context discipline" is simply how the agent finds code. Stock claude code, codex, and opencode navigate a repository the same way: grep, read the file, grep again, read more - and every re-read is context the model pays for on every subsequent turn. octomind's developer:general ships with octocode out of the box: structural search that finds the exact symbol, signature, or code pattern directly, so the agent jumps to the three functions that matter instead of paging through files that don't. Enable semantic indexing and it also searches the codebase by meaning - "where is cookie validation handled" as a query, not a grep pattern. Fewer wrong files read is fewer tokens re-bought, and that compounds into the 8M-vs-30M input-token gap the A/B exposed.

The other share is supervision. During dry runs an agent once "finished" a task by announcing "Now let me create a plan and implement the fix" - and stopping, with a zero diff. In a non-interactive run a text-only turn ends the session, so octomind added a deterministic guard: if a turn ends with no action while the agent's self-reported status is still in progress, it gets sent back to work. In the final run that failure mode was gone - and the cases opencode dropped are precisely the ones where nothing questioned an early declaration of victory.

Reproduce it

Everything is public and pinned: the full per-case table and reproduction guide at the exact commit of this run, per-case agent traces and judge verdicts in the run artifacts, and the case-harvesting pipeline - the reverse-spec agent, the derivability rules, the fail-to-pass verifier - documented so the set keeps growing as training cutoffs advance.

The result we care most about isn't the ranking. It's the A/B: same model, same endpoint, five more tasks solved at half the cost. Model quality is table stakes now - the harness is where the leverage is. That's the thesis octomind is built on, and now we have the number.

Workflows Come to the Cloud: Running Multi-Agent Pipelines from the Browser

Don Karter — Wed, 29 Jul 2026 08:22:38 +0000

Workflows Come to the Cloud: Running Multi-Agent Pipelines from the Browser

I've been building AI tools for three years now. Here's what I keep running into: most real work isn't a conversation – it's a contract.

You have the input (an article, a diff, a pile of CSV data). You know what the output should be (social drafts, a review verdict, a readable report). What you want in between isn't chat. It's a pipeline: specialists doing their parts, handing off to each other, with an auditor gating the result before it reaches you.

That's the core idea behind workflows in Octomind – our session-first, multi-provider AI agent runtime. And as of this week, those workflows now run in the cloud panel, not just the CLI.

Same pipelines. Same tap library. New surface.

If you've been running octomind workflow from your terminal, nothing changed – you just got a second way to do the same thing. If you haven't tried workflows yet, here's what I built and why I built it this way.

A workflow is a team with a contract

Every workflow in Octomind is a declared pipeline of steps. Each step is a full agent run with its own role. Steps can be sequential, parallel, conditional – or loops, which is where it gets interesting.

Take the promote workflow. You feed it an article. It turns that article into platform-native social drafts. Here's what actually happens:

A researcher grounds the article in its source material
A writer drafts per platform (Twitter, LinkedIn, whatever)
An auditor checks each draft against quality gates
If the audit fails, the draft loops back for re-editing
The pipeline halts rather than shipping something the auditor rejected

Or review – it takes your unstaged diff and produces an independently verified verdict. Or report – it turns raw data into a decision-ready document where every number is computed, never invented.

There are fourteen of these in the public tap today. They're the same whether you run them from a terminal or a browser.

# CLI still works exactly the same
cat article.md | octomind workflow promote

The full input goes in at the start – the whole brief, up to 256 KB of it – and the finished result comes out at the end. No steering mid-flight, no drip-feeding context. That's not a limitation; it's the point. You're not chatting with a team, you're commissioning one.

From library to running pipeline

In the cloud panel, the Library tab shows the catalog. Pick a workflow and the new-run screen asks for exactly two things: which machine, and your input.

The Dry run button is the part I'd point at first. It validates the workflow on the machine itself and renders the resolved pipeline – every step, every role, the loop caps – without spawning anything or reading your input.

It's free. It takes a couple of seconds. And it means a broken pipeline fails before a single token burns.

Starting a real run performs the same validation again on its own, so the button is a preview, not a chore. But I use it anyway. There's something useful about seeing the full pipeline shape before you commit to running it.

Then the run page becomes the thing worth watching: the whole chain renders immediately from the validated plan, and steps light up as the stream comes in. A checkmark when a step completes. A spinner on the one running. A pass counter on loops as the auditor sends drafts back.

You can close the tab and come back. The run belongs to the machine, not to your browser.

Artifacts: when output is a file, not text

Under the result there's a detail we're calling artifacts. Workflow deliverables are often files – promote writes drafts, report renders a document – and the final message names the paths.

The panel picks those mentions out and turns each one into a download chip, with inline previews for images and text. Nothing is fetched until you click – the mention is just a string until you ask for the file.

This is also the security posture: text can name a path, but only you can fetch one. Sessions got the same mechanic: when an agent in a chat says it saved something, the file is right there to grab.

Everything the run printed is kept, verbatim. The collapsible full log holds the validated plan, the machine-readable event stream, and the human progress view – downloadable, nothing summarized away. Step outputs get their own friendly view too, so you can read what each specialist handed to the next.

Honest one-shots: why there's no retry button

Here's a design decision I want to be explicit about: a workflow run has five states – queued, running, done, failed, canceled – and the last three are final.

There is no resume. No retry-in-place. No "continue from step 3".

The CLI has no such mode, and we didn't fake one in the UI. Partial re-execution of a pipeline whose earlier steps fed later ones is a good way to get confidently wrong output. If step 2 consumed step 1's output and step 5 consumed step 4's output, you can't just rerun step 3 without invalidating everything downstream.

So a failed run tells you plainly what went wrong – the actual stderr tail, not a shrug – keeps every completed step's output visible (that spend was real, and the work is often still useful), and offers exactly one recovery: Run again, which pre-fills a fresh run with the same workflow and input.

Your runs list is history you can trust: what ran, what it cost, what came out.

I'd rather give you a clean slate than a half-broken retry mechanism that produces garbage output.

What it costs: nothing new

There's no workflow fee and no new meter. A run's model calls flow through your account's hub key exactly like a session's – plan caps and credits decide, per published prices – and the machine bills per second while it works, like always.

The run page shows the aggregated cost the pipeline reported, so you can see what a promote actually costs you end to end. On the open models, it's typically cents.

Dry runs are free. And workflows are on every plan, free tier included – the free tier's one-at-a-time model calls just serialize the steps, which makes runs slower, not smaller.

Same contract as the CLI

If you already run workflows from the terminal, nothing changed and everything got a second surface. The panel drives the same octomind workflow binary on your machine, with the same tap resolution and the same machine-readable output contract the CLI exposes via --format jsonl:

# Machine-readable output
cat article.md | octomind workflow promote --format jsonl

One event per completed step. One aggregated cost at the end. A pipeline you tested locally behaves identically in the cloud, because it is identical.

That's also the direction this is headed. Today the library is the public tap. The plan is for every account to get its own tap – personal workflows, edited in the panel with the same dry-run validation, distributed to your machines through the exact mechanism tap content already uses.

One distribution system, not two.

Why pipelines beat chat for production work

I want to zoom out for a second. Why build this at all?

Chat is great for exploratory work. You don't know what you're looking for. You want to poke around, ask follow-ups, change direction mid-conversation. A session – a conversation where you steer turn by turn – is exactly right for that.

But production work is different. You have a contract. Input in, output out. You want repeatability. You want auditability. You want to know that if you run the same thing tomorrow, you get the same result.

Workflows give you that. They're not better than sessions – they're different. And for a whole class of problems, they're the right tool.

Here's what I mean:

Chat: "Help me figure out what's wrong with this code"
Workflow: "Review this diff and tell me if it's safe to merge"
Chat: "What should I post about this article?"
Workflow: "Turn this article into Twitter, LinkedIn, and Mastodon drafts"
Chat: "Help me analyze this data"
Workflow: "Turn this CSV into a decision-ready report with computed metrics"

The chat version is open-ended. The workflow version has a contract. Both are useful. I use both. But they're not the same thing.

The technical bit: how the pipeline actually runs

Under the hood, a workflow run is a state machine. Each step is an agent invocation with its own context, role, and constraints. The pipeline orchestrates these invocations, passing outputs between steps, handling loops, and aggregating costs.

The event stream is the key. Every step completion emits an event. The panel subscribes to that stream and renders it live. That's how you see steps light up, how loop counters increment, how the final cost gets computed.

Here's what a simplified event stream looks like:

{"event": "step_start", "step": "research", "role": "researcher"}
{"event": "step_complete", "step": "research", "output": "...", "cost": 0.002}
{"event": "step_start", "step": "write", "role": "writer"}
{"event": "step_complete", "step": "write", "output": "...", "cost": 0.004}
{"event": "step_start", "step": "audit", "role": "auditor"}
{"event": "audit_failed", "step": "audit", "reason": "..."}
{"event": "loop_iteration", "step": "write", "iteration": 2}
{"event": "step_complete", "step": "audit", "passed": true, "cost": 0.001}
{"event": "workflow_complete", "total_cost": 0.015, "artifacts": ["drafts/twitter.md", "drafts/linkedin.md"]}

The CLI and the panel both consume this same stream. That's why they behave identically – they're two different UIs over the same underlying contract.

What's next

If you haven't tried the cloud yet, it's open to everyone – no card, no invite. Create a machine, open Workflows, feed promote a blog post you like, and watch a team you didn't have five minutes ago argue itself into shippable drafts.

And if you're already running workflows from the CLI: nothing broke. Your taps still work. Your machines still work. You just got a browser option now.

The repo is at github.com/muvon/octomind. Apache-2.0, like everything we build. Pull it, run it, tell me what breaks.

This is the original article: Workflows Come to the Cloud

We Built an Invite System. We Deleted It Three Days Later.

Don Karter — Sun, 26 Jul 2026 15:18:29 +0000

Three days after launch, we killed the invite gate on Octomind Cloud machines.

Not paused. Not "temporarily opened." Deleted.

Here's what happened, why it was wrong, and what changed.

The Confession

At launch, machines were invite-only. We're bootstrapped – no investors – and hardware gets bought with revenue, not term sheets. A gate felt responsible. Don't let everyone in if you can't handle them.

Three days of production taught us the gate was solving a problem we didn't have yet, and creating one we definitely did.

Fleet had headroom. Bottleneck wasn't capacity – it was new users hitting a locked door and leaving before seeing what a machine actually is.

So we removed it. The invite system is gone from the product. Fewer moving parts, one honest answer to "can I try it?": yes.

What Octomind Cloud Is (Briefly)

Octomind Cloud is an agent runtime. Persistent Linux machines from $0.05/hr, real Docker inside, a hub of 21 models behind one key at published per-token prices, one wallet with caps.

Free tier: $0, $0.15/day usage, 1 Tiny machine, no card required.

The agent runs on these cloud machines, not your laptop. Sessions survive you closing the tab – keep running, full transcript when you come back.

Whole stack is open source Apache-2.0: octomind, octocode, octobrain, octohub.

What Three Days Taught Us

Day one: invites felt prudent. Don't oversubscribe a fleet you're funding yourself.

Day three: the prudent thing was creating friction for people who just wanted to see what this does.

We watched the funnel. Signups were fine. Activation dropped at the invite wall. People weren't hitting capacity limits – they were hitting a locked door and bouncing.

The invite system wasn't protecting us from overload. It was protecting us from users.

That's backwards.

What Changed

As of today, every Octomind account – free tier included – can create a machine and have it running in under a minute. No codes, no waitlist, no earning your way in.

What this means:

New users sign up, create a machine – real Linux box, whole agent toolchain, web terminal, Docker inside – in under a minute
Free tier, no card
Unredeemed codes are moot
Referral program still alive (both earn storage and credit bonuses)
Paid plans still buy bigger everything (caps, sizes, slots) – just no longer buy a key to a door that's now open

We're still bootstrapped. Fleet grows as subscriptions fund hardware. If demand outruns capacity, machine creation says so plainly rather than silently degrading.

Honesty over optics.

Try It

Open the panel, sign up free (no card), create a machine. Pick a name, pick a size, done – boots in seconds. Open a session and put the agent to work.

GitHub: https://github.com/muvon/octomind

Full post: https://octomind.run/blog/cloud-invites-removed

We Taught Our Code Search to Think — Here's What Broke (and What Fixed It)

Don Karter — Sun, 26 Jul 2026 08:14:36 +0000

Octocode is our open source semantic code search engine built in Rust (Apache-2.0). It's the code-search layer behind Octomind, and you can grab it at https://github.com/muvon/octocode.

Last month we added an LLM reasoning step to the retrieval pipeline. The first version made things worse.

Hit@10 dropped 7 points. Recall@10 dropped 7.5 points. The model was pruning away true positives because it thought they weren't relevant.

Here's what we learned, what we shipped, and why "add contextual retrieval" is not the universal win everyone claims.

The Problem: Similarity Is Not Relevance

Octocode uses hybrid retrieval — vector search plus keyword overlap. Works well. But there's a gap: the snippet that shares the most tokens with your query is often not the code that answers it.

Ask "where do we decide a request is retryable" and the similarity ranker hands you:

The retry config struct
The retry constant
The test that names the word four times

The actual function that makes the call? Rank seven.

Vector search ranks by similarity. Hybrid adds keyword matching. But neither reads the code. Neither knows what the code does.

First Attempt: Pure LLM Reranking

We added an LLM reasoning step after hybrid retrieval. The model reads the candidate code bodies and re-ranks by whether they actually answer the query. No new index, no reindexing — just a reranker sitting between retrieval and results.

Tested on 127 queries. Here's what happened:

Metric	Before	After	Change
MRR	0.595	0.752	+0.157
NDCG@10	0.658	0.758	+0.100
Hit@10	0.913	0.843	−0.071
Recall@10	0.886	0.811	−0.075

MRR and NDCG went up. The ranking quality improved. But Hit@10 and Recall@10 dropped.

The LLM was being too aggressive. It returned only what it judged relevant and quietly discarded true positives at ranks 6–10. Better ranking head, worse recall floor.

The Fix: Fuse, Don't Replace

Don't let the LLM replace the ranking — fuse it with the hybrid ranking via Reciprocal Rank Fusion (RRF).

score = 1/(k + hybrid_rank) + reasoning_weight * 1/(k + reasoning_rank)

Hybrid rank always contributes — that's your recall floor. Reasoning rank drives the head.

Final fused results on the same 127 queries:

Metric	Before	After	Change
MRR	0.595	0.809	+36%
NDCG@10	0.658	0.833	+27%
Hit@5	0.827	0.953	+0.126
Hit@10	0.913	0.969	+0.056
Recall@5	0.777	0.924	+0.147
Recall@10	0.886	0.944	+0.058

Every metric up. Hit@5 at 0.953 means nineteen times out of twenty the answer is in the top five.

What We Tuned (and What Didn't Matter)

Reasoning weight: Best at 2.0. Weight 5 buys nothing and costs recall.

Candidates: 25 is the sweet spot. We tried 40 — worse across the board.

Context level: Full code bodies win by a lot. Signatures-only was the worst performer.

LLM temperature: 1.0 beat 0.3 and 0.0. Counterintuitive, but the model reasons better with normal sampling. Stiff decoding made it dumber.

What Did NOT Work: Contextual Retrieval

Anthropic's contextual retrieval approach — adding descriptions at index time — gets recommended everywhere. We tested it.

Hit@5: −0.008

Recall@10: −0.019

It trades recall for ranking. On code, that's a net loss. "Add contextual retrieval" is cargo-culted advice — not a universal win. We didn't ship it.

How to Turn It On

The feature is in Octocode's master branch now (not yet released — landing soon). Off by default, one config flag:

[search.reasoning]
enabled = true
model = "deepseek:deepseek-v4-flash"
max_candidates = 25
context_level = "full"
reasoning_weight = 2.0
final_top_k = 10

Or swap in any other provider:model:

[search.reasoning]
enabled = true
model = "openai:gpt-4o-mini"
max_candidates = 25
context_level = "full"
reasoning_weight = 2.0
final_top_k = 10

Any provider:model works. One LLM call per semantic search. structural_search stays pure grep. No reindex needed.

The Takeaway

LLM reranking works – but only if you keep the hybrid ranking as a floor. Fusion beats replacement. And don't cargo-cult "best practices" without testing them on your actual workload.

Octocode is open source under Apache-2.0. The benchmark suite, ground truth dataset, and raw results are all in the repo: https://github.com/muvon/octocode

This feature is merged to master now, not yet released – landing soon.

Full writeup with all the numbers and tuning details: https://muvon.io/blog/reasoning-retrieval-code-search

The Tap Registry Grew Beyond Code: 108 Agents, 27 Domains, and Workflows That Verify Their Own Work

Don Karter — Fri, 24 Jul 2026 10:30:00 +0000

This post originally appeared on octomind.run/blog/octomind-tap-registry-expansion. Cross-posted to dev.to.

The cloud launch got the attention this week. But something quieter happened alongside it — the tap registry went through its biggest expansion since taps were first introduced, and it's worth a closer look if you're building with agents.

The default registry now ships 108 agents across 27 domains, 71 capabilities, and 18 workflows. All available with one command. No downloads, no marketplace accounts, no setup.

Here's what changed and why it matters.

What a tap actually is

If you haven't used taps before, the mental model is simple: a tap is a git-hosted registry of TOML manifests. Each manifest defines one agent — its system prompt, model, tools, MCP servers. Octomind fetches the manifest at runtime and merges it into your config.

Nothing gets installed. There's no global state to rot.

octomind run developer:rust      # a Rust specialist
octomind run lawyer:immigration  # an immigration-law explainer
octomind workflow harden         # a multi-step security audit pipeline

The tag format is domain:spec. The official muvon/octomind-tap ships as the default registry. You can browse it on the site, and adding your own registry is a single octomind tap away.

The point: agents should be distributed like code — reviewable in a diff, not installed like apps.

The registry isn't just for developers anymore

This is the biggest shift. The tap registry started as a developer toolbox, but most problems people bring to an agent aren't code problems.

This week added 17 new agents across domains you wouldn't expect in a dev tool:

Family — family:parenting, family:eldercare, family:bereavement (an agent for the paperwork and decisions that arrive at the worst possible time, written with the gravity that moment deserves)
Finance — finance:tax, finance:retirement, finance:insurance
Health & wellbeing — doctor:sleep, coach:wellbeing, coach:negotiation
Life — lawyer:immigration, home:realty, vet:general, vet:behavior, vehicle:mechanic, tutor:coding, content:fiction

These aren't replacements for licensed professionals. They're structured, well-prompted assistants that help you prepare, organize, and understand. The value is that the preparation — which is honestly 80% of the work — no longer starts from a blank page.

There's also assistant:concierge, which routes across the whole ecosystem. A bare octomind run discovers matching specialists by intent.

Four new workflows that close the loop

Workflows are multi-step TOML pipelines. Each step gets its own agent, model, and toolset, with validate scripts acting as deterministic quality gates between steps.

The shared pattern across all four new workflows: don't stop at the first answer — loop until the check passes.

harden

An OWASP-lens security audit of your current repo, then a fix ⇄ re-audit loop that runs until findings are resolved and your project's own checks stay green.

octomind workflow harden

upgrade

Dependency bumps — named packages, or safe patch/minor by default — running in a bump ⇄ verify loop until your build is green.

scout

This one's interesting. It's the phase before anyone has an idea: take a field or market, mine it for real evidenced pain through three blind parallel sweeps, and come back with vetted opportunities instead of vibes.

learn

Bootstraps a project knowledge base. Reads the codebase, extracts durable facts, promotes them into .box/ where they're indexed and readable by every agent that works on the project afterward.

All four run the same way as everything else — octomind workflow — reading from stdin, writing to stdout, scriptable by construction. That brings the registry to 18 workflows total.

Agents that remember the project

A new octobrain-backed knowledge capability gives agents durable project memory. assistant:knowledge curates it, the learn workflow seeds it from the codebase.

Facts get extracted once, stored in the repo's .box/ directory, and become available to every specialist that touches the project afterward. You run learn once. Every agent after that starts with context instead of zero.

The unglamorous fixes that actually matter

Two things that don't make headlines but fix real pain:

Dependency installs now work in containers and CI. Tap agents bootstrap their own tooling (Node for MCP servers), and those scripts assumed sudo exists. Root containers — Docker, CI images — don't have it. Every dep script now escalates through a helper that runs bare as root, uses sudo when present, and tells you exactly what's missing otherwise.

Web search needs no API key. The websearch capability defaults to DuckDuckGo now. One less credential between a fresh install and a working researcher agent.

Use it anywhere

Everything works on a local Octomind install (one curl command) and comes preloaded on cloud machines. Models route through the hub with octohub:auto routing.

What to do next

Browse the full registry at octomind.run/tap — see what's available before you build something from scratch
Read the manifests at github.com/Muvon/octomind-tap — they're TOML files, fully reviewable, and contributions are open
Try a workflow — octomind workflow harden on a repo you care about and see the loop-until-green pattern in action

If there's a specialist you keep wishing existed, it's one manifest away. And if you build one, we'd genuinely like to see it.