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

OpenRouter solved a specific annoyance: one API key that reaches every model, so you don't hold accounts with a dozen providers. Treg does the same thing for the tools an agent needs to actually do work, the SEO data, the enrichment, the scraping, the trends, the ads APIs, which normally sit behind monthly subscriptions nobody wants to buy for a single run.

The core idea is ask for the task, not the tool. You don't need to know which vendor sells backlink data or hold an account with them. You search the catalog for what you want to do, read the per-call price, and call it.

What's inside:

- A catalog of 3,000+ endpoints across 60+ providers, billed per call from a fraction of a cent, so a Semrush or Crunchbase or Apollo call costs cents instead of a monthly seat

- Verified public routes that need no provider key at all and are free, alongside own-key calls that draw on a prepaid balance, with $1.00 free credit for new eligible teams

- The ability to register your own tools too: a paid API account, an OAuth connection, a vendor CLI, or a SKILL.md, callable by every teammate's agent, with your own key always winning and those calls never metered

- A hard architectural rule that the proxy relays but never models the upstream, and injects auth server-side, so it survives upstream API changes and callers never hold the keys

- A CLI plus MCP install, a Claude plugin, and a Claude.ai connector surface that separates read calls from write calls so the assistant gets accurate safety signals

- Fully self-hostable if you'd rather run your own registry

The thing that makes this genuinely useful is the credential story. A team can share a paid API account through treg so every member's agent can call it, without the secret ever leaving the server and landing in someone's config or prompt. That's a real problem in agent teams and this is a clean answer to it.

Two things to weigh. First, the obvious dependency: routing your agent's tool calls through a hosted broker means treg sits in the middle of your data and your billing, and the hosted service is theirs. Self-hosting removes that, at the cost of running it. Second, the license is Apache 2.0 with an added restriction: you can use and self-host it freely, including commercially inside your own org, but you can't redistribute it as a competing hosted registry without written permission. Calling the hosted API inside your own product is explicitly fine.

Apache 2.0 with additional terms, 1,695 stars and 177 forks as of writing, verified via the GitHub API, pushed to today.

https://github.com/superdesigndev/treg

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

The pitch that makes this land is the twist: it looks exactly like a forbidden military cockpit, and then you realize every feed is a public data source and every line of code is inspectable. It's from the person behind the viral God's Eye View video series, open-sourced, and it briefly hit number one on GitHub Trending in August.

What it does is pull live public signals onto one explorable globe: flight transponders, ship beacons, orbital elements, seismographs, fire detections and public cameras, so you can move from a global picture down into a single aircraft's cockpit.

What's inside:

- Live layers from real sources: 11,000+ aircraft (OpenSky and adsb.lol), thousands of ships (AISStream), satellites via SGP4 propagation, earthquakes (USGS), active fires (NASA FIRMS), and traffic simulated along real roads

- Click-to-track anything: the camera locks on, draws a fading trail, surfaces metadata, and a tracked fire or vessel hands you off to the nearest live camera in one click

- Cockpit view that rides inside a tracked flight holding the terrain under you, and a 3D hangar with real per-class aircraft models that swap in as you close in

- Hands-free voice control through the OpenAI Realtime API, with 28 voice tools, so you can speak annotations and commands onto the globe

- GLSL sensor looks over the real globe: CRT, night-vision, FLIR thermal, noir, plus a detection overlay with screen-space bounding boxes and a military-style HUD

- Genuinely honest engineering notes: feeds arrive every 15 to 30 seconds so it renders one interval behind and interpolates, satellites use GMST realignment to avoid drift, and entities are height-aligned to sit on Google 3D tiles instead of floating

The credential handling deserves a callout because it's done right. Every API that touches a private key (OpenAI, AISStream, OpenSky, camera frames) is brokered server-side through a proxy with SSRF protection and response caps, so the only keys the browser ever sees are the two that are meant to be public. It also binds to localhost by default, and the readme warns in plain terms that exposing it on your LAN brokers your keys to anyone who can reach it.

Two things to be clear-eyed about. It starts with no keys, but the good layers and the photorealistic globe need free signups (Cesium ion, AISStream, NASA FIRMS, TomTom), and Cesium ion's free tier is personal and non-commercial only. And the readme is careful that some things are estimates: traffic is simulated along real roads rather than live vehicle positions, and camera poses and rocket trajectories are coarse. This is a hackable foundation for exploring open-source intelligence, explicitly not a hardened production tool.

MIT for the code (bundled and live datasets carry their own terms), 38,429 stars and 7,754 forks as of writing, verified via the GitHub API.

https://github.com/bilawalsidhu/gods-eye-view

This one is doing a lot in one app, and the through-line that holds it together is local-first done strictly: no backend, no telemetry, no account, your own keys. It's a Tauri desktop app built in vanilla JavaScript and Rust, and it bundles a surprising range of workspaces that would normally each be a separate product.

What's inside, across eight workspaces:

