Show stories

Hey HN, Waleed here. We're building Sim (https://sim.ai/), an open-source visual editor to build agentic workflows. Repo here: https://github.com/simstudioai/sim/. Docs here: https://docs.sim.ai.

You can run Sim locally using Docker, with no execution limits or other restrictions.

We started building Sim almost a year ago after repeatedly troubleshooting why our agents failed in production. Code-first frameworks felt hard to debug because of implicit control flow, and workflow platforms added more overhead than they removed. We wanted granular control and easy observability without piecing everything together ourselves.

We launched Sim [1][2] as a drag-and-drop canvas around 6 months ago. Since then, we've added:

- 138 blocks: Slack, GitHub, Linear, Notion, Supabase, SSH, TTS, SFTP, MongoDB, S3, Pinecone, ...

- Tool calling with granular control: forced, auto

- Agent memory: conversation memory with sliding window support (by last n messages or tokens)

- Trace spans: detailed logging and observability for nested workflows and tool calling

- Native RAG: upload documents, we chunk, embed with pgvector, and expose vector search to agents

- Workflow deployment versioning with rollbacks

- MCP support, Human-in-the-loop block

- Copilot to build workflows using natural language (just shipped a new version that also acts as a superagent and can call into any of your connected services directly, not just build workflows)

Under the hood, the workflow is a DAG with concurrent execution by default. Nodes run as soon as their dependencies (upstream blocks) are satisfied. Loops (for, forEach, while, do-while) and parallel fan-out/join are also first-class primitives.

Agent blocks are pass-through to the provider. You pick your model (OpenAI, Anthropic, Gemini, Ollama, vLLM), and and we pass through prompts, tools, and response format directly to the provider API. We normalize response shapes for block interoperability, but we're not adding layers that obscure what's happening.

We're currently working on our own MCP server and the ability to deploy workflows as MCP servers. Would love to hear your thoughts and where we should take it next :)

[1] https://news.ycombinator.com/item?id=43823096

[2] https://news.ycombinator.com/item?id=44052766

https://radar.cloudflare.com/scan/2491878e-d30b-4ab0-9a5a-f3...

Previously was ~540kb, which to be sure wasn't bad, but still felt heavy for a site that's largely text.

The big win was going from Google Analytics to https://umami.is/.

Other pieces in play:

Cookie compliance JS (85kb!) Bootstrap JS & CSS

OP here.

I built this because I recently caught myself almost pasting a block of logs containing AWS keys into Claude.

The Problem: I need the reasoning capabilities of cloud models (GPT/Claude/Gemini), but I can't trust myself not to accidentally leak PII or secrets.

The Solution: A Chrome extension that acts as a local middleware. It intercepts the prompt and runs a local BERT model (via a Python FastAPI backend) to scrub names, emails, and keys before the request leaves the browser.

A few notes up front (to set expectations clearly):

Everything runs 100% locally. Regex detection happens in the extension itself. Advanced detection (NER) uses a small transformer model running on localhost via FastAPI.

No data is ever sent to a server. You can verify this in the code + DevTools network panel.

This is an early prototype. There will be rough edges. I’m looking for feedback on UX, detection quality, and whether the local-agent approach makes sense.

Tech Stack: Manifest V3 Chrome Extension Python FastAPI (Localhost) HuggingFace dslim/bert-base-NER Roadmap / Request for Feedback: Right now, the Python backend adds some friction. I received feedback on Reddit yesterday suggesting I port the inference to transformer.js to run entirely in-browser via WASM.

I decided to ship v1 with the Python backend for stability, but I'm actively looking into the ONNX/WASM route for v2 to remove the local server dependency. If anyone has experience running NER models via transformer.js in a Service Worker, I’d love to hear about the performance vs native Python.

Repo is MIT licensed.

Very open to ideas suggestions or alternative approaches.

