DEV Community: Shanaya Carvalho

Khoj: A Little AI Companion That Helps You Rediscover the World

Shanaya Carvalho — Sat, 31 Oct 2026 10:02:37 +0000

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

What I Built

I built Khoj, an open-source, offline-first exploration companion designed to encourage people to step outside, explore their surroundings, and rediscover the world around them.

The idea is simple: choose how much time you have and what interests you, receive a curiosity-driven exploration mission, go outside and record your observations, and turn those experiences into a personal field journal.

I wanted to create something that makes everyday exploration feel a little more meaningful.

For this week's theme, I wanted to highlight how AI can act as a companion to human curiosity rather than simply generating answers.

Demo

https://khoj-37vp.onrender.com/

Note: The hosted demo currently uses curated missions and fallback functionality. Local Gemma inference is available through the project's Ollama integration.

Code

GitHub Repository:

Shanaya31 / Khoj

Open-source, offline-first AI exploration companion that turns city walks into curiosity-driven missions and a personal field journal.

Khoj (खोज)

Don't follow the map. Follow your curiosity.

Khoj is an open-source, offline-first AI exploration companion for discovering the city around you. Starting with Mumbai, it offers curiosity-driven missions, lets you record what you notice, and helps you turn those observations into a personal field journal.

Built for the Hacktoberfest 2026 Open-Source AI Challenge, Week 1: Touch Grass.

Live Demo · Source Code

Khoj doesn't tell you where to go. It gives you reasons to look around.

See Khoj in Action

The following screenshots show the application and its exploration experience.

How It Works

Choose: Select an exploration duration and an interest.
Discover: Receive a mission with prompts that encourage curiosity about your surroundings.
Explore: Head outside and record observations and notes.
…

View on GitHub

How I Built It

The project uses:

Python and FastAPI for the backend.
React, Vite and Tailwind CSS for the frontend.
SQLite for data storage.
Ollama with Gemma 3 (4B) for locally running open-weight AI.
Curated city information and validation mechanisms to keep generated missions grounded.

The local AI integration generates structured exploration missions. The backend validates the generated output and provides curated fallbacks when needed.

The application also incorporates offline-first functionality, allowing users to preserve their exploration progress and journal entries without depending on continuous internet connectivity.

Why Does Open Innovation Matter?

For Khoj, open innovation is about ownership, accessibility and control.

Using an open-weight model through Ollama means I can experiment with local inference rather than making a closed AI API the only way to power the application.

It also gives me the flexibility to experiment with different models, control how prompts and outputs are handled, and keep local AI processing on the user's machine.

The offline-first architecture complements this approach by allowing exploration and journaling to continue even when connectivity is unreliable.

I particularly like that these ideas can work together: local AI experimentation, open-source software and an application that does not have to depend entirely on a hosted service.

The Spirit of It

Sometimes we become so occupied with screens that we forget to notice the world around us.

Khoj was built around a small idea: technology should occasionally encourage us to disconnect, explore, observe and reconnect with our surroundings.

Not every meaningful discovery needs to come from a search engine. Sometimes, it starts with simply stepping outside.

Thanks for checking out Khoj!

I Built SlothBank Using Gemma 3 and Mastra to Catch Unexpected Bills with AI 🦥

Shanaya Carvalho — Mon, 26 Oct 2026 00:03:43 +0000

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

SlothBank: Let the AI Read the Bill. Let Code Check the Numbers. 🦥

Bills are easy to ignore until something changes.

A subscription becomes more expensive. An insurance premium increases. An internet bill arrives with a charge that looks slightly different from last month. Individually, these changes can seem small. Finding them means opening bills, comparing amounts, checking historical records, and deciding whether something deserves attention.

I built SlothBank, a local-first AI bill-monitoring project that helps make that process less tedious.

The idea is simple: let AI handle the repetitive reading, let deterministic code check the numbers, and let a human make the final decision.

What I Built

SlothBank is an AI-assisted bill-monitoring prototype designed to help people review recurring bills, identify unusual changes, and prepare follow-up emails without handing the final decision over to an AI model.

The workflow brings together:

Bill extraction: Use an open-weight language model to extract structured information from bills.
Validation: Check extracted data and financial relationships with deterministic code rather than trusting model output blindly.
Anomaly detection: Compare bill amounts with historical expectations and flag unusual differences for review.
Forecasting: Estimate upcoming expenses using a baseline forecasting approach.
Human-reviewed follow-up: Prepare draft emails that users can inspect and edit before sending.
Dashboard: Bring the results together in one place so users can review their bills and potential anomalies.

