DEV Community: Vytas

Hue Hunt: a daily colour hunt for friends, judged by Gemma

Vytas — Sun, 11 Oct 2026 06:18:15 +0000

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

What I Built

I built Hue Hunt, a daily colour hunt for a group of friends.

Every morning the group gets a colour and a bonus twist, for example "Yellow. Bonus: something that moves." During the day everyone goes out and photographs what they find. A yellow car, a bin lid, a sunflower. Nobody sees anyone else's photos until the evening reveal, when all of them appear side by side with points, a winner and a short, playful recap. A season runs for a week, with a leaderboard at the end.

The judge is an AI model. It looks at each photo and answers a few questions: is the thing in the photo really yellow, does it move, what is it, and is it a photo of a screen or a poster rather than a real thing. It also writes a one-line comment on every photo, which turned out to be the part people react to most. "That tiny yellow logo is a bit lost in all that gorgeous red!" is a fair verdict on a red Ferrari submitted on a yellow day.

The screen is the shortest part of the game. You read the colour in the morning, which takes five seconds. Taking a photo takes another five. Then you look at the reveal in the evening. Everything in between happens outside, and the game is a reason to look at things you walk past every day.

It's for a group of friends, the kind who already have a chat group. There are no accounts. You share a link, people type a name, and their phone remembers them. The person who creates the group is the host and can set the reveal time, press "reveal now", or start a new season.

Demo

Hue Hunt runs on a small private server for my friends and me, so there's no public link yet. Running it yourself takes five minutes, and the steps are in the next section.

Here is a demo season, screenshotted from the real app. I seeded it with a folder of photos and let the real judge score them, so every point and comment below is Gemma's.

Day 3: orange, "something with a face". The cat has been judged: 15 points, bonus earned, and a comment.

The reveal for the yellow day. Maja wins with a taxi, a raincoat and a sunflower. Every photo has its points and the judge's comment. Tom's sunlit grass got 0: "That golden sunlight is beautiful, but we're hunting for actual yellow objects!"

The season leaderboard after two days.

The invite page. No account, no password. The small print says photos go to a third-party API and that location data is stripped.

The share links carry preview cards, so a reveal unfurls in WhatsApp or iMessage as a collage of the day's best photos.

Code

vytasgavelis / hue-hunt

Hue Hunt

A daily colour hunt for a group of friends, judged by an open-weight vision model.

Every morning the group gets a colour and a bonus twist, for example "Yellow. Bonus: something alive." During the day everyone photographs what they find outside, straight from the phone's camera in the browser. Nobody sees anyone else's photos until the evening reveal, when all the photos appear side by side with scores, a winner and a short, playful recap. Seasons run a week with a leaderboard at the end.

Built for the DEV Hacktoberfest 2026 "Touch Grass" challenge. The screen is the shortest part of the game: a few seconds to take a photo, one look at the reveal in the evening.

How it works

Groups, no accounts. Create a group, share the join link. Players pick a display name and the phone remembers them with a random token in a cookie…

View on GitHub

The README has the full setup. In short, you need Node.js 24 and pnpm, and then:

git clone https://github.com/vytasgavelis/hue-hunt.git
cd hue-hunt
cp .env.example .env     # add a free Gemini API key from Google AI Studio
pnpm i
pnpm db:migrate
pnpm dev

Then open http://localhost:5201. If you want to look at a few files, these are the interesting ones:

apps/server/src/ai/tasks.ts has the four prompts: judge a photo, invent the day's challenge, write the evening recap, write the season recap.
apps/server/src/ai/client.ts is the model client. It asks for JSON, validates it, retries once, and logs every call.
packages/shared/src/scoring.ts turns the judge's answers into points. No AI in this file.
apps/server/src/scripts/eval-judge.ts is the judging eval, which is how I chose the model and tuned the prompt.
apps/server/src/lib/images.ts strips the metadata from every photo before it is stored.

How I Built It

