Cliffcheck

Hero
Impact and action

Inspiration

A raise should never leave you poorer. But for millions of US households that gethelp with food, health coverage, rent, or childcare, it happens all the time.

Earn a few hundred dollars more and a benefit worth thousands can cut off. The programs are run by different agencies and none of them coordinate, so the loss is invisible until the paycheck lands.

CliffCheck started as an entry in a community hackathon built around one theme: escape the permanent underclass.

The benefits cliff is one of the traps that keeps people stuck, because the rational move looks like turning down a raise.

That first version drew the cliff for a single state and placed third. Since then it has become a live tool with a benefit-rule engine covering 16 states, and it found an audience through people sharing their own cliff online.

The WebMCP Challenge added a new angle. When someone asks an AI assistant whether to take a promotion, the assistant guesses. It has no real model of how benefits phase out as income rises. I wanted it to call the actual engine instead.

What it does

You enter your state, household size, current income, and which benefits you receive. CliffCheck draws your real income across every wage level from $0 to $200,000 and marks every point where earning more would leave you with less. It shows your safe target: the wage where a raise finally puts you ahead. It also writes a short, copy-paste brief you can take into a conversation with your manager.

All of it runs in your browser. No account, no upload, nothing saved. Your financial details never leave your device.

With WebMCP, an in-browser agent gets that same engine as four tools it can call:

calculate_cliff — your real income before and after a raise, and the change
get_cliff_curve — the full curve, plus the steepest drop and what causes it
get_safe_exit — the lowest wage that clears your current income for good
list_supported_states — the 16 states with vetted rules

How the number works

Your real income is not just your wage. It is your wage, plus the cash value of every benefit you receive, minus every tax you owe:

real income = wage + benefits − taxes

CliffCheck works that out at every wage level and draws the line. Most of the time the line goes up: earn more, keep more. A benefits cliff is where the line goes down instead. You earned more and ended up with less, because what you lost in benefits was worth more than the raise.

I model each benefit as a gradual phase-out rather than a hard on/off switch, which is closer to how they actually work, so the chart shows a slope you can see coming instead of a single vertical drop.

Here is the built-in example. An Ohio family of four, one earner at $44,000, offered a promotion to $70,000. At the higher wage they lose SNAP, Medicaid, and most of their childcare subsidy, they start paying for health coverage, and more of the wage goes to tax. Add it all up and the $26,000 raise leaves them about $14,600 worse off over the year. The chart shows their safe target is around $96,000, and the sharpest single step down is just after $47,000, where the childcare subsidy ends.

How I built it

The engine is plain TypeScript with no framework tied to it. Federal rules (SNAP, poverty guidelines, ACA premium caps, the EITC and Child Tax Credit, payroll and income tax) live in one module.

Each state is a single file with its Medicaid rules, childcare subsidy schedule, housing standards, and income tax brackets.

Adding a state is one file and one line. Every state ships with automated tests that check the cliff math and confirm each rule value cites a government source.

There are 219 of these tests.

The app is Next.js 16, React 19, Tailwind, and Recharts for the chart. Most pages are static. The only server code is a contact form.

The WebMCP layer is small on purpose. One file defines the four tools and their inputs. One file registers them with the browser through document.modelContext and does nothing if the browser has no WebMCP support.

A small component mounts that from the app shell so the tools are available on every page. The tools run the same calculations the visible app does, with no network call, so an agent gets the same answer a person does and the privacy promise still holds.

Challenges I ran into

The standard is new. WebMCP is behind a Chrome origin trial and the API isstill moving. I kept our adapter thin so a spec change is a small edit, not a rewrite.