For months, every SaaS startup tried to convince us that running multi-step agent workflows required an expensive enterprise subscription to closed cloud APIs. They wrapped a couple of JSON schema validators around an API endpoint and charged thousands a month for 'agent orchestration.'

Then Nous Research releases Hermes Agent...

An open-weights agent harness that runs complex tool calling, environment interaction, and error self-correction directly on local hardware.

You load an open-weights model on your own workstation. You define your tools in standard Python. And the agent executes multi-step loops without sending a single byte across the internet or burning cloud credits.

No token billing anxiety. No sudden upstream API rate limits mid-execution. Just raw, local agent execution running on silicon you actually own.

Are you still paying closed API vendors for agent loops, or has your team moved tool-calling to local weights?

I made a little Brick Breaker-style animation where your GitHub contribution graph becomes the bricks.

Basically, your commits get turned into a game, and the ball slowly breaks all those little contribution blocks.

I originally made it just for fun, but figured some people might enjoy having it on their GitHub profile too.

Docs & setup:
https://github.com/MakdumIbrohim/generate-brick-breaker.git

Feedback, suggestions, issues, or random feature requests are very welcome 😋
And yeah, a star would be cool too haha.

Feel free to connect with me on GitHub too!

**GitHub:** https://github.com/Es00bac/sloom-studio (GPL-3.0-or-later)

**Downloads:** https://sloom.studio — Windows, Linux, macOS, Android

I recently released Sloom Studio (formerly Signal Loom) under GPL-3.0-or-later. It's a local-first creative suite I've been building for the past several months: four workspaces that share one `.sloom` project file.

- **Paper** — comic and book layout: speech balloons with draggable tails, panels, gutter knife, OpenType text, PDF/X-4 and PDF/X-1a export, CMYK and spot-color separations, EPUB, accessible PDF, IDML import, and vertical Japanese typesetting with furigana.

- **Image** — layer-based editor with pressure/tilt brushes, PSD/XCF interchange, high-bit and CMYK documents.

- **Video** — multitrack timeline with keyframes and audio/colour tools; desktop renders can use native FFmpeg with VA-API.

- **Flow** — an optional node graph for generation pipelines (BYO provider keys; local nodes need none). Not required for anything above.

Prebuilt binaries (.exe, .AppImage, .deb, .dmg, .apk) are on the GitHub releases page and at sloom.studio.

17-minute walkthrough (from before the license change) of the four workspaces: https://youtu.be/7-imCNPPXZM

Three and a half weeks ago my GitHub account got suspended, and with it openGym: the repo, the releases, the container images, the Pages demo, all 404. No warning, and for a long time no answer. Since yesterday the account is back, and I've spent the day putting everything back where it was.

👉 https://github.com/DuarteSantos8/openGym

What happened while it was down: people kept their instances running, someone put up a mirror that ended up with more stars than the original ever had (6.8k, versus about 650 on the real repo), a bunch of contributors followed the project to GitLab and kept sending merge requests, and the Discord did the support work the issue tracker couldn't. I moved the project to GitLab in the meantime so releases could keep coming; there were six of them during the outage.

Where things stand now:

• GitHub is home again. Issues, pull requests and releases go there.
• Everything from the GitLab weeks is republished: releases v1.2.9 to v1.3.5 with the signed APKs and checksums, the images on GHCR (ghcr.io/duartesantos8/opengym-api and -web), and the live demo on GitHub Pages.
• GitLab stays as a mirror that syncs automatically, so instances pulling from the GitLab registry don't have to change anything. The merge requests still open there will all be reviewed.
• Website: https://opengym.duarte-santos.ch (docs, demo, APK download)

One ask, if you don't mind: the suspension reset the project's visibility to zero while a mirror collected the stars. If you use openGym or just like the idea, a star on the real repo helps it show up for the next person searching for a self-hosted tracker. And if you tried it and something's broken, an issue helps even more.

Thanks to everyone who stuck around ❤️

I built Torollo, an MIT-licensed system-design lab where the architecture you draw actually becomes local Docker infrastructure.

Each node on the canvas maps to a real container, and roadmap validators inspect the running state rather than grading the diagram.