I’ve been working on gotui, a modern fork of the unmaintained termui, rebuilt on top of tcell for TrueColor, mouse support, and proper resize handling. It keeps the simple termui-style API, but adds a bunch of new widgets (charts, gauges, world map, etc.), nicer visuals (collapsed borders, rounded corners), and input components for building real dashboards and tools. Under the hood the renderer’s been reworked for much better performance, and I’d love feedback on what’s missing for you to use it in production.

Aulico provides a platform for creating and managing virtual workspaces, allowing users to customize their digital work environment and collaborate with team members remotely.

wget https://github.com/beehive-lab/TornadoVM/releases/download/v... unzip tornadovm-2.1.0-opencl-linux-amd64.zip # Replace <path-to-sdk> manually with the absolute path of the extracted folder export TORNADO_SDK="<path-to-sdk>/tornadovm-2.1.0-opencl" export PATH=$TORNADO_SDK/bin:$PATH

tornado --devices tornado --version

# Navigate to the project directory cd GPULlama3.java

# Source the project-specific environment paths -> this will ensure the source set_paths

# Build the project using Maven (skip tests for faster build) # mvn clean package -DskipTests or just make make

# Run the model (make sure you have downloaded the model file first - see below) ./llama-tornado --gpu --verbose-init --opencl --model beehive-llama-3.2-1b-instruct-fp16.gguf --prompt "tell me a joke"

I built a procedurally generated word-search game where the puzzle never ends - as you scroll, the grid expands infinitely and new words appear. It’s designed to be quick to pick up, satisfying to play, and a little addictive.

The core game works without an account using the pre-defined games, but signing up allows you to generate games using any topic you can think of.

I’d love feedback on gameplay, performance, and whether the endless format feels engaging over time. If you try it, I’d really appreciate any bug reports or suggestions.

Thanks in advance!

Hi HN!

I'm building a JavaScript debugger called Wirebrowser. It combines network inspection, request rewriting, heap snapshots, and live object search.

The main experimental feature is BDHS (Breakpoint-Driven Heap Search): it hooks into the JavaScript debugger and automatically captures a heap snapshot at every pause and performs a targeted search for the value or structure of interest. This reveals the moment a value appears in memory and the user-land function responsible for creating it.

Another interesting feature is the Live Object Search: it inspects runtime objects (not just snapshots), supports regex and object similarity, and lets you patch objects directly at runtime.

Whitepaper: https://fcavallarin.github.io/wirebrowser/BDHS-Origin-Trace

Feedback very welcome, especially on whether BDHS would help your debugging workflow.

The article discusses the author's experience with getting a job at a technology company called 'Hor'. It provides insights into the company's culture, hiring process, and the challenges the author faced during the interview and onboarding stages.

Hey HN! I'm Mert.

I built this because I was frustrated with LLM benchmarks potentially being contaminated by training data. When a model scores 99.9% on MMLU-Pro-Max, we can't tell if that's genuine reasoning or memorization.

Forecaster Arena tries to solve this by testing models on events that haven't happened yet—real prediction markets from Polymarket. The ground truth is reality itself, weeks or months later.

How it works:

7 frontier LLMs (GPT-5.1, Claude Opus 4.5, Gemini, Grok, DeepSeek, etc.) (will be updated) -> Each gets $10k virtual capital weekly -> They bet on 500+ real prediction markets -> Bet size = confidence (larger bet = more confident) -> We measure calibration (Brier score) + returns (P/L)

Currently running first cohort (started Dec 7). First statistically significant analysis expected over the next few weeks.

Everything is open source (MIT): https://github.com/setrf/forecasterarena

Happy to answer questions about the implementation or trade-offs I made. Would be great to hear your feedback on the methodology as well!

Mobile keyboards today are almost entirely based on the 26-key, 3-row QWERTY layout. Here’s a new 2-row, 16-key alternative designed specifically for smartphones.

Built this over the last few days, based on a Rust codebase that parses the latest ALPR reports from OpenStreetMaps, calculates navigation statistics from every tagged residential building to nearby amenities, and tests each route for intersection with those ALPR cameras (Flock being the most widespread).

