Livestock Farm Assistant

Offline AI assistant for livestock farmers. Husbandry advice animal records on a budget laptop- no internet, no GPU, all on-device.

Comment

Inspiration

I kept coming back to one simple, frustrating fact: the farmers who could benefit most from AI are usually the ones who can't reach it. Out in the field, internet is unreliable or absent. A vet might be hours away or too expensive to call for every small worry. And the AI tools everyone talks about all assume two things a typical farmer doesn't have — a constant connection and a powerful computer.

I wanted to flip that. What if the assistant lived entirely on the farmer's own laptop? No signal needed, no data leaving the device, no expensive hardware. Just a practical helper that knows your animals and helps you think things through — the kind of advice you'd get from an experienced neighbour, available any time, even with the WiFi off.

What it does

The Livestock Farm Assistant is a desktop app with three parts:

1.Advisor — a chat where you ask anything about feeding, breeding, housing, or symptoms to watch for. It quietly pulls in your animal records and recent log entries, so you can ask "Is Daisy due for anything?" and it actually knows who Daisy is. 2.Animals — a simple registry where you record each animal's name, species, breed, date of birth, and notes. 3.Farm Log — dated entries tagged by category (Health, Feeding, Breeding, Weight, Housing, General), each optionally tied to a specific animal.

Everything is saved locally on the machine. It works completely offline once it's set up. And it's careful about its limits — it always reminds you it's not a vet and to call a professional for anything serious.

How we built it

The whole thing is Python. The interface is built with Flet, which turns Python into a real desktop window without any web build step. The intelligence comes from a local language model (llama3.2:3b) running through Ollama, so all the thinking happens on the device itself. Records are stored in a single readable JSON file in the user's home folder — no database to set up, nothing to break.

The trickiest design goal was memory. The target was a budget laptop with only 8 GB of RAM and no graphics card, where going over 7 GB means instant disqualification. So I chose a small-but-capable 3B model, capped the context window to keep memory low, limited the CPU threads to match a budget processor, and streamed the answers so the farmer sees words appearing right away instead of waiting in silence. In the end the whole thing runs in under 4 GB — comfortably under the ceiling.

Challenges we ran into

Honestly, the hardest part wasn't the AI — it was getting everything to run on a real budget machine. Python wouldn't install on the PATH correctly at first, files kept saving with the wrong names and extensions, and the version of the UI library on the test laptop was older than expected, which broke parts of the interface that worked fine elsewhere. I had to rewrite chunks of the app to match exactly what that machine supported, and test each piece carefully before trusting it.

The other challenge was speed. On a CPU with no GPU, the first answer of a session can take a while because the model has to load into memory. I learned to keep the model resident between questions and to stream the output, which made the experience feel far more responsive even though the raw speed is limited by the hardware.

Accomplishments that we're proud of

Making it work and successfully running.

What we learned

I learned that "works on my machine" is a trap, and that building for constrained, real-world hardware forces much better decisions than building for a powerful one. Every megabyte mattered, and that pressure made the final app leaner and more thoughtful. I also got a real feel for how much capability you can pack into a small local model when you respect its limits and design around them.

What's next for Livestock Farm Assistant

I'd like to add region-specific guidance, support for local languages, and optional voice input so farmers with limited literacy can use it just by speaking. The foundation is offline, private, and runs on hardware people already own — and that's exactly where I want to keep building.

Built With

  • desktop-app
  • flet
  • json
  • llama-3.2
  • local-llm
  • offline-ai
  • ollama
  • python
Share this project:

Updates

posted an update —

REPORT.md — Livestock Farm Assistant

  1. Problem

Livestock farmers across much of Africa manage animal health, feeding, breeding, and housing decisions with limited access to veterinary expertise, unreliable internet connectivity, and no budget for cloud-based AI tools. A dairy farmer in a rural area may go days without stable connectivity, yet still needs fast, practical guidance on questions like "is this cow showing signs of illness?" or "what should I feed my goats before kidding season?"

Target user: A small-to-medium livestock farmer or extension officer working from a low-cost laptop (the ADTC Standard Laptop profile: 8 GB RAM, integrated graphics, no discrete GPU), often with no reliable internet after initial setup.

