DEV Community: Andrew

LiteParse v2 Review: LlamaIndex's Rust PDF Parser for Agents

Andrew — Mon, 01 Jun 2026 11:48:18 +0000

TL;DR

LiteParse v2 is LlamaIndex's June 2026 rewrite of their open-source document parser — the same spatial-layout extraction core that powers their LlamaParse cloud product, but now written entirely in Rust and shipped as native packages for Python, Node.js/TypeScript, and the browser via WASM. It's positioned as the answer to a real, specific problem: agents need to read PDFs fast during a reasoning loop, and existing tools either choke on layout (pypdf, pdfplumber) or block on a VLM call (Docling, LlamaParse cloud).

Key facts:

Rust core built on top of the PDFium C library for native text extraction
Multi-language bindings: Rust crate, Python (pip install liteparse), Node.js (@llamaindex/liteparse), browser WASM
One CLI (lit) that ships with every package — same flags whether you installed via cargo, npm, or pip
Formats: PDF natively; DOCX/XLSX/PPTX via LibreOffice; PNG/JPG/TIFF via ImageMagick
Selective OCR: bundled Tesseract.js, or plug in PaddleOCR/EasyOCR HTTP servers for higher accuracy
Spatial output: text + bounding boxes, layout-preserved plain text, or rendered PNG page screenshots for multimodal LLM follow-up
8,557 GitHub stars, ~3,006 stars this week — currently trending on the GitHub Rust board
Apache-2.0 license, zero cloud calls, zero Python dependencies at the core
The README claims up to 100x faster than the v1 Python implementation

If you've been writing one-off pypdf + regex hacks every time an agent needs to skim a PDF, LiteParse is the first OSS parser that's clearly designed for agents first and humans second.

Quick Reference

# Install (pick one — they all give you the same `lit` CLI)
npm i -g @llamaindex/liteparse
pip install liteparse
cargo install liteparse

# Parse a PDF, write layout-preserved text
lit parse report.pdf -o report.txt

# Structured JSON with bounding boxes
lit parse report.pdf --format json -o report.json

# Just pages 1–5 and page 10
lit parse report.pdf --target-pages "1-5,10"

# Generate page screenshots for visual reasoning
lit screenshot report.pdf -o ./screens --pages "1-3"

Why LiteParse Exists

The pitch from LlamaIndex's launch post is unusually specific. They've spent years building LlamaParse into a production document-intelligence cloud service, and along the way noticed that most of the time, agents don't need the heavyweight VLM pipeline. They need text — quickly — to decide their next move.

The current landscape forces a bad choice:

Fast but inaccurate — pypdf, pdfminer, Markitdown will hand you a string of text in milliseconds but mangle tables, lose column boundaries, and silently skip scanned pages with no OCR fallback.
Accurate but slow — Docling, MarkItDown-pro, LlamaParse cloud all run a vision model. Quality is great, but a 50-page PDF can take 30–120 seconds, which is forever inside an agent loop.
Local but ugly — Tesseract alone, no spatial reconstruction, no screenshot fallback, no agent-friendly API.

LiteParse picks a deliberate middle: native text extraction from PDFium with grid-based spatial projection (so columns and tables survive), selective OCR for scanned pages, and a screenshot command for the moments when the agent decides it wants to look at the page itself. The whole thing is a CLI subprocess away from any agent framework, no API key, no network.

Installation

The smartest design choice is that the CLI is identical across runtimes. Pick whatever your project already has:

Node.js / TypeScript:

npm i -g @llamaindex/liteparse
# or as a library
npm i @llamaindex/liteparse

Python:

pip install liteparse

Rust:

# CLI
cargo install liteparse

# As a library
cargo add liteparse

Browser (WASM):

npm i @llamaindex/liteparse-wasm

The first run will download the PDFium native library (≈10 MB) and the Tesseract.js OCR data files (~22 MB for English; more per added language). After that everything is offline.

A nice detail: the Python package ships as a thin wrapper over the same Rust binary, so Python, Node, Rust, and the CLI all hit the same code path. Same trick ruff and uv use.

Real Code Examples

Node.js / TypeScript

import { LiteParse } from "@llamaindex/liteparse";

const parser = new LiteParse({ ocrEnabled: true });
const result = await parser.parse("./contract.pdf");

console.log(result.text);          // layout-preserved plain text
console.log(result.pages[0].bbox); // bounding boxes per page

// Render specific pages to PNG for VLM follow-up
const screenshots = await parser.screenshot("./contract.pdf", {
  pages: [1, 2, 3],
  outputDir: "./screens",
});

Python

from liteparse import LiteParse

parser = LiteParse(ocr_enabled=True)
result = parser.parse("contract.pdf")

# Plain text, layout preserved
print(result.text)

# Per-page structured data with bounding boxes
for page in result.pages:
    for block in page.blocks:
        print(block.text, block.bbox)

Inside an Agent Loop

This is the pattern LlamaIndex actually built it for — text-first, screenshot-fallback. Pseudocode for any agent framework (LangGraph, LlamaIndex agents, OpenClaw, raw OpenAI tool-calling):

def read_document(path: str, question: str) -> str:
    # Fast pass: try text only
    text = LiteParse().parse(path).text
    if model_can_answer_from(text, question):
        return text
    # Slow path: render screenshots, send to a VLM
    screenshots = LiteParse().screenshot(path, pages="all")
    return vlm_describe(screenshots, question=question)

The text pass on a 50-page PDF takes ~1.5 seconds on a 2023 MacBook Pro. That's a number you can put inside an agent's reasoning step without thinking about it.

Layout Preservation in Practice

The key idea is "preserve layout rather than detect structure." Most parsers try to recognize "this is a table" and convert it to markdown — which adds failure modes. LiteParse projects text onto a spatial grid and emits something like:

Name        Age     City
John        25      NYC
Jane        30      LA

Modern LLMs already read ASCII tables, code indentation, and READMEs natively. Skipping the table-detection step makes the parser faster, simpler, and — counterintuitively — often more accurate for downstream LLM reading.

Architecture, Briefly

The pipeline is short: PDFs pass through directly; DOCX/XLSX/PPTX convert via LibreOffice; images via ImageMagick — everything becomes a PDF internally. PDFium pulls native text and positions in one pass; pages without an extractable text layer get routed to Tesseract (or your configured external OCR server); results merge with positions preserved and project onto a 2D grid that reconstructs columns and tables as ASCII. Output is JSON with bounding boxes, plain text, or PNG screenshots. No model weights, no GPU, no Python interpreter for the Python package.

Community Reactions

The reception has been notably warm for an LLM-adjacent tool launch:

The Show HN post from March 2026 for LiteParse v1 stayed on the front page most of the day, with commenters comparing it favorably to pypdf and Markitdown for agent use cases. The recurring sentiment: "finally a PDF parser that doesn't need to be a microservice."
LocalLLaMA Reddit picked up the v2 Rust rewrite within hours of release — the comment thread immediately compared latency numbers to Markitdown and pypdf4llm, with one user reporting 80–100x speedups on a 200-page legal contract. Caveat: speedups are largest on text-heavy PDFs; scanned-image PDFs are bound by Tesseract, which is the same library every parser uses.
The r/LangChain crowd flagged the OpenAI-skill packaging as the smartest part — npx skills add run-llama/llamaparse-agent-skills --skill liteparse drops a SKILL.md straight into Claude Code, Codex, or any other agent harness that follows the agentskills.io spec. No glue code.
A few sharper critiques on HN around the LibreOffice dependency for DOCX/XLSX/PPTX — it's heavy (~400 MB install) and a known source of crashes in containers. LiteParse's authors acknowledge this and have an open issue exploring a pure-Rust DOCX path.

Benchmarks

The team published their own benchmark dataset on HuggingFace along with the eval pipeline in-repo. The methodology is honest about its limits: they generate Q&A pairs from page screenshots, manually audit the dataset, then evaluate parsers with an LLM judge.

Two takeaways from their numbers:

Against non-VLM parsers (pypdf, PyMuPDF, Markitdown), LiteParse wins on QA accuracy across most document types and is the latency leader on large documents.
They explicitly don't claim to beat VLM-based parsers like LlamaParse cloud, Docling, or Mistral OCR on hard layouts (dense tables, multi-column scientific papers, charts). The README routes you to LlamaParse for those — fair and refreshingly upfront.

If you want to verify the claims on your own corpus, the eval scripts will run on your local PDFs in 10–15 minutes.

Honest Limitations

LiteParse is a focused tool, and the things it doesn't do are mostly intentional. Plan around these:

Complex tables get flattened, not structured. A multi-row-header pivot table from an SEC 10-K will become ASCII with column alignment, not a JSON schema. For structured table extraction, you want LlamaParse cloud, Docling, or a dedicated table model like Unstructured.io's hi_res.
Handwritten or low-quality scans are Tesseract-limited. Pointing it at a PaddleOCR or EasyOCR HTTP server helps a lot, but you're now running a Python service alongside, which partially defeats the "single binary" pitch.
LibreOffice is the DOCX/XLSX/PPTX backend. It works, but it's a ~400 MB system dependency. In Docker, you'll want apt install libreoffice-core and accept the image bloat, or pre-render Office docs to PDF elsewhere.
No semantic block detection. It won't tell you "this is a heading", "this is a caption", "this is a footnote". You get spatial text. If you need structural roles, that's a downstream step (a small LLM call on the parsed output usually works).
No streaming output. The CLI buffers the entire result before printing. For very large documents (1,000+ pages) you'll want to chunk via --target-pages.
Bounding-box coordinates are in PDF user-space units, not pixels. Fine once you understand it, but the docs could be clearer for first-time users plotting boxes on rendered screenshots.

How It Compares

A quick honest map of where LiteParse fits versus the tools you might already be using:

vs pypdf / pdfminer.six: LiteParse wins on layout, OCR fallback, and agent ergonomics. pypdf wins on zero dependencies and pure-Python install (if that matters for your stack).
vs Microsoft's markitdown (covered in our skim-list): MarkItDown is broader (covers audio transcripts, HTML, Outlook) but slower on PDFs and Markdown-output-oriented. Use both: MarkItDown for non-PDF formats, LiteParse for PDFs in the hot path.
vs LlamaParse cloud: LiteParse is for agents in a reasoning loop; LlamaParse is for "I need to nail every table on every page once at ingest time." Use LiteParse for runtime reads, LlamaParse for nightly batch ingestion of your knowledge corpus.
vs Docling: Docling is more accurate on hard layouts because it uses a vision model, but it requires GPU compute or a long CPU run. LiteParse is the right default; reach for Docling when LiteParse's output isn't enough.
vs Mistral OCR API: Cloud-only, paid, but excellent on hard scans. Use LiteParse first; fall back to Mistral OCR only on pages where Tesseract failed.

For a longer treatment of how parsing fits into an AI-agent retrieval pipeline, see our review of PageIndex's vectorless RAG approach and our walkthrough of CocoIndex's incremental indexer — both pair naturally with LiteParse as the document-extraction stage.

FAQ

Is LiteParse a replacement for LlamaParse cloud?

No, and LlamaIndex is explicit about that. LiteParse handles the fast-path text-extraction case for agents. LlamaParse cloud is the heavyweight VLM-powered pipeline for production document-intelligence work where you need perfect tables, structured JSON outputs, and premium OCR. They're complementary: use LiteParse in your agent loop, LlamaParse at batch-ingest time for your most valuable documents.

Do I need a GPU to run LiteParse?

No. LiteParse is pure CPU. PDFium and Tesseract both run on CPU and parallelize across cores automatically. A 50-page text-only PDF takes ~1–2 seconds on a modern laptop. Scanned PDFs are slower because Tesseract is the bottleneck — a 50-page scanned PDF takes 30–60 seconds depending on core count. There's no cuda flag because there's no model to accelerate.

Can I use it in a serverless function?

Yes for PDF-only workflows — the Node.js package bundles PDFium and Tesseract as native binaries that work on AWS Lambda's Amazon Linux 2 environment. Cold start is around 800 ms because of the binary unpack. For DOCX/XLSX/PPTX, you'll need LibreOffice in the runtime, which usually means a container-image-based Lambda. The browser WASM build is also viable for client-side parsing — handy when documents shouldn't leave the user's machine.

How does it handle scanned PDFs?

Automatically. If a page has no extractable text layer, LiteParse routes it to Tesseract.js. You can opt in to a higher-accuracy external OCR by running PaddleOCR or EasyOCR as an HTTP server and passing --ocr-server http://localhost:8000/ocr. The repo includes reference servers for both. Any OCR engine that returns text + bounding boxes works.

Will it work with LangChain / LlamaIndex / OpenClaw / Claude Code?

Yes, in a few ways. As a library, import it directly in Python or TypeScript. As a CLI, shell out from any agent that can run subprocesses. As a skill file, drop it into any AgentSkills-compatible harness (Claude Code, Codex, OpenCode, Cursor) with one command. For LlamaIndex specifically, there's a first-party LiteParseReader that mirrors the existing LlamaParseReader interface.

What's the license and can I use it commercially?

Apache 2.0 — as permissive as it gets. Commercial use, redistribution, and modification are all explicitly allowed. The PDFium dependency is BSD-licensed; Tesseract is Apache-2.0; LibreOffice is LGPLv3 (but only used as an external subprocess for Office-format conversion, which keeps your application licensing clean). No usage caps, no telemetry, no API key, no rate limits.

The Bottom Line

LiteParse v2 is the first OSS PDF parser I'd actually drop into an agent without a wrapper. The combination of one CLI across four runtimes, a single Rust binary, no Python interpreter for Python users, sub-2-second runtimes on real-world PDFs, and the agent-first design (text-first, screenshot-fallback) hits a sweet spot the existing tools have all missed in one direction or another.

If you're building anything where an LLM needs to skim a PDF inside a reasoning loop — RAG ingestion, contract review agents, research assistants, invoice readers — install it today and replace your pypdf calls. For batch ingestion of your most valuable corpus, keep LlamaParse cloud (or Docling) for the heavy lifting. The two are designed to coexist, and the LlamaIndex team built LiteParse exactly so you don't have to round-trip to a cloud service every time an agent gets curious about a document.

Dograh Review: Open-Source Vapi Alternative for Voice AI

Andrew — Sat, 30 May 2026 11:06:56 +0000

TL;DR

Dograh is an open-source, self-hostable voice AI platform from YC alumni Zansat Technologies — a drop-in alternative to Vapi and Retell. It's currently trending on GitHub with 3,776 stars and 1,141 gained this week, BSD 2-Clause licensed, and built around a drag-and-drop workflow builder for production voice agents.

One Docker command to go from zero to a working voice bot in under 2 minutes
BYOK across the stack — bring your own LLM, STT, TTS, or use Dograh's defaults
MCP-native — drive voice workflows directly from Model Context Protocol
Telephony built-in — Twilio, Vonage, Telnyx, Cloudonix, plus human handoff
BSD 2-Clause — every line is yours to modify, no SaaS lock-in
Visual workflow builder with a QA node that grades your prompts
Python-based backend, modular components, easy to swap pieces
Test mode + in-dashboard web calls so you can talk to your bot before deploying

If Vapi and Retell are the "Stripe of voice AI" (closed, per-minute, hosted), Dograh is the n8n of voice AI — open and self-hostable.

Quick Reference


Repository	github.com/dograh-hq/dograh
License	BSD 2-Clause
Language	Python
Maintainer	Zansat Technologies (YC alumni)
Stars	3,776 (+1,141 this week)
Install	One `docker compose up` command
SDKs	Python (`dograh-sdk`), Node (`@dograh/sdk`)
Dashboard	`http://localhost:3010` after install
Telephony	Twilio, Vonage, Telnyx, Cloudonix
Languages	English (expandable)

What Is Dograh?

Dograh is a self-hosted voice AI platform — the open-source analog of Vapi and Retell. If you've ever shipped a voice agent on either, the workflow is familiar: pick STT, an LLM, a TTS, wire up a script, attach a phone number, route to a human when things go sideways.

The difference is where it runs and who owns the data. Vapi and Retell are hosted SaaS products priced per minute, with proprietary internals. Dograh ships as Docker images you run on your own infrastructure, with every component swappable and every line of code under BSD 2-Clause.

It's built around three layers:

A visual workflow builder — drag-and-drop nodes for greeting → qualify → branch → transfer → end. Nodes include a built-in QA node that analyzes prompt quality across the rest of your workflow.
A voice engine — handles real-time STT → LLM → TTS with low-latency interaction, barge-in handling, and the speech-to-speech path when you want it.
A platform layer — testing, tracing, recordings, an in-dashboard web caller so you can talk to your bot mid-build, and an MCP server so other AI agents can trigger or compose voice workflows.

The repo has been climbing GitHub Trending; the week of May 23–30, 2026 it picked up over a thousand stars, helped by a Better Stack hands-on video and "finally, an open Vapi" posts in selfhosted communities.

Install in 60 seconds

The honest claim — "zero to working bot in under 2 minutes" — actually holds. Here's the one command:

curl -o docker-compose.yaml \
  https://raw.githubusercontent.com/dograh-hq/dograh/main/docker-compose.yaml \
  && REGISTRY=ghcr.io/dograh-hq ENABLE_TELEMETRY=true \
  docker compose up --pull always

A few things this does that are worth flagging:

Pulls all images from GHCR (ghcr.io/dograh-hq) — no DockerHub rate-limit pain
Sets ENABLE_TELEMETRY=true by default; flip it to false if you don't want anonymous usage data leaving your box
First boot takes 2–3 minutes while it warms up models and downloads images. After that, restarts are seconds.

When it's up, open http://localhost:3010, pick Inbound or Outbound, name your bot (e.g. Lead Qualification), describe the use case in 5–10 words (e.g. Screen insurance form submissions for purchase intent), and click Web Call. You're talking to it.

No API keys required for the first run. Dograh ships with auto-generated keys and its own LLM/TTS/STT stack so you can test the platform without sourcing 4 different credentials first. Once you're ready, you can connect your own:

LLM: OpenAI, Anthropic, Groq, any OpenAI-compatible endpoint (point it at vLLM, Ollama, or a local Llama deployment)
STT: Deepgram, AssemblyAI, your own Whisper instance
TTS: ElevenLabs, Cartesia, OpenAI TTS, or a self-hosted Piper/XTTS
Telephony: Twilio, Vonage, Telnyx, Vobiz, Cloudonix — and the integration layer is modular enough to add others

For remote deployment (the way you actually ship to prod), the Docker Deployment Guide walks through a remote server setup with HTTPS via a reverse proxy.

Building a real voice agent

Here's a minimal outbound lead-qualification flow, built in the visual builder and then represented as JSON (Dograh stores workflows as JSON so they're version-controllable):

{
  "workflow": "lead-qualification-v1",
  "nodes": [
    {
      "id": "greeting",
      "type": "speak",
      "prompt": "Hi, this is Aria from {{company}}. I'm calling about your recent quote request for {{product}}. Do you have a minute?",
      "next": "consent_check"
    },
    {
      "id": "consent_check",
      "type": "branch",
      "model": "claude-haiku-4",
      "prompt": "Did the caller agree to continue? Reply with one word: yes, no, or callback.",
      "routes": {
        "yes": "qualify_budget",
        "no": "polite_exit",
        "callback": "schedule_callback"
      }
    },
    {
      "id": "qualify_budget",
      "type": "speak_listen",
      "prompt": "Great. Quick one — what's the ballpark monthly budget you're working with?",
      "extract": {
        "budget_usd": "number"
      },
      "next": "qualify_timeline"
    },
    {
      "id": "qualify_timeline",
      "type": "speak_listen",
      "prompt": "And when are you hoping to have this in place?",
      "extract": {
        "timeline": "string"
      },
      "next": "qa_node"
    },
    {
      "id": "qa_node",
      "type": "qa",
      "checks": ["prompt_clarity", "data_capture_complete", "tone_appropriate"],
      "next": "transfer_or_end"
    },
    {
      "id": "transfer_or_end",
      "type": "branch",
      "condition": "budget_usd >= 500",
      "true_route": "transfer_to_human",
      "false_route": "polite_exit"
    }
  ]
}

The qa node is the genuinely novel piece. Most voice platforms make you build evaluation yourself — recordings sitting in S3, somebody listens, prompts get tweaked. Dograh ships a node that runs prompt-quality checks on your other nodes as part of the workflow, so you get a built-in regression signal when you change a prompt.

Calling it from code

Once the workflow exists, you can trigger calls from your backend via the Python or Node SDK:

from dograh import Client

client = Client(api_key="dograh-local-...")  # auto-generated, find it in the dashboard

call = client.calls.create(
    workflow_id="lead-qualification-v1",
    phone_number="+15551234567",
    variables={
        "company": "Acme Insurance",
        "product": "term-life-quote",
    },
    transfer_targets=["+15559876543"],  # human handoff
    webhook_url="https://your-app.example.com/dograh-events",
)

print(call.id)

Webhooks fire on call lifecycle events (call.started, call.transferred, call.completed) with the full transcript and any extracted variables. From there it's normal CRUD into your CRM.

MCP-native

This is the bit that distinguishes Dograh from older OSS voice frameworks. Dograh exposes its workflows as an MCP server, so Claude Code, Cursor, or any MCP-aware agent can list workflows, trigger test calls, and read transcripts directly.

In practice that means you can say "call my lead-qualification workflow on +15551234567 and summarize the result" to your coding agent during development, instead of clicking through the dashboard. It also opens the door to agent-driven dialing — orchestrator agents that pick which voice workflow to fire based on context.

How Dograh compares

Dograh's README puts up a comparison table that's mostly accurate, but it's worth widening the field. The voice AI OSS landscape has four players that matter:

	Dograh	Pipecat	LiveKit Agents	Vocode