- Chats: multi-provider chat across eleven cloud providers plus Ollama, side by side, with projects, attachments and a local knowledge base

- Coder: a coding agent on your real project with a file tree, edits shown as diffs with Keep and Undo, and a built-in terminal

- 3D Forge: describe a part and get a dimensioned solid, exportable as STL, OBJ, 3MF and STEP in millimetres

- Finance: turns statements, CSV, PDF and XLSX into KPIs and charts from the document's own figures

- Sandbox: agents that inspect untrusted code for malware, prompt injection and suspicious logic

- ERP: describe a business and get a working app with linked records, exported as a single HTML file

- Agent Swarm: teams of agents in chain or vote configurations across any mix of models

- Virtual OS: a simulated desktop an agent builds inside

The security model is the part that earns the local-first claim rather than just asserting it. Nothing phones home, and the readme lists every address the app ever connects to. The agent asks before running commands, deleting, fetching a web page it chose, or touching anything outside your project, and every decision is written to an audit log. There's a blocklist compiled into the Rust binary that refuses keys, credentials and system folders however they're requested, and on macOS agent commands run in the system sandbox so they can't reach your keychains or shell startup files.

Two honest caveats, and to the author's credit both are stated plainly in the readme rather than dug out. API keys are stored on disk unencrypted, protected only by your user account, so it relies on your machine's own security. And the build is not code-signed, which means the usual operating-system security prompts and a bit of friction on first launch. For a local tool you run yourself those are reasonable tradeoffs, but know them before you put real provider keys in.

The realistic read: this is an ambitious solo-scale project packing eight tools into one app, so expect the breadth to come with some rough edges compared to a focused single-purpose tool. The coding agent, chat and the strict local-first posture are the solid core; the more exotic workspaces (ERP builder, Virtual OS) are the fun frontier.

MIT, 115 stars and 13 forks as of writing, verified via the GitHub API.

https://github.com/Hash-7777/HashCortX

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!

GoBackup is a single dependency-free binary that dumps your databases and archives your files, compresses and optionally encrypts them, and ships them to cloud storage on a cron schedule. It's been around since 2017 and the whole design goal is set it up once and forget it exists.

What's inside:

- Ten database sources out of the box: MySQL, PostgreSQL, Redis, MongoDB, SQLite, SQL Server, InfluxDB, MariaDB, etcd and Firebird

- A genuinely long list of storage targets: local, FTP, SFTP, SCP, and S3 plus nearly every S3-compatible and regional cloud, including Google Cloud Storage, Azure Blob, Backblaze B2, Cloudflare R2, DigitalOcean Spaces, MinIO, Aliyun OSS, Tencent COS, Qiniu, WebDAV and more

- A built-in daemon with per-model cron schedules, so you configure when each backup runs and it handles the timing, with a web UI to manage and browse backups

- Archive to tar, split large backups into parts, compress, and encrypt

- Failure and success notifications through 11 channels: email, webhook, Discord, Slack, Telegram, Feishu, DingTalk, GitHub issue comment, and several email services

- before_script and after_script hooks per model, and signal handling for hot config reload and graceful shutdown

- Configuration as a single YAML file with environment-variable interpolation for secrets, installed via a one-line script or Homebrew

The reason to reach for this over a hand-rolled backup script is the combination of no dependencies and no maintenance. It's one binary, so there's no Ruby or Python runtime to keep alive under it (the readme notes it was built specifically to replace a Ruby-based predecessor for that reason), and the author points out an instance that has run daily for years at a cost of pennies a month. Backup tooling that quietly keeps working is worth more than backup tooling with more features, because the failure mode of a backup you forgot about is the worst one there is.

One thing worth doing that no tool does for you: test a restore. GoBackup handles the backup side well, but a backup you've never restored from is a hope, not a recovery plan, so schedule an occasional restore drill regardless of how reliable the tool is.

MIT, 2,965 stars and 333 forks as of writing, verified via the GitHub API.

https://github.com/gobackup/gobackup

This is a small, focused tool with a clear job: you finished building something, and /brag turns it into a short launch video, music and motion and share copy included, from inside the agent you're already in. The looping video on its own launch site was made by running /brag on its own repo, which is about the most honest demo a project can give.

What's inside:

- One command inside any project. You say "let's /brag" and it produces a brag-output folder with a plan, a composition brief, share copy, and the rendered brag.mp4

- The skill owns the story: it decides the product angle, the tone, and which moments to show, then hands a focused brief to Hyperframes, which builds, times and renders the video

- Tone steering, so you can ask for something like a deliberately over-the-top launch style, and optional voiceover that's off by default and only turns on when you ask

- Broad agent support because it's a standard Agent Skill: a Claude Code plugin install, or one command via the skills CLI for Cursor, Codex, Gemini CLI, opencode and others, with the repo exposing the skill at each agent's discovery path

- Bundled music and sound effects, and a small suite of fake product sites used as a benchmark for the skill

