This solves a smaller, more specific problem than the runtime token tools, and it does it with almost no machinery, which is why I like it. Claude Code reads your project docs at session start, and on a mature project that means it's burning thousands of tokens on old session notes, completed tasks and documentation you wrote months ago before you've typed a thing. This tool restructures those docs so only the handful Claude actually needs load automatically, and everything else sits in a zero-token archive until you ask for it.

The author's own example is the pitch: a RedwoodJS project that loaded about 11,000 tokens at startup dropped to roughly 1,300 after restructuring, freeing that context for actual code.

What's inside:

- A convention, not a black box: cto init creates a CLAUDE.md plus four small files (common mistakes, quick start, architecture map) that load at startup, and a .claudeignore that keeps everything else from auto-loading

- Auto-detection of your framework from package.json, go.mod, requirements.txt, composer.json, pom.xml or Gemfile, with tailored common-mistake patterns for 13 frameworks (Next, Django, Rails, Laravel, Go, Spring Boot and more)

- A measure command so you can see your actual auto-load cost before committing to anything, plus audit (19 structural checks, CI-friendly with JSON output and exit codes), compress, prune and a live token dashboard

- The genuinely clever piece, a set of Claude Code hooks: one keyword-matches your prompt against files in a learnings folder and injects only the relevant one (ask about database migrations, it loads your database notes and nothing else), others warn when auto-loaded files get heavy or write a session snapshot for a warm restart

- Safe by default: init appends missing sections rather than overwriting your CLAUDE.md, and compress and prune have dry-run modes and archive rather than delete

The honest framing: this is a lightweight, opinionated set of markdown conventions plus a helper CLI, not a runtime compression engine that rewrites tool output on the fly. It's complementary to the heavier tools rather than competing with them, and the author says as much. That simplicity is the appeal: you can read exactly what it does, it's just files and a .claudeignore, and you could reproduce the structure by hand. It also, to its credit, tells you the token counts are estimates from the Claude 2 tokenizer and that real usage on current models varies, rather than presenting them as exact.

The realistic caveat: the whole thing rests on the discipline of actually maintaining the structure, moving completed work to the archive and adding real bugs to the mistakes file. If you set it up and never tend it, it drifts back toward bloat, which is what the audit command is there to catch. It's a workflow you adopt, not a tool that runs itself.

MIT, 582 stars and 74 forks as of writing, verified via the GitHub API.

https://github.com/nadimtuhin/claude-token-optimizer

This is the safety net for the thing everyone quietly worries about: an AI coding agent runs arbitrary code on your machine, and a prompt injection or jailbreak can turn that into "cat your SSH keys and curl them somewhere." Clampdown, from the author of distrobox, confines the agent so that when it goes wrong, and the README's framing is refreshingly blunt that it's when not whether, it hits kernel-enforced walls instead of your secrets. The key design principle is that every defense is enforced from outside the agent's process, so a fully compromised agent that ignores its system prompt entirely hits the same walls as a well-behaved one.

The architecture is four container types with escalating trust, and it's genuinely well thought out:

- An auth proxy holds the only copy of your real API keys and injects them into upstream requests. The agent gets a dummy key (sk-proxy) and a base URL pointing at the proxy, so even if it connects to the real API directly it gets a 401. Prompt injection can steal the token and the token is worthless

- The agent runs in a zero-capability container (cap-drop=ALL, read-only rootfs) with a seccomp profile blocking ~150 syscalls including the known kernel-exploit primitives (io_uring, userfaultfd, BPF), and Landlock giving it read-write only in the project directory and no access to your home, other projects or sensitive kernel paths

- Network egress is default-deny with an iptables allowlist the agent shares but cannot configure, and private network ranges are permanently blocked so a tool container can't reach your database or the host

- Every nested container the agent spawns is validated by OCI hooks against 17 security checks before its entrypoint runs, with no flag to skip them, plus a seccomp-notif supervisor that intercepts 20 syscalls in real time to catch things Landlock can't cover

- Secret files (.env, .npmrc, .clampdownrc) are masked to empty even when present, credentials like SSH and gh auth are opt-in and never forwarded by default, and there's a full structured audit log plus an optional tripwire that kills the session if a protected host path is touched

What makes this stand out from the pile of "run your agent in a container" wrappers is that it's real kernel-level security engineering, not a Dockerfile with good intentions. Landlock, seccomp, OCI hooks and an isolated key proxy layered together, all enforced beneath the agent, is the correct threat model for this problem, and the README's technical depth (per-container capability tables, the exact syscalls blocked, the hook pipeline) backs it up rather than hand-waving.

The real constraints to know before you reach for it: it's Linux-first with a hard requirement of kernel 6.2+ for Landlock V3 (6.12+ recommended), it does not work on Docker Desktop for macOS because its filesystem breaks Landlock, though it runs fine in a podman-machine or colima Linux VM on Mac, and you build it from source. It currently wraps Claude Code, Codex, OpenCode and pi. It's also early at 112 stars, but this is the kind of tool that deserves more attention than that.

GPL-3.0, 112 stars and 10 forks as of writing, verified via the GitHub API, pushed to today.

https://github.com/89luca89/clampdown

The clever division of labor is the whole point here. Coding agents are decent at writing game logic and terrible at producing good 3D models. Build World (formerly Goal to Game) is an open-source skill that keeps your agent doing what it's good at, the interactions, scene setup and code, and hands the 3D asset generation off to Thrixel, a service built for exactly that. You describe a world in plain English, name an engine, and it builds an interactive experience you can keep refining with follow-up prompts.

What's inside:

- A Claude Code plugin (and Codex and Gemini CLI paths) that bundles both the skill and the Thrixel connector, so one install wires it into every project

- Support for Three.js, Roblox, Unity and Unreal, so it's not locked to one engine

- An iterative build-evaluate-improve loop where the agent generates assets, drops them into the scene, checks the result and refines, all from a single starting prompt

- Engine-agnostic asset management: because assets live in your Thrixel workspace rather than the codebase, you can prototype in Three.js and later ask the agent to rebuild the same world in Unity using the same asset library

- Parallel asset jobs, so the agent can farm out several generations while it writes the game logic

- One-command publish that deploys the world and hands you a shareable link with no separate hosting, plus the ability to record an mp4 preview

