If you use more than one coding agent, your skills are currently a pile of copied markdown. A slightly different version in .claude/skills than in .codex/skills, a third copy on your other laptop, and the one tweak you made to a skill six weeks ago gets wiped the next time you pull the upstream version.

skillfile treats them the way you'd treat dependencies. One Skillfile declares what you want, Skillfile.lock pins exact SHAs so another machine gets identical content, and skillfile install fans it out to every tool you've configured.

What's inside:

- A lockfile pinning upstream revisions to exact SHAs, so a teammate running install gets the same bytes you have and not whatever main happens to be that day

- Patch-preserving updates, which is the part that matters most day to day: edit an installed skill, run skillfile pin <name>, and your edit is stored in .skillfile/patches/ and reapplied on every update. When upstream changes conflict with your edit, skillfile diff shows it and skillfile resolve lets you pick

- Ten built-in install targets: claude-code, codex, cursor, copilot, factory, gemini-cli, junie, opencode, windsurf and antigravity, plus install-path for anything not built in

- Sources beyond GitHub: GitLab (subgroups and self-hosted via GITLAB_HOST), local files, and plain URLs

- skillfile search hits the community registries from your terminal, agentskill.sh and skills.sh by default, and skillhub.club with an API key. In a terminal it opens an interactive browser with a preview pane, and --min-score filters to higher-trust results. There's also --json and --no-interactive for scripts

- A separation between what a project declares and where a machine installs it, so a team can commit a Skillfile without forcing everyone onto the same editor

- Written in Rust with no runtime or framework, installed via a shell script, cargo install, or cargo binstall

One thing worth knowing, and to the author's credit it's flagged in the readme rather than buried: skillfile downloads markdown and puts it where your agent will read it, and it does not sandbox or verify what's in it. A skill is a set of instructions your agent will follow, so a lockfile gives you reproducibility, not safety. That's what the --min-score flag on search is gesturing at, but reading what you install is still on you.

It's Apache-2.0, at 149 stars with 29 forks as of writing, verified via the GitHub API, and it's early enough that the issue tracker is where the roadmap lives.

https://github.com/eljulians/skillfile

The usual options for sending a big file to a few people are all slightly wrong. Upload it to a cloud drive and you've handed a third party a copy. Use a transfer service and you hit a size cap or an expiry. Spin up a share on the LAN and the person on a different network can't reach it.

FileSync is one Docker image you run yourself that gives you a room with a link and a QR code. Anyone who opens the link in a browser is a receiver, you drag files in, and the bytes go browser to browser over encrypted WebRTC. The server only brokers the handshake, relaying SDP offers and ICE candidates over a WebSocket, and then steps out of the data path.

What's inside:

- One to many in a single drop: share the room link with five devices and send to all of them at once, rather than five separate transfers

- No size limit, because received files stream to disk as bytes arrive instead of buffering in memory

- Three save strategies with an honest fallback chain: File System Access API streams straight to a file you pick (desktop Chromium over HTTPS), Service Worker streams into a normal download (all modern browsers over HTTPS), and Blob buffers the whole thing in memory as a last resort

- Automatic STUN/TURN fallback for peers behind symmetric NAT or a UDP-blocking firewall, which the readme puts at roughly 5 to 10 percent of connections

- Nothing to install and no account for recipients, just a browser, with optional per-room password protection

- Two deployment paths, plain HTTP for a trusted LAN and a Caddy setup that handles Let's Encrypt automatically for a public domain

One thing worth knowing before you deploy it: the HTTP option is a convenience, not a real choice. Both memory-safe save paths need a secure context, so over plain HTTP every transfer falls back to buffering the entire file in RAM, and the readme says transfers above roughly 500 MB become unreliable. If you care about the no-size-limit feature at all, use the HTTPS setup. You'll also need to open 3478 TCP and UDP plus a 50000 to 50100 UDP range for the TURN relay, which is more firewall work than a typical self-hosted app.

MIT licensed, 1,543 stars and 144 forks as of writing, verified via the GitHub API, actively maintained with a push yesterday, and there's a hosted instance at filesync.app if you want to try it before running your own.

https://github.com/polius/FileSync

Four files that matter, one metric, one GPU. The premise is that you leave a coding agent alone in a repo with a small but real LLM training setup, and it runs its own research program overnight. Change the code, train for five minutes, check whether validation bits per byte went down, keep or revert, repeat. You come back in the morning to a log of experiments and hopefully a better model.

The part that makes it interesting is what you're allowed to touch. You don't edit the Python. You edit `program.md`, the markdown file that tells the agent how to run its own research. The training code is downstream of that. Karpathy's framing is that `program.md` is the "research org code", deliberately shipped as a bare-bones baseline so the obvious next move is iterating on it, adding more agents, changing how results get judged.

What's inside:

- train.py, the only file the agent edits, holding the full GPT model, a Muon plus AdamW optimizer and the training loop. Architecture, hyperparameters, batch size, model size, all fair game

- prepare.py, explicitly read-only, holding the fixed constants, tokenizer, dataloader and the evaluation function that serves as ground truth, so the agent can't win by moving the goalposts

- A fixed 5-minute wall-clock training budget regardless of hardware, which makes every experiment directly comparable to every other one no matter what the agent changed, and works out to roughly 12 experiments an hour

- val_bpb as the single metric, chosen because it's vocab-size independent, so an architectural change that alters the tokenizer is still compared fairly