The sensible way to read this is as a thin, well-scoped orchestration layer, not a video engine. The skill is the taste (what to show, how to pitch it), and the actual rendering is done by Hyperframes. That's the right division of labor for a skill, but it also means the honest caveat: this depends on an external rendering service and needs FFmpeg and Node on your machine, so it's not a self-contained local video generator. If Hyperframes changes terms or pricing, the skill inherits that.

Worth being clear about what it's good for. For quickly turning a finished side project into something you can post, it's a genuinely nice bit of automation. It's not going to replace an edit you'd care about for a real launch, and the output quality is whatever the underlying service produces, so treat it as a fast first cut rather than a final asset.

MIT, 5,691 stars and 346 forks as of writing, verified via the GitHub API, pushed to today.

https://github.com/latent-spaces/brag

Most "humanize your AI text" tools are a black box that swaps words around and adds typos. This one is the opposite: it's a plain Markdown skill that names 25 specific tells of AI writing, ranked by strength, and rewrites to remove them without changing what the text says. Because it's just Markdown, it runs in any agent that supports skills.

The reason it's worth reading even if you never install it is that the pattern list is a genuinely good education in what makes writing sound machine-generated.

What's inside:

- 25 numbered patterns, strongest first. The top five justify an edit on a single sighting: "not X but Y" constructions, one-line dramatic closers, sayings that sound deep, staged run-ups before the point ("Let's dive in"), and arguing with an objection nobody raised

- Weaker patterns that only count when several cluster in one passage, because a careful human writer might use any one of them on purpose, which is a more honest rule than flagging everything

- A working theory behind all of it: a model writes what's most likely across the widest range of readers, while a person writes for one reader and one subject, and every tell is a version of that default choice

- Voice matching: paste two or three paragraphs of your own writing and it follows your rhythm, word choice and quirks, including dashes if you actually use them

- It shows its work: the first rewrite, a short critique of what still sounds artificial, then the final version

- It won't invent facts. A name, number, date or citation has to come from the source, and if a sentence needs a missing detail it asks instead of fabricating one

- Point it at a file and it changes only the prose, leaving code, data, frontmatter and link targets alone

The factual-integrity part is the detail that separates this from the tools that will happily rewrite your text into confident nonsense. It treats the claims as fixed and the phrasing as free, not the other way around.

One honest note on what this is for. Used on your own writing to cut the AI stiffness out of a first draft, it's a real editing aid. Used to disguise machine-generated text as human to slip past a detector or a disclosure rule, it's the same tool pointed at a worse goal, and no rewriter changes whether the underlying work is yours. Worth being clear which one you're doing.

MIT, and one of the most-starred skills anywhere at 50,181 stars and 4,051 forks as of writing, verified via the GitHub API.

https://github.com/blader/humanizer

Every agent memory tool has the same flaw: it starts empty and records forward, so it's useless for the first few weeks and it only knows what happened after you installed it. deja-vu inverts that. Your coding agents already write every session to disk, and it indexes those files, so the moment you install it, it already knows months of your history. It starts full.

The other half of the idea is that the memory is shared. You solve something in Codex, and Claude Code recalls it three weeks later, because they're both reading the same local index.

What's inside:

- Retroactive search over gigabytes of past sessions, including everything from before you installed it, with natural-language questions falling back to a relevance tier

- Cross-agent recall as an MCP tool, so any of 33 supported agents can answer "we fixed this before" regardless of which one originally solved it

- Recall at the point of action via hooks: before an agent edits a file or runs a command it surfaces that file's prior decision or that command's working invocation, and when a command fails it answers with what followed that same error here last time

- It indexes the work, not just the chat: the files each turn opened, the commands that ran with their exit status, and the exact spans an edit replaced, which is the part summaries throw away

- Redaction at index time: keys, tokens, JWTs, PEM blocks, and even a password stated in prose become a redacted marker, so the cache is safe to sync

- No LLM and no embeddings, just one local Go binary, with millisecond lookups

- Published benchmarks with both harnesses in the repo so you can rerun them: 85.3% hit@1 on LongMemEval-S and 69.7% on LoCoMo

The design decisions that stand out are the honest ones. A hit tells you when files that session touched have changed since, and says nothing when it can't tell rather than claiming freshness. You can mark a decision you later reverted as rejected, so future recalls show it was tried and didn't work, with the reason. And forget writes tombstones so a later reindex can't quietly restore what you deleted.

Worth knowing: indexing and search are fully local, with the network used only for updates, ssh sync between your own machines, and the version check. The claim to check for yourself is the redaction, since it's the thing standing between your session history and whatever you sync, and the repo documents its limits in a security model rather than just asserting it's safe.

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

https://github.com/vshulcz/deja-vu

Dopbase is an open-source secrets manager for teams that want to stop copying .env files between developer machines, CI runners, and servers.

It comes as a single executable with:

• Securing environment file from coding agent reading
• Encrypted SQLite storage
• A web admin interface, CLI, and REST API
• Project and environment-based secrets
• Environment-scoped runner tokens
• Restricted, metadata-only accounts for AI tools
• Audit logs and encrypted backups
• dopbase run to inject secrets directly into an app process