Hue Hunt is a TypeScript app: a React web app, a Hono API, a SQLite database and a small job queue, all in one Node process on a $6 server. The AI side is one open-weight model, Gemma 4 26B-A4B from Google, called through the Vercel AI SDK. I call it on the Gemini API's free tier, so running Hue Hunt needs no GPU and no paid account, but the model is a published set of weights and nothing in the code depends on where it runs.

One model, four jobs

Gemma does four things, and they're all single prompt-and-reply calls. No agents, no tools, no streaming.

Judging a photo is the only task that sees images. The prompt gives the colour and the twist, and asks for exactly this:

{
  "colour_match": 0.0,          // number 0 to 1 on the scale above: how clearly the thing photographed is "yellow"
  "bonus_match": false,         // true only if the yellow thing in the photo itself satisfies the bonus twist "something that moves"
  "subject": "...",             // short noun phrase naming the main subject, e.g. "yellow taxi"
  "category": "...",            // one of: vehicle, plant, animal, building, sign, clothing, food, object, other
  "is_screen_or_print": false,  // true if this is a photo of a screen, a poster, a printed image or a drawing rather than a real thing
  "comment": "..."              // one playful line about the photo, at most 15 words, friendly never mean
}

This is the part a pixel histogram can't do. "Yellow and alive" is a question about what the thing is, not what colour the pixels are. So is "it's just a tiny sign in the corner of a grey street", and so is "that's a photo of a laptop screen".

Inventing the challenge runs at 7 am in the group's timezone. The model gets the colours and twists already used this season and returns a new colour, a twist and a tagline. It likes "terracotta" and "cobalt blue" more than I expected.

The recaps never see the photos. The evening recap gets the judge's notes for each player, the subject, points and comment of every photo, and writes three to five sentences naming the winner and the funniest find. The season recap does the same across the week.

Scoring is code, not the model

The model answers questions about a photo. Points are worked out by plain code that I can test:

export function photoPoints(j: Judged): number {
  if (j.is_screen_or_print) return SCORING.screenOrPrintPoints;
  const bonus = j.bonus_match && j.colour_match >= SCORING.bonusMinColourMatch;
  return Math.round(j.colour_match * SCORING.colourPoints) + (bonus ? SCORING.bonusPoints : 0);
}

Colour match times 10, plus 5 for the twist, 0 for screens. Your best three photos count for the day, and a second photo in the same category counts half, so three photos of three yellow cars don't beat one car, one flower and one bin. The season adds 3 points for each daily win.

The bonus only counts when the colour match is at least 0.5. That rule came from the eval. On a yellow day with "something alive", the model correctly called a green forest "alive", and without the rule it would have scored 5 points for a photo with no yellow in it.

Getting JSON out of Gemma

Gemma's native JSON schema mode let stray tokens into values in my last project, so this time I never turned it on. The prompt shows a filled-in template of the reply, with a comment on each field, and the server validates the reply with a Zod schema that the web app shares. The schema is forgiving where it can be: a colour match of "0.8" as a string is coerced to a number and clamped to 0 to 1, a category the model made up becomes "other". If the reply still doesn't validate, the call is retried once with a reminder. Of the 57 model calls logged while I built and tested it, none needed the retry.

Setting Gemma's thinking to "minimal" matters a lot here. Judging a photo takes 3 to 5 seconds. The recaps are slower, around 30 seconds, because they are longer and I let the model be more creative.

Choosing the model with an eval

I didn't want to guess, so I wrote pnpm eval:judge. It runs the judge over a folder of photos for a given colour and twist and prints a table. The photos are named for what I expect, so the table reads like a test report.

I ran it on nine photos for "yellow, something alive": a taxi, a raincoat, a sunflower, bananas, a duckling, a green forest, a red Ferrari, a photo of a smartphone screen, and a yellow mosaic on a wall.

	Gemma 4 26B-A4B	Gemma 4 31B
Photos judged	9 / 9	5 / 9 (4 timeouts at 60 s)
Judgements I agreed with	9	5
Median time per photo	3.8 s	40.8 s

