DEV Community: Hendra Hendriana

Afterlight: the ghost you leave in the machine, sealed on your own laptop

Hendra Hendriana — Fri, 30 Oct 2026 16:19:27 +0000

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

What I Built

When someone dies, their family inherits a ghost: accounts nobody can find, subscriptions that keep billing, a laptop no one can unlock, thousands of photos on a drive no one knew existed. Almost nobody leaves a map.

Afterlight is that map. It is a local-first digital estate planner. A language model running on your own laptop interviews you, one plain question at a time, and turns your answers into a letter of instruction for the people you love: where things are, who to call, what to cancel, what you want. The letter is encrypted, and the key is split into five printable cards. Any three unlock it. Nothing ever touches a server.

I took "ghost in the machine" literally, and kindly. Día de los Muertos is about keeping the dead present through memory and care. Afterlight is the practical side of that: the last thing you do so that your family's grief is not also a scavenger hunt. It is not a chatbot that impersonates the dead. It never pretends to be anyone.

What it does:

Interviews you. A local model asks natural follow-ups, but a state machine decides which topics are covered, so a small model stays on track.
Refuses secrets. If you paste a password, card number, or seed phrase, a guard blocks it before it reaches the model or the disk. The letter says where things are ("password manager, emergency kit in the blue folder"), never what they are.
Writes the letter from facts. Every fact comes from a validated record, not from model free text. The model only helps with personal messages, and you approve everything before sealing.
Seals with open standards. age encryption, with the key split by SLIP-39 into 5 cards, any 3 of which unlock it.
Recovers without me. The result opens with the stock age tool, so the family does not need Afterlight at all. I confirmed this: recovery opens with the stock age binary, no Afterlight code involved.

Demo

Code

hendrahend / afterlight

Afterlight: a local-first digital estate planner

Afterlight 🕯️

Local-first digital estate planner — built for DEV Hacktoberfest "Ghost in the Machine" (Oct 26–31, 2026).

Afterlight interviews you about your digital life, turns the answers into a plain-letter of instruction for your family, encrypts it with age, and splits the key with SLIP-39 into 5 printable cards. Any 3 of them unlock the letter. Nothing leaves your machine.

Why open

This data is too sensitive for a cloud API — a local model is a requirement, not a preference. The output must stay readable with standard tools (age + any SLIP-39 implementation) even if this project disappears. The model is swappable through config.

Three reasons open matters here:

No cloud. Your answers about accounts, devices, and wishes never touch a remote server. The local LLM never sends anything outward.
Interoperable output. estate.age is a standard age file. The share cards are SLIP-39 mnemonics. Anyone…

View on GitHub

How I Built It

The central design choice is a hard split between what the model does and what plain code does.

Purple boxes are where the open-weight model works. Everything else is plain, testable code.

The model: gemma3:4b (2.5 GB), served through Ollama on a Windows laptop with no GPU. The backend speaks an OpenAI-compatible API, and the model name lives in a config file, not in the code. I compared one model — gemma3:4b produced valid JSON on 5 of 5 answers at about 18 tokens/s, which was enough to move forward without a GPU.

The interview: a state machine owns the checklist (accounts, money, devices, people, wishes). The model rephrases each question naturally and extracts answers into a JSON schema using constrained output. Pydantic validates the result. If the model fails, static fallback questions keep the interview going. A small model plus a strict scaffold turned out to be more reliable than a big model improvising.

The guard: regex and entropy checks (Luhn for card numbers, seed-phrase patterns, high-entropy tokens) run on every answer before it goes anywhere.

