DEV Community: Jerrie Adah

Sloth Queue — three things, then a nap

Jerrie Adah — Sat, 24 Oct 2026 17:32:10 +0000

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

My laptop is not a GPU box, so "run a model locally" was never the interesting constraint. The interesting one was: can the lazy part be real code, and can the model be swapped without loosening it?

Sloth Queue is a small web app for the pile you keep orbiting. A group chat. An inbox. The note that has been rewritten four times. You paste it. You get a two-line morning note, at most three things worth doing, drafts for the ones that are just a reply, and a list of what got held back.

https://cursor.com/codebase/jerrie-kingdomdev/fest-finder

What effort it saves

The chore is triage. Not the work itself. The work is usually two messages and one errand, buried under newsletters, reaction GIFs, and tasks that belong to someone else. I reread that kind of pile because deciding feels harder than doing. The app does the deciding.

The samples are the demo:

A Sunday chat with fourteen messages. Two of them are asks. The reel, the song, and "react if you see this" are dropped. Ice can wait, because someone already offered.
An inbox where a landlord needs a yes or no before the electrician arrives, a boss will accept two lines, and a mom wants a call about a dog. The permission slip is due Friday, so it waits until Sunday evening. The lamp sale does not get a click.
A meeting note that tried to assign you a flaky test with no owner, a 14-page PDF, and two actual asks. The PDF needs a sitting. The asks are a spare minute.

That last one is the payoff. A helpful model will turn a meeting into homework. The cap will not.

How it is built

The agent is a Mastra agent, sloth-agent. Mastra is the open-source harness: instructions, a tool, and a model you can point somewhere else. The tool is apply-sloth-cap. The model is told to be a normal helpful assistant and to mark anything slightly useful as "today". Then the tool, which is just TypeScript, keeps three.

](...)

The rules are dull on purpose:

Today holds three items at most.
Energy of 4 or 5 means it needs a sitting. It waits.
Newsletters, promo, and other people's tasks are noise.
A person who is waiting, with a real deadline, is the one thing the sloth will pull back onto the list if a draft tried to drop them.
Something you already deferred stays deferred unless someone is blocked again.

After the model returns, the server runs the same function again. If the model skips the tool, or sweetens the buckets on the way out, the cap still happens. The screen shows the difference: "The model wanted 8 things today. The cap kept 3."