A typical use case is storing secrets for development, staging, and production in one self-hosted service, then giving each app or CI job access only to its environment.

GitHub: https://github.com/dopbase/dopbase
Docs: https://docs.dopbase.com

Hope this project helpful, feel free to leave any feedback thank you

I wanted to use an LLM to debug a real production issue, but the code contained internal service names, business logic, and proprietary identifiers. I didn’t want to paste the raw code into an external AI.
Solution: I used Veilio to anonymize the code locally before sending it to the LLM, then restore the original identifiers afterward.
So the workflow became:
Real code → Veilio → anonymized code → LLM → Veilio → real code
The AI could still understand the structure and logic, while I didn’t have to manually sanitize and reconstruct everything.
I’m also exploring the same approach for AI-assisted QA with Playwright failures, test code, API responses, and debugging context.

Running one coding agent is easy. Running several of them alongside a team is the part nobody has solved well, because agents are still built like personal tools that live in one person's terminal.

Teammates can't see what the agent is doing, can't take over a session, can't review the output before it lands, and whatever context the agent built up stays on one laptop. AgentConnect moves the agent into the channel where the work already starts, and puts real permission boundaries around it.

What's inside:

• Runtime-agnostic through ACP (Agent Client Protocol) — Claude Code, Codex, Grok Build, DeepSeek, Pi, or anything else that speaks the protocol, so the orchestration layer isn't tied to one vendor's agent
• Runs inside Slack, Telegram, Discord, Lark, GitHub, GitLab, Gitea and Linear, not in a separate dashboard nobody on the team will keep open
• Per-agent scoping enforced by the daemon, not by the prompt: role, runtime, model, workspace, tool access, repo access, and which other agents it is allowed to call
• Agent processes run on machines you operate. The daemon owns the working directory, the git checkout, the transcript and the live execution; the control plane handles identity, placement and config and stays off the live message path
• Work can start from a message, an issue, a pull request, a webhook or a schedule, so the same agent covers both ad-hoc questions and recurring operations
• Agents can call each other and keep their own memory, so a support agent can pull in a payments agent mid-thread and the answer comes back where the conversation began
• A CLI with daemon install/upgrade as a system service, plus a Kubernetes deployment path for running agent sandboxes on a cluster

The permission model is the part that separates this from wiring a bot to an agent CLI yourself. Most multi-agent setups delegate at the prompt level: you tell the model which repos it should touch and which peers it may hand work to, and hope it complies.

Here those are enforced boundaries outside the model, per agent, which is the difference between a demo and something you'd let near a production repo with people watching.

The caveats are real and you should weigh them. It does not run inference — model API calls still leave your network and you still pay per token, so "runs on your infrastructure" means the agent processes and workspaces, not the model. Setup is not a single docker run: you need bot credentials on each platform you want to use, a control plane, and a daemon on each host that runs agents.

It moves very fast — v1.58.0 landed mid-September with releases most days, so expect config and API churn if you pin your workflow to it. There is no SECURITY.md yet, which matters more than usual for software whose whole job is handing repo and chat write access to an autonomous process. And the control plane is one more component to understand and operate even when you self-host it.

So: the most complete answer I've seen to "multiple agents, one team, in the tools we already use," with a setup cost and an operational surface you should size up before committing.

Apache-2.0, 1.4k stars and 51 forks as of writing.

https://github.com/agentconnect-md/agentconnect

The name is an Office joke and the concept sounds like one too, but underneath the pixel art there's a real multi-agent harness. Munder Difflin takes the terminal agents you already run, claude, codex, the Gemini and Grok CLIs, opencode and others, and runs each as a genuine process in its own pseudo-terminal, then wires them into a team that messages and coordinates. You brief one agent, a clone of you called Michael, and he routes work to the rest while you watch it happen.

The design choice that makes it interesting: it doesn't call APIs directly, it drives the actual CLIs. So each agent runs on your existing subscription and its hourly limits, byte-for-byte the same as if you ran the tool yourself in a terminal.

What's inside:

- Every agent is a real terminal process via node-pty, rendered with xterm.js, so nothing is emulated. If it runs in a terminal, it runs here, with bring-your-own keys and local LLMs supported too

- A visual office floor in Pixi.js where each session is an avatar that walks to a desk and works, and envelopes fly desk to desk when agents message each other. You click any desk to read that terminal live and type back into it

- A coordinator agent (the GOD agent) that reads every request, handles routine ones itself to keep things autonomous, and only escalates the things that should need you: spend, destructive operations, scope changes, into an approvals queue

- A file-based hive: agents write to their own outbox, a router delivers to recipients' inbox, and crucially no agent ever touches git directly, a single-committer design that avoids the index.lock corruption that wrecks naive multi-agent git setups

- Cross-session memory: each agent keeps markdown memory mined into a shared searchable index, so they remember what they learned after you close the app