The goal isn't to declare every unusual bill incorrect. A higher charge might reflect a legitimate price change, a new service, or a different billing period. SlothBank highlights what deserves a closer look; it doesn't automatically accuse a provider of making an error.

How the workflow fits together

Bills / Historical Records
          |
          v
  Gemma 3 4B via Ollama
          |
          v
  Structured Extraction
          |
          v
  Deterministic Validation
          |
          v
  Anomaly Detection + Forecasting
          |
          v
     Dashboard
          |
          v
  Human-Reviewed Email Drafts

Testing what the model actually gets right

I didn't want to rely on a demo that merely looked convincing. I also evaluated extraction on a small set of 20 synthetic bills.

Metric	Single-shot run	Validation-enabled run
Merchant exact-match accuracy	80%	85%
Billing-date accuracy	95%	100%
Total-due accuracy	95%	100%
Line-item accuracy	95%	100%
All fields exactly correct	80% (16/20)	85% (17/20)
Failed validations	1	0

The all-field exact-match result increased by 5 percentage points, from 16 to 17 correctly extracted bills out of 20.

These are preliminary results on a small synthetic dataset, not proof of production-level accuracy. Both runs averaged one attempt per bill, so I can't attribute the improvement to retries. The experiment does, however, reinforce why structured validation and evaluation matter when language models handle financial information.

An example of an anomaly

In one synthetic example, Shellter Home Insurance was billed $171.56, compared with an expected amount of $146.00.

Difference: $25.56
Increase: approximately 17.5%

That is a useful signal to investigate, not proof that the bill is wrong. The user still needs to inspect the original bill and determine whether the difference is justified.

Being honest about forecasting

SlothBank also experiments with forecasting upcoming expenses. In one small backtest with eight observations, the baseline model had a mean absolute error (MAE) of $13.52, while a naive last-value benchmark had an MAE of $8.01.

The baseline did not outperform that simple benchmark. I am keeping that result visible rather than presenting forecasting as a solved problem. A meaningful next step is to improve the evaluation, compare suitable models, and establish when a more complex approach is actually worthwhile.

SlothBank in Action

The extraction evaluation below uses a separate fixed set of 20 synthetic bills; the bill count shown in the live dashboard reflects its current demo dataset.

Dashboard Overview

The dashboard brings spending history, merchant-level forecasts, and a concise summary into one place.

![SlothBank dashboard overview]

raw.githubusercontent.com

Anomaly Review

Unusual amounts are highlighted for investigation. An anomaly is a signal to review the bill, not proof that the provider made a mistake.

![SlothBank anomaly review]

raw.githubusercontent.com

Expense Forecasting

Merchant-level estimates help users understand expected upcoming expenses. These forecasts are experimental and should be interpreted alongside their evaluation results.

![SlothBank expense forecasting]

raw.githubusercontent.com

Demo

Live demo: SlothBank

The deployed public demo presents synthetic example data in read-only mode. Audit execution is disabled in this mode, allowing visitors to explore the example output without triggering the local processing workflow.

Screenshots: View the evidence folder on GitHub

Code

GitHub repository: [Slothbank]

Shanaya31 / slothbank

A local-first AI bill monitoring prototype with cost forecasting, anomaly explanations, and human-reviewed email drafts.

SlothBank — Slow and Steady

SlothBank is a local-first bill-monitoring prototype that tracks spending, estimates future costs, flags unusual bills, explains line-item changes, and drafts emails for human review.

Demo-data notice: Included bills and ground truth are synthetic. Forecasts and anomaly flags are estimates, not proof of overcharging. Draft emails are never sent automatically.

Screenshots

These screenshots show the local dashboard using the project's synthetic sample data.

Anomaly review

Forecasts and spending history

How it works

Bills enter the local processing workflow.
Mastra orchestrates bill processing and weekly audits.
A forecasting engine estimates costs and checks for unusual bills.
Explanations, email drafts, and a deterministic digest are generated.
The local interface displays the latest report.

The project supports a baseline forecaster and a TabPFN integration. Real model behavior depends on local configuration and dependencies.

Requirements

Node.js compatible with the installed dependencies. The current dependency set calls for Node.js 22.22.0 or…

View on GitHub

The repository contains the project implementation, including the application server, dashboard, local processing workflow, and supporting evaluation work.

How I Built It

