Too Green To Go

Inspiration

Every year, 30% of Europe's renewable energy is curtailed (wind turbines braked, solar farms throttled) because there's no demand-side flexibility to absorb the surplus. Meanwhile, three countries over, AI companies pay premium rates to run LLM inference on coal-powered grids. We saw a $47 billion collision: wasted clean energy on one side, overpriced dirty compute on the other.

The trigger was a stat from Crusoe Energy: flared natural gas alone wastes 150 billion cubic meters per year, enough to power every GPU on Earth. We asked ourselves: what if AI workloads could chase clean energy in real-time, the same way Uber matches riders to drivers? What if wasted energy could become AI compute, automatically, in seconds?

That's TO GREEN TO GO, The marketplace where green energy powers AI.

What it does

To Green To Go is a real-time GPU arbitrage platform that routes AI workloads to wherever clean energy is cheapest (across 11 grid zones in Europe) and reroutes them mid-execution when the energy landscape shifts.

For AI developers (B2B): Submit a workload (model fine-tuning, inference, batch processing), set a carbon budget and price ceiling, and the platform's broker agent automatically places it on the greenest, cheapest GPU available. If carbon intensity spikes mid-run, the workload is checkpointed and live-migrated to a cleaner node, zero downtime.

For GPU providers (B2C): Gamers with idle RTX 4090s register their hardware. When their local grid goes surplus (>50% renewable), inference jobs land on their GPU and they earn instant payouts via Solana.

For energy recyclers: Facilities powered by waste heat (steel plants, biogas co-gen, district heating) are Tier 1 providers, always green, always prioritized.

The secret sauce: a 3-tier priority broker

Priority	Source	When it triggers
Tier 1	Energy Recyclers	Always on, waste heat is perpetually green
Tier 2	B2B Data Centers	During surplus/curtailment windows
Tier 3	B2C Gamers	When local grid is >50% renewable

Every node is scored: 60% carbon intensity + 30% energy price + 10% GPU utilization. The best score wins. If no full GPU matches, NVIDIA MIG slicing kicks in, underutilized GPUs (<70%) are fractionally partitioned and sub-leased.

The platform monitors continuously. When conditions degrade by more than 25%, it triggers adaptive rerouting (checkpoint, migrate, resume) up to 5 times per workload. Every decision is logged with full audit trails and carbon receipts.

How we built it

Backend, Ruby on Rails 7.1 serving a RESTful JSON API with 14 database models and 12 domain services:

BrokerAgentService (420+ lines): The brain, tiered priority matching, composite scoring, adaptive rerouting with checkpoint-based live migration
GreenComplianceEngine: Filters nodes by renewable thresholds, surplus status, and carbon constraints
DynamicPricingService: Real-time pricing with base rates per GPU model (H100: €3.50/h → RTX 3070: €0.35/h), surplus discounts up to 30%, green premiums, demand multipliers, and time-of-day adjustments
GpuSlicingService: Automatic MIG partitioning, detects underutilization, creates up to 7 virtual slices per GPU, reclaims when load returns
GridDataService: Monitors 11 energy zones (FR, DE, ES, PT, NL, BE, IT, GB, US-CAL, US-NY, US-TX) with carbon intensity, renewable percentage, and spot pricing
CheckpointService: Periodic state snapshots enabling zero-downtime workload migration
StripeService + SolanaService: Dual settlement, metered billing for enterprises, instant crypto payouts for gamers

Frontend, React 18 + TypeScript + Vite with 10 pages, 49 shadcn/ui components, and a dark-mode green-themed design system:

TanStack React Query with auto-refresh intervals (8–20s), the dashboard feels alive, metrics update without page reloads
5 role-based views (Developer, Datacenter, Gamer, Recycler, Admin) with dynamic sidebar navigation
Live features: job submission → auto-routing → progress tracking, GPU marketplace with one-click deploy, energy heatmap across 11 regions, 30-day dynamic pricing charts, CO₂ offset tracking

Database: SQLite with 14 tables seeded with 13 real organizations (Crusoe Energy, Equinix, OVHcloud, Hetzner, Mistral AI, Hugging Face), 20 compute nodes, and realistic workload/grid data.