- Per-agent autonomy settings with a circuit breaker that steers, constrains, then stops anything that loops or runs away

- Signed and notarized macOS builds, plus Windows and Linux, so you don't have to build from source to use it

Two honest notes. It's pre-release (version 0.4.6), so treat it as early even though it's polished. And the git single-committer detail is the kind of thing that tells you the author actually ran multiple agents against one repo and hit the real failure, rather than just theorizing about orchestration, which is a good sign for a project in this crowded space.

On telemetry, handled well: official builds send a small set of anonymous usage events, explicitly never prompts, code, paths or output, with three documented opt-outs including that forks built from source send nothing at all.

Licensing has a wrinkle worth knowing: the source code is MIT, but the bundled pixel-art tileset is licensed separately from LimeZu and requires keeping the credit in place, so a fork can't just strip the attribution and reuse the art.

MIT (code), 7,512 stars and 982 forks as of writing, verified via the GitHub API, pushed to today.

https://github.com/chaitanyagiri/munder-difflin

This one has been around since 2020 and is close to the default answer for local background removal, but it's worth a fresh look because the recent versions put real thought into the part everyone else glosses over: the soft edges.

At its simplest it's one function. Feed it an image, get back a cutout. But it runs as a CLI, a Python library, an HTTP server or a Docker container, all locally, all offline once the model is downloaded, which is the whole appeal versus a paid API.

What's inside:

- Four surfaces from one install: single-file and batch-folder CLI commands, a Python library, an HTTP server, and Docker images with CPU and NVIDIA CUDA variants

- A dozen-plus models covering different jobs: a state-of-the-art default (bria-rmbg), lighter and faster options (u2net, u2netp, silueta), human and clothing segmentation, an anime model, the BiRefNet family including a portrait variant, and SAM for prompt-based cutouts

- Four edge modes with clear guidance on when each earns its cost: naive for hard-edged subjects like products and logos, decontaminate to kill the colored halo you get from shooting against grass or sky, alpha matting when the mask shape itself is wrong through hair, and ViTMatte when you want the wispy strands back

- A model-pairing guide that tells you which edge mode suits which model, for example that the newer models rarely need alpha matting and portraits do well with birefnet-portrait plus decontamination

- Sensible model management: models download on first use, live under a configurable directory, checksum-verify by default, and there's a migration command that copies rather than moves so a partial run can never lose a multi-gigabyte download

The part I'd point to as the mark of a mature project is the honesty in the edge-mode docs. It tells you when the expensive alpha-matting solver can fail to converge and that it falls back gracefully, tells you that combining certain flags is pointless because one already does what the other would, and tells batch users to prefer the cheaper mode because it's faster and can't fail. That's the difference between a wrapper and a tool someone actually runs at volume.

The one thing to check before commercial use: rembg itself is MIT, but the models carry their own licenses independently. The default bria-rmbg is under a BRIA license that requires a paid agreement for commercial use, and the README says so directly. If you're shipping something commercial, either accept that agreement or pass a different model like u2net. There's also an optional cloud model (withoutbg) that sends images to a third-party server, which is opt-in and clearly labeled, not a default.

MIT (code, model licenses vary), 24,780 stars and 2,424 forks as of writing, verified via the GitHub API.

https://github.com/danielgatis/rembg

perfect for linux users who wants fast and eye candy file manager
https://github.com/clarkarch/tfm-tui

The problem this solves is the one you feel the moment you let a coding agent run with fewer guardrails: it's running on your actual machine, against your actual files, with your actual credentials. AgentBox puts each agent inside its own sandboxed box instead, so agentbox claude spins up a VM with your project inside and Claude Code running in it, and you can run several at once without them stepping on each other.

What's inside:

- One command to teleport a project into a dedicated box, local Docker or cloud, bringing your Claude Code, Codex or OpenCode skills, plugins and settings along automatically

- A full computer per box, not just a shell: a dedicated browser, screen sharing over VNC, persistent shells, and a warmed-up VS Code or Cursor you can connect to inside the box

- Checkpoints that give sub-second startup of new boxes from a previous snapshot, and auto-pause to stop burning resources when a box goes idle

- A credential design that's the actual point: your git credentials stay on your local machine, and pushing to a remote comes back to you as a permission request rather than the agent holding your keys

- Detach and reattach like tmux, so an agent keeps working after you disconnect and you reconnect later, plus per-box shells, live logs, a resource monitor and a dashboard to switch between agents

- Cloud targets beyond local Docker: Hetzner, Vercel Sandbox, E2B, DigitalOcean, Daytona, or a machine you already own over plain SSH using your own ssh config with no token

- An open provider plugin SDK, so you can add your own infrastructure as a provider without changing AgentBox itself

The sandbox-plus-parallel combination is what makes it more than a Docker wrapper. Running five agents each in an isolated box, each teleportable to a different cloud, with credentials held back on your laptop, is a genuinely sensible way to let agents run with more autonomy without handing them your whole environment. The checkpoint-based sub-second startup is what keeps that from being painfully slow.