The seal: a random 128-bit secret becomes the age passphrase, and the same secret is split with SLIP-39 (shamir-mnemonic, Trezor's reference implementation) into 3-of-5 word shares with checksums, printed as cards with a QR code. A RECOVERY.txt in the package explains, in plain language, how to open everything with only age and any SLIP-39 tool.

Recover flow diagram coming once I capture the screenshots.

Recovery needs no model at all, only open tools.

Tests: 163 tests. Seal and recover round-trip for every 3-of-5 combination, fail correctly with only 2 shares, catch a single checksum typo in a share word, reject guard samples (API keys, card numbers, seed phrases), and a test fails on any non-loopback network connection.

I wrote the spec first in AGENTS.md and built the code with opencode following it. I decided the architecture and the hard rules up front (local-first, no plaintext on disk, guard every answer, no non-loopback network); the agent implemented to that plan rather than inventing its own.

Why Does Open Innovation Matter?

Privacy is the precondition, not a feature. This is the most sensitive data a person owns: accounts, money, family, wishes. With a closed API, every answer in the interview would travel to someone else's server. With an open-weight model on my own laptop, nothing leaves. You do not have to take my word for it: the demo runs with Wi-Fi off, and the test suite fails if the code opens a non-local connection.

This must outlive me. A digital legacy tool that depends on a company is a promise that expires when the company does. Afterlight's output uses open standards with independent implementations, age and SLIP-39. In thirty years, your family needs a copy of age and the instructions in RECOVERY.txt. They do not need this project, and they do not need me.

The model is swappable. Changing the model is one line of config. That is what lets the same tool run on a modest laptop today and on whatever small model is best next year.

It costs nothing to run, which matters for something people should do once and not pay a subscription to keep safe.

The honest tradeoff: a small local model is not as capable as a frontier model, so it cannot be trusted to improvise. That pushed me to give it a narrow job inside a deterministic structure, and I think the tool is safer for it.

The Spirit of It

The first time I ran the interview on my own life, the questions were simple but the answers were not. "Where are your accounts?" — I could answer that. "Who should get the photo drive no one else knows about?" — I had to decide, and deciding meant admitting there was something to decide. The guard is the moment I respect most: I pasted a real-looking API key into the test on purpose, and it refused to seal. It would rather be a pain in the moment than a secret leaked in a letter. And when three cards opened the letter and two did not, the 3-of-5 math stopped being a theorem and became a promise I could actually keep for my family.

Sloth Sounds: I Was Too Lazy to Pick a Playlist, So I Taught My Laptop to Make the Music 🦥

Hendra Hendriana — Thu, 22 Oct 2026 07:12:36 +0000

Sloth Sounds: I Was Too Lazy to Pick a Playlist, So I Taught My Laptop to Make the Music 🦥

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

International Sloth Day was October 20, and sloths have the right idea. They move at their own
pace, conserve their energy, and let the world come to them. So for this week's challenge I
built the most sloth-shaped thing I could think of: a tool for people who want music to wind
down to but cannot be bothered to browse, curate, or pay for another subscription.

You type a lazy vibe — "rainy sunday piano", "slow ambient for sleep", "fireplace while it
snows" — and Sloth Sounds writes the music. One command gets you a seamless loop. One command
before bed gets you a whole multi-minute wind-down set by morning.

Everything runs on my laptop. Open-weight models only. Nothing leaves the machine.

What I built

Sloth Sounds is a local-first ambient music generator:

"rainy sunday piano" ──► vibe expander ──► MusicGen (open weights) ──► seamless loop
  your lazy words        Gemma 3 / Ollama    facebook/musicgen-small    WAV + MP3
                         or keyword map      (swappable)                out/

slothsounds gen "rainy sunday piano" — generates one click-free loop in about half a minute on my GPU (a 4 GB RTX 2050; it also runs on CPU, just slower)
slothsounds night 10 "slow ambient for sleep" — composes a 10-segment set, each segment a variation on the vibe so the piece evolves instead of repeating, crossfaded into one continuous file with a run sheet of timecodes and seeds
slothsounds doctor — tells you exactly what your machine has and what it's missing

The stack is entirely open:

Piece	Role	Why open
MusicGen (`facebook/musicgen-small`)	generates the audio	open weights, runs offline, swappable, fine-tunable, free forever
Gemma 3 via Ollama	expands lazy vibes into music prompts	runs on a laptop, no API key, no usage meter
numpy + stdlib `wave`	loops, crossfades, WAV I/O	boring, reliable
ffmpeg (optional)	MP3 export	already on your machine

The Gemma layer: from lazy words to music prompts

MusicGen prompts want concrete audio descriptors. Humans type feelings. Gemma 3 (4B, Q4,
via Ollama) sits in the middle and translates. Real outputs from tonight's run:

You type	Gemma writes
`rainy sunday piano`	Ambient piano, melancholic, sustained chords, subtle rain ambience, gentle arpeggios, 60 bpm, seamless loop, no vocals
`fireplace while it snows`	Warm synth pads, gentle piano, distant sleigh bells, crackling log, soft strings, 60 bpm, seamless loop, no vocals
`midnight train through the countryside`	Synth pads, distant steel drums, mournful cello, driving arpeggio, shimmering reverb, slow tempo, expansive atmosphere, seamless loop, no vocals

If Ollama isn't running, a keyword-based expander takes over so the tool still works fully
offline. slothsounds doctor reports which path is live.

Hear the Gemma layer work

Same vibe, same seed (777), same model, same GPU. The only variable is who writes the prompt:

Expander	What MusicGen received	Listen
Keyword heuristic	rainy sunday piano, gentle rainfall, distant rolling thunder, soft felt-piano melody, intimate close-miked piano, ambient instrumental, seamless loop, high quality recording, no vocals	heuristic
Gemma 3	Ambient piano, melancholic, subtle strings, gentle rain ambience, slow tempo, shimmering textures, seamless loop, no vocals	gemma

The heuristic path staples stock descriptors onto your words. Gemma makes decisions — it
picks the instrumentation, sets a tempo, shapes an arc. Same seed means any difference you
hear comes from the prompt alone.

Demo

Three loops and one night set, all generated on my RTX 2050 tonight, committed as WAVs in
the repo so you can listen without running anything:

rainy-sunday-piano-42.wav — 30s loop
fireplace-while-it-snows-101.wav — 30s loop
midnight-train-through-the-countryside-202.wav — 30s loop
full-set.wav — 4.7-minute night set (10 segments, crossfaded)

Live demo: slothsounds-site.onrender.com — a
player page with all six tracks, deployed on Render from the render.yaml blueprint in
the repo. Generation stays local; the site is just the shop window.

slothsounds doctor on my machine, verbatim:

[OK  ] Python >= 3.10  3.12.10
[OK  ] numpy           2.5.4
[OK  ] torch           2.5.1+cu121 (NVIDIA GeForce RTX 2050)
[OK  ] audiocraft      1.3.0
[--  ] ffmpeg          not found (optional, MP3 export only)
[OK  ] ollama          reachable, models: gemma3:4b
[--  ] backboard       SLOTHSOUNDS_BACKBOARD_KEY not set (optional, taste memory)

Why open innovation matters for what I built

The closed-API version of this project would be a wrapper: send your vibe to someone else's
GPU, pay per generation, hope the service still exists next year, and hand a company a log of
everything you listen to at 2 AM. That's not a tool, that's a subscription with extra steps.

Running open-weight models locally means:

It works offline. Plane, cabin, cabin-in-the-woods. The music is generated where you are.
It costs nothing to run. The thousandth loop costs exactly as much as the first: zero.
The model is swappable. musicgen-small on a 4 GB laptop GPU today, musicgen-medium on a desktop tomorrow, a fine-tuned specialist the day after — the pipeline doesn't change.
Nothing is logged. Your 2 AM listening habits stay between you and your laptop.

The open pieces aren't decoration here — they're the whole product. Strip them out and there
is no project left.

The lazy payoff

The challenge asked how much time or effort the project actually saves. Here's the honest
math from my own evenings, measured on the runs above:

The old ritual: open the streaming app, scroll, skip, second-guess, land on something you've already played. Five to ten minutes of decisions, every evening, forever.
The new ritual: one command, about ten seconds of typing. The music exists half a minute later.
Night mode: the decision happens before you're even tired. Ten segments — 4.7 minutes of evolving music — composed in about five and a half minutes of wall time. You kick it off, and the set is just there.

Measured on the RTX 2050: each 30-second segment takes roughly 32 seconds to generate, and
the full 10-segment set (282 seconds of audio after crossfades) finished in about five and a
half minutes. Gemma's vibe expansion adds a few seconds when the model is warm.

I won't pretend this saves anyone hours. What it actually removes is the deciding — the
scrolling, the skipping, the standing in the kitchen at 11 PM arguing with yourself about
what to play. The sloth doesn't optimize the walk. The sloth skips it.

Prize categories

Entering two categories, where the integration is strongest:

Best Use of Gemma — Gemma 3 (via Ollama) expands lazy vibes into MusicGen-optimized prompts, with an offline keyword fallback; it also teachers the fine-tuning dataset in the repo
Best Use of Render — the public demo site at slothsounds-site.onrender.com, deployed from the render.yaml blueprint in the repo, serving the actual generated audio

Tinker and Backboard integrations are wired in the repo (a Gemma-distilled training
dataset plus LoRA SFT script; taste memory with a local fallback), but they are not the
headline entries for this challenge.

Show your work

Repo: github.com/hendrahend/slothsounds (MIT). 21 tests, slothsounds doctor for
setup checks, and a Windows shim script because audiocraft's xformers wheels don't exist
for Windows — the kind of detail you only find by actually running the thing.

Built during the Week 3 window (Oct 19–25). Repo: github.com/hendrahend/slothsounds

The hundredth clip costs nothing: Klipkit, a local-first clip finder for freelance editors

Hendra Hendriana — Sun, 18 Oct 2026 03:03:30 +0000

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

What I Built

Klipkit is a clip finder for freelance short-form editors that runs entirely on a laptop — no upload, no per-minute API bill, no NDA problem.

Point it at a podcast, a stream VOD or a client's raw footage. It transcribes the audio locally, finds the moments that work as standalone clips, writes a hook line for each, and exports a client-ready pack: MP4 + .srt + a run sheet with timecodes.

source ──► whisper (local) ──► candidate moments ──► local LLM judge ──► clip pack
file/URL     word timestamps     cheap heuristics      open-weight model     mp4 + srt

Who would pay for it: freelance clippers and short-form editors who get paid per clip and work under NDA. They have two problems that hosted tools make worse.

Per-minute pricing: cloud clip tools charge by upload-minute. If a client sends a two-hour podcast and you pull eight clips, you pay for the whole two hours. Do that for ten clients and the tooling costs more than the job.

And the footage isn't theirs. Clients send raw footage under NDA — uploading it to a server the client doesn't control is a non-starter, and "we have a SOC 2 report" is not a satisfying answer when the contract says the file never leaves the editor's machine.

So the business only works if the marginal cost of the hundredth clip is zero. That requires local inference, which requires open weights.

Demo

No hosted link, and that's the point — Klipkit runs locally, so there is nothing to deploy. Here is a real run on a public 62-minute Indonesian-language talk video, on an RTX 2050 with 4 GB of VRAM:

$ klipkit run "https://www.youtube.com/watch?v=zOnA_8JmdM8" -n 5 --whisper small --llm gemma3:1b

  Top moments - NEPHILIM, NABI ADAM & RAKSASA PURBA...
┏━━━┳━━━━━━━━━━┳━━━━━━━━━━┳━━━━━┳━━━━━━━┳━━━━━━┓
┃ # ┃ Start    ┃ End      ┃ Len ┃ Score ┃ Hook ┃
┡━━━╇━━━━━━━━━━╇━━━━━━━━━━╇━━━━━╇━━━━━━━╇━━━━━━┩
│ 1 │ 00:02:45 │ 00:03:31 │ 46s │  0.91 │ -    │
│ 2 │ 00:03:37 │ 00:04:23 │ 46s │  0.91 │ -    │
│ 3 │ 00:14:16 │ 00:15:05 │ 49s │  0.91 │ -    │
│ 4 │ 00:19:45 │ 00:20:31 │ 46s │  0.91 │ -    │
│ 5 │ 00:49:41 │ 00:50:31 │ 50s │  0.91 │ -    │
└───┴──────────┴──────────┴─────┴───────┴──────┘

Client-ready pack: out/nephilim/pack

Test source is a public YouTube video, used only as input. Klipkit processed it locally — nothing was re-uploaded, and the rendered clips stay on my machine.

Stage	Result
Transcribe	9,612 words, language `id` at 0.99 confidence, ~6 min on GPU
Utterances	1,216, reassembled from word timings
Candidates	606 → 16 shortlisted by heuristics
Output	5 MP4 clips (45–50 s), 5 SRT files, a run sheet

Roughly ten minutes of wall clock, six of it transcription. The SRT timings come out of the same word timings used for cutting, so captions stay locked to the audio instead of drifting.

The empty Hook column is the honest part of this demo, and I get into it below.

Code

hendrahend / klipkit

Klipkit

Find the clips worth posting — on your own laptop, with no cloud in the loop.

Klipkit is a local-first clip finder built for freelance clippers and short-form video editors Point it at a podcast, a stream VOD or a client's raw footage; it transcribes the audio with Whisper, finds the moments that actually work as standalone clips, writes a hook line for each and exports a client-ready pack (MP4 + .srt captions + a notes sheet).

Nothing leaves your machine. No upload, no per-minute API bill, no NDA problem.

                                                    
  source ──► whisper (local) ──► candidate moments ──► local LLM judge ──► clip pack
  file/URL     word timestamps     cheap heuristics      open-weight model     mp4 + srt

Why local, and why open

Freelance clippers are paid per clip, so two things kill their margin: time and API cost Cloud clip tools charge per upload-minute, which makes high-volume work unprofitable, and they…

View on GitHub

MIT licensed. Python, with faster-whisper, Ollama, ffmpeg and yt-dlp as the only real dependencies.

How I Built It

The open-source AI is the product, not a decoration. Four open pieces do all the work:

Piece	Role	Why it has to be open
faster-whisper	transcription with word-level timestamps	runs offline, no per-minute fee, audio never leaves the disk
Ollama + Gemma 3	judges which moments are clip-worthy, writes the hooks	runs on a laptop GPU, swappable, free forever
ffmpeg	cutting and caption rendering	already on every editor's machine
yt-dlp	optional URL import	no vendor gatekeeping your sources

The design decision that mattered most: the model never sees the whole transcript.

An hour of talk audio is ~10,000 words. Feeding that to a small open-weight model in one shot produces garbage — it loses the thread and burns context on filler. So the pipeline layers cheap and expensive. Heuristics run first and cost nothing: overlapping 45-second windows are scored on question openers, digits, filler density, and whether the cut starts mid-thought. Only the top slice reaches the model.

# klipkit/text.py
def rank_candidates(candidates, keep_ratio=0.5, min_keep=8, max_keep=16):
    ranked = sorted(candidates, key=lambda c: c.heuristic, reverse=True)
    keep = max(min_keep, int(len(candidates) * keep_ratio))
    keep = min(keep, max_keep, len(ranked))
    return sorted(ranked[:keep], key=lambda c: c.start)

That cap does real work: 606 candidates became 16, which is four small batches of judging instead of 606. Ollama runs the judge with format: "json" so the model is constrained to a parseable reply, and the whole pipeline ran on a 4 GB laptop GPU.

What broke on the way — the parts I'd want to read before trying this myself:

1. yt-dlp now requires a JavaScript runtime. Since the 2026 releases, YouTube extraction needs one, and it degrades with a vague "some formats may be missing" warning instead of an error. Node was already installed; the Python API just wasn't being told about it.

# klipkit/ingest.py
opts = {
    "format": "bv*[height<=720][ext=mp4]+ba[ext=m4a]/b[height<=720]/bv*[height<=720]+ba/b",
    "js_runtimes": {"node": {}},   # without this, YouTube extraction silently degrades
}

2. av 19 broke faster-whisper. Not a warning — a hard crash on every input, because av.open() gained a metadata_errors keyword that faster-whisper 1.2.1 doesn't pass. The fix belongs in pyproject.toml, not a README footnote:

dependencies = [
    "faster-whisper>=1.1",
    "av<15",
    "yt-dlp>=2025.1.1",
]

3. cuBLAS wasn't on LD_LIBRARY_PATH. faster-whisper picked CUDA via device="auto", model construction succeeded, then encoding failed with Library libcublas.so.12 is not found. The library existed — bundled inside Ollama's own runtime. Pointing LD_LIBRARY_PATH at it took the GPU to 98% utilization. Worth knowing before concluding your GPU is unsupported.

4. Gemma 3 1b is too small to batch-score reliably. This is the empty Hook column. I asked it to score four candidates at once and return JSON; it returned verdicts for one or two, and one batch came back as an HTTP 500 from Ollama. Every clip fell back to heuristic scoring.

That's a model-capability limit, not a pipeline bug. The default is gemma3:4b for a reason — I only had the 1b because the Ollama registry was unreachable from this machine and I imported the GGUF from HuggingFace directly. It's also the clearest argument for the swappable-model design: the fix is a flag, not a rewrite.

Why Does Open Innovation Matter?

Three things about this project only exist because the pieces are open.

The marginal cost is actually zero. A closed API that charges per minute makes high-volume freelance work unprofitable. Running Gemma 3 locally means the hundredth clip costs the same as the first: nothing. That isn't a discount, it's the difference between a tool a freelancer can build a business on and a tool that eats their margin.

The client's footage never leaves the laptop. This is a hard requirement, not a preference. No closed API can satisfy an NDA clause that says the file stays on the editor's machine — no matter how good its privacy policy is. Local open-weight inference is the only architecture that makes the promise structurally true instead of contractually promised.

I can swap the brain without touching the pipeline. --llm gemma3:1b for a fast pass, gemma3:4b when a clip really matters, or something else entirely next month. When I discovered the 1b model couldn't batch-score, the fix was one flag. With a hosted API, model quality is a vendor decision I'd have to wait on.

The open pieces are also what let a 1b model and a 4 GB GPU be enough. I'm not paying per token, so layering a free heuristic prefilter in front of an expensive judge is pure upside — 606 candidates down to 16 before the model sees anything.

Prize Categories

Best Use of Gemma — Gemma 3 is the judge at the centre of the pipeline, not a bolt-on. It scores hook strength, self-containment, payoff and energy for each shortlisted moment and writes the on-screen hook line. The project ships with gemma3:4b as the default and treats the model as swappable, so the same code runs a 1b or a larger Gemma depending on the hardware and how much the clip matters.

Community Wisdom

The local-LLM stack I leaned on is well-trodden on DEV, and these shaped how I built it:

Build a Voice-Controlled Local AI Agent with Ollama and Faster-Whisper by Shaik Idris — the Whisper + Ollama pairing that made this feel buildable on a laptop.
Local Meeting Notes with Whisper Transcription + Ollama Summaries (Gemma3n, LLaMA, Mistral) — Meetily AI by Zackriya — proof that local transcription plus a local summarizer is a real product shape, not a demo.
Clean JSON Extraction with Ollama and Python by nearshi — the parsing discipline I should have applied before discovering the 1b model's partial responses the hard way.
Taming Local LLM Non-Determinism: Building a Resilient, Multi-Stage JSON Sanitizer & Schema Adapter in Python by toai — the repair-validate-retry pattern that's now first on my list.

What I'd Do Differently

Score one candidate at a time and accept the latency. Batching looked like an obvious token saving, but a 1b model can't hold four scoring rubrics in its head at once, and a partial JSON response is worse than a slow complete one — the fallback silently degrades quality instead of failing loudly.

Make the fallback visible. "scored by heuristics only" is currently a note in the run sheet. It should be a warning at the top, because a pack with five empty hook columns looks like a working result.

Test on a short source first. My first real test was 62 minutes, so every iteration cost six minutes of transcription. A three-minute clip would have caught the av crash in seconds.

Limitations

Talk-heavy footage is where this shines. B-roll-driven video has no transcript worth judging.
Auto-reframing to 9:16 is deliberately not in v1 — a bad vertical crop is worse than none. Klipkit hands the editor timecodes and captions and lets them reframe in CapCut.
Non-Latin scripts and heavy code-switching depend on Whisper's coverage.
No first user yet. The next step is handing it to an editor with a real client backlog and watching which flag they reach for first.

Run it yourself: klipkit doctor tells you what's missing before you spend six minutes finding out.

Kicau: an Indonesian bird-call identifier that works offline

Hendra Hendriana — Sun, 11 Oct 2026 15:32:43 +0000

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

The birds outside my window have Indonesian names — but every bird-identifying app I tried only knew the English ones. Six apps, and not one could tell me what the bird out there is called in the language I actually speak.

So I built Kicau: an offline bird-call identifier that speaks Indonesian.

What I Built

Kicau records bird audio — from your microphone or an uploaded file — and identifies the species, on-device, in English or Indonesian. No internet, no server, no account. It works in the middle of a national park with zero bars of signal, and your recordings never leave your device. An EN/ID toggle in the corner switches the whole UI and the species names — Orthotomus sutorius reads "Common Tailorbird" or "Cinenen pisang" depending on the toggle.

It's for Indonesian birders, hikers, and anyone who's ever heard a bird on a trail and wondered what it was. The screen is the shortest part of the experience: record ten seconds, read the result, pocket the phone, go find the bird. Tap "Use my location" and it also weighs which birds actually live near you.

Yes — there are other bird identifiers in this challenge. Kicau is the one built for Indonesia's 280 million people: Bahasa Indonesia UI, Indonesian species names ("Cikrak bambu", not just Abroscopus superciliaris), two pip packages, one HTML file, zero build step.

Demo

Kicau is offline-first, so there's no hosted demo — that would defeat the point. It runs on your machine:

git clone https://github.com/hendrahend/kicau && cd kicau
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
python scripts/download_model.py   # one-time, ~53 MB
python -m kicau.server             # open http://127.0.0.1:8765

A Common Tailorbird field recording, identified on-device:

Or from the terminal:

python -m kicau.identify recording.mp3 --top-n 3

Code

https://github.com/hendrahend/kicau

MIT licensed. What's inside:

Path	What
`kicau/identify.py`	Model loading, chunking, inference, Indonesian labels
`kicau/audio.py`	ffmpeg-based decode/resample to 48 kHz mono
`kicau/server.py`	stdlib-only HTTP server + `/api/identify`
`kicau/labels_id.txt`	6,522 species labels in Indonesian (BirdNET team)
`web/index.html`	Single-file offline UI — record, upload, timeline, playback
`tests/`	Pipeline tests, including a real-audio classification test

How I Built It

The whole experience is built around one open-weight model:

Piece	Role	License
BirdNET v2.4 (Cornell Lab of Ornithology / TU Chemnitz)	6,522-species bioacoustics classifier; I use the fp16 TFLite variant (~26 MB)	CC BY-NC 4.0 (weights)
LiteRT (`ai-edge-litert`)	On-device inference runtime — no TensorFlow install, no GPU	Apache 2.0
BirdNET's Indonesian labels	Species names in Bahasa Indonesia, shipped by the BirdNET team	MIT (analyzer repo)

One honest caveat on the Indonesian names: the BirdNET team's Indonesian label set covers 1,227 of the 6,522 species so far — the rest fall back to English while the translation grows. The covered ones include the birds you're most likely to meet in Indonesia (Cinenen, Cikrak, Elang-alap).

Pipeline:

mic / upload → ffmpeg (→ 48 kHz mono) → 3-second chunks →
BirdNET v2.4 TFLite (LiteRT, on-device) → flat sigmoid →
top species per chunk, Indonesian names

I verified the math against BirdNET-Analyzer's source line by line — chunk length, sample rate, sigmoid sensitivity — so results match the reference implementation. Then I ran BirdNET's own reference soundscape through it: Black-capped Chickadee 0.92, Dark-eyed Junco 0.88, House Finch 0.83. And on an openly-licensed field recording of a Common Tailorbird (Vis M via iNaturalist, CC BY-SA 4.0, Wikimedia Commons): "Common Tailorbird (Orthotomus sutorius)" at 1.00 confidence — correct species. (Flip the app's EN/ID toggle and it reads "Cinenen pisang" — species names switch languages too.)

One honest miss, because that's part of the deal: on a noisy caged-bird training clip, confidence stayed low (0.06–0.21) and the top guess was wrong. Clean field recordings are this model's home turf; noisy clips aren't.

Location-aware, too. BirdNET ships a second tiny model that takes your latitude, longitude, and the week of the year, and returns how likely each species is there right now. Tap "Use my location" and Kicau multiplies the acoustic confidence by that local likelihood — a bird that merely sounds similar but doesn't live here gets demoted. I verified it: in Jakarta in October the top picks are Burung-gereja erasia (Eurasian Tree Sparrow) and Perkutut jawa (Zebra Dove) — exactly the birds outside my window — while Berlin returns Great Tit and Eurasian Blackbird.

Why Does Open Innovation Matter?

No signal, no problem. The entire point is identifying birds outside. A cloud API is useless in a national park. A local open-weight model is the only architecture that works where the birds actually are.
Your recordings stay yours. Audio is decoded, chunked, classified, and deleted — on your machine. There is nowhere to upload it to, because there is no server.
It costs nothing, forever. No per-request pricing, no API key to babysit. A school birding club can run it on one laptop for years.
I could actually verify it. I checked my preprocessing against the reference implementation line by line and tested on known audio. Try getting that level of verification from a black-box API.

One honest license note: the BirdNET weights are CC BY-NC 4.0 (free for research, education, and personal use) while the analyzer code is MIT and my code is MIT. Open weights with a non-commercial term — worth knowing, and fine for this project.

Prize Categories

Best Use of GitHub Copilot: the repo ships a GitHub Actions CI workflow that installs dependencies, downloads the BirdNET weights, and runs the full pytest suite — including a real-audio classification test — on every push.

Built for Hacktoberfest 2026. Then go outside. That's the whole point. 🌿