License	BSD 2-Clause	BSD 2-Clause	Apache 2.0	MIT
Self-hostable	✅ One Docker command	✅ Python framework	✅ (LiveKit infra)	✅
Visual workflow builder	✅ Built-in	❌ Code-only	❌ Code-only	❌ Code-only
MCP support	✅ Native	⚠️ Manual	⚠️ Manual	❌
Telephony	✅ Twilio, Vonage, Telnyx, Cloudonix	✅ Twilio, Daily	✅ via SIP	✅ Twilio, Vonage
BYOK LLM/STT/TTS	✅ Any provider	✅ Any provider	✅ Any provider	✅ Any provider
Built-in QA / eval	✅ QA node	❌ DIY	❌ DIY	❌ DIY
Maintained by	Zansat (YC)	Daily.co	LiveKit	Vocode team

Where Dograh wins: the visual builder + QA node + MCP combo. If you're hiring product-ops folks to maintain voice workflows, the visual builder removes the "every change needs a deploy" problem. The QA node removes the "we don't know why our bot got worse" problem.

Where Pipecat/LiveKit/Vocode might win: if your team is engineers-only and you want maximum flexibility, raw Python frameworks give you more room. LiveKit specifically has stronger scale guarantees for multi-thousand concurrent calls.

Compared to Vapi/Retell: you're trading per-minute SaaS pricing and a polished hosted UX for ownership, data residency, and no vendor lock-in. For high-volume use cases (>10k minutes/month) Dograh's economics dominate even at moderate self-host overhead. For low-volume prototypes, Vapi is still faster to demo.

Honest limitations

A week of poking at Dograh and reading the issue tracker, here's what would actually bite you in production:

English only at present. The README says "expandable to other languages" but the shipping config is English-tuned. If your audience is Spanish or Hindi, expect to wire up your own multilingual STT/TTS pipeline.
Single-tenant by design. The Docker setup is built for "I run this for my company." If you want to host voice AI for multiple customers, you're building the multi-tenancy layer yourself or running multiple stacks.
The visual builder is great until it isn't. Anything past ~30 nodes gets unwieldy. The JSON export is your escape hatch for diff-based version control.
No native browser-call SDK yet. The dashboard has an in-browser caller; the public SDKs are server-side (Python, Node). If you want a voice widget on a website, you're plugging telephony in via Twilio's Voice JS SDK as the bridge.
Telemetry on by default. Anonymous, but flip ENABLE_TELEMETRY=false if your security team will care — and they will care.
Community is brand new. The Slack and GitHub Discussions are active but small. Expect "founders personally onboard early adopters" levels of support, not "thousands of Stack Overflow answers."

None of these are dealbreakers, but they're the things that turn into Friday-afternoon problems if you don't plan around them.

Community reactions

The Show HN-adjacent threads and r/selfhosted discussions have a consistent through-line:

The criticism, mostly around the size of the docs ("API reference needs more depth") and the early-stage feel of the multilingual story, lines up with what you'd expect from a sub-2K-star repo that's growing into its production audience.

Who should use Dograh

Good fit:

Teams currently spending $1K+/month on Vapi or Retell and feeling the per-minute squeeze
Use cases with strict data-residency requirements (healthcare, finance, EU regulated)
Engineering teams that want voice workflows under version control
Anyone building a voice-first product where the bot logic is core IP and you don't want it in someone else's cloud
Agencies running voice campaigns for multiple clients (one stack per client, or build your own multi-tenancy)

Bad fit:

Prototypes where you just need a demo by Friday — use Vapi, decide later
Teams without a deployable infrastructure baseline (no Docker, no ops culture)
Non-English customer bases until the multilingual story matures
Use cases that demand 99.99% uptime out of the box without you investing in HA

FAQ

Is Dograh actually free?

Yes — BSD 2-Clause license means you can self-host, modify, and even ship a commercial product built on top of it without paying Dograh anything. The optional managed cloud at app.dograh.com is usage-based if you'd rather not run infrastructure yourself.

What hardware do I need to self-host Dograh?

For testing, any machine with Docker and 4 GB RAM works. For production, a $40–80/month VPS (Hetzner CPX31, DigitalOcean Premium, Vultr High-Frequency) handles dozens of concurrent calls. The bottleneck is almost always your STT/TTS provider's latency, not Dograh's compute footprint. Heavy local model use (running your own Whisper + XTTS) pushes you toward GPU instances.

Can Dograh replace Vapi for production workloads?

For most workloads, yes — telephony integration, real-time STT/LLM/TTS, transcription, recordings, and webhooks are all there. The trade-offs are operational: you take on uptime, scaling, and observability yourself. Teams running >10K minutes/month report meaningful savings even after factoring in DevOps overhead.

How does Dograh handle conversation interruptions (barge-in)?

Dograh's voice engine handles barge-in (where the caller starts speaking before the bot finishes) at the audio layer using VAD-based interruption detection. It's competitive with Vapi out of the box, though tuning the silence thresholds for noisy environments is something you'll do per-deployment.

Can I drive Dograh from Claude Code or another AI agent?

Yes — Dograh ships an MCP server, so any MCP-aware agent (Claude Code, Cursor, OpenCode, Codex CLI) can list workflows, trigger calls, and read transcripts. This is one of the genuine differentiators vs. Pipecat/LiveKit, which require you to wire MCP yourself.

What's the difference between Dograh and Pipecat?

Pipecat is a Python framework for building voice agents in code; Dograh is a full platform with a visual builder, dashboard, QA tooling, and telephony pre-wired. If you want maximum flexibility and don't mind writing every flow as Python, Pipecat is excellent. If you want product-ops people maintaining workflows without touching code, Dograh is the better fit. Both are BSD 2-Clause; they're not really competing for the same role on a team.

Does Dograh work with my existing Twilio account?

Yes — bring your Twilio account SID and auth token, point a number at Dograh's webhook, and you're live. The same is true for Vonage, Telnyx, and Cloudonix. The integration layer is modular enough that adding a new SIP provider is a feature PR, not a fork.

Verdict

Dograh is the most usable open-source voice AI platform I've installed this year. The Docker-up-and-running story is genuinely 2 minutes, the visual builder + QA node combo is the right level of abstraction for production voice workflows, and the MCP-native angle puts it in a different conversation than older OSS players.

It's not as polished as Vapi for your first 10 minutes — Vapi's onboarding is a masterclass — but Dograh is dramatically better at hour 10, day 30, and month 6, when ownership, debuggability, and cost compound. If you're paying voice-AI SaaS bills today and the bills are getting larger every month, this is the project to clone, run on a Hetzner VPS for a weekend, and benchmark against your existing stack.

Star, fork, ship. github.com/dograh-hq/dograh

CodeGraph Review: Pre-Indexed Knowledge Graph for AI Agents

Andrew — Thu, 28 May 2026 12:24:46 +0000

TL;DR

CodeGraph is an open-source MCP server from Colby McHenry that gives AI coding agents a pre-indexed, AST-based knowledge graph of your codebase. It's currently the #2 repo on GitHub Trending this week — 31,090 stars total, 21,424 gained in seven days. Highlights:

MCP-native — auto-configures Claude Code, Cursor, Codex CLI, opencode, Hermes Agent, Gemini CLI, Antigravity, and Kiro
Tree-sitter AST extraction across 20+ languages — symbols, call graphs, import chains, and references stored in local SQLite
No embeddings, no vector DB, no API keys — pure structural graph + FTS5 full-text search
Auto-syncing via native FSEvents/inotify with debounced re-indexing
35% cheaper, 57% fewer tokens, 46% faster, 71% fewer tool calls in published median-of-4 benchmarks on Claude Opus 4.7 across 7 real codebases
Framework-aware routing for 14 web frameworks (Django, Flask, FastAPI, Express, NestJS, Laravel, Rails, Spring, ASP.NET, etc.)
Cross-language bridging for Swift ↔ ObjC and React Native (legacy bridge, TurboModules, Fabric, Expo)
Apache 2.0, bundles its own runtime, one-command install on macOS, Linux, or Windows

If Claude Context is the vector-DB answer to "stop my AI agent from grepping the same files 50 times," CodeGraph is the structural answer — and the two are looking like complementary halves of the same problem.

Quick Reference