Both models judged the photos the way I would have. The 31B is dense, the 26B is a mixture-of-experts model with about 4 billion active parameters, and it's ten times faster. That's the difference between a comment appearing while you're still looking at your photo and a comment appearing after you've put the phone away, so the 26B is the default.

Tuning the prompt on real photos

The first prompt was two sentences. Then I ran it on a second set of photos, the kind of thing you'd actually find on a walk, and the results were uneven:

Photo	First prompt	Final prompt
Orange cat, "something alive"	0.70 + bonus = 12 pts	0.30 = 3 pts
Orange traffic cone	0.10	0.30
Yellow lid on a green bin	0.40	0.80
Sunlight on grass	0.40 + bonus	0.00
Field of sunflowers	1.00 + bonus	1.00 + bonus

An orange cat scoring 12 points on a yellow day was the problem. The model knew it was orange, its comment said so, but it gave 0.7 anyway. The cone, which is just as orange, got 0.1. And the bin lid, which is unmistakably yellow and the obvious point of the photo, got 0.4 because the bin around it is green.

The fix was to tell the judge what I actually meant. The final prompt judges the hue strictly and the size leniently: any shade of the colour counts fully, a neighbouring hue caps at 0.3, a coloured part of a bigger object counts if it's clearly the point of the photo, and light cast by the sun doesn't count. It also gives an anchored scale, 1.0, 0.8, 0.5, 0.3, 0, with a sentence for each.

One lesson from the iteration. My first version of that rule said "orange, gold or ginger is not yellow". Gemma took "gold" literally and dropped a golden-orange sunflower from 1.0 to 0.3. The rule became "lemon, mustard and golden yellow are all yellow" instead, and the sunflower came back. With a model this fast, the loop of change the prompt, run the eval, read the table takes a minute.

Photos and privacy

Photos are sent to a third-party API for judging. The join page says so. Before a photo is stored, the server decodes it, rotates it the right way up, resizes it to 1280 px and writes a fresh JPEG. All metadata is gone, including the GPS location phones embed in every shot. There's a test that uploads a photo with GPS coordinates and asserts they are not in the file on disk. Photos are only visible to the group, and other people's photos are hidden until the reveal.

How I worked

I wrote a spec first, then built it with Claude Code as my coding assistant over two days. The spec was the useful part. It settled the scoring rules, the data model and the job queue before any code existed, and it meant the first version came out working end to end, with 40 tests. I then spent my time on the eval and the prompt, which is where the quality of the game actually lives.

Why Does Open Innovation Matter?

The judge can be argued with. A game with an AI referee only works if people trust the referee. Everything the judge is told is in one file, the prompt is plain text, and anyone can read it, run the eval on their own photos, and see the table. When my friends disagree with a score, I can show them the rule, and if they are right I change it. A closed, hosted judging feature would be a black box with a score coming out of it.

The model I tested is the model I ship. Gemma 4 26B-A4B is a set of published weights. The eval results above stay true, because the model can't be silently updated or retired under me. With a closed API, the provider can swap the model next month and the orange cat might be worth 12 points again.

It can run anywhere, including at home. Today the calls go to Google's free tier because it was the easiest. The provider is one environment variable, and the code has a second provider for any OpenAI-compatible server. A group that doesn't want its photos leaving the house can run the same model on a machine at home with Ollama or vLLM and get the same judge. That's a real option for a game where people photograph their street, their garden and their kids' bikes.

Cost makes the game possible at all. A group of five taking five photos a day is 25 model calls a day, plus a challenge and a recap. A small open model on a free tier makes that free. A frontier vision model at API prices would make a daily game for friends an expense nobody would pay.

The frameworks are open too. The Vercel AI SDK is a library inside my app. When I wanted the image passed one way rather than another, or the thinking level set, I read the source instead of waiting for a feature.

Prize Categories

