Rubiks Cube Solver
Speedcube is an open-source platform for speedcubers featuring a Rubik's Cube solver, competition timer, algorithm library, and AI-assisted cube recognition directly in the browser. Built with React, TypeScript, Rust, and Python, the project aims to become an all-in-one platform for cubers—from beginners to competitive solvers. http://github.com/williamisnotdefined/rubiks-cube-solver/
We beat Cloudflare's bot detection (open-source stealth browser)
Show HN: We beat Cloudflare's bot detection (open-source stealth browser)
Learn by rebuilding Redis, Git, a database from scratch
Show HN: Learn by rebuilding Redis, Git, a database from scratch
Ant
Hello HN! I'm the author of Ant, a JavaScript ecosystem built around a runtime with its own JavaScript engine. Ant also includes a package manager, the ants.land package registry, a platform for deploying and hosting applications, and Ant Desktop for building native desktop apps with web technologies, similar to Electron. The goal is for these pieces to work as one coherent platform while remaining compatible with the wider JavaScript ecosystem. It's still early, and I'd appreciate any feedback on the overall direction or what you'd like to see from an e2e alternative to the existing JavaScript stacks. P.S. I’ve shared Ant here before as a runtime; since then, it has grown into the broader ecosystem you see today.
Kurvengefahr
A few years ago I made a pen plotter attachment for Prusa MK4 (https://www.printables.com/model/827264-pen-plotter-attachme...) and at the time I didn't have a good way to turn artwork into G-code for it, and I put the project on ice for a while. I recently wanted to dabble in line art again and made a small browser app to make it easier. As agentic AI tools of 2026 are quite addictive, it rather quickly grew into something quite a bit more - an integrated browser CAD/CAM for pen plotters that covers everything from importing existing artwork, creating artwork from scratch, preparing for plotting and hardware integration. It includes some off-beat features like a Logo interpreter for turtle art and Graves RNN for handwriting synthesis and in addition to 3D printer pretending to be pen plotters it now also supports actual pen plotters based on EBB (AxiDraw) and GRBL firmwares through Web Serial. If you own an AxiDraw or a GRBL plotter, I'd very much appreciate it you gave it a try and give feedback. As I don't own those, I did all the testing with a hardware mock on STM32, so I am not sure how well it works attached to an actual plotter. Source code and docs are on GitHub: https://github.com/tibordp/kurvengefahr
ZenStack
Hi HN, I'm Jiasheng, co-creator of ZenStack. Access control usually ends up scattered across app code instead of living with the data model — and that's riskier when the code is written by an agent, since it's easy to ship a query with a missing or incomplete authorization check. ZenStack enforces policy (RBAC/ABAC/relation-based) directly at the ORM layer, on top of Kysely, so every query gets checked the same way regardless of who wrote it and who is calling it. Postgres RLS is an option too, but it's hard to maintain and scale, and it's Postgres-only — ZenStack's approach is database-agnostic. One of our users, MermaidChart, put it well after launching their team feature on ZenStack: "much cleaner and easier to maintain than writing RLS policies or application-level checks that will surely leak after some time." Happy to answer anything.
Coasty
Hey HN, we’re Nitish and Prateek, the founders of Coasty (https://coasty.ai/computer-use). We’re building computer-use agents that can complete workflows inside legacy desktop software and web applications without usable APIs. Developers send Coasty a natural-language task either through our consumer app or through our API, select a machine or browser environment, and any relevant credentials or files. The agent then operates the interface through screenshots, mouse, and keyboard input, verifies the result, and returns a structured run record with screenshots, actions, outputs, and errors. Here is a raw demo of an agent completing a workflow in a legacy application(It’s a mockup): https://drive.google.com/file/d/1ZghU_3vsAYhHVz1bsvE0pkvZYk7... A lot of important software is still difficult to automate. Healthcare teams submit prior authorizations through payer portals, accounting teams enter data into desktop applications, and operations teams move information between internal systems, spreadsheets, and remote desktops. Many of these applications have no API, incomplete APIs, or integrations that take months to build. The usual alternative is RPA, record a sequence of clicks and replay it. That works when the interface and workflow are predictable, but it often breaks when a button moves, a pop-up appears, a page loads slowly, or the application enters an unexpected state. Coasty takes a different approach. The agent observes the current screen, decides what action to take, executes it, and then observes the resulting state before continuing. It does not require DOM access, an accessibility tree, selectors, or an application-specific integration, so the same API can operate browsers, remote desktops, and older Windows applications. A simplified request looks roughly like this: run = coasty.runs.create( environment="vm_123", task=""" Open the patient record in the billing portal. Enter the attached authorization data. Do not submit if the member ID or procedure code does not match. Return the confirmation number. """, files=["authorization.pdf"], approval_required=["final_submission"] ) The response includes the final status, extracted outputs, a replay URL, and a timestamped event log: { "status": "completed", "output": { "confirmation_number": "PA-184392" }, "replay_url": "...", "events": [ { "type": "verification", "field": "member_id", "result": "matched" } ] } The API can also pause a run for human approval, retry from a checkpoint, or return control to the developer when it encounters a condition the workflow did not anticipate. We started working on this last summer, because we saw that models were getting better at vision but kept seeing a gap between computer-use demos and the reliability needed for production workflows. Getting an agent to complete a task once is fairly straightforward. Getting it to repeat that task, recover from unexpected states, avoid silently entering incorrect data, and produce evidence of what it did is much harder. We built several layers around the underlying computer-use model. The system tracks the expected state of the workflow, detects when the application has diverged from that state, and can re-plan instead of continuing blindly. Developers can define invariants such as “the patient name must match the source document” or “never submit without approval,” and the agent checks those conditions during the run. Each run happens in an isolated virtual machine. We expose APIs for provisioning environments, uploading files, starting tasks, streaming events, inserting human approvals, and retrieving the full replay and audit trail. Environments can be kept alive across runs when the application has a long login flow or persistent local state. One problem we are still working through is the tradeoff between speed and reliability. The agent can move faster by taking fewer observations and verification steps, but that becomes risky in workflows involving patient records, payments, or regulatory filings. We currently bias toward slower execution with more checks and let developers configure approval points and verification policies. We are initially working with healthcare operations teams because their workflows combine many of the hardest conditions: payer portals, EHRs, PDFs, spreadsheets, remote desktops, and actions where quiet mistakes are expensive. We also expose the same infrastructure through the developer API for teams building their own agents and vertical automation products. We currently charge based on agent runtime and workflow volume, with separate pricing for dedicated environments and enterprise deployments. We’d especially appreciate feedback from people who have built and/or used browser agents, RPA systems, desktop automation, or agent infrastructure. We’re curious which parts of the API you would want direct control over, where you would prefer higher-level abstractions, and which failure modes have been hardest in your own automation systems. If you've hit weird failure modes automating software like this, we want to hear about them. We'll be here all day answering questions and taking notes!
Firefox in WebAssembly
This is the entire Firefox browser rendering to a <canvas> element. Gecko, all UI components, and the Spidermonkey JS engine are all compiled and running in WebAssembly. Here are a few things you might find interesting: - This is fully end to end encrypted! We use the WISP protocol for TCP-over-websockets. - There is a novel WASM->JS JIT for experimental site speedup - This port cost over 25k in opus/fable tokens for debugging and JIT research This was just a fun experiment to push the boundaries of WebAssembly. For a more usable "browser in browser" experience, we also built https://github.com/HeyPuter/browser.js that eats a bit less RAM.
AI Law Tracker
Show HN: AI Law Tracker – one audited API for US, EU and global AI law
Sentinel
Show HN: Sentinel – open-source QA agent that reads your code before it clicks
Mojibake
I've written Mojibake because I don't like the other Unicode libraries for Unicode support. It consists of only two amalgamation files: mojibake.h and mojibake.c. I've added all the most important Unicode algorithms, such as normalization, case conversion, segmentation, bidirectional text, collation, confusable, and others. I regularly test it in these OSes: Linux, macOS, FreeBSD, OpenBSD, NetBSD, and Windows 11. You can find a WASM demo on that site of all the public API functions and the documentation. If you want to participate, feel free to do it. Any kind of help is welcome. Check the CONTRIBUTING.md and API.md files in the GitHub repository for instructions on how to do it.
Libretto PR agents
Libretto PR agents is a free TypeScript library for maintaining Playwright browser automations. Add one line of code to your existing Playwright scripts and it lets an agent automatically open GitHub PRs fixing the script when it fails. A few months ago we released Libretto, a CLI + coding-agent skill for building deterministic browser automations. The idea was that for many browser workflows, especially repetitive business workflows, you don’t need an AI agent making decisions at runtime. You want deterministic Playwright scripts that are inspectable, faster to run, and much cheaper than repeatedly calling an AI browser agent. That helped us generate Playwright and network-request-based scripts, but websites can often change which breaks deterministic scripts. So maintaining a variety of scripts at scale is a headache. If you already have a bunch of functioning Playwright scripts, the last thing you want is to rewrite everything around a new runtime AI framework like browser-use or stagehand just to make maintenance easier. The Libretto PR Agent pulls your code from GitHub and connects via CDP to the browser session that just failed. It has an exec tool for injecting Playwright and javascript into the page, and once its inspected the failure, it opens a PR to your repo with a proposed code fix. You use it like this: try { await automationLogic(page); } catch (error) { await playwrightDebugger.debugFailure(error, page); throw error; } The agent is completely free and open source, lets you bring your own LLM provider API keys, and works with any browser provider (including self hosted). The source code is here: https://github.com/saffron-health/libretto/tree/main/package... We think this makes browser integrations much easier to maintain, especially for teams that already have Playwright browser automation scripts in production and don’t want a full migration to get AI-assisted debugging and repair. If you’re maintaining browser automations in production, would love to know what your debugging flow is currently and any feedback on this approach.