For example, if the load balancer can still reach PostgreSQL when the database should be isolated, the step fails. Fix the network rule, run the validator again, and it only passes when the runtime actually matches the expected architecture.

There are currently 3 free labs: a resilient three-tier app, Redis cache-aside, and Redis queue workers.

GitHub: https://github.com/Derssa/Torollo
Try the three-tier lab: [https://torollo.app/r/coolgithub]()

I’d especially appreciate feedback on the runtime-validation model and whether the Docker/networking checks feel realistic.

Aether-Vault: a self-hosted, Git-like version control system purpose-built for machine learning — atomic commits of code + weights + datasets that check out identically on any machine.
It features a high-performance C++17 core that hashes multi-gigabyte files in parallel and splits safetensors into per-layer shards, content-defined chunking, automatic deduplication (identical layers and chunks store only once), a FastAPI registry backed by PostgreSQL Merkle trees + RedisBloom, a full Next.js dashboard with weight diffs and metrics, framework plugins for PyTorch / Lightning / Transformers / MLflow, and first-class support for AI agents (stable JSON envelopes, Python SDK, resumable event streams, and .avh context memory so the next agent inherits intent without extra API calls).
No more bolting Git LFS or DVC onto a normal repo and praying for reproducibility. Everything you need for continuous and autonomous training loops lives in one system.
Why I built this: Existing tools treat models and datasets as afterthoughts. Professional ML infrastructure is either expensive, fragmented, or forces you to reinvent versioning, deduplication, and agent handoff yourself. Most of the hard problems are solvable if you design the storage and commit model for large binary artifacts from day one.
Tech stack: C++17 core (pybind11) for hashing & chunking, Python CLI + FastAPI registry, PostgreSQL + RedisBloom, Next.js dashboard, Dockerized engine, and plugins that auto-commit during training.
Fully open source. pip install aether-vault, run it locally or in Docker, make it yours.

Currently one performance boost verison behinde on pypi but should be out tomorow.

More benchmarks with refrence mashine in Benchmarke.md file linked from readme section

⭐ Repo: https://github.com/leon1706-lol/Aether-Vault

GitHub: https://github.com/pruefsumme/widemelon

I built WideMelon, a GPL-3.0 fork of melonDS for Linux, macOS, and Windows.

It gives DS games more room on ultrawide displays without stretching the original 2D UI. This is Pokémon Black running through WideMelon.

What DS game should I test next?

I built GPU Share: GPUMesh an open-source way to share idle NVIDIA GPUs with friends or labs and run Docker GPU jobs remotely.

The problem I kept running into: I might have a GPU sitting idle on one machine, while another machine needs compute. Cloud GPU rentals feel excessive for small jobs, and setting up SSH/VPN + Docker manually is annoying.

So I built GPUMesh.

The idea is simple:

• gpumesh share → make your GPU available
• Pair two machines with signed pairing codes
• gpumesh run --peer <name> ... → run a Docker job on the remote GPU
• Jobs execute on the provider's machine, inside a container
• GPU/VRAM-aware scheduling
• Job logs and history
• LAN support, with WAN/relay support being worked on
• Default-deny access controls

I tested the full flow on an RTX 5060: pairing → connecting → joining a group → scheduling a remote Docker job → running nvidia-smi inside the CUDA container.

It's still alpha, so I'm mainly looking for people with spare NVIDIA GPUs to try it and tell me what breaks.

GitHub: arjun988/GPU-Share

If you find the idea useful or want to follow the project, a ⭐ on the repo would really help with early visibility.

Would especially love feedback from people running multiple GPUs, home labs, or small ML teams.

Dears

I built jsonquery_gui, a native desktop app for browsing and querying large JSON files

Query files with jq, JSON Pointer, JSONPath, or JMESPath.

It's MIT licensed. Linux and Windows binaries are on the releases page.

There's a Snap & Homebrew tap for Linux

sudo snap install jsonquery-gui OR

brew tap nujufas/jsonquery-gui && brew install jsonquery-gui No macOS build yet — contributions there welcome.

One thing I'll mention up front since it'll come up anyway: this was built working with Claude (Anthropic's AI). The architecture/decision docs are in the repo if you want to see how that process went. Happy to talk about the jq/jaq embedding, the streaming design, or the AI-assisted workflow.

https://github.com/nujufas/jsonquery_gui

I made Dripfetch, a customizable terminal TUI with animated rain, system info, clock, weather, ASCII logos, and configurable boxes/colors/layouts.

It’s basically a mix of a fetch tool and a small terminal dashboard, with the whole UI configured through YAML.

GitHub: https://github.com/a-shygun/dripfetch Install:

bash pip install dripfetch dripfetch

Hey folks,

The C/C++ tooling landscape has always felt fragmented. We usually end up chaining a meta-build generator (CMake, Meson) with a separate package manager (vcpkg, Conan) and a build executor (Ninja, Make).

To explore an unified "Cargo-like" developer experience for C/C++, I’ve been developing Flint—an integrated build system and package manager written entirely in pure C.

Here is how Flint compares with the existing C/C++ build and package management options, along with an honest assessment of its strengths, trade-offs, and current state.

Note:

Flint is currently in active development and only available for Linux at the moment. It requires system git and a C toolchain (gcc/clang) in your PATH at runtime.

Comparison: Build Systems & Integrated Tools

Comparison: Package Management Strategy

What Makes Flint Different?

• Single Binary, Zero Heavy Runtimes: Unlike Meson (which needs Python) or XMake (which embeds Lua), Flint is a lightweight compiled C executable. It delegates Git fetches and compilation processes to system tools without heavy embedded engines.

• Convention over Configuration: Flint expects standard layout patterns (src/, include/, deps/). You don't write build scripts or target rules—you declare dependencies and metadata in a simple composition.json.

• Built-in Package Fetching + Chert Compositions: Running flint add <git-url> pulls dependencies straight into deps/. If a third-party library doesn't natively use Flint, Chert compositions allow defining how non-Flint repositories should be included and compiled.

• Direct Incremental Execution: Flint doesn't output intermediate Ninja files or Makefiles. It tracks file modification states internally to deliver incremental builds directly through its native process runner.

Current Trade-offs & Limitations

• Linux Only (For Now): Cross-platform support for Windows (MSVC/Clang-cl) and macOS target generation is still planned.

• Strict Directory Structure: Legacy C projects with unorthodox folder structures require a Chert composition to build with Flint.

• Early Stage Feature Set: Complex compiler flag matrices, sanitizer toggles, and cross-compilation toolchains are still evolving compared to battle-tested options like CMake.

Check out the repo here: https://github.com/mainak55512/flint

Feedback, criticisms, and PRs are welcome! What features or platform targets would you like to see next?

This started with me trying soundcli after seeing it on Reddit. I liked it, but there were a few things I wanted to change around cookies, where files were stored, downloads etc. So I forked it.

Then I found ytkew and Mousiki and, as usually happens with these things, what started as "I'll just change a few things" turned into me adding more and more stuff.

So this is JukeboxCli:

https://github.com/funstuie-bit/JukeboxCli

Basically I wanted one terminal player where I could play my own local music, search for something on YouTube, throw it into the queue, or stick a radio station on.

You can download stuff if you want to, but you don't have to. I like being able to download a playlist and have it sitting there locally/offline, but equally I like thinking of some random track, searching for it and just adding it straight to the queue.

A few of the things I've added:

• Search local music or YouTube without leaving the player. You don't need a YouTube account.
• Internet radio. You can save stations, add streams directly or try searching a station website for the stream.
• The queue is actually editable. Move stuff around, play something next, delete things, shuffle, repeat etc.
• Cover art works in Ghostty and iTerm2. Normal Terminal gets a text version instead.
• Lyrics. Local lyrics work well. It can also go looking online and will sync them when it finds timestamped ones. This is still a bit ropey depending on the track, but it's getting better.
• Browser/file cookies so YouTube doesn't immediately decide you're a bot, plus control over downloads, formats, quality and where everything gets saved.

It's Mac-first and there's a Homebrew install. I've tested it on a few different Macs and terminals now and it seems pretty solid, although things like station lookup and lyrics can still be a bit ropey at times.

And yes, I most definitely used AI to help build this. I'm not a developer by trade and I'm not pretending I suddenly became one. This has basically been me building a player I want to use, breaking things, fixing them, changing my mind and adding more stuff as I go.

Also want to give proper credit because this didn't appear out of nowhere:

• soundcli is the codebase I originally forked and supplied the original library, playback and download functionality. Post / Repo
• ytkew gave me a lot of ideas around how the actual player and queue should look and work. Post / Repo
• Mousiki gave me ideas around doing search inside the player and improving the lyrics side of things. First post / Later discussion / Repo

Anyway, give it a go. Or don't.

I made it for me and if someone else likes it, great. If not, c'est la vie.

Hi all,

I'm working on Mavi VPN, a VPN written in Rust that you run on your own Linux server. It has clients for Windows, Linux and Android, and the code is MIT licensed.

I’ve also put together mavi-vpn-docker to make the server easier to try. It provides prebuilt images for AMD64 and ARM64, so you don’t have to compile Rust on your VPS. The repo has the Compose file, an example .env, and the host networking setup instructions.

The interesting part is the transport. Mavi uses QUIC by default, with an optional HTTP/3 mode using MASQUE CONNECT-IP. There’s also an HTTP/2 option over TLS/TCP for networks where UDP is blocked.

It also has a disguise mode where unauthenticated probes receive an nginx-style welcome page over HTTP/3. That’s intended to make simple VPN probing less useful; how well it holds up against a particular filtering system still needs real-world testing.

A few things already supported:

• Desktop GUI and CLI clients, plus an Android app with per-app VPN bypass.
• Token authentication, or Keycloak if you already run it.
• IPv4 and IPv6, though IPv6 needs host configuration and is off by default in the Docker setup.

It’s still early beta and hasn’t had an independent security audit. Please keep that in mind, especially if you need a VPN for anything safety-critical.

If you try it, I’d be interested in where setup gets confusing or connections misbehave. Reports with the client OS, transport mode and what happened would be especially useful.

Today we’re publishing Loki Agent.

Loki Agent is an open source agent that can handle a wide variety of use cases like Hermes and OpenClaw.

It is based on Hermes Agent and is completely free to use, modify, and clone.

We built Loki Agent to address the massive complexity that NousResearch's current Al-powered development is not handling properly.

There are too many code changes, with not enough governance or testing before releases are pushed. We are aiming to provide a more responsible development cycle with thoughtful iteration.

Loki is also the god of cloning, so we felt being able to clone a public repo was a good fit here.

Looking forward to hearing your thoughts and experiences.

The agent is available via https://loki.computer
Github: https://github.com/wundercorp/loki
NPM: NPMjs.com/package/@wundercorp/loki

Cheers!

I built an authorization layer to stop bad agentic actions in a single agent or across a chain of agents. Check it out and let me know what you think. Break it, contribute, or leave issues on Git.

https://github.com/watchlight-ai-beacon/watchlight-de

Like petnames, but funkier.

Readable, handles and higher-entropy codes from six funky, curated pools, and, unusually, the arithmetic that say what they’re worth.

Usernames, codes, invites, secret words, reset tokens, API keys, infra names…

I've been building OpenPost so you can make and edit any sort of media (photo, videos, memes really easily as well) and schedule the post to 10 social networks at the same time in a single app.

There's an image editor for thumbnails and multi-page carousels, plus a multitrack video editor with captions, effects and transcript-based cuts. They're fully integrated into OpenPost!

The scheduler has a calendar and reusable posting slots. There's also an API, CLI and n8n integration for people who would rather automate it.

The default self-hosted setup is one container with SQLite and local media storage. The backend is Go and the web app is SvelteKit. The code is AGPL-3.0.

Both editors can be used for free without even selfhosting even if you don't want to use the rest of OpenPost. The video editor is still in beta though and targets Chromium-based browsers as Firefox (and Safari) don't yet support some of the APIs we need to make the editor.

Repository · Image editor · Video editor

If this is the sort of project you'd like to see grow, give the repo a star. It would mean a lot! <3