DEV Community: Kumuda ⚔️

Marigold /router - A Private Ofrenda for the Memories We Refuse to Lose

Kumuda ⚔️ — Fri, 30 Oct 2026 14:01:01 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

Some memories are not dramatic enough to become history.

They are a cup warmed before tea is poured.

A song playing from an old radio at dusk.

A yellow sari in a garden.

The exact way someone said, “Stay a little longer.”

These details are easy to lose because they are ordinary. But ordinary details are often where a person continues to exist in our lives.

So I built Marigold /router: an offline-first oral-history studio and virtual ofrenda for collecting family memories, photographs, recipes, and voice notes.

It is a place to keep what matters without turning a loved one into a chatbot.

The central idea is simple:

Marigold remembers what you give it. It refuses to invent what you did not.

The project was inspired by the challenge theme, Ghost in the Machine, and by the tension between memory and artificial intelligence.

A machine can search a memory.

It can help organise a memory.

It can transcribe a voice recording.

But it should not pretend to become the person in the recording.

That boundary is the heart of Marigold.

Demo

💻 Source code: https://github.com/kumudasrip/marigold-router

🎬 Demo: https://youtu.be/t74MdHNO8nM?si=TRmUi6bRflMOHTtK
Marigold currently runs locally because privacy is part of the product, not just a deployment limitation.

Run the browser app

git clone https://github.com/kumudasrip/marigold-router.git
cd marigold-router
py -m http.server 4173

Open:

http://localhost:4173

The archive works without an account, database, or cloud service.

For the full AI experience, install Ollama and pull the local Gemma model:

ollama pull gemma4:e4b

The optional Faster-Whisper service enables real audio-to-text transcription.

What Marigold Can Do

1. Build a private memory archive

You can add:

Written stories
Photographs
Voice notes
Years and dates
Sources and family context
Thematic tags

Memories are stored in the browser's local storage. There is no account system and no required cloud database.

The archive includes search, filters, a timeline, and a memory detail drawer so that small fragments can be revisited later.

2. Create an ofrenda-like memory space

I wanted the interface to feel like a place of keeping rather than another dashboard.

The design uses:

Marigold orange
Candle yellow
Terracotta
Deep altar red
Parchment-inspired surfaces
A hand-crafted Marigold /router logo
Decorative details inspired by papel picado and altar arrangements

The visual language is intentionally warm. The archive should feel calm enough to stay with a memory for a while.

3. Ask the Ofrenda Guide

The Guide lets you ask questions about the archive.

For example:

What did they love to cook?

If the archive contains a relevant memory, the Guide retrieves it and points to the source.

If the archive does not contain the answer, it says:

“That memory is not in the archive yet. I won't fill the silence with a guess.”

This is the most important behaviour in the application.

A convincing answer is not always a responsible answer.

4. Transcribe voice notes locally

A voice note can contain details that someone might never sit down to type.

Marigold optionally uses Faster-Whisper through a small local FastAPI service:

Audio file
    ↓
Local Faster-Whisper service
    ↓
Transcript
    ↓
Memory saved in the browser archive

The audio is sent to 127.0.0.1, not to a hosted transcription provider.

The transcript is attached to the saved memory, while the original audio remains available locally in the browser archive.

5. Export the archive

The archive can be exported as a standalone HTML file.

The exported memorial includes:

Memory titles
Written details
Dates
Sources
Tags
Uploaded photographs

The goal is to make the archive portable without requiring a Marigold server.

How I Built It

Marigold is intentionally built with a small, understandable stack:

HTML for the application structure
CSS for the responsive ofrenda-inspired design
Vanilla JavaScript for archive interactions and local state
Browser localStorage for private memory persistence
Ollama for local model inference
Gemma 4 e4b for curation and grounded Guide responses
Faster-Whisper for local multilingual transcription
FastAPI for the optional local transcription service
Uvicorn for running the Whisper service

There is no required npm build step and no Marigold backend.

The main app communicates with Ollama directly:

Marigold browser app
        │
        ├── localStorage
        │
        ├── Ollama
        │     └── Gemma 4 e4b
        │
        └── FastAPI localhost service
              └── Faster-Whisper

Where the AI Actually Earns Its Place