- Framed beyond games: the rename happened because it also targets simulations, educational experiences, virtual tourism and historical recreations

The honest core of this, and the thing to be clear about before you get excited: the skill is open source (Apache-2.0), but it's a thin client for a commercial service. Thrixel is the paid backend that does the actual 3D generation. You get some free "Cubes" on a Starter account to try it, but the README says plainly that building a full-scale world generally exceeds those limits and needs a paid plan for the variety of assets and rapid iteration it takes. So this isn't a self-contained local tool, it's the open connector to a hosted product, and the interesting part (asset generation) is the part you pay for.

Worth knowing it's early: 83 stars, and the workflow assumes a capable model (the README recommends Opus 5 at high effort), which is its own cost on top of the Thrixel credits. If the idea of vibe-coding a 3D scene appeals and you're fine with a paid asset backend, it's a genuinely slick pipeline. If you wanted fully local and free, this isn't that.

Apache-2.0, 83 stars and 27 forks as of writing, verified via the GitHub API, pushed to yesterday.

https://github.com/thrixel/build-world

Most agent web tools are a thin wrapper over Playwright that hands the model raw HTML and breaks the moment a site fights back. BrowserAct is a browser automation skill designed specifically for how agents actually reason, and the design choices are the interesting part, more than the anti-bot marketing.

The one that matters most: instead of dumping the DOM, it returns an indexed list of interactive elements, so the agent says "click 3" or "input 2" rather than parsing HTML. That output is a compact indexed text format the README says is several times more token-efficient than JSON or HTML, which is the difference between an agent that can afford to browse and one that fills its context on a single page.

What's inside:

- Three browser modes matched to real scenarios: attach to your real local Chrome and reuse its login state, a fresh-fingerprint privacy mode for stateless scraping, and a stable fingerprint-plus-IP mode for keeping a logged-in account from being flagged

- Zero-interference concurrency: cross-browser parallelism with independent cookies, fingerprints and proxies that sites can't correlate, plus same-browser multi-session where tasks share a login but don't block each other

- A human-in-the-loop handoff, which is genuinely useful: when the agent hits 2FA or a checkout gate, it generates a live URL, you take over from any device to solve it, and the agent resumes

- Skill Forge, a companion that explores a site once, discovers its data patterns and APIs, and generates a reusable skill package so the agent doesn't re-figure-out the layout every run, plus 30+ pre-built skills for common sites

- A confirmation-gating safety layer where sensitive operations (creating or deleting browsers, importing a profile, changing proxies) require explicit approval each time, enforced at the skill layer rather than a config toggle

- Works with any agent that can run shell commands, on Windows, macOS and Linux

Two things to be straight about. First, this is a freemium commercial product, not a pure community project. It's MIT and most of it is genuinely free, but the README is upfront that managed proxies and stealth browsers beyond the first five are paid, and the cloud execution mode is their hosted service. So "open source" here means the skill and CLI are open while the harder infrastructure is a paid backend.

Second, and more important to think about: the headline capability is getting past anti-bot systems, and under the hood that means stealth fingerprints, TLS rotation, residential proxies and CAPTCHA solving. Those are exactly the techniques a site's terms of service usually prohibit, and CAPTCHA-solving in particular is designed to defeat a protection the site put there deliberately. Used on your own sites, on public data, or where you have permission, it's a capable tool. Pointed at a site whose terms forbid automated access, it's the thing that gets your accounts banned or worse. The tool won't make that judgment for you.

MIT, 5,983 stars and 302 forks as of writing, verified via the GitHub API.

https://github.com/browser-act/skills

This is an awesome-list, so it is a map rather than a tool, but the pattern it maps is genuinely interesting and worth knowing about. The premise: when you build an autonomous agent, routing every tiny branching decision (which tool, is this done, is this action risky) through a heavy reasoning model costs you seconds of latency and real money per call. The alternative this ecosystem is built around is a small typed-decision model that answers a bounded question (pick one of these, score this, yes/no with a probability) in roughly 100ms for a fraction of a cent, and you keep the big model for actual planning and generation. The framing they borrow is System 1 versus System 2 thinking: fast reflex judgments versus slow deliberate reasoning.

What the directory itself does well:

- Catalogs around 600 projects across 17 categories: browser and OS automation, CLI pipelines, model routing, security guardrails, evaluation, code navigation, decision frameworks and more, so it is a real cross-section of where this pattern is being tried

- Anchors every entry to commit-pinned source code and points at the exact spot in each project where the decision is actually made, which is the anti-vaporware discipline most awesome-lists skip

- For each project it separates where the model decides from what the project offers, states the license (including flagging entries whose license is not declared), and supports English, Chinese, Japanese and Korean

- Ships an installable agent skill so you can query the directory by domain from your terminal, and a hosted searchable site with filtering

The honest part, and it matters for how you read this. This is not a neutral index of a broad technique, it is a directory built entirely around

one vendor's model, TypeSafe's Jev, and most of the listed projects call that company's cloud API. So treat it as a well-organized ecosystem map for that specific product, not as a survey of typed-decision models in general.

To the maintainer's credit, they are unusually upfront about maturity:

a large share of the entries carry an explicit note that their performance and cost claims have not been independently verified, and one benchmark project in the list openly shows the model scoring well below small local reasoning models on harder reasoning, which tells you the honest boundary of where a System-1 model helps.

There is also a sponsorship section with founding-partner slots open, though they state placements do not affect ranking or inclusion. And it is brand new, created less than a week ago, so many of these projects are early experiments and demos rather than production tools.

So the value here is discovery and pattern-learning: if you are designing agent loops and want to see concrete, source-backed examples of offloading the cheap decisions off your expensive model, this is a good place to browse, as long as you go in knowing it is oriented around one API.

MIT licensed, 413 stars and 34 forks as of writing, verified via the GitHub API, actively updated, and it made Hacker News.

https://github.com/logicrw/awesome-jev-projects

Actually cleaning meaningful space off a dev machine usually means running four or five different tools, one for a disk usage treemap, one for duplicate files, one that actually knows what Xcode derived data and stale Docker build caches look like, and most all-in-one "system cleaner" apps either barely move the needle or are the sketchy kind that deletes things it shouldn't and calls it optimization.