The model is not on the laptop. The default preset is openai/gpt-oss-20b on Groq, which is open weights behind a fast API. There is a larger gpt-oss preset, an OpenRouter preset for Gemma 3 12B (Google's open-weight model, for the Gemma category), and a box for any OpenAI-compatible host. Swapping the model is a settings change. Swapping the model does not change the cap.

With no key, the sample piles still run. An eager hand-labeled pass stands in for the model, and the same function edits it. A pasted pile with no key uses a smaller local sorter, and the screen says so. I would rather show a boring honest result than pretend a heuristic is Gemma.

Why open, here

A closed chat window will help you have a productive day. That is the failure. You cannot see the rule, you cannot cap it, and you cannot point it at a different open model when the first one is slow or expensive or gone.

Three open pieces are doing the work:

Mastra, which is the agent. The instructions and the tool are in the repo.
The cap, which is a function with tests. It does not care which model proposed the list.
The model id, which is a string. gpt-oss, Gemma, Qwen, whatever speaks chat completions. The weights stay on someone else's machine, which is the whole point on a low-spec laptop, and you can change them without rewriting the chore.

Personal piles stay in the request you choose to send. Demo mode never leaves the machine. There is no account and no database. History is six morning notes in the browser.

The lazy payoff is the morning note. Two lines. Three things. Then you can stop reading the pile.

Try it

npm install
npm run dev

Open http://127.0.0.1:3847, pick "The inbox" or "The meeting", and hand it over. Add a Groq or OpenRouter key in Model if you want the open-weight model to read a pile of your own.

ShopCast: a sales forecast a small shop can actually pay for

Jerrie Adah — Sun, 18 Oct 2026 23:09:10 +0000

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

What I Built

The shop owner already knows Saturday is busy. What they cannot price is how much busier, or what happens if they run a Friday promo, or whether last month's "slow Wednesday" was just Wednesday.

Closed forecasting tools want a seat licence in dollars and the whole sales history on a server they control. For a bakery or mini-mart, that is not a product. That is a cost centre.

ShopCast is the version I would actually charge for. Export daily sales as a CSV (date, sales, optional promo). Click Start forecast. You get:

the next 1–8 weeks of sales, with a range, not a single smug number
unusual days the model did not expect (generator died, surprise catering order)
a backtest against the owner's own rule: "same as last week"
a chat box that answers "what if I promo every Friday?" with TabPFN's numbers, then Gemma's words

Who pays: a shop that would spend a few thousand naira a month to stop over-baking on Tuesdays.

welcome screen with Start forecast

Demo

video:

live app (Render): https://shopcast.onrender.com Note that a free Render box sleeps, so the first load can take a minute.

forecast chart: —

blue history, orange dashed future.

Unusual days table:

Ask ShopCast answering a promo or forecast question, with Numbers behind this answer open.

Code

AdahJerrie / shopcast

The shop owner uploads a sales CSV. The TabPFN API predicts next month's sales and flags unusual days, and Gemma explains the results in plain English.

ShopCast

Sales forecasts for small shops. Upload a daily sales CSV and ShopCast:

forecasts the next 1 to 8 weeks with TabPFN (Prior Labs' tabular foundation model), with a 10-90% band

flags unusual days (spikes and drops) by scoring each day with a model that never saw it

backtests itself on the last 28 days against "same as last week", so the owner can see whether to trust it

answers questions in plain English through a small Gemma agent: forecast, unusual days, and "what if I run a promo every Friday?"

CSV format

column required notes

date yes also accepts day, sale_date, transaction_date

sales yes also accepts revenue, amount, total, turnover; multiple rows per day are summed

promo no 1 on promo days; enables the what-if tool

At least 8 weeks of history is needed. Missing days are treated as zero sales. sample_data/lagos_bakery.csv is…

View on GitHub

column	required	notes
`date`	yes	also accepts `day`, `sale_date`, `transaction_date`
`sales`	yes	also accepts `revenue`, `amount`, `total`, `turnover`; multiple rows per day are summed
`promo`	no	`1` on promo days; enables the what-if tool

The files that matter:

shopcast/forecast.py — TabPFN, one week per call, walk forward
shopcast/anomaly.py — score each day with a model that never saw it
shopcast/agent.py — tools, keyword routing, "copy the naira exactly"
app.py — upload, preview, Start forecast, then the dashboard

How I Built It

I built this on a five-year-old Latitude: 2-core i5, 8 GB RAM, no usable GPU. About a gigabyte free on a good day. So the first design decision was boring and correct: do not run TabPFN or a 27B model on this laptop. TabPFN goes through Prior Labs. Gemma goes through Google AI Studio. The laptop runs Streamlit and pandas.

The second decision was how to make forecasting tabular. Each day is a row: weekday, payday window, Nigerian public holidays, festive season, promo flag, sales from 7 and 14 days ago. Lags start at 7 on purpose. That way TabPFN predicts a whole week in one call, then those predictions become next week's lags. Four API calls for 28 days, not 28.

Unusual days use the same model in 5-fold out-of-sample scoring. I first flagged on robust z-score alone and the sample bakery lit up like a Christmas tree — 13 "anomalies" on ordinary noise. So a day now has to be statistically weird and at least 25% off expected. On the planted sample, TabPFN then flagged exactly the four days I had sabotaged.

Then the chat started lying.

Failure 1: Gemma 3 was gone. First Ask ShopCast reply on the real key:

404 NOT_FOUND … models/gemma-3-27b-it is not found

I had copied a model name from last week's docs. ListModels on this key returned two Gemma 4 models. Switched to gemma-4-26b-a4b-it. One environment variable. That is the open-weight pitch in practice: the product did not die with the model card.

Failure 2: the 1B model cannot route. I tried local gemma3:1b because the laptop can just about hold it. It answered "what if I run a Friday promo?" by calling forecast for 14 days. Clear questions now skip the model: promo / strange / next week go straight to the tool. Gemma only routes the vague ones. Routing went from 1/3 to 4/4.

Failure 3: JSON ate the naira. json.dumps escaped ₦1,452,027 as \u20a61,452,027. Gemma read the trailing 6 and told the owner they would sell "61,452,027 dollars." ensure_ascii=False, and every answer now has a Numbers behind this answer panel. Trust the table, not the prose.

Failure 4: it ran before anyone asked. First version analysed the sample CSV the moment the page loaded — minutes of TabPFN on a shop owner's first click. Now: upload (or sample toggle) → local preview of the last 10 days → Start forecast. Change the file or the horizon and it waits again.

I also tried to use the Gemma 4 E2B I already had in Ollama (4.3 GB). After "closing heavy apps" I still had 0.9 GB free. Cursor, VS Code, Edge, Chrome, and Notion were sitting on the rest. We skipped it. Hosted Gemma stays the default. That is not ideology. That is an 8 GB machine.

Measured, on the sample bakery, real TabPFN + Gemma 4:

Check	Result
TabPFN average daily error	₦4,671
"Same as last week"	₦11,248
Error vs naive	58.5% lower
Unusual days on planted sample	4 of 4

Why Does Open Innovation Matter?

The model vanished and the app did not. Gemma 3 27B 404'd. I listed what the key actually serves and swapped. A closed "forecasting API" with one SKU does not let you do that on a Sunday afternoon.
Small data is the product, not the edge case. A bakery has hundreds of daily rows, not millions. TabPFN is built for that. Asking a general LLM to "look at the CSV and predict October" is how you get confident fiction.
Cost stays at shop scale. TabPFN's free non-commercial tier plus Gemma on AI Studio is the difference between "₦2,000/month might work" and "the API bill is the business." Offline, Gemma 3 1B still explains a cached forecast on this laptop.
The owner's file is not a training set I keep. Preview and Start are local. The hosted path sends features to TabPFN and a short tool result to Gemma, not a dump of every receipt line.

My Agent Session

Building ShopCast: TabPFN forecasts and a Gemma agent that stopped inventing naira

You

Go through the Hacktoberfest Week 2 prompt, then give 3 to 5 project options that fit this laptop. Avoid anything too memory-draining.

Agent

The laptop is a Latitude 7480: 2-core i5-7300U, 8 GB RAM, Intel HD 620, about 1 GB free. Local models bigger than ~1B will thrash. I recommended ShopCast: a small-shop sales forecaster. TabPFN via Prior Labs API does the numbers. Hosted Gemma explains them. Optional Ollama fallback for offline chat.

You

Implement ShopCast as specified. Do not edit the plan file.

Agent

Scaffolded the Streamlit app, TabPFN week-by-week forecast, residual anomaly check, 28-day backtest vs same-weekday-last-week, and a Gemma agent with forecast / anomalies / what-if tools.

▸ Write shopcast/forecast.py, agent.py, app.py, sample_data/lagos_bakery.csv

Input

shopcast/forecast.py, agent.py, app.py, sample_data/lagos_bakery.csv

Output

Pipeline ran offline in 8s. Keyword routing sent promo / strange-days / next-two-weeks / accuracy to the right tools.

You

I already have gemma4:e2b-it-qat locally. Can that serve instead of gemma3:1b?

Agent

Yes, ShopCast reads OLLAMA_MODEL. Gemma 4 E2B is 4.3 GB. Only 0.9 GB RAM was free, so loading it would swap hard. Hosted Gemma stays the default.

You

Ask ShopCast returned 404 NOT_FOUND for models/gemma-3-27b-it.

Agent

Listed models on the key. Only gemma-4-26b-a4b-it and gemma-4-31b-it accept generateContent. Switched the default. Live TabPFN + Gemma 4 test: MAE ₦4,671 vs naive ₦11,248 (58.5% lower). Flagged the 4 planted unusual days.

▸ list_gemma_models GOOGLE_API_KEY from .env

Input

GOOGLE_API_KEY from .env

Output

gemma-4-26b-a4b-it, gemma-4-31b-it

You

It starts processing the moment ShopCast launches. I need to upload a real shop CSV, then click Start before it runs.

Agent

Welcome screen now. File is checked locally first (days, date range, promo column, last 10 rows). Start forecast is disabled until there is data. Changing the file or horizon waits for another click.

Prize Categories

Best Use of TabPFN — TabPFN 3.5 is the forecast, the anomaly scores, and the promo what-if, inside a small prediction agent
Best Use of Gemma — Gemma 4 26B hosted (after Gemma 3 404'd); optional Gemma 3 1B locally
Best Use of Render — render.yaml web service. ** https://shopcast.onrender.com **
Best Use of Entire — agent session above

Touch Grass FC: A Local AI That Reads Your Football Group Chat and Builds Fair Teams

Jerrie Adah — Sun, 11 Oct 2026 15:31:12 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

I love football. Every so often, a group of us gets together to play a kickabout, and it's honestly the best part of my week.

Getting to the pitch is the easy part. Getting ready for the pitch is the problem.

Before every game, the group chat turns into chaos:

"I'm in"
"maybe, depends on my shift"
"count me in, bringing my cousin"
"sorry guys, out this week"
"update: I'm in after all!"
...and then, ten minutes before kickoff, someone asks, "so how many are we?"

Someone has to scroll through 40 messages, count heads, decide whether "maybe" means "yes", and then pick two fair teams. If you've ever organised a game, you know the second part is even harder. Put all the strong players on one side and the match is dead after ten minutes. Everyone knows who the good players are, but nobody wants to be the one who splits them up.

So I built Touch Grass FC: a small app that does the admin so you can get outside.

How it works:

You paste the group chat exactly as it is, messy and all.
An open-weight AI model running on your own laptop reads it and sorts everyone into in, out or maybe. It even picks up guests ("bringing my cousin Brian") as separate players.
You choose how many teams you want, from 2 to 6.
It builds balanced teams using the player ratings (1 to 5) that you give it.

The screen part takes about a minute. After that, the screen's job is done, and the rest of the evening is spent on the pitch.

Who is it for? Anyone who organises a pickup game: five-a-side with friends, a church or office team, a Sunday league. It's built for the organiser, who is the person always stuck doing the maths while everyone else is already warming up.

Pasted group chat and player ratings

The teams formed by touch grass fc with balanced sides!

I tested it with a 20-person group chat that I wrote with traps in it on purpose:

two guests ("bringing my brother Dennis", "Moses is coming with me")
people who change their mind (maybe to in, out to in, in to out)
random chatter ("who has the ball?", "don't forget the bibs")

When I ran the test chat for the first time, the model skipped the people who had said they were out, instead of listing them as "out".

Took it outside: Yes and I will be taking it outside more often because everyone loves it, it helps save a lot of time, reduces the screen time of the coach and makes us really touch grass!!.

Code

https://github.com/AdahJerrie/touch-grass-fc.git

The project is deliberately small, because I only had about four days:

touch-grass-fc/
├── app.py        # the web page (Streamlit)
├── rsvp.py       # the "secretary": asks the local AI to read the chat
├── teams.py      # the "coach": builds balanced teams
└── .streamlit/
    └── config.toml   # the green football theme

Requirements

Python 3.9 or newer
Ollama installed and running (this runs open-weight models on your computer)
About 4 GB of free RAM for the model

Install and run

# 1. Download the open-weight model (about 4 GB, one time, needs internet)
ollama pull gemma4:e2b-it-qat

# 2. Install the Python libraries
python -m pip install requests streamlit

# 3. Start the app
python -m streamlit run app.py

Your browser opens the app. After the one-time model download, everything works with no internet at all.

On Windows, I run it with python -m streamlit instead of just streamlit, because the plain command isn't always on the PATH.

How I Built It

The models and tools

Piece	What I used	Open?
The AI "brain"	Gemma 4 E2B (`gemma4:e2b-it-qat`), a small open-weight model	Open weights (Apache 2.0)
Running the model	Ollama, which serves the model on `localhost`	Open source
The logic	Python	Open source
The interface	Streamlit	Open source

My laptop has no GPU and 8 GB of RAM, so the model had to be small. Gemma 4's smallest version runs entirely on the CPU. The first request is slow (it took me about two minutes, because the model has to be loaded from disk into memory), but after that it stays loaded and answers much faster.

The idea: a secretary and a coach

I split the job in two, because AI is good at one half and plain code is better at the other.

The secretary (AI): reads messy human language and turns it into clean data.
The coach (plain Python): takes that clean data and makes fair decisions with simple, predictable maths.

I don't ask the AI to build the teams, because a small model can get maths and fairness wrong. Code does that part the same way every time.

Part 1: the secretary

Ollama runs a small server on my laptop, so my Python code just sends a message to localhost and gets an answer back. Nothing leaves the machine.

response = requests.post(
    "http://localhost:11434/api/chat",
    json={
        "model": "gemma4:e2b-it-qat",
        "messages": [{"role": "user", "content": prompt}],
        "format": "json",            # force a structured answer
        "stream": False,
        "keep_alive": "30m",         # keep the model loaded between requests
        "options": {"temperature": 0},  # consistent, not creative
    },
    timeout=300,
)
players = json.loads(response.json()["message"]["content"])["players"]

Two settings made a big difference:

"format": "json" forces the model to answer with structured data my code can read, instead of friendly paragraphs.
"temperature": 0 makes it behave consistently. I want it to read a chat, not be creative with it.

The prompt tells the model exactly what to return and sets a few rules:

status must be exactly one of: "in", "out", "maybe".
If someone brings a guest, add the guest as a separate player with status "in".
Include every person who posted, even those who are out.

That last rule exists because of a real mistake. In my first test, the model skipped the people who had said they were out, instead of listing them as "out". I fixed it by adding a rule to the prompt. FILL IN: confirm whether this fixed it for you. Small models follow most instructions, but not always all of them, so you have to test them properly.

Part 2: the coach

The team builder works like dealing cards. Players are sorted from strongest to weakest, and each one goes to whichever team is currently the weakest. A cap on team size stops one team from getting too many players.

def make_teams(names, ratings, num_teams=2, default=3):
    players = sorted(names, key=lambda n: ratings.get(n, default), reverse=True)

    teams = [[] for _ in range(num_teams)]
    scores = [0] * num_teams
    max_size = (len(players) + num_teams - 1) // num_teams

    for name in players:
        score = ratings.get(name, default)
        open_teams = [i for i in range(num_teams) if len(teams[i]) < max_size]
        weakest = min(open_teams, key=lambda i: scores[i])
        teams[weakest].append(name)
        scores[weakest] += score

    return teams, scores

Ratings are optional. If you don't enter any, everyone gets a default of 3 and the teams are simply split evenly by number. A guest nobody has rated also gets that default.

Part 3: making it usable by non-developers

My first version was a command-line script, which is useless to a friend who has never opened a terminal. So I added a web page with Streamlit: a box for the chat, a box for ratings, a slider for the number of teams, and a button. Each team gets its own coloured "kit" card, and the page has a green pitch-style banner instead of Streamlit's default look.

Challenges

Running on an 8 GB laptop with no GPU. I had to choose the smallest useful model and accept a slow first load.
Small models make mistakes. Changes of mind ("maybe" turned into "in") and skipped players needed careful prompt tuning.
Keeping the AI's job small. The more I let plain code do the work, the more reliable it became.

Limitations and what's next

I want to be honest about what this version can't do yet:

The organiser has to run it, and needs Ollama and the model installed. It's not a one-click install yet.
Ratings are typed in by hand each time.
Names in the ratings box must match the chat spelling exactly.
It handles one game at a time.

Next: upload a WhatsApp chat export directly, save ratings between sessions, and package it so a non-developer can install it with one click.

Why Does Open Innovation Matter?

A tool like this reads your friends' names and what they say in a private group chat. That's the kind of data I don't want to send to a company's server just to figure out who is playing on Saturday.

Open-weight models gave me things a closed API couldn't:

Privacy by default. The chat never leaves my laptop. Ollama also offers larger hosted -cloud versions of Gemma, and I deliberately avoided them, because they would send the chat to someone else's servers and defeat the point.
It works with no network. Data and Wi-Fi aren't guaranteed at the pitch or on the way there. After the one-time download, Touch Grass FC doesn't need either.
It costs nothing to run. No API key, no per-request bill, no usage limit. A weekend kickabout shouldn't need a subscription.
I control the behaviour. I can tune the prompt, set the temperature, keep the model loaded, or swap in a different model by changing one line, without asking permission or waiting for an API change.
I can see how it works. Because the whole stack is open, I could understand each piece, which also made this a real learning project for me.

The honest trade-off is that a small local model is less capable than a giant cloud one. But for reading a football group chat, small was enough, and the privacy and offline benefits made it the better fit.

Prize Categories

Best Use of Gemma: Gemma 4 (E2B) is the whole "brain" of the app. It runs locally through Ollama, reads the raw group chat, and turns it into structured data. Without it, the project doesn't work.

SafeBite AI: Allergy-Aware Meal Planner Agent Powered by Mastra & Gemini

Jerrie Adah — Mon, 05 Oct 2026 10:27:13 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

Check it out

SafeBite AI — Allergy-Aware Agentic Meal Planner

Live Demo: https://safebite-agent.onrender.com/
Hacktoberfest Submissions: Best Use of Mastra | Best Use of Render
Code: Github Repo https://github.com/AdahJerrie/safebite-agent.git

Inspiration

Planning daily meals while managing food allergies or strict dietary restrictions is a constant source of stress for my friend who is very selective because of allergies. Standard recipe generators often output unsafe suggestions or fail to spot hidden allergen risks (such as dairy derivatives in pre-packaged items or peanut cross-contamination).

I created SafeBite AI to solve this problem with true agentic reliability. Powered by Mastra AI and Google Gemini, SafeBite doesn't simply prompt a static LLM—it runs an autonomous agent that screens pantry ingredients through real-time tool checks before generating a verified recipe.

📸 Proof of Functionality & Screenshots

1. Interactive Dashboard & Restrictions Selector

Users select active dietary restrictions (e.g., Peanuts, Dairy) and specify available pantry ingredients along with a maximum prep time limit.

Check out the demo: https://safebite-agent.onrender.com/

2. Autonomous Agentic Output & Recipe Verification

The Mastra agent validates ingredients against all listed restrictions and generates a structured, step-by-step recipe ("Quick Garlic Chicken & Wilted Spinach Rice Bowl").

What It Does

Dynamic Restriction & Pantry Inputs: Allows users to toggle active allergens (Peanuts, Tree Nuts, Dairy, Eggs, Soy, Gluten, Shellfish, Fish) and input exact pantry items.
Autonomous Ingredient Screening: The safeBiteAgent leverages Mastra's tool-calling engine to execute allergenCheckerTool, inspecting every ingredient before finalizing the recipe.
Execution Telemetry: Displays live agent status badges and execution telemetry on the interface so users can confirm active safety validation.
Clear Markdown Recipes: Outputs comprehensive cooking instructions complete with prep time breakdowns, safe ingredient lists, and safety disclaimers.

How I Built It

Agent Framework: Mastra AI (@mastra/core) for agent instructions, tool binding, and runtime execution.
LLM Model Provider: Google Gemini (gemini-3.8-flash) via @ai-sdk/google.
Frontend & Design: Next.js 15 (App Router) with Tailwind CSS v4 dark mode and react-markdown.
Deployment Platform: Deployed directly as a Node.js web service on Render.

Challenges I Ran Into

Module Resolution & Build Errors: Configured PostCSS and Tailwind v4 to use .cjs extensions to handle Next.js ESM module constraints ("type": "module").
AI SDK Compatibility: Resolved version specification mismatches between @mastra/core and @ai-sdk/google to enable seamless tool calling with agent.generate().
Production Build Dependencies: Adjusted dependency configurations to ensure Render's automated build pipeline cleanly installs @tailwindcss/postcss.

Accomplishments

True Tool-Driven Workflow: Built an AI agent that actively invokes validation tools instead of relying solely on raw text generation.
Seamless Render Deployment: Successfully hosted the application at safebite-agent.onrender.com with automated builds and fast response times.

Prize Category Submissions

Best Use of Mastra: Architected using Mastra's core Agent framework, custom tool orchestration (allergenCheckerTool), and execution telemetry.
Best Use of Render: Deployed and actively running in production as a Render Web Service.