I did not want to add AI just because the challenge had “AI” in the title.

The local model has real, limited responsibilities.

1. Curating themes

The Curator reads archive context and suggests thematic threads such as:

Kitchen
Garden
Music
Ritual
Belonging

These are suggestions, not facts about a person.

2. Grounded retrieval

The Ofrenda Guide receives the archive context and the user's question.

It is instructed to:

Answer only from the archive
Never impersonate the deceased
Never invent missing details
Return source references
Refuse unsupported questions

The frontend also keeps a deterministic fallback retrieval mode so the app remains useful when Ollama is offline.

3. Transcript cleanup

When a transcript is pasted into the AI Studio, Gemma can help clean punctuation and paragraph breaks while preserving the original meaning.

4. Audio transcription

Faster-Whisper handles actual voice-to-text conversion locally.

This is especially useful because oral history is often easier to speak than to type.

Why Gemma and Local Inference?

A cloud model would have made the first demo simpler.

But a memory archive is exactly the kind of application where sending everything to a remote API should not be the default.

Using Ollama and Gemma makes the project:

More private
Usable without an AI subscription
More transparent
Easier to run offline
Easier to inspect and modify
Independent of changing hosted API limits

The model can be replaced locally without changing the product architecture.

The user controls where inference happens.

That is important when the data includes family stories, grief, cultural history, or private recordings.

Why Does Open Innovation Matter?

Open innovation matters here because the project depends on trust.

A closed API might give a polished answer, but it would make it harder to understand:

Where the answer came from
What data left the device
Which model produced the response
What happens when the model is wrong
Whether the service will remain available

With local, open tools, the system is more inspectable.

Someone can see that:

Memories are stored in browser storage
Ollama is called through a local endpoint
Faster-Whisper runs on localhost
The Guide prompt explicitly prohibits impersonation
Unsupported answers fall back to a refusal
The export is generated locally

Open innovation made it possible to build a project where privacy is not a marketing sentence. It is part of the implementation.

It also made experimentation accessible. I could combine a static frontend, Ollama, Gemma, Faster-Whisper, and FastAPI without needing a paid infrastructure stack or a large production backend.

What I Learned While Building It

Local AI is not automatically responsible AI

Running a model locally improves privacy, but it does not automatically make the output trustworthy.

The important work was defining what the model should refuse to do.

The Guide is not allowed to recreate a person or confidently fill in missing history. The refusal behaviour is as important as the successful answer.

Small models need clear boundaries

A local model performs better when the prompt is narrow and the expected output is explicit.

For curation, Marigold asks for structured JSON.

For the Guide, it provides numbered archive entries and expects citation indexes.

For transcript cleanup, it asks the model to preserve every word and meaning.

The more specific the task, the more useful the local model becomes.

Fallbacks matter

Ollama may not be running.

Whisper may not be installed.

A model may take too long to respond.

The archive should still open, search, save memories, and provide honest fallback behaviour.

AI is an enhancement to the archive, not the foundation that everything else depends on.

The UI is part of the emotional design

A memory archive cannot feel like an admin panel.

The visual design needed to communicate care before the user ever clicked an AI button.

The warm palette, altar-inspired layout, candle details, and marigold branding are all part of making the project feel like a place people want to return to.

Responsible AI Decisions

Marigold follows a few simple rules:

Do not impersonate the deceased.
Do not fabricate memories.
Do not present guesses as family history.
Show where retrieved information came from.
Say when information is missing.
Keep the data local by default.
Use synthetic or consented data for demonstrations.
Treat browser storage as convenient local persistence, not encryption.

The project is not trying to make a ghost.

It is trying to make the silence around a missing memory honest.

The Spirit of It

The moment that stayed with me was not the model producing a clever answer.

It was the refusal.

I asked the Guide something that was not actually present in the archive, and instead of inventing a warm-sounding response, it said that the memory was not there yet.

That felt more meaningful than a perfect answer.

Because grief already contains enough imagined conversations.

A tool for remembering should not pretend that it can bring someone back.

It should help us hold on to what was actually said, photographed, recorded, cooked, sung, and lived.

That is what Marigold /router is for:

A record of love, not a reconstruction.

Prize Categories

