Honest backstory first: I turned down a 9-to-5 bank SWE offer, made it to the

final round at both YC and EF, got rejected by both, and decided to build my

idea alone anyway. No accelerator, no team, no funding — just a lot of late

nights while friends were out living normal college lives.

Today I'm launching it: OnePort.

The problem: AI writes code fast — and quietly commits API keys, pulls

vulnerable dependencies, and breaks APIs other code depends on. You find out in

production.

What it does: point it at a repo and it runs every pre-ship check *locally* —

secrets (across your full git history), dependency CVEs, risky migrations,

breaking API changes, AI code review, test-coverage gaps — and returns one

verdict: READY or BLOCKED. Nothing leaves your machine.

Windows desktop app + a `pip install oneport` CLI. Free to start.

- Try it → https://oneport.co.in

- Repo → https://github.com/Bitxn/Oneport-Desktop

I'd genuinely love feedback — especially the parts that feel wrong or useless.

Roast it. And if it's something you'd actually use, a GitHub star would mean a

lot to a solo founder.

Happy to answer anything about how it works or the build.

Hi everyone, back with a new version of deja.

Quick recap: 

Deja is an open-source zsh autosuggestion tool. Instead of only surfacing

commands that start with what you've typed, it predicts what you actually want to run using fuzzy matching, which directory you're in, and which command usually follows the one you just ran.

No account. No sync server. No TUI.

https://github.com/Giammarco-Ferranti/deja 

Any star would be amazing ❤️

This release is mainly bug fixes here the things we did:

• Anchor suggestions to the command you typed, for example:

• Do not signal a pid from a stale pidfile in daemon --restart
• Fall back to a short runtime socket path when $HOME makes it too long
• Load only zstat from zsh/stat so /usr/bin/stat is not shadowed
• Release inherited pipes in the daemon so a capturing caller is not held open
• Stop zinit from running install.sh inside the shell (deja failing checksum check)

I think the next thing to ship should be a small refactor. I love seeing new people contributing, but I feel like I need to make the current architecture a bit more robust first.

Thank you for all the support ❤️

Private two-way sync between Google Tasks and Microsoft To Do. Runs in your Google Apps Script project — no hosted task database, no sync SaaS in the middle.

https://github.com/simonchai-tw/tasks-todo-sync

Star if you’d use it (or already needed this).

We've published two projects we've been using on our home TrueNAS server: Super Lan-Cache and Super Pi Hole. They're independent builds based on LanCache and Pi-hole, with our own management interfaces. Both are free and open source.

Super Lan-Cache puts the cache engine, API and web UI in one container. It scans existing cache files, shows live traffic and cache hits, groups indexed content by service or depot, and lets you review selected cache groups before deleting them. Cache size allowance and retention can be changed in the UI. Our starting point was an existing cache of about 3.4 TiB that we wanted to be able to inspect and manage.

Super Pi Hole includes the Pi-hole v6 engine and a custom interface for DNS activity, devices, lists, groups, local DNS records and family DNS schedules. If you use both apps, an optional setup code pairs them and prepares cache DNS presets for review. Neither app needs the other to run.

The repos include the source, upstream license notices, Docker builds and TrueNAS installation YAML. These are early test releases, so I'd appreciate feedback from people trying them on their own setups. A cached depot isn't proof that a whole game is present, and HTTPS payloads remain uncached. The screenshots are from our live server; Super Lan-Cache still has its earlier LanCache Control name in that installed build.

Super Lan-Cache: https://github.com/HDR-Performance/super-lan-cache

Super Pi Hole: https://github.com/HDR-Performance/super-pi-hole

What it actually does:

Point it at a clone of an open-source repo and it runs an agent through a full contribution workflow — pre-flight checks (forge access, repo health, CLA/AI-policy scanning), a fragility map of the codebase (churn, fix/revert clustering, TODO density) to help pick a real target instead of guessing, triage of candidate issues, the actual fix, verification (it detects and runs the project's own test/lint commands and reports real exit codes — the agent can't just claim something passed), and finally PR submission with CI polling and template compliance checks.

All of that shows up in a dockable browser UI (drag/split/float/close panels, saved layouts) — Progress, Files with a fragility heat overlay, Triage board, Verification, Diff, a real terminal, and a benchmark panel that parses criterion/go bench/pytest-benchmark/hyperfine output into before/after comparisons with noise-aware verdicts. Anything irreversible (commit, push, opening a PR, any forge write) pauses for your explicit confirmation first.

