DEV Community: Wellington Filipe

A ghost in my shell, powered by a local Gemma

Wellington Filipe — Mon, 26 Oct 2026 20:48:23 +0000

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

What I built

Haunted Terminal: a ghost that lives in your shell. Every few commands (1 in 4 by default), it whispers one eerie sentence about what you just ran and whether it failed.

$ rm -rf node_modules
👻 A clean sweep… but something vital vanished with those modules, didn't it?

It is about 80 lines: a Bash hook (haunt.sh) on PROMPT_COMMAND and a stdlib-only Python script (whisper.py) that calls Ollama's /api/generate. No dependencies, no API key, no account.

Code: https://github.com/Tinhomagri/haunted-terminal

Why open-weight matters here

Your shell history is private. Commands carry hostnames, paths, tokens pasted by mistake. A ghost that reads them must not be a cloud API. Here the prompt never leaves 127.0.0.1.
It works with the lights off. No internet, no outage, no rate limit. If Ollama is down the ghost just stays silent (except Exception: pass) and the prompt is never blocked, because the call runs in a background subshell.
I can swap the model with one env var (HAUNT_MODEL). That let me compare two sizes honestly instead of trusting a spec sheet.
Costs nothing per command. A hook that fires on every few keystrokes would be absurd to bill per token.

Gemma 3 4B vs 12B (measured, not guessed)

Same prompt, 5 commands, 16 cores, no GPU, 14 GB RAM (warm = model already loaded):

Model	First call	Warm median	Warm max
gemma3:4b	9.5 s	2.2 s	2.3 s
gemma3:12b	5.5 s (pre-warmed)	8.2 s	9.3 s

Two things I learned:

12B writes slightly better lines, but 4B is the right default. The ghost runs in the background, but a whisper that shows up 9 s after the command feels disconnected; 2 s feels like it is watching you.
Cold start can silence the ghost. My first 12B run timed out: loading ~8 GB of weights exceeded the 20 s request timeout, and the "never explain yourself" error handling hid it. When it loaded first, the same call took 5.5 s. If you use a bigger model, keep it resident (OLLAMA_KEEP_ALIVE) or raise the timeout.

Sample 4B lines:

git push --force → The past resists your forceful rewrite, forever staining its digital echoes.
sudo apt update → The system whispers of updates, but something else is being quietly installed.

Try it

ollama pull gemma3:4b
git clone https://github.com/Tinhomagri/haunted-terminal && cd haunted-terminal
echo "source $PWD/haunt.sh" >> ~/.bashrc

Env: HAUNT_ODDS, HAUNT_MODEL, HAUNT_HOST.

Limits

Small models sometimes repeat "echoes" and "something unseen". Bash only (zsh needs precmd). Latencies above are CPU-only on one machine.

I taught a local LLM to be lazy on my behalf (sloth-alias)

Wellington Filipe — Tue, 20 Oct 2026 02:12:59 +0000

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

What I built

sloth-alias reads a shell history file, finds the commands and command sequences you keep retyping, and turns them into aliases. A local open-weight model (any Ollama model, default gemma3:4b) does one job: it names each shortcut and describes it in a few words.

$ python3 sloth_alias.py sample_history.txt     # gemma3:4b via Ollama
  deploy    x3   saves   228 keystrokes  <- git push origin main && docker compose up -d --build && ...
  commit    x4   saves   196 keystrokes  <- git add -A && git commit -m wip && git push origin main
  commit2   x4   saves   152 keystrokes  <- git status && git add -A && git commit -m wip
Total lazy payoff: 576 keystrokes (~2.9 min at 40 wpm).

Single file, Python standard library only, zero dependencies.

The sloth rules (design decisions)

The model names, it never writes. The alias body is always assembled from your commands joined with &&. The model returns only {"name", "why"}. A prompt-injected or hallucinating model can't smuggle a command into your shell.
Nothing installs itself. Output goes to sloth-aliases.sh. You read it, then you source it.
No implicit history access. You pass the file explicitly. Your history never leaves your machine.
Names are validated: regex check, no shell keywords, and no collision with anything already on your PATH.
Degrades gracefully: model down, bad JSON, or a name that breaks the length rule (my first prompt got statusaddcommit back from a 4B model) falls back to deterministic initials. A one-shot example in the prompt fixed most of it. --no-llm works fully offline.

Why open matters here

Shell history is some of the most sensitive text on a developer machine: hostnames, paths, tokens pasted by accident. This is exactly the data you should not ship to a hosted API. With an open-weight model on localhost, the history stays on disk, it costs nothing per run, and I can swap models with one flag (--model).

The lazy payoff

On the bundled 26-line sample history, it finds 576 keystrokes of savings, about 3 minutes of typing, in one run. That sample is synthetic; on a real history the repeats compound.

Code

https://github.com/Tinhomagri/sloth-alias

What I'd do next

Overlap handling between sequences (right now status && add && commit and add && commit && push can both be suggested, as the commit2 name above shows), and a --explain mode that lets the model flag dangerous aliases such as ones containing rm -rf.

The invoice on the counter: a local-first cost reader for small restaurants

Wellington Filipe — Wed, 14 Oct 2026 15:03:27 +0000

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

What I Built

Notinha turns a phone photo of a supplier invoice into a cost spreadsheet a restaurant can actually import. It runs entirely on the owner's laptop — Gemma 3 through Ollama, no API key, no upload, no per-invoice cost.

I work on point-of-sale software for Brazilian restaurants, so I have watched this specific chore happen a lot. The supplier delivers, hands over a paper invoice, and somebody types it into a spreadsheet line by line. Every week. The owner of a 12-table burger place does this at 11pm, after close, because nobody else will.

And the number they actually need is never the number on the paper.

The invoice says R$ 89,90 per case. The recipe card needs R$ 7,49 per litre. The invoice says FD 6X2 ROLOS; the stock count is in rolls. Between the paper and the decision — is this burger still making money? — there is a unit conversion that a human does in their head, badly, at 11pm.

So Notinha does two things, and the second one is the product:

Read the table off the photo.
Convert closed packaging into the unit the kitchen counts in.

$ notinha nota-do-fornecedor.jpg
lendo nota-do-fornecedor.jpg com gemma3:4b (local)...

Fornecedor: SERRA AZUL LTDA   Doc: PEDIDO DE VENDA No 018447   Data: 13/10/2026
10 itens · total lido R$ 2329,8

