Kinwise Carbon Budget

A scam screen for older adults that measures the carbon of every check, lets a GitLab Duo agent propose greener changes, and ships one only when a person approves it and no scam slips through.

Comment

Path B (Bring Your Own) · Assisted · also entering Most Environmentally Impactful

What it is

Kinwise screens the texts, emails and voicemails an older parent receives for scams. Scammers paraphrase, so the original rule-based detectors caught only 8 of the 26 scams in our labelled set; a model reading every message catches all 26. But that puts a model call, and its carbon, on every message an older person receives, and nobody could see that cost.

Kinwise Carbon Budget makes the cost visible and brings it down without letting a single scam through:

  1. Measure. On every merge request and every main pipeline, a GitLab CI job replays 52 labelled messages (26 scams, 26 benign, all fictional) through the code with real model calls, measures tokens, calls, bytes and seconds per check, and computes the Software Carbon Intensity (SCI = (E x I + M) per R, ISO/IEC 21031:2024) of one scam check. It recomputes the result with the Green Software Foundation's Impact Framework, compares with main, posts one table on the merge request, and fails if recall drops or the carbon budget is exceeded.
  2. Propose. A person mentions the kinwise-green-reviewer flow (GitLab Duo Agent Platform) in an issue. It reads the measured numbers and the code, opens up to three proposal issues with the arithmetic and the risk to recall, and stops.
  3. Implement. A person approves one proposal. The kinwise-green-implementer flow checks the approver against an allowlist, edits only the files the proposal names, and opens a merge request. The gate measures the real effect.
  4. Ship. A person merges and, separately, starts the deploy. After the deploy, a carbon ledger computes the SCI of the whole change, including every CI job and the agents' own model tokens, and how many checks it takes to repay.

Why Assisted: the agents never merge, deploy or approve anything. A person starts the green review, approves one proposal by replying "approve", reads the diff and the carbon table and merges, and presses Play on the manual deploy job. Every approval point is visible in GitLab: issues #3, #4 and #5, merge requests !3, !6 and !7, and four production deployments started by a person.

Results (measured in GitLab CI)

  • SCI per scam check: 32.4 mg CO2e (v1) to 13.9 mg CO2e (-57%), central estimate; bounding range 4.4 to 471 mg before and 1.5 to 238 mg after
  • Scams caught: 26 / 26 before and after; false alarms 0 / 26 before and after
  • Three agent-proposed, human-approved changes: model reasoning off (-35%), rules decide obvious messages first (-28%, 15 of 52 messages need no model call), shorter prompt (-8%)
  • A human experiment that removed the model entirely cut carbon by 100% but caught only 8 of 26 scams: the gate failed it and it was never merged (MR !5)
  • The whole program (29 pipelines, 21 eval runs, 4 agent sessions) cost 87.5 g CO2e and is repaid after 4,714 checks: under 4 hours for 1,000 people

Who it is for

Families who look after an older parent from a distance, and the team that runs the screen, who now see the carbon and the recall of every change before it ships. Americans 60 and older reported $7.7 billion in losses to internet crime in 2025 (FBI IC3, via AARP).

How we built it

  • GitLab Duo Agent Platform: two custom flows in the AI Catalog (flow registry v1 YAML kept under .gitlab/duo/flows/, synced with scripts/duo/sync-catalog.mts), each enabled with a mention trigger and running as its own service account on GitLab's runners. kinwise-green-reviewer reads the ledger and code through the API (coding_environment: none) and opens ranked proposal issues; kinwise-green-implementer checks the approver against .gitlab/duo/approvers.json, edits the named files in the runner's clone, pushes a green/... branch and opens the merge request.
  • GitLab CI/CD: verify (tests, build), secure (SAST, secret detection), the carbon and accuracy gate, a human-approved release stage with a GitLab environment, a carbon ledger after each deploy, and a scheduled production canary. CI also reads the flow sessions' own checkpoints through GitLab's GraphQL API to count the agents' model tokens in each change's carbon.
  • The app: Next.js and the Strands Agents SDK calling Qwen/Qwen3.8-27B on W&B Inference, deployed to Vercel by the pipeline.

How the sustainability gain is quantified

We follow the Green Software Foundation's SCI specification v1.1 (ISO/IEC 21031:2024) with two functional units, R1 = one scam check and R2 = one merged change, and location-based grid intensity only (no offsets, no RECs). Model tokens, retries, bytes, wall time, CI job seconds and the flows' own tokens are measured on every run; coefficients come from EcoLogits, the ML.ENERGY benchmark, Cloud Carbon Footprint, NVIDIA's HGX H100 product carbon footprint, EPA eGRID2023, Google's region data and Ember, each with low, central and high values and a source in docs/SCI.md. Every gate run is cross-checked with the GSF Impact Framework (if-run). Bounding ranges, not false precision: the level of one check is uncertain, but before and after use the same coefficients, so the change is robust (-57% central, -66% low end, -49% high end).

What we added during the Submission Period (on or after Oct 5)

The original Kinwise (https://github.com/chinesepowered/kinwise, MIT, last commit Sep 13 2026) had regex scam detectors and a Strands agent that holds scam payments, but no CI, no tests, no message screen and no carbon measurement. Its four commits are unchanged at the start of the repository. Added from Oct 23 on, in new commits: the message screen with a measured cost per check and a fictional eval set; SCI measurement, the Impact Framework cross-check, the carbon and accuracy gate, the ledger and the production monitor; GitLab CI; the two GitLab Duo flows, their allowlist and the catalog sync script; unit tests, the Vercel deployment from CI, and the README, diagram and slides; and the three changes the flows wrote after a person approved them (!3, !6, !7).

Challenges

  • GitLab runs flows only on human actions, which fits Assisted autonomy: every hand-off is a person's comment, merge or Play button.
  • The flows are most of each change's delivery carbon (16 to 20 g of 19 to 22 g), so the ledger counts them and states how many checks repay each change.
  • The project is public, so anyone can mention a flow; the flows act only for people on the allowlist and answer everyone else once without changing anything.

Links

All messages and people are fictional. AI tools used: Claude Code (coding assistant), GitLab Duo Agent Platform flows (GitLab's model, Claude Sonnet 5.5 via Vertex AI, per session metadata), Qwen3.8-27B via W&B Inference (the message screen and the original guardian agent), ElevenLabs (video narration).

Built With

  • elevenlabs
  • gitlab
  • gitlab-ai-catalog
  • gitlab-ci/cd
  • gitlab-duo-agent-platform
  • gitlab-sast
  • gitlab-secret-detection
  • green-software-foundation-impact-framework
  • next.js
  • node.js
  • playwright
  • pnpm
  • qwen3.8-27b
  • react
  • strands-agents-sdk
  • typescript
  • vercel
  • w&b-inference
Share this project:

Updates

Submission history