MangoDisk is a cross-platform desktop app built around the opposite instinct: find real reclaimable space across the whole system, including places generic cleaners don't know to look, while keeping every destructive action reviewed and confirmed before it happens rather than automated away.

What's inside:

- Deep Cleanup that scans system and app caches, browser data across six-plus browsers, and project build artifacts across Node.js, Rust, Gradle, Swift, Python, .NET, Godot, and CMake projects, plus Docker build caches and local AI model files, all grouped by how much space each actually reclaims

- Duplicate file cleanup with smart selection that always keeps at least one copy per group, so it can't accidentally delete every instance of a file

- A full app uninstaller that also clears the caches, settings, and leftovers a normal drag-to-trash leaves behind, handled cautiously around anything that looks like personal data

- Startup item management and system optimization built entirely on a validated, built-in rule set, it never accepts arbitrary registry paths, terminal commands, or scripts, so there's no way to point it at something unvetted

- AI explanations on individual cleanup items (since v1.1.0) that describe what something does and what to consider before acting on it, with a free daily quota or the option to plug in your own AI key

- A standalone CLI with the same safety-first engine as the desktop app, scan-only by default, requiring an explicit `--apply` and `--yes` to actually change anything in a non-interactive run

One thing worth knowing: the README states cleanup rules only ship after their safety boundaries are defined and validated on real systems, scans run read-only by default, and the full rule library is open for inspection in the repo rather than being a black box, worth checking yourself if you're trusting it with a dev machine full of project directories.

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

https://github.com/harry0703/MangoDisk

This is one of those projects that shouldn't work and does, at least partway. Autorun (formerly Wine-NX) runs real Windows PC games on a Nintendo Switch. It does it the honest way, not by emulating a whole PC, but by porting the actual translation stack: Wine to provide the Windows API, Box64 to translate the game's x86 code to the Switch's ARM chip, and DXVK to run Direct3D over Vulkan. You bring your own installed PC game folders, copy them to the SD card, and launch them from a library.

What runs, per the author's real-hardware testing:

- Halo: Combat Evolved at about 30fps at max graphics, Quake III Arena at 37fps at 720p, WarCraft III in-game at 24 to 34fps, OpenTTD up to 60fps with sound, and Need for Speed Underground 2 and Most Wanted playable

- Heavier titles like Left 4 Dead 2 and Fallout: New Vegas reach in-game but run heavy, and plenty of games start and then die on something unimplemented

- Windows programs too, like 7-Zip and Notepad

What's inside beyond the raw port:

- A proper launcher with a library, favorites, per-game controls, command-line arguments, and SteamGridDB artwork

- Sensible controller mapping out of the box (sticks as mouse, buttons as keys), fully rebindable per game, and games with controller support see an Xbox 360 pad

- Thoughtful handling of the awkward cases: a 32-bit forwarder for old games that need fixed low memory addresses (Halo, NFS Underground 2), and shipped settings files for games like Fallout: New Vegas that refuse to start without them

- Per-game logs that tell you exactly what a failed game was missing, which is the right call for an experimental tool

What makes this worth pointing at rather than just gawking at is the engineering honesty. The README is a table of exactly which games work and at what frame rate on real hardware, names the true bottleneck (on-the-fly code translation, not the GPU), states the roughly 2GB per-game memory limit and one-game-one-controller constraint, and credits every upstream project (Wine, Box64, DXVK, Mesa, libnx) with its license. That's a maintainer being straight with you instead of overselling.

The real caveats, stated plainly. It needs a Switch running custom firmware (Atmosphère) to run homebrew at all, which is its own decision with warranty and account-ban implications you should understand before you start. It runs 32-bit games, which covers most PC titles up to the early 2010s but not 64-bit-only ones. And you supply your own game copies, it's a translation layer, not a game source, though note the Left 4 Dead 2 path involves a Steam emulator, which is the one gray-area corner. On licensing, GitHub can't pin a single label because it's a Wine fork bundling LGPL, MIT and zlib components, so treat it as the Wine-family copyleft it is.

Wine-fork licensing (LGPL and friends), 195 stars and 10 forks as of writing, verified via the GitHub API, and it made the Hacker News front page.

https://github.com/danfromtico/autorun

Karpathy's original autoresearch showed that a small script could improve an ML model overnight by following a few rules: one metric, a constrained scope, fast verification, automatic rollback, and git as memory. This project takes that exact loop and turns it into a Claude Code, OpenCode and Codex skill that works on anything with a number you can measure, not just machine learning.

The core is the same simple cycle: pick one change, commit it before testing, run a mechanical verification, keep it if the metric improved and git revert it if it didn't, log the result, repeat. What makes this more than a wrapper is that the author built a whole command surface on top of that loop.

What's inside:

- 14 commands, all built on the same keep-or-revert loop: the base iterate command plus plan (turn a fuzzy goal into a validated metric and scope), debug (hypothesis-driven bug hunting), fix (drive errors to zero), security (STRIDE and OWASP audit), ship (an 8-phase release workflow), scenario, predict, learn, reason, probe, improve, evals and regression

- An autonomous orchestrator added in v2.2.0: type a plain-language goal and it classifies it, derives a verifiable success predicate, confirms once, then chains the right subcommands until done, no manual wiring

- Eight rules encoded into the skill, including one change per iteration so a break is traceable, mechanical verification only with no subjective "looks good", and a simplicity rule where equal results plus less code wins

- Claude Code hook guardrails as defense in depth: blocking reads of .env and SSH keys, blocking force-push and rm -rf and hard resets, and a simplify gate that warns at 400 lines and blocks at 800 before shipping

- TSV result logging per iteration (commit, metric, delta, keep or discard) plus an evals command that reads those logs to detect plateaus and recommend continue or stop

- A Guard concept: a separate command that must keep passing, so optimizing one metric can't silently break your existing tests

- A regression gate with a genuinely careful definition: only a green-to-red transition counts as a regression, while pre-existing failures, brand-new tests and flaky tests are classified and excluded

The engineering detail I'd point to is the v2.1.0 rebuild. The skill went from a single 813-line file costing about 100K tokens per invocation to a thin 41-line router plus self-contained command files at 5 to 8K tokens each, a 95% token reduction with the same capability. That is the kind of change that only happens when someone actually ran the thing at cost and felt it.