ITEM                                    QTD        UNIT     CUSTO USO
REFRIGERANTE COLA CX 12X1L                4        89,9       7,492/L
OLEO DE SOJA CX 20X900ML                  2         118       6,556/L
QUEIJO MUSSARELA FATIADO               12,5        38,9       38,9/KG
                                 ↻ unitário relido (38,9); quantidade calculada: 486,25 ÷ 38,9
BACON EM MENTA DEFUMADO                 8,2        27,5       27,5/KG
BATATA PRE-FRITA CONG PCT 2.5KG          10        31,4       31,4/UN
PAO BRIOCHE BURGER PCT C/ 12             15        14,2       14,2/UN
ALFACE AMERICANA UNIDADE                 24         4,3        4,3/UN
TOMATE SALADA CAIXA 20KG                  1          96        4,8/KG
MOLHO BARBECUE GALAO 3.2KG                3       42,75      42,75/UN
PAPEL TOALHA FD 6X2 ROLOS                 5        33,6        2,8/UN

CSV: nota-do-fornecedor.csv

That last column is the whole point. CX 12X1L at R$ 89,90 became R$ 7,49 per litre. FD 6X2 ROLOS at R$ 33,60 became R$ 2,80 per roll. Nobody did arithmetic at 11pm.

The ↻ on the cheese line is the interesting part. The model read that row wrong, the arithmetic caught it, a second look fixed it, and the mark tells you which number was reconciled rather than copied. More on that below — it is most of the engineering.

There is also a drag-and-drop page on localhost:8777, because the person who owns the restaurant is not going to open a terminal.

Demo

The ↻ under the cheese is the whole audit trail: unitário relido (38,9); quantidade calculada: 486,25 ÷ 38,9. The first pass read that row wrong, the second pass recovered it, and the line says so rather than looking like the other nine. Anything the second pass cannot recover stays flagged in orange and reaches the CSV with its numbers blank.

Repository: https://github.com/Tinhomagri/notinha

Try it on synthetic data — no real invoice needed, and no real CNPJ, supplier or price anywhere in the repo:

ollama pull gemma3:4b
pip install -e .
python3 samples/make_sample.py
notinha samples/nota-fornecedor.jpg

make_sample.py draws an invoice and then ruins it on purpose: tilts it, drops a light gradient across it, adds sensor grain. A clean render would have told me nothing.

How I Used Open Models

The stack is gemma3:4b served by Ollama, called over plain HTTP with a JSON Schema. Around 590 lines of Python — 455 of them the reading pipeline, the rest the drag-and-drop page — and one dependency (requests).

Structured output is doing real work here. Ollama lets you hand /api/chat a JSON Schema in format, and the model is constrained to produce conforming JSON. No "respond only with JSON" in the prompt, no regex over a markdown fence.

One detail cost me a run to find. Every numeric field in my schema is typed string:

"valor_unitario": {"type": "string"},

Brazilian invoices write one thousand two hundred thirty-four and fifty-six cents as 1.234,56. Let that be a JSON number and the parser reads 1.234 — a thousandfold error, silently, with no exception anywhere. So the model copies the glyphs and my code owns the parsing:

if "," in limpo:
    # comma is the decimal: a dot can only be a thousands separator
    limpo = limpo.replace(".", "").replace(",", ".")

The prompt is also explicit that the model must not compute anything — just transcribe. Arithmetic is the one thing I can do perfectly and it cannot.

The check that makes it usable

A 4B model reading a tilted photo under kitchen lighting will misread a digit. It reads 12,500 × 38,90 in the cheese row as quantity 2, unit price 12,5 — and it does so on every run, so this is not bad luck I can retry away.

The fix is not a better prompt. It is that an invoice line is over-determined: quantity × unit price = line total. Three numbers, one constraint. So:

if quantidade and unitario and total:
    esperado = (quantidade * unitario).quantize(CENTAVO)
    if abs(esperado - total) > max(CENTAVO, total * Decimal("0.01")):
        item["alertas"].append(f"qtd x unitário = {esperado}, nota diz {total}")

That misread line came out flagged: ⚠ qtd x unitário = 25.00, nota diz 486.25. The error was caught by arithmetic, not by the model noticing.

The same redundancy repairs crushed invoices: if a photo loses the unit-price column to a glare, any two of the three numbers reconstruct the third.

Spending inference only where verification failed

Flagging was where I stopped at first. Then I looked at why the model misses that row, and the answer suggested the fix.

The failure is not that the model cannot read 12,500. It is that it is reading a ten-row table in one pass, and the description column sits far to the left of the numeric columns. Row alignment is what breaks, not glyph recognition.

So the repair is a second look with a narrower question. For each flagged line — and only those — the line goes back to the model on its own, anchored by the one number I already trust:

Na nota da imagem, ache a linha do produto "QUEIJO MUSSARELA FATIADO".
Essa linha tem valor total 486,25. Olhe só para ela e devolva a quantidade,
a unidade e o valor unitário, copiados exatamente como estão escritos.
Atenção à coluna QTD: números como 12,500 são um só valor, não dois.

The focused read returns quantidade: 2, valor_unitario: 38,90. Still wrong on the quantity — but it now disagrees with the first pass on the unit price, and 486,25 ÷ 38,90 is exactly 12,5. Two of the three numbers are solid, so the third follows.

That last step needs a guard, because (12,5 × 38,90) and (38,9 × 12,50) both equal 486,25 — the identity alone cannot tell you which column is which. The tiebreaker is that a focused read does not suffer the alignment failure that a table-wide read does, so I take the new unit price only when it disagrees with the first pass, and derive the quantity from it. If anything in that chain fails, the line stays flagged.

# 1st choice: the re-read closes the arithmetic on its own.
candidato = normalizar_item({**base, "quantidade": relido.get("quantidade")})
if not candidato["alertas"]:
    ...
# 2nd choice: keep the re-read unit price, derive quantity from the total.
if unitario_novo is None or unitario_novo == item["valor_unitario"]:
    continue

The derived number is not presented as if it had been read off the paper. It carries ↻ unitário relido (38,9); quantidade calculada: 486,25 ÷ 38,9 through the terminal, the web page and the CSV, so you can see which numbers were transcribed and which were reconciled.

One invoice costs ~1m40s. One flagged line costs ~45s more. Nothing is re-read that passed.

This reframed the product for me. The promise is not the model always reads correctly. It is what it gets wrong is caught, and then either repaired in the open or handed to you marked. A tool that is right 95% of the time and silent about the other 5% is useless for money.

Vocabulary nobody else will maintain

FD, PÇ, SC, C/ 12, DZ are Brazilian wholesale distributor shorthand. No general-purpose vision API is going to carry a dictionary for it. Mine is 20 lines and I edit it when a customer's supplier invents a new abbreviation:

UNIDADE_CANONICA = {
    "KG": "KG", "CX": "CX", "FD": "FD", "PC": "UN", "SC": "SC", ...
}

Plus a regex that pulls 12X1L out of a description and divides the case price by 12 litres.

Honest numbers

On a 15 GB laptop with no GPU, gemma3:4b reads a one-page invoice in ~1m40s. That is slow for a chatbot and completely fine for a thing you run once per delivery while you put the boxes away.

Accuracy, measured rather than asserted. Runs at temperature: 0 over the same photo produce byte-identical CSVs (same md5), so the failures are reproducible rather than a lottery — which is the only reason the numbers below mean anything. Against the known ground truth of that invoice:

	first pass only (`--sem-reparo`)	with the repair pass
Items found	10 / 10	10 / 10
Supplier, document number, date	correct	correct
Invoice total reconstructed	R$ 2.329,80 — exact	R$ 2.329,80 — exact
Numeric lines fully correct	9 / 10	10 / 10
`QUEIJO MUSSARELA` (`12,500 × 38,90`)	read as `2 × 12,5` — flagged	recovered, marked `↻`
Description typos	1 — `MANTA` read as `MENTA`	1 — unchanged
Time	~1m45s	~2m20s

The spelling error survives both passes, and that is correct behaviour rather than a gap I failed to close. It does not touch a number, so no arithmetic can see it — and it does not need to. A misspelt item name costs you a rename. A wrong unit cost gets baked into every burger you sell. The verification layer is aimed at money, not at tidiness.

When the second pass cannot close the gap either, the line reaches the CSV with its quantity and cost columns empty and the reason written into the description field:

ITEM ILEGIVEL;insumo;KG;;;CONFERIR (qtd x unitário = 25.00, nota diz 486.25) — ...;;;;;

The importer refuses that row, the human looks at that one line, and the rest go in untouched. Half an automated invoice beats a wrong one.

Why Open Innovation Matters Here

Four reasons, in the order a restaurant owner would care.

The invoice is a tax document. It carries the supplier's CNPJ, the negotiated price, and by implication the supplier's margin. "Where does this go?" is the first question I get, and "nowhere, it stays on this machine" is an answer that ends the conversation. With a hosted API, the honest answer is a paragraph about data processing agreements, and I lose the sale.

Per-invoice cost is zero. A small restaurant receives 15–40 invoices a month. On a metered API my cost scales with my customer's volume, which means either I price for the heaviest user or I watch margin erode on them. It also means the repair pass above would be a line item I have to ration — spending a second inference on one bad row is free here, and a decision I would second-guess on a meter. Running local, a busy month costs me nothing, so I can charge a flat monthly fee, which is the only pricing a restaurant owner will agree to.

It works in the stockroom. Receiving happens at the back door, with the phone on one bar of signal and both hands full.

The dictionary is mine. FD 6X2 ROLOS is not a problem a general model will ever prioritise. It is a 20-line dict I edit the same afternoon a customer complains.

What I did not get for free: a 4B model on CPU is slower and shakier than a frontier API would be, and I paid for that with the verification layer. That trade was worth it — but it was a trade, and the verification layer is most of the engineering.

What's Next

Not shipped yet, and I am not going to pretend otherwise: it has not been in front of a real restaurant owner yet. Every number in this post comes from synthetic invoices I generated and degraded on purpose, run on my own machine. The real test is a stack of crumpled paper from an actual delivery, and that is the next thing, not a finished thing.

The repair pass also has an obvious next move I did not take: right now it re-reads the whole page image for one line, because I never know where on the paper that line is. Cropping to the row first would make it faster and probably more accurate, and it needs bounding boxes the current prompt does not ask for.

After that: reading NF-e XML when the supplier sends one (exact beats inferred, always), and tracking the same item across months so the tool can say this went up 9% since August — which is the question underneath the whole chore.

The session itself

The challenge notes that embedding the agent session helps judges follow the process, so here is this one. It includes the stretch where my own test-image generator painted a solid grey wedge over the product names and I spent a run blaming the model for not reading data that was not there.

Notinha: reading supplier invoices with Gemma 3 locally, and repairing what it misreads

You

Veja o novo desafio do Hacktoberfest e conclua para mim.

Agent

Vou buscar os desafios ativos antes de assumir qualquer coisa sobre tema ou prazo.

▸ get_challenges per_page=30

Input

per_page=30

Output

Week 2 'Side Hustle' — 12 a 18/out. Construir algo com IA open-source/open-weight no núcleo que alguém pagaria para usar. Julgamento: qualidade do texto > tema > criatividade > execução técnica.

Tema: Side Hustle. Prazo 18/out 23:59 PDT. Preciso de duas decisões suas: o que construir e até onde eu vou sozinho.

You

Conciliador de notas de fornecedor. Construa e deixe o post em rascunho.

Agent

Primeiro conferir o que existe nesta máquina — não adianta desenhar em cima de um modelo que não está aqui.

▸ bash which ollama && ollama list && nvidia-smi && free -g

Input

$ which ollama && ollama list && nvidia-smi && free -g

Output

ollama 0.32.5; gemma3:12b, gemma3:4b, deepseek-r1:7b; nvidia-smi: comando não encontrado; 15 GB de RAM

Sem GPU e com 15 GB de RAM, gemma3:4b é a escolha — e vira argumento, não desculpa: roda no notebook que o dono do restaurante já tem.

Agent

Olhando o sistema de PDV que já existe aqui, achei o formato de importação de estoque. Isso muda o produto: a saída não é 'uma planilha', é o CSV que o sistema dele já engole.

▸ bash head -3 modelos-importacao/modelo-estoque.csv

Input

$ head -3 modelos-importacao/modelo-estoque.csv

Output

Nome;Tipo;Unidade;Código de Barras;Código do Produto;Descrição;Estoque Inicial;Custo Unitário;Estoque Mínimo;Estoque Máximo;Fornecedor;Prazo de Entrega (dias);Foto

Agent

Escrevendo o extrator. Decisão que vale comentar: todo campo numérico no JSON Schema é string. Nota brasileira escreve 1.234,56 — se eu deixar como number do JSON, o parser lê 1.234 em silêncio, sem exceção nenhuma. O modelo copia os glifos, meu código faz a conta.

▸ write notinha/extract.py

Input

notinha/extract.py

Output

SCHEMA com valor_unitario/quantidade/valor_total como string; chamada ao /api/chat do Ollama com format=SCHEMA e temperature 0

Agent

Agora a parte que é o produto de verdade: converter embalagem fechada para a unidade que a cozinha conta. CX 12X1L a R$ 89,90 tem que virar R$ 7,49 o litro.

