A synthetic Spanish billing request returned Billing through the accepted provider router.
The actual GitLab Duo proposal restores unknown-overhead handling in the accounting module.
The 336-ticket study passed quality and latency but missed the fixed 20% provider-call reduction requirement.

Inspiration

A customer writes in Spanish because the same invoice appears to have been charged twice. Before anyone can fix the bill, their message needs to reach the right support queue. A cheaper routing decision is useful only when it still understands the customer, handles uncertainty and gets them to the right team.

I built The Carbon-Aware Release Lab to make that tradeoff visible. The audience is a support or platform team deciding whether a smaller local router is ready to take on work currently handled by a hosted model.

What it does

The public app combines a working multilingual ticket queue with a release review. You can enter a synthetic support message, see the accepted router's decision and inspect the evidence behind a proposed replacement. The queue identifies the active release and reports the route taken.

The central result is a blocked release. In the retained, independently frozen study, the smaller router handled 336 unique synthetic tickets across 84 cross-language clusters. Its joint macro-F1 was 0.979668 and its measured p95 latency was 1,340.86 milliseconds. It passed the recorded quality, latency and slice checks. It made 277 provider calls against the comparison's 336, saving 59 calls, or 17.56%.

The agreed release requirement was 20%. The candidate stayed blocked, and the previously accepted provider router remained active. The app makes that decision easy to inspect. Provider calls, tokens, local CPU and latency have separate records. Total energy and carbon savings remain unmeasured.

How I built it

The application, routing strategies, evaluator and release controls were created for this event. GitLab is the backbone of the work after the initial feature code. A real GitLab Duo Agent Platform session, 9795068, read the permitted source and policy files and proposed a repair for a deliberately seeded regression in the carbon-accounting module. The proposed edit was applied to an isolated branch. The original passed eight disclosed module cases, the seed failed, and the candidate passed all eight inside a network-disabled container. The merge request and retained trace show that scoped result.

A separate protected evaluator and signed evidence bind the proposed source to its checks. The supervised workflow keeps review and promotion explicit. The retained managed workflow records preparation, acceptance and the durable effect receipt. This gives the release decision a trail through proposal, verification and application state.

Google Cloud hosts the public application. Cloud Run serves the interface, Firestore holds managed state, and immutable storage keeps the reviewed artifacts available. The public repository includes the managed deployment source, Docker recipes, MIT license and recorded evidence.

Challenges and lessons

The hardest part was keeping comparisons honest. Languages and ticket families needed careful splits, cold startup affected latency, and provider calls were only one part of resource use. Earlier unsuccessful CPU and provider experiments remain visible alongside the later result. I learned that an understandable negative decision can be as valuable as a promotion: the operator can see which limit failed and which release is still serving.

Current result and next steps

The completed portion is the public routing lab, the retained study and the recorded native proposal and managed acceptance evidence. Student promotion remains blocked. A newer release-automation cycle is incomplete and is excluded from these results. Next steps are to improve local coverage on fresh development families, evaluate a fresh, unexposed set under the same fixed criteria, measure the target runtime and gather independent accessibility feedback before another promotion decision.