DEV Community: Nilesh H. Thipe

How I Choose AI Models for Different Tasks (And Why I Don't Stick to Just One)

Nilesh H. Thipe — Fri, 06 Nov 2026 12:27:25 +0000

AI tools are becoming part of our everyday workflow. Whether it's learning something new, writing code, researching a topic, or building a project, there is an AI tool for almost everything.

But one question I often ask myself is: Should I use the same AI model for every task?

After experimenting with ChatGPT, Gemini, Claude, DeepSeek, Grok, and Perplexity, I've realised that I don't need one model that does everything. I need the right tool for the task I'm working on.

Here's how I approach that decision.

1. I Don't Look for One Perfect AI Model

As a student, developer, and everyday AI user, I use AI for quite different things:

Learning difficult concepts.
Writing and debugging code.
Building applications and hackathon projects.
Researching technical topics.
Writing blogs and documentation.
Generating images and videos.
Quick troubleshooting and everyday questions.

Naturally, I don't expect one model to be equally useful for everything.

Instead of asking which model is the best, I ask:

Which model or tool can handle my current task better?

2. My Task-to-Tool Approach

Here is my personal starting point when choosing AI tools.

Task	My usual choice
Learning concepts	ChatGPT
Coding and debugging	Claude
Building projects	Antigravity or Replit
Research	Perplexity
Writing	Compare different models
Image generation	ChatGPT
Video generation	Google Flow
Quick troubleshooting	ChatGPT
Everyday questions	ChatGPT or Gemini

These are my personal preferences, not universal recommendations. I still compare results when a task is important.

Also, some of these are tools or development environments rather than AI models themselves. I choose based on the complete workflow, not just the model name.

3. My AI Model Selection Scorecard

Before choosing a tool, I consider a few things:

Factor	What I check
Accuracy	Does it provide reliable answers?
Reasoning	Can it understand complicated problems?
Ease of use	Can I get the result without unnecessary effort?
Cost	Can I complete the task within my available budget?
Speed	Can it deliver results within my deadline?
Privacy	Am I comfortable sharing this information?

I don't give every factor equal importance.

For example, during a hackathon, speed and reliability become extremely important because time is limited. When learning mathematics, accuracy and clear reasoning matter much more.

The task decides the priorities.

4. Real Experiences That Changed My Approach

I've experienced several situations where switching AI tools made a noticeable difference.

Research: I once compared ChatGPT and Perplexity for research. I found Perplexity's results more useful for that particular research task.

Coding: During a hackathon project, I tried Gemini and Claude while working on code. Claude gave me a more useful result for the problem I was solving.

These experiences taught me something important: a model that works well for one task might not be my first choice for another.

I don't consider these permanent rankings. Models improve, and results can change depending on the task and prompt.

5. Your Prompt Matters More Than You Think

Choosing the right model is only half the work. How you communicate your requirements matters too.

I experienced this while creating a study planner.

My initial approach was to give a broad instruction and expect the AI to understand everything. The result wasn't detailed enough.

Instead, I started providing clearer requirements.

Weak prompt:

Create a study planner for me.

Improved prompt:

Create a weekly study planner for a college student. Divide the schedule into college hours, academic revision, programming practice, and personal time. Include realistic study durations, short breaks, and a separate revision slot. Present the result in a clear timetable.

I also use this approach when learning mathematics.

Instead of asking for a complete explanation in one vague prompt, I specify that I want one topic explained fully, with a simple example, and then move to the next topic separately.

The result is usually much easier to follow.

6. Common Mistakes When Choosing AI Models

Here are a few mistakes I think beginners should avoid:

Following popularity: A popular model isn't automatically the best choice for your task.
Using only one model: Different tools have different strengths.
Ignoring the prompt: Even a capable model can produce a weak answer when instructions are unclear.
Trusting everything: Always verify important information, especially technical and factual answers.
Ignoring limitations: Cost, privacy, speed, and context limits matter.
Comparing without a purpose: Test models using the same task and requirements instead of comparing random answers.

7. Final Thoughts

I don't think choosing an AI model should be about finding one permanent winner.

My approach is simple: understand the task, identify what matters most, choose a suitable tool, and compare the results when necessary.

You don't have to use every new AI model that launches. Experiment with a few, understand their strengths, and build your own workflow.

The goal isn't to use more AI tools. It's to get better results with the right ones.

What about you?

Do you stick to one AI model, or do you switch between ChatGPT, Claude, Gemini, Perplexity, and other tools depending on the task?

I'd love to hear how you choose your AI tools!

Aayojan Ace: Building an AI-Powered Event Planner That Adapts When Plans Change

Nilesh H. Thipe — Wed, 28 Oct 2026 08:19:11 +0000

Planning a celebration should be about creating memories. But behind every wedding, birthday, or community event is a long list of decisions involving budgets, guests, vendors, deadlines, and last-minute changes.

What happens when the budget changes halfway through planning? What if the guest count increases or the event date moves? A plan that looked perfect yesterday can quickly become difficult to manage.

That was the problem I wanted to explore while building Aayojan Ace, an AI-powered celebration and event planning assistant developed for PromptWars Virtual Challenge 5: Celebration & Event Planner.

🎥 Watch the project demo: https://youtu.be/uXINb5E6vwg

🌐 Live Demo: https://ayojan-ace.vercel.app/

💻 GitHub Repository: https://github.com/nilesh0199/ayojan_ace_promptwars_virtual_challenge5
The Problem I Wanted to Solve
Event planning involves several connected parts:

Managing a budget across different categories
Organizing tasks and deadlines
Coordinating vendors and bookings
Creating ideas that match the event's style and cultural requirements
Identifying potential risks before they become problems These things don't work independently. Increasing the guest count can affect catering costs, seating arrangements, and the overall budget. Changing the event date can affect deadlines and the order in which tasks need to be completed.

I wanted to build something that could help users manage these connected decisions instead of simply generating a generic event checklist.
Introducing Aayojan Ace
Aayojan Ace turns a user's event requirements into a structured celebration plan.

Users provide details such as the event type, location, date, guest count, budget, preferred style, and important requirements. The application then generates a plan with budget estimates, a timeline, vendor checklists, personalized ideas, and operational risk considerations.

It supports weddings, birthdays, and community gatherings, including culturally relevant presets such as Indian weddings, Griha Pravesh, Diwali community gatherings, and college annual festivals.

The goal is simple: help users move from an idea to a plan they can actually work with.
Key Features

AI-Powered Event Planning Users shouldn't have to answer an overwhelming number of questions before getting started.

Aayojan Ace uses Google Gemini to generate personalized event plans based on the information provided. When important details are missing or contradictory, the application can ask adaptive clarification questions before generating the plan.

This helps make the resulting plan more relevant to the user's requirements.

Budget-Aware Replanning This is one of the most important parts of the project.

Imagine planning a celebration with a fixed budget, only to discover that you need to accommodate more guests. Simply generating a new plan isn't enough. You also need to understand what changed and what those changes mean.

Aayojan Ace supports budget-aware replanning. When users change the budget, guest count, event date, or a category allocation, Gemini can generate proposed adjustments to the affected parts of the plan.

The application presents a before-and-after comparison, explains why the changes are suggested, and provides trade-off options. Users can accept or reject the proposed changes, with an undoable version history.

The intention is to make AI-assisted planning more transparent, rather than silently replacing an existing plan.

Interactive Timelines With Assigned Owners A plan is only useful when people know what needs to happen and when.

The timeline organizes milestones into phases:

Now
Next 7 days
Next 30 days
Event week
Event day Each milestone includes a due date, an assigned owner or assignee, a linked budget category, and an interactive completion checkbox.

I also added timeline date reflow, which helps adjust milestone dates when the event schedule changes. Users can export the timeline as an .ics calendar file for use with compatible calendar applications.

Adding assignees makes the timeline more useful for coordination because tasks have a visible owner instead of being just another item on a checklist.

Vendor Checklists Finding a vendor is only one part of the process. Users also need to track conversations, quotations, bookings, and contracts.

Aayojan Ace includes vendor screening checklists with statuses such as shortlisted, contacted, quoted, booked, and contract received.

An important design decision here is to avoid presenting invented vendor details as real recommendations. The application focuses on vendor categories and useful screening questions, encouraging users to verify prices, availability, and agreements directly with vendors.

Personalized Celebration Ideas Different celebrations have different cultural, dietary, and practical requirements.

The personalized ideas section helps generate concepts tailored to the user's preferences, including decoration ideas, menus, cultural elements, and guest activities.

The aim is to make the plan feel relevant to the celebration instead of returning the same generic suggestions for every event.

Operational Risk Assessment A successful event also depends on anticipating potential problems.

Aayojan Ace includes a risk assessment workflow covering considerations such as seasonal weather, permit requirements, dietary cross-contamination, payment milestones, and dependencies that could disrupt the event.

The application helps surface these considerations so users can investigate them and plan appropriate mitigations.

These assessments are planning assistance, not a substitute for verifying local regulations, vendor commitments, or other real-world requirements.
How I Used Google Gemini
Google Gemini is the core generative AI service in Aayojan Ace.

Rather than using a single prompt for every operation, the application separates AI workflows according to their purpose:

Plan generation: Produces the initial event plan, including budget categories, timeline tasks, vendor types, and personalized ideas.
Adaptive clarification: Identifies missing or contradictory information and asks focused follow-up questions.
Budget-aware replanning: Proposes targeted changes when event requirements change.
Operational risk assessment: Identifies potential risks and suggests mitigations. The application uses the official @google/genai SDK through server-side route handlers. Generated responses are validated against Zod schemas before being used by the application.

This separation makes the different workflows easier to reason about and helps keep generated data aligned with the application's expected structure.

AI output still needs validation and real-world verification. Budget estimates are planning estimates, not guaranteed vendor quotations.
The Technology Behind the Project
Here are the main technologies used in Aayojan Ace:

Next.js and React: Application interface and server-side API routes
TypeScript: Type safety across the codebase
Google Gemini API: AI-powered planning, clarification, replanning, and risk assessment
Zod: Structured validation of generated data
Firebase Authentication: Google sign-in
Cloud Firestore: Storage for users' saved plans
Vercel: Application deployment
Google Antigravity: AI-powered development environment used to build and iterate on the application The application separates user interface components, business logic, and network operations. This keeps planning calculations and other reusable logic separate from the presentation layer. Building With Google Antigravity Aayojan Ace was built as part of PromptWars Virtual Challenge 5, where Google Antigravity is a required part of the challenge.

I used Antigravity as an AI-powered development assistant while building and refining the application, testing workflows, and iterating on the implementation.

One of the things I wanted to focus on was not just getting an AI-generated plan on the screen, but building a complete workflow around it: structured data, budget calculations, editable timelines, proposed changes, and clear user controls.

That distinction matters when working with AI-powered applications. Generating a plausible response is one thing; making that response useful inside a working product requires additional application logic and validation.
What I Learned
Building Aayojan Ace reinforced a few important lessons for me.

AI features need a well-designed workflow.

A model can generate useful content, but the surrounding application determines how that content is validated, presented, edited, and used.

Changes should be understandable, not just automatic.

When a plan changes, showing what changed and why helps users make informed decisions. Providing the option to accept or reject proposed changes also keeps the user in control.

Real-world problems are connected systems.

A change to the event date, guest count, or budget can affect multiple parts of a plan. Building around those relationships is more useful than treating every feature as an isolated screen.

Small coordination details matter.

Features such as task assignees, completion tracking, and calendar export may not look as impressive as AI generation, but they help turn a generated plan into something people can use.
Try Aayojan Ace
Want to see the application in action?

🎥 YouTube Demo: https://youtu.be/uXINb5E6vwg

🌐 Live Application: https://ayojan-ace.vercel.app/

💻 Source Code: https://github.com/nilesh0199/ayojan_ace_promptwars_virtual_challenge5

I'd love to hear your thoughts. If you were building an AI-powered event planner, what would you prioritize: smarter budget adjustments, better task coordination, or more personalized recommendations?

A sincere thank you to Hack2Skill and Google for Developers for organizing PromptWars Virtual and providing builders with an opportunity to experiment, learn, and turn ideas into working applications.

Thanks for reading!

PromptWars #BuildInPublic #GoogleForDevelopers

Before You Pay for That Internship: Building OfferClara with Wispr Flow | No Hands: The Wispr Challenge by WeMakeDevs and Wispr Flow

Nilesh H. Thipe — Sun, 25 Oct 2026 18:19:09 +0000

Imagine receiving an internship offer that looks perfect. The role sounds interesting, the stipend looks good, and the recruiter says your selection is confirmed.

Then comes one last requirement: pay a registration fee or training charge to secure your seat.

Would you pay? Would you trust the message? Or would you know what to check before replying?

For students and first-time job seekers, these situations can be difficult to judge. When you're trying to get your first internship, you might not have enough experience to recognise suspicious requests or know which details to verify.

That was the problem I wanted to work on when I started building OfferClara.

Try OfferClara

Why I chose this problem

I'm a college student myself, so this is a problem I can relate to. I've seen suspicious job offers and internship messages being shared among students, including in college group chats.

The problem isn't always that a message looks obviously fake. Sometimes it looks professional enough to make you hesitate before questioning it. A recruiter might use formal language, promise a good opportunity, or create urgency by asking you to complete everything within a short deadline.

Students may be asked for training fees, registration charges, security deposits, or sensitive identity documents before they've independently verified the opportunity.

I wanted to build something that could help people slow down and look at an offer more carefully.

Not another tool that simply declares, "This is a scam."

I wanted a tool that could show people what deserves a second look, what information is missing, and what they should verify next.

That's how OfferClara started.

What is OfferClara?

OfferClara is an AI-assisted offer review tool for students and first-time job seekers. It helps users review job and internship communications before paying money or sharing sensitive documents.

The name combines Offer with Clara, representing clarity. The idea is simple: make confusing offers easier to understand.

I wanted the experience to feel straightforward, even for someone who isn't familiar with technical terms or AI tools.

How the review works

Instead of asking users to paste a message and immediately showing them a verdict, OfferClara guides them through a structured review.

1. Add the offer

Users can paste or type the text of an offer, or upload screenshots and PDFs. The extracted text can be reviewed and edited before analysis.

2. Explain where it came from

Was the offer received through email, LinkedIn, WhatsApp, Telegram, a campus placement channel, or a job portal? Did the candidate actually apply for the role? This context can help frame the review.

3. Describe the conversation

Sometimes important details aren't written in the offer letter. A recruiter might have made a promise over a phone call or explained something during an interview. Users can describe those conversations in their own words.

4. Identify money or documents being requested

Users can record whether the recruiter asked for training fees, a security deposit, equipment charges, or sensitive identity documents.

5. Review and analyse

Before submitting, users can review the information they've entered. OfferClara then produces a structured review that highlights potential concerns, missing employment details, and questions worth asking the recruiter.

The analysis results also include a structured prompt for company research. Users can use it to investigate the company further, verify important details, and conduct their own research before deciding whether to trust an offer.

The idea is to go beyond simply flagging suspicious wording. I want users to have a practical next step: understand the concerns, investigate the employer, and verify the opportunity independently.

The goal isn't to make the decision for the user. It's to help them ask better questions before making a decision themselves.

Watch the project demo on YouTube

I wanted the tool to explain its reasoning

One design decision mattered to me: I didn't want users to receive a mysterious AI-generated score without understanding where it came from.

OfferClara connects its observations to exact quotations from the supplied text. For example, if an offer requests a training fee before the internship begins, the review can show the relevant sentence and explain why it deserves attention.

The application also separates two things that are easy to confuse:

What the offer actually says: statements and requests found in the provided text.
What the offer leaves unclear: details such as compensation, working hours, duration, or other important employment terms that may be missing.

That distinction matters. Missing information isn't automatically proof of fraud, and a professional-looking document isn't proof of legitimacy.

The implementation also validates quoted evidence against the original text before displaying it. If a model produces a quotation that doesn't match the user's input, the application can discard that finding rather than presenting it as evidence.

This is one of the most important parts of the project for me. When an AI tool is helping someone make a potentially important decision, its limitations matter just as much as its capabilities.

Where Wispr Flow changed my development workflow

This project was built for No Hands: The Wispr Challenge, organised by WeMakeDevs and Wispr Flow.

The challenge encouraged builders to use their voices for the building process: describing requirements, prompting coding tools, writing documentation, and communicating as they worked.

I decided to treat Wispr Flow as part of my regular workflow rather than something to demonstrate only at the end.

1. Speaking my development prompts

While building OfferClara, I used Wispr Flow to dictate prompts and follow-up instructions into my AI coding workflow.

When working on a feature, I often needed to explain several things together: what the interface should do, how a user should move through it, what edge cases to consider, and what shouldn't change.

Speaking those requirements felt more convenient than typing every detail manually. I could explain the intended behaviour in natural language and then review the resulting text before sending it to the coding assistant.

Wispr Flow handled the dictation. My coding tool handled implementation, and I still had to review the changes and test the application.

That distinction is important. Wispr Flow didn't build the project by itself; it changed how I communicated what I wanted to build.

2. Testing with realistic offer text

Another useful moment came during testing.

OfferClara depends on the text a user provides, so I needed to try realistic inputs rather than only neat, prepared examples. I used Wispr Flow to dictate offer text and other information directly into the application.

This helped me experience the workflow from a user's perspective: enter information, review it, correct anything necessary, and then run the analysis.

I also experimented with dictating questions into the Clear Doubt with AI feature.

It made me think more carefully about how someone might actually use the product. A person reviewing a suspicious message may want to explain a phone conversation in their own words or ask a question without carefully composing every sentence.

3. Asking friends to test the project

I also wanted other people to try OfferClara instead of relying only on my own testing.

I used Wispr Flow to draft the message inviting friends to test the application. It was a small task, but it was another practical use outside the coding environment.

Across these activities, I found voice input quicker and more convenient for me than typing everything. I was also pleasantly surprised by how accurately Wispr Flow captured what I said. I ended up using it more than I initially expected.

The biggest takeaway wasn't that speaking could replace every keyboard action. It was that I could explain a longer thought naturally, get it into the application I was using, and keep moving.

Learn more about the challenge

A few technical decisions behind OfferClara

I built OfferClara as a web application using Next.js, React, TypeScript, and Tailwind CSS. It uses Google's Gemini API for offer analysis and document text extraction, with a model fallback approach for supported AI operations. Zod validates structured model output, and Vitest is used for automated testing. The application is deployed on Vercel.

One of the more important engineering decisions was to avoid treating the language model as the final authority.

The application validates evidence in code, separates observations from missing information, and avoids assigning a numerical risk score or declaring an offer safe or fraudulent. The user sees specific concerns and verification questions instead.

I also built a Clear Doubt with AI page for follow-up questions, a command box that supports natural-language interface commands, and a help and reporting page containing official resources.

These features are intended to make the tool useful beyond a single analysis. Someone might want to understand a clause, navigate the application using a dictated command, or find out where to report a suspected scam.

Privacy needed careful thought, too

People may paste offer letters containing names, email addresses, phone numbers, or other sensitive details. I didn't want OfferClara to require an account or maintain a saved history of those documents.

The current application keeps the review session in temporary browser memory and doesn't persist offer text or uploaded files in a database. However, the text submitted for analysis is sent to the configured AI provider, so users should read the privacy notice and avoid submitting information they aren't comfortable sharing with that provider.

I think privacy explanations should be clear enough that people can make an informed choice before using a tool.

What OfferClara cannot do

Building this project also meant being clear about what it doesn't solve.

OfferClara analyses the content provided by the user. It cannot independently confirm that the recruiter is who they claim to be, authenticate an email address, verify a company's identity, or know what was said in a conversation unless the user describes it.

It can also miss unusual scam patterns or misinterpret ambiguous text. Document extraction can introduce errors, especially when screenshots are unclear. A review with no identified concerns must not be treated as proof that an offer is legitimate.

For that reason, OfferClara is a decision-support tool, not a guarantee, a background-check service, or legal advice. Users should verify offers independently through official company channels and consult official reporting resources if they suspect fraud.

I would rather make those limitations clear than promise something the tool cannot reliably deliver.

What I learned from building it

This project reminded me that building a useful tool involves more than getting an AI model to return an answer.

The workflow around that answer matters. The evidence shown to a user matters. Missing information matters. And so does making it clear when the application cannot know something.

I also learned to pay attention to the smaller parts of development: describing a feature clearly, trying realistic input, asking someone else to test it, and revisiting behaviour that doesn't feel right.

Using Wispr Flow throughout those activities made voice dictation a practical part of my process, not just a feature to mention in a hackathon submission.

There is still room to improve OfferClara. I want to expand its coverage of job-offer scenarios, improve support for different types of employment clauses, explore regional-language guidance, and continue testing the experience with more users. These are future improvements, not claims about features already completed.

Try OfferClara

If you're a student or a first-time job seeker, I hope OfferClara can help you pause, review an offer, and decide what to verify before sending money or sharing sensitive documents.

Live project: https://offerclara-wisprflow.vercel.app/

GitHub repository: https://github.com/nilesh0199/OfferClara-WisprFlow-Hackathon

Demo video: https://youtu.be/uXINb5E6vwg

Hackathon details: https://www.wemakedevs.org/wispr

Connect with me on LinkedIn: https://www.linkedin.com/in/nilesh-h-thipe-372291253/

I used Wispr Flow to dictate development prompts, enter test content, and draft messages while building and testing OfferClara. I also used AI-assisted coding tools during development and Gemini API for the application's offer analysis. I reviewed and tested the implementation as I built the project.

A special thank you to Wispr Flow for providing us with a one-month free trial of the Wispr Flow Pro plan. It gave me the opportunity to explore its features and use voice dictation throughout my development and testing workflow. Thank you to WeMakeDevs and Wispr Flow for organising this challenge and giving us the opportunity to build, experiment, and learn.

For me, OfferClara is a small attempt to use technology to help students make more informed decisions.

An AI tool doesn't need to make the final decision for someone. Sometimes, helping them notice what to question before they act is already a useful place to start.

Understand the offer. Know what to verify. Make every offer clear.

What I learned from building it

This project reminded me that building a useful tool involves more than getting an AI model to return an answer.

The workflow around that answer matters. The evidence shown to a user matters. Missing information matters. And so does making it clear when the application cannot know something.

Using Wispr Flow throughout those activities made voice dictation a practical part of my process, not just a feature to mention in a hackathon submission.

Try OfferClara

If you're a student or a first-time job seeker, I hope OfferClara can help you pause, review an offer, and decide what to verify before sending money or sharing sensitive documents.

Live project: https://offerclara-wisprflow.vercel.app/
GitHub repository: https://github.com/nilesh0199/OfferClara-WisprFlow-Hackathon
Demo video: https://youtu.be/uXINb5E6vwg
Hackathon details: https://www.wemakedevs.org/wispr
Connect with me on LinkedIn: https://www.linkedin.com/in/nilesh-h-thipe-372291253/

A big thank you to Wispr Flow and WeMakeDevs for creating this challenge and giving builders an opportunity to experiment with a voice-first workflow.

For me, OfferClara is a small attempt to use technology to help students make more informed decisions.

An AI tool doesn't need to make the final decision for someone. Sometimes, helping them notice what to question before they act is already a useful place to start.

Understand the offer. Know what to verify. Make every offer clear.

A Metro Closure Is a Graph Problem: Building MetroMarg with FalkorDB

Nilesh H. Thipe — Sun, 18 Oct 2026 16:42:06 +0000

TL;DR: MetroMarg is an AI agent that uses a FalkorDB graph of the Delhi Metro to answer one question: How did the closure of 45 stations on 9–10 October 2026 affect travel to Jantar Mantar? Each answer includes the route and the queries behind it.

Live demo: https://metromarg-graphhacks-2026.onrender.com/
Demo video: https://youtu.be/gkXa_tMcAOI (best viewed in 1080p)
Code: https://github.com/nilesh0199/MetroMarg-GraphHacks-2026
Built solo for Graph Hacks: Context for AI Agents (WeMakeDevs × FalkorDB), Track 1: Agents That Act on Connected Data.

Note on speed: responses may take a minute or more. The model can be busy, and the free hosting plan may need time to wake after inactivity.

The problem

On 9–10 October 2026, DMRC closed entry and exit at 45 Delhi Metro stations for security reasons ahead of a planned protest at Jantar Mantar. Business Today reported DMRC’s revised update; News On AIR reported that Delhi Police had proposed closures at 57 stations.

“How do I get there now?” is more than a lookup. You need to know station connections, which stations are closed, where transfers remain possible, and which open station is nearest. The answer depends on relationships—and that is what graphs represent well.

My first time with RAG, and with FalkorDB

I was new to both RAG and FalkorDB. I initially thought an AI agent needed retrieval: embed text, find similar chunks, and pass them to a model. But routes are spread across connected records, so retrieving nearby text is not enough.

Instead, I stored the connections and let the agent query them. To be precise, MetroMarg is not classic RAG or GraphRAG: it uses no embeddings or text chunks, and an LLM does not build the graph. It does share GraphRAG’s core idea of grounding answers in a graph, using fixed, human-written Cypher tools selected by the model. FalkorDB made this approach approachable for a first project.

The graph model

(:Station {name, lat, lon})-[:NEXT {line, minutes}]->(:Station)
(:Place   {name, lat, lon})-[:NEAR {walk_min}]->(:Station)
(:Closure {id, date, reason, sources})-[:CLOSES {interchange_open}]->(:Station)

DMRC’s timetable from Delhi Open Transit Data (262 stations and about 550 links) becomes Station nodes and NEXT links, with ride times from the timetable.
Jantar Mantar is a Place, connected to nearby stations with estimated walking times.
The closure is also a graph node, so routing, search, and the “why were stations closed?” panel use the same record.

The reports establish two rules: passengers could not enter or exit at closed stations, but trains continued passing through. Transfers remained possible at affected stations, except New Delhi.

The model never writes Cypher

The agent uses Gemini and chooses from five fixed, human-written tools, supplying their arguments.

Tool	What it does
`plan_trip_to_place`	Compares a ride-plus-walk trip normally and during the closure
`access_to_place`	Finds nearby stations and marks closed ones
`find_route`	Finds the fastest ride between two stations
`station_impact`	Finds stations within N hops and marks closures
`most_connected_stations`	Runs FalkorDB PageRank

Three safeguards help keep answers grounded:

Every station name is checked against the graph before a query runs. Unknown names are rejected.
The final sentence cannot name a station the tools did not return.
Each answer displays the path and queries that produced it.

The live app uses Gemini function calling. The repository also exposes the same five tools through an MCP server.

Three queries that do the real work

1. A route with a transfer rule. Trains can pass through closed stations, but transfers are allowed only where interchange remains open. This WHERE clause enforces that rule:

MATCH path = (x:Station {name: $a})-[:NEXT*1..5]->(y:Station {name: $b})
WHERE all(i IN range(0, size(relationships(path)) - 2)
          WHERE NOT (nodes(path)[i + 1].name IN $no_transfer)
             OR relationships(path)[i].line = relationships(path)[i + 1].line)
RETURN [n IN nodes(path) | n.name] AS via,
       reduce(t = 0, r IN relationships(path) | t + r.minutes) AS minutes
ORDER BY minutes
LIMIT 1

The query returns the ordered stations and total ride time, making the route itself part of the explanation.

2. The three nearest open stations, by distance:

MATCH (o:Station {name: $name}), (s:Station)
WHERE NOT (s.name IN $closed)
RETURN s.name AS station,
       distance(point({latitude: o.lat, longitude: o.lon}),
                point({latitude: s.lat, longitude: s.lon})) AS meters
ORDER BY meters
LIMIT 3

3. A built-in algorithm in three lines:

CALL algo.pageRank('Station', 'NEXT')
YIELD node, score
RETURN node.name AS station, score ORDER BY score DESC LIMIT 10

PageRank measures connectivity, not route quality. It highlighted major interchanges such as Kashmere Gate, Azadpur, and Welcome.

What the graph showed

Walking times are estimated from straight-line distance. Ride times come from the 2023 timetable.

The 12 stations nearest to Jantar Mantar—all within about 2.5 km—were among those closed to entry and exit.
The nearest open station was Chandni Chowk, about 3.5 km away. Janpath is normally about 240 m away.
From Chandni Chowk, the trip was about 17.7 minutes normally versus about 60 minutes during the closure, largely due to the long walk. Buses and taxis are not modelled, so this measures lost metro access rather than providing a travel recommendation.
Six of the 10 most connected stations by PageRank were closed.
Trips that only passed through closed stations were unaffected because trains continued running and interchange remained open.

What I liked about FalkorDB

These features stood out while I was learning:

Database plus browser UI: FalkorDB Browser helped me inspect the graph before trusting my queries.
No schema setup: the graph exists once you first write to it.
Parameterized Cypher and read-only ro_query: model text is never concatenated into a query.
Algorithms through Cypher: PageRank took three lines. Other listed options include shortest path, BFS, centrality, connected components, and community detection.
Bulk loading: I loaded the network in UNWIND batches and indexed station names.
Multiple isolated graphs: select_graph can separate graphs in one instance. I needed only one, but this could support per-user graphs.
Same code locally and in the cloud: I developed with Docker, then switched to FalkorDB Cloud by changing the host, port, and credentials.

Things that went wrong, and what I learned

Different station names: the press called one station Seva Teerth, while the 2023 timetable lists it as Udyog Bhawan. I added aliases so the name check can resolve both.
Incomplete station coverage: two of the 45 closed stations were absent because they opened after the timetable was published. The graph models 43 of 45 and states this limitation.
An empty database after restart: the app now rebuilds the graph from the timetable at startup.
“Not in the graph” is a valid answer: the agent says when it cannot verify something instead of guessing. That is more useful than always producing an answer.

Graph Hacks requirements, one by one

Requirement	How MetroMarg meets it
Solo or team of up to 4	Solo entry
FalkorDB as the primary database	Stations, links, places, and closure records live in FalkorDB; every tool queries it with Cypher
The graph does real work	Routes, transfer rules, nearest-open-station searches, and PageRank all depend on graph queries
Run FalkorDB your way	Docker locally and FalkorDB Cloud Free for the demo
Name your track	Track 1: Agents That Act on Connected Data
Use permitted data	Public data: Delhi Open Transit Data’s timetable (copied with attribution under its terms) and press reports; no personal data
Work starts after opening	Designed and built after the hackathon opened on 15 October
Frameworks and libraries allowed	FastAPI, FalkorDB Python client, Gemini API, and MCP Python SDK
Public source repository	https://github.com/nilesh0199/MetroMarg-GraphHacks-2026
README and graph data model	Included, with a diagram
Core Cypher and algorithms	Listed in a README table
Demo video	https://youtu.be/gkXa_tMcAOI
Live deployment or local setup	Both: Render deployment and local setup steps in the README
AI use disclosed	In the README, video description, and below

Limitations

The timetable is from 2023; walking times are estimates.
There is no live train data, and buses and taxis are not included.
The agent is advisory: it suggests where to get off but takes no action outside the graph.
Responses may be slow when the model is busy.

Credits and AI disclosure

Data: Delhi Open Transit Data (Department of Transport, GNCTD). This project is not endorsed by DMRC or the Department of Transport.
Closure details: Business Today and News On AIR.
Design approach: WeMakeDevs’ article How to Build an Agent That Reasons Over a Graph.
Video: Opening footage credited to Jist News; all rights belong to the original owner. Voiceover generated with ElevenLabs.
AI assistants: I used Google Antigravity and Claude (Anthropic). Claude drafted most of the code through our conversations. I chose the problem, domain, and closure event; defined the neutrality rules; ran and tested the answers; and checked the sources.

MetroMarg reports what DMRC and Delhi Police said and how the closure affected metro travel. It takes no position on the event itself.