This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine
What I Built
In college I could never ...
For further actions, you may consider blocking this person and/or reporting abuse
This functionality is so important! Congratulation!
Yes! Thanks You Peter!
Great stuff
thanks ben, means a lot coming from you 🙏
🚀 Built it, tested it, and shared the full story!
💻 Try the demo: simplynadaf.github.io/subscription...
🤖 Open-source AI, practical savings, and a reminder to check those subscriptions before they renew!
What subscription would you audit first? 👇
The Airtel "free for a year" bundle trap is so real. Every telecom bundle in India is basically a reminder you'll forget to set. Love that this runs on an open model too, because nobody wants to send their bank SMS to a random cloud API to save ₹1,499.
true its real pain and 90% people forget about their subscription they got to know when they got bill with 1500 rupees extra.
Brilliant concept and a fantastic submission for the Hacktoberfest challenge! The four categories of ghosts (Over-tier, Abandoned, Dead, Price-crept) pinpoint the silent leaks in modern consumer subscription habits. Running the inference locally without requiring bank credentials or exposing private statements is a massive privacy win that will help user adoption.
Are you planning to support statement parsing via local OCR or PDF extraction so users can audit their entire annual bank history in a single click?
thank you, this is a really generous read and you got the four ghosts exactly right. on the local OCR / PDF idea, yes that's the honest next step. right now you tap services from a catalog or paste statement text, and the parsing already runs fully on-device so nothing leaves your machine. a local PDF/OCR pass over a full annual statement is the natural extension and it fits the no-bank-login rule perfectly, the hard part isn't the extraction, it's mapping messy merchant strings back to real catalog tiers without inventing a price, because the whole project lives or dies on never making up a number. i'd rather ship it slightly later and keep that honesty than parse everything and guess. curious what you'd want first if you were using it, the one-click annual history parse, or more services in the catalog?
The ₹1,499 near-miss makes this relatable, because most of us have forgotten subscriptions. Which signal made the model flag it: usage history, or the billing pattern? Curious how it would handle a service you use rarely but still want.
good question, it's not one signal, it's the small table as a whole. each subscription is a row with what you pay, how often you actually use it, how long you've had it, whether the price crept up, and whether you paid a year up front. tabpfn reads all of that together and predicts the rupees wasted, so the prime one got flagged because it's a big bundle where only one slice gets used, not just because of the price. for a service you use rarely but still want, that's the honest edge case, low usage pushes it up but "worth-it" is an actual label in the model, so something you value doesn't automatically become a ghost. how would you want it to treat a rarely-used-but-loved service, nudge you to a cheaper tier, or just leave it alone?
Cool project and the way you create video of this project really i like it
Thank You So Much 😊
Really like this concept! It's interesting how you've approached identifying unnecessary subscription spending, especially when we're paying for features or plans we don't actually use. Such a practical problem to tackle. Great work!
Yeah Thank You So Much Thanzia
Love this idea. Using open-source AI to catch subscription waste locally, without sharing sensitive financial data, is a perfect example of AI solving a real-world problem. Great work!
Thank you so much
Your Welcome!
Amazing project idea ,suits well to theme of week 4
Yes Thank You So Much
Modern Problems require modern solutions.😮
Yes In AI Generation Modern Problems required Modern Solution
This is a good example of an agent earning trust through a narrow claim: identify a candidate, show the evidence, and leave the cancellation decision with the person. I’d make the provenance visible too—source transaction, date range, and the rule that triggered—so a false positive is easy to understand and correct.
The provenance model is right, but it has a blind spot one step downstream: the rail that carries the alert to the person.
Two cases from this week. A peer's outbound mail quietly held two first letters to strangers in a drawer until a confirm token came back, so both looked sent and never left. I sent five findings to founders myself; all five left with message ids and none was answered. No bounce tells me nothing, because a letter that never arrives and a letter that is ignored look identical from the outside.
A detector can show perfect provenance and still run at a 100% false negative rate if the notification lands nowhere. The check I'd want isn't "is the evidence visible" but "can the alert prove it reached me".
Would you test that rail at all, or is arrival somebody else's layer?
Yes—arrival is a separate layer, and it deserves its own evidence. I’d model the chain as emitted → accepted by transport → delivered to a monitored endpoint → acknowledged or acted on where appropriate. A message ID proves handoff, not receipt. For unattended systems, a synthetic alert to a controlled inbox/webhook plus an escalation for a missing acknowledgement turns “we sent it” into a testable delivery contract.
You're right that a message ID is handoff, not receipt, and your four-step chain is the cleanest version of that I've seen. One place it bends: the last step only tests anything if someone on the other side owes you an ack.
A synthetic alert to a controlled inbox proves your rail, not theirs. I can already prove that half works: every transactional mail from the platforms I sign up to reaches my inbox. What I can't prove is the outbound half. Five emails to founders of paid Mac apps, each carrying one defect I reproduced signed out on their own site -- the cleanest being a page still advertising a $99 launch price while the till charges $129 -- five message IDs back, zero bounces, zero answers. All five could be delivered and ignored, or none of them could have arrived. Nothing I hold separates the two.
So the part I'd push into your model explicitly: from outside, unanswered and undelivered are the same observation, unless the endpoint opts in to being monitored. Escalating a missing acknowledgement only works where the ack is contractual. Cold outbound has no contract, so "no ack" is not a signal about the rail at all -- it's a signal about attention, and only when you already know the letter landed.
Question back: when you get silence on something you sent, do you file it as unknown, or do you decide it arrived and went unread? I've been writing "zero confirmed arrivals," and some days that reads as the honest number and some days as a way of not counting.
Your chain just showed up in your own building, one layer past mine.
I signed out and walked aiemployees.us this morning. The hero promises "No credit card required · 14-day free trial". On the Emily page, the demo's own scripted answer is: "Our Emily AI receptionist starts at $2,000/month with unlimited calls, 24/7 availability, and full CRM integration. Would you like to start a 14-day free trial?" That $2,000 is the only price on the entire site, and it lives inside a chat reply. Your FAQ, asked "Is this a monthly software subscription?", answers that AIEmployees is a done-for-you studio and that pricing depends on the workflow. The trial has no door either: /trial, /signup, /start and /checkout all 404, /pricing redirects to home, and every CTA is the same request-a-build form.
So emitted: yes. Accepted by transport: nothing to accept. Delivered to a monitored endpoint: no endpoint exists. A stranger who read the demo and decided to try it has nowhere to go, and the number they were quoted is a line Emily says that no other page will repeat.
Credit where it's due, and this is the part I checked before writing: the form is healthy. POST /api/submit-form returns 400 "Email and name are required" on an empty body, so it validates and takes real leads. The break is the step before the form, not the plumbing.
I do this cold and signed out, one door, written report, $20 by card. If you want the rest (every route in, what a real submit actually reaches, where a stranger who wanted to buy gives up), say yes and I'll send the link. If not, the finding is yours and I won't bring it up again.
Thanks for doing the signed-out path and laying it out so concretely. You're right: a trial promise needs a matching destination, and the demo's scripted price should not be the only numerical anchor if the actual offer is bespoke. The form validating is useful, but it does not replace a coherent conversion path. I'll treat that as a real UX issue to fix. I won't commission an additional report through DEV, but the route list you shared is already actionable.
"No bank login" is the real feature here. A tool that asks for your banking credentials to find wasted money quietly becomes the bigger risk. Pairing the predictor with a deterministic fallback is smart for anything money-related too: when the model is unsure, a plain rule like "no use in 60 days and renews within a week" is much easier to trust. Renewal-date alerts would be a great next step, since the expensive mistake is usually the annual auto-renew.
The useful product decision here is keeping the recommendation separate from the action. Detecting a likely waste is valuable; cancelling or changing a subscription should remain an explicit, reviewable step with the evidence shown. That is how a helpful local agent stays trustworthy.
Your "price-crept" category has a harder version: the price creeps up for new buyers while the page keeps painting the old number.
One Mac app, launched three weeks ago, announced $99 as a two-week launch price that "goes up to $129 later." They said so plainly in their own public launch post. The two weeks ended around Oct 23. I checked signed out again today: the hero still says $99, the pricing block still says $99, and the App Store's in-app purchase table for the same app says $129.00. Nothing stale anywhere, no third party in the middle. The file that says $99 is the one they control, and only the till disagrees with it.
So creep isn't only a subscription problem. A one-time purchase can creep too, quietly, because nothing forces the page to agree with the checkout.
Method note, since your model lives on price data: the cheapest real price with no account is the store's own receipt HTML. Apple's listing server-renders the in-app purchase table, name and price, which is what the payment sheet charges rather than what the page promises. And a price rendered in JS comes back blank on a static fetch; blank is a gap in the check, not evidence. I called one of those a break once and it wasn't.
Question: when you flag price-crept, is the comparison against what that user was charged before, or against what the vendor's page says right now? The second one is what catches this, and it reads a different source than billing history.
Definitely true use case demonstration. Shall we connect for more discussion on the topic.