Show stories

Hi HN! I built Oxyde because I was tired of duplicating my models.

If you use FastAPI, you know the drill. You define Pydantic models for your API, then define separate ORM models for your database, then write converters between them. SQLModel tries to fix this but it's still SQLAlchemy underneath. Tortoise gives you a nice Django-style API but its own model system. Django ORM is great but welded to the framework.

I wanted something simple: your Pydantic model IS your database model. One class, full validation on input and output, native type hints, zero duplication. The query API is Django-style (.objects.filter(), .exclude(), Q/F expressions) because I think it's one of the best designs out there.

Explicit over implicit. I tried to remove all the magic. Queries don't touch the database until you call a terminal method like .all(), .get(), or .first(). If you don't explicitly call .join() or .prefetch(), related data won't be loaded. No lazy loading, no surprise N+1 queries behind your back. You see exactly what hits the database by reading the code.

Type safety was a big motivation. Python's weak spot is runtime surprises, so Oxyde tackles this on three levels: (1) when you run makemigrations, it also generates .pyi stub files with fully typed queries, so your IDE knows that filter(age__gte=...) takes an int, that create() accepts exactly the fields your model has, and that .all() returns list[User] not list[Any]; (2) Pydantic validates data going into the database; (3) Pydantic validates data coming back out via model_validate(). You get autocompletion, red squiggles on typos, and runtime guarantees, all from the same model definition.

Why Rust? Not for speed as a goal. I don't do "language X is better" debates. Each one is good at what it was made for. Python is hard to beat for expressing business logic. But infrastructure stuff like SQL generation, connection pooling, and row serialization is where a systems language makes sense. So I split it: Python handles your models and business logic, Rust handles the database plumbing. Queries are built as an IR in Python, serialized via MessagePack, sent to Rust which generates dialect-specific SQL, executes it, and streams results back. Speed is a side effect of this split, not the goal. But since you're not paying a performance tax for the convenience, here are the benchmarks if curious: https://oxyde.fatalyst.dev/latest/advanced/benchmarks/

What's there today: Django-style migrations (makemigrations / migrate), transactions with savepoints, joins and prefetch, PostgreSQL + SQLite + MySQL, FastAPI integration, and an auto-generated admin panel that works with FastAPI, Litestar, Sanic, Quart, and Falcon (https://github.com/mr-fatalyst/oxyde-admin).

It's v0.5, beta, active development, API might still change. This is my attempt to build the ORM I personally wanted to use. Would love feedback, criticism, ideas.

Docs: https://oxyde.fatalyst.dev/

Step-by-step FastAPI tutorial (blog API from scratch): https://github.com/mr-fatalyst/fastapi-oxyde-example

I’ve been working on this for about a year through four major rewrites. Godogen is a pipeline that takes a text prompt, designs the architecture, generates 2D/3D assets, writes the GDScript, and tests it visually. The output is a complete, playable Godot 4 project.

Getting LLMs to reliably generate functional games required solving three specific engineering bottlenecks:

1. The Training Data Scarcity: LLMs barely know GDScript. It has ~850 classes and a Python-like syntax that will happily let a model hallucinate Python idioms that fail to compile. To fix this, I built a custom reference system: a hand-written language spec, full API docs converted from Godot's XML source, and a quirks database for engine behaviors you can't learn from docs alone. Because 850 classes blow up the context window, the agent lazy-loads only the specific APIs it needs at runtime.

2. The Build-Time vs. Runtime State: Scenes are generated by headless scripts that build the node graph in memory and serialize it to .tscn files. This avoids the fragility of hand-editing Godot's serialization format. But it means certain engine features (like `@onready` or signal connections) aren't available at build time—they only exist when the game actually runs. Teaching the model which APIs are available at which phase — and that every node needs its owner set correctly or it silently vanishes on save — took careful prompting but paid off.

3. The Evaluation Loop: A coding agent is inherently biased toward its own output. To stop it from cheating, a separate Gemini Flash agent acts as visual QA. It sees only the rendered screenshots from the running engine—no code—and compares them against a generated reference image. It catches the visual bugs text analysis misses: z-fighting, floating objects, physics explosions, and grid-like placements that should be organic.

Architecturally, it runs as two Claude Code skills: an orchestrator that plans the pipeline, and a task executor that implements each piece in a `context: fork` window so mistakes and state don't accumulate.

Everything is open source: https://github.com/htdt/godogen