Best Use of Gemma

Code

https://github.com/kumudasrip/marigold-router

The repository includes setup instructions for:

The static browser app
Ollama and Gemma 4 e4b
Faster-Whisper
The local FastAPI transcription service
Privacy and troubleshooting notes

I Built a Pixel Hero That Nags Me to Drink Water (and Runs 100% on My Laptop)

Kumuda ⚔️ — Fri, 23 Oct 2026 13:30:44 +0000

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

What I Built

Be honest: when did you last drink water while working?

I can sit at my laptop for four hours straight, and the only thing that moves is my cursor. My eyes burn, my back hurts, and the water bottle next to me is exactly as full as it was in the morning.

I've tried reminder apps. They all fail the same way: they say the same boring sentence every time, and within a day my brain learns to skip it. A notification I've read 50 times is not a notification anymore, it's wallpaper.

So I built Break Buddy 🦸

Break Buddy is a Windows app that runs quietly in the background. When it's time for a break, a pixel-art hero pops up in the corner of my screen, points at an RPG-style dialogue box, and types out a message that is different every single time, in whatever personality I picked. Here's one it wrote for me:

"Are your eyelids auditioning for an endurance sport?"

I didn't write that. I never will see the same reminder twice. And honestly, it works. I laughed, then I actually rested my eyes.

Here's what it does:

Setup is one typed sentence. I typed "remind me to drink water every 45 min, rest my eyes every 20, stretch every hour, nothing before 9am or after 8pm, sarcastic friend tone" and a local model turned it into a config file. No settings screen, no sliders, no dropdowns.
Any personality you like. Sarcastic friend, calm coach, pirate, angry gym bro. Change one word and the whole app talks differently.
It knows when not to bother you. It reads my active window title, labels what I'm doing (coding, video, meeting, documents...), and holds reminders back during a Zoom or Google Meet call. When I leave the call, I get one combined popup instead of three stacked ones.
Long-break nudges. After 2 hours of continuous screen time, it tells me to take a proper break and mentions what I've mostly been doing.
Snooze, pause and quit from the popup and a system tray icon.

It starts with Windows and has no console window. I set it up once and never touched it again. That's the whole point. 🦥

Demo

Code

https://github.com/kumudasrip/Break-Buddy

The README has the full setup. You need Windows, Python and Ollama, and it's about five minutes from clone to first popup.

How I Built It

I know Python well, but I had never used an open-weight model before this week. I had Ollama installed and a few models pulled, and that was it. No fine-tuning, no GPU tricks, just calling a local model from Python and seeing what happens.

The stack

Ollama runs the models on my machine. I call it from Python like any other library.
gemma4:e4b is the default model. It's small enough to stay loaded all day.
Pydantic + Ollama structured output forces the setup step to return valid JSON, which is validated and retried up to 3 times.
pygetwindow reads the active window title, and the Windows GetLastInputInfo call measures idle time.
tkinter draws the popups and pystray draws the tray icon.
The hero is drawn entirely by Python (make_sprite.py). There are no image files to download. It's an original hooded, caped guardian with a crescent-moon emblem.

Where the AI actually earns its place

A plain "every 45 minutes" timer needs no AI at all, and I didn't want the model to be decoration. So it has three real jobs:

Understand me. Turn a typed sentence into a structured config.
Understand my screen. Label what I'm doing from the window title, so reminders can wait during meetings.
Write the message. A fresh line for every reminder, in my chosen tone. It only receives a label like "coding" and a number of minutes, never the real window title.

What went wrong (the part I actually learned from)

1. The model ignored my tone.
I typed "sarcastic friend" and the config kept saving "friendly". Again and again. The cause was my own schema: I had pre-filled "friendly" as a default value, and the small model copied the default instead of reading my sentence. The fix was to make the field required with no default, and to add one example ("pirate voice" becomes "pirate"). After that it worked every time. Small models follow defaults over instructions, and now I know.

2. The popups overlapped.
I had guessed the popup height, and on my high-DPI screen the real windows were taller. Popups piled on top of each other and hid the one below. I switched to measuring each popup after its text is laid out, and turned on DPI awareness.

