Spice simulation → oscilloscope → verification with Claude Code
I built MCP servers for my oscilloscope and SPICE simulator so Claude Code can close the loop between simulation and real hardware.
A visual CI/CD system
Over a year ago I started Actionforge, a managed/self-managed visual CI/CD platform. Just for fun, because I like building and experimenting with dev tools. Back then I thought the user would be a human with a keyboard and a mouse. These days I rarely write pipelines. I mostly write specs, an agent dumps 500 lines of YAML, Python and a Makefile then I get my artifacts. The amount is overwhelming and a liability, and I stop trusting what I just merged. So I pivoted my CI/CD project toward more visualization, analytics and data aggregation, so engineers can see what agents and the pipeline produced, the flow, steps, data. Where it fails. With that I have a better mental model instead of a blob of code. The goal is better observability, and pipelines that explain their own failures back to the next agent. And also with a personal focus on UX and design. My project supports Perforce P4, Git/GitHub and GitLab, so quite flexible. Would love to hear your impression. I'm also very interested in your CI/CD horror stories, and how you use them these days. Any input is much appreciated! P.S. Code is public and provides GitHub Attestations.
I've built a nice home server OS
ohai! I've released Lightwhale 3, which is possibly the easiest way to self-host Docker containers. It's a free, immutable Linux system purpose-built to live-boot straight into a working Docker Engine, thereby shortcutting the need for installation, configuration, and maintenance. Its simple design makes it easy to learn, and its low memory footprint should make it especially attractive during these times of RAMageddon. If this has piqued your interest, do check it out, along with its easy-to-follow Getting Started guide. In any event, have a nice day! =)
Agent MCP Studio
I built a browser-only studio for designing and orchestrating MCP agent systems for development and experimental purposes. The whole stack — tool authoring, multi-agent orchestration, RAG, code execution — runs from a single static HTML file via WebAssembly. No backend. The bet: WASM is a hard sandbox for free. When you generate tools with an LLM (or write them by hand), the studio AST-validates the source, registers it lazily, and JIT-compiles into Pyodide on first call. SQL tools run in DuckDB-WASM in a Web Worker. The built-in RAG uses Xenova/all-MiniLM-L6-v2 via Transformers.js for on-device embeddings. Nothing leaves the browser; close the tab and the stack is gone. The WASM boundary is what makes it safe to execute LLM-generated code locally — no Docker, no per-tenant container, no server. Above the tool layer sits an agentic system with 10 orchestration strategies: - Supervisor (router → 1 expert) - Mixture of Experts (parallel + synthesizer) - Sequential Pipeline - Plan & Execute (planner decomposes, workers execute) - Swarm (peer handoffs) - Debate (contestants + judge) - Reflection (actor + critic loop) - Hierarchical (manager delegates via ask_<persona> tools) - Round-Robin (panel + moderator) - Map-Reduce (splitter → parallel → aggregator) You build a team visually: drag tool chips onto persona nodes on a service graph, pick a strategy, and the topology reshapes to match. Each persona auto-registers as an MCP tool (ask_<name>), plus an agent_chat(query, strategy?) meta tool. A bundled Node bridge speaks stdio to Claude Desktop and WebSocket to your tab — your browser becomes an MCP server. When you're done, Export gives you a real Python MCP server: server.py, agentic.py, tools/*.py, Dockerfile, requirements.txt, .env.example. The exported agentic.py is a faithful Python port of the same orchestration logic running in the browser, so the deployable artifact behaves identically to the prototype. Also shipped: Project Packs. Export the whole project as a single .agentpack.json. Auto-detects required external services (OpenAI, GitHub, Stripe, Anthropic, Slack, Notion, Linear, etc.) by scanning tool source for os.environ.get(...) and cross-referencing against the network allowlist. Recipients get an import wizard that prompts for credentials. Manifests are reviewable, sharable, and never carry secrets. Some things I'm honestly uncertain about: - 10 strategies might be too many. My guess is most users only need Supervisor, Mixture of Experts, and Debate. Open to data on which ones actually pull weight. - Browser cold-starts (Pyodide warm-up on first load) are a real UX hit despite aggressive caching. - bridge.js is the only non-browser piece. A hosted variant is the obvious next step. Built with Pyodide, DuckDB-WASM, Transformers.js, OpenAI Chat Completions (or a local Qwen 1.5 0.5B running in-browser via Transformers for fully offline mode). ~5K lines of HTML/CSS/JS in one file. https://www.agentmcp.studio Genuinely curious whether running this much LLM-generated code in a browser tab feels reasonable to you, or quietly terrifying.
Limen
I built and released Limen v0.1.0: https://github.com/thecodearcher/limen Writeup/docs: https://limenauth.dev/blog/introducing-limen It’s inspired by better-auth’s plugin-first DX, but designed for idiomatic Go. The core handles sessions/cookies/security primitives, and auth methods are composed as plugins (credential auth, OAuth providers, and 2FA today). It exposes an http.Handler, so it works with plain net/http and frameworks like Gin/Echo/Chi/Fiber without framework lock-in. This is the first public release. I’d really appreciate feedback.
Startup Equity Adventure Game
I put this together (with Claude) as a semi-gamified way for folks to learn about startup equity. Take a look, and share your scorecard :)
Omar
We were both genuinely impressed by Claude Code after it helped each of us fix nasty CI problems overnight. Doing those fixes manually would have taken days. After that experience, we each found ourselves struggling through Ctrl+Tab through multiple Claude Code windows in our terminals. While we enjoyed having agents working for us in parallel, context switching and cycling through each terminal tab was a real pain. So we thought: Can we design a TUI dashboard that manages a large swarm of agents in one place? Even better, can agents manage agents hierarchically, like how companies work? OMAR (Open Multi-Agent Runtime) is the result of this exploration. We spent months building it, and we think it is now ready to show the world. If you find OMAR interesting, give it a try. We would love to hear from you. :) Check out our blog here for more details: https://omar.tech/blog/introducing-omar/ Thanks! Karim & Shaokai
Mljar Studio
Hi HN, I’ve been working on mljar-supervised (open-source AutoML for tabular data) for a few years. Recently I built a desktop app around it called MLJAR Studio. The idea is simple: you talk to your data in natural language, the AI generates Python code, executes it locally, and the whole conversation becomes a reproducible notebook (*.ipynb file). So instead of just chatting with data, you end up with something you can inspect, modify, and rerun. What MLJAR Studio does: - Sets up a local Python environment automatically, runs on Mac, Windows, and Linux - Installs missing packages during the conversation - Built-in AutoML for tabular data (classification, regression, multiclass) - Works with standard Python libraries (pandas, matplotlib, etc.) - Works with any data file: CSV, Excel, Stata, Parquet ... - Connects to PostgreSQL, MySQL, SQL Server, Snowflake, Databricks, and Supabase. For AI: use Ollama locally (zero data egress), bring your own OpenAI key, or use MLJAR AI add-on. I built this because I wanted something between Jupyter Notebook (flexible but manual) and AI tools that generate code but don’t preserve the workflow. Most tools I tried either hide too much or don’t give reproducible results and are cloud based Demos: - 60-second demo: https://youtu.be/BjxpZYRiY4c - Full 3-minute analysis: https://youtu.be/1DHMMxaNJxI Pricing is $199 one-time, with a 7-day trial. Curious if this is useful for others doing real data work, or if I’m solving my own problem here. Happy to answer questions.
Explore color palettes inspired by 3000 master painter artworks
I built PaletteInspiration.com, a browsable archive of color palettes pulled from artworks by 3,000+ master painters (Monet, Vermeer, Raphael, Van Gogh). Why I built it: every color palette generator I tried converged on the same five muted pastels. Painters spent centuries figuring out color and we mostly ignore that body of work when picking colors for digital design. Please share your feedback on the Color Harmony Explorer - drag the wheel to any color and it shows which hues master painters historically paired with it (not only standard complementary, analogous, triadic, etc.) It is solely based on co-occurrence across thousands of real paintings. Not algorithmic color theory rules - actual empirical pairings. No signup, no paywall, no email capture. Just curious what people think.
Mochi.js: bun-native high-fidelity browser automation library
Hi HN, I’m sharing mochi.js (https://github.com/0xchasercat/mochi), a Bun-native, raw-CDP browser automation framework. It's designed to make programmatic browser use more effective by focusing on consistency and measured parity with regular traffic, purely from the JS layer, against stock Chromium. The most common forms of browser automation focus heavily on client-side line by line probes, which are mostly cosmetic. This makes people feel better but it doesn't have much relevance to actual WAF or anti-automation defences. Mochi.js focuses on what actually matters, allowing you to get past captchas, WAF's and most defence mechanisms. In fact, in some cases it actually outperforms chromium forks simply by virtue of not having to lie. The foundation is built on a probe manifest based on analyzing several WAF's and trying to cover most of the ground that matters, and from there building upwards while ensuring every decision is backed by data. Solves turnstile/interstitial automatically, single digit fpjs suspect score, very good client-side results, though browserscan and a few others are known limitations that are fundamentally conflicting with what WAF's probe for. I'll be here if anyone wants to discuss the details, check out the docs and github. It's completely free and open source, MIT, strictly no relationship to any proprietary products whatsoever. No affiliation to patched chromium forks, or SaaS. But I also want to talk about why I built this, because the current paradigm of "bot detection" is fundamentally broken. Traditionally they would probably try to label my repository a malicious tool, or at best, a grey hat one. Let's take Turnstile for example, If you attach a debugger to see what data they are extracting from your hardware, their script intentionally self-destructs. When they try to extract your data—acting as a guest on your silicon, using your electricity, without asking, the industry calls it "Security." But if you write a script to control exactly what data your own hardware emits, refusing to provide the data they have no right to ask for, you are suddenly labeled a "Malicious Actor" engaged in "Bot Evasion." I find it absurd we let ourselves put up with this, and the stance of the bot-evasion community only makes them feel more able to take a higher moral ground. I have built a library that respects my hardware's reality. If that breaks your security model, that's because your security model relies on trespassing and secrecy. I stopped apologizing. Who's next? Mochi is the exact opposite of WAF opacity. It is a glass box. It is MIT-licensed. The entire DAG, fingerprint manifest schema, harvesting process, is documented. We even commit our live benchmarks to the public record (mochi on a Linux datacenter IP scored a suspect_score: 8 and bot: not_detected against FingerprintJS Pro v4). We don't even lie unnecessarily. We default to host-OS matching. If you run mochi on a Linux server, it uses privacy-sensible fingerprints for Linux, not Windows, because Linux is a real-user signal. It proves that WAFs aren't actually blocking what most people think they are, which begs the question of what they are really doing in that obfuscated payload. The legitimacy argument is exactly how they captured the narrative. And nobody challenged it because the people on the other side were too busy acting like they were doing something wrong. Is this a conspiracy theory? For sure, but only because they allow it to be. Try make a conspiracy theory about the sticky riceball.
An index of indie web/blog indexes
I saw a comment here about how there are so many indexes of indie sites, blogs, etc but there wasn't an index of all the indexes. So I built it. It doesn't require a log in, just go browse! I've curated about 30 or so, but there is a submission form if there are ones I am missing. Also happy to take UI improvements because I am not great in that area!
Personal Trainer
Hi HN, I'm an indie dev who built this to settle a long-running argument with my teenage son about who lifts more at the gym. I wanted a workout tracker to kept our data side-by-side on a leaderboard, and let us swap training plans without texting screenshots back and forth. Nothing I tried did all three without a subscription wall, so I wrote my own. Most of the app is free, it covers the full workout experience and progress tracking with 80+ exercises. The one-time purchase unlocks multiple plans, custom movements, and the social/sharing features, mainly to pay for the infra. The mobile app is React Native via Expo with Expo Router, NativeWind for styling, Zustand for state (every store is user-scoped via an AsyncStorage key prefix so account switches do a clean rehydrate, good way to have several using using the same app), Reanimated for animations, and react-i18next across six locales. The core workout loop is fully offline, and a Firebase layer sits on top for optional cross-device sync and the social features. Backend is a small workspace of Firebase Cloud Functions v2 that handle cross-user fan-out (friend requests, shared plans, shared movements) with rate limiting and anti-spam in Firestore triggers. Published a few weeks ago, I can proudly but surprisingly see the daily usage increasing. This is my first mobile app since a while (was doing some 10+y ago), keen for any feedback since it gave me the excitement of building some more. Android only for now, iOS to be published soon.