SlothPay: the sloth that pays for you - fail-closed agent payments with a local Gemma 3

A developer built SlothPay, an open-source, fail-closed agent payment tool that lets software autonomously settle machine-payable HTTP (x402) requests within user-defined price ceilings and nightly budgets. The tool runs a local Gemma 3 1B model on llama.cpp for morning digests and wake/sleep triage in strict JSON, while all arithmetic is handled by Python's Decimal to prevent the model from hallucinating prices. In a demo sweep of three mock sellers, SlothPay paid the well-behaved $0.05 endpoint, denied a hostile one for insufficient challenge entropy, and skipped a free resource.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady https://dev.to/challenges/hacktoberfest-week3-2026-10-19 SlothPay https://github.com/eddyflores100-lang/slothpay — the sloth that pays for you. Machine-payable HTTP the x402 flow, where a server answers 402 with a price and your software just... pays is powerful and slightly terrifying: your software can spend money while you are not looking. The usual answers are a cloud dashboard, a closed trust API, or another subscription. SlothPay is the lazy, local answer. You tell it once which resources your agents may buy and up to what price. Every night it: 402 Payment Required , it reads the seller's Who gets to be lazier? Anyone whose agents buy things from machines — API consumers, agent-framework users, tinkerers running local automation. You never review trust paperwork and you never click "buy" for a $0.05 endpoint again. You sleep; the sloth settles. Everything below is a real transcript from the repo's demo — one mock seller serving three resources: a well-behaved one, a hostile one shipping a real bad credential, and a free one. php $ slothpay sweep 🦥 sloth wakes. budget 1.00 USD, spent tonight 0 USD - http://127.0.0.1:8402/api/sleep-sounds PASS R0 signature verifies demo crypto PASS R1 amount usd fixed-scale string ok PASS R2 challenge entropy ok 24 bytes PASS R3 pin 'seller-demo-key-2026' present and in-window PASS R5 issued at/expires in present and sane PASS R6 credential inside validity window / resource binding ok PASS R4 verifier confirmed verdict: PASS — all rev-4 checks passed PAID 200 — verified + $0.05 <= ceiling $0.50 + budget ok - http://127.0.0.1:8402/api/night-report FAIL R2 challenge entropy < 128 bits 5 bytes DENY — trust check failed - http://127.0.0.1:8402/api/free-tips 200 — free, the sloth naps Morning: bash $ slothpay digest Paid 1 of 3 requests, total $0.05. Insufficient funds or trust violation – request denied. The project is also live on https://utalabs.tech https://utalabs.tech a landing with the full story; it currently serves the workers.dev mirror while DNS propagates . github.com/eddyflores100-lang/slothpay https://github.com/eddyflores100-lang/slothpay — Apache-2.0, Python 3.12+, zero required dependencies the optional Gemma path uses llama.cpp . Inside: slothpay/verify.py — the fail-closed verifier R0–R6, every branch testable corpus/vectors.json — a slothpay/policy.py — the lazy policy engine: ceilings, nightly budgets, allow/deny lists slothpay/llm.py — the local brain: Gemma writes the morning note; Decimal , never by the model demo/mock seller.py — stdlib-only x402-shaped seller, hostile variant included tests/ — 8 tests including a full end-to-end sweep; all green Three open pieces hold the whole thing together — none of them closed: Gemma 3 1B open-weight on llama.cpp, CPU-only. It does two jobs: writes the one-line morning note, and answers a wake/sleep triage question in strict JSON for edge cases. I deliberately did not let it do arithmetic — a model hallucinating a price is the one sloth sin I don't allow. So Gemma writes the commentary; Python's Decimal writes the numbers. The design point I care about: a component that runs while you're asleep must cost nothing per decision , and a 1B quantized model on a laptop CPU is exactly free. x402 open protocol . The client conversation is x402-shaped: 402 → PAYMENT-REQUIRED carrying the seller's credential and pinset reference → PAYMENT retry. The demo settles with HMAC receipts instead of moving real funds, and swapping that one function for a real signer is the only change needed. Being open meant I could read the handshake shape, implement just my slice, and stay compatible. ATC/1.0 open trust spec . The credential verification implements the §5 payment-credential profile from the openly published Universal Trust Adapter proposal, with the rev-4 hardening: fixed-scale amount usd strings ≤ 6 dp , seller-minted challenges with ≥ 128 bits of entropy, kid /pinset windows not before / not after , mandatory issued at / expires in , and — my favorite rule — if the trust verifier can't be reached, you deny. Never fail-open. I wrote a fresh Python implementation for this project, plus a 12-vector corpus where every rule branch, including the dark-verifier denial, is exercised by a test. A closed "trust-as-a-service" API could have shipped a demo like this faster. It could not have shipped this project, for three concrete reasons: Auditable decisions. When SlothPay denies a seller, you can read the exact rule FAIL R2 challenge entropy < 128 bits 5 bytes and then read the exact code that implements it, in a repo you can clone. Trust logic you can't read is just a black box with a logo — and this project's entire job is deciding who may spend your money. Closed would have defeated the point. Your money, your machine. A payment policy that runs locally cannot leak your spending history to a third party, because there is no third party. It also cannot be shut off, repriced, or deprecated under you at 3am — which is precisely when an overnight agent would be running. Swappable everything. Want Ed25519 instead of the demo HMAC? A bigger open model? Your own verifier network? Every layer is replaceable because the spec, the protocol and the weights are public. With a closed stack, "swap the trust provider" is a migration project; here it's a Tuesday afternoon. And the quiet one: it can exist at all. I couldn't have built a payment-gatekeeper against a proprietary credential format I can't read. Open specs let a weekend project touch money-grade problems safely. I built this with an AI coding agent, so showing the work matters to me. The full transcript of the demo run is committed in the repo at assets/demo output.txt https://github.com/eddyflores100-lang/slothpay/blob/main/assets/demo output.txt byte-for-byte what you saw above, nothing staged , the rule-by-rule verifier trace is part of every sweep, and the commit history shows the build order: verifier → corpus → policy → client → seller → digest. A DevRelay session embed is coming as an update before submissions close. The honest numbers from this week: policy.json with your ceilings and budget. I have not touched mine since. Slow and steady settles everything — including the invoices.