The Livestock Farm Assistant addresses this by pairing a local LLM advisor with a simple animal registry and farm log, so guidance is grounded in the farmer's actual animals and history — entirely offline, with zero recurring cost and zero dependency on connectivity.

  1. Design Decisions

Model: Llama-3.2-3B-Instruct, quantized to GGUF Q4_K_M (bartowski build). A 3B model was chosen over larger alternatives (e.g. Qwen2.5-7B) specifically because the ADTC efficiency score (S_eff) rewards lower RAM utilization, and our target hardware has only 8 GB total RAM to share between the OS, the app's UI (Flet), and inference. A 7B model would leave dangerously little headroom.

Runtime: Originally built against Ollama during early development for convenience (fast local iteration, simple HTTP API). For ADTC compliance — which requires llama.cpp directly, with no other runtime accepted — the app was migrated to llama-cpp-python, loading the same GGUF weight file directly via Llama() rather than proxying through a separate Ollama server process. This also removes a moving part (no need to keep ollama serve running in a second terminal) and matches exactly what the ADTC profiler benchmarks.

Quantization level: Q4_K_M was chosen as the standard balance point between output quality and memory footprint for 3B-class models on CPU-only inference. Q5/Q6 variants were considered but not tested in this cycle; Q4_K_M's ~1.87 GiB footprint left comfortable headroom under the 7 GB efficiency budget.

Context window: Configured at 2048 tokens (n_ctx=2048). This keeps memory overhead predictable and is sufficient for the farm-log context injection pattern used by the Advisor tab (recent log entries

animal registry + the current question), without needing a larger window that would only inflate memory usage for a use case that rarely requires long-context reasoning.

  1. Constraints

Hardware: Tested on an Intel Core i5-7200U (2 cores / 4 logical threads, 2.50 GHz base), a 2017-era ultrabook CPU with no discrete GPU — representative of the older, budget hardware the ADTC challenge specifically targets, rather than a high-end development machine. RAM: 8 GB total system RAM, shared with the OS and the Flet desktop UI process. Connectivity: The app must run with zero network calls during inference. Model weights are fetched once during setup (download_model.sh) and never re-fetched at runtime. Power: Target users may be running on battery or intermittent power in rural settings — informing the choice of a smaller, lower-thermal-load 3B model over a larger one.

  1. Benchmarks

Measured locally via llama-bench and the ADTC profiler (adtc-profiler run --mode participant --skip-accuracy) on the i5-7200U reference machine described above.

llama-bench (standalone, 4 threads — matches hardware thread ceiling)

TestResult (t/s)pp51220.53 ± 0.46tg1286.34 ± 0.14

ADTC profiler (submission.json, participant mode)

MetricValueTokens/sec (generation)5.62First token latency33,237.95 msPeak RSS (RAM)3,367.7 MBSteady-state RSS (RAM)2,783.6 MBCPU utilization (p99)94.4%Thermal throttledfalseParams match metadata claimtrue

The gap between the standalone llama-bench result (6.34 t/s) and the profiler's measured throughput (5.62 t/s) is attributed to the additional overhead of the full application context — the profiler exercises the actual submission pipeline rather than a bare llama-bench invocation, including model loading through the app's own configuration path.

Projected leaderboard components (accuracy omitted; not scored in participant self-check mode):

S_perf = min(5.62 / 15.0, 1.0) × 100 ≈ 37.5 S_eff = max(0, (7.0 − 3.368) / 7.0) × 100 ≈ 51.9 P_thermal = 0 (no throttling observed)

No out-of-memory errors or thermal throttling occurred during any benchmark run, indicating the model comfortably fits the ADTC Standard Laptop's 8 GB RAM / integrated-graphics-only profile with room to spare.

  1. Notes on Limitations

The Advisor is explicitly designed to defer to a real veterinarian for anything urgent or serious — this is enforced both in the system prompt and reinforced with an always-visible disclaimer in the UI. A 3B model, however capable at structuring farm-management thinking, is not a substitute for breed-specific expert knowledge or clinical diagnosis, and the app is built around that boundary rather than around it.

Log in or sign up for Devpost to join the conversation.