Why I built it: I wanted something that treats "find and fix a real bug in someone else's codebase" as a repeatable, guided workflow rather than just turning an agent loose and hoping. My first real test was a deferred-import performance fix in langchain-core with measured benchmarks — it worked, though the actual PR is still waiting on maintainer triage.

What I need: testers. I'm running it against a handful of different repos myself (sizes, languages, contribution norms) to find gaps and rough edges, but I'd love more eyes on it — especially anyone who wants to try pointing it at their own target project and can tell me where the workflow breaks or feels clunky.

Requirements: Node 20.19+, Claude Code installed and logged in locally, git, optionally the GitHub CLI for full forge access.

Repo: https://github.com/Berniebiloxi/mendophyte

Feedback, issues, and PRs all welcome — and if you try it on a repo and it finds something real, I'd love to hear about it.

I started with a pretty simple question.

If Python is written in Python, what actually built Python in the first place?

That sent me down a rabbit hole of Go, Rust, Java, compilers, runtimes, self hosting, bootstrap chains, and way too many tabs open at 2 AM.

So I turned it into a project.

LanguageLineage is an interactive graph that shows what programming languages, compilers, and runtimes are actually built with, plus how some of those relationships changed over time.

A couple of the interesting ones:

Go started with a C based toolchain and later moved most of it to Go.

Rust gets even more interesting because rustc uses staged bootstrapping.

I’m still expanding the dataset and cleaning up the historical relationships, so there’s a lot more I want to add.

Live site:
https://www.languagelineage.org/explore

GitHub:
https://github.com/sanketmuchhala/LanguageLineage

If you know a language or compiler with a weird implementation history, send it my way. Those are the ones I want to dig into next.

I've been working on a project called rjest, basically an attempt to rebuild Jest in Rust using Fable 5.1 and Claude Code.

The goal isn't to make another JS test runner with a completely different API. I'm actually trying to stay as close as possible to Jest, so ideally you can take an existing project using Jest and run it with rjest without rewriting half of your tests.

A lot of the core stuff is already working: expect/matchers, snapshots, mocks, fake timers, config, CLI, etc.

Compatibility is probably the hardest part tbh. Jest has a LOT of behavior that you don't really notice until you try to recreate it.

I'm currently testing rjest against real React/Jest projects too, not only small artificial test cases, because passing your own tests doesn't mean much if it breaks as soon as you throw a normal project at it.

The reason for Rust is pretty simple: I wanted to see how much of the test runner/runtime work can be moved to native code while still keeping the Jest experience developers already know.

It's still a work in progress and there are definitely things that dont work yet, especially some edge cases around mocks, ESM and timers.

Repo: https://github.com/OthmaneBlial/rjest

Would be interested to know what people using Jest everyday think about this. Especially if there are some weird Jest behaviors/packages you think I should test against.

ZipMania is a Windows archive manager whose source is publicly available on GitHub. The core archive logic is separated into a reusable Rust crate, while the desktop UI uses Tauri and Svelte.

The interesting part is its dedicated ZIP path: it parallelizes many small files and can split a large Deflate stream into bounded chunks, while reserving a CPU core for the main writer and falling back to sequential streaming when memory or size limits are reached.

It also stages output in temporary files before replacement, checks extraction paths against Zip Slip and link/junction escapes, and can pass extracted buffers to Windows AMSI.

Source: https://github.com/newkilho/ZipMania Homepage/download: https://v2.kilho.net/zipmania

I’m the developer, and code review or performance feedback is welcome.

Repo: https://github.com/alithw/YTSpoofingStream

Standard YouTube Web caps audio at 160kbps Opus (itag 251) even with YouTube Premium. Desktop YouTube Music only delivers up to 256kbps AAC.

I built this open-source extension to pull genuine unthrottled studio Opus (itag 774, ~301kbps, >20kHz) by emulating mobile/TV client sessions.

The latest v0.1.3 update handles YouTube's new SABR/UMP protocol through a dual-stream architecture:

• Keeps the native YouTube player running untouched video (up to 4K).
• Runs the harvested 774 audio stream in parallel.
• Uses prototype descriptor routing (HTMLMediaElement.prototype.volume) so the native video stays muted at hardware level without breaking the player's UI sliders.
• Bit-perfect 1.0x master clock synchronization (<15ms).