These have gotten more controversial in recent months, due to their indiscriminate large scale data collection, with 404 Media publishing many original pieces (https://www.404media.co/tag/flock/) about their adoption and (ab)use across the country. I wanted to use open source datasets to track the rapid expansion, especially per-county, as this data can be crucial for 'deflock' movements to petition counties and city governments to ban and remove them.

In some counties, the tracking becomes so widespread that most people can't go anywhere without being photographed. This includes possibly sensitive areas, like places of worship and medical facilities.

The argument for their legality rests upon the notion that these cameras are equivalent to 'mere observation', but the enormous scope and data sharing agreements in place to share and access millions of records without warrants blurs the lines of the fourth amendment.

The article discusses the future of news consumption in 2035, predicting a shift towards more personalized, interactive, and immersive news experiences driven by advancements in technology and user preferences.

Hi HN, I've always been interested in fractals, especially the Mandelbrot and Julia sets. A few years ago I created a 2d viewer of this inherently 4d space. But the other day I decided to ask Claude and GPT how to make this a full RT 3d explorer. A few hours later and this was vibe coded.

To use it you can use the mouse to rotate the fractal the the mouse wheel to zoom in and out. to map from 4d to 3d, one of the dims is mapped to an adjustable slider. the there is also a clipping plane slider to help visualize the internal structures of the fractal.

I have mixed feelings about vibe coding. It was amazing to go from an idea to live implementation within a few hours, but in my coding projects, I've always appreciated the journey and the learning, not just the final product. Vibe coding kind of skips to the end which is exciting and efficient, but just not as fulfilling as struggling through a project step-by-step.

I am a fan of gitk and its simplicity, however as https://github.com/NixOS/nixpkgs/ is getting larger each day, it is becoming almost impossible to use it. I just did a quick test with commit e16041020b082ca847b3658ee1b69f8e6a4323b1 and after a few seconds the memory usage got close to 20GiB and I couldn't click on it (but the UI was still updating). This is probably because gitk tries to eagerly load all commits in memory, works fine for small/medium repositories, but nixpkgs is just too big.

I rarely want to check an old commit (and for that case, I generally don't use gitk anyway), and since I was interested in https://pkg.go.dev/modernc.org/tk9.0 for a while and had a free month of ChatGPT+ to test, I decided to try and vibecode an alternative of gitk writing with Go and modernc.org/tk9.0. So here it is.

The idea here is not to be a full featured replacement for gitk, but to re-implement the things I use. I tried to influence some of the architecture ideas to avoid the performance issues that the original have, so instead of loading all commits in memory it will load it in batches of 1000 (you can increase this using `-limit` flag but I recommend not setting this too high) at a time. Originally I also wanted to use only Go, but in the end I needed to use `git` for a few specific operations to keep it running fast (by default it still uses a pure Go implementation, but building it with `-tags=gitcli` is recommended).

In the end I got what I wanted, a small, self contained app that reproduces most of the features that I want.

I built AlgoDrill because I kept grinding LeetCode, thinking I knew the pattern, and then completely blanking when I had to implement it from scratch a few weeks later.

AlgoDrill turns NeetCode 150 and more into pattern-based drills: you rebuild the solution line by line with active recall, get first principles editorials that explain why each step exists, and everything is tagged by patterns like sliding window, two pointers, and DP so you can hammer the ones you keep forgetting. The goal is simple: turn familiar patterns into code you can write quickly and confidently in a real interview.

https://algodrill.io

Would love feedback on whether this drill-style approach feels like a real upgrade over just solving problems once, and what’s most confusing or missing when you first land on the site.

Hey HN! Like most here regular meetings have always been a big part of my work.

Over the years I've learned the value of active note taking in these meetings. Meaning: not minutes, not transcriptions or AI summaries, but me using my brain to actively pull out the key points in short form bullet-like notes, as the meeting is going on, as I'm talking and listening (and probably typing with one hand). This could be agenda points to cover, any interesting sidebars raised, insights gotten to in a discussion, actions agreed to (and a way to track whether they got done next time!).

It's both useful just to track what's going on in all these different meetings week to week (at one point I was doing about a dozen 1-1s per week, and it just becomes impossible to hold it in RAM) but also really valuable over time when you can look back and see the full history of a particular meeting, what was discussed when, how themes and structure are changing, is the meetings effective, etc.

Anyway, I've tried a bunch of different tools for taking these notes over the years. All the obvious ones you've probably used too. And I've always just been not quite satisfied with the experience. They work, obviously (it's just text based notes at the end of the day) but nothing is first-class for this usecase.

So, I decided to build the tool I've always felt I want to use, specifically for regular 1-1s and other types of regular meetings. I've been using it myself and with friends for a while already now, and I think it's got to that point where I actually prefer to reach for it over other general purpose note taking tools now, and I want to share it more widely.

There's a free tier so you can use it right away, in fact without even signing up.

If you've also been wanting a better system to manage your notes for regular meetings, give it a go and let me know what you think!

I've been frustrated by existing "magic mushroom dosage calculators": most are either visually rough, only handle cubensis, or hard-code one potency value and ignore species, tolerance, and degradation.

So I built Mycodosing.wtf – a research‑informed calculator that tries to do three things better:

Models species‑level potency using psilocybin/psilocin/baeocystin mg/g with separate profiles for truffles (and syntetics!).

Outputs dose ranges (min/median/max) instead of a single magic number, using per‑species uncertainty factors for real‑world variability.

Includes a tolerance model based on 5‑HT2A receptor downregulation (dose‑dependent exponential decay over ~14 days), plus optional weight adjustment and MAOI flag.

The species potencies are pulled and normalized from LC‑MS/MS and classic chemistry papers (e.g., Garcia‑Romeu 2021, Gotvaldová 2021, Gartz/Stríbrný), then wrapped in a neobrutalist UI built with Vite + React. 100% client-side.

I'd love feedback on:

The dose model itself (any flaws in the math or assumptions?) Species data you'd adjust or supplement What you'd want from a v2

Site: https://mycodosing.wtf/ Code: https://github.com/ing-norante/mycodosing.wtf/

800M people use ChatGPT and Claude weekly. Right now they get text responses. Soon they'll get real interfaces: product cards, blog posts, booking flows, payment screens rendered directly in the conversation.

We built an open-source component library for this. Install any block with one command and customize it to your brand.

If you're building MCP servers or experimenting with AI-native apps, this might save you time.

Are you building apps for AI assistants? Would love to hear what's missing in your workflow.

Hey HN,

I’m an ex-Google engineer trying to get back into music production.

I needed a way to sequence my hardware synths using AI contexts without constantly switching windows, so I built this.

It runs entirely in the browser using WebMIDI. No login required. It connects to your local MIDI devices (if you're on Chrome/Edge) and lets you generate patterns.

Tech stack: [React / WebMIDI API / etc].

Link: www.simplychris.ai/droplets

Code is a bit messy, but it works. Feedback welcome.

Driftos.dev is a website that provides tutorials, articles, and resources for developers, with a focus on front-end development, JavaScript, and web technologies. The site offers a range of content, from beginner-friendly guides to advanced topics, to help developers improve their skills and stay up-to-date with the latest trends and best practices.

OP here. I built this library out of frustration with messy, day-to-day data: CSVs with duplicated columns, APIs returning nested JSON, Excel sheets, and various ad-hoc ETL requests.

Tools like Polars and DuckDB are great for heavy analytical workloads, but sometimes I just want a lightweight, Pythonic table I can iterate over. I want the ability to for `row in table:` without surprising semantics.

Serif takes a vector-first, zero-dependency approach aimed at everyday data tasks.

https://github.com/CIG-GitHub/serif

This is an early release, so I'm looking for feedback on ergonomics and places where the API is either missing features or could be simpler.

iOS real device support has been Maestro's most requested feature since January 2023. Almost 3 years of GitHub issues and comments asking for the same thing.

We needed it for our work, so we built it and submitted PR #2856. But the Maestro team said official support won't land until next year — no committed timeline.

We didn't want teams to wait, so we packaged a standalone tool that works today.

How it works: - maestro-ios-device builds and deploys the XCTest runner to your physical iPhone - Port forwarding bridges localhost:6001 → device:22087 - Your existing Maestro YAML runs unchanged

Bonus: We also unlocked parallel execution on multiple real devices. Maestro had a hardcoded port limitation — now you can run on device 1 at :6001 and device 2 at :6002 simultaneously.

Limitations (Apple restrictions): - clearState works via app reinstall (not simctl) - setLocation requires additional setup - addMedia not supported

Install: curl -fsSL https://raw.githubusercontent.com/devicelab-dev/maestro-ios-... | bash

Repo: https://github.com/devicelab-dev/maestro-ios-device PR: https://github.com/mobile-dev-inc/Maestro/pull/2856

Tested on iOS 18.x and 26.x with Maestro 2.0.9/2.0.10.

This is unofficial — when Maestro ships native support, use that instead. Happy to answer questions about the implementation.

Hi HN!

This keyboard is like a corne (v4) [0] with the physical layout of a fifi [1].

The PCB can be ordered from JLCPCB with PCB assembly of the components: no need to solder anything yourself! (unless you want encoders) See the ordering guide in the repository for more information [2].

Main Characteristics:

- 36/40 keys

- Encoder support

- Embedded RP2040 controller

- USB-C to connect the halves

- PCB assembly: no soldering required (unless you use encoders)

The PCB was made by a Fiverr contractor (I don't know how to do it myself, their profile here [3]) and the case by me.

If there is anything missing in the README or the docs, feel free to let me know.

[0] https://github.com/foostan/crkbd

[1] https://github.com/raychengy/fifi_split_keeb

[2] https://github.com/v3lmx/cornifi/blob/main/docs/pcb_ordering...

[3] https://www.fiverr.com/circuitwork32

https://github.com/mcp-shark/mcp-shark Site: https://mcpshark.sh/

I built MCPShark, a traffic inspector for the Model Context Protocol (MCP).

It sits between your editor/LLM client and MCP servers so you can: • See all MCP traffic (requests, responses, tools, resources) in one place • Debug sessions when tools don’t behave as expected • Optionally run “Smart Scan” checks to flag risky tools / configs

Hi HN,

I built WhatHappened (whathappened.tech) because I have a love/hate relationship with this site. I love the content, but the "wall of text" UI gives me FOMO. I was spending too much time clicking into vague titles ("Project X") or wading through flame wars just to find technical insights.

I built this tool to act as a filter. It generates a card for the top daily posts with a few specific features to cut the noise:

1. AI Summaries: It generates a technical TL;DR (3 bullet points) and an ELI5 version for every post.

2. The Heat Meter: I analyze the comment section to visualize the distribution: Constructive vs. Technical vs. Flame War. If a thread is 90% Flame War, I know to skip it (or grab popcorn).

3. Contrarian Detection: To break the echo chamber, the AI specifically hunts for the most upvoted disagreement or critique in the comments and pins it to the card.

4. Mobile-First PWA: I mostly read HN on my phone, so I designed this as a PWA. It supports swipe gestures and installs to the home screen without an app store.

Stack: Next.js, Gemini, Supabase.

It currently supports English and Chinese. Any feedback will be appreciated! My original X post: https://x.com/marsw42/status/1997087957556318663, please share if you like it or find it helpful! :D

Thanks!

Hi HN, I’ve released a new version of chess-tui, a Rust terminal UI for playing live games against Lichess opponents.

The update includes a cleaner TUI, better performance, improved keybindings, and smoother real-time integration with the Lichess API. It’s designed as a simple, fast way to play chess without leaving the terminal.

Repo:https://github.com/thomas-mauran/chess-tui

Feedback and bug reports are welcome. Happy to answer questions!