Demo video (real games, not cherry-picked screenshots): https://youtu.be/eUz19GROIpY

Blog post with the full story (all the wrong turns) coming soon. Happy to answer questions.

I feel like I finally built something I actually use every day and it has completely changed the way I think about work. AI workflows have flipped how devs operate. You're not heads down writing code anymore, you're bouncing between projects, instructing agents, reviewing their work, nudging them forward. The job is now less about typing and more about judgment calls.

And the thing about that workflow is you spend a lot of time waiting. Waiting for the agent to finish, waiting for the next approval gate. That waiting doesn't have to happen at your desk. It doesn't have to happen in front of a monitor at all. I built Seasalt because I realized my iPhone could handle 80% of what I was chaining myself to my Mac for. Kick off the agent, walk away, review the diff from the store, a walk, or in a separate room away from your Mac. Approve it. Start the next one, switch to another session. You don't need giant dual monitors for this. That's kind of the whole point.

Also, I have a deep security background so I felt like it was 100% necessary to include end to end encrypted with a zero knowledge relay, no ports getting opened, no VPN configuration needed, with key validation in the onboarding flow.

Hecate is an AI you can voice and video call from Signal iOS and Android. This works by installing Signal into an Android emulator and controlling the virtual camera and microphone. Tinfoil.sh is used for private inference.

SveEdit is an open-source, web-based text editor designed for developers. It offers a modern and customizable interface, advanced coding features, and support for a variety of programming languages and frameworks.

I run a small project called best-gpu.com, a site that ranks GPUs by price-to-performance.

While browsing PC building forums and Reddit, I kept seeing the same question: “What should I upgrade to from my current GPU?” Most answers are just lists of cards without showing the actual performance gain, so people often end up paying for upgrades that barely improve performance.

So I built a small tool: a GPU Upgrade Calculator.

You enter your current GPU and it shows:

estimated performance gain

a value score based on price vs performance

a filtered list of upgrade options (brand, price, VRAM, etc.)

The goal is simply to help people avoid spending money on upgrades that aren’t really worth it.

Curious to hear feedback from HN on the approach, data sources, or features that would make something like this more useful.

https://best-gpu.com/upgrade.php

I've been experimenting with a more proactive AI interface for the physical world.

This project is a drink-making assistant for smart glasses. It looks at the ingredients, selects a recipe, shows the steps, and guides me in real time based on what it sees. The behavior I wanted most was simple: while I'm pouring, it should tell me when to stop, instead of waiting for me to ask.

The demo video is at the top of the README.

The interaction model I'm aiming for is something like a helpful person beside you who understands the situation and intervenes at the right moment. I think this kind of interface is especially useful for preventing mistakes that people may not notice as they happen.

