[2026.06 Week 2] Five Trending Repos of the Week
Five GitHub repositories trending this week.
TL;DR
Agent skills became a packaging format. A large share of the trending repos were curated “skill” bundles for Claude Code, Codex, and other agents, spanning design, marketing, research writing, finance, and security. Google, OpenAI, and Vercel all shipped their own skill catalogs this week.
The token economy kept growing. Close to a dozen repos competed to cut agent token use and cost through compression, code indexing, on-disk session analytics, or proxying, several quoting 40 to 95 percent reductions.
Free and pooled model access stayed popular. Another run of proxies trended that aggregate free-tier API keys or pool paid subscriptions to hand out model access across providers.
Local-first agent infrastructure showed up across stacks. MicroVM sandboxes, resident in-memory file-search indexes, and offline workspaces trended in Rust, Swift, Go, and Python alike.
This week’s picks:
container (⭐ 36.1k). Apple’s tool for running Linux containers on a Mac, each one inside its own lightweight VM on Apple silicon.
headroom (⭐ 25.9k). A compression layer that shrinks tool outputs, logs, and RAG chunks before they reach the model.
fff (⭐ 8.4k). A Rust file-search toolkit for AI agents and Neovim that answers queries in single-digit milliseconds.
butterbase (⭐ 2.1k). An open-source, AI-native backend-as-a-service with Postgres, auth, storage, and functions.
agentsview (⭐ 2.3k). A local-first analytics tool that tracks token usage and cost across Claude Code, Codex, and 20-plus other agents.
apple/container
⭐ 36.1k · Swift
container is Apple’s open-source tool for running Linux containers on macOS. You drive it from the command line much like Docker, pulling and running standard OCI images, except each container boots inside its own lightweight virtual machine tuned for Apple silicon. The distinguishing choice is that isolation model. Docker Desktop runs every container inside one shared Linux VM, while container gives each container a dedicated VM that boots in under a second.
That choice lives in the bootstrap path, which runs once per container. Each call builds a fresh VM rather than scheduling a process onto a shared one.
var kernel = try bundle.kernel
kernel.commandLine.kernelArgs.append("oops=panic")
kernel.commandLine.kernelArgs.append("lsm=lockdown,capability,landlock,yama,apparmor")
let vmm = VZVirtualMachineManager(
kernel: kernel,
initialFilesystem: bundle.initialFilesystem.asMount,
rosetta: config.rosetta,
logger: self.log
)Every container gets its own kernel, loaded with hardened boot arguments. oops=panic turns a kernel oops into an immediate panic, so a compromised or broken guest dies instead of limping along. The lsm list stacks lockdown, landlock, yama, and apparmor security modules inside the guest. Later in the same function the code wraps this manager in a LinuxContainer and calls container.create() (line 287), which is what actually boots the VM.
Booting a full VM per container would normally be too slow to be practical. Apple leans on Virtualization.framework and a minimal initial filesystem to get boot times under a second, which is what makes one-VM-per-container affordable. The payoff is a separate kernel boundary around every workload instead of shared-kernel namespaces, plus a dedicated IP per container through the vmnet framework, so containers talk to each other without port-forwarding gymnastics.
chopratejas/headroom
⭐ 25.9k · Python
headroom is a compression layer that sits between an agent and the model. You run it as a library, a proxy, or an MCP server in front of your LLM calls, and it shrinks the bulky tool outputs, logs, and retrieved chunks that agents stuff into context. The claim is 60 to 95 percent fewer tokens with the same answers, and the compression is deterministic, so no extra model call is spent compressing.
The saving is easiest to see on a tool output that lists files. Two thousand results repeat "type":"file" and "language":"python" on every row, and most of the tokens are those field names printed over and over. headroom’s default path detects that the array is tabular, factors the keys into one schema header, and renders the rows as CSV.
fn write_table(out: &mut String, schema: &Schema, rows: &[Row],
original_count: usize, fmt: &CsvSchemaFormatter) {
// Declaration line: [N]{col:type,col:type,...}
out.push('[');
out.push_str(&rows.len().to_string());
out.push_str("]{");
let col_decl: Vec<String> = schema.fields.iter()
.map(|f| format!("{}:{}", f.name, f.type_tag))
.collect();
out.push_str(&col_decl.join(","));
out.push('}');
out.push('\n');
// Rows.
for row in rows {
let cells: Vec<String> = row.0.iter().map(format_cell).collect();
out.push_str(&cells.join(","));
out.push('\n');
}
}The field names are written once, on the declaration line, as [N]{col:type,...}. Every row that follows is bare comma-separated values. For two thousand rows the key type goes from two thousand copies to one. The Python package is now a thin shim, and this renderer is the Rust core doing the actual work. headroom borrows the [N]{cols} row-count declaration from TOON but keeps plain CSV escaping for the values, on the reasoning that every model has seen millions of CSV examples in training and parses them reliably.
This path is lossless. When an array is not cleanly tabular and CSV would not save at least 30 percent, headroom falls back to dropping rows, but it replaces the dropped block with a <<ccr:HASH>> marker and caches the originals, so the model can pull them back on demand. The answers stay the same because nothing semantic is removed. What gets cut is structural redundancy and repeated keys.
dmtrKovalenko/fff
⭐ 8.4k · Rust
fff is a file-search toolkit written in Rust and built for code that runs many searches in a row. The same core ships as a native crate, a C library, a Node SDK, and an MCP server, so an AI agent or a Neovim picker can hit it hundreds of times per session. The headline benchmark is sub-10ms per query on a 500k-file Chromium checkout, against the 3 to 9 seconds a fresh ripgrep spawn takes on the same tree.
Most of that speed comes from one decision. A command-line tool like ripgrep starts a new process and walks the directory tree on every invocation. fff scans the tree once, keeps the whole index resident in a long-lived process, and lets a background watcher patch it as files change.
pub(crate) struct FileSync {
git_workdir: Option<PathBuf>,
/// Base files laid out in two partitions, each sorted by
/// (parent_dir, filename):
/// files[..indexable_count] - indexable
/// files[indexable_count..base_count] - original-unindexable
/// files[base_count..] - overflow (created on demand)
files: StableVec<FileItem>,
indexable_count: usize,
base_count: usize,
/// Number of active present files that exist in the file system
pub(crate) live_count: usize,
dirs: StableVec<DirItem>,
overflow_builder: Option<ChunkedPathStoreBuilder>,
bigram_index: Option<Arc<BigramFilter>>,
bigram_overlay: Option<Arc<RwLock<BigramOverlay>>>,
chunked_paths: Option<Arc<ChunkedPathStore>>,
}FileSync is the resident index. The initial scan fills the files vector and sorts it into two partitions, indexable and unindexable, each ordered by directory and filename so lookups stay cache-friendly. Files created after the scan land in a third region, the overflow partition, appended on demand. That layout is what lets the background watcher apply a single filesystem event without rebuilding the whole index.
A query then costs almost nothing. fff takes a read lock on this structure and fuzzy-matches against the warm slice already in memory, with no process spawn and no directory walk. The SIMD-accelerated matching and the frecency ranking that boosts recently opened files are real, but they are second-order. The bulk of the win against ripgrep is simply never paying the per-query startup and rescan cost.
butterbase-ai/butterbase
⭐ 2.1k · TypeScript
butterbase is an open-source backend-as-a-service with the pieces you would expect, a Postgres data plane, auth, storage, and serverless functions. It looks like a Supabase alternative until you notice the surface it is built around. Instead of a human clicking through a dashboard, an AI agent operates the whole backend through a built-in MCP server that exposes roughly 35 tools.
Each tool maps to a backend operation, and the tool’s description doubles as the prompt that teaches the model how to use it. manage_schema is a good example.
server.tool(
'manage_schema',
`Manage the database schema: read, apply, preview, and audit migrations.
... a declarative schema DSL plus examples documented inline for the model ...`,
{
app_id: z.string().describe('The app ID'),
action: z.enum(['get', 'apply', 'dry_run', 'list_migrations']),
schema: SchemaInput.optional(),
name: z.string().optional(),
},
{ title: 'Manage Schema', destructiveHint: false, idempotentHint: true },
async (args) => {
const { app_id, action } = args;
switch (action) {
case 'get': // text() wraps the JSON result as MCP content
return text(await apiGet(`/v1/${app_id}/schema`));
case 'apply':
return text(await apiPost(`/v1/${app_id}/schema/apply`,
{ schema: args.schema, name: args.name }));
case 'dry_run':
return text(await apiPost(`/v1/${app_id}/schema/apply`,
{ schema: args.schema, dry_run: true }));
case 'list_migrations':
return text(await apiGet(`/v1/${app_id}/migrations`));
}
}
);The agent passes a desired schema as a declarative JSON object. apply diffs it against the current database and runs the safe DDL, dry_run returns the SQL it would run without executing, and the operation is idempotent so calling it twice is harmless. The tool body is a thin wrapper over the control-api REST endpoints. The substance is in the long description string, trimmed here, which spells out the schema DSL, worked examples, the destructive-op opt-in, and quota error codes. That text is the interface the model reads.
Stack that across manage_rls, deploy_function, manage_storage, and the rest, and building a backend becomes a sequence of MCP tool calls rather than dashboard clicks. The MCP server is not a convenience bolted onto butterbase. It is the product surface, which is what “AI-native” buys over a conventional BaaS.
kenn-io/agentsview
⭐ 2.3k · Go
agentsview is local-first analytics for coding-agent sessions. It reads the session files that Claude Code, Codex, and more than 20 other agents already write to disk, indexes them into SQLite, and serves a web UI plus a CLI for tracking token usage and cost. The pitch that drew attention is a 100x speedup over ccusage and similar tools.
That number comes from not re-parsing. ccusage walks the raw JSONL session files on every run. agentsview parses each file once into SQLite, then skips any file whose modification time has not changed since the last sync.
mtime := info.ModTime().UnixNano()
cacheSkip := e.shouldCacheSkip(file)
// Skip files cached from a previous sync whose mtime is unchanged.
if cacheSkip {
e.skipMu.RLock()
cachedMtime, cached := e.skipCache[file.Path]
e.skipMu.RUnlock()
if cached && cachedMtime == mtime {
return processResult{skip: true, mtime: mtime, cacheSkip: true}
}
}
var res processResult
switch file.Agent {
case parser.AgentClaude:
res = e.processClaude(ctx, file, info)
case parser.AgentCodex:
res = e.processCodex(file, info)
// ... 25 more agent parsers ...
}Each file is stat’d once for its modification time, then checked against an in-memory skipCache keyed by path. If the cached mtime matches, the function returns immediately and never parses the file. Only changed or new files fall through to the big switch, which routes each one to a per-agent parser that normalizes 20-plus different session formats into one schema. For live sessions that keep appending, agentsview goes a step further and indexes only the new JSONL delta rather than the whole file.
The result is that work per sync is proportional to what changed, not to the full history. Once the data is in SQLite, queries run against the index instead of re-reading any files at all. That is where the 100x lives. The headline is faster reporting, but the design idea is treating the on-disk session logs as a source to incrementally ingest, not as something to re-read on every command.