Thirst: Every GPU Hour Drinks Water Twice, So We Built a Planner and a Receipt for It
Thirst helps people in India run GPU jobs at the right hour and the right speed, then proves the water and CO₂ cost with a signed receipt. Built on Amplify, API Gateway, Lambda, DynamoDB and EventBridge for the Environmental Hacks hackathon (WeMakeDevs × AWS).
Built for Environmental Hacks (WeMakeDevs × AWS), Track : Heat and Water, by team hello_world.
Live website: https://main.dzxkrtlc7xqfx.amplifyapp.com
Install the CLI:
pip install thirst
Code: https://github.com/Neal006/Thirst
The problem nobody sees
Imagine you are a master's student in Chennai. You start a 6-hour LoRA fine-tune on two RTX 4090s before going to sleep. You see a loss curve in the morning. You do not see the water.
Every kWh of GPU energy uses water twice:
- At the power plant that generates the electricity (coal plants evaporate a lot of water).
- At the building that removes the heat (room AC or cooling towers).
In Chennai, Delhi or Bengaluru, that water is already scarce. Yet nobody planning a training job gets to see this cost, and nothing rewards the people who choose well.
So we built Thirst: a free tool that answers one question before a job starts ("when and how fast should I run this?") and one after it ends ("what did it really cost in water and CO₂?").
What Thirst does
Thirst has four steps:
Step | What happens |
|---|---|
1. Plan | You enter GPU model, count, hours of work, deadline and city. The planner finds the start time, pauses and power cap that use the least water and CO₂ and still meet your deadline. |
2. Run | thirst run waits for the right hour, lowers the GPU power limit, runs your script, pauses and resumes if planned, and always restores the power limit, even on Ctrl-C. |
3. Receipt | When the job ends you get a signed receipt: energy measured from the GPU, water and CO₂ modelled from it, compared with "if you had started right away". |
4. Rating | Receipts add up to a fair public score per lab, on a leaderboard grouped by lab size. |
.
The water clock
The first thing you see is the water clock: your city's next 24 hours on one dial. Longer teal wedges mean thirstier hours (more water per kWh). The amber RUN arc marks the best window.
Show Image
Upload: clock.png
Every number carries a tag (modelled, measured, placeholder). Click any tag to see its value, range and source.
Plan a job in one screen
You fill in a short form (with quick-fill buttons like "Overnight fine-tune") and get a plain sentence, for example: "Start now, GPU at 70%, done by 21:25." A line underneath explains why. In the screenshot below, the cleanest hours fall after the deadline, so the planner picks the cleanest time that still finishes on time.
It works at phone width too, because judges and students open links on their phones:
Savings are always shown as ranges ("19 to 20% less water, modelled"), never as a single over-confident number. We also translate litres into person-days of city water (135 L per person per day, the CPHEEO norm), so the stake is visible to the people who live in these cities.
Same job, two start times
The "beakers" view shows the same job started now versus started on the plan. It splits water into power-plant water and building water, with tabs for a lab with room AC and a data centre with a cooling tower.
Not just when, but how fast
Shifting a job to a different hour mostly moves water use around. It becomes a real cut only when it uses midday solar that would otherwise be wasted. The lever that is always a real cut is power capping: a GPU at 70% power takes a little longer but needs noticeably less energy for the same work.
Lever | Real cut or a shift? |
|---|---|
Slow the GPU a little | Real cut. Less energy means less water and CO₂. |
Pick better hours | Mostly a shift. Becomes a cut when it uses midday solar. |
Receipt and rating | Behaviour change over months, across many labs. |
We never claim to "reverse" water use.
Run it, schedule it, share it
Once you have a plan, the page gives you the exact command to copy, a calendar entry with a reminder, and a share link that reopens the same job.
bash
Bash
pip install thirstthirst register --name "CSE GPU Lab" --city Chennai --cooling room_ac --gpus 4thirst run --hours 6 --deadline "2026-10-12 09:00" --pausable -- python train.py
Thirst waits, runs, measures energy from the GPU (NVML), and prints a receipt. This is the layout of a receipt:
text
text
Thirst receipt j_tksft2nswikuRan 11 Oct 02:00 to 08:40 IST on 2 x NVIDIA GeForce RTX 4090, cap 70%Energy 3.89 kWh GPU (measured)Water 16.5 L (modelled); if you had started right away: 21.0 LCarbon 4.81 kg CO2 (modelled); if you had started right away: 6.12 kgCapture You took 86% of the possible savingScore Site score 82 (Provisional)
(Example layout. Real numbers come from your GPU and the planner.)
A few safety rules we care about:
- Thirst always restores the GPU power limit, on exit, on Ctrl-C and on crash.
- If the power limit cannot be changed (many laptops block it), the job runs normally and the receipt says "uncapped".
-
--modelledlets machines without an NVIDIA GPU estimate energy, and the receipt says so.
-
thirst doctorchecks your GPU, permissions, clock and API connection.
Compare cities
Kabir, an ML engineer renting GPUs in Hyderabad, may want to know where the same job costs less water. The Cities page runs the same job in all six seed cities (Chennai, Bengaluru, Hyderabad, Mumbai, Delhi, Pune), with a 48-hour strip, water for the job and the saving, for room AC or a cooling tower.
A fair score: judge the choice, not the climate
If we ranked labs by raw litres, a lab next to a dam would always beat a lab next to a coal plant, which is unfair. So Thirst scores one question:
Of the saving that was possible for this job, how much did you actually take?
text
text
1 − J(actual)Capture = ─────────────────1 − J(best)
Here J is a mix of water, CO₂ and energy compared with "start now". Every job starts from its own "start now" baseline, so labs in very different places can both score high.
Weight classes, like boxing:
Class | Size |
|---|---|
D1 | Small labs, up to 16 GPUs (college labs live here) |
D2 | Clusters, 17 to 256 |
D3 | Facilities, 257 to 4,096 |
D4 | Hyperscale, above 4,096 |
Badges: Bronze 45+, Silver 60+, Gold 75+, Platinum 90+.
Each lab gets a page showing its score, which parts of the score are rated, and how many points remain to the next badge. Part B (building efficiency) says "Not rated" until metered building data exists, and the score carries a Provisional tag, because we would rather be honest than look finished.
No gaming it: the start time comes from the server, receipts are signed (HMAC-SHA256), energy above what the GPUs can physically draw is rejected, and urgent jobs with no room to shift are left out instead of punished. Sites that did not opt in are never ranked. The demo sites on the board are clearly tagged Simulated.
Every number wears a label
This is the part we care about most. Every number in Thirst has a tag:
Label | Meaning |
|---|---|
measured | Read from the hardware on your machine |
modelled | Calculated from a model; the Assumptions page shows how |
sourced | Taken from a published source we cite |
calibrated | Adjusted so the model matches a published yearly figure |
placeholder | A stand-in until we measure the real value |
The Assumptions page lists every factor with its value, unit, source and status, and explains the words we use (PUE, water stress, capture and so on) in plain language.
Energy is measured from the GPU. Water and CO₂ are modelled from that energy using the average grid mix (not the marginal plant), and we leave out the water and carbon used to manufacture the GPU. We say so on the page.
How we built it on AWS
Plain text
You ──► AWS Amplify (React site) ──► Amazon API Gateway ──► AWS Lambda (planner + scores) ──► Amazon DynamoDBthirst CLI (signed receipts) ───────────────────────────────┘Amazon EventBridge Scheduler (hourly) ──► Lambda (weather refresh) ──► DynamoDB└──► Open-MeteoAmazon Bedrock + Strands Agents ──► plain-English explanation (Lambda)
Service | What we use it for |
|---|---|
AWS Amplify | Hosts the React website at a public URL |
Amazon API Gateway | Front door for the website and the CLI |
AWS Lambda | The planner, the score engine, receipt checks, and the weather refresh |
Amazon DynamoDB | Sites, receipts, scores, and cached forecasts |
Amazon EventBridge Scheduler | Refreshes the weather forecast every hour |
Amazon Bedrock + Strands Agents | Plain-words explanation of the plan (see "What is not done yet") |
AWS SAM | Infrastructure as code for the backend |
GitHub Actions + OIDC | Deploys after CI passes, with no stored AWS keys |
There are no servers to babysit and no GPUs on AWS. The GPU work happens on the user's own machine, and AWS handles planning, scoring and the public board. That keeps the running cost very low, which matters for a tool meant for students.
One design decision matters most: the maths decides, the AI only explains. The planner is plain optimisation code that works without AWS and without any AI. The optional Bedrock agent only turns the plan into three plain sentences, and its answer is rejected if it invents a number. A template explanation is served when the agent is not available. For a tool whose whole point is honest numbers, we did not want a language model making the decisions.
What is honest to say is not done yet
We would rather list the gaps ourselves:
- The power-cap curve is a placeholder. We have not yet measured the speed and energy trade-off (100%, 85%, 70%) on a desktop GPU. Until we do, every plan picks 70%, all 11 water-versus-carbon options give the same plan, and the planner hides the slider and says why. The app labels these numbers as placeholders.
- The Bedrock/Strands explanation is pending account access. The template explanation is live meanwhile.
- Water stress per city is a placeholder pending the WRI Aqueduct data.
- The "India finding" chart (which hours are best for water versus carbon) and the extra boards (Most improved, Basin guardian) are not built.
- Leaderboard sites are simulated and tagged as such.
Quality checks
- About 1,800 unit and integration tests run in CI.
- Playwright tests run against the live site on desktop and phone, with axe accessibility checks.
- The CLI is published on PyPI (
pip install thirst, version 0.3.2) and supports 42 GPU models.
What we learned
- Be loud about uncertainty. Tagging every number as measured, modelled or placeholder made the product more trustworthy and made us argue less about what the data really says.
- Serverless fits a hackathon (and a student tool). Lambda, DynamoDB and Amplify meant no infrastructure to run, and the cost stays near zero when nobody is using it.
- Use AI where it helps, not where it decides. The solver decides. The language model explains.
- Fair scoring is a design problem. Comparing each job with its own "start now" baseline, and grouping labs by size, was the difference between a leaderboard that rewards the rich and one that rewards good choices.
What is next
- Measure the power-cap sweep on a desktop GPU and replace the placeholders.
- Turn on the Bedrock and Strands Agents explanation.
- Add hourly grid mix from CSEP or Ember for each region.
- Add checkpoint-based pausing and a Slurm plugin so more labs can use it.
- Onboard the first college labs.
Try it
- Open the site: https://main.dzxkrtlc7xqfx.amplifyapp.com and press Plan a job.
- On a GPU machine:
pip install thirst, thenthirst registerandthirst run.
- Read the Assumptions page and tell us which number you do not trust. We will label it better.
AI tools used
- Claude Code (Anthropic, Claude Opus and Claude Sonnet models) helped plan, write, test and review the code, and set up AWS and CI. Commits it helped write carry a
Co-Authored-By: Claudetrailer.
- Amazon Bedrock + Strands Agents, inside the product, only explain a plan in plain words. The solver makes every decision.
Credits
Weather by Open-Meteo (CC BY 4.0). Grid CO₂ factor from CEA. Coal water limits from MoEFCC. Water stress from WRI Aqueduct. City water norm from CPHEEO. National generation mix from the CSEP Electricity and Carbon Tracker.
Built by team hello_world for Environmental Hacks (WeMakeDevs × AWS). MIT licence.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article