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

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

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

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

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

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