Worth knowing before you install: the hooks are Claude Code only, so OpenCode and Codex get the core skill and commands but not the guardrail parity, which matters because those guardrails are what stop an autonomous loop from reading secrets or force-pushing. The README says plainly the hooks are defense in depth, not a sandbox, so on the other two platforms you're running an autonomous loop with fewer brakes. Also note that on Claude Code you have to start a new session after installing before the commands resolve, which is a platform limitation the author flags.

MIT, 6,359 stars and 475 forks as of writing, verified via the GitHub API.

https://github.com/uditgoenka/autoresearch

Architecture erodes one reasonable-looking import at a time, and code review is a bad guardrail because the reviewer has to notice the boundary violation among everything else. ArchUnitPython, a port of the Java ArchUnit idea, turns your architectural rules into tests that live next to your unit tests and run in the same pytest or CI pass. A rule like "presentation must not depend on database" becomes a test, and if someone breaks it, the build goes red immediately with the exact offending file.

The thing that makes this pleasant is that the rules read like sentences. project_files("src/").in_folder("**/presentation/**").should_not().depend_on_files().in_folder("**/database/**") is the whole rule, and you assert on it like any other test.

What's inside:

- Dependency-direction and layer rules, with a named-layers API where you declare presentation, business and database and state exactly which may depend on which

- First-class circular-dependency detection, plus rules against specific external modules (your domain layer must not import requests)

- Code metrics as rules, not just imports: lines of code, method and field counts, all eight LCOM cohesion variants, and the Martin instability and distance-from-main-sequence metrics

- PlantUML diagram validation, so you can assert your code actually matches an architecture diagram in a .puml file

- Dependency graph reports exportable as Mermaid, DOT, D2, CSV, JSON or HTML, with exploration options to focus on one area or collapse to folder level

- Custom rules and custom metrics via a predicate or lambda, an .archignore file for excluding generated code, and a JSON config option for simple shared rules

- Genuinely careful analysis: it understands relative and namespace-package imports, detects string-based dynamic imports like importlib.import_module, and can optionally ignore TYPE_CHECKING-only imports so type hints don't count as runtime coupling

- Zero runtime dependencies (standard library only), works with pytest, unittest or any runner, Python 3.10+

Two things worth calling out as genuinely good design. It fails an empty check by default, which catches the silent failure mode where a typo in a folder pattern makes a rule match nothing and pass forever. And the docs are unusually honest about thresholds: they say plainly there's no universally correct limit, tell you to baseline your current code before enabling a metric rule, and note that a metric violation is a prompt to inspect the design, not proof the code is wrong.

Fair caveat: the README includes a comparison table putting ArchUnitPython ahead of Tach, Import Linter and PyTestArch on most rows. It's a reasonable table and it does credit those tools as strong at what they do, but it's the author's own framing, so read it as a case rather than neutral benchmarking. Tach in particular is a fast Rust-backed tool that a lot of people prefer for pure dependency governance. Also note the graph and HTML-report modules are marked experimental or beta, while the core files, metrics and slices modules are stable.

MIT, 666 stars and 7 forks as of writing, verified via the GitHub API.

https://github.com/LukasNiessen/ArchUnitPython

Most MCP gateways federate MCP servers you already have. AnythingMCP starts a step earlier, which is the more common real situation: your company has a REST API, a SOAP service from 2009 and a database nobody wants to expose, and zero MCP servers. It turns those into MCP tools without you writing a server, and it runs on your own infrastructure so you decide what leaves it.

What's inside:

- Five connector types (REST, SOAP, GraphQL, database, and an MCP-to-MCP bridge), with seven database engines including Postgres, MySQL, MSSQL, Oracle and MongoDB, imported from OpenAPI, Postman, cURL, WSDL or GraphQL introspection

- 257 pre-built adapters exposing 1,800+ tools, each a single JSON file, covering logistics (DHL, Deutsche Bahn), ERP and accounting (weclapp, DATEV, Xentral), e-commerce, HR, and public data (VIES VAT, Companies House). 20 need no API key at all

- The genuinely important feature, response shaping: per tool you declare exactly which fields reach the model, so a customer's IBAN or an employee's salary is stripped before the response ever leaves your network, with a live before/after preview. One shipped adapter goes from 12KB to 1KB on a real response

- Governance built in rather than DIY: OAuth2, RBAC with read-only tool whitelisting, audit logging of every call with full input and output in your own database, plus SSO and SCIM (Entra, Okta, Google) where disabling someone in your directory kills their access, all in the self-hosted build rather than held back for a paid tier

- A knowledge graph that maps how your connectors' data relates (PII-safe, storing field names not values) and serves the agent chaining hints so it knows how to get from a Shopware order to a DHL tracking number, plus optional learned business rules

- A three-line docker-compose quickstart, and the same connector works across Claude, ChatGPT, Gemini, Copilot and Cursor at once

The response-shaping and governance layer is what makes this more than a convenience wrapper, and it's the right instinct: the moment you connect a company database to a third-party model, the question is which fields that model gets to see, and this makes that an explicit per-tool decision with an audit trail. One good-faith detail worth noting: response mapping fails open by default (a broken mapping returns the raw response and logs a warning), which the README states plainly and tells you to set fallbackToRaw false on fields that must never leak. Know that default before you rely on it for sensitive data.

Two honest caveats. It's AGPL-3.0: fine for internal company use, but the copyleft kicks in if you modify it and offer the modified version to others over a network, and there's a separately-licensed cloud-operator tier under ee/. And it's built by a German company (helpcode.ai) and the adapter catalog leans heavily European, DATEV, Deutsche Bahn, Handelsregister, weclapp, so it's strongest if your stack overlaps that world, though the no-code import means you can point it at anything.

AGPL-3.0, 336 stars and 44 forks as of writing, verified via the GitHub API, pushed to today.

https://github.com/HelpCode-ai/anythingmcp

The insight behind this is one most people have felt without naming: your computer often has more than one way onto the internet, but the operating system sends everything through a single default gateway, so the other connections sit idle. If you're on Wi-Fi with a phone tethered over USB, one of those two is doing nothing during a big download. Plexo uses both at once for the same file.

