hiloop

The AI research world has spent the last two years arguing about models: who has the best benchmark score, the largest context window, the most efficient inference. hiloop, a Y Combinator-backed startup, is making a quieter but arguably more fundamental bet: that the next leap in AI capability won't come from a single model, but from the infrastructure that lets autonomous agents run thousands of experiments on their own. The company's website doesn't lead with a model card or a benchmark. It leads with a phrase that would have sounded like science fiction a few years ago: "Infrastructure for automated research."

hiloop's premise is that we're entering an era where AI agents don't just answer questions—they propose hypotheses, run experiments, and verify results. This is what the company calls "autoresearch," a term popularized by Andrej Karpathy's work showing that an agent with a verifiable metric can improve a system on its own. But running thousands of experiments at scale requires more than a clever prompt. It requires compute that can be snapshotted, forked, and restored; observability that can trace every action; and a way to make sense of it all. That's the gap hiloop is trying to fill.

The missing layer for autonomous research

Most ML infrastructure today is built for humans. You write a training script, launch it on a cluster, monitor the loss curve, and manually tweak hyperparameters. But autoresearch inverts this workflow: the agent is the one proposing changes, launching runs, and deciding whether to keep or discard them. This creates a new set of requirements that traditional MLOps tools weren't designed for.

hiloop's homepage lays out the problem in three words: "snapshot · fork · restore." The idea is that every experiment should be a branch in a tree, not a linear sequence. When an agent tries a new learning rate or a different prompt strategy, it forks the current state, runs the experiment, and either merges the result or restores the parent snapshot. This is a fundamentally different model from the typical "launch a job, wait, see the metrics" approach. It's more like version control for compute—git for experiments, if you will.

The company's blog post "Decouple, decouple, decouple" elaborates on this philosophy. The authors argue that what an autoresearch loop needs changes constantly, so they've decoupled the harness, the compute, and the data from each other, coupling only experiment state and observability. This is a deliberate architectural choice: instead of building a monolithic platform that does everything, hiloop provides a set of primitives that can be composed in unexpected ways.

Forkable compute: a primitive, not a feature

hiloop's core primitive is the forkable run. The command-line tool hiloop run wraps any command—whether it's a homegrown eval script or an off-the-shelf reinforcement learning loop—and provisions compute, captures every event, and tags it with the fork it belongs to. The example on the website shows an agent using Claude Code to propose a cosine learning rate schedule, run a training script, observe that the validation bits-per-byte got worse, and then restore the parent snapshot. All of this is recorded in a single trace.

This is more than just a nice debugging tool. It's the foundation for autonomous experimentation. Without snapshots, an agent can't safely try radical ideas—it might ruin hours of training progress. With forkable compute, the agent can branch off, try something crazy, and if it fails, restore the parent state in seconds. The risk of exploration drops dramatically, which is exactly what you want if you're trying to get an AI to improve itself.

The security model is also worth noting. The site mentions that secret values are write-only to callers and encrypted at rest, and that sandbox bindings fail closed until proof-bound request-time delivery ships. This suggests hiloop is thinking about the security implications of giving agents access to compute and secrets—a concern that most infrastructure providers have only started to grapple with.

Observability as a query engine, not a log viewer

One of the most interesting design decisions hiloop has made is in observability. Instead of a fixed dashboard with predefined charts, hiloop captures one raw record of everything an agent did and provides a query engine that can reshape it into whatever the research needs. The blog post "Telemetry and a query engine designed for autoresearch" explains this: "We capture low and reconstruct high."

This is a subtle but important point. Agent harnesses change every week, so pinning a fixed schema or a fixed set of queries to a moving target would be a mistake. Instead, hiloop stores every event—LLM calls, tool executions, stdout—as a trace, and lets you query it with SQL. This means you can ask questions like "how many times did the agent try a learning rate above 0.01?" or "what was the average cost per run for the last 100 forks?" without waiting for the vendor to add a new feature.

The site also mentions that tokens and estimated cost are rolled up per model, which is crucial for anyone running large-scale experiments. If you're spending thousands of dollars on compute, you need to know where it's going. hiloop's approach makes that transparent.

The open question: how do you actually run autoresearch?

hiloop is honest about the fact that the field is still nascent. The blog post "We don't know how to run autoresearch" admits as much: "We don't know how you'll run autoresearch, and you don't fully know either until you're in it." This is a refreshingly candid take from a company building infrastructure for something that doesn't have a playbook yet.

Instead of shipping a fixed set of eval features, hiloop has shipped one primitive: user-defined annotations that you can attach to any point, range, or run, and query like any other telemetry. This is a bet that the community will figure out the best practices, and hiloop will provide the raw material for them to do so.

The company's own research blog post "Search is enough" provides a proof point. Two stock coding agents with 50 B200s ran 4,188 experiments on Karpathy's autoresearch benchmark and reached a confirmed 0.9016 val_bpb, past the published state of the art, with almost no scaffolding. This is a remarkable result, but it's also a single data point. The question remains: can this scale to more complex tasks, and can other teams replicate it without hiloop's help?

Naming the loop: hiloop's brand bet

The name "hiloop" is a portmanteau of "hi" and "loop," suggesting a friendly, iterative process. It's short, memorable, and easy to type, which is a plus for a developer tool. The lowercase styling and the .ai domain reinforce the AI-native positioning. The name also evokes the idea of a feedback loop—the core mechanism of autoresearch, where an agent proposes, runs, and verifies experiments in a continuous cycle.

Compared to competitors with more descriptive names like "Weights & Biases" or "Comet," hiloop is more abstract. It doesn't tell you what the product does; it tells you what it enables. This is a risk: developers might not immediately understand what hiloop does from the name alone. But it's also a branding opportunity. As autoresearch becomes more mainstream, hiloop could become the category name, just as "Google" became synonymous with search.

The tagline on the YC launch page is more explicit: "we run thousands of experiments to improve your models." This positions hiloop as a service, not just infrastructure. But the website's own tagline—"Infrastructure for automated research"—is broader and more ambitious. The company seems to be straddling two identities: a managed research service and a platform for building your own autoresearch loops. It's not clear which one will win out, but the infrastructure-first approach suggests they're betting on the latter.

Who should care—and what's still unproven

hiloop is not for everyone. If you're a data scientist who manually tweaks hyperparameters and runs a few dozen experiments a week, this is overkill. But if you're building an AI agent that needs to improve itself, or you're training models where every point of accuracy and every dollar of compute counts, hiloop is worth a look.

The company is clearly targeting three audiences: teams building autoresearch systems, teams training models, and teams where performance is the product—whether that's speed, latency, memory, or cost. The website's "Who it's for" section is refreshingly specific, which suggests the founders have a clear sense of their initial market.

What's still unproven is whether hiloop can become the default infrastructure for this new paradigm. The company is Y Combinator-backed, which gives it some credibility, but it's early days. The blog posts are thoughtful and the technical design is sound, but there's no public pricing or detailed documentation yet. The 404 on the docs page is a reminder that this is a work in progress.

For now, hiloop is a bet on a future where AI research is conducted by AI itself. The infrastructure is clever, the naming is memorable, and the team seems to be thinking deeply about the right primitives. Whether that's enough to build a lasting company remains to be seen. But for anyone watching the evolution of AI, hiloop is a name worth remembering.