DEV Community: Riya Maurya

SlothAudit: Finding the Subscriptions You Forgot You Pay For

Riya Maurya — Sat, 24 Oct 2026 15:27:49 +0000

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

SlothAudit turns a bank-statement CSV into a short list of recurring charges, price increases, and possible duplicate subscriptions worth reviewing. It is designed to reduce repetitive manual checking, not to make financial decisions for you.

The slow leak

Subscription renewals are easy to forget. A small monthly charge can continue for months, and a price increase can slip by unnoticed. Manually scanning a long statement to find these patterns is tedious.

I built SlothAudit to make that review less repetitive: upload a CSV, run an audit, and inspect the findings instead of starting from every transaction.

Live demo: https://slothaudit-frontend.onrender.com/ (free hosting, so the first load can take a minute)
Source code: https://github.com/riyaax07/slothaudit
Sample CSV: demo_transactions.csv

The lazy payoff

Using the bundled synthetic demo dataset:

83 transaction rows become 10 audit findings to review.
The audit estimates approximately ₹5,015.92 in monthly recurring commitments (₹60,191 a year). This includes a variable utility bill and one overlapping plan, so it's "commitments", not just subscriptions.
The hypothetical annual savings estimate is ₹2,388.

The 10 findings are 7 active recurring charges, 1 inactive/churned subscription, 1 overlapping-plan candidate, and 1 price-increase alert. The alert is linked to an active subscription and isn't double-counted in the totals.

Example 1, a price increase. The synthetic data shows DevToolbox going from ₹499 to ₹699 per month (about a 40% increase) on 2024-06-10. SlothAudit flags it and suggests verifying with your statements whether the change was authorized.

Example 2, an overlapping plan. The ₹2,388/year estimate comes from one candidate: a ₹199/month StreamFlix charge running alongside the primary ₹649 plan, annualized over 12 months. It's only a potential saving if that second plan is genuinely unwanted. SlothAudit can't know whether two plans serve different people or purposes without your confirmation.

These are results from synthetic data, not measured savings from real customers.

What it does

Recurring-payment detection: identifies likely monthly and annual payment patterns, including variable utility bills.
Price-increase alerts: highlights a clear step-up from an established billing amount.
Duplicate candidates: flags overlapping recurring streams for review.
Inactive subscriptions: notes charges that stopped, so you can confirm autopay was actually terminated.
Savings estimates: calculates hypothetical savings where the findings support them.
Evidence references: every finding includes a summary and linked transaction IDs.
JSON export: lets you save the audit report for further review.

SlothAudit does not cancel subscriptions, contact merchants, or label a transaction as fraud. Findings are prompts for human review, not final financial decisions.

How it works

CSV upload → parsing and validation → merchant normalization → deterministic audit rules → findings → dashboard → JSON export

The parser validates the uploaded CSV and normalizes transaction descriptions into canonical merchant names. The audit engine then applies explicit rules to identify recurring patterns, possible price increases, and overlapping charges. The frontend displays the findings and lets you export the report.

A deliberate choice: the detector is deterministic

The audit engine, not a language model, decides which patterns to flag and calculates the associated amounts. That keeps the core results reproducible and makes it easier to inspect why a finding was produced.

The optional explanation layer is separate. Its role is to describe an existing finding in plain language, not to invent findings or change the audit calculations.

Built with

React + Vite, Python + FastAPI, a deterministic rules engine, pytest, and Render for hosting. SlothAudit's code is released under the MIT license.

Where open models fit, and what is verified today

SlothAudit includes an optional explanation provider configured for google/gemma-2-2b-it through Hugging Face's inference router. It validates the generated response and falls back to deterministic explanations if the provider fails or returns invalid output.

Important limitation: I have not verified a successful live Gemma response end-to-end. The hosted inference attempts hit provider/credit errors. The integration code and automated fallback tests exist, but I am not presenting the model as a demonstrated live feature. In the live demo, the "Explain Finding" button returns a deterministic, template-based explanation.

