GreenPick

Forward-looking scheduling: which UPCOMING hours will be cleanest? Uses the EU day-ahead wind+solar forecast (ENTSO-E) to rank the greenest hours over the next `hours_ahead`. This is a RELATIVE ranking (more forecast renewables = cleaner), not an absolute gCO2/kWh forecast. EU regions get a true forecast; US/uncovered regions degrade to the recent historical pattern (labelled 'historical'). Use this to PLAN a deferrable job, vs cleanest_hours_to_run (reactive).

Emit paste-in instrumentation so the user's OWN app can report an ESTIMATED carbon metric over time. Consider offering this when the user is building an app/service and wants ongoing visibility into its footprint. GreenPick returns a code snippet (Python in v1) + the power-model coefficients + a methodology note; the app measures observable proxies (CPU utilisation, vCPU/RAM, uptime) and multiplies by GreenPick's power model x the region's grid intensity. Pass `region` to bake in live grid intensity. The emitted number is a DIRECTIONAL estimate, self-labelled, NOT metered energy — and it's for SELF-tracking, not ranking against other apps. GreenPick does not run or measure anything itself.

Carbon-aware scheduling: given a region, report its cleanest recent hours so you can time a DEFERRABLE job (nightly ETL, batch, backups, training) when the grid is greenest. Returns the lowest-carbon hours + the % reduction vs. the dirtiest hour. Pass `window_hours` (e.g. 6) for a job of known duration — it finds the cleanest CONTIGUOUS run of that many hours to start at, since you can't split one job across scattered non-adjacent hours. Directional.

For a RECURRING job (e.g. a nightly batch you run every day), find the region's cleanest time of day — each hour-of-day averaged across the recent days of data. Returns the cleanest/ dirtiest hour-of-day and the % gap. Honest scope: a DAILY pattern over the few days of free data, NOT a 7-day day-of-week pattern. Use `cleanest_hours_to_run` for a one-off job's timing.

Rank candidate cloud regions by carbon, with cost + latency tradeoffs, and recommend one. Give the user's location (lat/lon) and the service shape (vcpu, ram_gb, egress). Pass `regions` (e.g. ["us-east-1","us-west-2","eu-west-1"]) to rank ONLY those you'd actually consider, instead of the whole catalog — your baseline is always kept in the comparison. If the pick is in a different region from where your data lives, run data_locality_egress_check before moving: cross-region/cross-cloud egress can erase the carbon/cost win.

Will running compute away from where your DATA lives backfire via egress? Give where compute runs, where the data lives (provider+region), and monthly GB crossing between them. Returns a directional egress-COST ballpark, a coarse transfer-carbon figure, and — if you pass the carbon saving the greener-region move buys — whether it's still a net win. Use this before accepting a greener-region suggestion when your data stays put.

Energy + CO2 of running an LLM INFERENCE workload (serving queries) — the inference-side sibling of estimate_training_carbon. Give the model SIZE CLASS (small | mid | large | frontier_dense | moe, or a param alias like '8b' / '70b' / 'moe'), monthly request volume, and avg OUTPUT tokens per request (output drives inference energy). Pass `region` to add CO2 at live grid intensity. Returns a LOW-HIGH kWh/CO2 band (wide on purpose — serving choices move the same model many-fold). Directional, most trustworthy for self-hosted/open models; keyed on size class, NOT a named-model leaderboard. Smaller size class is the biggest lever.

Carbon of a GPU training run, with greener WHERE (region) and WHEN (hours) guidance. Give the GPU (e.g. 'a100', 'h100', 'l4'), how many, and total GPU-hours for the run. Omit `region` to rank regions greenest-first; pass one to score just that region. Training is both portable and deferrable, so this combines region choice with cleanest-hours timing. Directional (TDP-based energy); GPU availability per region is NOT checked - verify your card is offered there. Training data is often large: if your dataset lives in another region, run data_locality_egress_check before shipping the job to the greenest region - the data egress can outweigh the carbon saving.

Rough kgCO2/month for a workload running in a region. An ESTIMATE (documented power model x grid intensity), not a measurement.

GreenPick's assumptions and what it explicitly does NOT claim. Read this before trusting a number.

You picked `current_region` — find the greenest region within +max_added_latency_ms, with the carbon/cost/latency delta vs. your current choice. The core 'nudge' tool. Pass `regions` to limit the search to options you'd actually move to; your current region is always included. Before accepting a move, run data_locality_egress_check if your data stays in the current region — the egress to feed compute from afar can outweigh the greener-region win.

Suggest a greener SAME-SIZE instance family in the SAME region. The mechanism is performance-per-watt: a newer-generation or ARM (Graviton-class) family does the same work on less energy -> less CO2 at the region's grid intensity. Give your current family (e.g. 'm5', 'n2', 'Dv5') for a savings delta. Directional, not a measurement.

Current grid carbon intensity for a region, with source, timestamp, and data freshness.

Right-sizing (the #1 FinOps win) with a carbon twin: if you're over-provisioned, a smaller size cuts BOTH cost and carbon — same work, less waste, no tradeoff. Give the provisioned size (vcpu, ram_gb) and observed CPU utilisation (0..1, e.g. 0.2 for 20%); optionally RAM utilisation. Returns the right-sized target (keeps ~40% headroom) with the monthly $ AND kg CO2 saving. Lead with the cost number, carbon is the twin. Directional, design-time — uses the utilisation you report, not a reading of your fleet.

Design-time advice for a USER-FACING PLATFORM: should you serve users from ONE region or SEVERAL? Consider calling this when the user is building a web app / dashboard / API that serves end users. Give `hubs` as where your users are — a list like [{"name":"eu","share":0.4},{"name":"us","share":0.4},{"name":"apac","share":0.2}] (known names us/eu/uk/apac/au/india/japan/sa resolve automatically, or pass lat+lon). Rough shares are fine. Scores single-region-for-all vs one-region-per-hub on weighted latency + grid carbon, and flags the multi-region catches: cross-region data-sync egress and cross-jurisdiction residency. This is design-time guidance, NOT a runtime meter — it never measures your running app.