Repository	github.com/colbymchenry/codegraph
License	Apache 2.0
Language	TypeScript
Author	Colby McHenry
Stars	31,090 (+21,424 this week)
Install	`curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh \
NPM	{% raw %}`@colbymchenry/codegraph` (also works via `npx`)
Storage	Local SQLite, FTS5 full-text search
Requires	Nothing (bundled runtime) — or Node ≥ 18 for npm install

What Is CodeGraph?

When Claude Code answers an architecture question — "how does X talk to Y here?" — it doesn't actually know your codebase. It launches Explore sub-agents that fan out across grep, glob, and Read, follow imports, re-read the same files, and spend most of their token budget on discovery before they can answer.

CodeGraph attacks that discovery cost by pre-computing what those sub-agents would otherwise have to learn from scratch. It parses your repo with tree-sitter, extracts every symbol, call site, import, and reference, and stores them as nodes and edges in a local SQLite database. An MCP server exposes that graph through three primary tools: codegraph_context, codegraph_explore, and codegraph_status.

No embeddings, no API keys, no Docker, no vector store. The SQLite file lives in .codegraph/. A native filesystem watcher debounces edits and re-indexes only what moved.

The pitch: the agent already pays for tool calls — make those tool calls answer with structure instead of bytes.

Why It's Trending Now

Three things converged this week:

1. Reproducible benchmarks. The README's headline numbers — 35% cheaper, 57% fewer tokens, 46% faster, 71% fewer tool calls — are eye-catching, but what convinced Hacker News was the methodology: claude -p Opus 4.7 headless, --strict-mcp-config, 4 runs per arm, median reported, raw per-repo numbers published. Reproducible, not marketing.

2. Structural counter-pitch to vector search. A month after Claude Context brought BM25 + embeddings to MCP, CodeGraph argues you don't need either. Symbol graphs are deterministic, lossless, and don't drift when you rename a function. For "who calls processOrder?", a graph answers in one query. Embeddings have to guess.

3. Zero infrastructure. No vector DB, no embedding API, no API keys. codegraph init -i and the MCP server wires into every coding agent on your machine.

How It Works

CodeGraph is three layers stacked on top of tree-sitter:

Parse layer. Tree-sitter grammars produce ASTs for 20+ languages — TypeScript, JavaScript, Python, Go, Rust, Java, C#, PHP, Ruby, C, C++, Objective-C, Swift, Kotlin, Dart, Lua, Luau, Svelte, Liquid, and Pascal/Delphi. CodeGraph walks each AST and extracts symbol declarations, references, imports, exports, and call sites.

Graph layer. Symbols become nodes; calls, references, and imports become edges. Stored in SQLite with an FTS5 virtual table for name search. On top of that, CodeGraph layers two enrichments:

Framework-aware route recognition for 14 web frameworks. Django path(), FastAPI @router.get(...), Express router.post(...), NestJS @Controller + @Get, Rails get '/x', to: 'users#index', Spring @GetMapping, ASP.NET [HttpGet] — each becomes a route node linked to its handler. "Who handles /api/orders?" now jumps straight to the controller.
Cross-language bridging for iOS / React Native / Expo. Swift ↔ ObjC @objc auto-bridging, JS NativeModules.X.fn(...) linked to ObjC RCT_EXPORT_METHOD or Java/Kotlin @ReactMethod, Fabric components, TurboModule specs, native → JS event emitters, and Expo's Module { Name("X"); AsyncFunction("fn") } DSL. The kind of thing static parsers normally drop on the floor.

MCP layer. A Node server speaks MCP and exposes three primary tools: codegraph_context(area) (entry points + related symbols), codegraph_explore(symbol) (full source plus immediate neighbors), and codegraph_status (pending edits, freshness banner).

The Benchmark, In Detail

The README's benchmark is the most-discussed part of the project. Here's the raw shape (medians of 4 runs per arm, Claude Opus 4.7 headless, --strict-mcp-config):

Codebase	Language · Files	Cost WITH → WITHOUT	Tokens	Time	Tool calls
VS Code	TS · ~10k	$0.60 → $0.80	601k → 2.8M	1m 10s → 2m 26s	8 → 55
Excalidraw	TS · ~640	$0.43 → $0.90	344k → 3.5M	48s → 2m 58s	3 → 79
Django	Py · ~3k	$0.59 → $0.67	739k → 1.2M	1m 19s → 1m 38s	9 → 19
Tokio	Rust · ~790	$0.42 → $2.41	379k → 2.6M	53s → 3m 2s	4 → 53
OkHttp	Java · ~645	$0.47 → $0.47	636k → 730k	42s → 1m 1s	6 → 11
Gin	Go · ~110	$0.37 → $0.47	444k → 675k	44s → 1m 0s	6 → 10
Alamofire	Swift · ~110	$0.61 → $1.14	1.0M → 2.8M	1m 17s → 2m 27s	12 → 69

Three things stand out:

Gains scale with codebase size. On VS Code (~10k files) the no-CodeGraph arm needs 55 tool calls and reads 2.8M tokens. On Gin (~110 files), native grep is already cheap and CodeGraph's edge collapses to 21% cheaper. ROI is real around the 1k-file mark, dramatic above 5k.
Tool calls drop harder than tokens. On Excalidraw it's 3 vs 79 — a 96% reduction. The WITHOUT arm spawns Explore sub-agents that themselves read files, multiplying calls. CodeGraph short-circuits the tree at the parent.
OkHttp is the honest outlier. 2% cheaper, tokens barely moved. Its query hits a small, localized part of the code where grep was already efficient. Not every question rewards a graph.

The author's own caveat is healthy: CodeGraph only helps when queried directly — if the parent agent delegates exploration to a file-reading sub-agent, the graph never gets called and becomes overhead. The system prompt shim matters as much as the index.

Getting Started

The installer is one command:

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh

# Windows PowerShell
irm https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.ps1 | iex

# Or via npm
npx @colbymchenry/codegraph

Then, in your project root:

cd your-project
codegraph init -i

The -i flag launches an interactive installer that detects every coding agent on your system — Claude Code, Cursor, Codex CLI, opencode, Hermes Agent, Gemini CLI, Antigravity, Kiro — and writes the MCP config and instruction shim into each one you select. No manual JSON editing.

Open Claude Code and start asking architecture questions. The first session triggers the initial index (seconds for small repos, minutes for VS Code-scale). The filesystem watcher keeps it current after that.

To uninstall: codegraph uninstall strips MCP config from every agent it touched; codegraph uninit removes .codegraph/ from the project. Cleanest uninstall story in the MCP ecosystem.

Real-World Use Cases

Onboarding to a large codebase. Drop CodeGraph on a 100k-line monorepo, ask "how does authentication flow work end to end?" — get a routed answer hitting middleware, the JWT verifier, and the user store in one tool call.
Refactor impact analysis. "What breaks if I change the signature of processPayment?" One codegraph_explore call returns every caller and callee.
Cross-language iOS apps. Swift ↔ ObjC and React Native bridge support means "where does this JS prop end up on the native side?" actually resolves across the boundary.
Cutting Claude/OpenAI API spend. Reddit reports in r/ClaudeCode put the saving at 30–50% on long sessions, consistent with the README's 35% median.
Auto-fresh long sessions. The file watcher debounces and re-indexes, so multi-hour agent sessions don't drift from the working tree.

First Impressions From the Community

Reception on Hacker News and r/ClaudeCode this week has been warm — partly the reproducible benchmark, partly the painless install:

The common gripe is the converse: for fuzzy semantic questions ("find the place that probably handles edge cases in checkout"), a symbol graph isn't as good as a vector store. Several commenters already run CodeGraph and Claude Context side by side.

Honest Limitations

CodeGraph is impressive, but worth knowing before you bet on it:

Symbol graphs don't help with fuzzy questions. If you don't know what the symbol is called, the graph can't find it. Vector search degrades more gracefully here.
First-index time scales with repo size. A 10k-file TS repo takes a couple of minutes to parse. Incremental after that, but the initial wait is real.
Tree-sitter coverage varies. Top-tier languages (TS, JS, Python, Go, Rust, Java) are excellent. Pascal/Delphi and Liquid work but with thinner symbol coverage. Anything outside the 20+ list falls back to FTS5 text search.
Benchmark is one question per repo. Real sessions ask many questions; some graph queries handle worse than grep. Median field cost lands closer to the lower half of the table than the headline average.
No multi-repo workspace yet. Index lives per project. Microservices repos mean multiple .codegraph/ directories with no cross-repo query.

Who Should Use This (And Who Shouldn't)

Use CodeGraph if:

You work on a 1k+ file codebase and your AI agent burns tokens on discovery
You want zero infrastructure — no embedding API, no vector DB, no Docker
You hop between Claude Code, Cursor, and Codex CLI and want one index across all of them
You work on iOS / React Native and lose context at the bridge

Skip CodeGraph if:

Your repo is under ~300 files (native grep is fast enough)
Your questions are mostly semantic ("find the place that handles X" without knowing the symbol name) — Claude Context fits better
You can't run a local SQLite file or are in a sandboxed environment with no filesystem watcher (CODEGRAPH_NO_DAEMON=1 works, but you'll need manual codegraph sync)

CodeGraph vs. Claude Context vs. Other Indexers

The MCP code-search space has crystallized into two distinct approaches:

Tool	Approach	Storage	Local-only	MCP	Multi-client	Best for
CodeGraph	AST symbol graph	SQLite	✅ always	✅	✅ 8+	Structural questions, refactors
Claude Context	Hybrid BM25 + embeddings	Milvus / Zilliz	⚠️ via Ollama	✅	✅ 13+	Semantic questions, vague queries
Cursor Codebase Index	Embeddings	Cursor cloud	❌	❌	❌ Cursor only	Cursor users
Aider repo-map	Tree-sitter graph	In-memory	✅	❌	❌ Aider only	Aider users
Sourcegraph Cody	Hybrid + graph	Sourcegraph	✅ enterprise	❌	❌	Enterprise
Continue @codebase	Embeddings	LanceDB	✅	❌	❌ Continue only	Continue users

Symbol graphs vs. embeddings is not a winner-take-all fight. The two answer different question shapes. CodeGraph nails "who calls X?", "what's the route for /api/orders?", "what breaks if I rename Y?". Claude Context nails "find the place that handles the corner case where users have two emails." Several commenters this week are running both — the graph as the structural source of truth, the vector store for fuzzy recall.

If you only have time to add one MCP server this week and your codebase is over 1k files: CodeGraph is the lower-friction install (no API keys, no Docker) and lands the bigger token reduction on architecture questions, which is what most agents waste budget on.

FAQ

Does CodeGraph work with Cursor and Codex CLI, or only Claude Code?

It auto-configures eight clients: Claude Code, Cursor, Codex CLI, opencode, Hermes Agent, Gemini CLI, Antigravity IDE, and Kiro. The interactive installer (codegraph init -i) detects which are present and lets you choose. The MCP server itself is client-agnostic — anything that speaks MCP can connect.

How does CodeGraph compare to Claude Context (Zilliz's MCP indexer)?

CodeGraph uses a tree-sitter symbol graph in local SQLite. Claude Context uses BM25 + dense embeddings in Milvus. CodeGraph wins on structural questions ("who calls X?", "what's the route for Y?") and zero-infrastructure setup. Claude Context wins on fuzzy semantic questions and recall when you don't know the symbol name. They're complementary, and several teams run both.

Is CodeGraph really 100% local?

Yes. No API keys, no embeddings, no external services. The graph is a SQLite database in .codegraph/ inside your project. The MCP server runs as a local Node process. Nothing leaves your machine.

Do I need Node.js installed?

No. The native installer (install.sh / install.ps1) bundles its own runtime. If you already have Node, npx @colbymchenry/codegraph works too — both paths land at the same binary.

How does the auto-sync work? Do I need to run `codegraph sync` manually?

You don't. A native filesystem watcher (FSEvents on macOS, inotify on Linux, ReadDirectoryChangesW on Windows) catches every file change and re-indexes after a 2-second debounce (tunable). On reconnect, the MCP server does a fast (size, mtime) + content-hash reconciliation. Manual codegraph sync only matters in sandboxed environments where the watcher is disabled.

Are the benchmark numbers reproducible?

Yes. The README publishes the methodology (claude -p Opus 4.7 headless, --strict-mcp-config, 4 runs per arm, median reported), the exact query for each of the 7 repos, and the raw WITH → WITHOUT medians per cell. You can clone any of the benchmark repos at --depth 1 and run the same comparison yourself.

Bottom Line

CodeGraph is the strongest pitch yet for symbol graphs as the structural layer beneath AI coding agents. The benchmark is reproducible, the install story is the lowest friction in MCP code search, and the 21,424 stars in seven days suggest a lot of developers had the same thought: I'm tired of watching Claude Code re-grep the same files.

If your repo is over 1,000 files and you're paying for an agent's tool calls, CodeGraph likely pays for itself in this week's Claude bill. Run it alongside Claude Context for fuzzy recall and you have the closest thing to a complete MCP code-intelligence stack that exists today.

Repo: github.com/colbymchenry/codegraph — Apache 2.0 licensed, 31K stars and gaining ~3K/day.

HyperFrames Review: HeyGen's HTML-to-Video for AI Agents

Andrew — Thu, 28 May 2026 11:09:54 +0000

TL;DR

HyperFrames is the open-source rendering engine HeyGen quietly carved out of its internal video stack and dropped on GitHub in mid-April 2026. The pitch fits on a sticker: write HTML, render video, built for agents. Compositions are plain index.html files with data-start and data-duration attributes; a headless Chrome renderer seeks each frame, FFmpeg encodes it, and the result is a deterministic MP4. No React, no proprietary timeline, no bundler. Key facts:

Apache 2.0, no per-render fees, no commercial-use thresholds
21,894 GitHub stars and growing fast — one of the most-starred new AI repos of Q2 2026
Node.js 22+ and FFmpeg are the only hard requirements
Adapter-based animation: GSAP, CSS, Lottie, Three.js, Anime.js, WAAPI, or your own runtime
Deterministic by design: same HTML in, same bytes out — built for CI, regression tests, and reproducible renders
Agent skills shipped on day one for Claude Code, Cursor, Gemini CLI, Codex
AWS Lambda render path included for distributed rendering at scale
In production at HeyGen with community use at tldraw and TanStack
Repository: github.com/heygen-com/hyperframes

The interesting bet here isn't "another video framework." It's that AI coding agents already know HTML — so if your video format is HTML, agents become competent video editors essentially for free. After a week of trying it, that claim mostly holds up.

Why "HTML as a video format" is the real story

Most video frameworks treat the timeline as a first-class object. You drag clips, set keyframes, and the tool serialises that into JSON, JSX, or a proprietary DSL. HyperFrames inverts that. The timeline is the HTML document:

<div id="stage" data-composition-id="launch"
     data-start="0" data-width="1920" data-height="1080">
  <video class="clip" data-start="0" data-duration="6"
         data-track-index="0" src="intro.mp4" muted playsinline></video>

  <h1 id="title" class="clip" data-start="1" data-duration="4"
      data-track-index="1">Launch day</h1>

  <audio data-start="0" data-duration="6" data-track-index="2"
         data-volume="0.5" src="music.wav"></audio>

  <script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>
  <script>
    const tl = gsap.timeline({ paused: true });
    tl.from("#title", { opacity: 0, y: 40, duration: 0.8 }, 1);
    window.__timelines = window.__timelines || {};
    window.__timelines.launch = tl;
  </script>
</div>

That's a complete six-second composition: background video, fade-in title, background music at half volume. Open index.html in Chrome, hit play, and you can preview it without any tooling. Run npx hyperframes render and the same file becomes an MP4.

The trick that makes it work is the paused: true GSAP timeline registered on window.__timelines.<id>. The renderer doesn't play your animation in wall-clock time — it seeks it. For each frame, it sets the timeline's progress to the correct point, waits for layout, and screenshots. Animations stay frame-accurate at 60fps and you can shard a render across Lambda workers without drift.

For agents this is a huge unlock. Claude Code doesn't need to learn a new "compositions and sequences" mental model — it writes the kind of HTML it already writes ten times a day, sprinkles in a few data attributes from the skill prompt, and the framework handles the rest.

Install and first render

# Prereqs: Node 22+, FFmpeg
brew install ffmpeg     # macOS
sudo apt install ffmpeg # Ubuntu/Debian

# Scaffold a project
npx hyperframes init my-video
cd my-video

# Preview in browser with live reload
npx hyperframes preview

# Render to MP4
npx hyperframes render

The init template gives you a working composition, a hyperframes.config.json, and a folder structure that won't surprise anyone who's used Vite or Next. Preview runs on port 4200 by default with live reload. First render of a 10-second 1080p composition takes 35–50 seconds on an M2 Pro — not blazing, but the deterministic property means identical re-renders hit cache.

The CLI is non-interactive by default: no [y/N] prompts, no spinners that confuse an agent's pty parser. Whoever designed this clearly had claude and codex in mind, not humans typing into a terminal.

Using HyperFrames from Claude Code

This is where it stops being "another Remotion alternative" and starts being interesting. One command installs the official skill:

npx skills add heygen-com/hyperframes

Then in a Claude Code session:

What I got back, end-to-end and unattended:

A scaffolded composition directory
An index.html with three tracks correctly wired
A GSAP timeline with the fade-in and a slide-up caption
A preview run, then a render run, then a ffprobe on the output to verify duration
A summary message with the file path and runtime

This is the production loop the skills teach: plan → write HTML → wire animation → add media → lint → preview → render. The lint step is doing more work than it sounds — it catches missing data-duration, audio tracks that overrun the composition, and timeline IDs the renderer can't find. Those are the exact errors that would otherwise make an agent loop endlessly trying to figure out why its render is silent or black.

After a week of using it daily, the main failure mode is the agent over-engineering animations: defaulting to Three.js when CSS transforms would do, or pulling in Lottie for what should be a text-shadow keyframe. The catalog mostly fixes that:

npx hyperframes add flash-through-white   # shader transition
npx hyperframes add instagram-follow      # social overlay
npx hyperframes add data-chart            # animated chart

If you point the agent at the catalog up front (Use blocks from the HyperFrames catalog where possible), output quality goes up noticeably.

HyperFrames vs Remotion: the honest comparison

Remotion has been the default answer for "video as code" since 2021. It's mature, it's well-documented, and Remotion Lambda is genuinely impressive. HyperFrames is openly inspired by it. So when does each one make sense?

Question	HyperFrames	Remotion
Authoring model	HTML + CSS + seekable animation	React components
Build step	None — `index.html` plays as-is	Bundler required
Agent handoff	Plain HTML files	JSX/TSX in a React project
Animation timing	Frame-accurate via seek adapters	Wall-clock; care needed for determinism
Distributed rendering	Local + AWS Lambda	Remotion Lambda (mature, more features)
License	Apache 2.0	Source-available Remotion License
Commercial cost above N renders	Zero	Paid tiers above thresholds
Component ecosystem	Catalog (small but growing)	Large React ecosystem
Learning curve for a React team	Slight relearn	Already there
Learning curve for a coding agent	Trivial	Higher (full React project mental model)

If you have a React team already shipping Remotion compositions, there's no reason to switch — Remotion is more mature for human authors and its Lambda story has years of polish on HyperFrames'. If you're building an automated content pipeline where the author is an agent, HyperFrames is genuinely a step change. The Apache 2.0 license also matters at scale: HeyGen explicitly removed the per-render and seat-count thresholds that creep into the Remotion License once you're past hobby usage.

The deterministic-output property is a real technical win regardless of which side you're on. Byte-identical MP4s from byte-identical HTML means you can put renders behind a content hash and skip rebuilds, run regression tests with diff, and shard work across workers without seams.

What people are saying

The launch hit r/ClaudeCode and r/ClaudeAI in mid-April and the reaction has been more measured than the typical "next-Remotion-killer" thread. A representative slice:

"Output is byte-identical across runs, so CI caching and shard-parallel rendering work. There is a frame-adapter pattern that lets GSAP, Lottie, CSS, Three.js, and (experimentally) Remotion coexist in one composition." — top comment on the r/ClaudeAI launch thread, by a contributor
"Setup isn't trivial and sometimes you spend more time debugging [Remotion] than creating. So when I saw HyperFrames calling itself 'agent-native' I got curious." — r/buildinpublic
"This is the right primitive. Video as deterministic function of HTML. Everything else is a wrapper." — top reply on the r/coolgithubprojects thread

The skeptical takes are mostly about ecosystem maturity ("the catalog is thin compared to React/Remotion ecosystem") and about whether HTML is really the right abstraction for complex sequences. Both are fair. The counter-argument from the maintainers is that "agents write HTML" beats "humans write JSX" by enough margin to justify the smaller initial surface area.

Worth noting: the Medium piece from AI Engineering and The Agent Times both lead with "deterministic video primitive" rather than "Remotion killer," and I think that's the more accurate framing.

Honest limitations after a week

Things that bit me, in rough order of severity:

1. Render speed isn't competitive on a single machine. Headless Chrome seek-per-frame is slower than Remotion's parallel-frame approach for simple compositions. A 30-second 1080p render that takes ~3 minutes locally takes ~25 seconds on Remotion Lambda. The HyperFrames AWS Lambda story closes that gap but the bundle and setup is heavier than Remotion's.

2. Audio sync is fiddly with seek-based animation. Because animations are seeked rather than played, audio that's tightly choreographed to timeline events needs careful data-start math. The default audio mixer handles offsets and volume fine, but Lottie-style audio-reactive animation isn't really a supported pattern yet.

3. The catalog is small. Right now it's transitions, overlays, captions, charts, and a handful of effects. If you want a Lottie-style ecosystem of polished components, you're going to build them. The blocks that exist are well-made, but expect to write a lot of HTML.

4. Git LFS for the test baselines is ~240MB. If you're cloning to contribute, the GIT_LFS_SKIP_SMUDGE=1 flag in the README is your friend. The repo will build fine without the LFS content; you just can't run the visual regression suite.

5. No first-party React adapter (yet). There's an experimental Remotion frame adapter, but if you have a deep React component library you want to reuse, you're going to wrap it yourself or wait. For greenfield work this doesn't matter; for migrations it might.

6. The Studio is "available, evolving." The browser-based editor exists but it's clearly not the primary surface — that's the agent skills. If you want a polished GUI editor with timeline scrubbing and visual track management, this isn't it yet.

None of these are deal-breakers. The framework is doing exactly what it advertises; it's just early.

When HyperFrames is the right call

Reach for it when:

You're building an automated content pipeline where an agent generates the video (newsletter highlights, PR changelog reels, social posts from blog content)
You need deterministic output for CI caching, regression tests, or shard-parallel rendering
The Apache 2.0 license matters because you'll be doing thousands of renders
Your team is comfortable writing HTML/CSS/JS and doesn't want to adopt React just to make a video
You want a low-ceremony local preview that doesn't require a dev server

Skip it (for now) when:

You already have a Remotion pipeline that works and a React team to maintain it
You need polished visual editing — Studio isn't there yet
You need the maximum-throughput cloud render path with zero setup; Remotion Lambda is more mature
Your sequences are heavily React-component-driven and porting them isn't worth it

FAQ

Q: Is HyperFrames actually open source, or is this a HeyGen-services play with an OSS wrapper?
A: It's Apache 2.0 with no usage caps, no telemetry requirement, and no "you must use our cloud for renders" clause. The Lambda render package is a self-deploy SDK — you stand up the Lambda functions in your own AWS account. HeyGen presumably benefits from ecosystem mindshare and from people who eventually want hosted authoring, but the OSS framework stands on its own.

Q: Do I need HeyGen credentials, an API key, or any cloud account to use it?
A: No. Local CLI usage requires nothing except Node 22+ and FFmpeg. The AWS Lambda path requires an AWS account (yours, not HeyGen's). hyperframes.dev is an optional community playground for sharing compositions.

Q: How does it compare to Manim or Motion Canvas?
A: Manim and Motion Canvas are oriented toward mathematical/educational animation with their own DSLs. HyperFrames is generalist video composition with HTML as the format. For lecture-style geometric animations Manim is still better; for product videos, social cuts, or dashboards-to-video, HyperFrames fits better.

Q: Can I use existing React components inside a HyperFrames composition?
A: Sort of. You can render React to a DOM node and have HyperFrames screenshot it like anything else, but you'll lose the determinism benefits if your components rely on wall-clock state. The clean integration story is to render React to static HTML+CSS first and let HyperFrames handle timing. The experimental Remotion adapter is the closest thing to first-class React support today.

Q: What's the actual ceiling — could I render a feature-length film with this?
A: Technically yes; practically no one would. HyperFrames is optimised for short-to-medium compositions (seconds to a few minutes) where determinism, agent authorship, and HTML-native authoring are the wins. For anything over 10 minutes you'd want a different toolchain — or you'd want to compose many HyperFrames outputs together with FFmpeg directly. The deterministic primitive does make that kind of pipeline easier.

Q: Will HeyGen keep maintaining this or quietly abandon it?
A: It's used in production at HeyGen itself, commits come from active engineers there, and HeyGen staff respond on the community Discord. Listed adopters include tldraw and TanStack. The risk profile feels similar to corporate-sponsored OSS that's load-bearing for the sponsor.

Verdict

HyperFrames is the first video framework I've used where "AI agent writes the video" feels like the intended workflow rather than a happy accident. The HTML-as-format bet is genuinely insightful: it dramatically lowers the surface area an agent has to learn while giving humans an authoring model they already know. The deterministic rendering property is the kind of unsexy technical decision that pays off for years.

It's not as mature as Remotion. The catalog is thin, render throughput on a single machine is unimpressive, and the Studio is still a work in progress. But for the specific job of "wire video generation into an automated content pipeline driven by Claude Code or similar," nothing else comes close right now.

If you're building agent workflows that need to produce video, install the skill and try a prompt today. If you're a Remotion shop with React infrastructure and human authors, there's no need to switch. If you're somewhere in between, watch the catalog and Studio progress over the next two quarters — that's where the gap will close.

For me, this goes on the short list of repos I expect to be load-bearing in agent stacks by the end of 2026.

Try it: github.com/heygen-com/hyperframes · Docs · Catalog · Discord

OpenBrief Review: Local-First Video AI Summarizer 2026

Andrew — Wed, 27 May 2026 11:07:28 +0000

TL;DR

OpenBrief is an open-source desktop app that does what most people actually want from a "video AI tool": paste a link, get a transcript, get a grounded summary, and chat with the content — without uploading anything to a SaaS. It hit 88 points on Show HN on May 26, 2026, and it's basically a polished GUI for yt-dlp + Whisper with an LLM layer wired in for summaries and Q&A.

Key facts:

Tauri v2 desktop app — macOS, Windows, and Linux from a single Rust/React codebase
Bundled yt-dlp — paste a YouTube/Vimeo/arbitrary URL, it downloads locally
On-device transcription — Whisper (via whisper.cpp and transcribe-rs) runs against the audio on your machine
Bring-your-own LLM — OpenAI GPT, Anthropic Claude, Google Gemini, or OpenRouter (DeepSeek) for summaries and chat
Grounded summaries — markdown briefs with timestamped takeaways tied back to transcript spans
Chat with media — Q&A against the transcript using the LLM of your choice
Text-to-speech — listen to the generated brief (Supertonic 3 / Qwen3-TTS on the roadmap)
AGPL-3.0 licensed, monorepo organized as a pnpm/Turborepo workspace
Honest limitation: LLM summaries are still cloud-by-default — local Gemma 4 / Qwen3-ASR support is on the roadmap but not shipped yet

If you've ever wanted a private alternative to NotebookLM or Read.ai for your own video backlog, OpenBrief is the most complete open-source attempt to date.

Why "Local-First" Video AI Suddenly Matters

For three years, the default flow for "summarize this video" has been: upload to a SaaS, get a summary, hope they don't train on it. Read.ai, Fireflies, Otter, NotebookLM — they all do good work, but every minute of audio you feed them is a minute on someone else's GPU.

For a lot of use cases that's fine. For others — legal depositions, internal all-hands recordings, anything under NDA, anything you don't want to count toward a per-minute pricing tier — it isn't. The market quietly noticed:

yt-dlp keeps gaining stars (currently 100K+) because people want their videos as files, not stream-only assets
whisper.cpp made on-device transcription genuinely usable on a MacBook
Local LLMs (Llama 3, Qwen 3, Gemma 3, DeepSeek V4) crossed the "good enough for summaries" line in 2025

What was missing was a polished desktop app that stitched these together with a sane UX. OpenBrief is the first Show HN this year that does it without feeling like a research demo.

What Makes OpenBrief Different

OpenBrief isn't doing any one thing nobody else has done. The interesting part is how it composes them.

1. Tauri v2 instead of Electron

Most "local AI" desktop apps reach for Electron because the team already knows React. OpenBrief uses Tauri v2, which means:

Rust backend, system webview frontend — installer is ~10MB instead of ~150MB
Native filesystem access for the helper sidecar (yt-dlp, ffmpeg) without IPC gymnastics
Lower memory footprint while a 90-minute Whisper transcription is running

The src-tauri/ directory exposes Rust commands that the React renderer calls. The helper sidecar — a separate binary that wraps yt-dlp and ffmpeg — is bundled at build time via pnpm setup:dev-sidecars. This is the right shape for a desktop tool that needs to shell out to native binaries; it avoids the "user has to install yt-dlp themselves" trap that kills adoption of a lot of similar projects.

2. Grounded summaries, not free-floating ones

A "grounded summary" in OpenBrief means each bullet in the generated brief is tied to a timestamp span in the original transcript. Click a takeaway → jump to the spot in the audio/video. This is the same idea NotebookLM popularized with its citation-numbered answers, and it matters for one reason: summaries hallucinate, transcripts don't. When the summary says "the speaker proposed a 40% price cut at 12:34," you can verify that's actually what they said.

The implementation is straightforward — the prompt template forces the LLM to emit JSON with { text, start_ts, end_ts } for each point, and the UI renders them as clickable chips. If you've built RAG over transcripts before, you've written approximately this code; OpenBrief just ships it as the default.

3. Pluggable model layer

The README's "Model Support" table is honest about what's shipped vs. roadmap:

Model type	Supported today	Roadmap
Speech-to-text	Whisper	Parakeet, Qwen3-ASR
Text-to-speech	(placeholder)	Supertonic 3, Qwen3-TTS
LLM	OpenAI, Anthropic, Gemini, OpenRouter (DeepSeek)	Local Gemma 4
Video embeddings	—	Frame/clip semantic search

The architectural win is that all four slots are service abstractions, not hardcoded. You wire your key into settings, the rest of the app doesn't care. Adding a local LLM later is "implement the LLM service interface against Ollama" — not "rewrite the summary pipeline."

Install and First Run

OpenBrief is currently distributed as a source build — the Tauri team hasn't pushed signed installers yet. You need:

# Prerequisites
# - Node.js ^22.21.0
# - pnpm 11.0.9
# - Rust + Cargo
# - Tauri v2 platform prerequisites for your OS
#   (Xcode on macOS, MSVC on Windows, webkit2gtk on Linux)

git clone https://github.com/tantara/openbrief
cd openbrief/client
pnpm install

# If pnpm flags ignored native build scripts on first install:
pnpm approve-builds  # approve the listed packages
pnpm install         # rerun

# Build and run the desktop app
cd apps/tauri
pnpm setup:dev-sidecars     # builds the yt-dlp helper sidecar
pnpm prepare:media-assets   # downloads Whisper model + ffmpeg
pnpm dev                    # launches the desktop window

First-run experience:

App opens to an empty library.
Paste a YouTube URL into the import bar.
The helper sidecar shells out to yt-dlp, downloads the audio (or video), and stores it in your local app data directory.
Whisper kicks off in a background worker. On an M2 MacBook Air, a 30-minute video transcribes in ~3 minutes against whisper-base. The bundled model size and the underlying whisper.cpp build determine real-world speed.
Once the transcript exists, the Summarize button calls your configured LLM with the grounded-summary prompt.
The right-hand pane shows the brief with clickable timestamps; the chat box at the bottom lets you ask follow-up questions against the transcript.

Configuring API keys

Settings → Models. Each provider gets its own key field:

OpenAI: sk-... — used for gpt-4o, gpt-4o-mini, or whatever model id you set
Anthropic: sk-ant-... — Claude models for summary + chat
Google: Gemini API key
OpenRouter: sk-or-... — routes to DeepSeek and 100+ others, cheap for bulk summarization

Keys are stored in the platform secure store (Keychain on macOS, Credential Manager on Windows, libsecret on Linux), not in plaintext config.

Real Use Cases

A few patterns that justify the install:

Conference talk backlog. I have ~40 saved YouTube talks I'll "watch later." OpenBrief into a library, summarize each, scan the briefs, watch the three that earn it. This is the use case the Show HN comments kept coming back to.

Podcast research. Drop a 90-minute episode in, ask: "Did they mention any specific tools or products?" The chat-with-transcript flow surfaces names you'd never catch on a normal listen.

Internal recordings. All-hands, customer interviews, sales calls — anything you can't or shouldn't upload to a SaaS. The transcript stays on disk, the summary is generated by your own API key (which you can route to a self-hosted LLM via OpenRouter or an OpenAI-compatible proxy).

Course / lecture notes. Long-form educational content compresses well into timestamped briefs. The grounded format makes it easy to re-watch the parts you actually need.

What the Show HN Thread Said

Sentiment in the HN thread was warm but pointed:

"Basically a GUI for yt-dlp with AI on top" — the maintainer's own characterization, and the thread mostly agreed that's a feature, not a bug. Wrapping a powerful CLI tool in a clean desktop UX has product value.
Local LLM gap — the most common request was support for Ollama / llama.cpp for the summary step. Right now BYO-key works fine but the "local-first" claim has an asterisk while the LLM call still goes to a cloud API by default.
Comparisons to NotebookLM — several commenters framed it as "the open-source NotebookLM I've been waiting for," which is roughly accurate for video/audio specifically. NotebookLM still has the edge on multi-source synthesis and audio overviews.
Why Tauri over Electron — a few people appreciated the small installer size; Tauri v2 is becoming the default pick for new local AI tools (Jan, LM Studio's recent versions, Bolt, OpenBrief).

Who Should Use This (and Who Shouldn't)

Use OpenBrief if:

You watch / produce a lot of long-form video or audio content
You want transcripts and summaries to stay on your machine
You already pay for at least one LLM API and want to extract more value from that key
You're comfortable with a source build for now (signed installers coming)

Skip it (or wait) if:

You want fully local end-to-end — local Gemma 4 / Qwen3-ASR are on the roadmap but not shipped
You need team collaboration features — this is a single-user desktop app today
You need real-time meeting transcription — OpenBrief is post-hoc, not live (use Whisper-Live or Fireflies for that)
You're on a low-spec machine — Whisper transcription is CPU/GPU-heavy; a 90-minute video takes meaningful time on older hardware

Comparison with Alternatives

Tool	Local-first	Open source	Video download	Grounded summary	Chat	Cost
OpenBrief	✅ (transcript)	✅ AGPL-3.0	✅ yt-dlp	✅	✅	Free + your LLM API
NotebookLM	❌	❌	❌	✅	✅	Free (Google account)
Read.ai	❌	❌	❌	✅	✅	$0.04/min uploads
Otter.ai	❌	❌	❌	✅	✅	$8.33/mo+
MacWhisper	✅	❌	❌	Limited	❌	$20–60 one-time
Whisper.cpp + custom	✅	✅	Manual	DIY	DIY	Free + dev time

The honest read: NotebookLM is still better for multi-source research with audio overviews. OpenBrief is better when privacy or per-minute cost is the constraint, or when you want one place for your personal video library.

Architecture: How a Single Import Actually Flows

For developers considering forking or contributing, here's the request lifecycle when you paste a URL:

[React UI: paste URL]
       │
       ▼  Tauri command: import_url
[Rust core] ──► [Helper sidecar: yt-dlp]
       │              │
       │              └─► writes .mp4/.m4a to app data dir
       │
       ▼  Tauri command: start_transcription
[Whisper worker (whisper.cpp via transcribe-rs)]
       │
       └─► writes transcript.json with { segments: [{start, end, text}] }
              │
              ▼  React reads transcript, renders timeline
              │
              ▼  User clicks "Summarize"
       [LLM service: OpenAI/Anthropic/Gemini/OpenRouter]
              │  prompt enforces grounded JSON schema
              ▼
       [Summary stored with timestamp links → rendered as clickable chips]

Every step is replaceable. The LLMService interface in packages/api/ is a few dozen lines; bolting on Ollama is straightforward, and the GitHub Issues already have a PR draft from a contributor doing exactly that.

Limitations Worth Knowing About

"Local-first" still routes summaries to cloud LLMs by default. Until local Gemma 4 ships, the transcript stays local but the summary prompt (which includes the transcript) goes to whichever API key you configured. If that's a dealbreaker, run a local OpenAI-compatible endpoint like LiteLLM or Ollama's OpenAI-compatible mode and point OpenBrief at http://localhost:11434.
No signed installers yet. Source build only on May 2026. On macOS that means xcode-select --install is a prerequisite.
Whisper model is fixed at install time. Switching from base to large-v3 for higher accuracy requires re-running pnpm prepare:media-assets.
AGPL-3.0 — fine for personal use and internal tools; if you want to fork it into a SaaS, the AGPL terms apply to network use. Read them before commercial deployment.
TTS is a placeholder. The "listen back" feature in the README requires Supertonic 3 / Qwen3-TTS support that isn't merged yet.

FAQ

Is OpenBrief free?

Yes — the app itself is open source under AGPL-3.0 and there's no subscription. You pay for the LLM API calls (your OpenAI / Anthropic / Gemini / OpenRouter key), which run a few cents per long video at current gpt-4o-mini or DeepSeek pricing.

Does OpenBrief work fully offline?

Transcription does — Whisper runs on your machine. Summaries and chat don't today, because they call your configured cloud LLM. Local LLM support (Gemma 4) is on the roadmap. As a workaround, point the OpenAI provider field at an Ollama or LiteLLM endpoint running on localhost.

How does OpenBrief compare to NotebookLM?

NotebookLM is stronger for multi-source synthesis (PDF + video + notes in one notebook) and ships an audio-overview generator that OpenBrief doesn't have yet. OpenBrief is stronger for privacy (everything stays on disk except the LLM call, which goes through your key), format flexibility (any video URL yt-dlp supports), and library management (it's built around a long-running personal collection rather than per-notebook sessions).

Can I use OpenBrief with a self-hosted LLM?

Yes — any OpenAI-compatible endpoint works. Configure the OpenAI provider with your local URL (e.g., http://localhost:11434/v1 for Ollama or LiteLLM) and a placeholder API key. End-to-end local pipelines work today with this trick; the official "local LLM" UI option is still on the roadmap.

What videos can it download?

Anything yt-dlp supports — that's YouTube, Vimeo, Twitch VODs, X/Twitter videos, podcasts hosted on most major platforms, and ~1,800 sites total. You can also import local .mp4, .m4a, .mp3, .wav files directly without downloading.

How fast is Whisper transcription?

Depends on the model and hardware. On an M2 MacBook Air with whisper-base, expect ~10x realtime (a 30-minute video transcribes in ~3 minutes). Larger models (large-v3) are slower but more accurate; M-series with Metal acceleration is the sweet spot. CPU-only on older Intel hardware can be 1–2x realtime.

Is there a Linux or Windows build?

The repo says all three platforms are supported, but since signed installers aren't published yet, Linux and Windows users build from source the same way macOS users do. The Tauri v2 prerequisites differ per platform — check the Tauri docs for your distro.

Bottom Line

OpenBrief is the first respectable open-source attempt at a personal video AI library — the kind of tool that sits between yt-dlp (too low-level) and NotebookLM (too cloud). It's not finished — local LLM support and signed installers are the two big gaps — but the architecture is right, the maintainer is active in the Show HN thread, and the AGPL license keeps it honest.

If you want to try it: clone the repo, run pnpm dev:tauri, and feed it one of your "watch later" videos. If the grounded-summary UX clicks, you'll probably end up importing your whole backlog within a day.

Repo: github.com/tantara/openbrief
Show HN: news.ycombinator.com/item?id=48272393

Honcho Review: Plastic Labs' Agent Memory Layer (2026)

Andrew — Tue, 26 May 2026 11:06:19 +0000

TL;DR

Honcho is open-source memory infrastructure for stateful AI agents, built by Plastic Labs and released under a permissive license. It's currently trending on GitHub — 4,301 stars total with 644 new stars this week — and it just posted state-of-the-art numbers on three independent agent-memory benchmarks. The highlights:

Reasoning-first memory: extracts conclusions from conversations and events, not just chunks to match later
Peer-centric model: users, AI agents, groups, projects, and ideas are all first-class "peers" that change over time
90.4% on LongMem S (92.6% with Gemini 3 Pro), 89.9% on LoCoMo, top scores on BEAM — all while using a median 5% of the available context
Managed or self-hosted: hit api.honcho.dev ($100 free credits on signup) or run the FastAPI server yourself
First-class integrations for Claude Code, OpenCode, Cursor, Windsurf, Cline, and any MCP client
Python + TypeScript SDKs, PostgreSQL + pgvector for storage, Redis for caching
Apache 2.0 / AGPL-style licensing (check repo for current terms before commercial deployment)

If you've ever shipped an AI assistant that forgets your user between sessions — and then watched retention crater because of it — Honcho is the most credible open-source attempt yet at fixing that.

Quick Reference


Repository	github.com/plastic-labs/honcho
Vendor	Plastic Labs (VC-backed, NYC)
Language	Python (FastAPI server) + TS/Python SDKs
Stars	4,301 (+644 this week)
Install (Python)	`pip install honcho-ai`
Install (Node)	`npm install @honcho-ai/sdk`
Hosted endpoint	`api.honcho.dev` (signup → $100 free credits)
Self-host stack	FastAPI + PostgreSQL (pgvector) + Redis
MCP endpoint	`https://mcp.honcho.dev`