SlothBank combines open-weight AI with conventional software components. Each part has a specific responsibility.

Gemma 3 4B: The open-weight language model used for bill-information extraction.
Ollama: Runs the model locally, avoiding a mandatory external model-inference API for the local workflow.
Mastra: Supports the AI workflow and orchestration.
TypeScript and Node.js: Power the application server and connect the components.
Python: Supports the forecasting and data-processing work.
JSON: Stores structured reports and makes the results available to the dashboard.
Render: Hosts the public, read-only demo using synthetic example data.

The local application and hosted demo have different responsibilities. The local workflow can use local processing and reports, while the hosted demo is designed to present a fixed synthetic example without exposing personal bills or enabling audit execution.

I deliberately kept the public demo read-only. A public URL should make it easier to understand the project, not quietly turn a prototype into a service that processes visitors' financial documents.

Why combine AI with deterministic code?

Language models are useful for interpreting semi-structured documents, but plausible output isn't necessarily correct output.

A model can extract the wrong amount, miss a field, or misinterpret a line item. SlothBank therefore separates extraction from validation: the model helps interpret the document, while code checks structured values and flags issues for review.

This separation is important in financial workflows, where an answer that sounds confident can still be wrong.

Why Does Open Innovation Matter?

Financial documents—utility bills, insurance statements, and subscription invoices—can reveal a lot about a person's life. They contain amounts, billing histories, service details, and sometimes sensitive account information. I wanted to explore how AI could make reviewing these documents easier without making a third-party commercial model API a requirement for the local workflow.

Open innovation gave me the flexibility to build around that idea.

More control over privacy: SlothBank uses Google's open-weight Gemma 3 4B model through Ollama for local inference. In the local workflow, documents can be processed on the user's own machine rather than automatically being sent to a hosted model API. That offers greater control over sensitive data, although privacy still depends on how the entire application handles files, logs, and storage.
Fewer dependencies on per-token API pricing: Running an open-weight model locally can avoid per-request inference charges from a commercial model provider. It isn't entirely cost-free—hardware, electricity, and maintenance still matter—but it makes experimentation and repeated local testing more accessible.
Freedom to inspect, evaluate, and improve: With Gemma 3, Mastra, and the surrounding application code, I could experiment with structured extraction, add deterministic validation, and measure the results instead of simply trusting a model's output. My small synthetic-bill evaluation also showed why this matters: a model's output needs to be checked, not just accepted because it looks plausible.
A practical path to sharing the project: Render provides a way to make a public demo accessible without asking everyone to set up the entire development environment. SlothBank's hosted demo uses synthetic example data and read-only interactions, keeping it separate from the local bill-processing workflow.

For me, open innovation isn't just about using an open-weight model. It's about having the freedom to experiment, understand limitations, evaluate results, and design the safeguards around the technology.

The principle behind SlothBank is simple: let AI handle the repetitive work, let code check the numbers, and keep people in control of financial decisions.

The Lazy Payoff

The hoped-for payoff is straightforward: less repetitive bill reading, less manual comparison, and an easier way to identify which charges deserve attention.

SlothBank brings extraction, historical comparison, anomaly flags, forecasting, and email drafting into one workflow. Instead of starting every review from scratch, a user can begin with a structured summary and investigate the exceptions.

I haven't measured real-world time savings yet, so I won't claim a specific number of minutes saved. The current work demonstrates the workflow and its early evaluation results; measuring time saved against a manual review process is a valuable next step.

The principle is automate the tedious parts, keep the important decisions human.

Prize Categories

Best Use of Gemma — SlothBank uses Google's open-weight Gemma 3 4B model through Ollama for local bill-information extraction, supported by structured validation and evaluation.
Best Use of Mastra — Mastra is part of the AI workflow used to connect the model-assisted processing with the wider application.
Best Use of Render — SlothBank has a deployed public demo that presents synthetic example data in read-only mode. The local bill-processing workflow remains separate from the hosted demo.

What's Next?

SlothBank is a prototype, and there is more work to do:

Evaluate extraction against a larger and more diverse set of bills.
Improve source-level traceability so a user can connect extracted fields to the relevant region of the original document.
Compare forecasting models against appropriate simple baselines.
Test anomaly detection on legitimate price changes as well as unusual charges.
Improve the public demo while keeping it synthetic and read-only.

The most important lesson so far is that useful AI isn't just about getting a model to produce an answer. It's about checking that answer, measuring its limitations, and designing the workflow so a person can make an informed decision.