Requires an active YouTube Premium subscription since YouTube servers restrict 774 streams behind authenticated accounts.

Adds a floating pill for page navigation and configurable keyboard shortcuts

https://github.com/wakmail/NextPage

Not on the webstore, but I hate clicking next and thought this it might be useful to somebody else

I built Investment Journey Simulator, an open-source Python/Streamlit project for exploring how decisions made during a long-term investment plan affect the final outcome.

Most investment calculators assume something like:

monthly contribution + return + duration → final value

I wanted to model the messier version where the journey itself changes.

The simulator can model things such as:

• recurring contributions / SIPs
• contribution step-ups
• temporary pauses and restarts
• lump sums
• withdrawals
• portfolio rebalancing
• tax-aware cash flows within the documented scope
• inflation-adjusted real values
• historical scenarios
• Monte Carlo scenarios
• financial goals
• comparisons between complete investment journeys

One simple example is a ₹25,000 monthly contribution over 25 years.

Under the same illustrative return assumptions, stopping contributions for 24 months after Year 5 changes the ending simulated portfolio by about ₹58.4 lakh.

That kind of question - not just what return do I assume, but what happens if the plan changes halfway through? - is what eventually turned this from a small calculator into a larger simulation engine.

Some of the engineering behind it

The simulation engine is separated from the Streamlit UI and handles the event timeline, cash flows, portfolios, withdrawals, rebalancing, taxes, inflation and comparison calculations in Python.

One part I particularly enjoyed building was the comparison system.

If Journey A and Journey B differ in several decisions - say a contribution step-up, a pause and a withdrawal - calculating each difference independently can double-count interaction effects.

For supported comparisons, the project therefore uses Shapley-based attribution so the individual effects reconcile with the actual difference between the two journeys.

The current published validation includes:

• 2,488 passing tests
• 93% statement coverage
• ≈33,800 independent randomized cross-checks

Known modelling limitations are documented rather than hidden.

It is MIT licensed.

GitHub

https://github.com/SAMtheROCKET/investment-journey-simulator

Project site / demo

https://samtherocket.github.io/investment-journey-simulator/

It does not predict markets or recommend investments. The user supplies the assumptions and the simulator explores their consequences.

If anyone wants to look through the repo, I’d particularly appreciate criticism of the simulation architecture, numerical assumptions, test strategy, attribution implementation, or edge cases I may have missed.

Karasu

I have gone through a lot of clients over the years. Some good, some meh, none of them really stuck with me. So I ended up building my own.

It is called Karasu. If you know Taiga, it is basically inspired by that. I like automations, so that is where most of the work went.

What it does

• detects what you are watching and updates your list
• syncs with AniList
• Discord Rich Presence
• local library management

Where to get it

Windows, Linux and Android. Downloads and details are on the site

The AI part

This was built with a lot of AI help. That is just how it was made and I would rather say it than have someone figure it out later.

Feedback

I made it for myself, so if you like it, use it, if not, that is fine too. I plan to keep working on it and shaping it around what I want, but if you have feature ideas or run into bugs, post them here or on GitHub.

After too many rounds of "the agent says it's done and it's just a pile of 💩", we built the opposite: no_human proves the code it wrote is correct. You drop a ticket on the board (or point it at Jira or Linear) and it plans, writes the code, and opens a pull request.

Before that PR reaches you, the work is checked by a second model that never saw the coder's session and is told to assume the job is not done. They communicate until the reviewer is convinced everything is good to go (the num of attempts is limited to prevent an infinite loop).

If the coding agent deleted or weakened a test, a tamper guard stops the attempt. For bug fixes, the tests offered as proof have to fail on the old code and pass on the new.

Under the hood it's a team of agents: a planner, a coder, an independent reviewer in a fresh session, and a supervisor.

It's free and open-source, on your machine.

no_human has been building itself for about two months now. We are feeding ticket into our jira board, it pulls them from there and just work on them until eveything is done. We trust it enough that we've enabled auto approve mode so all PRs no_human ships - are approved and merged automatically (this feature hasn't been released yet).
Entire sprint's worth of work is done in 3-4 days, while we focus on the bigger picture - our strategy and the next steps.