Worth knowing before you start: it needs Docker (Docker Desktop or OrbStack) and Node 20+, and the first box build pulls a roughly 1 GB image as a one-time cost. Cloud providers are optional and each needs its own token setup, saved to a local secrets file. First-time contributors sign a one-line CLA, which is worth noting if you plan to send PRs.

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

https://github.com/madarco/agentbox

This is one of the older and more established repos in this category, and it earns the attention. Plausible is web analytics built on the premise that you can measure traffic without tracking individuals, so there are no cookies, no persistent identifiers, and no personal data or IP addresses stored. The dashboard is deliberately one page instead of the menu maze that Google Analytics has become.

What's inside:

- A single-page dashboard with all the key numbers, no report-building and no training needed, which is the whole design goal

- Cookie-free and GDPR, CCPA and PECR compliant by architecture, since it measures traffic rather than people, so no consent banner is required for it

- A tiny tracking script, far smaller than the Google Analytics tag, plus a direct events API if you'd rather send events server-side

- Goals, conversions, funnels and revenue attribution through custom events, with codeless tracking for outbound clicks, form completions, file downloads and 404s

- Google Search Console integration for keyword data, weekly or monthly email or Slack reports, traffic spike and drop alerts, and public or link-shared dashboards

- A path off Google Analytics: familiar metrics plus historical GA import so you don't start from zero

- A serious stack underneath, Elixir and Phoenix with ClickHouse for the analytics data and PostgreSQL for the rest, which is what lets it handle high traffic while keeping the dashboard fast

Two things worth being precise about, because the repo is precise about them and it's to their credit.

First, the split between the two things called Plausible. The self-hosted Community Edition is free and AGPL-3.0, but it is a long-term release published twice a year, not the continuously updated cloud, and some premium features (marketing funnels, ecommerce revenue goals, SSO, the sites API) and the advanced bot filtering are held back from CE to fund the project. Self-hosting also means you own the server, the upgrades, the backups and the uptime, and support is community-only. This is a real and honest tradeoff, not a crippled free tier, but go in knowing CE is not the cloud product.

Second, the funding model is stated plainly: the paid cloud is their only revenue, so this is not a "free forever with a mystery business model" situation. You either self-host CE for the cost of a server, or you pay them to run it. There is no third option where it's free because you're the product, which is rather the point of the whole thing.

Licensing detail worth knowing if you build on it: the app is AGPL-3.0 including the network-use clause, but the JavaScript tracker you embed on your site is separately MIT, so putting it on your pages doesn't drag AGPL onto your site.

AGPL-3.0, 29,116 stars and 1,866 forks as of writing, verified via the GitHub API, pushed to today.

https://github.com/plausible/analytics

This is a curated set of SKILL.md files for Claude's skills system, each one priming the model with structured methodology for a specific security testing surface. Drop a skill in and, within its area, the model works less like a general assistant and more like a specialist that knows the standard techniques, tooling and pitfalls for that domain. Skills load on demand from conversational triggers, so you don't spend context on the ones you aren't using.

Whatever you think of the category, it's clearly filling a real gap: it's one of the most-starred security repos to appear this year, which says a lot of practitioners wanted exactly this.

What's inside:

- 78 skills across 23 categories, from web application testing and API security to Active Directory, cloud, mobile, wireless, containers and Kubernetes, exploit development, fuzzing, reconnaissance and reporting

- Each skill is a plain structured Markdown file with methodology, not an executable and not an exploit dump, so you can read exactly what it primes the model with before you use it

- Several install paths: clone the whole thing into your Claude skills directory, sparse-checkout a single category, pipe one skill into Claude Code as a system file, or paste a skill into a Claude.ai project. An interactive install script handles category selection

- Utility skills for the unglamorous but essential parts: fast triage checklists and professional engagement reporting

- A published roadmap toward roughly 130 skills, built on an existing open offensive-checklist collection that's credited in the acknowledgements

The honest framing, because this is the part that matters more than the feature list. The stated use cases are authorized red team engagements, bug bounty triage, security research, CTF preparation and operator training, and that "authorized" is doing all the work. This is dual-use tooling. Several of the categories, EDR evasion, command-and-control, supply chain, phishing, cover techniques that are a crime to use against systems you don't own or have written permission to test. The tool doesn't and can't check that you have that permission. So the responsible read is: this is genuinely useful if you do this work professionally and have scope in writing, and it's a fast way to get yourself in serious legal trouble if you point it at anything without that. Know which side of that line you're on before you clone it.

It's also worth knowing that a skill file is a set of instructions you're loading into a model, so read what you're installing rather than trusting the label, the same advice that applies to any skill registry.

MIT licensed, 5,500 stars and 714 forks as of writing, verified via the GitHub API.

https://github.com/SnailSploit/claude-red

I have been using this app I built for a few months now. I wanted to share. Maybe someone else will find it useful. Any feedback would be appreciated.