Gemma. Hue Hunt runs on Gemma 4 26B-A4B for every model call: judging photos, inventing the daily challenge and writing the recaps. It was chosen over Gemma 4 31B by the eval above.

What's Next

Hue Hunt is a first version, and it has gaps I know about:

It isn't public yet. Anyone who can reach the server can create a group and upload photos, so before I open it up it needs limits on groups and uploads, and a job that deletes photos when a season ends.
iPhones save photos as HEIC, and the server can't decode those yet. Safari hands the page a JPEG when you use the camera button, but a HEIC picked from the photo library is refused with a message.
The recap takes 30 seconds. That's fine for an evening reveal, and too slow for anything else.

What I want to build next:

Reactions on the reveal, so the group can disagree with the judge.
A "judge's appeal": tap a score, write one line, and the model re-judges with your argument in the prompt.
Running the eval on a few hundred real photos from a season, with the group's own verdicts as labels. With open weights, that's the dataset for a fine-tune.
A self-hosted mode in the README with Ollama, for groups who want their photos to stay home.

Enzyme: breaking research papers into facts you can check

Vytas — Sun, 04 Oct 2026 21:13:08 +0000

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

What I Built

I built Enzyme for a friend. They're a scientist who wants to create healthy-lifestyle content based on real, published evidence.

That means reading a lot of papers. New studies come out every week on the topics they follow, like gut health, omega-3 and inflammation, or vitamin D and autoimmune thyroid disease. Most aren't worth their time. Some are only loosely related to the search, some were done in mice, and some are too small to tell you much. The ones that do matter are dense abstracts that take a while to read properly. Sorting through all of this by hand is slow, and it's easy to fall behind or miss a good paper.

The name comes from what enzymes do: they break big molecules down into pieces the body can use. Enzyme does the same with research papers.

My friend saves the topics they care about. They can describe a topic in plain English and Enzyme writes the search query for them. Enzyme then pulls in matching papers from Europe PMC, which also covers PubMed and preprints, and marks the ones that are new since their last visit.

To cut the noise, they can filter by the information that comes with each paper. For example, they can show only meta-analyses and randomised trials, show only studies in humans, or hide preprints. Retracted papers are hidden by default.

For any paper, Enzyme can write a short plain-language summary and a one-line takeaway, and pull out the key facts: who was studied, how many people, what dose, for how long, what was measured and what happened. Each fact comes with the exact sentence from the abstract it was taken from, and hovering over a fact highlights that sentence. If the abstract doesn't mention something, like the dose or who funded the study, Enzyme says "Not stated" instead of guessing.

That last part matters most for what my friend wants to do. If you tell people something about their health, you should be able to show where it came from. With Enzyme, checking a fact means hovering over it instead of rereading the whole abstract.

Tools like Elicit and Consensus already exist, and they're good. But they're built for everyone. Enzyme is built around my friend's topics, and it's the first step toward turning the papers they read into the content they make.

When I showed it to them, their verdict was that scientists can now research and summarise papers fast, and at scale.

Demo

Enzyme is a tool for one person, so for now it runs on my laptop and there's no public link. Here's a walkthrough using my friend's real searches:

In the video:

I describe a topic in plain English and Enzyme writes the search query. For "gut health" it narrowed the results from about 121,000 papers to under 1,000.
I pull the newest papers for a search.
I filter the feed down to randomised trials and meta-analyses in humans.
I summarise a paper and hover over its key facts to show the sentence each one came from.

I sped up the waits in the video. A summary takes about 15 seconds.

The feed for one of my friend's searches, filtered to randomised trials and meta-analyses in humans. Summarised papers show their key numbers and a one-line takeaway right in the list.

An expanded paper. Hovering over "Dose / regimen" highlights the sentence it came from in the abstract: "1320 mg/day curcumin".

Writing a search in plain English. Enzyme suggests a query and shows how many papers it finds before you save it.

If you want to run it yourself, the setup steps are in the README, linked in the next section.

Code

vytasgavelis / enzyme

