Inspiration
Pests and diseases destroy nearly 40% of the global cocoa crop every single year. For a smallholder farmer in rural West Africa - a region that produces around 70% of the world's cocoa, an outbreak of Black Pod disease or CSSVD can destroy up to 90% of their harvest. While researching sometimes back, I realized that there was no model that covers more than 3 classes of these diseases that troubles cocoa farmers. These diseases are preventable and treatable. But because these farmers operate in deep rural areas with zero internet connectivity, and the nearest crop expert is often a long travel away, they simply can't get the advice they need immediately. I realized that if I couldn't bring the farmer to the expert, we had to put the expert in the farmer's pocket completely offline.
What it does
Kokodiv is an offline-first, zero-dependency AI agronomist workstation. It acts as a personal farm doctor that lives right on the user's device and requires absolutely no Wi-Fi or mobile data to function. If a farmer sees a sick plant, they just snap a photo. Kokodiv's vision engine instantly identifies the disease, while its conversational reasoning engine explains exactly how to treat it. Beyond image diagnosis, farmers can chat with Kokodiv like a knowledgeable friend, asking questions about soil health, planting seasons, or pest control. Every piece of advice it gives is grounded strictly in the official guidelines of the Cocoa Research Institute of Nigeria (CRIN).
How we built it
Building a state-of-the-art multimodal AI that runs completely offline on low-end hardware was an immense challenge. We built Kokodiv from the ground up:
The Vision Engine: We used a lightweight MobileNetV3 model exported to ONNX format to classify cocoa pod lesions in milliseconds with an incredibly small memory footprint (~40MB). The Cognitive Engine: We deployed the newly released Qwen3-0.6B reasoning model quantized to GGUF format (running via llama.cpp). This gives the system native blocks, allowing the AI to logically reason through agricultural problems before generating an answer. The RAG Database: We built a local, zero-dependency SQLite vector database housing CRIN agronomy profiles to ensure the AI's advice is scientifically accurate. The Architecture: We bypassed heavy frameworks like FastAPI or React entirely. The backend is a custom Python http.server, and the frontend is a Neo-Brutalist HTML/JS interface featuring real-time Markdown streaming over SSE (Server-Sent Events).
Challenges we ran into
Building an offline edge AI came with severe constraints and deep architectural hurdles:
The Thermal Measurement Problem: The hackathon explicitly required us to address hardware thermal limits, as running local AI on field devices can melt CPUs in hot climates. The real challenge wasn't just cooling the device, but actually getting an accurate temperature reading in the first place. Linux hardware varies wildly, and polling /sys/class/thermal/thermal_zone*/temp often returns missing sensor data depending on the motherboard. I'm still not completely sure this is fully solved for every device, but I managed to build a fallback loop to capture the most reliable package temp and trigger micro-naps to prevent throttling. Reasoning tendencies of Small Models: Before upgrading to the Qwen3-0.6B reasoning model, I struggled a lot with getting a 0.5B parameter model to behave reliably. It was very difficult to prompt correctly. Even after the upgrade, a 0.6B model is still extremely small and prone to failures. For example, if the farmer just said "Hey buddy," the strict RAG (Retrieval-Augmented Generation) pipeline would confuse the model, causing it to blindly regurgitate a lecture on planting loamy soils instead of just saying hello. Getting a sub-1-billion parameter model to juggle semantic search, native reasoning, and natural conversation required constant, delicate prompt engineering. Data Corruption on the Edge: Unstable power grids during initial installation meant model downloads often corrupted. I had to build a custom, progress-aware downloader and a security_check.sh hook that verifies SHA-256 checksums on boot to auto-heal the system if a file gets corrupted.
Accomplishments that we're proud of
100% Offline Multimodal AI: I successfully combined a local Computer Vision ONNX model (for instant lesion detection) with a quantized Language Model into a single, seamless, zero-dependency application that runs entirely on the edge. Dynamic AI Reasoning: I engineered the system to apply Chain of Thought (COT) processing selectively. When a farmer uploads a photo, the AI uses native tokens to reason through the diagnosis which I captured and rendered as a beautiful, transparent UI widget to build trust. But for casual chats, I bypass the COT to ensure instant, battery-friendly responses. The Thermal Safety Engine: I built an active CPU governor that protects the user's hardware by initiating POSIX SIGSTOP micro-naps when temperatures cross 80°C. Instead of freezing or crashing the HTTP server, it gracefully displays a pulsing "THERMAL COOLING" badge in the UI. Zero Heavy Frameworks: I didn't use FastAPI, Flask, React, or Node.js. I built a rugged, real-time Markdown streaming server using nothing but Python's built-in http.server and Vanilla JS/HTML to keep the memory footprint razor-thin for low-end devices.
What we learned
"Offline-First" Exposes Every Weakness: Building for the edge fundamentally changes how you write code. You quickly realize how much developers rely on the cloud to brute-force problems. When you have no internet, limited RAM, and an overheating CPU, you can't just spin up a bigger server or push an OTA update. You have to write defensive, self-healing code from day one to ensure things like managing memory locks, handling missing hardware sensor data, and verifying file integrity at boot. The Cost of Intelligence: Small reasoning models are capable of deep logic, but they possess almost zero inherent "common sense." If your pipeline architecture or prompt structure has even a slight logical gap, the model will faithfully follow it off a cliff. I learned that deploying local AI is less about raw model power and much more about building a bulletproof pipeline of constraints and context around it.
What's next for kokodiv
My vision is to turn Kokodiv into the ultimate offline agricultural ecosystem:
Mobile App Transition: The immediate next step is wrapping the core engine into a mobile application. Carrying a laptop into a muddy cocoa farm is inherently uncomfortable and impractical; farmers need this technology sitting right in their pockets on a smartphone. Voice and Vernacular Support: I plan to integrate local, offline Speech-to-Text (STT) models to allow farmers with lower literacy rates to simply speak their problems and have Kokodiv reply audibly in West African dialects. Federated Mesh Syncing: I want to build a local Bluetooth/Mesh network feature. When agricultural field officers visit these remote villages, they can sync disease detection data directly from the farmers' smartphones to their devices without internet, updating a centralized tracking system for regional disease outbreaks.
Log in or sign up for Devpost to join the conversation.