3. Meeting detection was too trusting.
I tested it with a file named Zoom meeting.txt, and the model correctly said it was not a meeting. But that test made me realise something uncomfortable: if the model ever misreads a real call, the app interrupts me in the middle of it, and that's the worst possible failure. So I added fixed patterns for Zoom, Meet, Teams and Webex that run first, with the model as the backup. In my logs the model caught titles my patterns missed (like Kumuda Sri Padmanabhuni's Zoom Meeting), so the two layers cover each other.

4. Limits I know about.
Zoom's home screen ("Zoom Workplace") also holds reminders back, even when I'm not in a call. And a "Connecting…" window at the start of a call can let a reminder slip through for a few seconds. I'd rather tell you than hide it.

Slow and steady: which model should an always-on app use?

I wanted to know if I even needed a big model, so I wrote benchmark.py. It imports the app's own prompts and runs the same tasks through three models: 10 typed setup sentences, 36 window titles (including my real ones), and reminder messages in five tones. Setup and labeling ran at temperature 0 with one attempt per case. The real app retries setup up to 3 times, so real-world results are a little better.

	gemma4:e4b	gemma4:26b	qwen3.6:35b
Setup: perfect parses	9/10	10/10	10/10
Window labels (patterns + model)	97%	97%	92%
Meeting recall	7/7	7/7	7/7
Non-meetings called meetings	0	0	0
Messages that follow the rules	100%	100%	80%
Cold start	5.8 s	64.7 s	25.7 s
Median time per message	0.2 s	0.4 s	0.5 s
Tokens per second	118	56	61
Memory while loaded	3.3 GB	18.3 GB	23.3 GB
Share running on my GPU	100%	51%	41%

What the numbers told me:

The small model was enough. The bigger models got exactly one more setup sentence right (e4b dropped the "walk every 90 minutes" reminder from "take a walk every 90 minutes, no reminders before noon, motivational speaker"). On labeling and message quality, e4b matched or beat them.
Going big costs a lot. gemma4:26b needs 18 GB and took over a minute to cold-start. On my laptop it only half fit on the GPU. For something that sits in memory all day, a 3.3 GB model running fully on the GPU is the obvious choice. That's the sloth way: do the job with the least energy.
The biggest model wasn't the best one. qwen3.6:35b labeled my Copilot window as "coding", and one sarcastic message wasn't about water at all: "I suppose someone has to remind you to stay alive today." Funny, but not a water reminder. 😅
Safety rules beat model size. All three models caught every meeting and none raised a false alarm, partly thanks to the fixed patterns.
Honest caveats. This is a small test (10 sentences, 36 titles), I wrote the correct labels myself, and some "mistakes" are debatable. A Chrome tab I'd call "other" was labeled "browsing" by all three models.

Why Does Open Innovation Matter?

I'll say it plainly: ChatGPT or Claude could write a nicer reminder than my local model, and would probably label odd window titles better. If this were a one-off task, I'd use one.

But Break Buddy isn't a one-off task. It's a tool that watches my screen and runs every day for the rest of my life. For that, open and local wasn't a nice-to-have. It's the only version I'd actually be willing to run.

1. It keeps my screen off someone else's server.
Break Buddy reads my active window title every few seconds. That's every tab I open, every file I touch, every chat window, every job search, every bank page. I would never stream that to a server I don't control, and I'd be uncomfortable even with a promise not to store it. Because the model runs on my laptop, I could build the one feature that makes the app smart, knowing what I'm doing, with zero privacy cost. With a closed API, that feature would have been the part I couldn't ship.

2. An always-on tool should cost nothing to leave on.
This app makes model calls all day, every day. On a metered API, "set it once and forget it" turns into a bill that never stops. Locally it's free, and gemma4:e4b idles at 3.3 GB without me noticing. Nothing in the app needs the internet once the model is downloaded.

3. I could measure instead of guess.
Changing one line let me put three models through the same tests and compare accuracy, speed and memory. That's how I discovered that the small model was enough, and that the biggest one wasn't better. With a closed API, I'd be using whatever model the provider picks, and I couldn't have measured the memory, the GPU share or the cold start at all.

