No H100? No Problem. Why I Built ML Patron for Autonomous AI Research

Andrej Karpathy recently open-sourced autoresearch—a project that lets an AI agent run experiments, iterate on code, and keep successful improvements automatically. It can churn through hundreds of experiments overnight on a single GPU. Not long ago, I wrote an article about "vibe research." The era of autonomous research isn’t just a concept anymore; it’s happening.

But there’s a catch: autoresearch assumes you have an H100. Karpathy has them. High-end labs have them. Most of us don't.

I’m a software engineer who has spent years building AI infrastructure, but model architecture and algorithms remain a passion project for me. I don’t have a lab, and I don't have a cluster. I have ideas, and I have coding agents to help me write the scripts, but every time I want to actually run an experiment, I hit a wall.

I’ve realized that three main things stifle independent research: experiment costs, execution infrastructure, and research continuity.

Sometimes I have too many ideas and can’t justify funding them all. Other times, implementing the algorithm is the easy part, but getting the infrastructure to behave is a nightmare. And even when I do manage to run a test, the context—the "why" behind a specific parameter—ends up scattered across codebases, chat logs, and my own fading memory. I wonder how many great ideas have died simply because the path to testing them was too friction-heavy.

That’s why I built ML Patron.

What is ML Patron?

ML Patron is a platform where researchers can submit experiments and interested supporters can fund them. The platform handles the heavy lifting: it spins up cloud resources, runs the experiment, and preserves all code, parameters, metrics, and artifacts. Research notes and discussions are synced directly to the run.

Researchers don't have to shoulder the full cost, build their own environments, or worry about losing context once the training finishes.

1. Bridging the "Funding Chasm"

Most good ideas don't need a massive budget; they just need that first push. When an idea first pops into your head, it’s unproven. It’s not worth a $10,000 investment yet. Usually, you don't face active opposition—you just hear, "Sounds cool, run a baseline and let's see."

But "running a baseline" costs money. The moment GPUs and cloud providers are involved, someone has to foot the bill.

We have VCs for companies and Kickstarter for consumer products. But early-stage ML experiments fall into an awkward middle ground: they are too "heavy" to just run on a laptop, yet too "light" for formal fundraising. ML Patron fills this gap. Anyone can back an experiment with a few dollars—no committees, no formal proposals. If someone thinks it's worth a shot, it gets run.

2. Outsourcing the Infrastructure Tax

Coding agents can write almost any script today. But moving from "code that works" to "an experiment that runs" requires a lot of "infra-work": managing GPU clusters, locking environments for reproducibility, and setting up storage for metrics and artifacts. It’s not necessarily hard, but it’s tedious—and it shouldn't be every researcher's job to rebuild this from scratch.

ML Patron takes over this layer. You submit your repo, pick your GPU, and set your parameters. The platform handles scheduling, resource allocation, and execution. Metrics are automatically logged to a cloud-hosted MLflow. We even run a "dry run" first to ensure the pipeline works at a minimal cost. You don't need to write K8s YAMLs or manage clusters.

3. Solving for Research Continuity

Research isn't a series of isolated events; it’s a chain of decisions. Why did we pick this config? Why did we abandon that direction? What was that weird spike in the loss curve? In today’s fragmented environment, this context leaks. Code is in GitHub, discussion is in Slack, results are in logs, and the explanation is in your head. A few days later, you’re left with fragments. This is true for humans, and even truer for agents, where the "reasoning" might only exist in a 1M-token context window that’s about to be compacted.

ML Patron attaches research notes and discussion boards to every project and run. The goal is to make logs more than just status updates—they are the narrative of the research itself.

Designing for the "Agent-Native" Era

Beyond these three pillars, there is one core design philosophy: Treat AI agents as first-class citizens.

Since the rise of OpenClaw, we’ve seen what agents can do—operating computers, calling APIs, and completing real tasks. Tools like Claude Code and Cursor have made agentic coding a daily reality. Yet, most platforms still force agents to interact through UIs designed for humans, requiring them to either scrape HTML or rely on a human middleman.

I believe that shouldn't be the case. Agents can already understand rules and analyze results. They deserve a clean entry point.

That’s why ML Patron is API-first. Everything you can do in the frontend—creating projects, submitting experiments, funding runs, checking metrics—can be done via API. We even provide a public skill.md that describes the platform’s capabilities and how to call them. An agent can read this one file and start working immediately.

The Proof of Concept: Claude Code vs. Nanochat

I tested this workflow by asking Claude Code to find a reasonable baseline configuration for nanochat within a set budget.

The agent read skill.md to understand the workflow.
It estimated the cost and submitted the config.
It ran a dry run to verify the code.
It triggered the funding and started the full experiment.
When a GCP spot instance was preempted, the agent read the logs, realized it wasn't an OOM (Out of Memory) error, and simply resubmitted the run.

I stayed on the sidelines, providing high-level direction, while the agent pushed the experiment forward. It proved my hypothesis: if the API is complete and the documentation is clear, agents don't need "special features"—they just need a platform that doesn't get in their way.

The Path Forward

ML Patron is still in its early stages—more of a prototype built to solve a specific set of frustrations. I don’t yet know which parts will fit into other people’s workflows and which are just my own quirks.

But I am certain of one thing: as ideas, code, and analysis become cheaper, the execution of experiments becomes the bottleneck. If autonomous research is truly coming, we don't just need smarter models; we need a layer that connects those ideas to physical resources—GPUs, environments, budgets, and logs.

That’s what I’m trying to build with ML Patron. I don’t know where it ends, but I know it’s worth trying now.

After all, many great ideas aren't proven wrong—they're just never run.

If you have an experiment that’s "worth a shot," come check us out at mlpatron.com.