Show HN: LocalCode – turn plain English into CLI commands with Apple's local AI https://ift.tt/5esybMi

Show HN: LocalCode – turn plain English into CLI commands with Apple's local AI https://ift.tt/YJzM96o June 10, 2026 at 02:34AM

Show HN: OpenYabby, voice-controlled multi-agent orchestrator for Claude Code https://ift.tt/xKOuhC9

Show HN: OpenYabby, voice-controlled multi-agent orchestrator for Claude Code https://ift.tt/oHZFjeJ June 10, 2026 at 01:38AM

Show HN: Transit-format (JSON/MessagePack) reader/writer in C https://ift.tt/fGB5ihJ

Show HN: Transit-format (JSON/MessagePack) reader/writer in C Transit.c is an addition to the set of libraries to support transit data interchange format written in C11. It supports full 0.8 specification of cognitect's transit-format: JSON, JSON-Verbose and MessagePack encodings, all ground and extension types, compression via keys caching, extensibility via custom tag handlers. https://ift.tt/etkdHVs June 8, 2026 at 03:05PM

Show HN: HTTP/3 and raw QUIC client/server APIs for Node.js https://ift.tt/ecnuEKb

Show HN: HTTP/3 and raw QUIC client/server APIs for Node.js I built this because I wanted to make outbound and accept inbound HTTP/3 and raw QUIC connections from ordinary Node.js code, without building Node from source or putting everything behind a reverse proxy. Repo: https://ift.tt/NXKcFUq npm: https://ift.tt/XnrOCqP It’s a native package around Rust/quiche. It supports both client and server APIs, I'm using it in a couple of projects: creating raw QUIC streams, datagrams, custom ALPN, session behavior, and HTTP/3 client work from Node. I've tried to be very safe in the native code, written in rust, with proofs around the parts I was most concerned about getting wrong. I have it hosting a couple of sites as HTTP3 endpoints and found it working well. https://ift.tt/NXKcFUq June 9, 2026 at 12:08AM

Show HN: Stop returning raw JSON from MCP servers, build rich inline UIs https://ift.tt/vH6b2Bj

Show HN: Stop returning raw JSON from MCP servers, build rich inline UIs https://ift.tt/mxs0wul June 9, 2026 at 12:07AM

Show HN: A Minecraft builder skill for coding agents https://ift.tt/R5DQ8I0

Show HN: A Minecraft builder skill for coding agents https://ift.tt/RaWLn4B June 8, 2026 at 08:21PM

Show HN: NoSuggest – Watch YouTube without the recommendation algorithm https://ift.tt/KkdOoMr

Show HN: NoSuggest – Watch YouTube without the recommendation algorithm NoSuggest is a quiet act of resistance against YouTube algorithms always trying to pull you into a loop of unlimited videos in turn into unlimited screen time. With unending side cards of videos, auto-play, what's next suggestions, YouTube shorts and notifications, users will be doom scrolling for many hours in a day. I faced the same problem. Acknowledging that, not all content in YouTube is bad. There are educational videos, genuine news contents without political bias which is very hard to find outside YouTube and many other good relaxing, entertainment stuff. NoSuggest lets you only follow the YouTube channels you like and removes all types of recommendation YouTube has. So you don't waste time on watching things which you never wanted to watch anyways. UI is very simple. You add your favourite channels in "Channels" tab and latest 5 videos per channel excluding shorts would appear in "Feed" tab. "Search" tab is to search for specific videos to watch and "Saved" tab is to bookmark any video you want to watch later. Intention of NoSuggest is to provide whatever is necessary to extract whats good from YouTube all inside NoSuggest and leave out bad parts. NoSuggest works in any devices. Install it as an app (PWA) in android and iPhone, or simply open in browser in laptops. No sign-in, no account creation or no card details. NoSuggest won't even ask your name. Total privacy for the users. Parents can add the channels and save some educational videos and lock it with the pin for kids mode. Kids won't be able access unwanted additive contents inside NoSuggest. Completely free, no string attached. Source available in Github through NoSuggest website. I would love genuine feedback. Thank you very much for your attention on this matter. https://ift.tt/DJYTmhR June 4, 2026 at 02:44AM

Show HN: An mkv player that uses WASM to render you videos https://ift.tt/pJjemUr

Show HN: An mkv player that uses WASM to render you videos hello HN i want to share this wasm experience i built for a universal mkv player on the web using wasm to ship a lean decoder only ffmpeg build, thus way codecs unsupported by the browser can be played I wonder if this holds any value to anyone anymore https://parallax.kinosoft.moe/ June 8, 2026 at 05:27AM

Show HN: I Derived a Pancake https://ift.tt/MNrBp83

