The best Hacker News stories from Show from the past day
Latest posts:
Show HN: WeTransfer Alternative for Developers
Show HN: Backlit Keyboard API for Python
It currently supports Linux as of now. You can use this package to tinker with many things. Let's say, if you want to make a custom notification system, like if your website is down, you can make a blink notification with it. MacOS support is underway. I haven't tested Windows yet, I don't use it anymore btw.
In future, if this package reaches nice growth, I'll be happy to make a similar Rust crate for it.
Show HN: Broccoli, one shot coding agent on the cloud
Hi HN — we built Broccoli, an open-source harness for taking coding tasks from Linear, running them in isolated cloud sandboxes, and opening PRs for a human to review.<p>We’re a small team, and our main company supplies voice data. But we kept running into the same problem with coding agents. We’d have a feature request, a refactor, a bug, and some internal tooling work all happening at once, and managing that through local agent sessions meant a lot of context switching, worktree juggling, and laptops left open just so tasks could keep running.<p>So we built Broccoli. Each task gets its own cloud sandbox to be executed end to end independently. Broccoli checks out the repo, uses the context in the ticket, works through an implementation, runs tests and review loops, and opens a PR for someone on the team to inspect.<p>Over the last four weeks, 100% of the PRs from non-developers are shipped via Broccoli, which is a safer and more efficient route. For developers on the team, this share is around 60%. More complicated features require more back and forth design with Codex / Claude Code and get shipped manually using the same set of skills locally.<p>Our implementation uses:<p>1. Webhook deployment: GCP
2. Sandbox: GCP or Blaxel
3. Project management: Linear
4. Code hosting & CI/CD: Github<p>Repo: <a href="https://github.com/besimple-oss/broccoli" rel="nofollow">https://github.com/besimple-oss/broccoli</a><p>We believe that if you should invest in your own coding harness if coding is an essential part of your business. That’s why we decided to open-source it as an alternative to all the cloud coding agents out there. Would love to hear your feedback on this!
Show HN: Ctx – a /resume that works across Claude Code and Codex
ctx is a local SQLite-backed skill for Claude Code and Codex that stores context as a persistent workstream that can be continued across agent sessions. Each workstream can contain multiple sessions, notes, decisions, todos, and resume packs. It essentially functions as a /resume that can work across coding agents.<p>Here is a video of how it works: <a href="https://www.loom.com/share/5e558204885e4264a34d2cf6bd488117" rel="nofollow">https://www.loom.com/share/5e558204885e4264a34d2cf6bd488117</a><p>I initially built ctx because I wanted to try a workstream that I started on Claude and continue it from Codex. Since then, I’ve added a few quality of life improvements, including the ability to search across previous workstreams, manually delete parts of the context with, and branch off existing workstreams.. I’ve started using ctx instead of the native ‘/resume’ in Claude/Codex because I often have a lot of sessions going at once, and with the lists that these apps currently give, it’s not always obvious which one is the right one to pick back up. ctx gives me a much clearer way to organize and return to the sessions that actually matter.<p>It’s simple to install after you clone the repo with one line: ./setup.sh, which adds the skill to both Claude Code and Codex. After that, you should be able to directly use ctx in your agent as a skill with ‘/ctx [command]’ in Claude and ‘ctx [command]’ in Codex.<p>A few things it does:<p>- Resume an existing workstream from either tool<p>- Pull existing context into a new workstream<p>- Keep stable transcript binding, so once a workstream is linked to a Claude or Codex conversation, it keeps following that exact session instead of drifting to whichever transcript file is newest<p>- Search for relevant workstreams<p>- Branch from existing context to explore different tasks in parallel<p>It’s intentionally local-first: SQLite, no API keys, and no hosted backend. I built it mainly for myself, but thought it would be cool to share with the HN community.
Scoring Show HN submissions for AI design patterns
Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
I got tired of libvirt XML and Vagrant's Ruby/reload dance for single-host VM stacks, so I built a compose-style runtime directly on QEMU/KVM.<p>What's there: GPU passthrough as a first-class primitive (VFIO, OVMF, per-instance EFI vars), healthchecks that gate depends_on over SSH, socket-multicast L2 between VMs with no root and no bridge config, cloud-init wired through the YAML, Dockerfile support for provisioning.<p>What it's not: Kubernetes. No clustering, no live migration, no control plane. Single host.
Prototype, but I'm running it on real hardware. Curious what breaks for people.
Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
I got tired of libvirt XML and Vagrant's Ruby/reload dance for single-host VM stacks, so I built a compose-style runtime directly on QEMU/KVM.<p>What's there: GPU passthrough as a first-class primitive (VFIO, OVMF, per-instance EFI vars), healthchecks that gate depends_on over SSH, socket-multicast L2 between VMs with no root and no bridge config, cloud-init wired through the YAML, Dockerfile support for provisioning.<p>What it's not: Kubernetes. No clustering, no live migration, no control plane. Single host.
Prototype, but I'm running it on real hardware. Curious what breaks for people.
Show HN: Daemons – we pivoted from building agents to cleaning up after them
For almost two years, we've been developing Charlie, a coding agent that is autonomous, cloud-based, and focused primarily on TypeScript development. During that time, the explosion in growth and development of LLMs and agents has surpassed even our initially very bullish prognosis. When we started Charlie, we were one of the only teams we knew fully relying on agents to build all of our code. We all know how that has gone — the world has caught up, but working with agents hasn't been all kittens and rainbows, especially for fast moving teams.<p>The one thing we've noticed over the last 3 months is that the more you use agents, the more work they create. Dozens of pull requests means older code gets out of date quickly. Documentation drifts. Dependencies become stale. Developers are so focused on pushing out new code that this crucial work falls through the cracks. That's why we pivoted away from agents and invented what we think is the necessary next step for AI powered software development.<p>Today, we're introducing Daemons: a new product category built for teams dealing with operational drag from agent-created output. Named after the familiar background processes from Linux, Daemons are added to your codebase by adding an .md file to your repo, and run in a set-it-and-forget-it way that will make your lives easier and accelerate any project. For teams that use Claude, Codex, Cursor, Cline, or any other agent, we think you'll really enjoy what Daemons bring to the table.
Show HN: Daemons – we pivoted from building agents to cleaning up after them
For almost two years, we've been developing Charlie, a coding agent that is autonomous, cloud-based, and focused primarily on TypeScript development. During that time, the explosion in growth and development of LLMs and agents has surpassed even our initially very bullish prognosis. When we started Charlie, we were one of the only teams we knew fully relying on agents to build all of our code. We all know how that has gone — the world has caught up, but working with agents hasn't been all kittens and rainbows, especially for fast moving teams.<p>The one thing we've noticed over the last 3 months is that the more you use agents, the more work they create. Dozens of pull requests means older code gets out of date quickly. Documentation drifts. Dependencies become stale. Developers are so focused on pushing out new code that this crucial work falls through the cracks. That's why we pivoted away from agents and invented what we think is the necessary next step for AI powered software development.<p>Today, we're introducing Daemons: a new product category built for teams dealing with operational drag from agent-created output. Named after the familiar background processes from Linux, Daemons are added to your codebase by adding an .md file to your repo, and run in a set-it-and-forget-it way that will make your lives easier and accelerate any project. For teams that use Claude, Codex, Cursor, Cline, or any other agent, we think you'll really enjoy what Daemons bring to the table.
Show HN: Mediator.ai – Using Nash bargaining and LLMs to systematize fairness
Eight years ago, my then-fiancée and I decided to get a prenup, so we hired a local mediator. The meetings were useful, but I felt there was no systematic process to produce a final agreement. So I started to think about this problem, and after a bit of research, I discovered the Nash bargaining solution.<p>Yet if John Nash had solved negotiation in the 1950s, why did it seem like nobody was using it today? The issue was that Nash's solution required that each party to the negotiation provide a "utility function", which could take a set of deal terms and produce a utility number. But even experts have trouble producing such functions for non-trivial negotiations.<p>A few years passed and LLMs appeared, and about a year ago I realized that while LLMs aren’t good at directly producing utility estimates, they are good at doing comparisons, and this can be used to estimate utilities of draft agreements.<p>This is the basis for Mediator.ai, which I soft-launched over the weekend. Be interviewed by an LLM to capture your preferences and then invite the other party or parties to do the same. These preferences are then used as the fitness function for a genetic algorithm to find an agreement all parties are likely to agree to.<p>An article with more technical detail: <a href="https://mediator.ai/blog/ai-negotiation-nash-bargaining/" rel="nofollow">https://mediator.ai/blog/ai-negotiation-nash-bargaining/</a>
Show HN: Mediator.ai – Using Nash bargaining and LLMs to systematize fairness
Eight years ago, my then-fiancée and I decided to get a prenup, so we hired a local mediator. The meetings were useful, but I felt there was no systematic process to produce a final agreement. So I started to think about this problem, and after a bit of research, I discovered the Nash bargaining solution.<p>Yet if John Nash had solved negotiation in the 1950s, why did it seem like nobody was using it today? The issue was that Nash's solution required that each party to the negotiation provide a "utility function", which could take a set of deal terms and produce a utility number. But even experts have trouble producing such functions for non-trivial negotiations.<p>A few years passed and LLMs appeared, and about a year ago I realized that while LLMs aren’t good at directly producing utility estimates, they are good at doing comparisons, and this can be used to estimate utilities of draft agreements.<p>This is the basis for Mediator.ai, which I soft-launched over the weekend. Be interviewed by an LLM to capture your preferences and then invite the other party or parties to do the same. These preferences are then used as the fitness function for a genetic algorithm to find an agreement all parties are likely to agree to.<p>An article with more technical detail: <a href="https://mediator.ai/blog/ai-negotiation-nash-bargaining/" rel="nofollow">https://mediator.ai/blog/ai-negotiation-nash-bargaining/</a>
Show HN: GoModel – an open-source AI gateway in Go
Hi, I’m Jakub, a solo founder based in Warsaw.<p>I’ve been building GoModel since December with a couple of contributors. It's an open-source AI gateway that sits between your app and model providers like OpenAI, Anthropic or others.<p>I built it for my startup to solve a few problems:<p><pre><code> - track AI usage and cost per client or team
- switch models without changing app code
- debug request flows more easily
- reduce AI spendings with exact and semantic caching
</code></pre>
How is it different?<p><pre><code> - ~17MB docker image
- LiteLLM's image is more than 44x bigger ("docker.litellm.ai/berriai/litellm:latest" ~ 746 MB on amd64)
- request workflow is visible and easy to inspect
- config is environment-variable-first by default
</code></pre>
I'm posting now partly because of the recent LiteLLM supply-chain attack. Their team handled it impressively well, but some people are looking at alternatives anyway, and GoModel is one.<p>Website: <a href="https://gomodel.enterpilot.io" rel="nofollow">https://gomodel.enterpilot.io</a><p>Any feedback is appreciated.
Show HN: GoModel – an open-source AI gateway in Go
Hi, I’m Jakub, a solo founder based in Warsaw.<p>I’ve been building GoModel since December with a couple of contributors. It's an open-source AI gateway that sits between your app and model providers like OpenAI, Anthropic or others.<p>I built it for my startup to solve a few problems:<p><pre><code> - track AI usage and cost per client or team
- switch models without changing app code
- debug request flows more easily
- reduce AI spendings with exact and semantic caching
</code></pre>
How is it different?<p><pre><code> - ~17MB docker image
- LiteLLM's image is more than 44x bigger ("docker.litellm.ai/berriai/litellm:latest" ~ 746 MB on amd64)
- request workflow is visible and easy to inspect
- config is environment-variable-first by default
</code></pre>
I'm posting now partly because of the recent LiteLLM supply-chain attack. Their team handled it impressively well, but some people are looking at alternatives anyway, and GoModel is one.<p>Website: <a href="https://gomodel.enterpilot.io" rel="nofollow">https://gomodel.enterpilot.io</a><p>Any feedback is appreciated.
Show HN: VidStudio, a browser based video editor that doesn't upload your files
Hi HN,
I built VidStudio, a privacy focused video editor that runs in the browser. I tried to keep it as frictionless as possible, so there are no accounts and no uploads. Everything is persisted on your
machine.<p>Some of the features: multi-track timeline, frame accurate seek, MP4 export, audio, video, image, and text tracks, and a WebGL backed canvas where available. It also works on mobile.<p>Under the hood, WebCodecs handles frame decode for timeline playback and scrubbing, which is what makes seeking responsive since decode runs on the hardware decoder when the browser supports it.
FFmpeg compiled to WebAssembly handles final encode, format conversion, and anything WebCodecs does not cover. Rendering goes through Pixi.js on a WebGL canvas, with a software fallback when WebGL is
not available. Projects live in IndexedDB and the heavy work runs in Web Workers so the UI stays responsive during exports.<p>Happy to answer technical questions about the tradeoffs involved in keeping the whole pipeline client-side. Any feedback welcome.<p>Link: <a href="https://vidstudio.app/video-editor" rel="nofollow">https://vidstudio.app/video-editor</a>
Show HN: VidStudio, a browser based video editor that doesn't upload your files
Hi HN,
I built VidStudio, a privacy focused video editor that runs in the browser. I tried to keep it as frictionless as possible, so there are no accounts and no uploads. Everything is persisted on your
machine.<p>Some of the features: multi-track timeline, frame accurate seek, MP4 export, audio, video, image, and text tracks, and a WebGL backed canvas where available. It also works on mobile.<p>Under the hood, WebCodecs handles frame decode for timeline playback and scrubbing, which is what makes seeking responsive since decode runs on the hardware decoder when the browser supports it.
FFmpeg compiled to WebAssembly handles final encode, format conversion, and anything WebCodecs does not cover. Rendering goes through Pixi.js on a WebGL canvas, with a software fallback when WebGL is
not available. Projects live in IndexedDB and the heavy work runs in Web Workers so the UI stays responsive during exports.<p>Happy to answer technical questions about the tradeoffs involved in keeping the whole pipeline client-side. Any feedback welcome.<p>Link: <a href="https://vidstudio.app/video-editor" rel="nofollow">https://vidstudio.app/video-editor</a>
Show HN: Alien – Self-hosting with remote management (written in Rust)
Hi HN, I'm Alon, and I'm building Alien, an open-source platform for deploying your software into your customer's environment and keeping it fully managed.<p>In my previous startup, I heard the same question from <i>every</i> single enterprise customer over and over again: "My data is sensitive. Can I deploy your product to my own cloud account?"<p>Self-hosting is becoming very popular because it lets users keep their data private, local, and inside their own environment. Unfortunately, self-hosting breaks down when someone starts paying for your software. Especially if it's an enterprise customer.<p>Customers usually don't actually know how to operate your software. They might change something small — Postgres version, environment variables, IAM, firewall rules — and things start failing. From their perspective, the product is broken. And even if the root cause is on their side, it doesn't matter... the customer is always right, you're still the one expected to fix it.<p>But you can't. You don't have access to their environment. You don't have real visibility. You can't run anything yourself. So you're stuck debugging a system you don't control, through screenshots and copy-pasted logs on a Zoom call. You end up responsible for something you don't control.<p>I think there's a better model of paid self-hosting: the software runs in the customer's environment, but the developer can actually operate it. It's a win-win: for the customer, their data stays private and local, and the developer still has control over deployments, updates, and debugging.<p>Alien provides infrastructure to deploy and operate software inside your users' environments, while retaining centralized control over updates, monitoring, and lifecycle management. It currently supports AWS, GCP, and Azure targets.<p>GitHub: <a href="https://github.com/alienplatform/alien" rel="nofollow">https://github.com/alienplatform/alien</a><p>Getting started: <a href="https://alien.dev/docs/quickstart" rel="nofollow">https://alien.dev/docs/quickstart</a><p>How it works: <a href="https://alien.dev/docs/how-alien-works" rel="nofollow">https://alien.dev/docs/how-alien-works</a><p>Excited to share Alien with everyone here – let me know what you think!
Show HN: Alien – Self-hosting with remote management (written in Rust)
Hi HN, I'm Alon, and I'm building Alien, an open-source platform for deploying your software into your customer's environment and keeping it fully managed.<p>In my previous startup, I heard the same question from <i>every</i> single enterprise customer over and over again: "My data is sensitive. Can I deploy your product to my own cloud account?"<p>Self-hosting is becoming very popular because it lets users keep their data private, local, and inside their own environment. Unfortunately, self-hosting breaks down when someone starts paying for your software. Especially if it's an enterprise customer.<p>Customers usually don't actually know how to operate your software. They might change something small — Postgres version, environment variables, IAM, firewall rules — and things start failing. From their perspective, the product is broken. And even if the root cause is on their side, it doesn't matter... the customer is always right, you're still the one expected to fix it.<p>But you can't. You don't have access to their environment. You don't have real visibility. You can't run anything yourself. So you're stuck debugging a system you don't control, through screenshots and copy-pasted logs on a Zoom call. You end up responsible for something you don't control.<p>I think there's a better model of paid self-hosting: the software runs in the customer's environment, but the developer can actually operate it. It's a win-win: for the customer, their data stays private and local, and the developer still has control over deployments, updates, and debugging.<p>Alien provides infrastructure to deploy and operate software inside your users' environments, while retaining centralized control over updates, monitoring, and lifecycle management. It currently supports AWS, GCP, and Azure targets.<p>GitHub: <a href="https://github.com/alienplatform/alien" rel="nofollow">https://github.com/alienplatform/alien</a><p>Getting started: <a href="https://alien.dev/docs/quickstart" rel="nofollow">https://alien.dev/docs/quickstart</a><p>How it works: <a href="https://alien.dev/docs/how-alien-works" rel="nofollow">https://alien.dev/docs/how-alien-works</a><p>Excited to share Alien with everyone here – let me know what you think!
Show HN: Run TRELLIS.2 Image-to-3D generation natively on Apple Silicon
I ported Microsoft's TRELLIS.2 (4B parameter image-to-3D model) to run on Apple Silicon via PyTorch MPS. The original requires CUDA with flash_attn, nvdiffrast, and custom sparse convolution kernels: none of which work on Mac.<p>I replaced the CUDA-specific ops with pure-PyTorch alternatives: a gather-scatter sparse 3D convolution, SDPA attention for sparse transformers, and a Python-based mesh extraction replacing CUDA hashmap operations. Total changes are a few hundred lines across 9 files.<p>Generates ~400K vertex meshes from single photos in about 3.5 minutes on M4 Pro (24GB). Not as fast as H100 (where it takes seconds), but it works offline with no cloud dependency.<p><a href="https://github.com/shivampkumar/trellis-mac" rel="nofollow">https://github.com/shivampkumar/trellis-mac</a>
Show HN: Run TRELLIS.2 Image-to-3D generation natively on Apple Silicon
I ported Microsoft's TRELLIS.2 (4B parameter image-to-3D model) to run on Apple Silicon via PyTorch MPS. The original requires CUDA with flash_attn, nvdiffrast, and custom sparse convolution kernels: none of which work on Mac.<p>I replaced the CUDA-specific ops with pure-PyTorch alternatives: a gather-scatter sparse 3D convolution, SDPA attention for sparse transformers, and a Python-based mesh extraction replacing CUDA hashmap operations. Total changes are a few hundred lines across 9 files.<p>Generates ~400K vertex meshes from single photos in about 3.5 minutes on M4 Pro (24GB). Not as fast as H100 (where it takes seconds), but it works offline with no cloud dependency.<p><a href="https://github.com/shivampkumar/trellis-mac" rel="nofollow">https://github.com/shivampkumar/trellis-mac</a>
Sauna effect on heart rate