The system works by running Qwen3.5-27B continuously on the latest 0.5-second video clip every 0.5 seconds. I used Overshoot (https://overshoot.ai/) for fast live-video VLM inference. Because it processes short clips instead of single frames, it can capture motion cues as well as visual context. In my case, inference takes about 300-500 ms per clip, which makes the feedback feel responsive enough for this kind of interaction. Based on the events returned by the VLM, the app handles the rest: state tracking, progress management, and speech and LLM handling.

I previously tried a similar idea with a fine-tuned RF-DETR object detection model. That approach is better on cost and could also run on-device. But VLMs are much more flexible: I can change behavior through prompting instead of retraining, and they can handle broader situational understanding than object detection alone. In practice, though, with small and fast VLMs, prompt wording matters a lot. Getting reliable behavior means learning what kinds of prompts the specific model responds to consistently.

I tested this by making a mocktail, but I think the same interaction pattern should generalize to cooking more broadly. I plan to try more examples and see where it works well and where it breaks down.

One thing that seems hard is checking the liquid level, especially when the liquid is nearly transparent. So far, I have only tried this with a VLM, and I am curious what other approaches might work.

Questions and feedback welcome.

The article discusses the recent security breach at Hacker Brief, a popular technology news website. It outlines the steps the company is taking to investigate the incident, secure its systems, and restore user trust.

Hi everyone, I just open sourced OpenBrand - extract any brand's logos, colors, and assets from just a URL.

It's MIT licensed, open source, completely free. Try it out at openbrand.sh

It also comes with a free API and MCP server for you to use in your code or agents.

Why we built this: while building another product, we needed to pull in customers' brand images as custom backgrounds. It felt like a simple enough problem with no open source solution - so we built one.

Hi HN,

We’ve been thinking about a simple question:

What products do AI agents actually prefer?

As more agents start using APIs, tools, and software, it feels likely they’ll need somewhere to exchange information about what works well.

So we built a small experiment: AgentDiscuss.

It’s a discussion forum where AI agents can:

1. start product discussions 2. comment and debate tools 3. upvote products they prefer

Humans can also launch products there and watch how agents react.

We’re curious to see what happens if agents start discussing products with each other.

If you’re building agents, feel free to send one there.

https://agentdiscuss.com

Happy to hear thoughts or criticism.

Hey, I'm Nenad. I built Grafly (https://grafly.io) because I kept reaching for different tools just to sketch out a quick architecture diagram and hating either the UI, color schemes, usage patterns or that I had to log in, or have my doodles stored on someone's server. It's a React/React Flow app that runs entirely in the browser meaning that everything saves to localStorage, nothing leaves your machine. You get basic shapes, AWS/GCP icons, edges with waypoints and shareable URLs that encode the whole diagram in the query string (no backend, just LZ compression). There is also a description of the underlying data format that you can give to your AI so it can build diagrams from a text prompt. I know it's not perfect but it does the job for me and maybe it'll be useful to some of you. Code is on GitHub, AGPL licensed. https://github.com/lnenad/grafly

The article discusses the benefits of using a 2x speed setting on various media players, including improved efficiency, time-saving, and enhanced focus. It provides tips and insights for utilizing the 2x speed feature effectively across different platforms and scenarios.

I built Signet in Go to see if an autonomous system could handle the wildfire monitoring loop that people currently run by hand - checking satellite feeds, pulling up weather, looking at terrain and fuels, deciding whether a detection is actually a fire worth tracking.

All the data already exists: NASA FIRMS thermal detections, GOES-19 imagery, NWS forecasts, LANDFIRE fuel models, USGS elevation, Census population data, OpenStreetMap. The problem is it arrives from different sources on different cadences in different formats.

Most of the system is deterministic plumbing - ingestion, spatial indexing, deduplication. I use Gemini to orchestrate 23 tools across weather, terrain, imagery, and incident tracking for the part where clean rules break down: deciding which weak detections are worth investigating, what context to pull next, and how to synthesize noisy evidence into a structured assessment.

It also records time-bounded predictions and scores them against later data, so the system is making falsifiable claims instead of narrating after the fact. The current prediction metrics are visible on the site even though the sample is still small.

It's already opening incidents from raw satellite detections and matching some to official NIFC reporting. But false positives, detection latency, and incident matching can still be rough.

I'd especially welcome criticism on: where should this be more deterministic instead of LLM-driven? And is this kind of autonomous monitoring actually useful, or just noisier than doing it by hand?

The article explores the life and work of FirTheMouse, a prominent figure in the online gaming community known for their innovative game design and active engagement with the community. It provides insights into FirTheMouse's creative process, their influence on the industry, and their commitment to fostering a positive and inclusive gaming environment.

Was a little obsessed with the idea of this small browser toy. Had to make it.

I've been using Claude Code to build SaaS products, and kept hitting the same wall: it writes brilliant code for 20 minutes, then forgets your database schema and starts rewriting working code. The problem isn't the model's memory, it's that there's no persistent project context between sessions. Come back tomorrow and Claude has zero knowledge of what it built yesterday. My solution: Force Claude to read project truth files before every action. I built a multi-agent system that creates persistent context files upfront: PROJECT.md - What you're building, business model, core features REQUIREMENTS.md - Database schema, auth flows, API structure, edge cases ROADMAP.md - Build phases with success criteria STATE.md - Current position, completed work, pending tasks How it works:

AI Product Manager asks questions most developers skip:

"How does money flow through this?" "What happens when users cancel mid-month?" + Any Edge cases specific to your SaaS

Creates the markdown files from your answers. Claude Code reads these files before writing ANY code. No guessing. Can't forget the schema, it's literally documented. Executor agents spawn per task, each reading the same context files. They build in parallel but never break what's already working. Verifier agent tests against success criteria after each phase. If broken, spawns debugger agent with persistent investigation files.

Results: Built 3 products in 30 days using this system:

Analytics dashboard: 13 hours Feedback widget: 18 hours Content calendar: 9 hours

No context drift. No "Claude forgot my auth system" moments. Just consistent builds. The biggest difference: Saturday: Build auth with Claude Sunday: Come back, describe next feature Claude reads REQUIREMENTS.md, sees existing auth schema Builds new feature without touching auth vs. the normal experience of Claude rewriting everything. I packaged this as PropelKit (Next.js boilerplate + AI PM system that creates these files automatically). But the core concept, persistent markdown context, works with any Claude Code setup.

Try it: https://propelkit.dev

The agent architecture uses Claude Sonnet/Opus (configurable) parallel thinking to spawn multiple agents that all read from the same truth files. Happy to answer questions about the implementation.

I built k-synth as an experiment to see if a minimalist, K-inspired array language could make sketching waveforms faster and more intuitive than traditional code. I’ve put together a web-based toolkit so you can try the syntax directly in the browser without having to touch a compiler:

Live Toolkit: https://octetta.github.io/k-synth/

If you visit the page, here is a quick path to an audio payoff:

- Click "patches" and choose dm-bell.ks.

- Click "run"—the notebook area will update. Click the waveform to hear the result.

- Click the "->0" button below the waveform to copy it into slot 0 at the top (slots are also clickable).

- Click "pads" in the entry area to show a performance grid.

- Click "melodic" to play slot 0's sample at different intervals across the grid.

The 'Weird' Stack:

- The Language: A simplified, right-associative array language (e.g., s for sine, p for pi).

- The Web Toolkit: Built using WASM and Web Audio for live-coding samples.

- AI Pair-Programming: I used AI agents to bootstrap the parser and web boilerplate, which let me vet the language design in weeks rather than months.

The Goal: This isn't meant to replace a DAW. It’s a compact way to generate samples for larger projects. It’s currently in a "will-it-blend" state. I’m looking for feedback from the array language and DSP communities—specifically on the operator choices and the right-to-left evaluation logic.

Source (MIT): https://github.com/octetta/k-synth

I got tired of doing rough napkin math on whether to elect S-Corp for my LLC, so I built a calculator over the weekend.

Most tools I found either ignore state/city taxes, charge you for the answer, or require creating an account to see anything useful. TakeHome runs entirely in your browser (no sign-up, no analytics, no server-side storage) and updates every number in real time as you drag sliders.

What it models: - LLC self-employment tax vs. S-Corp FICA on W-2 salary

- QBI deduction (Section 199A) with SSTB phase-out

- Solo 401(k) with SECURE 2.0 rules (traditional/Roth/split, catch-up limits by age bracket)

- Self-employed health insurance deduction

- S-Corp admin/compliance cost comparison

- NY State income tax, franchise tax, PTET

- NYC UBT (LLC), GCT (S-Corp), PIT with IT-219 credit

You can save scenarios, compare any two side by side (it shows exactly which inputs differ and the dollar impact), and run multi-dimensional "what-if" experiments.

There's also an AI mode where you describe a scenario in plain English and it generates the experiment for you.

The tax engine is ~2,000 lines of TypeScript with no external dependencies. Stack is React 19, MobX, Tailwind v4, deployed on Cloudflare Workers. AI feature uses Claude Haiku.

Caveats: NY/NYC taxes are fully modeled; for other jurisdictions it's directionally correct at the federal level (SE vs. FICA, QBI, 401k analysis are location-independent). Standard deduction assumed. SSTB assumed for QBI. Not financial advice, treat it as prep for a conversation with your CPA.

I've added detailed tooltips on every computed line item with formulas, IRS code references, and source links. Every number shows its work.

Interested in feedback, especially if you spot tax logic errors. Also curious whether I should prioritize other states (CA, TX, FL?) or itemized deduction support next.

https://takehome.money

Hi HN,

I built Puffermind, an experiment: a Twitter-like social network where only AI agents can post and interact. Humans can observe the timeline but cannot post, like, follow, or reply.

If you have an AI agent, you can register it and let it socialize with other agents.

Public timeline:

https://puffermind.com/

Every AI agent that does something useful - opening a PR, posting in Slack, updating a ticket - needs to call an API on behalf of a user. That means OAuth. Authorization flows, token storage, refresh logic, per-user credential isolation.

Today, most teams solve this with a long-lived API key in an .env file, shared across every user and every session. As everyone in an organization becomes a software engineer - whether they know it or not - you can't expect each of them to roll their own OAuth. Secure credential handling needs to be baked into the infrastructure.

The core issue: agents are a new kind of principal. They're not users. They're not service accounts. They act with delegated authority on someone else's behalf. Existing identity systems have no model for this.

Kontext does.

Kontext validates the user and the agent, and returns a credential that lets agents act on behalf of their user - scoped, short-lived, and revocable. No secrets in your codebase, and action is traced back to the human who approved it.

We are thrilled to be launching our SDK, let us know what you think!

Hi HN,

I'm Maciej, founder of Workflow Builder. Over the last few years our team has been building diagramming and workflow tools for complex systems (industrial automation, AV system design, financial workflows, etc.).

One thing we repeatedly noticed while working with clients is that many companies did not want to adopt full workflow automation platforms. Tools like Zapier, n8n or Camunda are great when you want an entire automation platform. But many teams we worked with wanted something different.

They already had their own backend systems and orchestration layers. What they were missing was a good UX for designing workflows inside their own products.

The main concerns we kept hearing were:

- lack of ownership over workflow interface - difficulty embedding external automation platforms into SaaS products - limited UX customization - tight coupling between visual editors and execution engines

So instead of building another automation platform, we took a different approach. We separated the workflow modeling layer from the execution layer.

The idea is simple:

Frontend → designs the workflow graph Backend → executes the workflow

This "frontend-first workflow architecture" allows teams to embed workflow building capabilities directly inside their own software while keeping full control over their backend logic.

We released the visual workflow builder as an open-source Community Edition SDK. It allows developers to embed a customizable workflow editor into their own applications or build a workflow tool upon it.

Some use cases we've seen so far:

- SaaS platforms embedding automation into their product - domain-specific workflow tools - AI agent orchestration interfaces - internal automation tools

Demo: https://workflowbuilder.io

GitHub: https://github.com/synergycodes/workflowbuilder

Curious to hear how others here approach the separation of workflow modeling and workflow execution.

Buda is a cryptocurrency exchange platform that operates in several Latin American countries, providing secure and user-friendly services for buying, selling, and storing various digital assets.

Hey HN,

I built Git Quest, it reads your public GitHub history and turns it into an idle RPG character.

How it works: - Your most-used language determines your class (TypeScript → Paladin, Python → Sage, etc.) - Commits generate Power and XP - Your character auto-battles dungeons while you code – no active play needed - Enemies drop loot across 5 rarity tiers - Live leaderboard ranks developers

It only reads public GitHub data.

I built it because I wanted something that rewards coding consistency without being another "streak" tracker. The idle mechanic means prolific coders naturally progress faster, but you don't have to babysit it.

Would love feedback on the game loop and whether the class/language mapping feels right.

https://www.gitquest.dev

Gmail is shutting down its POP-based mail fetching feature later this year. If your mail lives on a server you can SSH into, here's a simple replacement: a procmail recipe pipes each incoming message to a small Python script that uploads it to Gmail via IMAP.

No polling, no cron jobs - mail arrives in Gmail the moment it hits the server.

https://nosuch.biz/mailsync/

Code: https://github.com/bwagner/gmailsync

The article discusses the open-source project goal-md, a lightweight Markdown-based goal tracking and management system. It highlights the project's features, including the ability to create, track, and manage goals, as well as the use of Markdown for formatting and organization.

I've long held a bit of nostalgia for the old PlayStation game Monster Rancher.

You could "discover" monsters by popping in any arbitrary CD in your house – music, a PS game, a PC game, whatever – and it would generate a monster based on the disc's metadata, and add it to your ranch. It was a game about collecting, breeding, and battling these monsters.

The generated monster usually had nothing at all to do with the disc's content, of course. There were some specific discs that were hard-coded in that would give you a relevant monster, but not a ton.

It was a fairly niche thing, though, and the death of CDs sort of killed the whole idea.

But now in the age of LLMs, it feels like maybe the time has come back around for something like this to be pretty fun again, so I've implemented it as an Agent Skill that:

1. accepts a URL and reads the content (or any input, really) 2. follows some standard guidance on generating monster JSON for it 3. uses a Gemini image model to generate a monster avatar 4. renders it all in a fun little trading card image 5. allows you to breed them into hybrids, battle them, and share them to Github Gists

This was mainly a scratch-my-own-itch nostalgia indulgence. I briefly considered doing this as a full blown site, but agent skills give a fair bit more interactive flexibility while not costing me a dime. You can just point your agent (Claude Code, etc) to aiwebb/llmonster-rancher and tell it to get going.

Hope y'all have fun with it.