Show HN: I Derived a Pancake After 25 years of making other people's pancake recipes - always yearning for more tang, more fluff, and more predictability - I decided to derive the pancake recipe from the chemistry. You mark checkboxes for what you have on hand (ricotta, sour cream, kefir, buttermilk, yogurt, cottage cheese, lemon, cream of tartar, etc.) and it computes the best recipe based on targets for acid, fat, salt, sugar, and CO2. My particular favorite are the yeast-raised lemon ricotta kefir pancakes - the best I've ever had. The math is done in a small pure-ESM library: ingredient composition to component masses and acid moles, a stoichiometry layer, and a bisection solver for the target deficits. I'm not a chemist, so if something is off, tell me and I will fix it! https://ift.tt/05n2zxX June 5, 2026 at 12:12PM

Show HN: Nightwatch, The open-source, read-only AI SRE https://ift.tt/84AakcH

Show HN: Nightwatch, The open-source, read-only AI SRE nightwatch is a local-first, read-only layer on top of your monitoring. it groups alert storm into incidents, flags noisy checks and has an agent that can investigate for you live systems. You can e.g. jump from the incident into the agent directly. the reason for this weekend project is that we had a kubernetes upgrade that went wrong, and at some point a rollback wasn't possible anymore, so it had to be fixed live during the night while several problems came together. We run a lot of different systems, on-prem and several Kubernetes clusters, and in a situation like that you spend most of the time just figuring out what is actually broken and where. So i thought that it would be pretty cool to have eyes in the dark in each system that can talk to your "brain". so the idea is to put a baby owl into each environment. Each owl runs where the systems live, keeps that environment's credentials local, and only dials outbound to a central brain, so there is no inbound hole into prod. It exposes a set of read-only skills, and the agent uses them to gather evidence and form a root-cause hypothesis, so the on-call engineer starts with a head start instead of from zero. read-only for now, i don't trust it near prod yet and honestly neither should you. llocal-first for easy self-hosting and to keep credentials on your side. the clustering and recommendations run fully offline with no llm at all. the agent needs a tool-calling llm, you can point it at a remote one, or self-host one (ollama etc.) if you want to stay fully offline. for non selfhosters: before every remote llm call, nightwatch strips real secrets (unrestorable) and swaps identifiers like ips, hostnames and paths for reversible placeholders, so the model only sees masked data while real values are restored only in the proposed commands and tool calls Would love if you try it in your Systems https://ift.tt/sM5IZ8X June 8, 2026 at 01:54AM

Show HN: Dap-mux – Connect your editor and REPL to the same debug session https://ift.tt/iw4onjx

