Hacker Newsnew | past | comments | ask | show | jobs | submit | dim0r's commentslogin

Hey HN! Founder here.

I run a small fleet of agents: Claude Code, Codex, Hermes, a couple of custom ones. I kept failing to answer a simple question: what did they actually do last night, and what did it cost me?

It grew into the thing I now use every day: a control plane that sits between my agents and everything they touch — their models and their tools — so I can see what they're doing, gate what they're allowed to do, and cut what they waste.

What it does, concretely:

- *See them.* Onboard agents with one command — the CLI discovers Claude Code, Codex, OpenClaw, OpenCode and friends on your machine, backs up their config, and routes them through Preloop. You get live and historical sessions: every prompt, tool call, and token, with cost per session.

- *Govern them.* An MCP firewall with allow / deny / require-approval rules (per tool, with tiers — e.g. auto-allow payments under $100, human approval to $2,000, deny above). Approvals reach your phone or watch, and they're async — the agent keeps working while a human decides.

- *Cut their cost.* This part recently went open source: session autopsies find concrete waste (unused tools loaded into every request, tool-output fields nothing ever reads, cache-breaking prompts), one click applies the fix at the gateway — no agent code changes — and you can replay the same session through the fix to verify the savings instead of trusting an estimate. Analysis runs on your own model keys (BYOK).

Everything is self-hosted (Apache-2.0, docker compose, helm) — your prompts and traffic stay on your infrastructure. There's a hosted version if you don't want to run it, which is how the project pays for itself: the paid tier is hosting, teams/RBAC/SSO, and hosted-compute analysis. The loop itself is in the open-source core.

Honest limits, since you'll find them anyway:

- Subscription-billed agents (e.g. Claude Code on a Pro/Max plan) pass through byte-faithfully — you get sessions, governance, and budgets for that traffic, but message-level context optimizations only apply to API-key traffic. (Anthropic tightened validation on subscription OAuth requests recently; we pass the exact original payload through rather than rewrite it.)

- Claude Desktop and Cursor are MCP-governed only — their model traffic can't be repointed, so cost analysis doesn't cover it.

- Savings figures are per-session and replay-verified where shown; we don't publish an average because it depends entirely on how wasteful your agents were to begin with. Mine were embarrassing.

I made a short video series showing the whole loop on my own agent fleet: https://www.youtube.com/watch?v=Y_geb2Or8zM&list=PLr2Jp0c-Qn...

Try it: `curl -fsSL https://preloop.ai/install/oss | sh` (self-hosted) — or the hosted version at https://preloop.ai. I'll be here all day; the sharpest criticism gets the most attention.


CTO here.

We built this because we’re seeing a shift from "chatting with agents" to event-driven flows (agents reacting to webhooks, PRs, or tickets in the background).

The problem we hit was responsibility. An agent can technically execute a stripe.refund tool call, but it cannot weigh the consequences of a $50 refund vs. a $5,000 refund. It lacks the context of risk.

We built the proxy to bridge that gap. It lets the agent run autonomously 99% of the time, but forces a "hardware interrupt" (human check) when the stakes get high. We handle the state management of pausing that headless workflow so you don't have to build custom polling logic into every bot.


War crimes committed by a superpower != personal secrets


Every member of our ops team has the following PS1 var in .bashrc to prevent such accidents:

  PS1='\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]\[\033[01;33m\] [`kubectl config current-context| rev | cut -d_ -f1 | rev`] \[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\] $ '


Multi-Cloud can be hard to do right and there are plenty of traps along the way. It sure doesn't make sense to go that way just for Disaster Recovery, unless you need to be prepared for the unlikely event that Amazon or Google will suddenly get wiped out of the planet.

That said, going Multi-Cloud is indeed unavoidable in a growing number of settings. So, instead of looking at it as a source of troubles, it can be leveraged as a way to extract the best features out of each provider, to avoid lock-in wherever it makes business sense and to minimize costs by distributing workloads accordingly. That introduces new issues regarding access control, cost analysis, auditing and governance which are best managed by a Multi-Cloud Management Platform.

If you're looking for such a tool check out https://mist.io

It's an open source CMP that supports most popular public & private clouds, as well as Hypervisors and container hosts. It takes care of provisioning, monitoring, RBAC, cost analysis and automation/orchestration. It can also be used to deploy Kubernetes clusters on any supported cloud.

Disclaimer: I'm one of the founders.


There, open source, that's the key point to avoid lock-in.

There is no problem with going with any single provider, as long as you "can" replicate any functionality you're using. You may never actually replicate it, but that ability is what makes me trust a provider... because even if they fail, I know it won't be too much of a problem.


Mist.io provides a Cloudify blueprint that can be used to deploy and scale Kubernetes clusters on any supported cloud. It's using kubeadm under the hood.

https://docs.mist.io/article/119-kubernetes-getting-started-...

Disclosure: I'm one of the founders


mist.io supports most public and private cloud platforms. Also, it's open source https://github.com/mistio/mist-ce


What's the difference between mist.io and Apache's libcloud?


Apache libcloud is a Python library that's used primarily to create, reboot & destroy machines in any supported cloud.

Mist.io is a cloud management platform that uses Apache libcloud under the hood. It provides a REST API & a Web UI that can be used for creating, rebooting & destroying machines, but also for tagging, monitoring, alerting, running scripts, orchestrating complex deployments, visualizing spending, configuring access policies, auditing & more.


Also check out Mist.io. It's an open source multi-cloud management platform that abstracts the infrastructure layer to help you avoid the lock-in.

Disclosure: I'm one of the founders.


What's the difference between mist.io and Apache's libcloud?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: