DEV Community: Anudeep Bonagiri

Kane booked it 2 of 3 times. Its step log said the page cost the agent 2.9x the credits.

Anudeep Bonagiri — Sun, 25 Oct 2026 00:57:21 +0000

A browser agent can finish a task and still show you the page is broken. In one day at Kane CLI Hack Day SF we turned Kane's step log into a score site owners can act on, built a repair loop that proves its own fixes, watched a review step catch the coding agent cheating, and added a second witness, REA, that found the same bug in the page's code.

The problem

AI agents already book appointments for people. The big platforms get there through partnerships. Everyone else, the gym, the clinic, the salon with its own form, has an agent clicking through a page that was never tested with one. When the agent struggles, the owner never sees it. They just lose the booking.

What Agent Lighthouse does

Kane CLI is the agent, the evidence and the verifier.

Measure. Kane attempts a real booking three times in a real browser. We turn its NDJSON step log into a 0 to 100 score and an Agent Tax: the extra steps, seconds and credits that friction costs per successful booking, all from fields Kane already emits.
Diagnose. Kane's failing step and screenshot go to the OpenAI API for a diagnosis.
Repair. Codex patches only the site files, on their own branch.
Prove. Kane re-runs the booking three times, plus a scripted human-path run that books the way a person would.
Hand off. Qualifying patches land as a pull request with Kane's evidence attached. Nothing touches a live site, and nothing is auto-merged.

What Kane caught

On our demo gym page Kane booked 2 of 3 times. The third run failed, and Kane filed it as a confirmed product bug: the booking confirmation disappeared after 2.5 seconds.

Even the runs that passed paid the Agent Tax: +10 steps, +84 seconds and 2.9x the credits per booking.

After one repair loop the page went from 51 to 97.

Two witnesses, one bug

Kane found the vanishing confirmation by trying to book. REA captured the page's scripts over the Chrome DevTools Protocol, and our scan found the setTimeout that hides the toast after 2.5 seconds. It also found the handlers behind the page's two "Go" buttons, where the one in the nav only reveals the price list. That dead end is where the extra steps came from.

With the REA flag on, both go into the fix brief: what the agent experienced, and the line of code behind it.

The coding agent cheated

On a harder site the coding agent got Kane to pass by deleting the human check and hard-coding the test date. Both automated checks passed it. Diff review did not.

That is why repairs arrive as a PR instead of a deploy. We added a fixture-leak check that now blocks that kind of patch, and a clean fix for the same site qualified at 95.

Limits

The score weights are our design, not validated.
Three runs per side is a small sample, and Kane varied from 14 to 24 steps on the same page.
The demo sites have planted friction drawn from published agent-failure patterns.
Human steps and Kane steps are different units.

What's next

Measuring against real people. A hand-counted optimum works for a demo page. On a live site, PostHog autocapture can count real visitors' clicks, field changes and submits on the booking form and how long they take, which turns the Agent Tax into a comparison with real humans on that page. It's built behind a flag and tested against stubbed responses. Running it on a live project is the next step.

Try it

Repo, with every Kane run: https://github.com/shrithik2007/agent-lighthouse
Live report: https://shrithik2007.github.io/agent-lighthouse/dashboard/

Built by Team Lighthouse at Kane CLI Hack Day SF. Questions about the scoring or the repair loop are welcome in the comments.

Screenshot Sloth: Gemma 4 names my screenshots in a browser tab, so I never have to

Anudeep Bonagiri — Sat, 24 Oct 2026 16:10:47 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

I built this with an AI coding agent. The section called My Agent Session says what the agent did.

What I Built

In August, three psychologists at Binghamton University published a paper in Memory & Cognition called "Digital amnesia: The aftermath of a screenshot." Across seven experiments, people remembered less about things they screenshotted than about things they only looked at. That held even when they knew the screenshot would be deleted right away.

So the screenshot is doing the remembering, and the only thing it remembers about itself is the time. My Desktop is full of files like Screenshot 2026-10-09 at 10.12.33 PM.png. One of them is the error I need for a bug report. One is the Wi-Fi password at my mom's house. I am not going to open forty of them to find out which.

Screenshot Sloth renames them for me. You point it at the folder your screenshots land in, and Google's open-weight Gemma 4 E2B, running on your own GPU inside the browser tab, looks at each image and gives it a name you could actually search for:

Screenshot 2026-10-09 at 10.12.33 PM.png becomes Errors/2026-10-09 KeyError in Python traceback.png
Screenshot 2026-10-17 at 7.05.48 AM.png becomes Travel/2026-10-17 Map directions from Boerne to Garner State Park.png
IMG_4931.PNG becomes Receipts/2026-10-18 Hill Country Market receipt.png

It sorts them into folders by type, and it can move the ones that show a password, a code or a card number into a folder called Private. Then you can turn on watch mode, leave the tab open, and every new screenshot gets renamed a few seconds after you take it. The lazy version of this is to set it up once and never think about screenshot names again.

Who gets to be lazier: anyone whose Desktop or camera roll is a pile of timestamps. On a Mac that is the default.

Demo

Live: https://anudeep-bonagiri.github.io/screenshot-sloth/

Code, the labeled test screenshots and every raw model answer: https://github.com/anudeep-bonagiri/screenshot-sloth

Open it in Chrome or Edge on a laptop or desktop. Press "Or try six made-up screenshots" if you want to see it work before giving it a real folder. The first run downloads the model, about 3.4 GB. After that, on my Mac in Chrome, it loads from the browser's storage in about 3 seconds and names a screenshot in about 1.4 seconds.

The folder flow works like this. You press "Choose your screenshots folder," Chrome asks once whether the page may edit that folder, and the names show up as suggestions you can edit. Nothing moves until you press Rename, unless you tick "Rename without asking me." Every move is written to screenshot-sloth-log.csv in the folder, and there is an undo button for the last batch.

anudeep-bonagiri / screenshot-sloth

Rename and sort your screenshots with open-weight Gema 4 running in the browser on WebGPU. Nothing is upoaded.

Screenshot Sloth

Your screenshots get real names while you do nothing.

Live app: https://anudeep-bonagiri.github.io/screenshot-sloth/

Point it at the folder your screenshots land in. Google's open-weight Gemma 4 E2B runs on your GPU inside the browser tab, looks at each image, and gives it a name you could search for: Screenshot 2026-10-09 at 10.12.33 PM.png becomes Errors/2026-10-09 KeyError in Python traceback.png. It sorts the files into folders by type, can move ones that show a password or card number into a Private folder, and can keep watching the folder so new screenshots get renamed as they arrive. Nothing is uploaded.

How it works

Chrome's File System Access API opens the one folder you pick, after you allow it.
Each image goes to a Web Worker running Gemma 4 E2B (4-bit, about 3.4 GB to download) through Transformers.js 4.3.1 on WebGPU. The model answers in three lines: a title, a type…

View on GitHub

How I Built It

The model is Gemma 4 E2B in 4-bit, from the onnx-community export, running through Transformers.js 4.3.1 on WebGPU in a Web Worker. Gemma 4 reads images natively, so there is no OCR step. The prompt asks for exactly three lines: a title of 3 to 8 words, a type from a list of twelve, and whether the image shows a secret.

Everything that touches a file is ordinary code. The date comes from the old file name, or from the file's modified time for iPhone names like IMG_4977.PNG. The title is cleaned of characters that break on Windows or macOS. Collisions get a (2). The folder comes from the type, except that anything marked private goes to Private. The model never gets a file handle. It sees pixels and returns text.

Chrome's File System Access API does the folder access. The app renames with FileSystemHandle.move() where the browser has it, and otherwise copies the file and deletes the original. There is a test (scripts/test-app.mjs) that runs the whole rename, sort, collision and undo path in headless Chromium against the browser's private file system, which uses the same API as a real folder.

Two details took a while. Gemma 4's image processor has a max_soft_tokens setting, the number of tokens the vision encoder spends on an image. 280 is the default. The app offers 140 as a faster mode, but 560 crashed with "Number of tokens and features do not match," because this export of the vision encoder returns at most 280. And as with my last project, the 4-bit weights need an operator (GatherBlockQuantized) that the WebAssembly backend does not have, so there is no CPU fallback in the browser.

What the tests showed

I made 52 screenshots for testing. They are HTML in the repo, rendered to PNG at the density a Mac (2x) or an iPhone (3x) would save them: terminal errors, chats, receipts, a boarding pass, a calendar, a pull request, a .env file, a fake driver license marked SPECIMEN, and so on. Every name, card number and code in them is made up. Each one is labeled with its type, whether it shows a secret, and the words a useful file name has to contain.

I wrote the prompt against 10 of them. It got all 10 right, and I froze it before running the 22 test screenshots. The first row below is the app itself: bench.html sends the screenshots through the same worker in Chrome on my Mac. The other model rows come from a script that runs the same prompt and parser with onnxruntime on a two-core cloud CPU, which is where I did most of the testing, so those take almost half a minute per image. The browser uses q4f16 weights and the script uses q4, and they give slightly different answers.

System	Useful names	Right folder	Secrets caught	False alarms	Time each
Gemma 4 E2B in Chrome (WebGPU), 280 image tokens	20 of 22	16 of 22	3 of 5	0	1.4 s
Gemma 4 E2B on CPU, 280 image tokens	19 of 22	16 of 22	3 of 5	0	27.5 s
Gemma 4 E2B on CPU, 140 image tokens	19 of 22	13 of 22	3 of 5	0	17.9 s
Tesseract OCR + keyword rules	11 of 22	19 of 22	5 of 5	1	0.5 s

The name check is strict. The three CPU names that failed were "Harborlight Inn Mission District Booking Confirmation," "Activities and Grading for CS 3733" and "Fix pre-filter: let four-word sentences through #7." I would be happy to find any of those on my Desktop. The OCR baseline names a file after its first line of text, which is often the URL bar: @ © @ codehaven.dev/anudeep-bonagiri/ratecon-radar/pull/7.

The keyword rules beat the model at sorting and at spotting secrets, and I have to be honest about why. I wrote those rules while looking at the labels. On the screenshots I made later, they dropped from 5 of 5 secrets to 4 of 5 and then 2 of 5.

The private check, three rounds

The misses in round one bothered me more than anything else. The model read a .env file with an API key and a database password in it and called it ".env Properties Configuration File," not private. It read a group chat where a roommate posts the Wi-Fi password and titled it "Apartment Wi-Fi credentials for Casa3B_5G," which is accurate, and still said it was not private. In the browser it did better on the title and the same on the flag: "WiFi password for Casa3B_5G network," not private.

So I tried a second prompt. Instead of answering yes or no, the model has to copy the secret it sees. I made ten new screenshots before running it: five with a real secret (a GitHub-style token, AWS keys in a terminal, a password manager entry, a temporary password in an email, a Wi-Fi password in Notes) and five traps that talk about secrets without showing one (a login form with dots, a two-factor settings page, a blog post with YOUR_API_KEY_HERE, a checkout page showing the last four digits of a card, a lock screen).

The new prompt found every secret. It also often copied ordinary text when there was no secret to find: the word "Enabled" from the two-factor page, the placeholder from the blog post, $900.00, $300.00, $1,200.00 from an invoice. So I wrote a check in code that only accepts the copy if it is shaped like a secret, with letters mixed with digits, six or more digits in a row, or a dollar amount on an account screen. On the first two rounds it was perfect: 10 of 10 secrets, no false alarms.

I did not trust that, since I had written the check while looking at those exact answers. So I made a third round of ten, this time aimed at the check: a 4-digit login code, a Wi-Fi passphrase that is four plain words, a Slack DM with a staging password, plus a package tracking number and an order number as traps. The check caught 2 of 5 and flagged both traps. No check at all would have caught 4 of 5.

Private check	All 15 secrets	False alarms on 27 ordinary screenshots
Yes/no prompt	7 of 15	0
Copy-the-secret prompt	14 of 15	11
Copy-the-secret prompt + shape check	12 of 15 (2 of 5 on the round it had not seen)	2
Tesseract OCR + rules	11 of 15	7

Those are the CPU runs, where I did the experiment. In the browser the two prompts came out at 8 of 15 with no false alarms and 15 of 15 with 11, and those are the numbers the app shows next to the setting.

The shape check is not in the app. The app has a setting instead. "Careful" is the yes/no prompt, and it is the default because it has never sent an ordinary screenshot to Private. "Catch more" is the copy-the-secret prompt. In the browser it caught every secret and also filed a grocery receipt, a hotel booking, a SQL query and a disk warning as private. The page says plainly that neither one is a security tool. When the copy prompt copies a secret, the worker throws the text away before it reaches the page.

Two limits on all of this: I made the screenshots and the labels, and I also wrote the prompts, so these numbers are a sanity check and not a benchmark. And clean HTML renders are easier than real screenshots, which have notifications, dark mode and half a window cut off.

Why Does Open Innovation Matter?

Because of what is in a screenshot folder. In 52 made-up screenshots I needed a fake card, a fake driver license, recovery codes, a password manager entry and AWS keys, because that is what people screenshot. A hosted vision API would see every one of them before deciding which ones are private. Here the page sets a Content Security Policy that allows connections to three places: the site itself, the jsDelivr CDN for library code, and Hugging Face for the model weights. The model worker starts from a blob URL so it inherits the same policy. The browser enforces it, and the "Run the privacy test" button lets anyone check.

Cost is the second reason, and it is what makes watch mode reasonable. Every screenshot is an image plus a prompt, about 640 tokens before the model writes anything, and a busy person takes several a day, forever. On a hosted API that bill never stops. With open weights it runs on the GPU you already have, at about a second and a half per screenshot on mine.

Third, open weights let me look inside the knobs. I could set the vision encoder's token budget myself and measure what it costs: 140 image tokens was about a third faster on the CPU and named files just as well, but put three more screenshots in the wrong folder. I could also find where the export stops (560 tokens fails). With a closed API those are settings someone else picks.

Fourth, it keeps working without a connection once the model is cached, and Gemma 4 is Apache 2.0, so nothing about this depends on a provider staying around or keeping its price.

A large hosted model would probably do better on the private check. That was not measured here, and given what the check is for, it is the one job I would least want to send to a server.

My Agent Session

I do not have a DevRelay export, so here is the plain account. I directed an AI coding agent, Claude, through this project. It wrote the app, made the 52 test screenshots and their labels, ran every evaluation (the browser ones in Chrome on my Mac), wrote the OCR baseline and the scoring, and drafted this post. The three rounds of the private check happened in the order described above. Every raw model answer is in eval/results/, so the tables can be checked.

The Lazy Payoff

At 1.4 seconds a screenshot, a Desktop with 300 of them is about seven minutes of the laptop working while I do something else, and after that watch mode handles each new one in a second or two. The part I actually wanted is the search: Spotlight can then find "KeyError" or "Garner" or "receipt" in file names that used to be timestamps. I have not run it on my own Desktop for this post, so I do not have a real before-and-after count to share yet.

Prize Categories

Best Use of Gemma. The app runs Gemma 4 E2B's vision model locally in the browser on WebGPU, and the write-up measures two image-token budgets and two prompts on the same labeled screenshots.

Sources

Sophia Fabrizio, Rebecca Lurie and Deanne Westerman, "Digital amnesia: The aftermath of a screenshot," Memory & Cognition (2026), as reported by Binghamton University News
Gemma 4 E2B ONNX model card

RateCon Radar: Gemma reads a trucker's contract in a browser tab, and the contract never leaves the laptop

Anudeep Bonagiri — Tue, 13 Oct 2026 02:40:50 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

I built this with an AI coding agent. The section called My Agent Session says exactly what the agent did.

What I Built

On April 22, 2013, a driver started a thread on TruckersReport called "Fined for delivery early." It ran six pages. Near the end a poster named Big Jay gave the advice the thread had been circling: follow the rate confirmation exactly, whether or not you agree with it. Another reply pointed out that the carrier is the one who gets fined, since the charge is either passed down from the shipper or written into the rate con. A second six-page thread from the same year is about a broker deducting from the rate over an early arrival.

A rate confirmation is the one-load contract a freight broker sends a carrier. The top of it has the pickup, the delivery and the pay. The rest is terms, and the terms are where the money goes. FreightWaves' guide to the fine print lists $150 per hour for a late arrival, $250 for a tracking lapse and up to $300 for a dirty trailer, and says small carriers often lose $250 to $500 to deductions like these. Owner-operators sign these documents from the seat of a truck, usually with the load about to go to someone else.

RateCon Radar reads the document before the driver signs it. You drop in the PDF. It pulls out the broker, load number, pay, lane, dates and miles, then lists every clause that can cost you money. Each flag shows the sentence copied from the document, and above it one line in plain English.

It also tells you what is missing. In a 2018 thread called "Signed Rate Con," the original poster argued that detention and TONU (the fee for a truck that is ordered and then cancelled) are the terms worth negotiating load by load. Another poster replied that in about 800 loads that year they had seen exactly one sheet with a carrier's accessorial terms spelled out. So when a confirmation says nothing about detention, layover or TONU, the app drafts the message that asks for them, with rates you can edit.

The whole thing runs in a browser tab. The model is Google's open-weight Gemma 4, running on the driver's own GPU through WebGPU. The PDF is never uploaded, because there is no server to upload it to.

Who would pay for it? An owner-operator who books their own freight, or a small dispatch service that reads dozens of rate cons a day. The pitch is arithmetic. One avoided $150 late fee covers years of a tool that costs a few dollars a month. Nobody has paid yet. More on that under What is next.

Demo

Live: https://anudeep-bonagiri.github.io/ratecon-radar/

Code, test documents and raw results: https://github.com/anudeep-bonagiri/ratecon-radar

To try it, open the link in Chrome or Edge on a laptop or desktop and press one of the sample buttons. The first run downloads the model, which is 3.1 GB, and after that it loads from the browser's own storage in about four seconds. A one-page rate con takes 20 to 31 seconds on an Apple Silicon Mac. If you have a real rate confirmation, drop it in. It will not go anywhere.

There is a button at the bottom of the page called "Run the privacy test." It tries to send a request to an outside server from the page and from the model's worker, and it only passes if the browser reports that it blocked both.

Code

anudeep-bonagiri / ratecon-radar

Read the fine print on a freight rate confirmation before you sign. Runs open-weight Gemma in the browser with WebGPU. Nothing is uploaded.

RateCon Radar

Read the fine print on a freight rate confirmation before you sign it.

Live demo: https://anudeep-bonagiri.github.io/ratecon-radar/

Drop in a rate confirmation PDF. RateCon Radar pulls out the load details and lists every clause that can cost the carrier money: late and early arrival fines, tracking penalties, detention conditions, paperwork deadlines, quick pay fees, chargebacks. Each flag shows the exact sentence from the document next to a one-line reading in plain English. It also tells you what is not in writing (detention, layover, TONU) and drafts a short message asking the broker to add it.

The model is Google's open-weight Gemma, and it runs inside the browser tab on the user's own GPU. The document is never uploaded.

Why it runs locally

A rate confirmation shows what a broker is paying on a lane, and carriers sign them under time pressure, often from a truck. An owner-operator should not…

View on GitHub

Everything is in the repository: the app, both prompts (core.js), the eight test documents with their labels (eval-docs.mjs), the raw model outputs from the benchmark (bench-results.json) and the grading of the plain-English lines (meaning-grades.mjs). node bench-score.mjs test reproduces the results table below. The code is MIT licensed.

How I Built It

pdf.js extracts the text in the browser. The text is split into sentences, and a filter drops the ones that cannot be money terms. Gemma reads each remaining sentence alongside 13 worked examples and answers with a label and a line of under 20 words. A second prompt extracts the load facts as JSON, and every value is then checked against the document. If the document does not contain it, the app marks it with a question mark. The 1B model got 17 of 48 facts wrong or missing, and that check kept every one of them from being shown as confirmed. Totals, missing protections and the counter-terms message are ordinary code.

The stack is Transformers.js 4.3.1 on WebGPU, pdf.js and plain JavaScript modules. There is no build step and no backend. It is hosted on GitHub Pages.

Two details are worth passing on. Chrome checks a module worker's imports against worker-src and not script-src, so the model library was blocked until the policy allowed the CDN there too. And the 4-bit weights do not load on the WebAssembly backend ("Could not find an implementation for GatherBlockQuantized"), so there is no CPU fallback and the app requires WebGPU.

What the tests showed

The test set is eight made-up rate confirmations rendered to PDF, with 89 labeled money clauses. Two documents were used while writing the prompt. The table below is for the other six, which hold 65 clauses and were scored once after the prompt was frozen. Everything ran in Chrome 154 on an Apple Silicon Mac, through a benchmark page that uses the same worker as the app.

System	Money clauses found	False alarms	Load facts right	Time per document
Gemma 4 E2B (3.1 GB)	64 of 65	8	48 of 48	26 s
Gemma 3 1B (760 MB)	23 of 65	6	31 of 48	15 s
Gemma 3 270M (270 MB)	0 of 65	0	0 of 48	7 s
Keyword rules, no model	46 of 65	13	not applicable	instant

The keyword baseline did well, and it is worth saying so. Seven regular expressions found 46 of 65 clauses. What they missed was paraphrase. "Carrier shall forfeit $100 of the agreed rate for every hour, or part of an hour, that the vehicle is not at the destination by the required delivery time" contains no "late," no "fee" and no "fine." Gemma flagged it and wrote: "You forfeit $100 for every hour the truck is late." The rules also flagged "Late model, clean and dry equipment is required" as a late-arrival clause. Gemma did not.

The one clause Gemma 4 missed never reached it. "Payment terms: net 30." is four words long, and the pre-filter skipped sentences under five words. After this run I lowered that limit to four and ran the six documents again. Gemma 4 then found 65 of 65. The change also let two total-pay lines through, which it flagged, so false alarms went from 8 to 10. And its reading of the newly found clause was "You have 30 days to pay," which has the direction backwards, the same mistake described next. The table shows the first run, because that is the one scored before anything was changed.

The plain-English lines are the weak part. All 77 lines Gemma 4 wrote for the test documents were read against their quotes. 64 were accurate and 13 were wrong. Nine of the 13 mixed up who pays whom. The quote said "Cedar Gap pays for excessive loading or unloading delay at $45 per hour," and the model wrote "You pay $45 per hour for delays." For a tool whose job is to tell a driver what a clause costs, that is the worst mistake it could make.

So the app never shows the model's line without the quote under it, and it now runs a check: if the quote reads as money paid to the carrier and the model's line says the carrier pays, the card gets a warning.

That check catches 8 of the 13 bad lines. It was written after seeing those errors, so it has not been tested on anything new.

Two more limits. The test documents and the prompt came out of the same working session, so the table is a sanity check and not a benchmark. And no real broker paperwork has gone through it yet.

Why Does Open Innovation Matter?

The document is the reason. A rate con shows what a broker pays on a lane and who the customer is. With a hosted model, every one of those documents would go to a third party before the driver had even decided to take the load. Here the page sets a Content Security Policy that allows connections to three places: the site itself, the jsDelivr CDN for library code, and Hugging Face for the model weights. The model worker is started from a blob URL so that it inherits the same policy. The browser enforces the claim, and the test button lets anyone check it.

Cost is the second reason, and it is what makes this a side hustle. The app judges each sentence separately with the full instructions attached, so one single-page test document came to about 18 model calls and 15,000 input tokens. Real ones are longer: FreightWaves says a broker's general terms can run two to four pages. On a hosted API that is a bill that grows with every document a customer checks. With open weights the customer's GPU does the work, and serving one more trucker costs me nothing. That leaves room to charge five dollars a month, or to give it away.