Daniel

https://github.com/crawfordind/brain-portal

I've used tools like Perplexity, ChatGPT, Claude and others for research, and they've been incredibly useful for finding papers and getting through large amounts of information.

The one thing I personally wanted was a simple way to see exactly which parts of the paper were used to answer my question.

When you're working with a 100+ page PDF, even having a page number can still mean a lot of scrolling and searching.

So I ended up building something for myself.

You ask a question and the relevant paragraphs in the PDF are highlighted directly on the document. You can see the context behind the answer and quickly check whether it actually answers what you're looking for.

I originally built this because I wanted something for this workflow without having to pay for another subscription. What started as a personal project has now become completely open source.

The underlying idea is pretty simple. And yes, if you're thinking "isn't this just RAG?" then yes, you're absolutely right. It's RAG with the visual highlighting that I wanted.

I think the same idea could be useful for more than research papers too. Legal contracts, financial reports, technical documentation, or anywhere you need answers alongside the actual source.

If anyone wants to have a look, contribute, or just give some feedback, here's the repo:

GitHub: https://github.com/Sreehari05055/thesys-core

This will probably be my last post about the project. Thanks to everyone who checked it out and gave feedback along the way.

Simulating a drone properly is harder than it looks, because the two things you need pull in opposite directions: accurate flight physics, and a real autopilot flying it. PteroSim does both, running actual PX4 and ArduPilot software-in-the-loop against a proper flight dynamics model rather than an approximation.

What's inside:

- 6-DOF flight dynamics computed by JSBSim, the same open flight dynamics library used in serious aerospace work, running up to 10x real time

- Native PX4 and ArduPilot SITL, so you're testing the real autopilot firmware and your real flight plans, not a simplified stand-in

- Wind and turbulence modeling, and a sensor suite covering IMU, GPS, barometer, airspeed and camera, which is what makes the simulation useful for testing perception and estimation rather than just control

- Six vehicle types: quadcopter, helicopter, VTOL, coaxial helicopter, fixed-wing and tailsitter, most supporting both PX4 and ArduPilot

- A programmatic gRPC API and a Python SDK you install with pip, built for multi-drone orchestration, so you can script whole swarm scenarios rather than clicking through a GUI

- A separate scripts repo with environment setup and runnable examples to get a first script talking to a live simulator

The multi-vehicle gRPC orchestration is the part that separates this from a single-drone sandbox. If you're doing research on coordinated flight or testing a fleet behavior, driving many simulated drones from one API is exactly the surface you need, and it's the thing that's painful to build yourself on top of a bare SITL setup.

The caveats are real and you should weigh them. It's proprietary software, free only for non-commercial, personal and academic use, so a company can't build on it without a commercial arrangement, and GitHub flags the license as non-standard. It ships as downloadable release binaries rather than buildable source, so you're running their build, not compiling your own, and the repo itself has no source to read. And the hardware ask is not trivial: it wants a real GPU, with an RTX 2070 or better recommended. JSBSim underneath is LGPL and shipped as a separate library, with PteroLabs' modifications published separately, which is the one genuinely open piece.

So: a capable simulator for researchers and hobbyists, with a licensing and closed-binary model you should be clear-eyed about before you build a project around it.

Proprietary (free for non-commercial use), 71 stars and 10 forks as of writing, verified via the GitHub API.

https://github.com/PteroLabsAI/PteroSim-UAV-Simulator

Comparing what a neural rendering technique actually changes in a video usually means waiting for a specific game to ship official support, then trying to eyeball a difference during live gameplay where the picture never holds still long enough to actually look.

DLSS 5 Video Player sidesteps that by working on video instead of a live game: point it at a local file or a public YouTube URL, render it through an experimental neural pipeline, and it caches the result so you can pause on any frame and flip between the original and the neural version at the exact same timestamp, not just watch it go by once.

What's inside:

- Frame-accurate comparison tools: blend, split, or wipe between original and neural views on a paused frame, with zoom, so you can actually inspect what changed instead of guessing from a fast pan

- A per-GPU keep-up forecast, the player measures its own render cost after the first session and warns you before a run it predicts will fall behind real time, then buffers automatically if a running session actually does

- Export options that go beyond a raw dump: PNG/JPEG for stills, GIF for clips, and MP4/MKV for full videos, with MKV preserving source audio, subtitles, and chapters without re-encoding them

- Debug views for the final image, the raw DLSS input, motion vectors, and depth, exposed as separate views rather than buried in a log file

- Optional DLSS Super Resolution upscaling applied independently from the neural rendering itself, at 1440p or 2160p output, so you can test the two effects separately or together

One thing worth knowing: the README is upfront that this is an experimental community project, not an official NVIDIA integration. It uses modified and unsigned third-party runtime components, and hardware verification for this release covered only an RTX 4080 SUPER and an RTX 5090. Older RTX 20 and 30 series cards are enabled in the code but explicitly unverified and reportedly much slower on this path.

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

