Intunedhq
Hey HN, we're Faisal and Ahmad from Intuned (https://intunedhq.com). We’re building a platform for building, deploying, and maintaining browser automations. Customers primarily use the Intuned AI agent to automate websites that don't expose APIs. Common use-cases include scraping data, pulling reports, and submitting forms. As the website changes, our agent also helps automatically heal the automation. On Intuned, browser automations are created by an AI agent and run as code. Our infra captures the context of every run, allowing our agent to debug and maintain the underlying code - to keep the automations working over time. This way, we’re able to offer the predictability, speed, and cost of code, without the painful parts of writing and maintaining it. Here’s a demo of building a scraper on Intuned: https://youtu.be/ruZP73bK4FU Here’s a demo of using AI to maintain a project: https://youtu.be/e4R4hLdHBro Backstory: we were accepted into YC for a completely different idea. During the batch, because of Faisal's background at UiPath, several batchmates asked us whether RPA tools could fill API gaps in their products by automating websites without APIs. When it was time to pivot, we went back to those founders to dig deeper. (RPA in this context is referring to using UI automation to do complete non-testing tasks) We discovered that the actual hard problem in browser automation is maintenance. Websites change, selectors break, and failures can be painful to reproduce and fix. So in early 2024, we decided to take a crack at this problem with a handful of customers. It needed a fair number of iterations before we landed on our current code-first approach. How it works: Intuned is infra + agent, deeply integrated. On the infrastructure side, Intuned is a managed runtime for browser automation code. Projects are usually Playwright-based TypeScript or Python. Users can write them directly in our online IDE, or hand the work off to the agent. Either way, once deployed, the platform runs each project in its own isolated machine and handles auth/session reuse, scheduling, batch execution, concurrency, observability, and the other plumbing around running browser code. On the agent side, it took us a few iterations to get to the current approach. Our initial attempts were rigid pipelines: collect requirements, inspect the site, generate code, then try to patch whatever broke. It looked reasonable on paper, but real websites are too messy for fixed paths. Late last year, we were planning to ship that version when stronger models landed and harnesses like Claude Code and Codex showed what a more open-ended coding agent could do. We built a prototype on the Claude Agent SDK, it felt much better than what we had, and we scrapped the release and decided to rebuild the agent. The rebuild came down to three pieces around the SDK: an execution environment for running long agent sessions reliably, a CLI that exposes the platform to the agent so it operates Intuned the way engineers do, and a custom plugin (skills + MCP) built around what we've learned building browser automations. The infra-agent integration is where the product gets more interesting. The runtime doesn't just run the automation; it captures the context needed to debug it when it fails: params, results, traces, logs. That enables features like Fix with AI, where you can open a failed run and have the agent investigate and prepare a fix. The same integration powers a feature called self-healing. For configured projects, the platform detects failures, starts an agent session with the relevant context, and either proposes a fix for review or deploys it automatically. Demo: https://youtu.be/IVHIXw0lYMs We recently also packaged the infra and agent as an API called Web Task API, here is a demo: https://youtu.be/1olRn3l95vw We strongly believe that browser automations can and should be faster, cheaper and more predictable. Check us out at https://app.intuned.io/, we have a free tier with trial credits for your first few automations. Excited to hear your thoughts, questions, and feedback!
A Highly Available Distributed Router for Global Realtime AI
Show HN: A Highly Available Distributed Router for Global Realtime AI
Rayline routes Claude Code subagents to on-device and cheaper models
Hi HN, I’m one of the builders of Rayline. Rayline is a Claude Code compatible LLM gateway. It intercepts and overrides claude code’s internal routing and lets you route subagent calls to different models instead. For example, you can run the main agent on Opus, some subagents on cloud-hosted open models, and other subagents on-device. We’ve seen others implement routing for claude code as tools the agent can invoke. In our experience, that doesn’t work well because it requires the main agent to use tokens to think about + call the tools, and LLMs are generally a very inefficient way to make routing decisions. By implementing Rayline as a gateway, we let users deterministically configure routing decisions, and you can optionally use our ML model to make routing decisions. We built it after noticing that Claude Code sessions contain a lot of subagent calls that don’t all need the same model. Other routers exist, but we built Rayline to let us continue using claude code (no separate harness), route tasks at a subagent level, and route across cloud and on-device. The main agent often benefits from Opus. But many delegated calls have narrow scope: search the repo, summarize context, inspect an error, poll for CI updates, etc. The thing we’re exploring is subagent-level routing. The main cost lever in coding agents is usually cached vs non-cached input. Subagent delegations are a natural point to make routing decisions because you avoid busting cache. We look at the message-thread context for a delegated call and choose a model for that call. At a task level, Sonnet and Haiku are almost always less capability-per-dollar than open models, so the main advantage is better + (much) cheaper subagents (60-90% in our private beta). The whole world seems to have started talking about model routing in the past two weeks, so apparently others agree it’s a relevant product area. We’d love to get feedback from the HN community!
DomainTasker
Show HN: DomainTasker – avoid losing domains and surprise renewals
I ported Xonotic (arena FPS) to WebAssembly with full P2P multiplayer
Show HN: I ported Xonotic (arena FPS) to WebAssembly with full P2P multiplayer
ABC Classic 100 Rankings visualised
This weekend is the ABC Classic FM countdown, which prompted me to dust off an old un-published data visualisation of rankings from previous years. I've considered adding a search function, but I also kind of like that it requires a bit of exploration in the current form. Some of the code is a bit clunky and I wouldn't mind refactoring it. I'm also not sure about browser compatibility - I've only got access to a couple of devices to test it on.
Mercek
Hey HN I've been using ECS for a while now and found it annoying having to log into the console everytime I use Lens for Kubernetes but couldnt find an equivalent for ECS so i built one! The project is open source as well https://github.com/utibeabasi6/mercek
ClearLogo
Show HN: ClearLogo – a logo API that returns usable logos, not raw files
GrayCloud
I miss Dark Sky, so I built my own weather app. Here's how GrayCloud works: * Raincast: minute-by-minute rain prediction and accumulation tracking for your exact location * Forecasts: 10 day forecasts use multiple high resolution sources and correct for bias at your location. * Alerts: rain starting, stopping, severe weather, daily summary and more * Widgets: home and lock screen widgets * Multi-platform: apple watch and mac apps I use NOAA and ECMWF models for core weather data and a custom model to compute rain accumulation and the next 60 minute radar movements. I also offer Apple WeatherKit as an alternative weather source.
Hydron
Hi HN, this is Prashant from H2Loop. Embedded engineers that we work with were annoyed that generic AI tools hallucinated register addresses, generated code for peripherals that don't exist on the chip and mixed up timer quirks between similar platforms like STM32F4 and F7. The code looks clean but it just won't boot. This made them go back to the datasheet every time. So we built Hydron, an AI tool that writes datasheet-grounded code for your hardware. Demo: Hydron setting up sleep-mode CPU logging for an onboard temp sensor on an STM32U385 - https://boot.hydron.sh/zzzDemo First, we've pre-indexed 580+ platforms and peripherals. Most of what you'd use in a robotics, UAV, or IoT build: common dev platforms like STM32, ESP32, RP2040, AM6 families, plus the IMUs, GNSS modules, motor drivers, and baros that ship around them. Ask about a peripheral, the answer comes from our KG and the actual datasheet. Second, you can bring your own context and share it with your team. Hydron indexes PDFs up to 5000 pages, plus a whole host of various file types and even ZIPs of full C/C++/Python codebases up to 250MB. One engineer indexes the HW, BSPs, and datasheet pack once. Anyone else can reference it from their own Hydron agent. Third, HW-SW development happens in your editor or terminal. Agentic serial monitor is live today. GDB integration, and an AI log reader land in the next two weeks. Up next, we're focused on closing the hardware-software loop. We're building more HIL debugging capabilities, deeper target awareness, and support for additional platforms. If you work on embedded SW we'd love your feedback on where today's tools fall short and what you'd like to see next. Install: VS Code extension - https://marketplace.visualstudio.com/items?itemName=H2Loop.h... CLI mac/linux -> curl -fsSL https://get.hydron.sh/cli/install.sh | bash. CLI windows -> irm https://get.hydron.sh/cli/install.ps1 | iex More at http://boot.hydron.sh/HN. 200 free credits, 50% off on paid plans, one-step signup. Me and u/ajithhyd will be in the thread all day.
Open Terminal
Show HN: Open Terminal – A Bloomberg Style App for Research
Boxes.dev: ditch localhost; run Claude Code and Codex in the cloud
Hi HN, we’re Nick and Drew, and we’re building boxes.dev – the first cloud-only agentic dev environment (ADE) that gives every Codex and Claude Code agent its own cloud computer. We’re two engineers who previously built Gem (co-founder/CTO and first hire), and we spent the last year coding almost exclusively using Codex and Claude Code. It’s been a huge change to how we code, and it’s been exhilarating seeing the models keep getting better – but we eventually realized that developing on localhost was holding us back: - Git worktrees are clunky to set up and use for parallelizing work - It’s 2026, but somehow everyone is still walking around with laptops cracked open or SSHing into mac minis in their garage so their agents don’t stop working. - Mobile is treated like an afterthought even though coding is just texting now We started hitting resource constraints when multiple parallel agents test their own work by running the full app locally. - We tried different products, but couldn’t find any that solved all of our pain points – so we pivoted and decided to just build the ADE we wanted for ourselves. Boxes.dev is a desktop and mobile app that lets you run Claude Code, Codex (using your subscription!), and the full dev environment for whatever you’re building, all on remote compute. It’s similar to Conductor or the Codex desktop app, except everything is in the cloud. We use coding agents to scan your local dev setup and port it to the cloud. Then every Claude Code/Codex thread starts from a snapshot of the full setup, with its own filesystem and compute. No more git worktrees, no more cracked-open laptops, and your coding agents can actually test their work end-to-end because they can run your full app in isolation. We’ve mirrored the Claude Code and Codex UX to feel natural to power users, and also have a fully-featured mobile app (no handoffs or remote control), plus scheduled automations and a Slack integration. We’re obviously biased, but we’ve been building boxes.dev with boxes.dev for months and it’s honestly been a gamechanger. It’s hard to go back once you realize how much localhost has been limiting you; based on early feedback from beta testers, we’re increasingly sure that cloud is the future of agentic coding. We’d love for you to experience it yourselves! Would appreciate any feedback – and happy to answer any questions on this thread.