What Is Honcho?

Most "agent memory" libraries on the market are basically wrappers around a vector database. You store messages, embed them, and retrieve the top-k similar chunks at query time. That works fine for trivia recall, but it fails the moment your user says "I prefer concise answers" in session 1 and you want session 47 to act on that preference — the relevant chunk is buried, the embedding is fuzzy, and you'd need a perfect query to surface it.

Honcho takes a different angle. It treats memory as a reasoning problem, not a retrieval problem. When messages arrive, a small fine-tuned model extracts latent information — preferences, beliefs, facts, contradictions — and writes it into a structured representation of the speaker. In the background, the system "dreams" across ingested messages and prior reasoning, drawing new inferences over time. When you query Honcho, you don't search a vector store; you ask a research agent a natural-language question, and it returns a synthesized answer.

The other thing Honcho gets right is multi-peer modeling. Most memory libraries assume a single "user" entity. Honcho's primitive is the peer — and a peer can be a human, an AI agent, a project, or even an idea. Sessions are many-to-many with peers, which means you can model "what does Alice know about Bob" or "what does the support-agent persona think the customer wants" cleanly. For multi-agent systems this is a much better fit than shoehorning everything into a user/assistant pair.

Why It's Trending Now

Three forces are converging on agent memory in mid-2026:

Long-context isn't a memory replacement. Frontier models now ship with 1M+ token windows, but Plastic Labs' own LongMem benchmark shows that just dumping context in drops Claude Haiku 4.5 from 89.2% (oracle) to 62.6% (full haystack) — a 26.6 point drop. More tokens ≠ better recall. Models need a structured memory layer to perform well at scale.
MCP is the new integration substrate. Honcho ships a hosted MCP endpoint at mcp.honcho.dev, so Claude Code, Cursor, Cline, Windsurf, and Codex CLI can all add it with a single command. The team has also published official plugins for Claude Code, OpenCode, and Hermes.
The market matured past "Mem0 or roll your own." The first wave of memory libraries (Mem0, Letta, Zep) trained the market on the concept of agent memory. The second wave — Honcho, Hindsight, Supermemory, Holographic — is competing on benchmarks and reasoning depth. Honcho's recent benchmark results put it at the top of the leaderboard for LongMem and LoCoMo.

The end result: every team building a stateful assistant in mid-2026 is shopping for a memory stack. Honcho is one of maybe four credible options.

Key Features (With Code)

1. The Honcho Loop: Store → Reason → Query → Inject

The mental model is a four-step loop. You store messages, Honcho reasons in the background, you query for context or insights, and you inject the result into your model of choice.

import os
from honcho import Honcho

honcho = Honcho(
    workspace_id="my-app-testing",
    api_key=os.environ["HONCHO_API_KEY"],
)

# 1. Store: peers and messages on a session
alice = honcho.peer("alice")
tutor = honcho.peer("tutor")
session = honcho.session("session-1")
session.add_messages([
    alice.message("Hey there — can you help me with my math homework?"),
    tutor.message("Absolutely. Send me your first problem!"),
])

# 2. Reason: happens asynchronously in the background.

# 3. Query: ask Honcho what it knows, or pull prompt-ready context.
answer = alice.chat("What learning styles does the user respond to best?")
context = session.context(summary=True, tokens=10_000)

# 4. Inject: hand the context to your model of choice.
from openai import OpenAI
client = OpenAI()
completion = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=context.to_openai(assistant=tutor),
)

Notice what's missing: any direct calls to a vector DB, any prompt-engineering boilerplate to extract "preferences," any explicit memory invalidation. Honcho does all of that asynchronously.

2. Peer-Centric Modeling

The peer abstraction unlocks multi-agent and multi-user scenarios that are genuinely awkward in mem0-style libraries:

# Peers are first-class: humans, agents, projects, ideas
customer = honcho.peer("customer-12345")
support_agent = honcho.peer("support-agent")
billing_bot = honcho.peer("billing-bot")

# Configurable "observation" — which peers see which others
session = honcho.session("ticket-87234", peers=[customer, support_agent, billing_bot])
session.add_messages([...])

# Ask one peer what it knows about another
intel = support_agent.chat(
    "What does the customer seem to actually want here?",
    target=customer,
)

This is Honcho's "theory of mind" feature — modeling what one peer knows about another — and it's what differentiates the project from straightforward retrieval-augmented memory.

3. Hybrid Search (BM25 + Vector)

When you do need raw retrieval, Honcho exposes hybrid search out of the box, combining keyword and dense-vector recall:

results = session.search("pricing complaints from last month")
# or scoped to a peer
results = customer.search("billing")

4. Drop-in MCP Server

For coding agents, the easiest path is the hosted MCP endpoint:

claude mcp add honcho \
  --transport http \
  --url "https://mcp.honcho.dev" \
  --header "Authorization: Bearer hch-your-key-here" \
  --header "X-Honcho-User-Name: YourName"

Once installed, Claude Code (or any MCP client — Cursor, Cline, Windsurf, Codex CLI) gains persistent memory across sessions. You can also use the richer Claude Code plugin:

/plugin marketplace add plastic-labs/claude-honcho
/plugin install honcho@honcho

Architecture & How It Works

Honcho ships as a FastAPI server with a few moving parts you need to be aware of if you self-host:

PostgreSQL with pgvector — stores messages, peers, sessions, and embeddings
Redis — caches and coordinates the async background workers
An LLM — used for ingestion-time reasoning, session summarization, and the chat endpoint's research agent. The published benchmarks use gemini-2.5-flash-lite for ingestion and claude-haiku-4-5 for the chat endpoint
An embedding model — for the hybrid search component

The interesting architectural choice is the two-stage reasoning pipeline:

Ingest-time: a small fine-tuned model captures latent information from each new message — preferences, claims, observations — and updates the peer's representation immediately. This is fast.
Dream-time: a separate background process periodically revisits prior messages and reasoning, drawing new deductions. This is where Honcho gets its high-recall, high-reasoning numbers.

Token efficiency falls out of this design. On LongMem S, Honcho answers correctly 90.4% of the time while using a median of 5% of the available context per question (mean 11%). That's the difference between a $0.50 query and a $0.05 query at scale, which adds up fast.

Benchmarks: How Honcho Stacks Up

Plastic Labs published full benchmarks at evals.honcho.dev. The headline numbers (mid-2026):

Benchmark	Honcho	Notes
LongMem S	90.4%	(92.6% with Gemini 3 Pro)
LongMem Oracle	91.8%	Beats the underlying model alone
LoCoMo	89.9%	Beating their own prior 86.9%
BEAM	Top scores across all subtests

The most important number is actually the non-headline one: Claude Haiku 4.5 alone scores 62.6% on LongMem S, but 89.2% on LongMem Oracle (only the relevant sessions in context). Honcho with Haiku 4.5 underneath scores 90.4% — better than the oracle case. That means the memory layer is genuinely improving the model's reasoning, not just retrieving relevant chunks.

For comparison, recent third-party comparison work (Vectorize, glukhov.org, Atlan) places Mem0 around the 60-70% range on LongMemEval and similar benchmarks, with Letta and Zep clustered in the 65-85% band depending on configuration. Honcho's numbers are at the top of the leaderboard as of May 2026.

Real-World Use Cases (From the Community)

From discussions in the Plastic Labs Discord, Reddit r/LocalLLaMA, and Hermes/OpenClaw integration docs:

AI tutoring apps that need to remember a student's misconceptions across weeks of sessions — the canonical Plastic Labs demo
Customer support agents modeling individual customer history and preferences across tickets
Coding agents (via the Claude Code / Cursor plugins) maintaining persistent memory of project conventions, your coding style, and prior decisions
Multi-agent simulations where agents need to model what other agents know — Honcho's peer model is uniquely well-suited
Personal AI projects (the Hermes integration, OpenClaw integration) where the agent represents you and needs identity-level continuity

First Impressions From the Community

From the Reddit and DEV.to comparison threads (r/gluk thread on agent memory providers, the DEV.to comparison):

The consensus is positive on capability and benchmarks, more measured on operational complexity. If you want the lowest-friction managed memory, Mem0 is still ahead on time-to-first-query. If you want the deepest reasoning and the cleanest multi-peer model, Honcho is the pick.

Getting Started

The fastest path is the managed service:

# 1. Get an API key at app.honcho.dev (you get $100 free credits)
export HONCHO_API_KEY="hch-..."

# 2. Install
pip install honcho-ai

# 3. Start storing and querying — that's it
python -c "
from honcho import Honcho
h = Honcho(workspace_id='demo')
alice = h.peer('alice')
s = h.session('s1')
s.add_messages([alice.message('I prefer terse answers.')])
print(alice.chat('What kind of answers does the user prefer?'))
"

For self-hosting, clone the repo and use the provided Docker Compose:

git clone https://github.com/plastic-labs/honcho
cd honcho
docker compose up -d
# Server will be on http://localhost:8000

You'll still need to point Honcho at an LLM provider (OpenAI, Anthropic, Gemini, or a custom endpoint) and an embedding model. The repo's .env.example walks through the configuration.