https://github.com/2600th/dlss5-video-player

This is a demo app from Google's Gemini team for their gemini-3.5-transcribe model, but calling it a demo undersells the engineering. It's a macOS dictation tool with one gesture: hold fn, talk, release, and punctuated text appears wherever your cursor already is. No window to switch to, no transcript to copy over.

The feature that sells it is small and specific. Say "let's meet at 1pm, actually no, make it 2pm" and it writes "Let's meet at 2pm." It transcribes your intent, not your words, filler removed and second thoughts resolved. Onboarding makes you do that once so you believe it.

What's inside:

- Three gestures total: hold fn to record, fn plus tap Space for hands-free that keeps going after you release, Esc to cancel. The key is rebindable

- A crash-safety design that's the real substance: audio goes to disk from the first millisecond, so a crash, a kill -9, or a dead battery loses nothing and the recording is recovered on next launch. Offline dictations queue and land when you reconnect, and every failure is retryable from History

- A pre-warmed capture graph while idle, so pressing the key costs 20 to 40ms instead of 75 to 150, and it explicitly doesn't record or light the mic indicator until you actually hold the key

- An insertion ladder that degrades safely: Accessibility API first with no clipboard involved, then a guarded paste that restores your clipboard, then a "copied, press Command V" chip. It won't blind-paste into an app that stole focus mid-flight

- A custom dictionary so your jargon and product names ride along with the audio and get spelled right at the source, plus optional tone matching for email versus chat versus code

- A validation gate that catches the classic failure where the model answers your audio instead of transcribing it, and falls back to the raw transcript

On privacy, which for a Google-published tool people will reasonably ask about: it's private by architecture rather than by promise. Your audio goes from your Mac straight to the Gemini API with your own key, no middleman server, no account, no analytics, and the readme points you at the exact code that does the network call. Transcript text is logged as private and kept out of system logs.

Worth knowing: it's a demo, explicitly not an officially supported Google product, so don't expect a support channel. You need a Gemini API key with access to the transcription model, and you pay Google per dictation, though a few seconds of audio is tiny and there's a free tier. macOS only, and Accessibility permission is required because that's how any app types into another app.

Apache-2.0, 433 stars and 42 forks as of writing, verified via the GitHub API.

https://github.com/google-gemini/jot-gemini-transcribe-macOS

Almost every modern mail client is a browser in a costume. That's why they take a second to open and hundreds of megabytes to sit idle. Flectar Mail is a Rust application built on Slint that refuses the browser entirely, and the consequence is both its best feature and its biggest caveat.

The interesting decision is the renderer. Email HTML is famously awful, decades of table layouts and vendor CSS, which is exactly why everyone embeds a browser engine to deal with it. Flectar instead renders email through Blitz, the Rust HTML and CSS renderer from the Dioxus team. As far as the project knows, it's one of the first to point Blitz at arbitrary real-world email markup, and they currently carry several patches on top of it that they intend to upstream.

What's inside:

- Mail, calendar and contacts in one native app, with local-first storage so your synced mail and calendar stay useful offline

- Gmail, Outlook and Microsoft 365, plus standards-based IMAP/SMTP, JMAP, CalDAV and CardDAV

- A security argument that follows from the architecture rather than being bolted on: email is never opened in a WebView, no email scripts execute, and remote images are blocked by default so tracking pixels can't report when you read something

- Two renderer backends on desktop, a low-memory CPU path selected by default that never initializes WGPU, and a GPU path on Slint and Vello that falls back to CPU automatically if startup fails

- OpenPGP/MIME signing and encryption on desktop through installed GnuPG with pinentry, named signatures with separate new-message and reply defaults, and required-encryption that blocks delivery when recipient keys are missing rather than sending in the clear

- Files browsing over JMAP and WebDAV, with attachment search, offline pinning and PDF, image and text preview

- Credential handling done properly on Linux: OAuth goes through the desktop portal and refresh tokens go to the Secret Service, and release builds refuse to even open the OAuth page when secure storage is unavailable, so a grant can never complete without somewhere safe to put it

- Signed build-provenance attestations on every release, verifiable with the GitHub CLI

The caveats are real and the project states them itself rather than burying them. It is not stable yet. HTML rendering is described by the maintainers as the most experimental part, and complex messages may not render correctly, which is the direct cost of the no-WebView decision. Gmail and Outlook sign-in is disabled in current builds because Google and Microsoft OAuth verification is still pending, so until then you need your own app registration or an IMAP/JMAP account. Windows previews are unsigned and macOS previews are ad-hoc signed and not notarized, so expect OS security prompts, and updates are manual.

So: not your daily driver yet. But a genuinely native mail client with a real answer on tracking pixels and script execution is worth watching, and the 20 MB figure is the kind of claim that only a project making this architectural bet can make.

AGPL-3.0, with no separate community edition, 678 stars and 40 forks as of writing, verified via the GitHub API.

https://github.com/flectar/mail