4. I could control and debug the model's behavior.
When the model kept saving "friendly" instead of "sarcastic friend", I could look at my own schema, set the temperature to 0, switch thinking off, force the output into JSON and find the real cause. When the vision model failed, I could test it from the command line to prove the problem wasn't my code. Having every layer in my hands is what turned "it doesn't work" into "here's why".

5. Nobody can change it under me.
The app behaves the same way tomorrow as it does today. A provider can't quietly update a model, change its pricing, or retire the endpoint my daily tool depends on.

The honest trade-off is quality on unusual cases. A big cloud model would probably win there. But for this job, a small model on my own machine did everything I needed, and that's the point. Open models let me pick the right size for the problem instead of renting the biggest one by default.

The Lazy Payoff

I set Break Buddy up once, with a single sentence. Now it starts when I turn on my laptop, and since I switched to real mode the reminders show up on schedule without me opening a settings screen or touching a config file.

And the best part: it actually changed what I did. I really did drink the water, rest my eyes and stand up when the hero told me to. A normal timer I would have dismissed without reading. A pixel hero that roasts me in a fresh sentence every time is much harder to ignore. 😄

In my Meet and Zoom tests, reminders were held back for the whole call, and I got a single combined popup afterwards instead of a pile of them. So the app doesn't just remind me. It knows when to stay quiet, which is what a lazy person really wants from an assistant.

Effort I save: no remembering, no setup screens, no switching apps, no dismissing the same sentence 50 times. Effort I spend: one typed sentence.

Prize Categories

Best Use of Gemma. The default model is gemma4:e4b, and I benchmarked it against gemma4:26b for setup parsing, window labeling, message quality, speed and memory. The small Gemma turned out to be the right model for an always-on tool.

Look away from the screen. Drink some water. The hero is watching. 👀😂

I Built BirdLens, an AI-Powered Bird Identifier That Encourages You to Look Up

Kumuda ⚔️ — Sat, 10 Oct 2026 13:07:22 +0000

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

What I Built

Here's a small question I've been thinking about: how many interesting things do we walk past every day without really noticing them?

A bird sitting on a tree. A flash of blue across a park. A bird with a call we've heard a hundred times but never identified.

We see these things, maybe get curious for a few seconds, and then move on.

Sometimes, we want to learn more, but identifying an unfamiliar bird isn't always easy. You might not know where to start, and searching through pictures of similar-looking species can be frustrating.

That's where BirdLens comes in💟

BirdLens is a web application that helps people explore birdlife through AI-assisted identification, a personal field journal, and small outdoor discovery challenges.

The idea is simple: upload a photograph of a bird, explore the AI's possible identification, and save the moment in your field journal.

It's not meant to turn birdwatching into another activity where you spend an hour staring at your phone. I want the technology to help you become curious about what's around you, then give you a reason to look away from the screen and observe a little more.

That felt like a natural fit for this week's Touch Grass theme.

Meet BirdLens

You can try the live application here:

🌿 Live demo: https://birdlens-7vm7.onrender.com/

💻 Source code: https://github.com/kumudasrip/BirdLens

I wanted the experience to feel approachable rather than like a complicated machine-learning demo. You shouldn't need to understand image classification to get started.

The interface follows a simple flow: upload a photo, explore the results, and save your discovery.

1. Give a bird a name

The main feature is AI-assisted bird identification.

Upload a bird photograph, and BirdLens sends it to a hosted image-classification model. The application displays possible species matches along with their model scores.

For example, while testing BirdLens with a peacock photograph, the model returned Peacock with a 96.9% model score.

Seeing the result appear in my own application was a particularly satisfying moment. It wasn't just a model running in a separate demo anymore. I had connected the inference process to my own frontend and backend, and the result was appearing in the interface I had built.

Of course, a high model score doesn't guarantee that an identification is correct. The predictions are suggestions, not definitive answers.

2. Keep a little field journal

I also wanted somewhere for discoveries to go after identification.

That's why BirdLens has a personal field journal. Each entry can include a bird name, photograph, date, optional location, and personal notes.

Maybe you spotted a bird in a nearby park. Maybe you noticed its colour, watched it searching for food, or simply liked the way it looked.

You can record those details and build a small collection of sightings over time.

The journal also displays the total number of sightings and the number of different species recorded. Saved entries appear in a responsive card layout, making it easier to revisit them later.