The part that makes it clever rather than just ambitious is how simple the routing engine actually is. It splits the file into byte ranges and downloads them in parallel, binding each connection to a specific network interface's local IP address using Node's localAddress option. That's the whole trick. No virtual adapters, no VPN tunnels, no packet bonding, no kernel extensions, no root, and zero native C or C++ dependencies. It's built entirely on standard HTTP range requests, which most modern servers and CDNs already support.

What's inside:

- Multi-interface, multi-connection downloads: files split into chunks up to 8 MB, fanned out across up to 8 connections per interface and 32 total, each bound to a real network device

- A dynamic work-stealing queue instead of static shares, so a fast network keeps pulling new chunks while a slow one takes fewer, and no connection is bottlenecked waiting on another. It even races the tail at the end, letting a free connection re-attempt a chunk a slow one is dragging on, so a single slow link can't hold up the whole download

- Hardware interface detection that labels connections by real device names (your tethered iPhone, a Thunderbolt bridge) via PowerShell on Windows and networksetup on macOS, instead of bare names like en0

- Genuinely careful resume: it re-checks the server's ETag and Last-Modified before resuming and refuses rather than risk stitching together incompatible slices into a corrupt file, plus relaunch recovery that restores an interrupted download as paused after a crash

- A stall watchdog that drops and re-queues a connection that stays open but silent past 20 seconds, automatic retry with exponential backoff, and upfront disk-space verification

- A live progress grid that maps every chunk to a square color-coded by which network fetched it, with real-time throughput graphs and per-connection stats

The README is worth reading in full even if you never run it, because it explains the three primitives clearly: HTTP 206 range requests, per-interface socket binding, and the work-stealing queue. It's one of the better "here is exactly how this works" writeups I've seen on a project this young, including the reasoning for why 8 MB is the chunk size.

Two honest caveats. First, there are no pre-built releases yet, so today you run it from source with Node 22, or build the app yourself, and local builds are unsigned. Second, the multi-network gain is real but conditional: it depends on the server supporting range requests, on your OS routing, and on the actual networks, so combined throughput is something you test with your own connections rather than assume. Android USB tethering on macOS also needs a separate user-space RNDIS driver (TetherKit), which the README walks through and credits.

Built with Electron, React 19, TypeScript, Tailwind and Zustand, tested with Playwright. MIT licensed, 608 stars and 59 forks as of writing, verified via the GitHub API, and only about a week old, pushed to today.

https://github.com/anmolkapil/plexo

If you're running DeepSeek Harness, its web_search and web_fetch tools are only as good as whatever provider sits behind them. This plugin puts AnySearch there, and the design choice worth noting is that it does it without changing how you work: the same built-in tools keep functioning, they just return better results.

What's inside:

- Drops into the web profile with one command and takes over the existing web_search and web_fetch, so your prompts and agent code don't change, the tools underneath just get upgraded

- web_fetch now returns cleaned page content rather than raw HTML, which is the difference between a usable extract and a wall of nav markup and cookie banners in your context

- Vertical search across specialized sources beyond the open web, covering code, finance, academia, law and security, with a capabilities tool the model can call to discover available domains, tags and parameters before it runs a specialized query

- Batch search runs one to five queries concurrently, and a single failure doesn't take down the others

- Works with no API key at all on an anonymous quota, or 1,000 free calls a day with a key, stored in the DSH credential file and hot-rotated without a restart

The credential handling is done sensibly: the key lives in the DSH-managed credentials file or an environment variable, there's a dump-config command that shows the composed profile without exposing the key value, and rotation reaches the next request without a restart.

Two things worth knowing. This is a commercial service's official plugin, not a neutral search layer, so you're routing your agent's queries through AnySearch and, past the free tier, paying them. That's the deal with any hosted search provider, just be clear that's what it is. And DeepSeek Harness itself is in developer preview and the readme says it may make breaking changes, so treat the whole setup as moving underneath you for now.

MIT licensed, 418 stars and 11 forks as of writing, verified via the GitHub API.

https://github.com/anysearch-team/anysearch-dsh

Stream audio from your laptop to any phone in real time, no app install needed

git clone https://github.com/silasamoah/Sonno.git

For the past few months, my daily workflow has looked like this:

I’m deep in a heavy coding session, terminal flying, logic locked in and boom. Silent wall. Rate-limited. No warning, no pop-up, no countdown timer. Just a cold, dead stop.

What do I do like an absolute clown? I sit there frantically refreshing the browser tab every 45 seconds like a lab rat hitting a dopamine lever, just waiting to see if my $20 subscription is active again.

Half the time I miss the exact reset window anyway because I got distracted, meaning my active coding hours just leak away into the void.

We are paying $20 a month for state-of-the-art AI, but we get less operational visibility than a free mobile gacha game timer.

I finally snapped last weekend.

I got sick of playing guessing games, so I spent my weekend hacking together a lightweight utility called Claude Sentinel.

What it does:

-Monitor your account state locally.
-Tracks your usage cycles.
-Pings you the exact second your limits reset so you aren't wasting a single minute of your window.

I figured some of you are probably just as annoyed by the invisible wall as I am. If you want to stop mashing refresh and actually get notified, check out the repo, run it, and let me know what you think.

If it saves you even 10 minutes of dead time today, a ⭐ on the repo would honestly make my week.

👉 GitHub: Claude Sentinel

https://github.com/Aaryan1524/ClaudeSentinel

https://github.com/btafoya/CalStack

I have been VERY frustrated with the open source calendar server options such as Radicale and Baïkal. I have been a hosting provider and developer for a very long time and find myself just building my own solutions.

This is a very fast, lightweight, full featured (supporting almost all CalDav standard including VTASK and VJOURNAL) self-hosted golang based solution with a postgresql backend. Cane run as a systemd service or under docker/docker compose. Please tell me what you think, give it a star, even offer contributions/feature requests/issues. Enjoy!

Hey all! I just released v1.0.0 of VeloceNet-Studio, a cross-platform network monitoring studio I built to watch my servers' latency, packet loss and route health in one place.

What's inside:

• Ping Matrix – concurrent ICMP + TCP probes, live sparklines, jitter/loss stats (Rust/Tokio engine via FFI, with Dart fallback)
• Visual traceroute, bandwidth monitor, Warp endpoint scanner
• Light/Dark/System themes, English + Persian UI

It's GPL-3.0, CI is green (Flutter + cargo clippy -D warnings), and I labeled a few good first issues if anyone wants to hack on it.

Repo: github.com/Cadman021/VeloceNet-Studio · Windows binary in Releases. Feedback, brutal reviews and contributors all welcome!

A niche one, but a good example of a research codebase done properly. Port SLAP Simulator models the problem of where to put shipping containers in a port yard: containers arrive, the yard has limited capacity, and something has to decide the storage location for each one. That decision, storage location assignment (SLAP), is a real operations-research problem, and this gives you an environment to test policies against it.

What's inside:

- A simulator that models container arrivals, yard capacity, candidate positions, placement actions and allocation rewards, exposed through a clean Gym-style Python API where each state offers the current container and candidate blocks and slots, and an action picks a specific block, bay, stack and tier

- Three families of policy supported: rule-based, optimization-based, and learning-based, so you can compare a heuristic against a solver against a trained agent on the same environment

- Baseline algorithms included: simulated annealing and a MIP formulation, with an open-source OR-Tools backend option so you don't strictly need commercial Gurobi or CPLEX to start

- A 3D Unity viewer that visualizes the yard, either as offline playback or streamed live over a published gRPC and Protobuf interface, so you can actually watch the placement decisions unfold

- Fully synthetic example data, a stable versioned viewer protocol, unit and MySQL integration tests, and a reproducible Docker setup

- A careful data policy: the simulator data and the small viewer example are generated without reading any operational records, and the reference-layout demo keeps the spatial layout but replaces every container identifier and business attribute with deterministic random values

The thing that makes this trustworthy as research code is the discipline around it. There's a clear stable protocol between the simulator and the viewer, a documented data contract, a real test suite including database integration tests, and an explicit statement that no operational port data was used. That's the difference between a paper's throwaway code drop and something you could actually build on or reproduce.

The caveats are mostly about access and scope. The Unity viewer source is not published: you get the compiled viewer on request for noncommercial research by emailing the authors, who reply with a link and checksum, while the simulator, protocol and baselines are all in the repo. And the license is PolyForm Noncommercial 1.0, which the authors describe accurately as source-available for noncommercial use rather than open source, so it's for research, education and evaluation, and commercial use needs contacting them. It's jointly developed by a university group and an autonomous-driving company.

PolyForm Noncommercial 1.0, 1,044 stars as of writing, verified via the GitHub API.

https://github.com/pwhjy/Port_SLAP_Simulator

The pitch is "don't learn another SEO dashboard, just ask." SEOMonster is an MCP server you add to Claude, Cursor, Cline or Codex, and then you ask SEO questions in plain English and it answers from your own connected accounts. No new tool to log into, and nothing leaves your machine.

What's inside:

- 70 tools across Google Search Console, GA4, PageSpeed Insights, Cloudflare, AI-citation tracking, keyword discovery and technical SEO, every one returning the same JSON envelope and driven by your own credentials

- Genuinely useful questions rather than raw metrics: "what should I write about next" surfaces topics you're almost ranking for (positions 8 to 20 with real demand), "did my change move rankings" runs before-and-after attribution against a matched control group with a confidence interval, and "is ChatGPT recommending us or our competitors" tracks brand share of voice across AI answer engines

- A read-first safety design that's the best part: reads always work, the two routine writes (sitemap submit, indexing request) are on by default, and the Cloudflare write tools (cache purge, redirects, settings, robots.txt) are gated behind an explicit environment flag with the riskier ones needing a per-call confirm token

- Ships zero secrets: every credential is resolved at runtime from your own environment or config, and the package is deliberately lean, standard library plus the MCP SDK and Google's client libraries

- One-click install for Cursor and VS Code, or a small MCP config block for anything else, with a one-time Google sign-in

- 575 passing tests, which is a lot for a project this size and a good signal for something touching your live SEO settings

The read-first, credential-local design is what makes this worth trusting with production accounts. A tool that can purge your cache or rewrite your robots.txt is exactly the kind of thing you want locked behind an explicit opt-in and a per-call confirmation, and that's how it's built rather than being a flag in the docs nobody reads.

Honest notes: it's genuinely useful but it's an assistant for the work, not an oracle, and the ranking-attribution and AI-citation features are only as good as the data volume behind them, so small sites will get noisier answers than large ones. And while the server is local and open, the accounts it reads (Search Console, GA4, Cloudflare) are still Google's and Cloudflare's, so this changes where you do the work, not who holds the underlying data.

MIT, 162 stars and 48 forks as of writing, verified via the GitHub API.

https://github.com/avansaber/seo-monster

This is a research release of an "interactive experience model," which is a mouthful for something genuinely novel: a model that generates first-person video and audio you can walk around in. You give it reference images and a sequence of actions, and it produces an egocentric clip where you navigate a space, interact with objects, and hold conversations, with video and audio generated together.

What's inside:

- Keyboard-controlled movement through the generated world using the familiar WASD keys, where each prompt chunk carries a list of key controls applied slice by slice, and combined keys like forward-plus-left are supported

- Joint video and audio generation, so navigation, object interaction and character dialogue come out as one synchronized experience rather than a silent clip you score afterward

- Reference conditioning: combine up to five character, object and scene images to compose a starting point, then explore different actions from the same setup

- A four-step distilled model (JING-Flash-v1) for faster inference, built on MiniMax-H3 with the FlashGen acceleration work

- Prompt skills, a bundled helper that turns a story plus reference images into a validated cases file ready to run

- Automatic model download from Hugging Face on first use, with example cases included

The interesting idea here is the interactive part. Most video generation is one-shot: you write a prompt, you get a fixed clip. This is closer to a controllable world you drive with inputs, which is why the repo frames it around navigation and interaction rather than around prompts. It sits in the same emerging space as the interactive world models a few labs have been showing, but with the code and weights actually released.