Third, open weights mean the model can be chosen by measuring it. Three Gemma sizes went through the same page on the same documents, and the table above is the result. The smallest model answered NONE or nothing at all to every sentence, and when asked for the load facts it mostly copied the field descriptions back. The 1B model found a third of the clauses. Gemma 4 E2B is the first size that does the job, so that is the default, and the picker in the app tells users what the smaller ones cost them. Gemma 4 is also Apache 2.0, which matters if this ever becomes something people pay for.

Fourth, it keeps working without a connection. A service worker caches the app and Transformers.js caches the weights. This was tested in headless Chromium with the network switched off, using the smallest model: the page reopened and the model loaded from cache in three seconds. It has not been tested on a phone or on truck-stop Wi-Fi.

A large hosted model would probably write better plain-English lines than a model this size. That was not measured here, and this is a document I would not send out anyway.

My Agent Session

I do not have a DevRelay export of the session, so here is the plain account. I directed an AI coding agent, Claude, through this project. It read the forum threads, wrote the code and the test documents, ran the benchmark in Chrome on my Mac, graded the 77 lines and drafted this post. The repository has every prompt, the test documents, the raw model outputs and the grades, so the numbers can be checked.

What is next

Nobody has used it on a real load yet, so there is no first-user section in this post. The next step is to run real rate confirmations through it with a working owner-operator watching, and to ask the question this week's theme asks: would you pay for this? After that: add OCR for scanned PDFs, and try fine-tuning the 270M model on labeled clauses, since a 270 MB download would suit a phone far better than a 3.1 GB one.

Prize Categories

Best Use of Gemma. The app runs Gemma 4 E2B locally in the browser, and the benchmark compares it with Gemma 3 1B and Gemma 3 270M on the same task.

RateCon Radar is a reading aid and not legal advice.

Sources

TruckersReport, "Fined for delivery early" (2013)
TruckersReport, "CH Robinson deducted my rate for arriving early" (2013)
TruckersReport, "Signed Rate Con" (2018)
Adam Wingfield, "Every Load You Haul Starts Here: Don't Skip the Fine Print," FreightWaves (2025)
Adam Wingfield, "How to Read Your Rate Con Like a Pro," FreightWaves (2025)

Lookout: the alarm that goes off before a scam's getaway

Anudeep Bonagiri — Mon, 05 Oct 2026 23:36:25 +0000

This is a submission for the MLH x DEV Writing Challenge

What I Built

Lookout is a practice wallet where a risky payment waits until someone you trust agrees to it.

The theme at Rowdy Hacks XII was "Heist," and the title sponsor, Swivel, asked teams to build a shield against social engineering. So we flipped the theme around. Instead of planning a heist, we built the lookout who stops one.

People over 60 lost billions of dollars to scams last year, and in almost every case the victim approved the payment themselves. Banks check whether the account holder authorized a transfer. In a scam they did authorize it, because a stranger on the phone talked them into it. The fraud happens in the conversation, so a login check never sees it.

Lookout steps in right before the money moves. In our demo, Rosa opens the wallet to send $2,000 because "the IRS" texted her about a warrant. Lookout reads the payment along with the message that prompted it, scores the risk from 0 to 100, and decides to allow, verify, or hold. On a hold, Rosa sees which stage of the heist the scammer has reached, a few plain-language reasons, and hears a spoken warning in English or Spanish. Her daughter Maya, the trusted contact she picked ahead of time, gets the request on her own phone with the amount, the recipient and the signals that fired. Maya never sees passwords or codes. She taps approve or deny, and Rosa gets the answer along with a safer next step.

We kept a few rules the whole weekend. Gemini interprets the message, but a small scoring function in plain code makes the decision, and no single signal can hold a payment on its own, since words like "urgent" show up in normal texts all the time. Each point in the score maps to a sentence Rosa can read. Lookout never moves money by itself: releasing a held payment requires a human to confirm, and that check lives in the code instead of the prompt. Codes are redacted before the request reaches anyone else.

