Tomshardware
Open-source 3D-printed portable MRI machine built for under $70k
Uploads.sh
Show HN: Uploads.sh – the missing upload command for coding agents (open-source)
Production duplex speech model for revenue calls
Hi, HN, we’re building Mia & Leo: AI personalities backed by purpose-built duplex speech models for revenue calls. Teams building real-world agents told us that more than 40% of callers hang up within the first 30 seconds. On a revenue call, that meant a lost booking, an unpaid balance, a cold lead, or a customer who does not come back. This happens because humans interrupt, correct dates, pause halfway through a sentence, or speak over someone in the background. The agent misses it, talks over them, or loses the thread. That’s because of how the current voice systems work. They sequentially listen, stop, think, and then speak. The conversation is actually a walkie-talkie exchange. So, we’re proud to introduce our first iteration of Mia & Leo who keep listening while they speak. They can handle interruptions, overlapping speech, corrections, and background voices without breaking the conversation. They are also built for production. Developers get control over agent behaviour, visibility into calls, failures they can debug, and costs that work at scale. Please try them out at metavoice.io. We'd love to hear any feedback!
I built a zero-latency developer tool suite in pure Vanilla JavaScript
Show HN: I built a zero-latency developer tool suite in pure Vanilla JavaScript
Unlayer
Hi HN, We’re Adeel and Umair, co-founders of Unlayer (https://unlayer.com/). We let you add content creation to your applications without having to build an entire editor, renderer, template, and export stack yourself. Unlayer lets you create emails, web pages, and documents inside your app, in three different ways: in code, visually, or with AI. Here’s a demo: https://www.youtube.com/watch?v=0HsDtNkdMpM. We started with an embeddable email editor because a lot of products eventually need one: CRMs, marketing tools, customer engagement platforms, marketplaces, internal tools, and vertical SaaS apps all run into this at some point. At first, it sounds like a small feature: "just" add a drag and drop editor. In practice, it turns into a big pain. You end up dealing with email rendering, Outlook quirks, responsive layouts, templates, merge tags, image uploads, exports, permissions, localization, versioning, and a long tail of edge cases that have nothing to do with your core product Over time, we saw the same problem beyond email. Apps also need landing pages, invoices, proposals, reports, contracts, and PDFs. Some of this content is best created visually by end users. Some of it is better generated in code by developers. Increasingly, some of it is also generated by AI agents. Many teams eventually need all three workflows. That is the direction we have been working toward with Unlayer. There are three parts we are showing today: (1) Unlayer Elements. This is our open-source React component library for creating emails, pages, and documents in code (repo: https://github.com/unlayer/elements, more at https://unlayer.com/elements). Instead of hand-writing raw HTML templates, developers can compose content using React components, reuse sections like headers, footers, CTAs, invoice rows, and branded blocks, keep templates in Git, and render them into production output. One newer use case we are seeing is AI-assisted content creation. If an AI agent is asked to create an email, invoice, report, or landing page, the output is usually raw HTML or markdown that becomes hard to maintain. With Elements, the agent can generate structured React components instead. A developer can review the result, refactor it, keep it in Git, and still pass the design into a visual builder later if someone needs to edit it. (2) Visual Builder. This is the drag and drop editor (repo: https://github.com/unlayer/react-email-editor, more at https://unlayer.com/email-builder) that can be embedded inside an app so non-technical users can create or edit content. In the demo, we show the email builder and the AI assistant inside the builder. The goal is not to replace the developer workflow, but to connect it with a visual workflow when marketers, admins, customers, or internal teams need to make changes themselves. (3) Document Builder. This is for structured documents such as proposals, reports, invoices, contracts, and PDFs. We have seen a lot of teams build separate systems for email templates, web pages, and document generation, even though the underlying primitives are similar: layout, content blocks, variables, assets, preview, export, and permissions. More: https://unlayer.com/document-builder The technical challenge is making these workflows share a common foundation. Developers should be able to build templates in code when that makes sense. End users should be able to edit visually when that makes sense. AI agents should be able to generate structured content instead of unmaintainable blobs. The final output should still be usable by the host application. We make money by selling hosted builder, template, export, and platform features to companies embedding this into their products. Elements is open source. The commercial product is the broader hosted platform around builders, collaboration, storage, exports, and production use cases. We were part of W22, so this is a late Launch HN. At the time, Unlayer was an embeddable email editor, and we did not think we had the right broader story for HN yet. Since then, the product has expanded into a more general content creation layer for products, including emails, pages, documents, APIs, open-source developer projects, and AI-assisted workflows. That felt like a better moment to bring it to HN and ask for feedback. We'd really appreciate thoughts from HN. This is one of those areas where a lot of people have strong opinions because they’ve been burned by editors, email HTML, document editing, or “simple” content workflows before. We'd love to hear what resonates, what sounds wrong, and what you think we should be thinking harder about!
Langy, an automated AI engineer (we gave it a robot body) [video]
Founder here. Langy is an AI engineer that lives inside our platform, LangWatch. It reads your production traces, writes Scenario tests and evaluations for the problems it finds, opens a pull request on your repo, and proves the fix by running those simulations in CI. A human still merges. Reachy robot from Hugging Face arrived on the same week we were planing on launching it, so we wanted to use for the launch. So we it wired to our Langy which actually lives on the platform, and asked it to test our own customer-support voice agent. On the video you can see it writing the agent tests reading traces and everything. LangWatch is an open source platform (github.com/langwatch/langwatch) and Scenario, the simulation-testing library it drives, is open source too if you want to run that part yourself: https://github.com/langwatch/scenario. A full write-up on how Langy works under the hood is coming later this week. Happy to get into how it drives the robot, what is real vs staged, latency, or how the whole harness around it actually works.
Maptoolkit.org
We built Maptoolkit.org - a free, production-grade vector maps service built on OpenStreetMap and MapLibre. Map rendering and tile hosting have historically been either expensive (Google, Mapbox) or complex to maintain yourself. (Plus: Their maps are car-focused.) Our maps feature max data zoom 15, global hill-shading, 3D terrain, contour lines, water depths, and specialized styles (like Hiking, Cycling, Winter). No sign up or API keys required. You can use it like this: ``` const map = new maplibregl.Map({ container: 'map', style: 'https://styles.maptoolkit.org/summer.json', // <- that's all you need to add center: [11.40, 47.27], zoom: 12 }); ``` And you can create custom styles with our MapMaker. Maybe a Elden Ring map style for your website? We hope you like it.
Agent in 9 Lines Python
I asked myself: what would a minimal implementation of an agent look like? Something that works out of the box, is a real agent with tool calling, but without 1000s of lines of code, without dozens or hundreds of npm or pypi dependencies. Something with just a few 'essential' features (not a whole kitchen sink that most agent harnesses come with nowadays). An implementation close to pseudocode that you can look at in one page, everything there at a glance, no scrolling. This is the agent.py I ended up with so far: import json,sys;from subprocess import getoutput as sh;from urllib.request import Request as R,urlopen url=sys.argv[1];h=[];b=dict(model="gpt-5.6",input=h,tools=[dict(type="custom",name="sh")]) while p:=input("> "): h+=[dict(role="user",content=p)];H={"Content-Type":"application/json"} while True: o=(r:=json.load(urlopen(R(url,json.dumps(b).encode(),H))))["output"] h+=o;c=[i for i in o if i["type"]=="custom_tool_call"];z=r["usage"]["total_tokens"]/10500 if not c:print(o[-1]["content"][0]["text"],f'\n[{z:06.3f}%]');break h+=[dict(type="custom_tool_call_output",call_id=i["call_id"],output=sh(i["input"])) for i in c] It is a bit code golfed but I think it is fairly readable - imports are all from stdlib (0 external dependencies!) - assumes there is an inference api endpoint running somewhere - assumes the inference api endpoint is openai-like - model hardcoded to "gpt 5.6" (=> Sol), can easily be changed to e.g. open weight (kimi k3, glm 5.2 etc) - api endpoint url is passed as arg to the python script - configures only 1 custom tool: 'sh' - 'sh' is sufficient for interacting with the environment in an open ended way - new api output gets added to history ("h") - if api output contains tool calls the tool calls get executed - agent gives control back to user when the last model response is without tool calls - agent message to user shows % of context window used Noteworthy: no dependencies other than python stdlib (!) - less startup time - less dependency churn - less supply chain attack vector surface - less code to verify and understand no mcp, no plugins, no security theater - if you want to add something specific: add it explicitly - adapt the environment to give the agent access or restrict access to tools, resources, network etc (the env is the security boundary, not the harness) no system prompt - every token in context window is precious - current strong models do fine without steering via system prompt (or are even harmed by long overly specific system prompts designed for models from months ago) - system prompt or agents.md context can easily be added if needed (agent can also discover it or get prompted to read from environment as is) how to run/deploy the agent - design the environment you want to give the agent (container, docker, sandbox of your choice) - start an inference api endpoint that is openai-like (support the request/response shape used in agent.py above) - inference api endpoint can be as simple as a proxy to openai api that adds credentials/api key - adapt as you want/need it, change the model, remove/alter context window behaviour, add tools, etc etc Looking for any feedback you have to make it more clear or even simpler!
Ex Situ
Hi, I designed and developed a spatial index that maps museum artefacts as connecting arcs/hyperlinks from their origin site to institutional location/sources. The Index specifically looks at western/euro-american institutions and maps their collection categorised by them under Islamic art, Asian/African art, ethnological collections, Middle East, South America etc. Started as my MA thesis in 2022, kept building since, mostly solo with a little funding. Fully open source, self-hosted, AGPL-3.0, Next.js + Deck.gl on the frontend, Strapi backend, Python ETL pulling from museum open-access APIs. Currently indexing over 100k artifacts from all over the world, across 8 collections (Met, V&A, SMB Berlin). Recently added an md export so researchers can download provenance data for a filtered set of artifacts. The infrastructure is conceptualized as an indexer, not a hoster. Even images are kept as URLs pointing to the source institutions. It's connective tissue between archives that were never designed to speak to each other, with an origin-first search UI concept. The data model is on purpose flat, to avoid encoding problematic taxonomies, and routes researchers directly to the source giving responsibility to the source institutions rather than duplicating institutional data. It indexes the relationship between origin sites and destination collections. Coming from a design background, taking this project from prototype to production app has been incredibly rewarding, but honestly it’s getting a little bit overwhelming to scale alone. I would love community’s feedback on performance scaling, any code contributions, data pipelines for missing museum apis or general feedback. Repo: https://github.com/hburakyel/ex-situ Live: https://exsitu.app
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.
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.
Sentinel
Show HN: Sentinel – open-source QA agent that reads your code before it clicks