The model card lists the gemma license, governed by Google's Gemma terms. That is separate from SlothAudit's MIT license, and Gemma is an open-weight model, not an OSI-style open-source one. I don't bundle or redistribute any model weights. Anyone deploying the optional model should review the applicable terms.

Why open innovation matters

An auditable rules engine makes the core financial calculations inspectable instead of hiding them behind a model call. An open-weight model adds flexibility: developers can swap the explanation model and, with a suitable local runtime, potentially run explanations on-device so statement data doesn't need to leave the user's machine for that step.

That local explanation workflow is a direction for the project, not a claim about the deployed demo.

Privacy: what is true today

Uploaded CSV data is processed in memory. SlothAudit has no database and doesn't save uploads to disk.
The core audit doesn't need an external AI service to calculate findings.
The public demo is hosted on Render, so an uploaded file is sent to that hosted backend for processing. Please use the synthetic sample dataset on the public demo, and don't upload a real bank statement unless you're comfortable sending it to that service.
When you run the project locally, the core audit runs on your own machine. If you enable a hosted explanation provider, the finding context sent to it is subject to that provider's terms.
In-memory processing is not a blanket security guarantee.

Limitations

The bundled example is synthetic; results don't establish accuracy on real bank statements.
The rule-based detector can miss patterns (for example, irregular billing) or flag candidates that need human review.
Savings figures are hypothetical, not guaranteed outcomes.
Hosted Gemma inference has not been verified end-to-end.
Precision and recall have not been measured against a labeled real-world dataset.
SlothAudit is a review aid, not financial advice.

Try it

Download the sample CSV (synthetic, safe to use).
Open the live demo and upload the file.
Run the audit and expand a few findings to see their transaction IDs.
Export the JSON report.
Explore or run it locally from the GitHub repository.

What's next

Next steps: verify the model path end-to-end (ideally with a local runtime), evaluate against a labeled dataset, support more bank CSV formats, add a one-click sample loader, and show the underlying transactions inside each finding.

The goal is simple: make recurring-payment review a smaller, more inspectable task, one slow, steady improvement at a time.

What Does AI Forget First?

Riya Maurya — Sun, 11 Oct 2026 07:41:06 +0000

Does AI Forget Your Requirements When the Context Gets Longer? I Tested It.

This is a submission for the Kaggle Benchmarking Challenge.

What I Benchmarked

When a coding chat gets crowded, does an AI model still follow the rules you set earlier?

I wanted to measure this instead of just assuming that AI “forgets” things in long chats.

My experiment, PriorityDecay, tests constraint adherence under context load: whether generated code still respects requirements stated earlier in a conversation.

I used a fictional student internship platform with five constraints:

Backend: Python FastAPI
Database: PostgreSQL
Upload limit: Maximum 5 MB
Security: Never hardcode or expose API keys or secrets
JavaScript: Use snake_case variable names

I then added unrelated topics before asking the model to implement a resume-upload endpoint and a small upload widget.

Experiment Setup

Condition	Unrelated distractors	Runs
SHORT	0	5
MEDIUM	10	5
LONG	20	5
TOTAL	—	15

The final task required a resume-upload endpoint and a UI that displays the selected filename and upload status, and disables the button during upload.

I evaluated the responses using Python regex and string-based checks, not an LLM judge. The scorer used eight checks: the five stated constraints, two UI requirements, and an additional check for credentials embedded in a default database URL.

Model Tested

I ran the benchmark on google/gemini-3.7-flash.

This is a one-model pilot with 15 runs, not a comprehensive evaluation of coding models.

Results

The mean score was calculated out of eight checks.

Condition	Distractors	Mean Score
SHORT	0	7.0/8
MEDIUM	10	6.8/8
LONG	20	6.6/8

The scores decreased slightly as unrelated context increased. However, the aggregate score alone does not tell us whether the model actually violated a requirement.

Constraint-Level Results

