Watch: How an AI agent rewrites its own food routing logic, tests it against real cities, and keeps only what feeds more people.
🔊 Listen: The full story behind this fork.
Why Karpathy's pattern works for food routing. How the scoring engine learns.
What happens when you let an AI rewrite its own matching logic 200 times an hour.
HELIOS AutoResearch: Self-Improving AI Food Routing
No GPU. No funding. No organization. Just a scoring engine that gets better at feeding people every iteration.
A fork of Karpathy's autoresearch. Same pattern. Different target. Instead of optimizing neural networks, this one optimizes how surplus food reaches hungry families.
119 billion pounds of food wasted in the U.S. every year. 34 million Americans not eating enough. The gap between surplus and need is not a supply problem. It is a routing problem.
An AI agent takes a food matching engine, rewrites its scoring logic, tests the changes against real city data across Nashville, Memphis, Chicago, Atlanta, and Knoxville, measures whether more meals got matched more efficiently, keeps what works, throws away what doesn't, and does it again. No stopping. No human in the loop. No GPU. Runs on a laptop in under a second per experiment.
Karpathy proved autonomous AI research works for training neural nets. This fork points that same loop at feeding people.
Three files. Same structure as the original.
| File | Role | Who modifies it |
|---|---|---|
route.py |
Food routing scoring engine (weights, formulas, matching logic) | The AI agent |
evaluate.py |
Fixed evaluation script. Loads scenarios, measures results. | Nobody. Read-only. |
program.md |
Agent instructions. How to run experiments, what to optimize. | The human |
The agent reads program.md, then enters an infinite loop:
1. Modify route.py (try a new scoring strategy)
2. Run evaluate.py (measure helios_score)
3. Score went up? Keep it.
4. Score went down? Throw it away.
5. Go to 1.
Each iteration takes under a second. An agent can run 200+ experiments per hour. Leave it running overnight and wake up to a routing engine that's better at feeding people than it was when you went to sleep.
The evaluation script scores routing quality across five dimensions:
| Component | Weight | What it measures |
|---|---|---|
| Match rate | 30% | Did every hungry family get matched to a food source? |
| Match quality | 25% | How good are those matches? (distance, freshness, quantity) |
| Supply utilization | 20% | How much available food actually got routed? |
| Distance efficiency | 15% | Are matches close, or wastefully far apart? |
| Dietary satisfaction | 10% | Did families with dietary needs get appropriate food? |
Higher is better. The baseline scores 0.7753. Beat it.
Test data covers 10 food suppliers and 10 food needs across real U.S. cities (Nashville, Memphis, Chicago, Atlanta, Knoxville, Cookeville). Includes restaurants, grocery stores, farms, caterers matched against food banks, shelters, soup kitchens, and community events. Mix of dietary constraints (halal, vegan, kosher, gluten-free), varying urgency levels, and volume mismatches.
All coordinates are real. All distances are calculated using the Haversine formula on real latitude/longitude.
No GPU. No cloud account. No API keys. Python 3.10+ and a terminal.
git clone https://github.com/jmthomasofficial/helios-autoresearch.git
cd helios-autoresearch
# Run the baseline
python evaluate.py
# Point your AI agent at program.md and let it goTo start an autonomous research loop with Claude Code:
Read program.md and kick off a new experiment. Do the setup first.
The agent takes it from there.
The baseline route.py scores each food-supply-to-food-need pair using four signals:
Distance (40% weight): Exponential decay. A restaurant 2km from a food bank scores near 1.0. One 200km away scores near 0.
Perishability (30%): Food expiring in 2 hours is urgent. Food expiring in 2 days is not. Linear decay over 48 hours.
Volume match (20%): 50 surplus meals matched to a need for 50 scores 1.0. 50 matched to a need for 200 scores 0.25. Rewards right-sized matches.
Dietary fit (10%): A halal food bank needs halal food. Partial credit for partial matches. Full credit if no dietary restrictions.
These weights, these formulas, these curves are what the agent optimizes. Maybe distance should be 50% instead of 40%. Maybe perishability should use exponential decay instead of linear. Maybe there should be a fifth signal for geographic clustering, or a bonus for supplier reliability, or an asymmetric penalty when supply falls short of demand. The agent discovers what works.
The autoresearch engine optimizes scoring weights against test scenarios. That is step one. Step two is connecting it to real food moving through real cities. Here is how the full feedback loop works.
A bagel shop has 50 pounds of bagels at closing time. The owner texts a local HELIOS number: "50 bagels ready." That is the entire interaction. No app download. No account. No login. One text message.
The system parses the message, creates a supply listing, and the routing engine picks it up immediately. For repeat businesses, it gets even simpler: HELIOS texts them at their usual surplus time ("Surplus tonight? Reply Y"), and they reply one letter.
Future phases add POS integration (Square, Toast, Clover send end-of-day inventory automatically), pattern prediction (the system learns that this bakery has surplus every Friday at 7pm), and community tips from volunteers who know local businesses.
A volunteer running the HELIOS app (a Progressive Web App, no app store required) sees the mission: "Pick up 50 bagels at Joe's Bakery, deliver to Second Harvest Nashville, 3.2 km." They accept. The routing engine chose them because they were closest, had a car, and had a strong completion history.
At pickup, the volunteer takes a photo and counts the actual quantity. Listed: 50 bagels. Actual: 42 (8 were already stale). That discrepancy is data.
At delivery, another photo, a confirmation from the recipient, and a quick rating. The recipient org gets a follow-up text: "Rate this delivery 1-5."
Every mission captures ~30 data points: timestamps, GPS coordinates, actual quantities, food condition, photos, ratings, waste reasons. This is the raw material.
When the routing engine created that match, it predicted a score. Call it 0.83. That score was based on haversine distance, listed quantity, stated dietary needs, estimated freshness.
After the mission completes, the system recomputes the score using ground truth: actual quantity delivered, actual transit time, actual food condition, recipient satisfaction. Call the real score 0.71.
The gap (0.83 predicted, 0.71 actual) is the error signal. The system overestimated this match. Why? The bakery overstated quantity by 20%, and the food condition was "fair" not "excellent." Next time this bakery reports surplus, the routing engine discounts its listed quantity and adjusts the freshness assumption.
The synthetic scenarios in scenarios.json are the starting point. As real missions complete, they get added to the evaluation dataset. Now evaluate.py scores route.py against both synthetic and real scenarios where the actual outcome is known.
The autoresearch agent optimizes for two things simultaneously:
- helios_score (are matches good?)
- prediction_accuracy (does predicted score match actual outcome?)
A routing engine that makes great matches but can't predict its own performance is unreliable. A routing engine that predicts accurately but matches poorly is useless. The autoresearch loop pushes both numbers up.
Over hundreds of real missions, the system learns patterns no human would program: which food types lose quality faster than expiry dates suggest, which neighborhoods have traffic that makes haversine distance misleading, which volume ratios actually result in completed deliveries versus partial waste. The scoring weights in route.py evolve to reflect reality.
After 10+ missions from a business, the system builds a profile: quantity accuracy (do they overstate?), availability consistency (are they actually ready when they say?), food quality track record. This profile becomes a multiplier in the routing score. Reliable businesses get prioritized. Unreliable ones get their numbers adjusted before matching.
Physical pickup and delivery. Always. Building relationships with businesses. Always. Community organizing. Always. Deciding where to expand next. Always.
The AI optimizes routing math. Humans move food and build trust. That split is permanent.
Every fork of autoresearch so far optimizes loss curves. This one optimizes meal delivery.
The scoring engine you see in route.py powers a real food routing system at feedhumanity2026.com. Improvements found by the autoresearch loop get deployed to the live system. Better helios_score = more families fed.
There is no organization behind this. No nonprofit. No corporation. One person built the router. AI agents improve it. Anyone can fork it, run it for their city, and contribute improvements back.
Decentralized. Open source. Self-improving. Forever.
Built on top of Project HELIOS: Feed Humanity, an open-source AI system that connects surplus food to hungry families. The matching engine, food bank search, impact tracking, and AI playbook generator are all live and working.
Forked from karpathy/autoresearch (MIT License).
The original autoresearch proved that AI agents can do autonomous ML research. This fork asks: what if we pointed that same pattern at something that actually feeds people?
The best way to help:
- Run experiments. Fork this repo, point an agent at
program.md, and see if you can beat the current best helios_score. Submit your bestroute.pyas a PR. - Add scenarios. More cities, more edge cases, more diversity in supply/demand patterns.
- Add scoring dimensions. The baseline has four signals. What's the fifth? The sixth? Time-of-day factors? Supplier track record? Multi-hop routing chains?
MIT