The journal uses browser local storage, so there's no account creation or database setup involved. Your saved sightings remain in that browser on that device rather than syncing automatically to an online account.

3. Make going outside the point

BirdLens also includes Nature Quests: short, beginner-friendly prompts that encourage you to pay closer attention to your surroundings.

They might encourage you to notice bird behaviour, look for different colours, or observe what is happening around you.

These quests currently use predefined prompts rather than AI-generated challenges. I wanted to start with something lightweight that supports the project's main idea: getting outside and noticing things you might otherwise overlook.

The goal isn't to collect the most sightings or spend the longest time using an app. It's to find a small reason to explore.

How I Built It

I built BirdLens using a straightforward web stack:

HTML, CSS, JavaScript and Bootstrap 5 for the frontend.
Python and Flask for the backend.
Hugging Face Spaces and Gradio Client for hosted model inference.
Browser local storage for the field journal.
Render for deploying the application.

The architecture is intentionally simple.

When someone uploads a photograph, the frontend sends it to a Flask API endpoint. The backend forwards the image to my Hugging Face Space, which runs the bird-classification model. The resulting predictions are returned to the frontend and displayed to the user.

The journal works separately from the AI identification flow. Once the user has a bird name, they can save the sighting locally, including when the AI service is temporarily unavailable.

This separation became especially useful while I was building and debugging the project.

Choosing the AI model

BirdLens currently uses the prithivMLmods/Bird-Species-Classifier-526 image-classification model, accessed through my Hugging Face Space.

I chose this approach because an image-classification model is a natural fit for the problem. The input is a photograph, and the output is a ranked set of possible species.

The model is available through an open-weight ecosystem, which gives the project a more flexible starting point than building around a single proprietary vision API.

I also wanted to keep the inference integration behind a small backend API. That makes the frontend simpler and gives me a place to handle authentication, errors, and future changes to the model provider.

The current implementation uses hosted inference. It does not run the model directly on the user's device, and it depends on the availability and usage limits of the Hugging Face Space.

The Part That Didn't Work Immediately

Getting the model to make predictions was only part of the challenge. Getting the entire application to work reliably was another story.

One issue appeared when I started testing the integration through my website.

The Hugging Face Space could identify a bird when I used its own interface, but requests from BirdLens sometimes failed with a ZeroGPU usage-limit error.

At first, it was confusing. The model worked, the image was valid, and the frontend appeared to be doing its job. Yet the application couldn't consistently get a result.

The important lesson was to stop treating every failure as a frontend problem.

I checked the Flask terminal logs and traced the request through the application. That helped me distinguish a request reaching the backend from a request successfully completing inference.

I then configured Hugging Face authentication through an environment variable instead of placing a token in the frontend. After that change, I was able to test multiple bird photographs successfully.

That wasn't the end of the deployment work, either. The local application and the Render deployment behaved differently because the hosted environment had its own configuration and dependency requirements. Checking the deployment logs helped me identify and fix a Gradio Client configuration error.

Eventually, the complete flow worked on the live application: upload a photograph, receive predictions, edit the bird name, and save the sighting.

This was a useful reminder that a successful model demo and a working application are two different things. The integration, error handling, authentication, and deployment all matter.

Taking BirdLens Outside: From a Nature Quest to a Real Sighting 🌿

I didn't want BirdLens to be just another AI demo that I built, tested in my browser, and left online.

One of its main features is Nature Quests, so I decided to use the app the way I had imagined someone using it in real life: start with a small challenge, head outside, and see what I discover.

I opened BirdLens on my phone and generated today's quest:

Listen carefully for two minutes. Can you distinguish different bird calls?

That gave me a reason to pause and pay attention to the birds around me. While observing them, I noticed one that caught my attention because of its unusually long, curved beak. It looked unfamiliar to me, and I wanted to know more about it.

So I took a photograph and opened BirdLens on my phone.

I uploaded the image, and the classifier returned Tropical Kingbird as its top prediction, with a model score of 24.7%. Other suggestions included Malagasy White Eye and Malachite Kingfisher, with much lower scores.