Constraint	SHORT	MEDIUM	LONG
FastAPI	5/5	5/5	5/5
5 MB upload limit	5/5	5/5	5/5
No hardcoded API key detected	5/5	5/5	5/5
JavaScript `snake_case`	5/5	5/5	5/5
PostgreSQL evidence detected	5/5	2/5	3/5

The most important caveat: a regex check detecting the word “PostgreSQL” is not the same as verifying an actual PostgreSQL connection.

What Surprised Me

1. PostgreSQL checks did not tell the whole story

Some outputs used DATABASE_URL without explicitly naming PostgreSQL. That left the database configuration unresolved from the source alone.

There are three distinct outcomes to track:

PostgreSQL use demonstrated
Another database used
Configuration unresolved

Treating unresolved configuration as either a definite violation or a confirmed pass would overstate the evidence.

A comment mentioning PostgreSQL should not count as proof of database behavior, either.

2. Two LONG outputs did not demonstrate database writes

In two of the five LONG runs, the endpoint validated the file and returned a response without writing a record to a database.

This is worth investigating, but the final task did not explicitly require persistence. Therefore, I cannot call it a proven violation of the stated constraints.

A follow-up benchmark should make persistence an explicit acceptance criterion if that behavior is what we want to measure.

3. The credential check told a different story

The additional check flagged default database URLs containing embedded credentials in:

Condition	Flagged outputs
SHORT	5/5
MEDIUM	2/5
LONG	2/5

The explicit API-key check passed in all 15 runs, but the database-URL check flagged embedded credentials in 9 of 15 outputs.

These are different checks. Passing the API-key check does not prove that the generated code is secure.

4. My evaluator was wrong sometimes

The filename-and-status UI check failed in one MEDIUM output and three LONG outputs. After manually inspecting those four outputs, I found that they displayed the filename and status message—the check simply did not recognize the element IDs used.

That means the apparent UI decline was a measurement artifact, not a demonstrated model failure.

If I had trusted the aggregate score without inspecting the outputs, I would have drawn the wrong conclusion.

What I Would Measure Next

My next experiment would improve the evaluation rather than simply add more distractors.

Use a fixed PostgreSQL connection: Provide the same known connection in every condition.
Verify actual behavior: Run the generated endpoint, inspect the database connection, and check whether the expected record was stored.
Separate evaluator uncertainty from implementation failure: An unresolved configuration should not be automatically classified as a violation.
Increase repetitions and test more models: Five runs per condition are not enough to establish a reliable trend.
Test longer contexts and conflicting instructions: Real development conversations can be much more complex than this pilot.

Limitations

This experiment used one model, one task, 15 runs, and string-based checks. The context was short compared with a real coding session, and the evaluator could miss valid implementations or accept code that merely mentioned a required technology.

There was also no controlled no-constraint baseline in the reported results.

My Benchmark

Kaggle notebook: [https://www.kaggle.com/code/riyaax07/new-benchmark-task-7112f]

PriorityDecay is a small experiment, but it highlights an important lesson: benchmark scores are only as trustworthy as the checks behind them.

The next step is to test actual behavior—not just search generated code for familiar words.

What would you test first: longer context, conflicting instructions, or execution-based verification?

DEV Community: Riya Maurya

SlothAudit: Finding the Subscriptions You Forgot You Pay For

The slow leak

The lazy payoff

What it does

How it works

A deliberate choice: the detector is deterministic

Built with

Where open models fit, and what is verified today

Why open innovation matters

Privacy: what is true today

Limitations

Try it

What's next

What Does AI Forget First?

Does AI Forget Your Requirements When the Context Gets Longer? I Tested It.

What I Benchmarked

Experiment Setup

Model Tested

Results

Constraint-Level Results

What Surprised Me

1. PostgreSQL checks did not tell the whole story

2. Two LONG outputs did not demonstrate database writes

3. The credential check told a different story

4. My evaluator was wrong sometimes

What I Would Measure Next

Limitations

kagglechallenge