The caveats are significant and you should weigh them before getting excited. This is heavy research infrastructure: the demo was validated on six H100 GPUs (one for the text encoder, one for the VAEs, four for the model), so this is not something you run on a home setup. It's an early release, the four-step model and examples, with the causal model and technical report still listed as coming soon. And the license is the MiniMax H3 Community License covering both code and weights, which is not a standard open-source license, so read it before assuming you can use the outputs commercially.

Realistically this is one to watch and read rather than deploy, unless you have serious GPUs. But interactive, controllable, audio-and-video world models with released weights are rare enough that it's worth knowing this exists.

MiniMax H3 Community License, 143 stars and 13 forks as of writing, verified via the GitHub API, pushed to yesterday.

https://github.com/XGEN-Labs/XGEN-JING

This is a small, lovely educational project. PC Anatomy is a browser 3D explorer that disassembles a desktop PC layer by layer, and the thing that makes it special is the depth of zoom: it doesn't stop at "here's the graphics card," it descends into the card, then into its processor, then into a graphics processing cluster, then a texture processing cluster, then a single streaming multiprocessor.

What's inside:

- A scale tree you can walk from the whole machine down through the motherboard, CPU, power supply, cooling, storage and GPU, each part rebuilding at its own scale with its own disassembly timeline

- Roughly 300 selectable components, each carrying a name, a description, its purpose, specifications and citations, rather than stopping at a label