Thanks for reading, and happy Hacktoberfest! 🦥

devchallenge #hf26challenge

I Built InvoiceLens for a Friend’s Handmade Tote Bag & T-Shirt Business Using AI

Shanaya Carvalho — Sat, 24 Oct 2026 20:07:09 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Sometimes, the best project ideas don't come from brainstorming sessions or trying to use the latest technology. They come from noticing a problem someone close to you deals with every day.

For this challenge, I built InvoiceLens for a friend who runs a small online business selling handmade tote bags and custom-printed T-shirts.

Running a small business means juggling a lot of things at once: managing orders, keeping track of expenses, handling suppliers, and making sure the paperwork doesn't pile up. Invoices and receipts are part of that work, but manually reviewing them and entering their details into spreadsheets can be tedious, especially when you're already busy running the business.

I wanted to explore whether AI could make that process a little easier.

InvoiceLens is an invoice and receipt assistant designed to extract key information from documents and make it easier to review and organize the results.

The project focuses on extracting details such as vendor information, invoice numbers, dates, subtotals, taxes, and totals. It also includes validation checks to flag arithmetic inconsistencies and allows extracted records to be reviewed and edited before being exported to CSV.

One thing I wanted to get right was that AI output shouldn't automatically be treated as correct. A model might read an invoice incorrectly, misinterpret a tax amount, or return an inconsistent total. InvoiceLens separates extraction from validation so that potential problems can be flagged for human review rather than silently accepted.

I built this as a prototype inspired by my friend's business needs, with the goal of exploring a more manageable invoice workflow for small businesses.

This project reminded me that building for someone means thinking beyond whether the code works. It also means understanding the person's workflow, the mistakes that matter, and where automation should leave room for human judgment.

Demo

Live demo: Try InvoiceLens

A note about the demo: The hosted version currently uses mock extraction, so it does not run the Gemma model on uploaded documents. The local version integrates Gemma 3 4B through Ollama for local inference. The hosted demo is useful for exploring the interface and workflow, but its output should not be interpreted as actual AI extraction from your uploaded invoice.

Code

The project is open source!

GitHub repository:

Shanaya31 / InvoiceLens

InvoiceLens

Your invoices stay yours.

A local-first assistant that turns invoice and receipt images and PDFs into structured, editable records with validation warnings and a reviewed CSV export. Built for Indian freelancers, small businesses and small CA practices. Extraction runs on your own machine with an open-weight model (Gemma 3 4B through Ollama), with Tesseract OCR as a fallback.

Status: working scaffold. The full pipeline runs end to end and is covered by automated tests that use a fake model. It has not yet been measured against real model output; no accuracy claim is made anywhere in this repository. See Evaluation.

What it does

