This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
PingPilot is a local-first AI network diagnostic tool I built for a friend who loves gaming but regularly struggles with high ping, random lag, jitter, and packet loss.
Whenever the connection gets unstable, the usual solution is to guess: restart the router, blame the Wi-Fi, or assume the internet plan isn't fast enough. The problem is that a speed test doesn't really explain why a game is lagging.
So I built PingPilot to investigate the connection instead.
It measures real network conditions such as gateway latency, internet latency, game-server latency, jitter, packet loss, DNS resolution, and network routes, then uses an open-weight AI model running locally to interpret those measurements and explain the likely cause in simple language.
Instead of just telling my friend:
"Your ping is 82 ms."
PingPilot tries to answer the more useful question:
"Why is your game lagging, and what should you actually do about it?"
The goal was to build something small enough to be useful immediately, but personal enough that my friend could actually use it the next time a game starts lagging.
Demo
Live Demo: https://pingpilot-two.vercel.app/
The live demo showcases PingPilot's professional network-diagnostics interface and the complete user flow for analyzing gaming connectivity.
Code
GitHub Repository: https://github.com/bhavya277/PingPilot
The complete source code for PingPilot is open source and available on GitHub.
The repository includes the React + TypeScript frontend, FastAPI backend, network diagnostic engine, Ollama-powered local AI integration, SQLite diagnostic history, and demo mode.
How I Built It
PingPilot is built around a local-first AI architecture, where the AI doesn't replace the network diagnostics — it interprets them.
The backend is built with Python and FastAPI, while the frontend uses React, TypeScript, Vite, and Tailwind CSS.
For the AI layer, I used Ollama to run open-weight models locally, with support for models such as Llama 3.2, Mistral, Qwen, and Phi.
The diagnostic flow works like this:
Real Network Measurements
↓
Deterministic Heuristic Engine
↓
Structured Diagnostic Data
↓
Local Ollama Model
↓
AI Diagnosis + Recommendations
PingPilot first collects real measurements from the user's machine, including:
Gateway latency and packet loss
Internet latency and jitter
Game-server RTT and packet loss
DNS resolution latency
Traceroute information
Network throughput
The diagnostic engine then performs deterministic analysis to identify patterns such as local network instability, upstream packet loss, high jitter, or routing problems.
That structured evidence is passed to the local Ollama model with a strict system prompt that tells the model to never invent measurements, reason only from the collected data, separate evidence from interpretation, and provide prioritized troubleshooting recommendations.
The AI returns a structured JSON diagnosis containing the overall connection status, primary issue, confidence level, evidence, possible causes, recommended actions, and things the user should avoid doing.
I also built a deterministic fallback engine, so PingPilot can still perform useful diagnosis even when Ollama isn't running.
Diagnostic sessions are stored locally using SQLite, allowing users to review previous connection tests and identify recurring problems.
The result is a system where the network engine provides the facts and the open-weight AI explains what those facts mean.
Why Does Open Innovation Matter?
For PingPilot, using open AI wasn't just about adding an AI feature. It made the product possible in the way I wanted to build it.
PingPilot analyzes network information from a user's machine. I didn't want that diagnostic data to be sent to a closed third-party AI API just to explain what was happening.
By using Ollama with an open-weight model, the AI analysis can run locally on the same machine as the network diagnostics.
That gives PingPilot three important advantages:
🔒 Privacy
Network diagnostics can contain information about a user's connection environment. With local inference, the diagnostic data doesn't need to be sent to a cloud AI provider for analysis.
🧩 Freedom to Change
PingPilot isn't locked into a single proprietary AI model. The underlying model can be swapped, upgraded, or eventually fine-tuned for gaming-specific network troubleshooting without rebuilding the entire application.
💰 No Per-Request AI Cost
Once the model is available locally, PingPilot doesn't require a paid AI API or a cloud request every time a user wants to diagnose their connection.
Most importantly, the open-weight model is part of the architecture, not just a feature added on top.
The network diagnostic engine collects the evidence, deterministic logic analyzes the measurements, and the local AI turns that evidence into an explanation that a gamer can actually understand.
For this project, open innovation gave me something a closed API wouldn't have given me as easily: local control over the entire AI reasoning pipeline while keeping the user's diagnostic data close to them.
Top comments (0)