Enzyme

An enzyme breaks big molecules down into pieces the body can use. Enzyme the app does the same for research papers: it gathers the new studies on the topics you follow and breaks each one down into a short, checkable set of key facts.

Built in one weekend for the DEV Hacktoberfest 2026 Weekend Challenge, "Build for a Friend".

Who it's for

My friend has a master's in biochemistry, works in the field, and wants to create healthy-lifestyle content based on real, published evidence. Their problem is keeping up: every week brings new papers on the topics they care about, many of them off-topic, animal studies or weak designs, and each one a dense abstract to read before you know if it matters.

General tools for this already exist. Enzyme is built for them: their topics (anti-inflammatory diet autoimmune disease, gut health), their filters (human studies, RCTs and meta-analyses…

View on GitHub

The README has the full setup. In short, you need Node.js 24 and pnpm, and then:

git clone https://github.com/vytasgavelis/enzyme.git
cd enzyme
cp .env.example .env
pnpm i
pnpm db:migrate
pnpm seed
pnpm dev

Then open http://localhost:5173. The seed adds my friend's six saved searches. Searches, pulls and filters work without an API key. The AI features need a free key from Google AI Studio, which serves Gemma.

If you only want to look at a few files, these are the interesting ones:

packages/shared/src/card.ts checks every quote the model returns against the abstract.
apps/server/src/ai/card-agent.ts is the agent that writes the key facts. Its comments explain the Gemma quirks I had to work around.
apps/server/src/ai/query-agent.ts is the agent that turns plain English into a search query and checks the hit count with a tool.
packages/shared/src/evidence.ts works out study type, species and retractions from the paper's metadata, without AI.

How I Built It

Enzyme is a TypeScript app: a React web app, a Hono API and a SQLite database. The AI side uses two open pieces. Gemma 4 26B-A4B is an open-weight model from Google. Mastra is an open-source TypeScript framework for building agents. I call Gemma through the Gemini API's free tier, so running Enzyme needs no GPU and no paid account.

Metadata first, AI second

I decided early that the model shouldn't do anything the data can already do. Papers from Europe PMC come with publication types and MeSH terms, the subject tags that PubMed indexers add. Study type, humans or animals, and retractions are all worked out from those fields, so the filters are exact, instant and free. The model only does two jobs that metadata can't: reading an abstract, and turning a plain-English topic into a search query.

Key facts you can check

The study card comes from a Mastra agent. It gets a paper's title and abstract and returns 12 facts, a one-line takeaway and a short summary. For every fact, it has to copy the exact words from the abstract that state it. The reply is validated against a Zod schema that the server and the web app share.

Then the server checks every quote against the abstract. If a quote isn't there, the fact is flagged with "check" in the UI. If the model says the abstract doesn't state something, the fact shows as "Not stated". Whether a fact is backed up is decided by plain code, not by the model.

Getting clean output from Gemma took some work. Its native JSON schema mode let stray tokens into the values (one dose came back as "2.emannine 2.5 g"). When I gave it Mastra's generated schema description, it copied the description's structure instead of filling it in. Mastra's structured output can also work through the prompt, with your own format instructions, so I gave Gemma a filled-in template of the reply and kept the Zod validation. Setting Gemma's thinking to "minimal" brought a card down from over a minute to about 15 seconds.

An agent that tests its own search queries

Europe PMC's query syntax is powerful, but my friend shouldn't have to learn it. A second Mastra agent turns a plain-English description into a query. It has one tool, count_hits, which counts the papers the query finds and says whether that's too many, too few or about right (50 to 5,000). The agent revises the query and checks again, up to three times. For "gut health", it went from about 121,000 papers to 975.

The tool doesn't hold any logic of its own. Each request passes its own checker to the tool through Mastra's request context. That checker counts the hits, limits how many checks the agent gets and records every query it tried. If the agent's final answer is worse than a query it checked earlier, the app uses the earlier one. So the agent chooses what to try, but my code counts the hits and picks the final answer.

Choosing the model with a benchmark

I didn't want to guess which model was best, so I wrote a benchmark with Mastra's scorers. It runs each model on the same 12 papers and scores the cards in three ways:

How many quotes are really in the abstract.
How often the model says "unknown" for the fields abstracts usually leave out, like dose and funding, instead of guessing.
How many claims in the summary are backed by the extracted facts. A second model judges this, and each model judged the other's cards, so neither marked its own work.

Each score is a Mastra scorer. The simplest one, the quote check, looks like this:

export const quoteCheckScorer = createScorer<ScoredPaper, ScoredCard>({
  id: "quote-check-rate",
  description: "Share of the values the model gave whose quote is found in the title or abstract",
})
  .preprocess(({ run }) => quoteCheck(run.output.card))
  .generateScore(({ results }) => results.preprocessStepResult.rate ?? notScorable("no values"))
  .generateReason(
    ({ results: { preprocessStepResult: q } }) =>
      `${q.stated} of ${q.given} values verified, ${q.suspect} suspect, ${q.unknown} unknown`,
  );

The faithfulness scorer has the same shape, but its analyze step calls the judge model. Here are the results:

	Gemma 4 26B-A4B	Gemma 4 31B
Cards produced	11 / 12	10 / 12 (2 timeouts)
Quotes found word for word in the abstract	99%	99%
Said "unknown" instead of guessing	98%	100%
Summary claims supported by the facts	84%	69%
Median time per card	14.2 s	49.4 s

Both models extract facts equally well. The summary scores are a softer signal, since the judges are different models and most flagged claims were true but went beyond the extracted facts. The smaller model, a mixture-of-experts model with about 4 billion active parameters, is 3.5 times faster and never timed out, so it's the default. Switching models means changing one environment variable, because Mastra's model router takes a plain provider/model string.

Tracing

Every agent run is traced with Mastra's observability: each model call with its tokens and timing, and each count_hits call with its query and result. The traces go into a local SQLite file, and pnpm traces prints them. Here is the query agent narrowing "supplements that reduce inflammation" in three checks (I shortened the queries):

$ pnpm traces --agent query-writer

agent run: 'query-writer'  15518 ms
  input:  "supplements that reduce inflammation"
  model llm: 'gemma-4-26b-a4b-it'  in=3127 out=379
  tool tool: 'count_hits'  1427 ms
    in:  (supplement* OR vitamin* OR mineral* OR herb* ...) AND (inflammation OR inflammatory)
    out: {"hitCount":40748,"verdict":"Too many (aim for 50–5000). Narrow it."}
  tool tool: 'count_hits'  428 ms
    in:  ... AND (PUB_TYPE:"Review" OR PUB_TYPE:"Systematic Review" OR PUB_TYPE:"Meta-Analysis" OR PUB_TYPE:"Randomized Controlled Trial")
    out: {"hitCount":10912,"verdict":"Too many (aim for 50–5000). Narrow it."}
  tool tool: 'count_hits'  378 ms
    in:  ... AND (PUB_TYPE:"Systematic Review" OR PUB_TYPE:"Meta-Analysis")
    out: {"hitCount":911,"verdict":"Good: in the useful range."}

Traces also show when the problem isn't the model. When one suggestion failed, its trace showed every count_hits call getting a 503 from Europe PMC, and the agent being told it had no checks left.

Study card runs are simpler: one model call each, with the facts and their quotes in the output (shortened here too):

$ pnpm traces --limit 3 --agent study-card

agent run: 'study-card'  16824 ms
  input:  "Title: Effect of 21-Day Omega-3 Polyunsaturated Fatty Acid Supplementation on Exercise-Induced Secretory Factors ..."
  output: {"design":{"quote":"randomized double-blind study","value":"randomized double-blind study","status":"stated"},
           "population":{"quote":"24 physically active men","value":"24 physically active men","status":"stated"}, ...}
  model llm: 'gemma-4-26b-a4b-it'  16822 ms  in=1268 out=749

agent run: 'study-card'  16906 ms
  input:  "Title: Role of the EPA: DHA dosing ratio in omega-3 supplements on blood fatty acid profiles and inflammation ..."
  output: {"design":{"quote":"systematic review and meta-analysis","value":"systematic review and meta-analysis","status":"stated"},
           "population":{"quote":"across 96 clinical trials","value":"96 clinical trials","status":"stated"}, ...}
  model llm: 'gemma-4-26b-a4b-it'  16903 ms  in=1319 out=730

agent run: 'study-card'  16034 ms
  input:  "Title: Omega-3 Fatty Acids Supplementation Improves Pulmonary Function and Clinical Outcomes in Critically Ill Patients ..."
  output: {"design":{"quote":"meta-analysis","value":"meta-analysis","status":"stated"},
           "sampleSize":{"quote":"29 studies involving 2551 critically ill patients", ...}, ...}
  model llm: 'gemma-4-26b-a4b-it'  16031 ms  in=1412 out=704

How I worked

I built Enzyme over the weekend with Claude Code as my coding assistant. I built the UI first against mock data, to settle how it should work before writing the API.

Why Does Open Innovation Matter?

My friend works in science, where a result counts when someone else can check it. A tool that helps them read research should follow the same rule, and open models and tools make that possible.

The model I tested is the model I ship. Gemma 4 26B-A4B is a set of published weights. The version I benchmarked is a fixed file that anyone can download and inspect, and it will still exist next year. With a closed model behind an API, the provider can update or retire it at any time, and you have no way to see what changed. For a tool whose job is getting facts right, I want my benchmark results to stay true. One honest caveat: different providers can serve the same open model in different ways, for example at lower precision. Real consistency means pinning the provider too, but with open weights that choice is mine.

No lock-in. Today the model calls go to Google's Gemini API, because the free tier made it easy. Nothing ties Enzyme to it. Any host that serves Gemma will do, and so will my friend's own hardware if they ever want their reading to stay private. Because Mastra's model router takes a plain provider/model string, moving is a one-line change in .env.

It can learn from them. The next step is letting my friend correct and verify the key facts. Every corrected card is an example of exactly the output they want. With open weights, those examples can be used to fine-tune the model for their topics. A closed model offers that only if its provider decides to.

Cost. Keeping up with research means hundreds of papers a week. A small open model that writes a card in 15 seconds on a free tier makes that affordable for one person.

The framework is open too. Mastra runs inside my app, so the traces and benchmark scores stay on my machine as local files. When Gemma struggled with structured output, I could change how Mastra asked for JSON instead of waiting for a fix from someone else.

Prize Categories

Mastra. Mastra is the AI layer of Enzyme, and I used more of it than plain model calls:

Agents: one writes the study card, one writes search queries.
Tools: the query agent checks its own queries with count_hits, and the request context gives the tool the current request's checker.
Structured output: the reply is validated with Zod, using prompt-based JSON with my own format instructions to work around Gemma's quirks.
Scorers: the model benchmark is built from them, including an LLM judge where each model judges the other.
Observability: every agent run is traced to a local file.
The model router: switching models is one environment variable.

Gemma. Enzyme runs on Gemma 4 26B-A4B, chosen over Gemma 4 31B by a benchmark on my friend's own topics.

What's Next

Enzyme is a first version, and it has gaps I know about:

It only reads abstracts, so details that appear only in the full paper show as "Not stated".
About 1 card in 12 fails validation and has to be generated again.
Recent papers often don't have MeSH terms yet, so the "Humans only" filter hides them.

What I want to build next, roughly in order:

Corrections and verification. My friend can edit any fact and mark a card as checked.
Drafting posts from verified cards, the step toward their content plans.
A weekly digest of new papers on their topics.
Full text for open-access papers.
Fine-tuning Gemma on their verified cards.
A private deployment on a small server behind Tailscale, so they can use it without my laptop.