Integration: Vite proxies all /api/* requests to the Rails backend, seamless dev experience on separate ports (8080 → 3000).

Challenges we ran into

1. The scoring algorithm was deceptively hard. Balancing carbon, price, and utilization across heterogeneous GPUs (H100 vs. RTX 3070) in different grid zones with different energy mixes required careful normalization. We went through 4 iterations of the composite scoring formula before landing on the 60/30/10 weighting that produced sensible routing decisions.

2. Adaptive rerouting without data loss. The concept is simple "just move the workload" but implementing checkpoint-based live migration that actually preserves state, handles edge cases (node goes critical mid-checkpoint, max reroutes exceeded, no better alternatives), and maintains an audit trail was the hardest engineering challenge. The reroute logic alone is 120+ lines with 6 failure modes.

3. MIG slicing economics. Figuring out how to price fractional GPU slices fairly, so that a 1/7th slice of an H100 during surplus is cheaper than a full RTX 4090 on a dirty grid, required the dynamic pricing engine to incorporate tier discounts, surplus detection, and demand multipliers simultaneously.

4. Making the frontend feel real-time. With 8 different API endpoints refreshing at different intervals (8s for jobs, 20s for sustainability), we had to prevent UI flicker, handle loading/error states gracefully, and ensure React Query's cache invalidation didn't cause jarring re-renders. The LoadingState component evolved through multiple iterations.

5. Full-stack integration in a weekend. Wiring 14 models → 12 services → 8 API controllers → TypeScript API client → React Query hooks → 10 pages was a massive integration surface. A single mismatched field name could break an entire page. We caught and fixed dozens of shape mismatches between backend JSON and frontend TypeScript types.

Accomplishments that we're proud of

The broker actually works. Submit a workload, and it genuinely evaluates all node candidates across 3 tiers, scores them on carbon + price + utilization, picks the best one, and logs the full decision reasoning. It's not a mock, it's a real routing engine.
Adaptive rerouting with live migration. When grid conditions change, workloads are checkpointed and moved to greener nodes automatically. Up to 5 reroutes per workload, with a 25% improvement threshold to avoid unnecessary churn.
MIG GPU slicing as a market feature. Underutilized H100s automatically create virtual partitions that smaller workloads can rent. This turns waste compute into revenue, the same philosophy we apply to waste energy.
A full-stack production-shaped system in one weekend. 14 database tables, 12 backend services (420+ LOC for the broker alone), 8 API endpoints, a complete TypeScript API client, React Query hooks, and 10 live-updating frontend pages, all integrated end-to-end.
Real organization modeling. Crusoe Energy, Equinix, OVHcloud, Mistral AI, Hugging Face, the seeded data reflects real market participants, real GPU models (H100, A100, RTX 4090), and real grid zones with plausible carbon intensities.
Dual settlement stack. Stripe for B2B metered billing and Solana for instant B2C gamer payouts, two very different payment paradigms unified under one platform.

What we learned

Energy markets are surprisingly accessible. APIs like Electricity Maps provide real-time carbon intensity and renewable mix data for most European and US grid zones. The data quality is good enough to make routing decisions on.
The scoring function IS the product. The 60% carbon / 30% price / 10% utilization weighting isn't just a formula, it encodes an entire philosophy about what matters. Changing those weights would create a fundamentally different platform. We learned that the broker's scoring weights are a strategic decision, not a technical one.
GPU underutilization is a massive hidden cost. Most datacenter GPUs run at 30-50% SM utilization. MIG slicing can turn that idle 50% into revenue. The economic case for fractional GPU allocation is overwhelming once you do the math.
Hackathon architecture decisions compound fast. Choosing Rails + React + shadcn/ui gave us incredible velocity, but the integration surface between backend JSON shapes and frontend TypeScript types was the primary source of bugs. Type safety at the API boundary is critical.
Green computing is a real market, not just CSR. The 15-30% cost reduction from energy arbitrage alone justifies the platform, the carbon savings are a bonus, not a trade-off. That's the insight that makes this commercially viable.

What's next for Too Green To Go

Live grid data integration, Connect to Electricity Maps API and ENTSO-E for real-time carbon intensity feeds instead of simulated snapshots
Kubernetes orchestration, Deploy workloads as actual K8s pods with GPU scheduling, NVIDIA MIG partitioning, and CRIU-based live migration
Solana carbon receipts, Mint on-chain NFTs proving each workload ran on verified green compute, auditable, tradeable, and composable
Provider SDK, A lightweight daemon that gamers install to auto-register their GPU, run benchmarks, and receive workloads when their grid goes green
Predictive routing, ML model trained on historical grid data to predict surplus windows 2-4 hours ahead, enabling pre-positioning of async workloads
Multi-cloud federation, Extend the broker to route across AWS, GCP, and Azure spot instances, scoring them on the underlying grid's carbon intensity
Mobile app, Push notifications for gamers when their GPU earns money, and for operators when curtailment events trigger surplus routing