Upload JPG, PNG or PDF files (10 MB each, PDFs up to 5 pages).
Extract vendor, GSTIN, invoice number, date, subtotal, discount, CGST/SGST/IGST and total with Gemma vision. If the answer is unusable, run Tesseract and retry the model once.
Validate in Python (never…

View on GitHub

Feel free to explore the implementation, suggest improvements, or build on the idea.

How I Built It

InvoiceLens combines an AI extraction workflow with a separate validation and review process.

The main technologies I used were:

Gemma 3 4B via Ollama: An open-weight model used in the local version for invoice and receipt extraction.
FastAPI: The Python backend for handling document-processing requests and application logic.
React, Vite, and JavaScript: The frontend for uploading documents, reviewing extracted fields, and working with records.
Python validation logic: Deterministic checks that compare extracted numerical values and flag inconsistencies.
CSV export: Allows reviewed information to be moved into a spreadsheet-based workflow.

One of the most useful lessons from building InvoiceLens was understanding the difference between extracting information and verifying it.

During testing with a synthetic invoice, the model correctly identified the subtotal and individual tax amounts but reported the total tax as ₹11,800 instead of ₹1,800. Rather than trusting the model's output, the validation logic flagged the inconsistency.

That example reinforced an important design principle for me: AI should assist with repetitive work, but it shouldn't remove the user's ability to question, correct, and verify the result.

InvoiceLens is still a prototype. Model extraction can be inaccurate, the validation rules cannot detect every possible mistake, and the current hosted demo does not perform real model inference. It isn't a replacement for accounting software or professional tax review.

Why Does Open Innovation Matter?

Open innovation made it possible for me to experiment with a local, open-weight model rather than building the entire project around a proprietary AI API.

Using Gemma 3 4B through Ollama gave me a way to explore local inference, inspect the model's behavior, and build the surrounding validation logic myself. It also gave me more control over how the local processing workflow is configured.

For a tool intended to handle financial documents, the ability to explore local processing is particularly interesting. It creates an opportunity to design workflows in which documents can be processed on a user's own machine instead of automatically sending them to a remote model provider.

Of course, using an open-weight model alone doesn't guarantee privacy, accuracy, or security. Those still depend on how the application is built and deployed.

For me, open innovation means being able to experiment, understand the limitations, and adapt technology to a real problem without being locked into one provider's ecosystem.

Prize Categories

Best Use of Gemma — if this category is available for this challenge.

Gemma 3 4B is the core model explored in InvoiceLens's local extraction workflow. The project combines it with deterministic validation and human review to investigate how an open-weight model can support a practical small-business task.

Building InvoiceLens was a reminder that a meaningful project doesn't have to begin with a huge idea. Sometimes, it starts with a small problem faced by someone you know and a question: Can I build something that might make this a little easier?

That's what I set out to explore with InvoiceLens. 💚

InvoiceLens: A Local AI Assistant for Invoices That Knows When to Ask for Human Review

Shanaya Carvalho — Mon, 19 Oct 2026 04:19:40 +0000

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

What I Built

Freelancers and small businesses deal with a surprisingly tedious task: turning invoices and receipts into structured records without manually typing every field into a spreadsheet.

InvoiceLens is a local-AI invoice and receipt assistant built to make that workflow easier. Upload an invoice or receipt, extract the important fields, review the results, correct anything that looks wrong, and export the records to CSV.

It is specially designed for freelancers, independent bookkeepers, and small businesses that want to reduce repetitive data entry without sending financial documents to a third-party AI inference API.

InvoiceLens can extract fields such as vendor details, invoice number, date, subtotal, tax amounts, and total. It also runs validation checks and flags suspicious results for human review. Records can be edited before being marked as reviewed.

Human-in-the-loop verification: Tax identifiers such as GSTIN should be checked against the original invoice before records are relied upon. When a GSTIN is missing or uncertain, the user can review and complete the field manually rather than treating an incomplete extraction as verified.

The important design decision: an AI-generated value is not automatically a trustworthy value.

During a local test with a synthetic invoice, Gemma correctly read the subtotal and individual tax amounts but incorrectly reported the total tax as ₹11,800 instead of ₹1,800. InvoiceLens flagged both the tax-total mismatch and the invoice-total mismatch. It did not silently correct the model or pretend the result was accurate.

That is the kind of failure an invoice workflow needs to make visible.

The potential business model is a lightweight tool for freelancers and small accounting practices: save time on repetitive entry while keeping a person in control of financial records. I have not yet validated willingness to pay with a real customer, so this is a target use case rather than a proven business.

Demo

Video walkthrough:

The walkthrough demonstrates the invoice-processing workflow, including extracted fields, validation warnings, manual review, and CSV export.

Hosted demo limitation: The public Render version uses mock extraction and returns synthetic invoice data; it does not run Gemma. The local version integrates Gemma 3 4B through Ollama for on-device inference.

Code

GitHub repository:

Shanaya31 / InvoiceLens

InvoiceLens

Your invoices stay yours.

Status: working scaffold. The full pipeline runs end to end and is covered by automated tests that use a fake model. It has not yet been measured against real model output; no accuracy claim is made anywhere in this repository. See Evaluation.

What it does

Upload JPG, PNG or PDF files (10 MB each, PDFs up to 5 pages).
Extract vendor, GSTIN, invoice number, date, subtotal, discount, CGST/SGST/IGST and total with Gemma vision. If the answer is unusable, run Tesseract and retry the model once.
Validate in Python (never…

View on GitHub

The project includes a React/Vite frontend, a FastAPI backend, local model integration, extraction and validation logic, CSV export, and automated tests.

InvoiceLens combines:

Gemma 3 4B through Ollama: the local vision model used to extract structured fields from invoice images.
FastAPI: the backend API for document processing, record management, validation, and export.
React, Vite, and JavaScript: the interface for uploading documents, reviewing extracted fields, and editing records.
Python validation logic: arithmetic checks and review flags that operate independently of the model's claims.
CSV export: a practical bridge between the tool and the spreadsheets freelancers and bookkeepers already use.
Session-scoped records: requests are separated by session identifier, with records held in memory rather than a persistent database.

I tested the extraction workflow using synthetic invoice data and verified document uploads, record listing, manual review, CSV export, and separation between two session identifiers. The backend test suite and frontend production build also passed.

There are limitations. Model extraction can be wrong, and validation checks cannot catch every semantic error. Records are lost when the server restarts. OCR fallback is optional and was not available in my local environment because Tesseract was not installed. InvoiceLens is a working prototype, not accounting software or a guarantee of tax compliance. Extracted values still need to be checked against the source document.

Engineering for trust, not just extraction

InvoiceLens separates model-generated values from deterministic validation. The model proposes structured invoice fields; independent checks compare arithmetic relationships and flag inconsistencies for human review. Users can correct extracted values before marking records as reviewed.

The backend also separates records by session identifier and applies in-memory limits. This is a prototype-level isolation mechanism, not user authentication or a complete multi-tenant security system.

These design choices reflect the core goal of InvoiceLens: make AI-assisted data entry useful without assuming that AI-generated financial data is correct.

Why Does Open Innovation Matter?

Invoice data can contain names, addresses, tax identifiers, transaction amounts, and other sensitive business information. Sending every document to a hosted AI API introduces a third party into that workflow.

With an open-weight model running locally through Ollama, InvoiceLens can perform inference on the user's machine without requiring a paid, remote model API for the core extraction step. That gives the user more control over where document contents go and makes experimentation possible without a per-request inference bill.

Open tooling also makes the system easier to inspect and change. The extraction logic, validation rules, prompts, and review workflow can be modified for different invoice formats or business needs. The model is replaceable, and the validation layer can be tested independently.

Local inference is not magic: it still needs compatible hardware, and model errors remain possible. That's why the project combines local extraction with explicit validation and human review rather than treating a fluent model response as ground truth.

For a small side hustle, the goal is simple: make repetitive work less tedious without making private data or blind trust in AI the price of convenience.

Prize Categories

Best Use of Gemma — Gemma 3 4B is used as the core local vision model for invoice extraction.

Khoj: Step Outside With a Question, Come Back With a Story

Shanaya Carvalho — Mon, 12 Oct 2026 01:36:15 +0000

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

Khoj (खोज) — Don't Follow the Map. Follow Your Curiosity.

What I Built

What if your phone gave you a reason to explore your city instead of another reason to stare at a screen?

We pass the same streets, buildings, markets, and waterfronts every day. We use maps to get from one place to another, but how often do we stop to notice the world around us?

I built Khoj (खोज, "search" or "discovery"), an open-source, offline-first AI exploration companion that turns a walk around your city into a curiosity-driven adventure.

Starting with Mumbai, Khoj encourages people to step outside, observe their surroundings, and discover something new through short, guided exploration missions. Instead of simply telling you where to go, it gives you a reason to pay attention once you get there.

With Khoj, you can:

🧭 Choose an exploration duration and area of interest.
🌿 Get a curiosity-driven mission grounded in a curated Mumbai city knowledge pack.
👀 Explore the real world and record your own observations, notes, and discoveries.
📓 Turn those observations into a personal field journal.
📶 Keep using the cached app when connectivity is unreliable.

The idea is simple: the phone gives you a question. The city gives you the answer.

The goal isn't to keep people chatting with an AI. It's to use AI to give them a reason to leave the screen.

How a Khoj Exploration Works

1. Start with curiosity

Choose an area of Mumbai and decide how much time you want to spend exploring. The experience is built around a manageable mission rather than a rigid itinerary.

2. Receive a mission

Khoj uses curated city knowledge to generate or select a mission that encourages you to notice something about your surroundings. The aim is to make an ordinary walk feel like an opportunity for discovery.

3. Look up from the screen

This is the most important part. Put the phone away, look around, and pay attention to details you might otherwise miss. When something catches your attention, record it in Khoj.

4. Keep what you discovered

Your observations become the foundation for a personal field journal. Khoj turns what you've recorded into a reflection without presenting unobserved details as facts about your experience.

The mission provides direction. You provide the curiosity.

A mission, start to finish

Mission: [paste a real mission Khoj gave you]

What I noticed: [2–3 real observations from your walk]

Journal entry: [an excerpt of the journal Khoj produced from those observations]

Demo

[One line on what the video shows, e.g. "A local Gemma-generated mission, the validation step, an observation, and the journal."]

Live demo: Try Khoj on Render

GitHub repository: [Shanaya31/Khoj]

Shanaya31 / Khoj

Open-source, offline-first AI exploration companion that turns city walks into curiosity-driven missions and a personal field journal.

Khoj (खोज)

Don't follow the map. Follow your curiosity.

Built for the Hacktoberfest 2026 Open-Source AI Challenge, Week 1: Touch Grass.

Live Demo · Source Code

Khoj doesn't tell you where to go. It gives you reasons to look around.

See Khoj in Action

The following screenshots show the application and its exploration experience.

How It Works

Choose: Select an exploration duration and an interest.
Discover: Receive a mission with prompts that encourage curiosity about your surroundings.
Explore: Head outside and record observations and notes.
…

View on GitHub

An important distinction: The hosted demo does not run Gemma inference. It uses the curated fallback experience. Local Gemma inference is supported when running Khoj with Ollama configured, and the video above shows it.

I tested Khoj's offline behaviour using Chrome DevTools' Offline network setting. After the application had been cached, I could refresh the page and still access the field journal, including the observation saved on the device.

The screenshot below shows the application remaining accessible while the browser is offline. Some network requests fail as expected, but the cached interface and locally saved observation remain visible.

![Khoj working offline in Chrome DevTools]

For the best offline experience, open the app while online first so its app shell and required assets can be cached. Locally saved observations are stored on the device and are not automatically synced to the server.

How I Built It

I built Khoj around a simple principle: AI should help people engage with the real world, not give them another reason to stay online.

USER: Choose duration + area of interest
                  |
                  v
+-------------------------------------------+
| React + Vite + Tailwind                   |
| Service worker: cache app shell/assets    |
| Browser storage: session + observations   |
+----------------------+--------------------+
                       | API request
                       v
+-------------------------------------------+
| FastAPI Backend                           |
| Curated Mumbai city knowledge pack        |
| Mission prompt + grounding rules          |
+----------------------+--------------------+
                       |
                       v
+-------------------------------------------+
| Mission Generation                        |
|                                           |
| LOCAL: Gemma 3 4B via Ollama              |
| HOSTED: Curated fallback (Render)         |
+----------------------+--------------------+
                       |
                       v
+-------------------------------------------+
| Validation / Fallback                     |
| Check generated mission against rules     |
| Use curated mission when needed           |
+----------------------+--------------------+
                       |
                       v
+-------------------------------------------+
| Frontend displays mission                 |
|                                           |
| Field Journal                             |
| Observations saved in browser storage     |
| Reflection based on saved observations    |
| Cached app + local data available offline |
+-------------------------------------------+

A lightweight, open-source stack

Frontend: React, Vite, and Tailwind CSS
Backend: Python and FastAPI
Storage: SQLite and browser-side storage
AI: Gemma 3 4B through Ollama for local inference
Offline support: Service worker caching and locally available city data
Deployment: Docker and Render

Grounding AI in a real city

Generative AI can produce convincing text, but a convincing mission isn't useful if it sends someone to the wrong place.

Khoj uses a curated Mumbai city knowledge pack to ground missions in known places and local context. Generated output is validated, and unsupported place or fact references are removed or handled through curated fallback behaviour. [Add one concrete example of what the validator catches, e.g. "a place name that isn't in the city pack."]

I also refined the mission-generation prompts to reduce irrelevant locations and keep missions aligned with the selected area and duration. [Optional: add one before/after example.]

The principle is straightforward: AI can help shape the experience, but it shouldn't invent the map.

Local Gemma, with a fallback path

Khoj supports Gemma 3 4B through Ollama for local mission generation. The model receives city context to help generate relevant exploration missions.

When generation is unavailable or produces unusable output, Khoj falls back to a curated mission, so the app still works. These are separate execution modes: local inference requires Ollama and the model to be available, while the hosted demo currently uses the fallback experience.

Offline-first exploration

Connectivity isn't always reliable, especially when you're out exploring.

Khoj uses service worker caching for the app shell and static assets, alongside browser-side persistence for the active exploration session and observations. I tested the cached experience by switching the browser offline and refreshing the application, so the essential exploration flow stays resilient when the network doesn't cooperate.

Reflections grounded in real observations

An AI-generated journal can sound polished while quietly adding things a user never experienced. For an exploration companion, that defeats the purpose.

Khoj's reflection flow is designed to use the observations a person has saved as its source of truth. The intention is to help users reflect on what they noticed, rather than inventing a more interesting story on their behalf.

During development, I tested the backend, frontend build, and automated tests, and refined the generation and validation logic to improve reliability.

Why Does Open Innovation Matter?

No mandatory hosted API. Running the open-weight Gemma model through Ollama means mission generation doesn't have to depend on a paid, remote service. That matters for a project meant to work wherever you are.
Everything can be inspected. Because the whole stack is open, I could see and change how missions are generated, why one is accepted or rejected, and how data is stored. That made it possible to tighten grounding when the model invented details.
Resilience. Cached data and curated fallback missions keep the experience useful when generation or connectivity isn't available.
A city is just data. A knowledge pack is separate from the model, so anyone can add their own city without retraining anything. A longer-term direction is a community-built collection of city packs.

For me, open innovation isn't only about making the code available. It's about giving people the freedom to understand, adapt, and build on the ideas behind a project.

Current Limitations

The hosted demo runs in curated-fallback mode; Gemma needs a machine with Ollama, so the AI part currently lives on a laptop, not a phone.
Only Mumbai is supported right now.
Observations are saved on the device and are not synced.

What I Learned

Building Khoj reinforced a lesson about AI products: generating text is easy compared with generating something genuinely useful.

The difficult parts include keeping missions grounded in real geography, making short explorations realistic, handling model failures, preserving observations, and making sure reflections don't claim more than users actually recorded. Those constraints shape whether the product deserves the user's trust.

For Khoj, a smaller, grounded mission is better than an impressive-sounding one that sends someone to the wrong neighbourhood.

Prize Categories

Overall Winner: Turns city exploration into curiosity-driven missions, with an offline-first design that sends people out of the app and into the city.
Best Use of Gemma: Gemma 3 4B through Ollama generates missions locally, with curated Mumbai data, grounding rules, validation, and fallback keeping them tied to real places.
Best Use of Render: The live demo is deployed on Render (running curated fallback missions; local Gemma is supported through Ollama).

Final Thoughts

Khoj started with a simple question: can AI help us pay more attention to the world instead of keeping us glued to a screen?

I built it as a small step toward making everyday exploration more intentional: one area, one mission, and one observation at a time.

Khoj isn't about seeing more of your phone. It's about seeing more of your city. 🌿🏙️

What's something in your city you walk past every day and have never really looked at?

DEV Community: Shanaya Carvalho

Khoj: A Little AI Companion That Helps You Rediscover the World

What I Built

Demo

Code

Shanaya31 / Khoj

Open-source, offline-first AI exploration companion that turns city walks into curiosity-driven missions and a personal field journal.

Khoj (खोज)

Table of Contents

See Khoj in Action

How It Works

How I Built It

Why Does Open Innovation Matter?

The Spirit of It

I Built SlothBank Using Gemma 3 and Mastra to Catch Unexpected Bills with AI 🦥

SlothBank: Let the AI Read the Bill. Let Code Check the Numbers. 🦥

What I Built

How the workflow fits together

Testing what the model actually gets right

An example of an anomaly

Being honest about forecasting

SlothBank in Action

Dashboard Overview

Anomaly Review

Expense Forecasting

Demo

Code

Shanaya31 / slothbank

A local-first AI bill monitoring prototype with cost forecasting, anomaly explanations, and human-reviewed email drafts.

SlothBank — Slow and Steady

Screenshots

Anomaly review

Forecasts and spending history

How it works

Requirements

How I Built It

Why combine AI with deterministic code?

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

What's Next?

devchallenge #hf26challenge

I Built InvoiceLens for a Friend’s Handmade Tote Bag & T-Shirt Business Using AI

What I Built

Demo

Code

Shanaya31 / InvoiceLens

InvoiceLens

What it does

How I Built It

Why Does Open Innovation Matter?

Prize Categories

InvoiceLens: A Local AI Assistant for Invoices That Knows When to Ask for Human Review

What I Built

Demo

Code

Shanaya31 / InvoiceLens

InvoiceLens

What it does

Engineering for trust, not just extraction

Why Does Open Innovation Matter?

Prize Categories

Khoj: Step Outside With a Question, Come Back With a Story

Khoj (खोज) — Don't Follow the Map. Follow Your Curiosity.

What I Built

How a Khoj Exploration Works

1. Start with curiosity

2. Receive a mission

3. Look up from the screen

4. Keep what you discovered

A mission, start to finish

Demo

Shanaya31 / Khoj

Open-source, offline-first AI exploration companion that turns city walks into curiosity-driven missions and a personal field journal.

Khoj (खोज)

Table of Contents

See Khoj in Action

How It Works

How I Built It

A lightweight, open-source stack