DEV Community: Vishal Keerthan

ClimateOS — I Built a Climate Decision Engine, Not Another Carbon Tracker

Vishal Keerthan — Sun, 19 Apr 2026 17:43:41 +0000

This is a submission for Weekend Challenge: Earth Day Edition

Climate tools don't have a data problem. They have a decision problem.

Most products fall into two failure modes:

Carbon trackers — dashboards that show you what you already did wrong
Generic AI wrappers — "here are 10 tips to reduce your footprint," unranked, with no constraints

Neither answers the only question that actually matters:

Given my life, my budget, and my time — what should I do next?

That's not an information gap. It's a prioritization gap. So I built a decision engine.

What I Built

ClimateOS takes your lifestyle inputs and outputs a ranked, constraint-aware action plan. Not a report. Not suggestions. A plan — with a hierarchy, explicit tradeoffs, and one clear first move.

Instead of tracking past emissions, it simulates future impact and returns:

A projected score improvement (e.g. 42 → 86)
A ranked action playbook with reasoning for each action
One Hero Action — the single highest-ROI change for your specific situation

The framing underneath: climate action is a resource allocation problem. Given limited budget and time, what sequence of changes produces the maximum emission reduction? That's a solvable problem. Most apps just haven't tried to solve it.

Demo

👉 Video Walkthrough: https://www.loom.com/share/576c4f7d5f8f417390c28c8786183c01

Code

👉 GitHub:

pvishalkeerthan / ClimateOS

ClimateOS is a constraint-aware decision engine that moves beyond simple carbon tracking to provide prioritized, resource-aware action plans.

ClimateOS — A Decision Engine, Not a Tracker

"Climate tools don't have a data problem. They have a decision problem."

ClimateOS is a constraint-aware decision engine built to help individuals move from awareness to prioritized action. Instead of just showing you what you already did wrong (tracking), it simulates future impact and returns a ranked, resource-aware action playbook.

⚡️ The Core Premise

Most climate products fall into two failure modes:

Carbon Trackers: Dashboards that emphasize past mistakes.
Generic AI Wrappers: Unranked tips without context or constraints.

ClimateOS answers the only question that matters: Given my life, my budget, and my time — what should I do next?

🧠 The Hybrid Engine — Core Technical Decision

The defining feature of ClimateOS is its Hybrid Inference Pipeline. Pure LLMs are prone to "carbon hallucinations" (inconsistent math), while pure heuristic systems lack contextual reasoning. We split the labor:

Layer 1: Deterministic Heuristics

…

View on GitHub

How I Built It

User Journey

Step 1: Input

Eight inputs. Designed to be fast, not exhaustive:

Location
Daily commute (km)
Transport type — Car / EV / Public / Bike
Diet — Veg / Mixed / Non-Veg
Electricity usage (kWh/month)
Renewable energy %
Budget constraint — Low / Medium / High
Time constraint — Low / Medium / High

The constraint fields are the part most apps skip. They're also what makes the output usable.

Step 2: Processing Pipeline

Request hits /api/analyze:

Input validated via Zod schema
Deterministic emissions model computes baseline (no AI involvement yet)
Computed data — not raw inputs — passed to Gemini 2.0 Flash
AI output validated again via Zod before it touches the response
Ranked plan returned to client

Step 3: Results

Score transition: 42 → 86
Emissions breakdown by category (transport, diet, electricity)
Ranked actions with constraint filters applied
Hero Action called out separately — the one thing to do first

Example Output

For a user with:

25km daily car commute
mixed diet
low budget

ClimateOS identifies transport as the dominant source and prioritizes:

Reduce car usage (Hero Action)
Shift to public transport (partial)
Adjust diet (secondary impact)

High-cost options like EV or solar are rejected due to budget constraints.

Step 4: Simulation

Sliders for commute, diet, and renewable percentage. Every adjustment recomputes the score client-side, in real-time — no API call, no loading spinner, same heuristic logic as the backend. This turns a one-time report into an exploratory tool.

Architecture

Frontend     →  Next.js 15 (App Router) + React 19
Styling      →  Tailwind CSS + Framer Motion
API Routes   →  /api/analyze, /api/explain
Validation   →  Zod — applied to both input and AI output
AI Layer     →  Google Gemini 2.0 Flash
Identity     →  State-First, Database-Less Identity System (Auth0 + LocalStorage)
Simulation   →  Client-side heuristics via useMemo
Persistence  →  LocalStorage (results + user identity)

No traditional database. No auth overhead. Instead, a State-First, Database-Less Identity System: Auth0 provides a cryptographically-backed user sub that keys into LocalStorage, giving users full persistence and consistent identity across sessions — without cold starts, schema migrations, or a SQL layer.

The Hybrid Reasoning Engine — Core Technical Decision

This is the part most "AI climate tools" get wrong.

Handing raw inputs to an LLM and asking it to produce an action plan gives you inconsistent numbers, confident hallucinations, and no reproducibility. Pure rules-based systems can't reason about tradeoffs. The split between the two is where the real work happened.

Layer 1 — Heuristics (Deterministic)

All emissions are computed with fixed factors in lib/heuristics.ts before Gemini ever sees the data:

transport_emissions   = commute_km * transport_factor * 30
diet_emissions        = diet_factor * 30
electricity_emissions = kwh * 0.82 * (1 - renewable_pct)

Reproducibility — same inputs always produce the same baseline
Explainability — every number has a traceable source
Hallucination prevention — the AI receives computed values, not raw inputs to misinterpret

The LLM does not touch arithmetic. It receives results.

Layer 2 — Gemini 2.0 Flash (Reasoning Engine)

Gemini operates on the computed emissions data and performs four specific tasks:

Ranking — selects top 5 actions by impact-to-effort ratio
Constraint filtering — removes options outside the user's budget or time window
Tradeoff analysis — surfaces real downsides (e.g. "switching to EV requires significant upfront cost")
Rejection reasoning — explains why alternatives didn't make the list

Output is strictly typed via a 60+ line AnalyzeOutputSchema Zod contract. If the response breaks schema → fallback to the deterministic engine. Gemini is the reasoning layer, not the source of truth.

Layer 3 — Simulation Engine (Client-Side)

The same heuristic functions from the backend run in the browser. Slider changes trigger useMemo recalculations — sub-100ms, no network call. The simulation isn't an approximation of the backend — it's the same model.

Key Features

Real-Time Simulator

Requires sharing computation logic across server and client. Most climate tools skip it. The result is a tool people actually explore vs. a report they read once.

Decision Engine, Not a Recommendation List

A recommendation list has no hierarchy. This has a Hero Action, ranked supporting actions, and explicitly rejected alternatives with reasoning. Users don't need more options — they need a clear first move.

Collective Impact Engine with Elastic Scaling

Individual actions scaled to population level across a dynamic range — from 1,000 to 1,000,000 people. Users can simulate the effect at a community level, a city district, or an entire metropolitan node: "If 500,000 people in your city adopted this plan, it would eliminate X tonnes of annual emissions." This reframes individual action as system-level impact.

Shareable Impact Card

Exportable PNG via html-to-image. Designed to spread.

Technical Decisions

Why hybrid instead of pure AI?

Pure LLM for emissions math = hallucination risk + inconsistent outputs. Pure heuristics = no contextual reasoning. The split gives you deterministic accuracy where you need it and flexible judgment where rules fall short.

Why Zod on AI output?

JSON.parse() on raw LLM output without schema validation will fail — malformed keys, missing fields, wrong types. The AnalyzeOutputSchema Zod contract (60+ lines) enforces a strict interface. If the AI breaks it, the error is caught before it reaches the user.

Why client-side simulation?

API calls add 3–5s of latency. Sliders need sub-100ms feedback. Duplicating the heuristic logic on the frontend is the only clean solution. The tradeoff — keeping two implementations in sync — is worth the UX delta.

Why State-First, Database-Less Identity?

No cold starts, no schema migrations, no auth overhead. Auth0 provides a stable user identifier (sub) that keys into LocalStorage, giving users long-term persistence and a consistent profile without a traditional database.

Challenges

Gemini Rate Limits (429 errors)

Free-tier quota runs out fast during live demos. Fix: exponential retry on 429s, full deterministic fallback if retries exhaust. The fallback is less rich but the app doesn't break.

LLM Latency (3–5 seconds)

You can't optimize past the model's inference time. The fix is perceptual — staged loading UI with granular progress feedback makes 4 seconds feel faster than a blank spinner.

What's Next

Persistent backend (Postgres / Supabase) for action tracking over time
Geo-specific emission factors via Electricity Maps API
Habit loop — weekly check-ins tied to your Hero Action
Live grid carbon intensity via real-time energy APIs

Prize Categories

🏆 Use of Google Gemini

Gemini 2.0 Flash — Google's latest model — is used as a constrained reasoning engine, not a content generator. It receives pre-computed emissions data from lib/heuristics.ts (not raw inputs) and performs ranking, constraint filtering, tradeoff analysis, and rejection reasoning — all within a strict 60+ line AnalyzeOutputSchema Zod contract. This isn't Gemini generating text. This is Gemini generating structured reasoning that passes a typed schema gate on every single call. If it breaks the schema, a deterministic fallback takes over. Gemini handles judgment, not arithmetic.

🏆 Use of Auth0

Auth0 is used to generate a unique sub (subject identifier) for each user, which acts as a deterministic key for client-side persistence. This sub is used to scope and store data in LocalStorage (e.g. results, actions, history), enabling user-level isolation and cross-session continuity without a backend database. The design avoids auth and storage overhead while maintaining a consistent identity model, with straightforward extensibility to server-side persistence.

Why This Approach Matters

The dominant model for climate software is measurement: track what happened, surface the data, assume awareness drives change.

ClimateOS operates on a different premise: people don't lack awareness. They lack prioritized action.

Deterministic computation builds trust — users can see exactly where numbers come from
AI handles the combinatorial judgment problem that rules-based systems can't
Real-time simulation turns a one-time output into a tool people return to
Auth0-backed identity enables long-term continuity without database overhead

ClimateOS doesn’t measure your footprint better — it forces a decision. Not more data. Not more tips. One decision, made correctly.