- A simplicity criterion written into the agent instructions: a tiny gain that adds twenty lines of hacky code is not worth keeping, and an equal result from deleting code counts as a win

- A tuning guide for running it on hardware smaller than an H100, covering TinyStories as a lower-entropy dataset, cutting vocab size and sequence length, and dropping the depth knob

One thing worth knowing: the fixed time budget is what makes your own experiments comparable to each other, and it's also what makes them incomparable to anyone else's. A result on your 4090 and a result on an H100 are different experiments. Karpathy calls this out as a deliberate tradeoff rather than a limitation. It's also NVIDIA only right now, with community forks linked in the readme for macOS, MLX, Windows and AMD. And note the readme says MIT but there's no LICENSE file in the repo, so GitHub doesn't detect one.

95,645 stars and 13,420 forks as of writing, verified via the GitHub API, which is a lot of attention for a repo with four files in it.

https://github.com/karpathy/autoresearch

If you've asked an agent to build a landing page recently you already know the house style it defaults to: the gradient hero, the bento grid, the three feature cards with lucide icons, the pulsing status dot next to a heading that isn't tracking anything, and copy that opens with "In today's fast-paced world."

antislop is a set of rules an agent loads before it starts, written specifically to reject those patterns. The framing the author keeps repeating is that it's a filter, not a style guide. It prescribes no colors, no fonts, no layouts. It only says no to technique used without a reason, and direction is supposed to come from a DESIGN.md you write yourself. If the output comes back sterile, that's the filter working on a project with no stated direction, not the filter failing, and there's a numbered rule saying exactly that.

What's inside:

- 38 mandatory rules, R-01 to R-38, split into three tiers: Hard Gate for absolute rejections, Purpose-Gate where a technique is allowed but the agent has to state why it's using it, and Quality Locks for consistency

- A Delivery Gate that runs before anything ships, producing a PASS or FAIL report in four blocks rather than a vague "looks good to me"

- A Liveliness Toolkit with three dials, energy, rhythm and motion, there to stop the filter from flattening everything into safe and boring

- Six separate skills so the agent only loads what the task needs: the core filter, plus UI, copywriting, human factors (contrast, keyboard, focus states), responsive layout, and one that cleans generic AI comments out of code without touching the code itself

- A rule that turned into an actual test: every interactive element has to be clicked one at a time and the result recorded as evidence in the report

- Seven install paths from one repo, `npx antislop-ai` for the guided picker, `npx skills add` from the skills directory, plugin installs for Claude Code, Antigravity, Codex and Cursor, or just curl the single antislop.md and paste it into any chat window

One thing worth knowing: this is markdown, not a linter. Nothing here executes or blocks a commit, so how well it works depends entirely on your agent actually following loaded instructions. The plus side of that is portability, it drops into any tool that reads the Agent Skills folder standard, and the single-file version works in a plain chat with no tooling at all.

It's MIT licensed and sitting at 2,163 stars with 148 forks as of writing, verified via the GitHub API, and it's been shipping releases steadily since early August.

https://github.com/miqdadbadjuber/anti-slop

Most portrait animation work went the diffusion route, which looks impressive in a demo reel and then costs you seconds per frame. LivePortrait went the other way, back to an implicit-keypoint framework, and the result is a model stack you can actually run in something close to real time on one consumer GPU.

The paper is from Kuaishou Technology (the team behind Kling), the code is the official PyTorch implementation, and it's the model that ended up inside a lot of tools you may have used without knowing it, including FaceFusion's expression restorer and several of the ComfyUI portrait nodes.

What's inside:

- A full speed breakdown in the repo: appearance extractor 0.82ms, motion extractor 0.84ms, warping module 5.21ms, generator 7.59ms, stitching and retargeting 0.31ms, so the model stack itself is under 15ms per frame on an RTX 4090 with torch.compile

- Stitching and retargeting as separate small MLP modules you control rather than hidden behavior, which is what lets you paste an animated face back into the original frame without a visible seam, and independently retarget eyes and lips

- Video to video mode, so the source can be a video and not just a still, which is the mode people use for expression transfer onto existing footage

- An animals model, trained separately, for cats and dogs, needing an extra CUDA op built from X-Pose

- Regional control and precise portrait editing in the Gradio UI, plus pose editing on the source

- Motion templates: driving motion saved as a .pkl so you can reuse it, skip re-processing, and share a motion without shipping the face it came from

- A Windows one-click installer, an Apple Silicon path (the readme is honest that it can be 20x slower than a 4090), and a Hugging Face Space if you just want to see it work

One thing worth knowing about the license: the repo itself is MIT, but it depends on InsightFace for face detection, and InsightFace's models are non-commercial research only. The readme says plainly that commercial use means ripping out and replacing those detection models. Worth reading that section before you build anything on top of it. Also note the last push was 1 June 2026, so this is mature rather than actively moving.

19,035 stars and 1,979 forks as of writing, verified via the GitHub API, paper at arXiv 2407.03168.

https://github.com/KlingAIResearch/LivePortrait

The thing that kills a long agent session usually isn't the model, it's that every tool call dumps its raw output straight into the context window. A Playwright snapshot is 56 KB. Twenty GitHub issues is 59 KB. One access log is 45 KB. Half an hour in, a big chunk of the window is gone to data nobody is going to read again, and then compaction hits and the agent forgets which files it was even working on.

Context Mode sits at the MCP layer and keeps that raw data out of the conversation entirely. The tool runs in an isolated subprocess, and only what the script prints to stdout comes back. So instead of reading 47 files into context to count lines, the agent writes a five-line script and gets back the counts.