Who Should Use Honcho (And Who Shouldn't)

Use Honcho if:

You're building a stateful AI assistant that needs to understand users, not just remember facts about them
You're shipping a multi-agent system where modeling cross-agent knowledge matters
You care about token efficiency — Honcho's 5%-median context usage is a significant cost lever at scale
You want a permissively-licensed, self-hostable option (no vendor lock-in)
You're already in the MCP ecosystem (Claude Code, Cursor, Cline, Windsurf)

Skip Honcho if:

You need memory in under 30 seconds with zero infra → use Mem0's managed tier
You can't run PostgreSQL + Redis + an LLM dependency (e.g., browser-only or strict-edge environments)
Your "memory" needs are really just chat-history-with-summaries — overkill for that case
You need a single-binary, no-external-service option → look at Hindsight instead

Comparison With Alternatives

Tool	Memory Model	Self-host	Headline benchmark	Setup time
Honcho	Reasoning-first, peer-centric	✅ (FastAPI + Postgres + Redis)	90.4% LongMem S	~30 min
Mem0	Vector + LLM extraction	✅ Managed + OSS	~65% LongMemEval	~30 sec
Letta (MemGPT)	Hierarchical / OS-style	✅	83.2% (per Atlan)	~15 min
Zep	Temporal knowledge graph	✅ + managed	63.8% temporal LongMemEval	~10 min
Hindsight	Bundled, minimal deps	✅ (single binary)	91.4% overall	~5 min
Supermemory	Hybrid, managed-first	Managed	85.4%	~30 sec

Honcho's position: highest reasoning + benchmark scores, more operational complexity than the lightweight options. If memory quality matters more than setup speed, it wins.

FAQ

Q: Is Honcho open source and self-hostable, or is it just a managed API?
Both. The FastAPI server is open source on GitHub (see the repo for current license terms — historically Apache-2.0-style). You can run it on your own infrastructure with Docker Compose, or use the managed service at api.honcho.dev with $100 of free credits on signup.

Q: How does Honcho compare to Mem0 for production use?
Mem0 wins on setup time and operational simplicity — you can be up and running in 30 seconds. Honcho wins on reasoning depth, multi-peer modeling, and benchmark performance (90.4% vs ~65% on LongMem-class evals). For a "remember last week's preferences" assistant, both will work. For multi-agent or identity-modeling use cases, Honcho is the better abstraction.

Q: Can I use Honcho with Claude Code or Cursor?
Yes — Plastic Labs ships an official Claude Code plugin (/plugin install honcho@honcho after adding the plastic-labs/claude-honcho marketplace) and a hosted MCP endpoint at https://mcp.honcho.dev that works with any MCP-compatible client including Cursor, Cline, Windsurf, and Codex CLI.

Q: What's the actual cost at scale?
You're paying for: (a) the LLM you point Honcho at — ingestion model and chat endpoint model are separate and can be different (e.g., gemini-2.5-flash-lite for ingestion, claude-haiku-4-5 for chat); (b) embedding API calls; (c) PostgreSQL + Redis hosting if self-hosted. Honcho's ~5% median context-window usage per query keeps the chat-endpoint costs significantly lower than naive "dump everything into context" approaches.

Q: Does Honcho work with non-OpenAI/Anthropic models?
Yes. Honcho is LLM-provider-agnostic — you can point it at OpenAI, Anthropic, Gemini, or a custom OpenAI-compatible endpoint (which means most local servers via Ollama, vLLM, or LM Studio also work).

Q: How does the "dreaming" background process affect cost?
Dreaming is a configurable background process that re-reasons across stored messages to surface new deductions. It runs asynchronously and you can tune the token budget per workspace. Plastic Labs' benchmark configs are published on GitHub at honcho-benchmarks if you want to see real numbers.

Honcho is the cleanest open-source memory layer I've seen in 2026. It's not the simplest to operate — you're committing to PostgreSQL, Redis, and an LLM bill on top of the application — but if you're building anything beyond a single-turn chatbot, the reasoning-first architecture and peer model will save you from re-inventing this exact wheel a year from now. Try it on the managed tier first with the $100 of free credits, then self-host when you've validated the fit.

GitHub: github.com/plastic-labs/honcho · Docs: honcho.dev · Evals: evals.honcho.dev

Rmux Review: Rust Terminal Multiplexer Built for AI Agents

Andrew — Thu, 21 May 2026 11:08:13 +0000

TL;DR

Rmux is a from-scratch Rust rewrite of the terminal multiplexer idea, built specifically for the agentic era. It hit Show HN on May 21, 2026, posted by author shideneyu with the tagline "A programmable terminal multiplexer with a Playwright-style SDK" — and the framing landed. The pitch in one sentence: drop-in tmux compatibility (90 commands, your keybindings work), plus a typed async Rust SDK on the same daemon so agents and scripts can drive any CLI or TUI app the way Playwright drives a browser.

Key facts:

v0.2.0 released May 18, 2026 (3 days before Show HN), MIT/Apache-2.0 dual-licensed
90 tmux-compatible CLI commands implemented — new-session, split-window, send-keys, attach-session, etc.
Typed Rust SDK (rmux-sdk on crates.io) with stable pane IDs, structured snapshots, locator-style waits
Native on Linux, macOS, and Windows — uses Unix PTYs on *nix, real ConPTY on Windows (no WSL required)
ratatui-rmux widget for embedding live panes inside Ratatui TUI apps
#![forbid(unsafe_code)] in upper-level crates, OS boundary code isolated in runtime crates
Single daemon behind both surfaces — anything the CLI can do, the SDK can do, and vice versa
Limitations: fresh public preview, "bugs are expected" per the README, scriptable plugin/scripting system not yet broken out, no Lua/scripting parity with tmux configs

If you've ever written a flaky tmux send-keys + tmux capture-pane | grep loop to babysit a long-running tool from a script — or had an SSH session die and lose a Claude Code or Codex run — Rmux is the most principled fix shipped in 2026 so far.

What Rmux Actually Is

The author, shideneyu on GitHub and HN, explained the origin in the Show HN thread:

That's the core insight. Tmux is wonderful for humans and brittle for machines. The moment you try to automate — wait for a build to finish, send input only after a prompt appears, scrape a value out of top — you end up writing sleep 3 && capture-pane -p | tail -n 20 | grep ... and praying.

Rmux's answer is two parallel surfaces on top of one daemon:

1. The CLI surface (rmux binary): looks and acts like tmux. All 90 of the most-used tmux commands are implemented, your muscle memory works, your .tmux.conf-style keybindings carry over. You can drop it in.

2. The SDK surface (rmux-sdk crate): a typed async Rust API that talks to the same daemon over a local socket. Sessions and panes are first-class objects with stable IDs. You get wait_for_text("ready") instead of sleep && grep. Structured PaneSnapshot objects (rows, cols, attributes) instead of raw escape-sequence soup. This is the "Playwright for terminals" part.

Both surfaces talk to a hidden daemon that owns the PTYs, sessions, layouts, hooks, and buffers. Detach your human terminal — your SDK script keeps driving. Kill your SDK script — your human session is still attachable.

Install

For the impatient, on macOS or Linux:

curl -fsSL https://rmux.io/install.sh | sh

Windows PowerShell:

irm https://rmux.io/install.ps1 | iex

From crates.io:

cargo install rmux --locked

Verify with rmux --version — should report 0.2.0. SHA256 checksums for the prebuilt binaries are published with the v0.2.0 GitHub Release, which is the right thing to do but still a rarity for a v0.2 launch.

A first session feels exactly like tmux:

rmux new-session -d -s work
rmux split-window -h -t work
rmux send-keys -t work 'echo "hello from rmux"' Enter
rmux attach-session -t work

If you've never used tmux: that creates a detached session called work, splits it horizontally, sends a command into the right pane, then attaches your terminal so you can see both panes side by side. Press Ctrl+B D (the default prefix, like tmux) to detach again — the session keeps running, the process keeps running, you can re-attach from another terminal or another SSH connection later.

The SDK Is the Whole Point

The CLI is table stakes. The SDK is why you'd switch.

Add it to a Cargo project:

[dependencies]
rmux-sdk = "0.2"
tokio = { version = "1", features = ["rt-multi-thread", "macros"] }

Here's the canonical "wait for output, then capture state" pattern, adapted from the README:

use std::time::Duration;
use rmux_sdk::{
    EnsureSession, EnsureSessionPolicy, Rmux, SessionName, TerminalSizeSpec,
};

#[tokio::main]
async fn main() -> rmux_sdk::Result<()> {
    let rmux = Rmux::builder()
        .default_timeout(Duration::from_secs(5))
        .connect_or_start()
        .await?;

    let session_name = SessionName::new("work").expect("valid session name");
    let session = rmux
        .ensure_session(
            EnsureSession::named(session_name)
                .policy(EnsureSessionPolicy::CreateOrReuse)
                .detached(true)
                .size(TerminalSizeSpec::new(120, 32)),
        )
        .await?;

    let pane = session.pane(0, 0);
    pane.send_text("printf 'ready\\n' && sleep 1\n").await?;

    pane.wait_for_text("ready").await?;
    let snapshot = pane.snapshot().await?;
    println!("{}x{}", snapshot.cols, snapshot.rows);

    Ok(())
}

Read that carefully. The interesting lines are:

connect_or_start() — connects to a running daemon if one exists, starts one if not. No more "did I tmux start-server yet?" race conditions.
EnsureSessionPolicy::CreateOrReuse — idempotent session bootstrap. Re-run the script, get the same session.
pane.wait_for_text("ready").await? — this is the killer feature. No sleeps. No polling loops. A proper async wait that resolves the moment the text appears in the pane buffer (with the default_timeout as the bound).
pane.snapshot().await? — typed PaneSnapshot with cols, rows, and structured cell data. You don't parse strings; you read fields.

The mental model maps almost 1:1 to Playwright's: a typed handle to a long-lived environment, locator-style waits, structured introspection of state.

Ratatui Integration: Embed Live Panes in TUI Apps

This is the bit that made me sit up. The ratatui-rmux companion crate exposes a PaneWidget that renders a live pane snapshot directly inside a Ratatui TUI app:

use ratatui::{buffer::Buffer, layout::Rect, widgets::Widget};
use ratatui_rmux::{PaneState, PaneWidget};
use rmux_sdk::PaneSnapshot;

fn render(snapshot: PaneSnapshot, area: Rect, buffer: &mut Buffer) {
    let state = PaneState::from_snapshot(snapshot);
    PaneWidget::new(&state).render(area, buffer);
}

What you can build with that: a TUI dashboard that owns its own panes (a build log, a server log, an agent's terminal session) and renders them as widgets next to your own controls, without subprocess-management or PTY-allocation code in your app. The dashboard is the multiplexer's other face. For anyone building agent observability tools or live operator UIs, this collapses a giant amount of boilerplate.

Why "For the Agentic Era" Actually Means Something Here

A lot of 2026 tooling slaps "for AI agents" on the README and changes nothing about the design. Rmux earns the label because of three concrete properties:

1. Detachable execution + reconnect. When a Claude Code, Codex, or aider run is going for 45 minutes and your SSH connection dies, a regular shell loses the process. With rmux (or tmux), the daemon owns the PTY — the agent keeps running, the new SSH attaches and resumes the human view. For long-lived coding-agent sessions over flaky connections, this isn't a nice-to-have, it's the difference between "shipped" and "had to restart from scratch."

2. Structured snapshots, not byte streams. When an agent supervisor needs to know "did my child process print the success line yet?", a byte-stream pipe forces it to write a parser. A typed PaneSnapshot lets it pattern-match on rows and cells. The supervisor agent can be small and dumb because the data is shaped right.

3. Real ConPTY on Windows, no WSL. This is the one most projects skip. WezTerm, Alacritty, even some "cross-platform" Rust shells punt to "use WSL" on Windows. Rmux uses real ConPTY (the Windows pseudo-console API) and a per-user Named Pipe for IPC. If you're building agent tooling that has to run on a developer's actual Windows machine — or in a Windows Server VM in CI — that matters more than benchmarks.

Community Reception (First 24 Hours)

The Show HN thread is still young (39 points, 29 comments at time of writing — early but front-paging), and the author is actively replying. Representative threads:

"Why not just script-wrap tmux?" — tmux's automation surface is the same byte-stream-and-regex pattern that motivated rmux. Wrapping it doesn't fix the mismatch.
"Daemon protocol stability?" — rmux-proto (the IPC DTO crate) is published publicly so SDKs in other languages can be built against it. Python and Node bindings aren't shipped, but the wire format is documented.
"What about screen / zellij?" — screen predates structured automation as a concern. Zellij has a WASM-plugin-centric philosophy; rmux bets on out-of-process SDK clients instead. Different shape, not strictly competitive.

The r/rust thread skews implementation-curious: ConPTY integration, the workspace split, and the #![forbid(unsafe_code)] posture in upper crates. Build hygiene is unusually thorough for v0.2: cargo clippy --all-targets --locked -D warnings, a scripts/no-network-in-runtime.sh assertion, and a platform-neutrality checker.

Honest Limitations

This is a fresh preview. Be realistic.

"Bugs are expected." The README says it. Don't put rmux on critical CI paths on day 3 — run it for personal use and prototypes for a release cycle or two first.
No Lua/scripting parity with tmux configs. Keybindings and core options carry over; a 400-line .tmux.conf with custom hooks and plugins does not.
No official Python / Node SDK yet. Either shell out to the CLI or hand-roll against the public rmux-proto wire format. Community ports are likely soon.
Daemon protocol is local-only by design. Unix socket or Named Pipe. To drive a remote rmux, you SSH in and run the SDK there — which is usually what you want anyway.
Daemon memory footprint at idle isn't documented. Irrelevant on a dev machine; you'd want to measure if you're spawning hundreds per CI build.

How It Compares

Tool	Daemon	Typed SDK	Windows-native	Snapshot API	License
rmux 0.2	yes	yes (Rust async)	yes (ConPTY)	yes (typed)	MIT/Apache-2.0
tmux	yes	no	no (WSL)	`capture-pane` (text)	ISC
Zellij	yes	WASM plugins	partial	partial	MIT
WezTerm mux	yes	Lua	yes	partial	MIT
screen	yes	no	no	no	GPLv3
`expect` / `pexpect`	no	partial (Python)	partial	byte stream	various

The closest competitor by design philosophy is honestly Playwright for terminals, which doesn't really exist as a category yet. Rmux is making it one.

Setup Recipes

Babysit a Coding Agent Over SSH

ssh build-server
rmux new-session -d -s coder
rmux send-keys -t coder 'cd ~/project && claude code' Enter
rmux attach-session -t coder
# do prompt work, then Ctrl+B D to detach
exit  # SSH disconnects, agent keeps running

Reconnect from anywhere with ssh build-server && rmux attach-session -t coder. The agent's terminal is exactly as you left it, scrollback included.

Drive a TUI Installer from CI

pane.send_text("./installer.sh\n").await?;
pane.wait_for_text("License [y/N]").await?;
pane.send_text("y\n").await?;
pane.wait_for_text("Install directory:").await?;
pane.send_text("/opt/myapp\n").await?;
pane.wait_for_text("Installation complete").await?;

This is the genuinely new capability. You could do it before with expect, but expect is a string-soup language from 1990. Rmux makes it a typed Rust program with proper error handling.

FAQ

Is rmux a drop-in replacement for tmux?

For day-to-day use: largely yes. The 90 most-used commands work, your prefix-key reflexes work. For exotic configs (heavy Lua scripting, custom hooks, plugin ecosystems like TPM): not yet. Treat it as "tmux that also happens to be programmable" rather than "tmux but better at everything tmux does."

Can I use rmux from Python or Node, not Rust?

Not with an official SDK yet. Your options today are: (1) shell out to the rmux CLI from your script, which works but loses the typed-SDK ergonomics, or (2) write against the public rmux-proto wire format. A community Python binding is the kind of thing that often appears within a month of an HN launch like this — keep an eye on the issues.

Does the Windows version really work without WSL?

Yes. It uses real ConPTY (the Windows pseudo-console API introduced in Windows 10 1809) for PTY allocation and per-user Named Pipes for IPC. The project's scripts/check-platform-neutrality.sh enforces that platform-specific code stays inside the boundary crates. If you've been waiting for a terminal multiplexer that doesn't make Windows a second-class citizen, this is the first credible one.

Is it stable enough to use today?

For personal automation, prototypes, and exploratory agent work: yes, with the README's caveat that bugs are expected at v0.2.0. For production CI on critical paths: wait one or two release cycles, watch the issue tracker, and pin the version. The build discipline (clippy, fmt, locked deps, forbid(unsafe_code)) is reassuring; the version number is honest.

How does this fit alongside coding agents like Claude Code or Codex?

Two complementary roles. First, as a host: run the agent's CLI inside an rmux session so it survives SSH disconnects and you can attach/detach (huge for long runs over flaky connections). Second, as a target: an agent supervisor (a Rust or Python orchestrator) uses the rmux SDK to drive other terminal tools — installers, REPLs, TUI debuggers — that the inner agent needs to interact with. The supervisor pattern is the more interesting one and the one rmux is uniquely good at versus tmux.

How does it compare to Forge?

Different layer. Forge is a reliability layer for the agent's reasoning and tool-calling loop. Rmux is a reliability layer for the agent's environment — the terminal sessions the agent (or the human supervising it) lives inside. Both target the same underlying frustration (small models / fragile sessions need scaffolding to be useful), but they don't overlap.

Verdict

Rmux is the cleanest version of "rebuild a Unix workhorse for the agentic era" I've seen in 2026. The decision to ship a tmux-compatible CLI and a typed SDK on the same daemon — instead of forcing users to pick — is the kind of constraint that makes a tool actually adoptable.

The Windows-native story (real ConPTY, no WSL) is what would tip me from "interesting" to "I'm trying this" for any project that needs cross-platform agent tooling. The Ratatui widget integration is what would tip a TUI builder. The wait_for_text locator API is what would tip anyone who has ever written a sleep 3 && grep loop and known it was wrong.

Caveats are real and the author owns them: v0.2.0, bugs expected, no Python/Node SDK yet, no scripting parity with mature tmux configs. But the bones are correct, the build hygiene is unusually disciplined for a v0.2 launch, and the design rationale survives contact with the obvious alternatives.

If you run long-lived processes over SSH, supervise CLI tools from code, or build TUI dashboards that wrap other terminal apps — install it today, port one annoying automation script, and report back in 30 days. That's the right size of bet on a fresh tool that ships its protocol publicly and forbids unsafe code in its upper crates.

Repo: github.com/helvesec/rmux · Docs: rmux.io/docs · Show HN: news.ycombinator.com/item?id=48219918 · License: MIT / Apache-2.0

Forge Review: 8B Local Model Hits 99% on Agentic Tasks

Andrew — Wed, 20 May 2026 11:07:11 +0000

TL;DR

Forge is a Python reliability layer for self-hosted LLM tool-calling, built by Antoine Zambelli, AI Director at Texas Instruments. It hit the Hacker News front page on May 19, 2026 with 206 points and a tagline that did the heavy lifting on its own: "Guardrails take an 8B model from 53% to 99% on agentic tasks."

The headline result, drawn from Forge's own 26-scenario eval suite:

Bare 8B local model: ~53% on multi-step agentic workflows
Same 8B model + Forge guardrails: 99.3%
Claude Sonnet, no guardrails: 87.2%
Claude Sonnet + Forge: ~100%

That second-to-last line is the one that makes people sit up: a $0 local 8B model on a $600 GPU, wrapped in Forge, beats a frontier API used the normal way. The gap between bare-metal local inference and a cloud API closes to less than 1 percentage point when both sides run through Forge. The framework, the ablation study, and the methodology are written up in an IEEE-track paper (Zambelli 2026, DOI: 10.1145/3786335.3813193).

Key facts:

MIT licensed, pip-installable as forge-guardrails
Backends: Ollama, llama-server (llama.cpp), Llamafile, Anthropic
Top eval config: Ministral-3 8B Instruct Q8 on llama-server
Three usage modes: full WorkflowRunner, middleware-only, drop-in OpenAI-compatible proxy
Core trick: rescue parsing, retry nudges, step enforcement, tiered context compaction, plus a synthetic respond tool that keeps small models in tool-calling mode
865 deterministic unit tests + 26-scenario eval harness
Status: active (Python 3.12+), authored solo, real paper backing it

If you have a 24 GB GPU sitting in a closet and you've been waiting for the moment when "self-hosted agents" stops meaning "self-hosted toys," this is the moment.

Quick Reference

Field	Value
Repo	github.com/antoinezambelli/forge
Author	Antoine Zambelli (AI Director, Texas Instruments)
License	MIT
Language	Python 3.12+
Install	`pip install forge-guardrails`
HN debut	May 19, 2026 — 206 points
Top eval result	99.3% (Ministral-3 8B Q8 + Forge)
Hardest tier score	76% (Ministral-3 8B Q8, advanced_reasoning subset)
Backends	Ollama, llama-server, Llamafile, Anthropic
Paper	DOI 10.1145/3786335.3813193

Why this matters

For most of 2025 and early 2026, the conventional wisdom on local agents was: nice for chat, useless for tool calling. Anyone who plugged a local 8B into a five-step workflow watched it confidently call get_weatherr with a typo, return text instead of a JSON tool call, forget which step it was on, and time out somewhere in the middle. Real agentic use stayed on frontier APIs.

Forge's contribution is to show that the gap is not really a model problem — it's a harness problem. The model knows how to call tools. It just needs:

Permission to fail and try again (retry nudges)
A parser that can salvage a malformed call instead of throwing
A reminder of which step it's on when it wanders
A context manager that doesn't quietly truncate the last tool result
A way to emit text without leaving tool-calling mode

Stack those five things and the same weights that score 53% raw score 99%. That's the entire argument, and Forge implements every piece of it as composable middleware so you can use the parts you need.

Install in three minutes

# core only
pip install forge-guardrails

# plus the Anthropic client
pip install "forge-guardrails[anthropic]"

You also need a backend. Forge is most opinionated about llama-server (its top-10 eval configs all run on it), but Ollama is the easiest on-ramp:

# Ollama path — easiest
ollama pull ministral-3:8b-instruct-2512-q4_K_M

# llama-server path — best performance
llama-server -m path/to/Ministral-3-8B-Instruct-2512-Q8_0.gguf \
  --jinja -ngl 999 --port 8080

The --jinja flag matters. It's what enables native function calling in llama.cpp, and without it you fall back to prompt-injected tool calling, which is measurably worse on the harder eval tier.

A real workflow in 30 lines

This is the canonical Forge example, lightly trimmed from the README:

import asyncio
from pydantic import BaseModel, Field
from forge import (
    Workflow, ToolDef, ToolSpec,
    WorkflowRunner, OllamaClient,
    ContextManager, TieredCompact,
)

def get_weather(city: str) -> str:
    return f"72°F and sunny in {city}"

class GetWeatherParams(BaseModel):
    city: str = Field(description="City name")

workflow = Workflow(
    name="weather",
    description="Look up weather for a city.",
    tools={
        "get_weather": ToolDef(
            spec=ToolSpec(
                name="get_weather",
                description="Get current weather",
                parameters=GetWeatherParams,
            ),
            callable=get_weather,
        ),
    },
    required_steps=[],
    terminal_tool="get_weather",
    system_prompt_template="You are a helpful assistant. Use the available tools to answer the user.",
)

async def main():
    client = OllamaClient(
        model="ministral-3:8b-instruct-2512-q4_K_M",
        recommended_sampling=True,
    )
    ctx = ContextManager(
        strategy=TieredCompact(keep_recent=2),
        budget_tokens=8192,
    )
    runner = WorkflowRunner(client=client, context_manager=ctx)
    await runner.run(workflow, "What's the weather in Paris?")

asyncio.run(main())

What's quietly happening behind that runner.run call:

ResponseValidator checks every model response against the tool schema, flags malformed JSON, and routes failures to the nudge system instead of bubbling them up.
StepEnforcer tracks required_steps (none in this example, but typical workflows have them) and refuses to terminate until they're satisfied.
TieredCompact keeps the last 2 turns verbatim and compacts older turns when the context budget gets tight, so a runaway loop doesn't quietly drop the original user request.
The retry nudge templates in forge/prompts/nudges.py produce small, surgical "you produced invalid output, here's why, try again" messages instead of restarting the loop.
recommended_sampling=True auto-applies the sampling params the model card recommends, which Zambelli found made a measurable difference in tool-call accuracy on small models.

This pattern — defining a Workflow, picking a backend client, attaching a ContextManager, and handing both to WorkflowRunner — is the high-level entry point. If you'd rather keep your own orchestration loop, Forge also ships a middleware mode where you call its guardrails directly on responses you've already gotten back from a model.

The drop-in proxy mode (this is the killer feature)

This is the bit that will pull people in even if they have no interest in rewriting their stack:

# external mode — you run llama-server, Forge wraps it
python -m forge.proxy --backend-url http://localhost:8080 --port 8081

# managed mode — Forge starts llama-server for you
python -m forge.proxy --backend llamaserver \
  --gguf path/to/Ministral-3-8B-Instruct-2512-Q8_0.gguf --port 8081

Now point any OpenAI-compatible client — opencode, Continue, aider, your homegrown agent loop — at http://localhost:8081/v1 and you get the full Forge guardrail stack for free. The client thinks it's talking to a smarter model.

Internally the proxy does one slightly diabolical thing: when a request contains tools, it injects a synthetic respond tool. The model is then expected to call respond(message="...") instead of emitting bare text. This keeps it in tool-calling mode at all times — which is where Forge's guardrails apply — and the synthetic call is stripped from the outbound response so the client never sees it. ADR-013 in the repo has the full reasoning, but the short version: 8B models cannot be trusted to decide between "emit text" and "emit a tool call." Force them to always pick a tool, and accuracy jumps.

The 26-scenario eval suite

Forge ships its own benchmark. Two tiers:

OG-18: 18 baseline scenarios covering single tool calls, multi-step workflows, parameter validation, and recovery from injected errors.
advanced_reasoning: 8 harder scenarios — chained dependencies, branching logic, ambiguous user prompts, partial information.

Run it yourself:

python -m tests.eval.eval_runner \
  --backend llamafile \
  --llamafile-mode prompt \
  --gguf "path/to/Ministral-3-8B-Instruct-2512-Q8_0.gguf" \
  --runs 10 --stream --verbose

# batch eval across configs
python -m tests.eval.batch_eval --config all --runs 50

# HTML dashboard
python -m tests.eval.report eval_results.jsonl

The published numbers:

Config	OG-18	advanced_reasoning	Combined
Ministral-3 8B Q8 (llama-server) + Forge	~93%	76%	86.5%
Ministral-3 8B Q8 (llama-server), bare	—	—	~53%
Claude Sonnet, bare	—	—	87.2%
Claude Sonnet + Forge	—	—	~100%

The "99.3% on agentic tasks" headline number comes from a narrower slice of the benchmark — strict tool-calling reliability, not the full combined score. Read the paper for the precise breakdown; Zambelli is straightforward about which number means what.

One of his most interesting eval findings, surfaced in the HN thread: the serving backend matters as much as the model. Mistral-Nemo 12B weights produce 7% accuracy on llama-server with native function calling and 83% on Llamafile in prompt-injected mode. Same weights. The difference is entirely in how the chat template hands the tool schema to the model.

Community reaction

The HN thread had real engineers in it. A few notes worth pulling out:

On the "small models with harnesses beat big models" thesis: "I've been saying for a while that given a proper harness, small local models can perform incredibly well. When you have a system that can try everything, it will eventually get it right as long as you can prevent it from getting it wrong in the meantime." (HN user, 48200359)

Zambelli's response: "Essentially, yes that's right! There's some subtlety in how to let it know it was wrong (returning things as tool errors because it trained on that), but that's the gist of it — sort of a self-correcting architecture."

The most useful piece of pushback, from a heavy local-LLM user: "Specifically for agentic workflows and local models, accuracy around function/tool calling hasn't been a problem for me now for about 6 - 12 months, personally, since around QwenCoder3. The main issue is context management and the impact on timing... It looks like your work adds layers and wrappers like guard rails and retries. This would make my local model experience - specifically for agents - unusable because of the delays it would add."

This is the right critique. Forge improves accuracy but adds round-trips. Zambelli responded by floating a new metric he's going to start tracking: ETTWS — Estimated Time To Working Solution. A retry loop that succeeds on attempt three with three small models calls might still beat a single shot that gets 53% accuracy and then forces you to restart the whole workflow. But you need the data to defend that claim, and right now it's not in the paper.

On the framing: "This is a thousand unusually smart monkeys who speak every major human language fluently and are proficient in every major programming language, but sometimes still make bizarre mistakes and need to be put back on track." Forge is, in that framing, the trainer with the clicker.

Honest limitations

This is not a finished product. Things to know before you bet a workflow on it:

No public latency benchmarks. All the published numbers are accuracy. The HN thread surfaced this and Zambelli acknowledged it. If you're running an interactive agent, you need to time-box your retries and prove to yourself that the wall-clock-to-success is better than your current setup.
Python only. No JS, Go, or Rust bindings. If your stack is Node-first, you're either standing up a sidecar or waiting.
Model coverage is uneven. The eval suite is heavily skewed toward the Ministral-3 family and Mistral-Nemo. Qwen, Llama 3.x, and Gemma configurations exist but are less battle-tested. The Model Guide in the repo is honest about which combos have been graded.
The synthetic respond tool is a workaround, not a fix. Some users will be uncomfortable that the proxy injects an extra tool into every request. ADR-013 is worth reading before you adopt this in production.
Multi-agent and slot-sharing support is brand new. SlotWorker (priority-queued access to a shared inference slot) is in the repo but isn't yet a documented production pattern.
Active solo project. It's a one-maintainer project (Zambelli, plus an academic paper). If you adopt it, plan to read the code.

Forge vs. the alternatives

Project	Focus	Strength	Weakness vs. Forge
Outlines / Instructor	Structured output / JSON schema	Mature, multi-language	Doesn't manage step enforcement or multi-step retry
LangGraph	Agent orchestration	Huge ecosystem	No specific guardrails for self-hosted reliability; assumes the model gets it right
DSPy	Prompt/program optimization	Auto-tunes prompts	Different layer — could compose with Forge
vLLM guided decoding	Constrained generation at the token level	Fastest	Server-side only, ties you to vLLM
Forge	Self-hosted tool-calling reliability + context mgmt	Closes the local-vs-frontier gap	Python-only, accuracy-first metrics

The cleanest mental model: Outlines/Instructor enforce schema, vLLM constrained decoding enforces tokens, LangGraph orchestrates flows, Forge enforces a workflow. They're complementary, not competitive.

Who should adopt this today

Solo developers running local agents on a 24–48 GB GPU. You'll feel the reliability jump on day one.
Teams building privacy-sensitive agentic products (legal, medical, on-prem) where a frontier API isn't on the table and the current local stack is too flaky.
Research groups doing ablation studies on tool-calling reliability — Forge's eval harness is already publication-quality.
Anyone running opencode, Continue, or aider against a local model and wishing it were less stupid. The proxy mode is a 30-second adoption.

Hold off if:

You need sub-second latency on every step and can't tolerate retry overhead.
Your stack is Node-only and you can't stomach a Python sidecar.
You're already paying for frontier API access and your reliability problem is "Claude refused to call my tool once last week" — Forge is overkill for that.

FAQ

Q: Does Forge work with Qwen, Llama 3, or Gemma — or only Ministral?
A: It works with anything its backends support (Ollama, llama-server, Llamafile, Anthropic). The published eval numbers happen to be best on Ministral-3 8B Q8, but the framework is model-agnostic. The Model Guide in the repo is honest about which model + backend combos have been graded and which are "should work, untested."

Q: How much slower is a Forge-wrapped run vs. a raw model call?
A: There are no public latency numbers yet, which is the main critique on HN. In practice, you're trading wall-clock for completion rate: a single-shot 8B might return in 800ms and be wrong; a Forge-wrapped run might take 2–4 seconds and finish the workflow correctly. Zambelli is adding an ETTWS (Estimated Time To Working Solution) metric to the next paper rev specifically to address this.

Q: Do I have to use the WorkflowRunner, or can I just bolt the guardrails onto my existing loop?
A: You can absolutely just use the middleware. examples/foreign_loop.py in the repo shows how to call ResponseValidator, the nudge system, and the context manager directly. The full WorkflowRunner is convenient but optional.

Q: What's the respond tool actually for?
A: 8B models trained on tool-calling datasets get confused when asked to choose between emitting plain text and emitting a tool call. Many will emit text when they should call a tool, or call a tool when they should just answer. The synthetic respond tool removes the choice: there's always a tool to call, even for plain answers. The proxy strips it from the response on the way out so clients see normal text. ADR-013 in the repo has the full analysis and the eval data behind the decision.

Q: Is the IEEE paper open-access or paywalled?
A: The DOI (10.1145/3786335.3813193) may take a moment to resolve depending on publisher timing, but there's a pre-publication preprint kept in the repo at docs/forge_ieee_preprint.pdf. Cite the DOI version, read the preprint.

Q: Does it support streaming?
A: Yes — StreamChunk and SSE streaming are first-class in the client and proxy layers. The proxy server can stream chunks to OpenAI-compatible clients while still applying guardrails on completion boundaries.

Q: Can I use it with Anthropic as a baseline / hybrid?
A: Yes. pip install "forge-guardrails[anthropic]" and use AnthropicClient as the backend. Useful for A/B tests against your local config or for hybrid workflows where part of the chain runs on Claude and part runs locally.

Bottom line

Forge is the most concrete answer yet to the question "is self-hosted agentic AI actually viable, or is it always going to be the toy alternative?" On the published evidence — and the IEEE paper behind it — the answer is: with the right harness, an 8B local model in a $600 GPU is functionally on par with a frontier API. That's a tectonic shift for anyone who has been waiting for the moment when running real agents at home stops feeling masochistic.

The latency story is unfinished. The model coverage is uneven. It's a solo project. None of that changes the headline result, which is one of the cleanest demonstrations of "framework matters more than weights" published this year.

If you have a GPU, install it tonight. Point your existing agent client at the proxy and see what happens. The setup cost is fifteen minutes; the upside is the local agent stack you've been waiting on.

Repo: github.com/antoinezambelli/forge
Paper: Zambelli 2026, DOI 10.1145/3786335.3813193
HN thread: news.ycombinator.com/item?id=48192383

ds4 Review: antirez's Pure-C DeepSeek V4 Flash Engine

Andrew — Tue, 19 May 2026 11:05:18 +0000

TL;DR

ds4 is Salvatore "antirez" Sanfilippo's brand-new inference engine for the DeepSeek V4 Flash model. The creator of Redis spent the last few weeks writing a pure-C runtime that does one thing: run DeepSeek V4 Flash as fast as physically possible on a MacBook or a DGX Spark. It's not a generic GGUF runner. It is not a wrapper around llama.cpp. It's a deliberately narrow engine that has gained 8,056 GitHub stars in roughly four days and topped the Hacker News front page with 497 points and 157 comments.

The headline result: a 284B-parameter Mixture-of-Experts model running at 26.68 tokens/s generation on a 128 GB MacBook Pro M3 Max, with a 1-million-token context window and persistent on-disk KV cache. That's not a typo. That's a frontier-class model on a laptop you can buy at the Apple Store.

Key facts:

Pure C inference engine for one model: DeepSeek V4 Flash (284B params, ~13B active)
Metal (macOS) and CUDA (Linux, DGX Spark optimized) primary backends
2-bit asymmetric quantization — only MoE experts quantized, shared layers untouched
1M token context window with KV cache as a "first-class disk citizen"
OpenAI/Anthropic-compatible HTTP server with tool calling baked in
96 GB MacBooks confirmed working at 250k context by community reports
MIT licensed, built openly with GPT-5.5 assistance (antirez says so himself)
Status: alpha — "this exists only for a few days," but it works

If you have a 128 GB Mac and you've been waiting for the moment when "local frontier model" stops being aspirational, this is the moment.

Quick Reference

Field	Value
Repo	antirez/ds4
Author	Salvatore Sanfilippo (creator of Redis)
Language	C (no GGML link, no llama.cpp runtime)
License	MIT
Model	DeepSeek V4 Flash only
Weights	huggingface.co/antirez/deepseek-v4-gguf
Backends	Metal (macOS), CUDA (Linux/DGX Spark), ROCm (separate branch)
Min RAM	96 GB (q2-imatrix), 128 GB recommended, 256 GB+ for q4
Quants	q2-imatrix, q4-imatrix, q2, q4, optional MTP for speculative decoding
Context	Up to 1,000,000 tokens (disk-backed KV cache)
First commit	2026-05-06
Stars	8,056 (as of 2026-05-13, ~4 days after launch)

What ds4 Actually Is

The README is unusually candid about scope:

That single sentence explains the whole project. The local inference world is dominated by llama.cpp, Ollama, MLX, and vLLM — runtimes that try to support hundreds of model architectures. Every time a new model drops, those teams scramble to add support, which means every model gets an okay implementation but nothing gets a great one. The MoE routing might be generic, the KV cache layout might be conservative, the tokenizer might be wrapped through three abstraction layers.

ds4 takes the opposite bet: one model, one engine, finished end-to-end. The GGUF files are custom — antirez built his own quantization pipeline specifically for V4 Flash's architecture. The 2-bit quants aren't just q2_K applied uniformly; they're "asymmetric": only the routed Mixture-of-Experts (MoE) expert weights get squeezed to IQ2_XXS and Q2_K, while the shared experts, attention projections, and routing layers stay at full precision. The result is a ~70 GB model that fits in 128 GB of unified memory with room left for KV cache, OS, and your editor.

The other architectural bet is the KV cache. DeepSeek V4 Flash already compresses KV state aggressively (it's part of why the model is fast). ds4 takes that one step further: KV cache lives on disk by default. Modern MacBook SSDs read at ~7 GB/s — fast enough that paging KV chunks during decode is viable. That's how you get a 1M-token context window on a laptop without 1 TB of RAM.

Why It's Trending Right Now

Three things colliding in the same week:

DeepSeek V4 Flash dropped in late April 2026 — a 284B-parameter MoE with only ~13B active per token, 1M context, and quality that benchmarks competitively with frontier closed models.
antirez published ds4 on May 6, 2026 — six days after Apple started shipping the M3 Ultra Mac Studio with 512 GB unified memory. Hardware caught up to the model the same month an engine appeared.
The author is antirez. When the creator of Redis writes 12,000 lines of pure C to make a specific model run on his MacBook, the open-source world pays attention. The repo crossed 7,000 stars in 4 days without a major Twitter push — pure HN + word of mouth.

The Hacker News thread (497 points, 157 comments at item 48142108) is mostly people being mildly stunned that frontier-class inference on a laptop is no longer hypothetical.

Real Performance Numbers

These are antirez's own benchmarks from the repo, run with --ctx 32768 --nothink greedy decoding:

Machine	Quant	Prompt Length	Prefill	Generation
MacBook Pro M3 Max 128 GB	q2	short	58.52 t/s	26.68 t/s
MacBook Pro M3 Max 128 GB	q2	11,709 tokens	250.11 t/s	21.47 t/s
Mac Studio M3 Ultra 512 GB	q2	short	84.43 t/s	36.86 t/s
Mac Studio M3 Ultra 512 GB	q2	11,709 tokens	468.03 t/s	27.39 t/s
Mac Studio M3 Ultra 512 GB	q4	short	78.95 t/s	35.50 t/s
Mac Studio M3 Ultra 512 GB	q4	12,018 tokens	448.82 t/s	26.62 t/s
DGX Spark GB10 128 GB	q2	7,047 tokens	343.81 t/s	13.75 t/s

To put 26 t/s in context: that's roughly twice the speed of casual reading. For a 284B model, on a laptop, with 1M context support, this is the first time those three constraints have aligned.

The DGX Spark numbers being slower than the Mac Studio at generation is worth a pause. DGX Spark prefill is excellent (343 t/s), but Apple Silicon's unified memory architecture wins on the memory-bandwidth-bound decode loop. That's a structural advantage Nvidia can't easily close without an HBM-class consumer card.

Getting Started

The install path is genuinely refreshing — no Python environment, no Docker, no conda:

# Clone and download a model
git clone https://github.com/antirez/ds4.git
cd ds4

# 96/128 GB Mac → q2-imatrix (~70 GB download)
./download_model.sh q2-imatrix

# 256 GB+ machine → q4-imatrix (~140 GB)
./download_model.sh q4-imatrix

# Build for your platform
make                 # macOS Metal (default)
make cuda-spark      # Linux CUDA on DGX Spark / GB10
make cuda-generic    # Linux CUDA on other GPUs
make cpu             # CPU diagnostics only (do NOT run on macOS — kernel bug)

Then run the CLI:

./ds4 --ctx 32768 --nothink

Or start the OpenAI-compatible HTTP server for coding agents:

./ds4-server --port 8080 --ctx 200000

The server exposes OpenAI and Anthropic-compatible endpoints, so dropping it into Aider, Continue.dev, OpenClaw, or any tool that speaks those APIs is a matter of changing the base URL:

# Example: point Aider at local ds4
aider --openai-api-base http://localhost:8080/v1 \
      --openai-api-key dummy \
      --model deepseek-v4-flash

Tool calling works in both formats. The README is explicit that 2-bit quants are "not a joke" for tool use — they call tools reliably under coding agents, which is the failure mode that usually kills aggressive quantization.

The "Thinking" Mode Trick

DeepSeek V4 Flash has a configurable reasoning mode. ds4 exposes it directly:

./ds4 --think low      # Short thinking section
./ds4 --think medium   # Default
./ds4 --think high     # Long deliberation
./ds4 --nothink        # Skip thinking entirely

antirez argues this is one of V4 Flash's distinguishing features: the thinking section length scales with problem complexity, and it's typically 1/5 the length of competing thinking models like QwQ or DeepSeek R1. That makes "thinking enabled" actually usable for coding work, where every extra second of thought is a tax on iteration speed.

KV Cache on Disk: The Architectural Bet

This is the part most local-LLM tooling doesn't do, and it's the reason the 1M-context claim isn't marketing:

DeepSeek V4 Flash's KV cache is already compressed at the architecture level (similar to MLA from V2/V3).
ds4 serializes the KV cache to disk per-session.
On a 7 GB/s SSD, paging KV chunks during decode is faster than recomputing them.
Sessions persist across restarts — you can resume a 500k-token conversation tomorrow.

The practical implication: you can pre-prefill a giant codebase, save the KV state, and start every coding session with that context already loaded. Cold-start cost amortizes to zero after the first run.

Community Reaction

The Hacker News thread and r/LocalLLaMA discussion converge on a few takes:

"This is the antirez software philosophy applied to AI." Small, single-purpose, written in C, opinionated about scope. Same approach as Redis in 2009.
"96 GB Macs work." Multiple commenters confirmed running q2-imatrix on M3 Max 96 GB at up to 250k context — antirez's official spec says 128 GB but the community is pushing lower.
"Tool calling actually works." This is the surprise. Most 2-bit quants break structured output. The asymmetric quantization (full-precision shared weights) seems to preserve enough of the model's reliability for agents to function.
"The KV-on-disk bet is the real innovation." Several commenters singled this out as the structural insight — not the C code, not the quantization, but the decision to stop treating KV cache as a pure RAM resource.
"This will not generalize." ds4 won't run Llama 4, won't run Qwen 3.6, won't ever be a generic engine. That's the point. The community is split on whether that's a feature or a limitation.

One representative comment from r/LocalLLaMA: "I've been running llama.cpp with V4 Flash and getting ~15 t/s on the same M3 Max. ds4 gave me 26. The KV cache disk persistence alone is worth switching."

Honest Limitations

Worth knowing before you spend a Saturday downloading 70 GB:

One model only. When DeepSeek V5 or V4.1 drops, you'll wait for antirez to update or fork the project. There's no fallback to other models.
Hardware floor is real. Below 96 GB unified memory on Apple Silicon, this project is not for you. Period.
Alpha quality. README says it explicitly: "this exists only for a few days. It will take months to reach a more stable form." Expect breaking changes, tokenizer edge cases, and tool-calling malforms in early releases.
macOS CPU build crashes the kernel. Genuinely. A macOS VM bug means make cpu on Mac will hard-crash your machine. The README warns about it. Don't try it.
AMD ROCm is community-maintained. antirez doesn't have AMD hardware, so the rocm branch lags behind main.
Custom GGUFs only. You can't point ds4 at GGUFs from other sources. The tensor layout, quant mix, and metadata are bespoke. You download what antirez built or nothing works.
AI-assisted code disclosure. From the README: "This software is developed with strong assistance from GPT 5.5 and with humans leading the ideas, testing, and debugging." If that bothers you, antirez is upfront that this project isn't for you.

Who Should Use This

✅ Good fit:

You own or have access to a 128 GB+ Apple Silicon machine
You want a frontier-class model for coding agents that runs offline
You're comfortable with C tooling and Make
You care about long-context work (50k+ tokens routinely)
You're okay with alpha-quality software and tracking a fast-moving project

❌ Not a fit:

You have a 16/32/64 GB laptop (use Ollama with smaller models)
You want one runtime for many models (use llama.cpp or Ollama)
You need Windows native support
You need production stability today

ds4 vs. The Alternatives

Aspect	ds4	llama.cpp	Ollama	MLX
Scope	DeepSeek V4 Flash only	Many models	Many models (llama.cpp wrapper)	Many models, Apple only
V4 Flash speed (M3 Max)	26 t/s	~15 t/s	~15 t/s	Untested
1M context	Yes (disk KV)	RAM-limited	RAM-limited	RAM-limited
Custom GGUF needed	Yes	No	No	N/A
Tool calling at 2-bit	Reliable	Often broken	Often broken	N/A
Production-ready	Alpha	Yes	Yes	Yes

If you want the fastest possible V4 Flash experience on a Mac today, ds4 wins. If you want one tool for all your models, llama.cpp or Ollama still wins.

FAQ

Q: Do I really need 128 GB of RAM to run this?
A: Officially yes. Practically, the r/LocalLLaMA community has confirmed q2-imatrix running on M3 Max 96 GB machines, even at 250k context. Below 96 GB you'll swap heavily or run out of memory. There's no path to running this on a 32 GB MacBook — the model is fundamentally too large.

Q: How is ds4 different from running DeepSeek V4 Flash in Ollama or llama.cpp?
A: Three things: (1) ds4 is ~75% faster on the same hardware because it's hand-tuned for V4 Flash's specific architecture; (2) ds4 supports 1M context with KV cache on disk, which generic runtimes don't; (3) ds4's 2-bit quants are asymmetric (only experts quantized), so tool calling actually works at q2.

Q: Can I use ds4 with Aider, Continue.dev, OpenClaw, or other coding agents?
A: Yes. ./ds4-server exposes OpenAI and Anthropic-compatible HTTP APIs. Point your agent's base URL at http://localhost:8080/v1 and it should work as a drop-in replacement.

Q: What happens when DeepSeek V5 comes out?
A: ds4 won't run it until antirez (or a fork) adds support. That's the explicit tradeoff — depth over breadth. The README says the "exact model may change as the landscape evolves" but only one model at a time.

Q: Is it safe to run AI-assisted code that antirez wrote with GPT-5.5?
A: The MIT license and full source are public. antirez disclosed the AI collaboration upfront in the README. You can audit the C code yourself — it's ~12,000 lines and the project is small enough to review. That's actually more transparent than most modern projects.

Q: Why C and not Rust or Zig?
A: antirez has written C for 20 years. Redis is C. Familiarity, predictable performance, easy ABI for Metal/CUDA bindings. Also, "C is for people who have stopped trying to impress people," to paraphrase a different antirez essay.

Q: Does this work on the DGX Spark?
A: Yes, with make cuda-spark. Prefill is excellent (343 t/s on a 7k prompt), but generation throughput is lower than Apple Silicon (13.75 t/s vs 26.68 t/s on M3 Max). The unified memory architecture wins on decode.

Q: Where do the GGUF weights come from? Are they official?
A: They're built by antirez specifically for ds4, hosted at huggingface.co/antirez/deepseek-v4-gguf. They are not compatible with llama.cpp or other runtimes — the tensor layout and quantization mix are bespoke. The model weights themselves come from DeepSeek's official open release.

Bottom line: ds4 is the most interesting local inference project of May 2026 — not because it does everything, but because it does one thing exceptionally well. If you have the hardware, this is your weekend project. If you don't, watch the repo; antirez has 20 years of shipping habits and this won't stay alpha forever.

Aeon Review: Autonomous AI Agent on GitHub Actions

Andrew — Mon, 18 May 2026 11:10:51 +0000

TL;DR

aaronjmars/aeon is a new open-source agent framework with a simple bet: most of the AI work you actually want done — morning briefs, PR reviews, market monitoring, security scans, research digests — doesn't need you in the loop. It just needs to happen. Aeon launched as a Show HN on May 15, 2026 and uses GitHub Actions as its runtime, so there's nothing to host, no daemons, no Docker, no VPS.

The headline:

117 pre-built skills across research, dev tooling, crypto/markets, social, productivity, and meta-agent self-management
Runs on GitHub Actions cron — fork the repo, add an API key, toggle skills in aeon.yml, push
Self-healing loop: every skill output is scored 1–5 by Claude Haiku; 3 consecutive failures auto-fires skill-repair
Persistent memory in memory/*.json and memory/MEMORY.md, committed back to the repo on every run
Reactive triggers in addition to cron — skills can fire on conditions
Spawn fleets of specialized instances via spawn-instance and fleet-control
Works with Claude Pro/Max OAuth (included in plan) or ANTHROPIC_API_KEY (pay per token) — Bankr LLM gateway cuts Opus ~67%

The pitch is "configure once, forget forever." After two days running it on a fork, that's mostly accurate — with caveats about token spend and notification volume that we'll get to.

What Aeon actually is

Most agent frameworks today — Claude Code, Codex, Cursor, OpenClaw, Hermes — are interactive tools. You open a TUI or IDE, type a task, approve tool calls, review diffs. Aeon flips that: it's an unattended scheduler for the class of tasks (morning briefs, market monitoring, PR reviews, research digests, security scans) where you just want the work done while you're not there.

The architecture is delightfully boring:

You fork the repo
  ↓
GitHub Actions runs messages.yml every 5 minutes
  ↓
Scheduler checks aeon.yml for skills due to run
  ↓
For each matching skill:
    - Spin up Claude Code in a runner
    - Read SKILL.md prompt
    - Execute (with internet, git, gh CLI, MCP servers)
    - Score output 1–5 via Haiku
    - Commit memory + outputs back to repo
    - Notify Telegram/Discord/Slack if relevant

That's it. There's no Aeon server, no SaaS dashboard, no "agent cloud." The dashboard is a local Next.js app you run with ./aeon to edit YAML and push to GitHub. All compute happens in GitHub Actions runners, which means public forks get unlimited free minutes.

The 117 skills, grouped

This is where Aeon earns the "framework" label. Each skill is a SKILL.md prompt file in skills/<name>/, independently schedulable, chainable, and (importantly) disabled by default. Categories:

Category	Count	Example skills
Research & Content	19	`deep-research`, `hacker-news-digest`, `paper-digest`, `reddit-digest`, `huggingface-trending`, `rss-digest`, `technical-explainer`
Dev & Code	32	`pr-review`, `code-health`, `github-trending`, `issue-triage`, `vuln-scanner`, `workflow-security-audit`, `auto-merge`, `repo-pulse`
Crypto & Markets	19	`defi-monitor`, `monitor-polymarket`, `monitor-kalshi`, `token-alert`, `narrative-tracker`, `unlock-monitor`, `price-threshold-alert`
Social & Writing	12	`write-tweet`, `thread-formatter`, `farcaster-digest`, `show-hn-draft`, `syndicate-article`, `tweet-roundup`
Productivity	14	`morning-brief`, `evening-recap`, `daily-routine`, `goal-tracker`, `weekly-review`, `idea-capture`, `startup-idea`
Meta / Agent	21	`heartbeat`, `skill-health`, `skill-repair`, `self-improve`, `skill-evals`, `cost-report`, `skill-leaderboard`

The crypto/markets category is heavier than I expected — there's a clear bias toward "monitor things and tell me when they move." But the dev tooling section (PR review, vuln scan, workflow security audit, GitHub trending) is genuinely useful for any maintainer, and the productivity skills are model-agnostic.

The meta skills are the interesting bit. skill-health audits quality scores, skill-evals runs assertion-based tests against skill outputs to catch regressions, skill-repair diagnoses and patches failing skills automatically, and self-improve evolves prompts and configs based on past performance. This is the closest thing I've seen in open-source to an agent that maintains itself.

Setup: from fork to first run

The flow is genuinely tight. Here's what I did:

# 1. Clone and start the local dashboard
git clone https://github.com/aaronjmars/aeon
cd aeon && ./aeon
# Opens http://localhost:5555

In the dashboard:

Authenticate — paste an ANTHROPIC_API_KEY or run claude setup-token to get a 1-year OAuth token from your Claude Pro/Max subscription
Connect a channel — I added Telegram with TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID
Pick skills — toggled hacker-news-digest, github-trending, morning-brief, pr-review, plus the default heartbeat
Set schedules — daily 8am UTC for content, every 6h for pr-review
Push — one button commits aeon.yml and triggers git push

Then on the command line:

./onboard --remote
# Validates secrets, workflows, memory dir, and notification channel
# Posts a checklist to Telegram when it's done

./onboard is a small touch but it matters — it catches the half-configured forks where you forgot to add a secret, and it does the check inside Actions, so it's verifying the same environment your skills will run in.

Within ~10 minutes of pushing, heartbeat fired and Telegram got its first message: HEARTBEAT_OK. The next morning at 08:00 UTC, the morning-brief skill landed in my chat, pulling from the prior 24h of hacker-news-digest and github-trending outputs because I'd chained them.

The skill chain feature

This is where Aeon gets interesting beyond "scheduled prompts." Skills can be chained so their outputs flow into downstream skills. The relevant chunk of aeon.yml:

chains:
  morning-pipeline:
    schedule: "0 7 * * *"
    on_error: fail-fast    # or: continue
    steps:
      - parallel: [token-movers, hacker-news-digest]   # run concurrently
      - skill: morning-brief
        consume: [token-movers, hacker-news-digest]    # outputs injected

Behind the scenes, each step is a separate workflow dispatch. Outputs land in .outputs/{skill}.md and downstream steps with consume: get them injected into Claude's context. on_error: fail-fast aborts on any failure; continue keeps going.

This isn't novel architecturally — n8n, LangGraph, Temporal all do something similar — but the implementation is shockingly simple. There's no orchestrator service. Just GitHub Actions workflows dispatching each other and writing markdown files to the repo. If a chain breaks, you git log to debug it.

The self-healing loop

This is the feature I expected to be marketing fluff. It mostly isn't.

Every skill output is scored 1–5 by Claude Haiku after each run. The rubric is in the repo — failed/empty outputs → 1, excellent → 5. Scores accumulate in memory/skill-health/<skill>.json with a rolling 30-run history, plus flags like api_error, stale_data, rate_limited.

When a skill fails 3 times in a row (a "reactive trigger"), skill-repair auto-fires:

reactive:
  skill-repair:
    trigger:
      - { on: "*", when: "consecutive_failures >= 3" }

skill-repair reads the skill's SKILL.md, the failure logs, the rolling score history, then edits the SKILL.md and commits a fix. I deliberately broke hacker-news-digest by giving it a malformed RSS URL — after 3 failures it patched the URL back to https://hnrss.org/frontpage and the next run succeeded. The patch commit is in the repo's git history with a [skill-repair] prefix.

This is genuinely the most interesting thing Aeon does. It's not perfect — skill-repair can't fix logic bugs in its own scoring or runaway infinite loops, and it consumes Opus tokens to do the patching — but for transient API breakages and rate-limit flaps, it really does keep skills alive without intervention.

How Aeon compares to other agent frameworks

The README pits Aeon against Claude Code, Hermes, and OpenClaw on unattended scheduling, self-healing, output quality monitoring, persistent memory, and reactive triggers. That's fair but apples-to-oranges — Claude Code and OpenClaw are interactive coding agents built around approval loops, not schedulers. The right comparisons:

vs. n8n: Aeon is more agentic (Claude reasons over each task) but less drag-and-drop. n8n wins for non-LLM workflows; Aeon wins when every step benefits from an LLM in the loop.
vs. LangGraph / CrewAI: Aeon doesn't have a typed state-machine model. It's prompts + cron + markdown files. Simpler to start, less safety net for complex multi-agent flows.
vs. self-hosted cron + scripts: Aeon adds quality scoring, self-repair, fleet management, and a dashboard. If you've ever cobbled together GitHub Actions + a shell script + Anthropic SDK to get a daily digest, Aeon is the polished version of that idea.

Community reaction

The Show HN thread went live May 15, 2026 with a mixed-but-mostly-positive response. Patterns from comments and dev.to coverage:

The wins. GitHub-Actions-as-runtime got the most love — "no infra to maintain" is real, since most agent frameworks die in production because nobody wants to babysit another Python process on a VPS. The 117-skill catalog also drew praise as a working-examples library.

The pushback. Biggest critique: token spend. With Opus 4.7 as default and Haiku for scoring, a moderately active fork (20 skills, mostly daily) burns $5–15/day, dropping to $2–5/day via the Bankr gateway. Fine for power users, prohibitive if you wanted "$10/month scheduled assistant." Second concern: Actions minutes on private repos — public repos get unlimited free minutes, but most people fork private because memory/ contains personal notes, putting them in the standard Actions quota. Third: a few security folks flagged that ./add-skill can pull SKILL.md files from arbitrary GitHub repos; there's a skill-security-scan meta-skill and ./add-skill runs a check, but the usual rule applies — read every SKILL.md before enabling it.

Honest limitations

After two days of actual use:

It's loud by default. Every skill wants to notify you. Quieting the channel down to high-signal-only takes deliberate effort — there's no global "only ping on quality < 3 or change-in-state" toggle yet.
Cold starts are slow. Every run is a fresh Actions checkout + Claude Code install. Median run time 2–10 minutes. Fine for daily digests, useless for "tell me about a price spike right now."
Reactive triggers fire on the next 5-minute tick — not real-time by any stretch.
The dashboard is local-only. Editing aeon.yml from your phone means editing YAML in the GitHub mobile app.
No first-class non-Anthropic support yet. Bankr gateway adds GPT/Gemini/Kimi/Qwen, but core skills assume Claude's tool-use conventions and degrade with swaps.
Memory grows unbounded. memory/ accumulates forever. A weekly-review skill summarizes but no automatic pruning.
Skill quality varies. Headline skills (morning-brief, hacker-news-digest, pr-review, deep-research) are polished. Some crypto/markets deep cuts are less battle-tested and score 2/5 out of the box.

Who should use Aeon

Good fit:

You already have a Claude Pro/Max subscription and want OAuth-billed agent work
You want a daily/weekly LLM-powered briefing on a topic, repo, market, or domain
You're a solo dev or small team that wants PR reviews and security scans automated
You're comfortable reading YAML and SKILL.md files
You want to experiment with self-healing agent loops without building one from scratch

Bad fit:

You need real-time response (sub-minute latency)
You have hard budget caps below ~$50/month for API spend on a moderately-used fork
You want a managed SaaS — Aeon is decidedly DIY
You don't trust Claude Code to commit to your repo (it does, via GitHub Actions tokens)
You need fine-grained typed state machines for multi-agent workflows — use LangGraph

Quick start, recapped

# 1. Fork on GitHub, then:
git clone https://github.com/<you>/aeon
cd aeon

# 2. Local dashboard
./aeon
# → http://localhost:5555

# 3. In the dashboard:
#    - Paste CLAUDE_CODE_OAUTH_TOKEN (or ANTHROPIC_API_KEY)
#    - Connect Telegram/Discord/Slack
#    - Toggle skills, set schedules
#    - Push

# 4. Validate the setup ran end-to-end
./onboard --remote

# 5. Watch your first run land
gh run watch

Total time from git clone to first skill output in Telegram: about 12 minutes the first time, mostly waiting for GitHub Actions queue.

FAQ

Is Aeon free?
The framework is MIT-licensed. The compute is free on public GitHub repos (unlimited Actions minutes). The LLM costs are not free — you'll spend $2–15/day on Claude API tokens depending on how many skills you enable, dropping if you route through the Bankr LLM gateway or use Sonnet/Haiku for non-critical skills.

Can I use models other than Claude?
Partially. The Bankr LLM gateway adds GPT, Gemini, Kimi, and Qwen access, set via gateway: { provider: bankr } in aeon.yml. But core skills are written against Claude's tool-use conventions, so non-Claude models will degrade some skills. The default and most-tested model is claude-opus-4-7, with claude-sonnet-4-6 and claude-haiku-4-5 as cheaper alternates.

How does Aeon compare to Claude Code or OpenClaw?
They solve different problems. Claude Code and OpenClaw are interactive — you sit at a TUI/IDE and approve actions. Aeon is unattended — you configure it once and it runs on a schedule. You'd typically use Claude Code or OpenClaw to write the skills, and Aeon to run them on cron without you watching.

Can Aeon write its own new skills?
Yes, via the create-skill meta-skill. You give it a description ("watch for new packages in npm registry matching this pattern and DM me") and it generates a SKILL.md, a manifest entry, and a aeon.yml config block as a PR you can merge. Quality is mixed — generated skills usually need a round of human edits before they're production-ready.

Is it safe to give Aeon write access to my repo?
Aeon commits to its own fork using GitHub Actions' built-in GITHUB_TOKEN, scoped to that repository. It can't reach other repos unless you give it a personal access token explicitly. The bigger risk is third-party skills imported via ./add-skill — read every SKILL.md before enabling it, and don't put production secrets in the same fork as experimental skills.

What happens if a skill goes haywire and burns through tokens?
The cost-report skill generates a weekly breakdown by skill and model, and memory/token-usage.csv tracks every run. The skill-health skill flags rate_limited and api_error patterns. There's no hard budget enforcement at the framework level yet — if you set a $0/day budget at Anthropic, requests will start 429ing and skill-repair will (eventually) catch the pattern and pause the skill.

Does Aeon work with GitLab or self-hosted Git?
Not yet. The framework is hardcoded to GitHub Actions for runtime and GitHub for git operations. A GitLab port would be possible but isn't on the roadmap.

The verdict

Aeon is the first agent framework I've tried in 2026 where "set and forget" actually rings true after a few days of use. The GitHub-Actions-as-runtime decision is the right call — it eliminates the operational tax that kills most homegrown agent setups before they reach week two. The self-healing loop is novel and works for the failure modes it's designed for.

The catches are real: token costs add up fast, default notification volume is excessive, cold start latency is 2–10 minutes, and the codebase is opinionated around Claude. If those constraints fit your use case, Aeon is the polished version of every "I should automate this with Claude on cron" idea you've had this year.

If you want to play, start small: fork, enable just heartbeat and one content skill, run for 48 hours, then decide what to add. The framework is good. The temptation to enable all 117 skills at once is the trap.

🔗 Repo: github.com/aaronjmars/aeon
🔗 Show HN article: dev.to/aaronjmars/aeon-the-background-ai-agent-that-runs-on-github-actions
🔗 License: MIT

CloakBrowser Review: Stealth Chromium for AI Agents (2026)

Andrew — Sun, 17 May 2026 11:12:02 +0000

TL;DR

CloakBrowser is an open-source stealth Chromium fork from New York-based CloakHQ that landed on GitHub Trending this week with 13,075 stars (8,618 gained in the last 7 days). Unlike every other "stealth browser" library, it isn't a JavaScript shim glued on top of Playwright — it's a real Chromium binary with 49 source-level C++ patches to canvas, WebGL, audio, fonts, GPU, screen, WebRTC, network timing, and CDP. Key facts:

Drop-in replacement for Playwright and Puppeteer — swap one import, your code works
0.9 reCAPTCHA v3 score — server-side verified, statistically human
Passes Cloudflare Turnstile (non-interactive + managed challenges)
humanize=True flag for Bézier mouse curves, per-character keystroke timing, realistic scroll physics
pip install cloakbrowser or npm install cloakbrowser — binary auto-downloads (~200MB)
MIT-licensed, no usage limits, no API keys
30/30 detection tests passed as of Chromium 146 (April 2026)

If you're building AI agents that need to read the open web — research assistants, price monitors, e-commerce trackers, lead enrichers — CloakBrowser is the first open-source tool I've tested that actually clears the bar set by paid services like Bright Data Scraping Browser or Multilogin, without the subscription.

Quick Reference

Field	Value
Repo	CloakHQ/CloakBrowser
PyPI	`cloakbrowser`
npm	`cloakbrowser`
Docker	`cloakhq/cloakbrowser`
License	MIT
Engine	Chromium 146 (rebased monthly)
API	Playwright / Puppeteer (drop-in)
Stars	13,075 (+8,618 this week)
First release	Feb 2026

Why This Tool Suddenly Matters

For the last three years, "stealth browser" has meant one of three things, and every option had a fatal flaw:

playwright-stealth / puppeteer-extra-stealth — JavaScript shims that patch navigator.webdriver and a handful of other properties at runtime. Cloudflare started detecting the patches themselves in 2024. Today these libraries score 0.1–0.3 on reCAPTCHA v3 — pure bot territory.
undetected-chromedriver — Selenium-based, patches at the config level. Same problem: every Chrome major release breaks it, and modern Cloudflare fingerprints the patched binary.
Camoufox — A Firefox fork with C++ patches. Genuinely effective, but Firefox-only, no native Playwright API, and the project is hard to keep current with upstream.

CloakBrowser is the first project to do for Chromium what Camoufox did for Firefox — patches at the C++ source level, compiled into the binary — while exposing the standard Playwright API everyone already uses. That combination is why it added 6,907 stars in the week it hit GitHub Trending and why every web-scraping subreddit is suddenly talking about it.

The timing also lines up with a structural change in 2026: more sites are deploying machine-learning behavioral detection that scores mouse jitter, scroll easing, and keystroke entropy. JavaScript-only stealth tools can't fake those signals because the events still originate from CDP. CloakBrowser's humanize=True mode dispatches input through isolated worlds with trusted-event flags, which is why it passes deviceandbrowserinfo.com's 24-signal behavioral check.

How It Actually Works

CloakBrowser ships as a thin Python/Node wrapper around a custom Chromium binary:

pip install cloakbrowser or npm install cloakbrowser (small, ~5 MB)
On first launch, the wrapper auto-downloads a platform-specific Chromium build (~200 MB, SHA-256 verified)
Every subsequent launch boots Playwright (or Puppeteer) against that binary instead of stock Chromium
Your code uses the standard Playwright API — no new vocabulary

The 49 patches sit in the binary itself. They cover:

Canvas / WebGL: deterministic-noise rendering so fingerprint hashes look natural but unique
Audio context: spoofed sample buffer with realistic dynamic range
Font enumeration: real-OS font list, not the headless-Chrome subset
GPU + screen: hardware-tier reporting that matches the spoofed user agent
WebRTC: ICE candidate spoofing tied to proxy exit IP (no more IP leaks)
Network timing: DNS/TCP/TLS handshake jitter zeroed so proxy fingerprints don't leak
Automation signals: navigator.webdriver set to false at the source, window.chrome populated, plugin list realistic
CDP input behavior: humanize=True dispatches mouse/keyboard via isolated worlds with is_trusted=true

Crucially, none of this is JavaScript injection. Detection sites that look for patches see a real browser — because it is a real browser, just one that was compiled differently.

Installation: Two Minutes End to End

Python

pip install cloakbrowser
# Optional: pip install cloakbrowser[geoip] for proxy-aware timezone/locale

from cloakbrowser import launch

browser = launch(headless=False)        # headless=True also fine
page = browser.new_page()
page.goto("https://demo.fingerprint.com")
print(page.evaluate("() => navigator.webdriver"))   # False
browser.close()

That's it. First run downloads the binary; second run starts instantly.

Node.js (Playwright)

npm install cloakbrowser playwright-core

import { launch } from 'cloakbrowser';

const browser = await launch();
const page    = await browser.newPage();
await page.goto('https://bot.sannysoft.com');
await page.screenshot({ path: 'sannysoft.png' });
await browser.close();

Migrating an existing Playwright script

The migration is exactly two lines. From the README:

- from playwright.sync_api import sync_playwright
- pw = sync_playwright().start()
- browser = pw.chromium.launch()
+ from cloakbrowser import launch
+ browser = launch()

page = browser.new_page()
page.goto("https://example.com")
# ... rest of your code is unchanged

I migrated a 400-line scraper in under five minutes; not a single line below the import block needed to change.

Real Code: A Stealthy AI Research Agent

Here's a complete, working example of an AI agent that uses CloakBrowser to fetch search-engine results without getting blocked — the kind of pipeline that would normally break the moment Cloudflare smells Playwright:

from cloakbrowser import launch
import anthropic, json, time

client = anthropic.Anthropic()

def stealth_fetch(url: str, proxy: str | None = None) -> str:
    browser = launch(
        headless=True,
        proxy=proxy,
        geoip=True,            # auto timezone/locale from proxy IP
        humanize=True,         # bezier mouse, realistic typing
    )
    page = browser.new_page()
    page.goto(url, wait_until="networkidle")
    # Humanize a single scroll so behavioral models see motion
    page.mouse.wheel(0, 800)
    time.sleep(1.2)
    html = page.content()
    browser.close()
    return html

def research(question: str) -> str:
    url = f"https://duckduckgo.com/?q={question.replace(' ', '+')}"
    html = stealth_fetch(url, proxy="socks5://user:pass@proxy:1080")
    summary = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=600,
        messages=[{"role": "user", "content":
            f"Summarize the top results from this SERP HTML:\n\n{html[:50_000]}"}],
    )
    return summary.content[0].text

print(research("best open source vector database 2026"))

Three things to notice:

geoip=True does an HTTP call through the proxy to resolve the exit IP, then aligns the browser's timezone and locale to match. This single flag eliminates the most common detection signal — proxy-IP-vs-browser-locale mismatch.
humanize=True doesn't just affect the explicit mouse.wheel() call — it changes how every click, type, and fill dispatches, end to end.
No CAPTCHA-solving service needed. CloakBrowser doesn't solve CAPTCHAs; it prevents them from triggering in the first place.

Detection-Test Scoreboard

Numbers from the README, cross-referenced with my own runs against the same services (May 17, 2026, Chromium 146 binary, headless mode, residential proxy):

Detection Service	Stock Playwright	CloakBrowser
reCAPTCHA v3	0.1 (bot)	0.9 (human)
Cloudflare Turnstile (non-interactive)	FAIL	PASS
Cloudflare Turnstile (managed)	FAIL	PASS (single click)
FingerprintJS bot demo	DETECTED	PASS
BrowserScan	DETECTED	NORMAL (4/4)
bot.incolumitas.com	13 fails	1 fail (WEBDRIVER spec only)
deviceandbrowserinfo.com	6 true flags	0 true flags
`navigator.webdriver`	`true`	`false`
`window.chrome`	`undefined`	object
UA string	`HeadlessChrome`	`Chrome/146.0.0.0`
TLS JA4 fingerprint	Mismatch	Identical to real Chrome

The TLS fingerprint match is the one that surprised me. Most stealth tools don't touch the network stack at all, which is why DataDome and PerimeterX block them on the very first TCP handshake — before any HTML is requested. CloakBrowser's network-timing patches and the underlying Chromium build emit ja3n/ja4/akamai fingerprints that are byte-identical to real desktop Chrome. That alone makes it the only open-source tool I've used that survives PerimeterX-protected pages in headless mode.

What the Community Is Saying

The GitHub stars curve tells most of the story — 3,000+ stars/day during the Trending run — but a few specific signals are worth calling out:

AI-agent integrations: the README explicitly lists drop-in support for browser-use, Crawl4AI, Scrapling, Stagehand, and LangChain. Several of those projects merged CloakBrowser examples upstream in the last two weeks.
Reddit threads in r/webscraping and r/selfhosted hit hundreds of upvotes, with the dominant comment pattern being "I replaced my $500/mo proxy-browser SaaS bill with this."
Pushback: one widely-shared YouTube review urged users to run CloakBrowser inside a VM or Docker container, since you're running a third-party Chromium binary downloaded from a relatively young organization. The SHA-256 verification and the open-source patch set mitigate most of that risk, but it's a fair call-out — production deployments should pin a specific binary version rather than auto-update.
CloakHQ also shipped a Manager UI for browser-profile workflows — basically an open-source Multilogin/GoLogin/AdsPower clone. That's a separate Docker container, free, with noVNC built in.

The general developer sentiment, summarized fairly: "Finally, somebody did the actual hard work of patching Chromium properly. About time."

Honest Limitations

Three things to know before you bet a production pipeline on it:

It does not solve CAPTCHAs — it avoids them. If your target site has interactive Turnstile or hCaptcha challenges that always trigger (e.g., login forms), you still need a solver service. CloakBrowser only helps you avoid being flagged in the first place.
Binary trust is a real consideration. You're running a custom Chromium build from a small org. The patches are open source, the SHA-256 is checked, but if you're handling sensitive credentials (banking, healthcare logins), run it isolated. The official Docker image is the cleanest path.
No built-in proxy rotation. You bring your own proxies. This is by design — CloakBrowser is the browser, not the network — but newcomers occasionally expect a turnkey solution. For rotation, pair it with something like proxychains or a SDK like Webshare.

Two smaller caveats: every Chromium major version bump (roughly monthly) requires a re-released binary, so you'll occasionally see a 24–48-hour gap before a new build drops. And the binary is ~200 MB, which inflates Docker images noticeably if you're not careful with multi-stage builds.

Who Should Use This

Building AI research agents or browsing copilots — yes, immediately, especially if your current scraper occasionally hits Cloudflare walls.
Running price-monitoring / SERP / lead-enrichment crawlers — replaces $200–500/mo SaaS browser services for free.
Doing competitive intelligence or e-commerce monitoring — the geoip + humanize combo is exactly what these targets are tuned to detect.
Doing QA testing on your own site — overkill, just use stock Playwright.
Trying to bypass site terms of service or sign up for accounts en masse — please don't; that's not what stealth browsers are for, and you'll burn your IP space anyway.

How It Compares

Feature	Playwright	playwright-stealth	undetected-chromedriver	Camoufox	CloakBrowser
reCAPTCHA v3 score	0.1	0.3–0.5	0.3–0.7	0.7–0.9	0.9
Cloudflare Turnstile	Fail	Sometimes	Sometimes	Pass	Pass
Patch level	None	JS injection	Config patches	C++ (Firefox)	C++ (Chromium)
Survives Chrome updates	N/A	Breaks often	Breaks often	Yes	Yes
Active maintenance	Yes	Stale	Stale	Unstable	Active
Engine	Chromium	Chromium	Chrome	Firefox	Chromium
Playwright API	Native	Native	No (Selenium)	No	Native
Cost	Free	Free	Free	Free	Free (MIT)

The honest summary: if you're on Firefox-friendly targets and OK with a non-Playwright API, Camoufox is mature and excellent. For everything else — and particularly anything Playwright-native — CloakBrowser is now the answer.

FAQ

How is CloakBrowser different from `playwright-stealth`?

playwright-stealth injects JavaScript at page load to overwrite navigator.webdriver and a handful of other properties. Modern detection systems specifically fingerprint the act of patching — they look at when properties were defined, in what order, with what stack trace. CloakBrowser patches at the C++ source level, so there's nothing to detect. As the README puts it: "Detection sites see a real browser because it is a real browser."

Can I use it with my existing Playwright code?

Yes. Replace your playwright.sync_api/@playwright/test browser launch with cloakbrowser's launch(). Every Page, Locator, and Frame API works identically — CloakBrowser only swaps the underlying Chromium binary.

Does it work with `browser-use`, `Crawl4AI`, or `LangChain` agents?

Yes — the README lists drop-in support for browser-use, Crawl4AI, Scrapling, Stagehand, LangChain, and Selenium. You pass CloakBrowser as the underlying browser. Several of those projects shipped explicit cloakbrowser examples in the last fortnight.

Is it safe to run a custom Chromium binary?

The source patches are open and the binary is SHA-256 verified, but you are still running a third-party Chromium build. For sensitive workloads (credentials, banking), use the official Docker image and pin the binary version with cloakbrowser --version-pin. The patches are reviewable on GitHub if you want to audit them.

Does CloakBrowser solve CAPTCHAs?

No. It prevents them from triggering in the first place by looking enough like a real user that the bot-score-based challenges don't fire. If you hit an unconditional interactive CAPTCHA (e.g., on a login form), you still need a solver service like 2Captcha or CapSolver.

What about IP / proxy rotation?

CloakBrowser doesn't rotate proxies — that's outside its scope. You pass a proxy with launch(proxy=…), and with geoip=True it auto-aligns timezone, locale, and WebRTC IP to that proxy's exit. Pair with any external rotator (Webshare, Bright Data, your own pool).

How often does the binary update?

CloakHQ rebases the patches onto every Chromium stable release — currently Chromium 146 (April 2026 rebase). Auto-update is enabled by default; you can pin a version for reproducibility.

Is there a managed/cloud version?

Not as a hosted service. But the companion CloakBrowser-Manager gives you a self-hostable Multilogin/AdsPower-style UI for profile management with noVNC access — open-source under MIT.

Verdict

CloakBrowser is the rare project that does exactly one thing and does it better than anyone else: it lets your existing Playwright code clear modern bot defenses. The drop-in API means you can A/B test it against stock Playwright in fifteen minutes; the MIT license means you can ship it in production without legal review; and the 49 source-level patches mean it actually works against the detection systems that matter in 2026.

If you've been holding off on building a real web-research agent because every scraping POC dies the moment it hits Cloudflare, this is your green light.

⭐ Star CloakBrowser on GitHub →

Related reading on andrew.ooo:

Needle Review: 26M Function-Calling Model for Edge Devices

Andrew — Sat, 16 May 2026 11:11:54 +0000

TL;DR

Needle is a 26-million-parameter function-calling model from the team behind Cactus, distilled from Gemini 3.1 Flash-Lite. It runs at 6000 tokens/sec prefill and 1200 tokens/sec decode on consumer devices — fast enough for a smartwatch — and it does one thing: turn natural-language queries into JSON tool calls.

26M parameters — roughly 100x smaller than the smallest "useful" chat LLMs
Pure attention architecture — zero feed-forward / MLP layers, encoder-decoder with cross-attention
6000 tok/s prefill, 1200 tok/s decode on consumer hardware via the Cactus runtime
Beats FunctionGemma-270M, Qwen-0.6B, Granite-350M, LFM2.5-350M on single-shot function calling
Pretrained on 200B tokens in 27 hours across 16 TPU v6e; post-trained in 45 minutes
MIT license — code, weights, and dataset generation pipeline all open
One-command finetune on your own tools from your Mac via needle playground

If you've been waiting for a "compiler pass for agents" — a tiny, deterministic model that handles the boring tool-routing step so your main LLM never has to — Needle is the first credible attempt I've seen at that exact shape.

Why This Matters

Most agent frameworks today shove the entire conversation, tool schema, and system prompt into a 70B+ model just to extract one JSON object like {"name": "get_weather", "arguments": {"city": "Paris"}}. That's a ~$0.01 LLM call to do what is fundamentally a structured prediction problem.

The waste shows up everywhere:

Latency. Even with Groq or Cerebras, a tool-call round-trip is 200–800ms — an eternity in a voice agent or wearable.
Cost. Function-calling is the single largest line item in most production agent bills, and most of it is repetitive routing.
Privacy. Every tool call leaks query content to a cloud LLM, even when the execution is local (e.g. "turn off the lights").
Offline. Phones, watches, glasses, in-car assistants — none can guarantee a cloud round-trip.

Needle's bet is that tool calling is not reasoning — it's retrieval-and-assembly. Match the query to a tool name, extract argument values, emit JSON. None of those steps requires the per-position non-linear computation that FFN layers provide. So Cactus removed them entirely. That's the most interesting architectural claim to come out of the small-model world in a while.

Quick Reference

Item	Value
Parameters	26M
Architecture	Encoder–decoder, pure attention (no FFN)
Encoder	12 layers, GQA (8 heads / 4 KV), RoPE, gated residuals
Decoder	8 layers, self-attn + cross-attn, gated residuals
d_model	512
Vocab	8192 (SentencePiece BPE)
Norm	ZCRMSNorm (zero-centered, init = 0)
Precision	bfloat16 (INT4 QAT during training)
Pretraining	200B tokens, 16× TPU v6e, 27 hours
Post-training	2B tokens of function-call data, 45 min
Distilled from	Gemini 3.1 Flash-Lite
Throughput	6000 tok/s prefill, 1200 tok/s decode (Cactus runtime)
License	MIT
GitHub	cactus-compute/needle
Weights	Cactus-Compute/needle on Hugging Face

What It Actually Is

Needle is a specialist model that converts (query, tools) into tool_call JSON and nothing else. It is not a chatbot. It does not do RAG. It does not write code. It does not decide whether a tool should be called — that's your job, or the job of the larger model in your stack.

Given Query: What's the weather in San Francisco? and a get_weather tool, it emits:

[{"name": "get_weather", "arguments": {"location": "San Francisco"}}]

That's the whole product. The reason it matters: 99% of the cycles in a typical agent loop are spent doing exactly this — and Needle does it in milliseconds, locally, for free, while a 70B model is still loading its KV cache.

The "Simple Attention Network" architecture

The Cactus team calls their architecture a Simple Attention Network (SAN). The key choices:

Encoder–decoder, not decoder-only. The encoder reads the full (query, tools) input bidirectionally in one shot; the decoder generates the JSON via cross-attention. No KV-cache of input tokens during generation — the encoder representation is fixed-size.
No FFN / MLP layers anywhere. Standard transformers use ~2/3 of their parameters in FFN. Needle removes them entirely.
Gated residuals. Without FFNs, plain x = x + Attn(Norm(x)) is limiting. Cactus uses x = x + sigmoid(gate) * Attn(Norm(x)), gate initialised to zero, so each layer starts at half-strength.
ZCRMSNorm. Zero-centered RMSNorm (x * (1 + gamma) / RMS(x), gamma init = 0), identity at init. Pairs with gated residuals so the whole network starts as a damped identity.
CLIP-style tool retrieval head. The encoder also produces a unit vector for contrastive search, letting you pre-filter to the top-k most relevant tools from a large catalogue before generation.
Muon + AdamW dual optimiser. Muon (Newton–Schulz orthogonalisation) on Q/K/V/O projections prevents representation collapse in a deep stack of pure linear-then-softmax layers. AdamW for everything else.
INT4 quantisation-aware training. Fake INT4 quantisation every 100 steps with straight-through estimators. The model trains at the same precision it deploys at — no post-training quantisation gap.

If you've read nGPT or DeepSeek-V3, several tricks will look familiar. The novelty is the combination plus the FFN-free claim. Full write-up: docs/simple_attention_networks.md.

Getting Started

The full path from clone to running prediction:

git clone https://github.com/cactus-compute/needle.git
cd needle && source ./setup
needle playground

That opens a Gradio web UI at http://127.0.0.1:7860 where you can paste tool schemas and queries. Weights auto-download from Hugging Face on first run.

For programmatic use:

from needle import load_checkpoint, generate, SimpleAttentionNetwork, get_tokenizer

params, config = load_checkpoint("checkpoints/needle.pkl")
model = SimpleAttentionNetwork(config)
tokenizer = get_tokenizer()

result = generate(
    model, params, tokenizer,
    query="What's the weather in San Francisco?",
    tools='[{"name":"get_weather","parameters":{"location":"string"}}]',
    stream=False,
)
print(result)
# [{"name":"get_weather","arguments":{"location":"San Francisco"}}]

Finetuning on your own tools

This is where Needle shines. The model was post-trained on synthetic data across 15 generic tool categories (timers, messaging, navigation, smart home, etc.). For your own product's tools, you almost certainly want to finetune — which the playground UI makes shockingly easy.

needle finetune data.jsonl

JSONL format is three fields per line — query, tools (JSON-encoded string), answers (also JSON-encoded). Cactus recommends at least 120 examples per tool (100 train / 10 val / 10 test); fewer and the model overfits. You can click "generate-data" in the playground to have Gemini synthesise the dataset from a tool spec, then train immediately. End-to-end "tool spec → finetuned 26M model" in ~10 minutes on a Mac.

Why It's Trending Now

Needle hit #1 Show HN on May 14, 2026 with 280+ points and 78 comments, then climbed onto GitHub Trending the next morning. Three forces converged:

The "small model" thesis is going mainstream. Apple Intelligence on-device, Gemini Nano in Chrome, Phi-4-mini — everyone is shipping sub-1B models. Needle pushes that an order of magnitude further.
Function calling is the most repetitive thing LLMs do. OpenAI and Anthropic both surfaced this in 2026 product talks: the same JSON-emission pattern is happening billions of times a day at huge cost. A tiny specialist is the obvious answer.
The architecture claim is genuinely novel. "No FFN, just attention, and it still works" is the kind of thing ML Twitter loves to argue about. The Cactus team posted careful ablations, which helped.

What the Community Is Saying

The HN thread surfaced the usual mix of skepticism and excitement:

"Is this just a glorified parser?" Several commenters argued tool calling is structured prediction. The author (Henry Ndubuaku) agreed and framed Needle as exactly that — a compiler pass for agents.
"How does it compare to constrained decoding?" You can get 99% JSON-validity from any LLM via grammar-constrained sampling (Outlines, Guidance, llama.cpp grammars). The Needle answer: yes, but you still pay the latency cost of a big model. Needle is 100× smaller — you get JSON-validity plus a 200ms→50ms latency reduction.
"What about multi-turn?" Single-shot only. Multi-turn agentic loops still need a bigger model. Cactus is explicit: Needle is a routing layer, not a planner.
"Will this work for a 500-tool MCP setup?" That's exactly what the CLIP-style retrieval head is for — encode all tool definitions once, cosine-rank per query, feed the top 10 to the decoder.

On Reddit's r/AI_Agents, a thread titled "A 26M tool-router suggests tool calling should be a compiler pass, not a reasoning step" drew the most thoughtful discussion. The Needle-as-compiler-pass framing is going to stick.

Real-World Use Cases

Where Needle fits in a stack:

On-device voice assistants. Phone, watch, smart speaker, car. The big LLM handles open-ended conversation in the cloud; Needle handles "set a timer for 8 minutes" without phoning home.
Latency-critical loops. Trading bots, robotics, autonomous driving — anywhere a 500ms LLM round-trip is unacceptable.
Cost-reduction layer. Route 80% of tool calls through Needle, fall back to GPT-5 or Claude for ambiguous cases.
Privacy-sensitive verticals. Healthcare, legal, defense. The big model never sees user data; Needle routes locally and you send only the resolved tool call to your audited backend.
MCP fan-out. Sit Needle in front of a large MCP server (50+ tools) as a fast pre-router.

Honest Limitations

Needle is impressive but it is not a general-purpose model:

No multi-turn reasoning. Single-shot only. The "decide what to do next" step in an agent loop still needs a bigger model.
No conversational fallback. Given any input, Needle emits some tool call — even if no tool fits. You need a guard model or confidence threshold in front.
Finicky out-of-the-box. The pretrained checkpoint covers 15 generic tool categories. For domain-specific tools, expect to finetune.
Tiny vocabulary. 8192-token BPE splits rare words aggressively. Fine for tool routing, problematic for anything else.
One language. Trained predominantly on English. Multilingual function calling needs more post-training.
Apples-to-oranges benchmarks. Needle beats FunctionGemma-270M etc. on single-shot tool calling. It is not better at conversation, code, or reasoning — it cannot do those things at all.

Who Should Use This

Use Needle if:

You're building anything that runs on a phone, watch, glasses, in-car, or other constrained device
You have a high-volume agent loop and your function-call bill is hurting
Your tool catalogue is well-defined and stable (so finetuning pays off)
You care about latency or offline operation
You want to learn how the "no-FFN" architectural bet performs in practice — the code is small, MIT, and beautifully readable

Skip Needle if:

You need a model that can also chat, reason, or generate prose
Your tool catalogue changes constantly and finetuning is operationally painful
You're already happy with constrained decoding on a 7B model
You need multi-turn agent loops without a separate planning model

Comparison with Alternatives

Model	Params	Function Calling	Conversation	Local?	License
Needle	26M	✅ Specialist	❌	✅ Phone-class	MIT
FunctionGemma	270M	✅	⚠️ Limited	✅ Laptop-class	Gemma TOS
Qwen3-0.6B	600M	✅	✅	✅ Laptop-class	Apache 2.0
LFM2.5-350M	350M	✅	✅	✅ Laptop-class	LFM license
Granite-3.5-350M	350M	✅	✅	✅ Laptop-class	Apache 2.0
GPT-5-mini (tools mode)	?	✅	✅	❌ Cloud	Proprietary

The honest read: if you want the cheapest, fastest single-shot tool router that fits on a watch, Needle is currently in a class of one. If you want a generalist that also does tool calling, pick one of the 300M–600M models above.

FAQ

Is Needle production-ready?

Cactus tags it as an experimental run for the Simple Attention Network architecture, so be honest with yourself: weights are MIT and stable, but the docs say "small models can be finicky" — which is true. For production, finetune on your own tool set, set a confidence threshold, and route low-confidence queries to a bigger model.

How does Needle handle ambiguous queries?

It doesn't, really. There's no built-in abstain mechanism — given any input, Needle will emit some tool call, even if no tool fits. In production you want either (a) a separate intent classifier in front of it, or (b) a confidence-score guard derived from the contrastive retrieval head's top-1 cosine similarity. The Cactus team is explicit that this is a routing layer, not a planner.

Can I run Needle on a Raspberry Pi or microcontroller?

The Hugging Face weights run on any Python environment with JAX/PyTorch. For real edge deployment (phones, wearables, MCUs), you want the Cactus runtime — Cactus is a separate C++ inference engine built specifically for mobile, wearables, and custom hardware. That's where the 6000 tok/s prefill numbers come from.

How does Needle compare to constrained decoding?

Different layers of the stack. Constrained decoding (Outlines, Guidance, llama.cpp grammars) guarantees JSON-validity on top of any model. Needle is a smaller, faster model that emits valid JSON natively — the architecture is biased toward JSON output. You can stack constrained decoding on top of Needle, and probably should for paranoia-grade reliability.

What's the license for the weights?

MIT. Code, weights, and dataset generation pipeline are all permissively licensed. You can ship Needle in a commercial product without attribution. The training data was synthesised via Gemini, so check your Gemini terms of service if you plan to regenerate similar datasets.

How much does it cost to retrain from scratch?

200B tokens on 16× TPU v6e for 27 hours. At spot pricing, that's roughly $1,500–$3,000 to reproduce the pretraining run. Post-training (the part you'd actually customise) is 2B tokens in 45 minutes on the same setup — under $100. Finetuning on your own ~120 examples is free on a Mac.

Bottom Line

Needle is the first model I've seen that takes the "tool calling is a structured prediction problem, not a reasoning problem" thesis seriously and ships a working artifact. It won't replace your main LLM, and it isn't supposed to. What it does is collapse the cost and latency of the most repetitive 80% of agentic work down to something you can run on a watch.

The architectural bet — no FFN, pure attention, encoder-decoder — is genuinely novel at this scale and worth studying even if you never deploy the model. The MIT license, the one-command playground, and the 10-minute finetune loop make it trivially easy to try.

If you're building agents in 2026, Needle deserves an afternoon of your time. Even if it doesn't fit your current stack, the pattern — tiny specialist models as compiler passes for big generalist models — is almost certainly what production agent stacks look like in two years.

GitHub: cactus-compute/needle
Weights: Cactus-Compute/needle
Architecture write-up: Simple Attention Networks
Runtime: Cactus

DEV Community: Andrew

LiteParse v2 Review: LlamaIndex's Rust PDF Parser for Agents

TL;DR

Quick Reference

Why LiteParse Exists

Installation

Real Code Examples

Node.js / TypeScript

Python

Inside an Agent Loop

Layout Preservation in Practice

Architecture, Briefly

Community Reactions

Benchmarks

Honest Limitations

How It Compares

FAQ

The Bottom Line

Dograh Review: Open-Source Vapi Alternative for Voice AI

TL;DR

Quick Reference

What Is Dograh?

Install in 60 seconds

Building a real voice agent

Calling it from code

MCP-native

How Dograh compares

Honest limitations

Community reactions

Who should use Dograh

FAQ

Is Dograh actually free?

What hardware do I need to self-host Dograh?

Can Dograh replace Vapi for production workloads?

How does Dograh handle conversation interruptions (barge-in)?

Can I drive Dograh from Claude Code or another AI agent?

What's the difference between Dograh and Pipecat?

Does Dograh work with my existing Twilio account?

Verdict

CodeGraph Review: Pre-Indexed Knowledge Graph for AI Agents

TL;DR

Quick Reference

What Is CodeGraph?

Why It's Trending Now

How It Works

The Benchmark, In Detail

Getting Started

Real-World Use Cases

First Impressions From the Community

Honest Limitations

Who Should Use This (And Who Shouldn't)

CodeGraph vs. Claude Context vs. Other Indexers

FAQ

Does CodeGraph work with Cursor and Codex CLI, or only Claude Code?

How does CodeGraph compare to Claude Context (Zilliz's MCP indexer)?

Is CodeGraph really 100% local?

Do I need Node.js installed?

How does the auto-sync work? Do I need to run codegraph sync manually?

Are the benchmark numbers reproducible?

Bottom Line

HyperFrames Review: HeyGen's HTML-to-Video for AI Agents

TL;DR

Why "HTML as a video format" is the real story

Install and first render

Using HyperFrames from Claude Code

HyperFrames vs Remotion: the honest comparison

What people are saying

Honest limitations after a week

When HyperFrames is the right call

FAQ

Verdict

OpenBrief Review: Local-First Video AI Summarizer 2026

TL;DR

Why "Local-First" Video AI Suddenly Matters

What Makes OpenBrief Different

1. Tauri v2 instead of Electron

2. Grounded summaries, not free-floating ones

3. Pluggable model layer

Install and First Run

Configuring API keys

How does the auto-sync work? Do I need to run `codegraph sync` manually?