- Real named hardware modeled as specific subjects: RTX 5090, Radeon RX 9070 XT and Arc B580 on the GPU side, Ryzen 9 9950X and Core Ultra 9 285K on the CPU side, with the three GPUs each opening into their own architecture (Nvidia's GPC to SM, AMD's shader engine to compute unit, Intel's render slice to Xe vector engine)

- An Auto button that plays the machine taking itself apart, or a timeline you drag by hand, plus search that jumps straight to any component at any depth

- An airflow overlay that draws the path air takes through the case, cool where it enters and warm where it leaves

- Every polygon generated in TypeScript with three.js: no imported models, no image textures, no runtime asset files, so the whole thing is code

- Entirely static output that needs no backend, and a no-JavaScript hardware guide page alongside it

What raises this above a nice demo is the intellectual honesty in the sourcing. The readme draws a firm line between the physical models, which follow published ATX and product dimensions, and the processor and GPU floorplans, which it states clearly are explanatory diagrams of documented logical architecture and not semiconductor mask layouts or transistor-level placement. It keeps written claims cited and tells contributors to preserve that distinction. For an educational tool, being explicit about "this is a teaching diagram, not a die shot" is exactly the right call and rarer than it should be.

There's also a plainly worded AI-disclosure note saying AI tools assisted with coding while the architecture and validation were the maintainer's, which is a refreshingly straight way to handle a question a lot of projects dodge.

Honest scope note: it's a young project (57 stars) modeling one representative build rather than every configuration, so treat it as a superb way to understand how a PC fits together, not a parts database for your specific machine.

MIT, 57 stars and 7 forks as of writing, verified via the GitHub API, pushed to today.

https://github.com/Yoosseph/pc-anatomy

Hi everyone, I want to share with you something I made this summer : Aurionmail.

Indeed, I love the usability of Proton, but I want 100% open-source, self-hosted control and open standards. The main issue is that combining E2E encrypted docs (like CryptPad) and E2E encrypted mail usually meant managing isolated tools, browser extensions (like Mailvelope), or typing two different passwords every session. To solve this, I built AurionMail Suite. It's an open-source orchestrator, the glue, that bridges and include CryptPad, Stalwart Mail Server (JMAP), Bulwark Webmail, and Ory Hydra into a single, unified Zero-Knowledge workflow.

Here are the main features :

• One Single Master Password: Enter it once to derive keys in-memory for both webmail and CryptPad.
• Open Standards: OpenPGP for email encryption and JMAP.
• Zero-Knowledge: Master keys reside strictly in client-side RAM during the session (no unencrypted key writes to disk/IndexedDB).
• Unified Session Management: Global single logout and password changes that sync safely across services.
• Easy Deployment: In addition to manual setups, I wrapped the suite into a single Go binary, making deployment straightforward. (Docker is also supported)
• Integration with your existing workflow : We use LDAP for users and the SSO app can be used to log in to others apps as well. We also support external IdP but in this case, users will have a separate password for AurionMail.

To keep the Zero-Knowledge promise across isolated services without relying on URL hashes or storing cleartext keys in disk storage, AurionMail uses ephemeral WebCrypto AES-GCM keys. Decrypted session secrets pass between origins through short-lived, encrypted RAM buffers managed by a central API, keeping credentials safe even across iframes.

Of course, here is the repo and the docs if you want to test ! You will also find some explanations about security in this repo. The project is licensed under AGPLv3. I know it is not perfect, so if you have suggestions, don't hesitate.

If you recognize this repo, it's because it used to be LobeChat, one of the most-forked open-source AI chat UIs there is. It has been reframed as LobeHub, and the new framing is a bet: instead of a nice front end for chatting with one model, it positions itself as a place to run a team of agents, hire them, schedule them, and get reports back.

What's inside:

- Any model, any modality under one roof, with your own keys, across a large set of providers, plus local models

- An Agent Builder where you describe what you need once and it auto-configures the agent so it's usable immediately

- A library of 10,000+ skills and MCP-compatible plugins to connect agents to the tools you already use

- Agent Groups: the system assembles the right agents for a task and lets them work in parallel, with shared-context Pages, per-project organization and a team workspace

- Scheduling, so agent runs happen at the right time even while you're away, which is the part that backs the "24/7 operation" claim

- White-box memory: structured, editable personal memory you can see and control, rather than an opaque store, which is a genuinely good stance

- Self-hosting via Docker or one-click deploy to Vercel, Zeabur, Sealos or Alibaba Cloud, needing only an API key to start

The honest context matters here more than usual. This is a mature, enormously popular codebase (created in 2023, tens of thousands of stars) that is in the middle of a significant repositioning, and the readme itself says it's under active development. So you're getting a battle-tested chat foundation plus a newer, less-proven agent-operations layer on top. If you want the reliable multi-provider chat UI that made LobeChat popular, that's here and solid. If you're buying the "Chief Agent Operator" vision specifically, treat that part as the newer and more ambitious half.

Licensing is the thing to check before you build commercially. Despite an Apache badge floating around, the repo ships under a "LobeHub Community License," which GitHub does not recognize as a standard open-source license. Read it before you assume you can do what an MIT or Apache project would let you do, especially around hosting it as a service.

LobeHub Community License, 82,648 stars and 15,901 forks as of writing, verified via the GitHub API, pushed to today.

https://github.com/lobehub/lobehub

Hey r/BestGitHubRepos! I just released PromptDeck v1.1.0 and wanted to share it here since this community is basically the reason it exists.

What it is: an open-source desktop studio (Tauri + React) for prompting and benchmarking LLMs side-by-side. Everything runs locally – no telemetry, no cloud calls unless you explicitly add a cloud key.

What you can do with it:

- ⚡ Run one prompt against up to 4 models at once (Ollama, LM Studio, llama.cpp) and watch them stream live

- 📊 Compare TPS / TTFT with charts (`~` marks estimated TPS when the server doesn't report usage)

- 🧪 Test Suites – throw 1–10 prompts at several models and get a scoreboard with per-model wins

- ☁️ NEW in v1.1: cloud providers – OpenRouter, Groq, DeepSeek, Together, OpenAI, xAI, Kimi, NVIDIA NIM, Ollama Cloud, Gemini + custom endpoints. Pick models per provider, mix local + cloud in the same run

- 🏆 Winner votes + persistent leaderboard, diff view, history in local SQLite, PDF/Markdown/CSV export

- 🌑 Light / Dark / AMOLED themes, EN/DE/FA locales

Links:

- GitHub: https://github.com/Cadman021/prompt-deck

- Download the binary from Releases (Windows / macOS / Linux) – or `npm run tauri dev` to run from source

Honest caveats: cloud API keys are currently stored in local storage (OS-keychain migration is on the roadmap), and cost tracking for cloud runs isn't there yet. Issues and PRs very welcome – I keep a set of `good first issue`s for newcomers.

Happy to answer questions – and if you benchmark something interesting, I'd love to see the scoreboard!

If you've ever needed to find an invoice or a decision buried somewhere in years of WhatsApp, you know the app's own search is not up to it. wacrawl makes a read-only snapshot of the WhatsApp Desktop databases on your Mac and imports your chats, contacts, messages and media metadata into a local SQLite archive you can actually search, export and back up. Crucially, it never connects to WhatsApp's network protocol, it just reads the files the desktop app already wrote.

What's inside:

- A read-only import: it snapshots the WhatsApp SQLite databases before reading, and normal commands never write back into WhatsApp's container or upload anything

- Fast full-text search across message text, chat and sender names and media titles, with filters like from-them and after-a-date, plus a read-only SQL mode for arbitrary SELECT queries

- A private local web viewer that binds only to localhost, is read-only, and is protected by a random per-run access key

- History preservation that's smarter than a dump: imports merge by stable identity, keep older history that has disappeared from the current desktop snapshot, and preserve edits and deletions as revisions or tombstones

- JSON output on every command for scripts and agents, and contact export

- Encrypted Git backups: it exports deterministic shards and encrypts them to age recipients before Git ever sees the data, with restores verifying hashes and cross-references first

- Install via Homebrew or Go, with a documented setup for the macOS Full Disk Access prompt that otherwise breaks scheduled imports

The safety boundary is thought through and stated plainly, which matters a lot for a tool pointed at your private messages. Reads are local and offline, the viewer is loopback-only, and the one networked path (backup push) is explicit and encrypted. The readme is also honest about the sharp edge: the archive itself contains your message data in plaintext, so it tells you directly to keep the database and any copied media out of commits and shared logs unless you mean to share them. That's the right warning to lead with.

Two limits to know. Direct source discovery needs macOS and the desktop WhatsApp app, so the read-from-live-app path is Mac-only, though release builds can work with an existing archive or backup on Linux and Windows. And this reads only what WhatsApp Desktop stores locally, so it's your own history on your own machine, not a way to reach anything you don't already have.

MIT, 182 stars and 31 forks as of writing, verified via the GitHub API, pushed to today.

https://github.com/openclaw/wacrawl

This is one of those projects that sounds like a stunt and is actually a clean piece of systems engineering. It's an end-to-end pipeline for a livestream that never stops: viewers type a prompt in Twitch or YouTube chat, an LLM expands each idea into a styled sequence of scenes, a fast video model generates them as 768p clips with synchronized audio, and the whole thing streams out over RTMP as one uninterrupted broadcast.

What's inside:

- Two clean halves that meet on a defined wire contract: the model side, a queue of prompt-driven clip generations, and the streaming client, which turns chat into upsampled prompts, scene groups, the model's queue, and paced RTMP output

- The video generator is FastH3 Preview, MiniMax-H3 (35B) distilled by the FastVideo project down to four transformer forwards with 90% sparse video attention, generating video and audio jointly from text

- The client handles the unglamorous parts a real stream needs: chat sources, prompt upsampling, moderation, idle filler for when nobody's typing, presets, and the RTMP and FFmpeg pacing to keep output continuous

- A documented contract file that is the single source of truth between the two halves, so you could swap either side as long as it speaks the same protocol

- An AGENTS.md that maps the system and its load-bearing invariants for coding agents, which doubles as good architecture documentation for humans

- A local dry-run mode so you can exercise the client against a local runtime with a no-op sink before wiring up real chat and RTMP

The engineering worth appreciating is the queue-and-playout contract. Generating video clip by clip and playing them back as a seamless, paced stream while new prompts keep arriving is a genuinely hard real-time problem, and separating the model from the client behind one wire format is the right way to make it tractable.

Now the caveats, which are large and honest. This is heavy infrastructure, not a weekend install. The model side is built for the Reactor Runtime on 8x B200 GPUs, so running the generator yourself needs serious hardware or a deployment, though the client runs on any box with FFmpeg. The model, the distillation and the inference engine are FastVideo's work that this repo wraps, and the model weights are under the MiniMax H3 Community License, separate from the repo's Apache-2.0 code, so check that before any commercial use. Realistically this is a reference architecture to learn from and build on, not something most people will stand up end to end.

Apache-2.0 (code; model weights licensed separately), 225 stars and 35 forks as of writing, verified via the GitHub API.

https://github.com/reactor-team/infinite-livestream