The result was interesting, but the relatively low top score also reminded me not to treat the prediction as a confirmed identification. I hadn't independently verified the species, so I kept the result as a suggestion rather than a definitive answer.

I then saved the sighting in my BirdLens field journal, adding a note about what had caught my attention:

“Its beak was so long and it looked very new to me.”

That small observation was the reason I wanted to identify the bird in the first place. The AI gave me a starting point, while the field journal let me preserve the moment and my own thoughts about it.

My outdoor experiment

Nature Quest: Listen carefully for two minutes and try to distinguish different bird calls.
Observation: A bird with a long, curved beak that I hadn't noticed before.
BirdLens prediction: Tropical Kingbird — 24.7% model score.
Field journal: One sighting saved, with my observation recorded in the notes.

What I liked most was how the experience connected the different parts of BirdLens. A simple quest encouraged me to observe my surroundings, that observation made me curious about a bird, and the AI gave me somewhere to start exploring.

The prediction itself wasn't conclusive, and that's an important part of the experience too. AI can help us investigate what we see, but it shouldn't replace careful observation or independent verification.

BirdLens wasn't just something I built to identify birds. I finally used it for the reason I built it: to turn a little curiosity outdoors into a discovery worth remembering.

Why Open Innovation Matters Here

This is one of the most interesting parts of building BirdLens for me.

An AI-powered bird identifier could be built around a proprietary vision API. That might be a perfectly reasonable engineering choice, but it would also tie the application to that provider's model access, API behaviour, pricing, and available features.

Using an open-weight model gives me another option.

I can explore how the classifier behaves, evaluate its results on different bird photographs, and investigate alternative models as the project develops. The model is not simply an opaque feature that I have no choice but to accept as-is.

It also makes experimentation more accessible. I can build the application around a model that is already available, test its capabilities, and decide where it works well and where it needs improvement.

There is an important distinction, though: open-weight does not automatically mean offline, free forever, or completely private.

BirdLens currently sends photographs to a hosted inference service. Its availability depends on that service's usage limits, and the current implementation does not provide local inference.

I see this as a starting point rather than a limitation I should hide. A future version could investigate local inference, alternative compatible models, or other deployment options. Those changes would need to be evaluated for model quality, hardware requirements, latency, and cost.

For this version, the main benefit is having a working AI integration built around a model I can investigate and potentially replace, rather than committing the entire application to one closed AI API.

What I Learned

Building BirdLens reminded me that a project doesn't become complete just because its main feature works once.

I learned how the pieces of an AI-powered web application fit together: the frontend handles the user's interaction, the backend manages requests, the inference service runs the model, and the application needs to handle failures at every boundary.

I also learned the importance of reading logs rather than guessing. The ZeroGPU issue and the deployment configuration error were different problems, even though both initially appeared to the user as a failed identification.

On the product side, I found myself thinking about what should happen when AI is unavailable. Rather than blocking the entire experience, BirdLens lets users enter a bird name themselves and still save the sighting. That keeps the field journal useful even when the model cannot provide an answer.

And perhaps most importantly, I had to think about how the application should encourage people to use it.

The purpose isn't to keep someone browsing bird cards indefinitely. It's to help them become curious about the birds around them and make that curiosity a reason to spend more time outdoors.

What's Next?

BirdLens is working as a deployed application, but there is still room to improve it.

Some things I'd like to explore next include:

Expanding the educational information available for identified species.
Testing the classifier across more bird species, photographs, and lighting conditions.
Improving identification reliability and communicating uncertainty clearly.
Exploring alternative inference options and their trade-offs.
Making the experience more accessible.

I'd especially like to evaluate how useful the predictions are with photographs taken in everyday outdoor conditions, rather than relying only on a few successful test images.

Try BirdLens

🌿 Live demo: https://birdlens-7vm7.onrender.com/

💻 GitHub repository: https://github.com/kumudasrip/BirdLens

If you try it, I'd love to know which bird you tested it with and how well the predictions matched what you expected. Feedback about the identification experience, journal, or outdoor challenges would be especially useful.

BirdLens is a small project, but I like the idea behind it: technology can help us pay more attention to the world rather than simply giving us another reason to stay online.

Sometimes, the most interesting discovery is waiting just outside.

Look closer. Discover more. 🌿