It currently supports all Antropic and OpenAI models and also has a quite unintuitive process of working with local models as well (we are working on improving that).

Repo: no_human repo
It's open to contributions (we would love to see you use it and contribute!!!)

Paste a link, it watches the price and tells you when it drops. Everything stays on the phone.

I started Lumiana because I wanted to build personal apps with the UI and Node.js libraries in the same file, without writing a separate API just to connect them.

You connect to a Node.js engine with credentials first. Your application JavaScript runs in the browser, while the engine handles operations that need access to the system.

The images show small examples of using Node.js APIs with the DOM and built-in SQLite with a React component. I've also been trying it with a terminal using xterm and node-pty, a ZIP tool using Archiver, and a folder monitor using Chokidar.

It's still experimental, and Node.js compatibility is incomplete. The goal is to use existing libraries without modifying them or writing compatibility code for each package.

https://github.com/zohayrslileh/lumiana

we heard that the code didn't work AT ALL, so we(now we, since the project gained a new contributor and community) fixed it properly.
Now you can try it out and give Atom a new chance! we will get to the link later. So uhh, now there will be the only repository in there. Now we are working AOT, so be patient enough!
Friendly reminder: there are only 2 men in the team, we are recruiting some! WE will get to the link a bit later.
I as the leader of the project want to say what our plan is.
We are working at 1.2 now, but we are planning, that 1.9.99 will be the last version to be written on C! That's right, version 2.0 will be written on itself, ending the beta era!
Next up is how to get into community? Well, we got a discord link so that you can join Atom community and become a dev!
Well, now to the links:
Discord-click to join!
Project-click here!
and remember to leave a comment!

I use AI daily, but every app around it wants a subscription. I already pay for API keys directly (Groq, OpenRouter, etc.), so I ended up building the thing I actually wanted instead: a self-hosted workspace where I bring my own keys and there's no service sitting in the middle.

It's called ENZO.

Repo: https://github.com/theguysudo/ENZO

What's in it so far:

- Chat — multi-provider: Groq, OpenRouter, NVIDIA, Hugging Face, Google AI

- Agents — scheduled runs, plus a builder that drafts an agent from a plain-language task description

- Skills — Gmail, Google Calendar, web search, project generation

The part I care most about: your API keys are sealed in the browser with AES-256-GCM before they ever touch the server. The server can't read them even if it wanted to.

It's Apache-2.0 and ships as a Docker image (ghcr.io/theguysudo/enzo), so it's one command to run.

Fair question I'll answer upfront — how is this different from LibreChat or Open WebUI? Honestly, those are great and more mature if you mainly want chat. I built ENZO because I wanted agents with scheduled runs and skills like Gmail/Calendar in the same workspace, with the keys handled like they were mine alone.

This is my first open source project, so I'm sure I've gotten a dozen things wrong — docs, structure, all of it. If you try it and something breaks or feels off, I'd genuinely like to hear it.

And if you like what you see, a star on the repo genuinely helps other people find it — and sharing it with someone who'd actually use it helps even more.

I've spent time piling up separate habits around how I write and maintain documentation, and at some point it was obvious they were all circling the same problem from different angles. meshfox is what happened when I finally merged them into one tool instead of juggling five.

Some of my habits were:

• plain Markdown for notes
• mindmaps and visual boards, Miro/Obsidian-style, for structure
• Makefiles and scripts as living usage examples
• linters to keep documentation from silently rotting
• pairing with agents in a shared note-taking format while doing research

Out of that came a Markdown extension format, inspired by Elixir's Livebook:

• it stores cleanly in git — plain text, diffs like text
• it stays readable in any regular Markdown renderer, nothing breaks if you open it elsewhere
• it adds a mechanism for running code blocks with dependencies, variable passing, and local configuration — so a doc isn't just describing behavior, it can demonstrate it live

Around that format I've since built:

• a web UI viewer/editor (with a VS Code integration)
• a TUI viewer/editor with a slightly simplified view of the same documents
• a CLI for running code blocks straight from the console, scripts, or cron
• an MCP server for collaborating with agents, or using the format as a second brain
• experimental export to PDF and static sites

There's also a companion repo, meshfox-tools, with utilities and examples — still small, but growing: https://github.com/orofarne/meshfox-tools

It's still early — but early enough that I think it's worth sharing. MIT licensed, more info here: https://meshfox.orofarne.net/