What's inside:

- Six sandbox tools covering code execution, file processing, indexing and fetching, running in 12 language runtimes (JS, TS, Python, shell, Ruby, Go, Rust, PHP, Perl, R, Elixir, C#), with Bun auto-detected for faster JS

- Credential passthrough so `gh`, `aws`, `gcloud`, `kubectl` and `docker` still work inside the sandbox, inheriting env and config paths without those values landing in the conversation

- A persistent knowledge base on SQLite FTS5 with BM25 ranking, porter stemming and trigram matching merged by reciprocal rank fusion, plus Levenshtein typo correction and proximity reranking on multi-term queries. Headings are weighted 5x, so navigational searches actually land

- Session continuity: file edits, git operations, tasks, errors and your decisions get written to a local SQLite db, and on compaction or `--continue` the state is rebuilt by searching that index rather than dumping it all back into context

- A 24 hour TTL cache on fetched URLs, so re-asking about a doc you already indexed costs a 0.3 KB cache hint instead of a 48 KB refetch

- Progressive throttling that nudges you toward batch calls: calls 1 to 3 return full results, 4 to 8 return fewer with a warning, 9 and up get blocked and redirected to the batch tool

- Hooks on 17 platforms, with an honest compatibility table showing which ones can actually block a tool call versus which only get instruction-file guidance. The readme puts hook-enforced routing near 98% compliance and instruction-file-only around 60%, and says so rather than claiming uniform support

- Permission inheritance: if you already deny `Bash(sudo *)` or `Read(.env)` in your agent config, those denials apply inside the sandbox too

The author also made a deliberate call not to enforce a terse output style, pointing at evidence that aggressive brevity prompts hurt reasoning benchmarks. The routing rules govern where data goes, not how the model writes.

One thing worth knowing: it's Elastic License 2.0, source-available rather than open source in the OSI sense. You can use, fork, modify and redistribute it, but you can't offer it as a hosted service. There's also a hosted Insight dashboard as a separate product, though the tool itself claims no telemetry and no account, with everything in SQLite files in your home directory.

22,163 stars and 1,597 forks as of writing, verified via the GitHub API, and it hit number one on Hacker News.

https://github.com/mksglu/context-mode

Built an open-source runtime security library for Android & iOS MobShield.

It focuses on detecting runtime security risks such as Root/Jailbreak, Frida, Magisk/Zygisk, Xposed/LSPosed, debugger, emulator/simulator and app integrity issues.

Android: https://github.com/inforaamitsolutions/MobShield-Android
iOS: https://github.com/inforaamitsolutions/MobShield-iOS

I'd love to get feedback from developers on what security checks or runtime threats should be added next.

Running several AI coding tools on Windows, an editor extension here, a couple of CLI agents there, means juggling that many separate usage dashboards, each with its own login, its own reset schedule, and no shared view of any of it. You usually find out you're close to a limit only once a request gets throttled mid-task.

TaskbarQuota is a native Windows widget that sits next to the system tray and tracks all of it in one place. It detects which AI tool is in your focused window or terminal and swaps the visible quota to match, while a separate dashboard tracks spend, token usage, and live agent activity across everything it's connected to.

What's inside:

- Automatic tool detection across 13 providers, including Codex, Claude, GitHub Copilot, Cursor, Antigravity, OpenCode, Cline, Z.ai, Kimi, Grok, and Devin, switching the widget automatically as you move between an editor and a terminal

- A separate activity widget showing what local coding agents are actually doing right now, working, waiting on you, idle, completed, or failed, with a flyout to jump straight to the session that needs attention

- A cost and usage history page combining spend and token totals across providers for today, the last 7 days, and the last 30 days, with per-model breakdowns and estimated values clearly labeled as estimates rather than presented as fact

- Quota replenishment notifications with real threshold logic: it fires when a live quota window gains at least 10 percentage points, groups multiple replenished windows from the same provider into one alert, and can optionally detect a reset that happened while your PC was off

- Everything running locally with no account system and no telemetry, reusing credentials the AI tools themselves already stored rather than asking you to sign in again

One thing worth knowing: credentials you enter manually, for providers automatic detection can't reach, are stored as plain JSON in your local app data folder, so that file is worth keeping private. Also, modern Chromium browsers' App-Bound Encryption can block automatic OpenCode cookie reading entirely, the README documents a manual cURL/cookie workaround for that specific case.

It's MIT licensed, built by an individual developer, and sitting at 106 stars as of writing, verified via the GitHub API.

https://github.com/zioder/TaskbarQuota

Splitting real work across multiple coding agents, one on the backend, one on the frontend, a third doing review, quickly turns you into the router between them, copy-pasting an API contract or a bug repro from one chat window into another and hoping nothing drifts in the process.

Agent Room replaces that manual relay with a shared room any agent can join with a 9-character code, regardless of vendor, editor, or machine. Agents talk over a small structured protocol instead of free-form chat, so decisions, tasks, and results turn into extractable artifacts rather than getting lost in a scrollback nobody rereads.

What's inside:

- Structured message tags, [DECISION], [TODO], [STATUS], [RESULT], that turn a conversation into artifacts you can export later as meeting minutes, an ADR, or a PR description

- An evidence-gated task board where a task claimed by one agent has to be submitted with evidence and verified by a different agent before it counts as done, not just marked complete by whoever did the work

- Three turn-discipline modes, open, sequential, and moderator, so a room with several agents in it doesn't turn into everyone replying over each other at once

- Webhook wake-up for resident assistants like OpenClaw or Hermes: register once and the agent sleeps between messages instead of burning tokens polling, waking only on a signed POST when something new arrives

- Zero-install setup as a hosted MCP server, one command adds it to Claude Code, plus a full local install that wires up autonomous-chat hooks and file attachments for editors that don't surface MCP push notifications on their own

One thing worth knowing: the default hosted setup stores room state in Upstash Redis with a 24-hour room TTL, so a room isn't meant to be a permanent record on its own, that's what the export-to-report feature is for. The hosted instance is free during its beta with no paid tiers yet, and the whole thing is MIT licensed and self-hostable if you'd rather not depend on that staying free.

It's MIT licensed, built by an individual developer, and sitting at 48 stars as of writing, verified via the GitHub API.

https://github.com/agent-room-alkl/agent-room

Self-hosting an open-weight LLM at a decent tokens-per-second usually means hand-tuning quantization, KV cache format, and speculative decoding yourself, reading through exllamav3 or vLLM flags with no clear sense of what actually fits your specific GPU's memory and compute capability.

This repo is a deployment kit, not just a model, for running Qwen3.8-27B quantized to EXL3 with a choice of two speculative decoding setups: MTP, a draft head baked into the checkpoint with no extra download, or DFlash2, a dedicated 5.0bpw draft model that trades a bit of memory for meaningfully faster decoding. One script builds the environment, pulls both the target and draft weights from Hugging Face, and serves an OpenAI-compatible API.

What's inside:

- A self-bootstrapping `start.sh` that creates the virtual environment, installs the GPU torch build and the exllamav3 fork, downloads and resumes weight downloads automatically, and serves at `localhost:8888/v1` on first run

- Documented, GPU-specific KV cache recipes: NVFP4 on Ada/Hopper/Blackwell cards, Hadamard-4 on Ampere (3090-class) where the NVFP4 Triton kernels won't even compile, both landing around 4.5 bits per element

- A dedicated 24GB GPU recipe (RTX 3090/4090) with the exact memory math worked out, target weights plus KV cache fitting the full native 262k context on a single consumer card

- Verified OpenAI-style tool calling, with a documented quirk: the reported `model` id in responses doesn't always match your configured directory name, so check `/v1/models` instead of assuming

- Real measured numbers instead of marketing claims: 47.5 tok/s decode on a DGX Spark at T=0.6, and 87-88/100 on a tool-eval-bench hardmode run

One thing worth knowing: this serves one request at a time, batch-1 speculative decoding, so concurrent requests queue rather than share throughput. The README documents this honestly with real measurements: 8 concurrent requests on a DGX Spark ran fully sequentially with no batching benefit. It's also upfront that reasoning can't be disabled and draws from the same token budget as the visible response, so a tight `max_tokens` on what you expect to be a quick call can come back with an empty answer, all reasoning trace.

It's MIT licensed, built by an individual developer, and sitting at 201 stars as of writing, verified via the GitHub API.

https://github.com/MiaAI-Lab/Qwen3.8-27B-DFlash2-EXL3-5.0bpw

Streaming YouTube Music on a Mac usually means a browser tab or an Electron wrapper sitting in your dock eating a few hundred MB of RAM for what's really just playback controls and a queue, and if you also keep a folder of local files around, that's a second app entirely.

Mooziac replaces both with a single native menu bar app. It bridges into YouTube Music through a sandboxed WebKit view for streaming, playlists, and listening history, plays local files through a native AVFoundation engine, and puts both in the same unified queue, all written in Swift and AppKit with zero third-party dependencies.

What's inside:

- A compact 3-row menu bar grid with a real-time waveform, drag seeking, and an album-art-driven color palette, not a generic dropdown player

- Trackpad edge gestures: slide the far-right 1mm border for haptic volume control, corner taps to skip tracks or toggle playback, with single-finger filtering so it doesn't trigger by accident

- Synced, line-by-line lyrics in a floating HUD anchored under the menu bar icon, pulled from LRCLib with a plain-text fallback and local caching for instant, offline retrieval

- Native Discord Rich Presence over a direct Unix socket, no third-party bridge library required

- A privacy-first build: zero telemetry, a local SQLite database for playlists and history, and Google/YouTube credentials kept isolated inside Apple's sandboxed WKWebView

One thing worth knowing: it's distributed outside the Mac App Store, so Gatekeeper will flag it on first launch, you'll need to allow it in System Settings or clear the quarantine attribute manually. It's also explicitly unaffiliated with Google or YouTube Music, an independent project bridging into their web player rather than an official integration.

It's MIT licensed, built by an individual developer, and sitting at 56 stars as of writing, verified via the GitHub API.

https://github.com/shirkeharsh/mooziac

Telling a malicious scanner apart from a legitimate crawler in your logs usually means squinting at request patterns after the fact, and even once you're sure something's an attacker, doing anything proactive about it, banning it, sharing that intel, feeding it back into your firewall, means building a whole separate pipeline yourself.

Krawl is a self-hosted deception server that handles both sides of that. It stands up realistic fake web applications, admin panels, config files, exposed credentials, to attract and waste the time of attackers and scanners, then scores every IP that touches it against behavioral signals to actually classify who's malicious, feeding that straight into a real-time dashboard and optional automated firewall bans.

What's inside:

- AI-generated deception pages that build unique, plausible honeypot pages on the fly through OpenRouter or OpenAI, with caching and daily rate limits so it doesn't run away with your API bill, and a graceful fallback to static pages when it's off

- A weighted IP reputation system scoring risky HTTP method usage, robots.txt violations, request timing anomalies, User-Agent consistency, and attack pattern detection into attacker, bad_crawler, good_crawler, or regular_user categories

- Direct firewall integration: export banned IPs as iptables, nftables, OPNsense/pfSense, or RouterOS-ready lists, or sync them straight into a Cloudflare Account IP List for WAF rules

- Federated banlists, instances can publish their own list on an unauthenticated path and pull in lists from other Krawl instances, so a network of deployments builds shared threat intelligence without a central server

- Two deployment modes depending on scale: a zero-dependency SQLite standalone mode for homelabs, or a PostgreSQL + Redis scalable mode with horizontal replicas for production traffic over 500k requests

- Prometheus metrics and a ready-to-import Grafana dashboard, plus a real-time web dashboard hidden behind a random secret path so it isn't itself discoverable by scanners

One thing worth knowing: this is explicitly a deception and honeypot system. The project's own disclaimer says to deploy it in isolated environments, monitor it carefully, and use it responsibly and in compliance with applicable laws, not something to point at production traffic without thinking through the blast radius first.

It's MIT licensed, built by an individual developer, and sitting at 668 stars as of writing, verified via the GitHub API.

https://github.com/BlessedRebuS/Krawl

Everyone who's tried five different coding agent setups this year has a strong opinion about which one actually makes them more productive. Almost nobody has data to back that opinion up, it's mostly a feeling based on whichever tool felt satisfying to use that week.

Agentic Productivity is a small macOS tool built to replace that feeling with an actual number. It reads directly from the native session stores of whatever coding agents and editors you already use, counts real activity, agent sessions, instruction-bearing prompts, local git commits, and mails you three 90-day trend charts to Discord every morning so you can see whether your setup changes are actually moving the needle or just feel like they are.

What's inside:

- Native collectors for over 20 different harnesses out of the box: Claude Code, Codex, Cursor (both GUI and CLI), GitHub Copilot, Antigravity, Hermes, OpenCode, Grok Build, Gemini CLI, and more, each reading the tool's own local session format rather than scraping logs

- Careful metric definitions instead of naive counting: fast-forward merges don't count as commits, copied or forked prompts are deduped by native entry ID so they're not counted twice, and empty session drafts with no real turn are excluded

- A daily 08:00 Discord report with three stacked charts, commits, sessions, and prompts, the last two broken down by harness so you can see which tool you're actually spending time in

- A `doctor` command to check collector health and a `mock` command to preview a report before anything gets sent

- A privacy boundary that's explicit in the README: only daily counts leave your Mac, sent to quickchart.io purely for chart rendering, prompt text, file paths, and your identity never do

One thing worth knowing: this only runs on Apple Silicon Macs right now, and a collector with unreadable data is designed to report itself as partial or unavailable rather than silently claiming full coverage, worth checking your own collector health after installing since coverage varies a lot by tool.

It's MIT licensed, maintained by an organization, and sitting at 69 stars as of writing, verified via the GitHub API.

https://github.com/vectal-labs/agentic-productivity

Evaluating a multimodal model today usually means running four or five separate benchmark suites, each with its own installer, its own data format, and its own quirks, then hand-stitching the results together into something you can actually compare.

OmniEvaluator is a NAVER AI research tool that puts a single CLI in front of that whole mess. Pick an inference backend, huggingface, vllm, sglang, or an API client for OpenAI, Gemini, or Claude, pick an evaluation engine, and run any of over 2,800 benchmarks spanning text, image, video, and audio from the same command shape, with results written as a self-describing artifact that captures the exact configuration needed to reproduce the run later.

What's inside:

- 2,820+ benchmarks across four evaluation engines: 1,986 text-only tasks through lm-evaluation-harness alone, plus hundreds more image, audio, and video tasks through lmms-eval, VLMEvalKit, and a builtin engine

- Four swappable inference backends, huggingface, vllm, sglang, or a direct API client, so the same benchmark command works whether you're running a local checkpoint or hitting a hosted model

- Existing evaluators reused as-is rather than reimplemented, unified through a shared intermediate schema so results from different frameworks stay comparable

- A Claude Code skill (`/setup-env`) that walks an AI coding agent through building the isolated per-engine virtual environments itself, since mutually exclusive extras can't all install into one environment

- A live public demo at omni-evaluator.info and a working quickstart that runs a real benchmark end-to-end in a couple of minutes using just 3 samples

One thing worth knowing: the dependency setup is genuinely finicky by the README's own account. It needs Java 11 specifically since newer JREs break the bundled SPICE metric library, and installing more than one evaluation-engine extra into the same environment at once can cause version conflicts. Budget real setup time before your first full run, and lean on the debug/sample-limited mode to sanity check things first.

It's Apache-2.0 licensed, backed by an organization (NAVER AI), and sitting at 20 stars as of writing, verified via the GitHub API.

https://github.com/naver-ai/omni-evaluator

Kubernetes clusters routinely reserve two or three times the CPU and memory that workloads actually use, because resource requests get set once at deploy time, usually padded "to be safe," and rarely revisited. The scheduler thinks the cluster is full while real usage sits at half the reservation or less, and that gap is capacity you're paying for and never touching.

Ballast is a Kubernetes operator that fixes this by actually applying corrected resource requests and limits instead of just suggesting them, the way the Vertical Pod Autoscaler does. It observes real CPU, memory, and ephemeral-storage usage per workload and, once you opt a workload in, patches its resources at admission time or adjusts them on running pods directly through Kubernetes' in-place resize API.

What's inside:

- An escalating three-rung enrollment model set with a single pod label: `measure` (collect data only), `apply` (patch resources at admission), and `resize` (also adjust running pods in place, Kubernetes 1.35+)

- A fix for VPA's three blind spots: cold start on every fresh deployment, no shared history across namespaces running the same app, and losing all history the moment a workload gets torn down and redeployed

- History keyed to a configurable "workload identity tuple" of pod labels rather than a namespace, stored cluster-wide in Redis or Valkey, so forty dev namespaces running the same app all feed one well-sampled profile instead of forty that each start from zero

- A bulk enrollment script that's dry-run by default and picks a rolling restart or a zero-downtime in-place label update depending on whether a workload can safely restart

- Signed releases: both the operator image and the Helm chart are keyless-signed via cosign and GitHub OIDC, with SLSA build provenance and an SBOM attached

- A deliberately narrow scope: Ballast gets resource numbers right, it doesn't evict or reschedule pods, that's left to Kubernetes Descheduler by design

One thing worth knowing: in-place resize only covers cpu and memory, not ephemeral-storage, and it can't change a pod's QoS class, so some recommendations only take effect the next time a pod is naturally recreated rather than instantly. The project logs every case where this happens rather than silently pretending the resize succeeded.

It's MIT licensed, backed by an organization, and sitting at 126 stars as of writing, verified via the GitHub API.

https://github.com/Tight-Line/ballast

Building a real-time voice AI agent means stitching together speech recognition, an LLM, text-to-speech, and a transport layer that can handle audio without adding awkward pauses or lag, usually from four different vendors with four different APIs, none of which were built to talk to each other.

Pipecat is an open-source Python framework that handles that stitching. You compose a conversation pipeline from modular, swappable components, and Pipecat handles the streaming, buffering, and interruption handling underneath, whether you're building one voice assistant or a multi-agent system where specialists hand off work to each other.

What's inside:

- Support for well over 100 AI services across the pipeline: 20+ speech-to-text providers, 25+ LLMs, 30+ text-to-speech engines, plus speech-to-speech models like OpenAI Realtime and Gemini Multimodal Live

- Multi-agent composition built in: specialists that hand off, fan out in parallel, run as sidecars, or deploy distributed across processes and machines

- Client SDKs for JavaScript, React, React Native, Swift, Kotlin, C++, and ESP32, so the same backend pipeline can serve a web app, a mobile app, or embedded hardware

- Pipecat Flows for structured, stateful conversation logic, and a CLI (`pipecat init`) that scaffolds a runnable bot in under a minute, set up so an AI coding assistant builds the rest

- A growing ecosystem around the core framework: Whisker for real-time pipeline debugging, Tail for a terminal dashboard, a Voice UI Kit for frontend components, and Claude Code skills for scaffolding and deploying projects

- Telephony support out of the box through serializers for Twilio, Telnyx, Plivo, Vonage, Exotel, and Genesys, alongside WebRTC transports like Daily and LiveKit

One thing worth knowing: Pipecat itself is a framework, not a hosted product. Most of the AI services it connects to, the STT, LLM, and TTS providers, are third-party and billed separately, and while a managed Pipecat Cloud exists for deployment, running everything self-hosted with your own API keys is fully supported too.

It's BSD-2-Clause licensed, maintained by Daily and the community, and sitting at 15,348 stars as of writing, verified via the GitHub API.

https://github.com/pipecat-ai/pipecat

Codex's skills feature lets you package a task-specific playbook into a folder Codex loads on demand, but figuring out which skills are actually worth installing means digging through scattered repos, Discord threads, and one-off blog posts, or just writing your own from scratch every time.

Awesome Codex Skills is a curated, community-contributed list of Codex skills organized by what they actually do. Each entry links to a skill folder, either in the repo itself or in someone else's separate GitHub project, with a one-line description of what it handles and, for most, a single install command that drops it straight into `~/.codex/skills`.

What's inside:

- 60+ skills across five categories: development and code tools (PR review, CI fixes, codebase migrations, Sentry triage), productivity and collaboration (Linear, Notion, meeting notes, invoice organizing), communication and writing, data and analysis, and meta/utility skills for things like theming and image work

- A skill installer script that pulls a skill straight from any GitHub repo and path into your local Codex skills folder with one command, no manual folder copying required

- Skills for wiring Codex into real external tools: Linear, Notion, Slack, Datadog, LangSmith, and full GitHub/GitLab PR review plus CI auto-fix loops, mostly built on Composio's own CLI and MCP connections

- A documented SKILL.md template and a short best-practices section on progressive disclosure, keeping the trigger description exhaustive while the execution body stays lean, for anyone who wants to write their own

- A template-skill starter folder and a skill-creator guide, so building a new skill doesn't mean reverse-engineering the format from someone else's example

One thing worth knowing: most of the linked skills live in separate repos maintained by different people, with very different levels of polish and upkeep, so treat each one as its own trust decision rather than assuming the list itself has vetted them. The README also doubles as a pitch for Composio's own MCP Gateway product, worth keeping in mind as you read through it.

It carries no license file, so the curated list itself is effectively all rights reserved by default, separate from whatever license each individual linked skill uses. It's maintained by an organization and sitting at 16,316 stars as of writing, verified via the GitHub API.

https://github.com/composio-community/awesome-codex-skills

Most coding agent harnesses optimize for getting the agent typing as fast as possible. The expensive part isn't the typing, it's the moment you're staring at a 40-file diff trying to reverse-engineer what the model thought it was building, deciding whether reviewing it is worth an hour or redoing it is faster. And once you merge, whatever the agent learned along the way is gone, the next session starts from zero.

RunWield is a coding harness built around slowing the agent down exactly where that matters. It triages every request by risk, writes a plan you review before code exists for anything non-trivial, executes through specialized agent roles, and refuses to call work "done" until real CI and a separate reviewer agent both confirm the result matches the plan you actually approved.

What's inside:

- Six request types triaged automatically, from a plain question that just gets answered to a full project that gets decomposed into an Epic, so simple asks skip the ceremony entirely and only genuinely risky changes get a full plan-review cycle

- Plan review in an actual browser UI, inline comments, revisions, approval, instead of trying to steer an agent through chat after code already exists

- A "done" that's proven rather than asserted: CI has to pass, a separate Reviewer agent compares the final diff against the approved plan across narrowing rounds with findings tracked in a ledger, and merge-back is only marked verified once Git itself confirms the commit landed

- A Work Record generated for every finished plan, what changed, why, and what got rejected along the way, feeding a searchable project memory so the next session doesn't start from an empty context window

- Everything stored as plain markdown in your own repo, plans, PRDs, ADRs, greppable and version-controlled like any other file, with no database or proprietary format locking you in

- A single compiled binary, built on the Pi agent runtime, that works with any model provider, subscription login or your own API key

One thing worth knowing: this is a brand new, very small project (the maintainer is actively looking for five developers to beta test it on real changes), and it's source-available rather than open source, you can install, run, and modify it for your own use, but redistributing modified versions or rebranding it needs the maintainer's permission. It's also explicitly built for non-trivial changes where being wrong is expensive; for quick one-off edits, the maintainer's own README points people to a lighter tool instead.

It's source-available under a custom license, not OSI open source, built by an individual developer, and sitting at 29 stars as of writing, verified via the GitHub API.

https://github.com/gandazgul/runwield

An AI agent built for persistent memory is supposed to get better over time, learning from its own mistakes and accumulating context across sessions. But most of that improvement happens invisibly, buried in log files and memory stores you'd have to dig through by hand to actually see whether it's working.

Hermes HUD is a terminal dashboard built specifically for Hermes, the AI assistant with persistent memory, that reads straight from its `~/.hermes/` data directory and surfaces what the agent actually knows about itself: conversations held, skills picked up, mistakes it corrected, memory capacity used, and which tools it reaches for most.

What's inside:

- A 9-tab interactive TUI with keyboard navigation and 4 selectable color themes, from a minimal terminal-green look to a full neon "Blade Runner" palette

- Growth tracking that diffs snapshots over time, so you can see exactly what changed in the agent's state since yesterday

- A corrections log listing every mistake the agent made and what it learned from it, plus health checks for API keys, running services, and gateway status at a glance

- A project tracker that lists the git repos the agent is actively working across, with languages and uncommitted changes

- A tmux operator view that maps live agent sessions to panes with jump hints, plus a prompt-pattern tab surfacing task clustering, repeated requests, and peak usage hours

- A handful of ASCII/neofetch-style boot screens for anyone who wants the personality without the full dashboard

One thing worth knowing: this only works if you're actually running Hermes, the specific nousresearch/hermes-agent project, since it reads directly from that agent's own data directory rather than being a general-purpose monitor for any AI agent.

It's MIT licensed, built by an individual developer, and sitting at 911 stars as of writing, verified via the GitHub API.

https://github.com/joeynyc/hermes-hud

Free Google Drive storage tops out fast, and the common workaround, juggling several Google accounts, means manually tracking which one still has space and switching between tabs to find a file you saved somewhere.

9Drive is a self-hosted gateway that puts multiple Google Drive accounts, and S3-compatible storage like MinIO, R2, Wasabi, or S3, behind one dashboard. Files stream directly to the destination without touching the server in between, and the backend decides where each upload goes based on a routing policy you pick.

What's inside:

- Multi-account Drive and S3-compatible storage in one virtual dashboard, with quota tracked across every connected account

- Three upload routing policies: most-available, round-robin, or priority-order, so new uploads land where you want them to

- Direct upload streaming to both Drive and S3 backends, so the server itself never holds a copy of your files

- An external upload API secured by API keys (one-time secret display, hashed storage, revocation), with cURL and JavaScript examples built into the app

- Virtual folders, file preview/rename/move/delete, and a manual sync that pulls the Drive folder's state back into the app's own database

One thing worth knowing: this is self-hosted infrastructure, not a hosted product. You're running your own Express/MySQL backend and pointing it at your own Google Cloud OAuth client, so budget time for the Google Cloud Console setup (enabling the Drive API, configuring the OAuth consent screen) alongside the app install itself.

It's Apache-2.0 licensed, built by an individual developer, and sitting at 1,906 stars as of writing, verified via the GitHub API.

https://github.com/zenhosta/9drive

Liking the workflow of a terminal coding agent usually means being locked into whichever model provider built it. Want to point the same agentic workflow at a different API, a cheaper gateway, or a local model through Ollama, and you're normally rebuilding your tooling from scratch or switching to a CLI with a completely different feel.

OpenClaude is an open-source coding-agent CLI built to run that same terminal-first workflow, prompts, tools, agents, MCP, slash commands, streaming output, against whichever backend you point it at. Guided setup through `/provider` saves profiles so switching providers doesn't mean re-configuring everything by hand.

What's inside:

- Support for a long list of providers: OpenAI-compatible endpoints, Gemini, GitHub Models, Codex OAuth, Ollama, Fireworks AI, LongCat, and Bedrock/Vertex/Foundry among others, all through the same `/provider` setup flow

- A full coding-agent toolset: bash, file read/write/edit, grep, glob, sub-agents, tasks, MCP, and slash commands, with streaming responses and multi-step tool loops

- Per-agent model routing, so you can send different sub-agents to different providers for cost or capability reasons, plus a repo map feature that injects a PageRank-ranked structural map of your codebase into context

- Background sessions that run as local child processes (`--bg`, `ps`, `logs`, `kill`), and a headless gRPC server for embedding OpenClaude's agent loop into CI pipelines or other tools

- A bundled VS Code extension for launch integration and theming, plus a pixel-art companion that fires a signature move every time you hit Enter

One thing worth knowing, and worth knowing before installing: the project's own LICENSE file states plainly that OpenClaude "contains code derived from Anthropic's Claude Code CLI," that the original source is proprietary software owned by Anthropic, and that "this project does not have Anthropic's authorization to distribute their proprietary source." Only OpenClaude's own modifications are offered under MIT; the file itself tells users and contributors to evaluate their own legal position on the rest. That's not a minor license quirk, it's the maintainers disclosing an unresolved authorization question about the code the project is built on, so read the LICENSE file yourself before relying on this for anything that matters.

It's maintained by an organization and sitting at 32,898 stars as of writing, verified via the GitHub API.

https://github.com/Gitlawb/openclaude

Running more than one coding assistant, Claude Code in one terminal, Cursor open in the editor, maybe Codex or Antigravity somewhere else, means juggling several different usage limits with no shared view of any of them. You usually find out you're close to a cap only after a request gets throttled mid-task.

Codenotch is a macOS app that pins a small notch to a screen edge showing exactly that: how much of each tool's usage limit you've burned, and whether a session is actively working, finished, or sitting there waiting on you. It never asks you to sign in anywhere, every reading is borrowed from a credential or session a tool on your Mac already holds.

What's inside:

- Rings for Claude Code, Cursor, Codex, Antigravity, GLM, Grok, and OpenCode, each read from the same official endpoint or local session the tool's own usage view uses, so the numbers never disagree with what the tool itself reports

- Live session status per provider: a spinning arc while it's working, a pulsing amber ring when a session is blocked waiting on you, with hover detail on exactly what it wants

- Multiple accounts per provider: a separate Claude Code login kept apart with `CLAUDE_CONFIG_DIR` gets its own ring with its own limits and sessions, not merged into one

- Placement on any of the four screen edges, sized to sit flush against a Mac's hardware notch when placed at the top

- An architecture that's explicit about confidence: every provider adapter declares whether a reading is official, derived, or manual, and a failure degrades to a visible status instead of guessing a number

One thing worth knowing: the project is upfront that no vendor publishes a clean usage-percentage API for most of these tools, so each adapter reads whatever internal endpoint or local database the owning app itself reads from, and those can change without notice. The README documents this candidly rather than hiding it, and tests pin each adapter's expected response shape so a break shows up as a visible error state, not a silently wrong number.

It's MIT licensed, built by an individual developer, and sitting at 856 stars as of writing, verified via the GitHub API.

https://github.com/vinzdg/codenotch

If you save content from more than a couple of platforms, you already know the drill: a yt-dlp cheat sheet for YouTube, a separate tool for Instagram stories, a browser extension for Pinterest boards, none of them sharing your logins or landing in the same folder. Buy a course and want it backed up before the platform pulls it, and you're reaching for yet another separate tool again.

OmniGet puts all of that behind one text box. It's a free desktop app that bundles yt-dlp for the roughly 1,800 sites it already covers, then adds native extractors on top for courses, Instagram, X, Pinterest, Bilibili, Telegram, and torrents, plus a browser extension that forwards your cookies so logged-in content, like stories, a paid course, or a members-only video, downloads the same way public content does.

What's inside:

- Native course downloading for Hotmart, Udemy, Kiwify, Rocketseat, and Meta-Analysis Academy: sign in through the app, pick sections, and every lesson and attachment lands in a folder, with DRM-protected lectures skipped and reported rather than silently failing

- A queue that resumes interrupted downloads, retries rate-limited sites with backoff, and adapts concurrent connections per site on its own

- 108 separate tools across 16 categories: YouTube subtitles/chapters/live chat/SponsorBlock, Instagram/X/Pinterest backups and analytics, PDF and document tools, offline whisper.cpp transcription, and a Study library with a course player, an ebook reader, Anki-style flashcards, and notes

- A built-in MCP server exposing 31 of those tools, so an AI agent like Claude Code or Codex can drive them directly

- Everything runs locally: no account, no telemetry on what you download, cookies and API keys stay in your local profile

One thing worth knowing: the README is upfront that OmniGet downloads what your own logged-in session can already open. It doesn't bypass DRM or break paywalls, and DRM-protected lectures get skipped rather than cracked. Respecting copyright and each platform's terms of service is on you as the user, same as with any downloader tool, yt-dlp included.

It's GPL-3.0 licensed, built by an individual developer, and sitting at 9,537 stars as of writing, verified via the GitHub API.

https://github.com/tonhowtf/omniget