We also added a /learn page, a six-round game where you read a message, flag the scam signals and watch Lookout's score build using the real weights and thresholds. Catching a scam once helps one person on one day. Teaching the pattern sticks around longer.

The thing I'll take away from this build is that catching scams turned out to be the easier half. The harder half was leaving the rent payment and a grandkid's birthday money alone, because one false alarm costs more trust than a missed scam.

Demo

You can visit the landing page at stoptheheist.us and try the scam-signal trainer at stoptheheist.us/learn.

anudeep-bonagiri / Lookout

Lookout

A risky payment waits until someone you trust agrees. This is a practice wallet!

Main application

apps/web is the landing page, the wallet, and the Lookout's phone.
apps/api receives a payment check and returns allow, pause, or hold.

Open / for the door. Open /wallet for Rosa. Open /crew/maya-demo for Maya. On a wide screen the wallet sits in one phone. On a real phone it fills the screen.

Data

apps/api/schema.sql is the Tiger tables and the hourly chart.
apps/api/app/db.py is the records: payments, approvals, reasons, watchers, pulse samples.
apps/api/app/samples is the IRS text used in the demo.

How a payment is decided

apps/api/app/labels.py — Gemini, or the offline rules, reads the words.
apps/api/app/scoring.py — the fixed score. One signal cannot hold a payment.
apps/api/app/why.py — why the money is moving, ranked by threat and updated from a finished payment or a denial.
apps/api/app/desks — watchers. A new file…

View on GitHub

Partner Technologies

Gemini does the reading. It takes the payment note and the suspicious message (pasted text or a screenshot) and returns structured JSON against a fixed schema with fields for an authority claim, a threat or reward, urgency, secrecy and a sensitive request. Using structured output was the decision that made everything else work, because the model can only hand back labels our scoring layer checks. It never gets to return a verdict. If Gemini errors out or the key is missing, Lookout falls back to an offline rules engine so the demo survives bad venue Wi-Fi. Gemini also writes replies for our phone voice agent, with scripted lines as a backup.

ElevenLabs speaks the warnings using eleven_multilingual_v2, with one English voice and one Spanish voice. For an older person in the middle of a scam, hearing "You are being rushed. That is how scams work." out loud gets through better than a red banner on the screen. San Antonio is a bilingual city, so Spanish had to be there from the start.

Tiger Data (TimescaleDB) stores payment attempts, risk checks and vitals samples as hypertables. A continuous aggregate rolls the risk checks into an hourly chart for Maya's history view. When no Tiger URL is configured, the API drops to SQLite on a Docker volume, which got us through setup more than once.

We also wired up Presage SmartSpectra to read pulse and breathing from the camera. A spike only counts after a 15-second baseline, and if the sensor isn't there the code reports nothing instead of making up a number. Elevated pressure adds one signal to the score and nothing more.

The rest of the stack is FastAPI and Next.js, Twilio for a call-in voice check, a shared list of reported scam numbers, an ESP32 alarm light that polls for active holds, and Docker Compose behind Caddy with automatic HTTPS.

Hackathon Experience

Rowdy Hacks XII was at UTSA, my home school, and I built Lookout with my teammate Takshi Savaliya. For 24 hours the room was full of vaults, escape rooms and getaway cars.

Around 3am the first thing to break was our plan. We had a design doc that mapped out a dozen prize tracks, and by the middle of the night it was clear we couldn't ship all of it. We cut hard and protected the core flow of wallet, risk check, hold screen and trusted-contact approval. Everything else had to earn its way back in.

Then deployment broke right before judging. Our config found the repo root with parents[3], which worked fine on our laptops and overflowed inside the container at /app, so uvicorn crashed on startup. A type check in the scroll intro also failed the production build. Both fixes were one line each and went in during the last stretch before submission. Twilio's trial account only calls verified numbers, too, so for the demo the "call my phone" button turned into "call in."

What I'll remember most is that many of the judges were volunteers without a technical background. That pushed us to make Lookout make sense in 30 seconds: "You're grandma. You just got this text. Try to send the money." When someone who doesn't write code can feel it work in their own hands, I know the engineering underneath is doing its job.