Show HN: Dap-mux – Connect your editor and REPL to the same debug session I have been coding over four decades, in many languages, on many projects (including Firefox, Final Cut Pro, the Newton, and Fullwrite Professional if you can remember that far back; all these using my "dead-name"). I wrote something small and simple to scratch an itch. It's the UNIX philosophy: small "one-trick ponies", each *really* good at their one trick, then the user can hook them together to solve actual problems. I'm a CLI guy, and for almost everything, I already have this. But not for debugging. The itch I scratched was the connector that enables this philosophy for debugging. That thing is dap-mux. A DAP multiplexer turning a one-to-one protocol into a cooperating session of as many tools as you need to get it done! How it started: Helix and Python for me (and sometimes IPython), with the rest of my team using PyCharm (which I have long loved!). My team's problem is that they want the PyCharm debugger, and so must be satisfied with the JetBrains editor. *My* problem was I could use a full-blown debugger *or* I could have IPython *or* I could have Helix (or sometimes an unsatisfying combination of Helix and the debugger). That was my "itch". DAP (Debug Adapter Protocol) is the tantalizing answer, except it isn't. DAP is what editors (that don't want to write their own debuggers) are starting to adopt. The problem with DAP is it's one-to-one. One editor connects to one debugger. Done. Not a solution to my problem. And then suddenly, it *was* the solution. I realized that a DAP multiplexer would let you connect any DAP-aware editor to any debugger for any language, and simultaneously to a REPL, another session of your editor (or a different editor)! With the side benefit that now, like screen or tmux, since each process is its own thing: sessions are durable. Just restart whatever crashed and you're back where you were! There were hard parts: sequencing, late joiners, state management. Different end-points working on different actions in different sequences but with the same message ids. I solved these problems something like how NAT works. Instead of translating network addresses, though, I'm translating the sequence numbers of each client into something global and ordered, then correctly routing replies back to the end-point awaiting them, while mapping the sequence numbers for those replies back into the space of that end-point. Knowing the current state of the debugger, and replaying that as a message sequence to late joiners lets you start/connect the clients in any order. I chose Python: asyncio fits the I/O-router pattern perfectly, and it lets the IPython extension run in-process rather than over IPC. There are problems not yet solved: for instance, I think configuration in the clients and/or the startup sequence is too complicated. But it functions! I got what I wanted! The combination I use every day: Python + debugpy + Helix + IPython, all connected simultaneously. Step with `%n` or `%s`, evaluate expressions with `%eval`, watch Helix track the current line in real time. Rust with codelldb is the second confirmed combination — I debugged a Dijkstra implementation with Helix and a third-party DAP observer tool both connected to the same codelldb session. A community member, Sean Perry, has already built [dap-observer]( https://ift.tt/J94PEKy ), which renders the current frame's variables as a navigable terminal tree. *This* was my exact dream! Small, focused, connectable tools all playing together! There's so much left to try: other editors, other debug adapters, Windows, other languages. None of this has been touched yet. The most helpful thing now is people testing it with their own setup and reporting what they find. It's time to play! `uv tool install 'dap-mux[ipython]'` for Python + IPython. `uv tool install dap-mux` for headless use with any language and adapter. No need for any part of the Python ecosystem. https://ift.tt/y298GJA June 7, 2026 at 02:43AM

Show HN: Typedframes – Pandas/polars column name checking at lint time https://ift.tt/vEfYhgJ

Show HN: Typedframes – Pandas/polars column name checking at lint time https://ift.tt/kCsAiWf June 7, 2026 at 02:02AM

Show HN: Resonate – Low-latency, high-resolution spectral analysis https://ift.tt/fQDC9rE

Show HN: Resonate – Low-latency, high-resolution spectral analysis Last April I shared about my Resonate project here ( https://ift.tt/K5OdwQE ) A lot has happened since: the work I presented in much more detail at last June's International Computer Music Conference (ICMC) got best paper award. I also gave a talk at the Audio Developer Conference in Bristol last November, the video is on YouTube). This year's work, which I recently presented at this year's ICMC, starts with known techniques from the phase vocoder literature to build self-tuning filter banks that extract very efficiently the frequency components that are actually present in the input signal. Overview on the project website, more details in the papers, including applications to super-resolution spectrograms and re-synthesis experiments. As many people have pointed out, none of the techniques I have used are new (some of them even have different names across different fields), but I haven't seen them applied together in this way, and to me the results are incredibly satisfying and sometimes look magical. See for example this demo: https://youtu.be/LasdoIJJkw8 Of course the best way to experience in person is through the free demo app: https://ift.tt/fOUHniM Looking forward to feedback from the community! https://ift.tt/4vNn3mI June 6, 2026 at 11:39PM

Show HN: I nerfed our coding agents on purpose https://ift.tt/btRQN9j

Show HN: I nerfed our coding agents on purpose Tl;dr: I trained a classifier to route to the least expensive model and reasoning depth to complete the request. Coupling that with additional automated token efficiency techniques has yielded 3x usage for the same spend. For anyone interested in trying it themselves: https://nerfguard.com Various teammates and I switched over to Codex from Claude Code recently. We still bounce between the tools, but Codex’s speed and steerability coupled with performance gains were hard to ignore. One of the downsides was that the per token pricing kicked in way sooner. This is happening across the board, but we felt it in Codex more acutely. We’re a startup filled with people who work around the clock and are obsessed with building — naturally our daily bill alone was striking. Luckily we’re going after a big mission and speed matters significantly more than marginal token spend on the edges. Still, it got us thinking about how it was ludicrous that while our product has a side effect of decreasing token spend and speeding up agentic workflows by many orders of magnitude, we were using these top tier models for all types of internal coding tasks without any of those optimizations. The waste felt pretty ridiculous — the most glaring culprit was that we were seemingly using the max intelligence model on max reasoning for every task even when the task clearly didn’t require it. As a company who spends a lot of time on cached intelligence, it was also easy for us to see how there was plenty of other low hanging fruit as well. So, on a recent weekend, I quickly built a tool to optimize our usage. At its core is a very fast classifier that classifies your requests to the least intelligence required for the task and includes some nice token optimizations on top. The result is roughly the same quality for multiples lower token spend. But even more exciting for us, is that the properly bin packed intelligence and reasoning levels meant our speed also went up considerably. This wasn’t negligible. We’ve observed up to 3x savings and hours per day per person in saved time that we would have otherwise been waiting on tool turns and coding agent responses. For us, that means improved engineering velocity and significantly higher usage for the same spend. It also means more usage before getting throttled. As I told friends about this, they also wanted to start using it to maximize the usage they could get out of their coding agent plans. There are now engineers across many of the most cutting edge AI companies using this tool to optimize their token utilization in this way. Not just to save money, but to maximize output. Turns out that the best way to avoid getting nerfed by Claude is to intentionally nerf yourself selectively. We decided to release it for the rest of the builder community to use as well. You can now turn on Nerfguard for yourself and start getting more usage today. June 6, 2026 at 04:49AM

Show HN: I rebuilt a tiny old volleyball game I loved https://ift.tt/lZQObdh

Show HN: I rebuilt a tiny old volleyball game I loved https://volleyhop.com/ June 6, 2026 at 01:42AM

Show HN: Bash Runtime for AWS Lambda https://ift.tt/je8JKH7

Show HN: Bash Runtime for AWS Lambda Hi HN, I built a Bash runtime for AWS Lambda to make writing glue code simpler and faster. Sometimes, all you need is a bit of `sed`, `awk`, maybe a loop and a few HTTP API calls, and this runtime gives you all the tools to do that. It comes bundled with `jq` and `curl` so you can handle JSON payloads and string together HTTP API calls right out of the box, including calling AWS services with `curl --aws-sigv4`. In keeping with the theme, the Lambda handler contract is also made as simple as practical: read from stdin, write to stdout, return 0 for success and non-0 for error. You can run shell scripts, call binaries (either what's available in `al2023.provided` or you can package your own static binaries with your handler), or a combination of both. If you remember nodding along to Adam Drake's post about how bash and coreutils can be faster than a Hadoop cluster, I hope you give this a whirl and find it useful. The runtime is packaged as a Lambda layer, so it should drop right into your normal AWS infrastructure. https://ift.tt/PwmT07U June 6, 2026 at 12:42AM

Show HN: Bot or Not – Spot AI-generated randomness https://ift.tt/fnPoJVI

Show HN: Bot or Not – Spot AI-generated randomness https://play-bot-or-not.vercel.app/ June 5, 2026 at 01:26AM

Show HN: Using Haskell to play music on 3D printer motors (2020) https://ift.tt/UJX25Gb

Show HN: Using Haskell to play music on 3D printer motors (2020) https://lucasoshiro.github.io/software-en/2020-07-31-music_gcode/ June 5, 2026 at 01:37AM

Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call https://ift.tt/2zao37s

Show HN: Cost.dev (YC W21) – making agents cost-aware and cheaper to call We launched Infracost on HN five years ago ( https://ift.tt/cuE04hU ) where our CLI generated cost estimates for infra-as-code, e.g. "this Terraform PR adds $400/mo". The idea was to shift cloud costs (FinOps) left, so engineers get visibility of costs before deployment and make better decisions. Earlier this year we started seeing agent traffic in our logs and it looked like coding agents were calling our CLI. But that CLI wasn't designed with coding agents in mind. We went down a philosophical rabbit hole to see if a CLI is even needed anymore given that Claude, Copilot et al. already follow best practices. Ultimately we decided to create a new CLI from the ground up with coding agents in mind for two reasons: 1. We optimized the CLI for agent callers and cut Claude's output token usage by up to 79% and API cost by up to 67% versus a bare-Claude baseline. We wrote a blog documenting our lessons on optimizing user token usage when designing a CLI, e.g. using predicate flags so the agent doesn't compose jq | python | wc pipelines, output format that strips JSON's redundant field names. The blog is here: https://ift.tt/BJ5v8oy... 2. With cloud costs, precision matters. Telling a coding agent "make this Terraform cost-optimized" can be expensive and lossy. You burn tokens loading code and policy context into every conversation. Your agent could make up a price and you wouldn't know because it's difficult to verify that across the ~10M price points that AWS, Azure and Google have. The CLI runs static analysis on the code, uses the latest prices from cloud vendors, and passes that context to the coding agent. So that's what we're launching today - Cost.dev: https://cost.dev/ . - It runs locally. Your code never leaves your machine, you get a fast feedback loop, and you're not burning API calls per character when you want to fetch prices. - The CLI does the deterministic work. Fetching price points, scanning the code, validating fixes. The coding agent does the natural-language part. You don't have to trust the LLM to remember the rules, and can verify it called the right CLI command. - It provides a consistent rule layer across every tool you use. Get cost estimates in your IDE and your coding agent with a single install. We support Claude Code, GitHub Copilot, Cursor, Windsurf, OpenAI Codex, Gemini CLI, as well as IDEs like VS Code and JetBrains Before we keep building more in that direction, I want to sanity-check with HN: is "agents writing IaC in prod" actually a thing yet, or am I betting on a future that's still a year out? I know software developers are using coding agents heavily, but are platform/infra folks doing that for prod too? Also, if you have any feedback on Cost.dev, I'd love to hear it! https://cost.dev/ June 4, 2026 at 05:00PM

Show HN: Fork of Rsync https://ift.tt/wdAXWp3

Show HN: Fork of Rsync Hello. After hearing of the problematic LLM commits in rsync, I made a fork of rsync. I decided to fork it off release 3.4.1, since I heard that's the last release without the LLM code. https://ift.tt/z3wt1HF June 4, 2026 at 03:50AM