▸ write notinha/normalize.py

Input

notinha/normalize.py

Output

para_decimal pt-BR, dicionário de siglas de distribuidor (CX/FD/PÇ/SC/DZ), regex de embalagem, e a conferência qtd × unitário = total

Agent

Preciso de uma nota de teste sem expor cliente nenhum. Gerei uma sintética e a degradei de propósito: torta, com luz de lado e granulado. Nota limpa não testa nada.

▸ bash python3 samples/make_sample.py && notinha samples/nota-fornecedor.jpg --json

Input

$ python3 samples/make_sample.py && notinha samples/nota-fornecedor.jpg --json

Output

descrições truncadas: 'ANA UNIDADE', 'CAIXA 20KG', '5X2 ROLOS' repetido

Esse resultado é culpa minha, não do modelo. Vou olhar a imagem antes de mexer no prompt.

Agent

Confirmado olhando o JPEG: a rotação cortou a margem esquerda e a 'sombra' que eu desenhei virou uma cunha cinza sólida por cima dos nomes dos produtos. O dado foi destruído, não degradado — o modelo não tinha o que ler.

▸ edit samples/make_sample.py

Input

samples/make_sample.py

Output

moldura antes de rotacionar; linear_gradient com point(lambda v: 150 + v // 3) no lugar da cunha opaca

You

Isso mesmo, o do dia 12.

Agent

Com a nota legível (e ainda fotografada), a leitura fecha.

▸ bash notinha samples/nota-fornecedor.jpg

Input

$ notinha samples/nota-fornecedor.jpg

Output

10 itens · total lido R$ 2329,8

REFRIGERANTE COLA CX 12X1L                4        89,9       7,492/L
QUEIJO MUSSARELA FATIADO                  2        12,5       12,5/KG
                                 ⚠ qtd x unitário = 25.00, nota diz 486.25
PAPEL TOALHA FD 6X2 ROLOS                 5        33,6        2,8/UN

10 de 10 itens, total exato. E a conferência aritmética pegou sozinha a única linha que o modelo errou: leu 12,500 × 38,90 como 2 × 12,5.

Agent

Três rodadas a temperature 0 produziram CSVs byte-idênticos. Isso importa: significa que o erro é reprodutível, não loteria — e é a única razão pela qual medir faz sentido.

▸ bash md5sum out/run1.csv out/run2.csv out/run3.csv

Input

$ md5sum out/run1.csv out/run2.csv out/run3.csv

Output

5f679c8d25df02cb646ed47b80b052f4  (os três)

Agent

A linha marcada ainda entrava no CSV com o valor errado. Isso é dinheiro: melhor o importador reclamar de campo vazio do que aceitar custo errado calado.

▸ edit notinha/export.py

Input

notinha/export.py

Output

linha com alerta vai sem quantidade e sem custo, com CONFERIR (motivo) na descrição

You

Melhore.

Agent

O furo real é que o modelo erra a linha do queijo em toda rodada e eu só marco. Antes de escrever qualquer correção: por que ele erra essa linha?

A hipótese é que não é leitura de dígito. Ele lê uma tabela de 10 linhas numa tacada só, e a coluna de descrição fica longe das numéricas — o que quebra é o alinhamento de linha.

Agent

Se a hipótese está certa, uma pergunta mais estreita não sofre o mesmo problema. Testando uma releitura de uma linha só, ancorada no total que já conferi.

▸ bash reler_linha(img, 'QUEIJO MUSSARELA FATIADO', '486,25')

Input

$ reler_linha(img, 'QUEIJO MUSSARELA FATIADO', '486,25')

Output

{'quantidade': '2', 'unidade': 'KG', 'valor_unitario': '38,90'}

Hipótese confirmada em parte: a quantidade continua errada, mas o unitário agora vem certo — e 486,25 ÷ 38,90 dá exatamente 12,5. Dois dos três números fecham, o terceiro sai deles.

Agent

Esse último passo precisa de guarda, e quase me escapou: (12,5 × 38,90) e (38,9 × 12,50) dão o mesmo total. A identidade sozinha não diz qual coluna é qual.

O desempate é o próprio diagnóstico: leitura focada não sofre o desalinhamento que a leitura da tabela inteira sofre. Então só aceito o unitário novo quando ele discorda do antigo — que é exatamente onde o desalinhamento aconteceu. Se qualquer elo falha, a linha segue marcada.

▸ write notinha/pipeline.py

Input

notinha/pipeline.py

Output

relê só itens com alerta e com total legível; 1ª escolha a releitura inteira, 2ª escolha unitário relido + quantidade derivada, marcada com ↻

Agent

Resultado, três rodadas, CSVs byte-idênticos de novo.

▸ bash notinha samples/nota-fornecedor.jpg

Input

$ notinha samples/nota-fornecedor.jpg

Output

QUEIJO MUSSARELA FATIADO               12,5        38,9       38,9/KG
                                 ↻ unitário relido (38,9); quantidade calculada: 486,25 ÷ 38,9

(sem itens pedindo conferência)

10/10 linhas numéricas contra o gabarito (12,500 KG × 38,90 = 486,25). Sem reparo eram 9/10. Custo: 1m45 → 2m20, uma inferência extra só na linha ruim.

Agent

O que o reparo não conserta, eu não finjo que conserta: 'MANTA' lido como 'MENTA' sobrevive aos dois passos. Não toca em número, então nenhuma aritmética enxerga — e não precisa. Nome errado custa um rename; custo unitário errado entra em todo hambúrguer que ele vende.

E o número derivado não se disfarça de lido: o ↻ carrega a procedência até o CSV.

You

Publique.

Agent

Publicado com a tag do desafio. O post declara o que não foi validado: nenhuma nota real de fornecedor ainda, só a sintética degradada de propósito.

▸ update_article id=4850796, published=true, tags=[hf26challenge, ai, opensource, python]

Input

id=4850796, published=true, tags=[hf26challenge, ai, opensource, python]

Output

https://dev.to/wellington_filipe_fccda4c/the-invoice-on-the-counter-a-local-first-cost-reader-for-small-restaurants-3bo

Built with Claude Code. Code is MIT.

trilha: identifying birds by ear on the trail, with no signal

Wellington Filipe — Tue, 06 Oct 2026 22:05:16 +0000

This is my submission for the Hacktoberfest Open-Source AI Challenge: Week 1 — theme: Touch Grass.

What I built

You're on a trail. Something calls from the brush, twice, and then stops. You don't know what it was.

The normal move is to hold your phone at the canopy and wait for a bar of signal. The places worth birding are exactly the places that don't have one. So you get home six hours later with a recording you can no longer place, and it sits in your phone forever.

trilha is a command-line tool that does the whole thing on your laptop, offline. It listens to a recording, names what it heard, and writes the outing into a field journal in prose.

$ trilha listen manha.wav --lat -23.55 --lon -46.63 --place "Parque do Carmo"

  manha.wav
  596 species in range · 5.2s on CPU · week 40

   0.97 ###################  Rufous-bellied Thrush
        Turdus rufiventris · first at 30s · 22 window(s)
   0.94 ###################  Rufous-collared Sparrow
        Zonotrichia capensis · first at 42s · 26 window(s)
   0.92 ##################   Southern Lapwing
        Vanellus chilensis · first at 63s · 4 window(s)
   0.59 ############         Southern Yellowthroat
        Geothlypis velata · first at 78s · 2 window(s)

  Field note
  The presence of the Rufous-bellied Thrush, Rufous-collared Sparrow, and
  Southern Lapwing strongly suggests a mixed habitat of open woodlands and
  grasslands within Parque do Carmo. Next, while on this trail, pay particular
  attention to the calls of the Southern Yellowthroat — they often favour dense
  undergrowth and shrubbery, and their distinctive song is relatively
  high-pitched.

No account, no API key, no upload. 5.2 seconds on CPU.

How it works

Three open pieces, each doing the one thing it's good at.

The ear — BirdNET 3.0, through ONNX on CPU. It knows 11,560 species. It slices the audio into 3-second windows and scores each window independently, which is why the output can tell you a bird was first heard at 78s across 2 windows rather than just handing you a label.

The filter — BirdNET's range model, 14,082 species. This is the part I find most interesting and it's the part nobody demos. Give it latitude, longitude and the week of the year, and it narrows the candidates to what could plausibly be there right now. At -23.55, -46.63 in week 40 that's 596 species instead of 11,560.

That reduction is the difference between a useful answer and a list of everything that has ever had feathers. A classifier asked to choose from 11,560 classes will cheerfully hand you a Himalayan bird in São Paulo. Asked to choose from the 596 that are actually in range in October, it won't.

The voice — Gemma 3, through Ollama, on my machine. It turns the detection list into a few sentences for the journal. It never touches the identification.

That last point is a hard architectural boundary, not a disclaimer: if Ollama isn't running, the note is skipped and the detections still print. The language model is the part with taste in it, so it's the part that's allowed to be absent.

The two bugs that mattered

I had the thing working and almost wrote it up at that point. Then I ran it once more, properly, and read the output instead of just checking that it ran.

The field note came back like this:

  Field note
  Aqui está a nota de campo em português:

  **Nota de Campo – Reserva do Pampa**

  A combinação de corruíras, sabiás-laranjeira e sabiá-poca sugere um habitat
  de matagal aberto...

Two separate problems in one paragraph.

The small one: the model announced what it was about to do, then added a Markdown heading. In a terminal pretending to be a paper journal, **Nota de Campo –** is noise.

The one that actually mattered: Reserva do Pampa. There is no such place in this story. I passed no --place, so the prompt sent bare coordinates — -23.55, -46.63, which is São Paulo. The model read the numbers, decided it knew where that was, invented a reserve name, and put the wrong biome on it. The Pampa is 1,000 km south.

This is the failure mode that would have killed the project. The whole premise of a field journal is that it's a record of where you actually were. One invented place name and the entire artifact becomes untrustworthy — not just that line, all of it, retroactively. A tool that is right about the birds and wrong about the ground is worse than no tool, because you'd believe it.

The root cause was in the prompt contract, not the code path. My original SYSTEM already said "never invent a species that is not listed, and never invent a count" — I had thought about hallucination, but only about the taxonomy. I never constrained the geography. So I added the rule I'd been missing:

Only ever refer to the location exactly as it is given to you. When you are given
coordinates and no place name, leave the place unnamed — never guess a park,
reserve, region, biome or city from them.

Return only the note itself: no preamble, no sign-off, no heading, no title, no
Markdown formatting, no restating of this instruction. Start with the first
sentence of the note.

Same recording, after:

A forte presença de corruíras e sabiás indica um habitat de matagal aberto, possivelmente com árvores frutíferas na região. A identificação do sabiá-poca com menor confiança sugere a possível existência de áreas mais sombreadas ou de vegetação densa próximas. Próximo, procure por cantos altos nas árvores, pois o sabiá-laranjeira tende a se exibir em posições elevadas para anunciar sua presença.

No preamble, no invented place, and it still flags the low-confidence detection as low-confidence.

Then I checked the inverse, because a fix that only works in one direction isn't a fix: with --place "Parque do Carmo" it uses the real name. And one more paranoid check — the English note told me to listen for Southern Yellowthroat, a species I hadn't noticed in the list. Was that a third hallucination? No: it's there at 0.59 confidence, 2 windows. The species rule had been holding the whole time. Only the location was unguarded.

The lesson I'm taking: when you write an anti-hallucination rule, you're enumerating the categories of thing the model must not invent. I enumerated species and counts and felt covered. Place was a category I hadn't thought of, and it was sitting right there in the prompt as a bare pair of floats. Worth asking, of any prompt: what else is in this context window that the model could decide it recognizes?

That session, if you want to watch the diagnosis happen:

Catching two prompt bugs in an offline bird identifier

You

Check how we're doing for Hacktoberfest — we were already building a new project.

Agent

The Week 1 theme is "Touch Grass", and the first example in the prompt is literally "a bird call identifier that works on the trail with no signal". That is exactly what trilha-offline is. Deadline Oct 11, 11:59 PM PDT.

The code is 677 lines across 6 modules and the CLI runs, but there is no README (and pyproject points at one, so the build breaks), no git repo, and no DEV post.

▸ get_challenges DEV challenges, active

Input

DEV challenges, active

Output

Hacktoberfest Open-Source AI Challenge: Week 1 — theme "Touch Grass" — ends 2026-10-12T06:59:00Z. Featured categories include Best Use of Gemma.

▸ bash trilha --version && ollama list

Input

$ trilha --version && ollama list

Output

trilha 0.1.0
gemma3:12b  8.1 GB
gemma3:4b   3.3 GB
deepseek-r1:7b  4.7 GB

You

What's left to finish?

Agent

Running it end to end first, because a checklist written without running the thing is a guess.

▸ bash trilha listen samples/corruira-XC436932.mp3 --lat -23.55 --lon -46.63 --lang ...

Input

$ trilha listen samples/corruira-XC436932.mp3 --lat -23.55 --lon -46.63 --lang pt --no-journal

Output

  596 species in range · 5.2s on CPU · week 40

   0.91 corruira (Troglodytes musculus) · first at 21s · 9 window(s)
   0.90 sabia-laranjeira (Turdus rufiventris) · first at 45s · 13 window(s)
   0.47 sabia-poca (Turdus amaurochalinus) · first at 3s · 1 window(s)

  Field note
  Aqui esta a nota de campo em portugues:

  **Nota de Campo - Reserva do Pampa**

  A combinacao de corruiras, sabias-laranjeira e sabia-poca sugere um habitat de matagal aberto...

It works — the identification is solid. But the field note has two defects.

Preamble leak: the note opens with "Aqui esta a nota de campo em portugues:" and a Markdown heading, instead of starting with the note.
Hallucinated location — the worse of the two. The note names "Reserva do Pampa". I passed no --place, so the prompt sent bare coordinates (-23.55, -46.63, which is Sao Paulo). The model invented a place name and got the biome wrong too. A field journal that invents where you were destroys its own credibility.

▸ grep place|prompt|system in trilha/narrate.py

Input

place|prompt|system in trilha/narrate.py

Output

29: def _prompt(listening, place)
31:   f"Location: {place or f'{lat:.4f}, {lon:.4f}'}"
55:   "system": f"{SYSTEM}\n\nWrite the note in {language}."

You

Fix it!

Agent

Both defects are in the prompt contract, not the code path — SYSTEM never forbade a preamble, and never constrained how the location may be referred to. Two rules added to SYSTEM in trilha/narrate.py:

"Only ever refer to the location exactly as it is given to you. When you are given coordinates and no place name, leave the place unnamed — never guess a park, reserve, region, biome or city from them."
"Return only the note itself: no preamble, no sign-off, no heading, no title, no Markdown formatting."

Plus a reinforcement at the end of the user prompt: "Output the note text and nothing else."

▸ bash trilha listen samples/corruira-XC436932.mp3 --lat -23.55 --lon -46.63 --lang ...

Input

$ trilha listen samples/corruira-XC436932.mp3 --lat -23.55 --lon -46.63 --lang pt --no-journal

Output

  Field note
  A forte presenca de corruiras e sabias indica um habitat de matagal aberto, possivelmente com arvores frutiferas na regiao. A identificacao do sabia-poca com menor confianca sugere a possivel existencia de areas mais sombreadas ou de vegetacao densa proximas. Proximo, procure por cantos altos nas arvores, pois o sabia-laranjeira tende a se exibir em posicoes elevadas para anunciar sua presenca.

Preamble gone, no invented place. Now the inverse case — does it still honour a place when one is given?

▸ bash trilha listen samples/sabia-laranjeira-XC112745.mp3 --lat -23.55 --lon -46.63...

Input

$ trilha listen samples/sabia-laranjeira-XC112745.mp3 --lat -23.55 --lon -46.63 --place "Parque do Carmo" --no-journal

Output

  The presence of the Rufous-bellied Thrush, Rufous-collared Sparrow, and Southern Lapwing strongly suggests a mixed habitat of open woodlands and grasslands within Parque do Carmo. Next, pay particular attention to the calls of the Southern Yellowthroat - they often favour dense undergrowth and shrubbery.

Uses the real place. One more check: the note tells the reader to listen for Southern Yellowthroat — is that species actually in the detections, or is it a third hallucination?

▸ bash trilha listen samples/sabia-laranjeira-XC112745.mp3 --lat -23.55 --lon -46.63...

Input

$ trilha listen samples/sabia-laranjeira-XC112745.mp3 --lat -23.55 --lon -46.63 --no-note

Output

   0.97 Rufous-bellied Thrush
   0.94 Rufous-collared Sparrow
   0.92 Southern Lapwing
   0.59 Southern Yellowthroat (Geothlypis velata) · 2 window(s)
   0.57 Red Junglefowl
   0.48 Southern House Wren
   0.43 Rufous-browed Peppershrike

It is there at 0.59. No species hallucination — the "never invent a species that is not listed" rule in the original SYSTEM was already holding. Only the location was unguarded.

You

Yes, let's finish this challenge.

Agent

Wrote the README around what the tool actually prints (captured from real runs, not invented), added the MIT LICENSE file that pyproject declared but did not ship, and made the first commit.

▸ bash trilha doctor

Input

$ trilha doctor

Output

  trilha 0.1.0
  state      ~/.local/share/trilha
  journal    ~/.local/share/trilha/journal.jsonl (0 outing(s))
  ear model  BirdNET 3.0 (11560 species)
  range      BirdNET 3.0 (14082 species)
  field note ready - gemma3:4b ready

  Models are cached on disk. After this check you can go offline.

▸ bash git init -b main && git add -A && git commit

Input

$ git init -b main && git add -A && git commit

Output

6478e82 trilha 0.1.0 - identify birds by ear, offline
 13 files changed, 903 insertions(+)

▸ bash gh repo create trilha-offline --public --source=. --push

Input

$ gh repo create trilha-offline --public --source=. --push

Output

https://github.com/Tinhomagri/trilha-offline
 * [new branch]      HEAD -> main

A blind test across six countries

I want to be straight about something: I have not yet taken this out on a real trail. The challenge offers bonus points for doing that and I'd rather tell you what I actually did than dress up a demo as a morning in the woods.

What I did instead is arguably harder on the tool. iNaturalist has an open API full of bird observations that carry an audio recording, the exact coordinates, the exact date, and a species identification verified by the community (research grade). That is a labelled test set with real geography attached — and nothing about it was chosen by me to flatter the tool. I pulled eight at random across six countries and ran each one with its own true coordinates and date.

Where	Truth	trilha's top guess
🇧🇷 Parque Nacional das Emas	Melanopareia torquata	Collared Crescentchest `0.98`	✅
🇺🇦 Lviv Oblast	Corvus corax	Northern Raven `0.95`	✅
🇮🇹 Reggio Calabria	Certhia brachydactyla	Short-toed Treecreeper `0.94`	✅
🇺🇸 Bannock County, Idaho	Corvus brachyrhynchos	American Crow `0.93`	✅
🇩🇪 Bad Wurzach	Rallus aquaticus	Water Rail `0.92`	✅
🇩🇪 Berg im Gau	Tadorna ferruginea	Ruddy Shelduck `0.91`	✅
🇩🇪 Duisburg	Larus canus	Common Whitethroat `0.52` → Common Gull `0.32` at #2	⚠️
🇹🇭 Chanthaburi	Arborophila cambodiana	nothing above `0.10`	❌

Six of eight correct on the first guess, seven of eight in the top three, 3.2–4.9 seconds each on CPU. The range filter shrank the candidate pool differently at every site — 592 species in the Brazilian cerrado in January, 232 in western Ukraine in late November — which is the whole mechanism working as intended.

The two that didn't land are the interesting ones.

Duisburg is a city gull recording, and the tool put a warbler on top of the real answer. The gull is right there at #2. This is the honest shape of the thing: on a messy urban recording with several birds and traffic, you get a ranked list, not an oracle. The confidence bars exist so you can see when it isn't sure, and 0.52 versus 0.32 is visibly not sure.

Chanthaburi is the one that taught me something. Complete miss. So I asked the obvious question — does the model even know this bird? I grepped the acoustic model's label files:

$ grep -i arborophila ~/.local/share/birdnet/.../labels/no.txt
Arborophila cambodiana_khmerhøne

It knows it. All 11,560 labels include the Chestnut-headed Partridge. Then I checked what the range filter allowed at that coordinate:

$ trilha here --lat 12.9257 --lon 102.1796 --date 2024-03-16 --limit 0 | grep -i partridge
  Green-legged Partridge  (Tropicoperdix chloropus)

429 species in range, and Arborophila cambodiana is not one of them. The ear could have identified this bird. The filter — the component I'd just finished praising as the thing that makes the tool trustworthy — had made the correct answer unreachable. It's a Cardamom Mountains endemic with a tight range, exactly the kind of bird a range map is least confident about, and exactly the kind of bird someone pointing a recorder at a Thai forest most wants named.

The bug the error message confessed

While tracing that, I found this in detect.py:

raise RuntimeError(
    "The range model expects no species at this coordinate. "
    "Check --lat/--lon, or pass --no-range to listen worldwide."
)

There was no --no-range flag. I had written the error message for a feature I never built, and nothing caught it because that code path is hard to reach — you need a coordinate where the range model expects nothing at all.

The Thai partridge turned it from a cosmetic lie into a missing feature with a concrete use case, so I built it. Same recording, filter off:

$ trilha listen th-partridge.wav --lat 12.9257 --lon 102.1796 \
    --date 2024-03-16 --no-range --min-conf 0.1

  11560 species worldwide · 3.6s on CPU · week 11

   0.35 #######              Chestnut-headed Partridge
   0.34 #######              Taiwan Barbet
   0.21 ####                 Taiwan Scimitar Babbler
   0.17 ###                  Malayan Partridge
   0.10 ##                   Blue-throated Barbet

Correct answer, first place. And look at what came with it: Taiwan Barbet at 0.34, a hair behind, from 4,000 km away. Taiwan Scimitar Babbler at 0.21.

That is the trade-off made legible in one screen. With the filter you get 0.98 on a Brazilian crescentchest and a wall in front of a Cambodian partridge. Without it you can reach the partridge, but Taiwan is suddenly a live hypothesis in Thailand. Neither mode is correct in general, so the tool now does what it should have done from the start: default to the filter, and give you a documented way out when you have reason to think it's the thing standing in your way.

The blind test and the Chanthaburi diagnosis, end to end:

A blind test across six countries, and the range filter that hid the answer

You

Get it from the internet!

Agent

I'll do it, but not as a "Taking it outside" section — writing a field report from a downloaded recording would be claiming, publicly and in your name, something that did not happen. That is literally the bug we just fixed in the code.

The honest version is stronger. iNaturalist's open API has bird observations carrying audio, exact coordinates, exact date, and a community-verified species ID (research grade). That is a labelled test set with real geography attached. Run trilha with each recording's true coordinates and date and check whether it gets the known species. A real blind test, not a demo.

▸ bash curl 'https://xeno-canto.org/api/2/recordings?query=cnt:brazil'

Input

$ curl 'https://xeno-canto.org/api/2/recordings?query=cnt:brazil'

Output

{
  "error": "server_error",
  "message": "Xeno-canto API v2 is no longer available. Visit https://xeno-canto.org/explore/api for API v3 documentation."
}

▸ web_fetch https://xeno-canto.org/explore/api — does v3 need a key?

Input

https://xeno-canto.org/explore/api — does v3 need a key?

Output

Access denied error page (BotStopper protection). No API documentation retrievable.

xeno-canto v3 needs an API key and the site is behind anti-bot protection. Two closed doors — switching to iNaturalist rather than retrying.

▸ bash curl 'https://api.inaturalist.org/v1/observations?taxon_id=3&sounds=true&qual...

Input

$ curl 'https://api.inaturalist.org/v1/observations?taxon_id=3&sounds=true&quality_grade=research&geo=true&per_page=12&order_by=random&captive=false'

Output

total 1062890
Melanopareia torquata | 2026-01-08 | -18.1224,-52.9085 | Parque Nacional das Emas, Brasil
Certhia brachydactyla | 2023-09-19 | 38.3150,16.0922 | Reggio Calabria, Italy
Rallus aquaticus | 2025-04-16 | 47.9144,9.8967 | Bad Wurzach, Germany
Larus canus | 2022-05-01 | 51.3441,6.6847 | Duisburg, Germany
Tadorna ferruginea | 2022-05-23 | 48.6257,11.2156 | Berg im Gau, Germany
Corvus brachyrhynchos | 2025-04-13 | 42.7115,-112.4220 | Bannock County, Idaho
Arborophila cambodiana diversa | 2024-03-16 | 12.9257,102.1796 | Chanthaburi, Thailand
Corvus corax | 2023-11-24 | 49.9325,23.7292 | Lviv Oblast, Ukraine

Eight research-grade observations across six countries. Downloading each and running trilha with its own real coordinates and date.

▸ bash blindtest.sh — trilha listen <each> --lat <true> --lon <true> --date <true> -...

Input

$ blindtest.sh — trilha listen <each> --lat <true> --lon <true> --date <true> --min-conf 0.1

Output

BR Melanopareia torquata  -> Collared Crescentchest 0.98   (592 in range, week 2)   OK
UA Corvus corax           -> Northern Raven 0.95           (232 in range, week 47)  OK
IT Certhia brachydactyla  -> Short-toed Treecreeper 0.94    (353 in range, week 38)  OK
US Corvus brachyrhynchos  -> American Crow 0.93             (258 in range, week 15)  OK
DE Rallus aquaticus       -> Water Rail 0.92                (331 in range, week 16)  OK
DE Tadorna ferruginea     -> Ruddy Shelduck 0.91            (322 in range, week 21)  OK
DE Larus canus            -> Common Whitethroat 0.52, Common Gull 0.32 at #2        TOP-3
TH Arborophila cambodiana -> nothing above 0.10             (428 in range, week 11)  MISS

6/8 on the first guess, 7/8 in the top three, 3.2-4.9s each on CPU. The candidate pool varied by site exactly as designed: 592 species in the Brazilian cerrado in January, 232 in western Ukraine in late November.

The Chanthaburi miss is worth diagnosing rather than excusing. Two hypotheses: either the acoustic model does not know this species, or the range filter excluded it. Those are completely different bugs.

▸ bash trilha here --lat 12.9257 --lon 102.1796 --date 2024-03-16 --limit 0 | grep -...

Input

$ trilha here --lat 12.9257 --lon 102.1796 --date 2024-03-16 --limit 0 | grep -i partridge

Output

  Green-legged Partridge  (Tropicoperdix chloropus)
--- 429 species in range ---

▸ bash grep -i arborophila ~/.local/share/birdnet/acoustic-models/v3.0/onnx/labels/n...

Input

$ grep -i arborophila ~/.local/share/birdnet/acoustic-models/v3.0/onnx/labels/no.txt

Output

Arborophila ardens_hainanhøne
Arborophila atrogularis_hvitskjegghone
Arborophila cambodiana_khmerhøne
Arborophila campbelli_malayhøne

Diagnosed. Arborophila cambodiana IS in the acoustic model's 11,560 labels — the ear knows the bird. It is not among the 429 species the range filter allowed at that coordinate. The filter, the component that makes the tool trustworthy, had made the correct answer unreachable. A Cardamom Mountains endemic is exactly the kind of bird a range map is least sure about.

Agent

Found a third bug while tracing it, and this one is in code, not in a prompt.

▸ read trilha/detect.py:152-157

Input

trilha/detect.py:152-157

Output

allowed = self.plausible_species(latitude, longitude, week)
if not allowed:
    raise RuntimeError(
        "The range model expects no species at this coordinate. "
        "Check --lat/--lon, or pass --no-range to listen worldwide."
    )

The error message tells the user to pass --no-range. There is no --no-range flag in the CLI. The message was written for a feature never built, and nothing caught it because the code path is hard to reach — you need a coordinate where the range model expects nothing at all.

The Thai partridge turns it from a cosmetic lie into a missing feature with a concrete use case, so: implement it. use_range threaded through Listener.listen, custom_species_list set to None when off, and a ranged field on Listening so the output says "worldwide" instead of "in range" when the filter is off.

▸ bash trilha listen th-arborophila-cambodiana.wav --lat 12.9257 --lon 102.1796 --da...

Input

$ trilha listen th-arborophila-cambodiana.wav --lat 12.9257 --lon 102.1796 --date 2024-03-16 --no-range --min-conf 0.1

Output

  11560 species worldwide · 3.6s on CPU · week 11
   0.35 Chestnut-headed Partridge
   0.34 Taiwan Barbet
   0.21 Taiwan Scimitar Babbler
   0.17 Malayan Partridge
   0.10 Blue-throated Barbet

Correct answer in first place at 0.35 — and the trade-off visible in the same screen: Taiwan Barbet a hair behind at 0.34, from 4,000 km away. Neither mode is right in general. Default stays filtered; --no-range is the documented way out.

▸ bash trilha listen samples/corruira-XC436932.mp3 --lat -23.55 --lon -46.63 # regr...

Input

$ trilha listen samples/corruira-XC436932.mp3 --lat -23.55 --lon -46.63  # regression

Output

  596 species in range · 4.5s on CPU · week 40
   0.91 Southern House Wren
   0.90 Rufous-bellied Thrush

No regression on the ranged path. Committed and pushed.

▸ bash git commit && git push

Input

$ git commit && git push

Output

0d31246 listen: add the --no-range flag the error message already promised

Why open matters here

Not as a philosophical preference. This tool does not function without it.

No signal is the normal case, not the edge case. Every model here is a file on disk. You run trilha doctor once at home on wifi, it confirms the weights are cached, and then it tells you: "Models are cached on disk. After this check you can go offline." A hosted API is a hard dependency on a network that, by the nature of the activity, isn't there.

Coordinates are a movement profile. Where you go birding, at what hour, how often, how it changes over a year — that's not a bird fact, it's a map of your habits and your free time. Sending that to someone else's server to get a bird's name back is a bad trade, and it's a trade you'd be making weekly for years. Here it never leaves the machine. There is no server to leak it.

I could read the filter's mind. This is the one I didn't expect to matter and it turned out to be the whole story of the Thai recording. I could grep the label files to confirm the species existed, query the range model directly with trilha here to see what it allowed, find the discrepancy, and ship a flag to work around it — in an afternoon, without filing a ticket with anyone. Against a closed endpoint the entire investigation would have been "it returned nothing, I guess the bird isn't supported." Open weights let you distinguish the model doesn't know this bird from my pipeline threw the answer away. Those are completely different bugs with completely different fixes, and from the outside they look identical.

Swappable voice. --model takes anything Ollama runs. The note is the subjective part, so it should be the replaceable part — gemma3:4b on a laptop in the field, gemma3:12b at a desk with RAM to spare. Same tool, no code change, no vendor to ask permission from.

It costs nothing per use. That blind test was 9 inference runs over 8 recordings, plus every re-run while I was chasing the partridge. On per-call pricing I would have tested three and called it good — and the Chanthaburi miss, the only genuinely instructive result of the day, was the eighth.

Try it

git clone https://github.com/Tinhomagri/trilha-offline
cd trilha-offline
python3 -m venv .venv
.venv/bin/pip install -e .
ollama pull gemma3:4b
trilha doctor

Two xeno-canto recordings are included so you can try it before going outside:

trilha listen samples/corruira-XC436932.mp3 --lat -23.55 --lon -46.63 --lang pt

There's also trilha here --lat --lon, which lists what's in range at a coordinate with no audio at all — useful the night before, to know what you might be about to hear. And trilha journal, which prints every outing you've recorded, or exports it to Markdown.

Code: https://github.com/Tinhomagri/trilha-offline — MIT.

Prize categories

Best Use of Gemma — Gemma 3 through Ollama writes every field note, locally, and it's the component that makes the journal readable rather than a CSV of confidence scores. It's also deliberately scoped: constrained by prompt to the detections it was handed, forbidden from naming the ground, and fully optional at runtime. The identification never depends on it.

Built with BirdNET (birdnet-team/birdnet), Gemma 3 and Ollama. Test recordings from iNaturalist observers under their respective licenses; samples from xeno-canto.