CampusMate AI

A JavaFX AI companion for engineering students that answers instantly offline, thinks harder with Claude when it needs to, and tracks your deadlines and headspace along the way.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for CampusMate AI

Inspiration

As a first-year CSE (AI & ML) student juggling coursework, hackathons, and placement prep, I kept noticing the same gap: every AI chatbot I tried was either a thin wrapper around an API — expensive to run and slow for questions that didn't need a big model at all — or a rule-based bot with no real reasoning underneath. I'd already built a rule-based JavaFX chatbot before (MindMate AI), and I wanted this project to go a step further: not "chatbot vs. no chatbot," but a genuinely hybrid system that makes a real engineering tradeoff between speed/cost and depth.

At the same time, I noticed I don't just need answers — I need somewhere to track deadlines and check in with myself during a packed semester. So CampusMate AI became three things in one: a hybrid AI chat, a study planner, and a lightweight mood log.

What it does

CampusMate AI is a JavaFX desktop app built around a hybrid local + cloud AI architecture:

A local knowledge engine matches common questions (CGPA calculation, placement prep, hackathon tips, Java/JavaFX help, campus life) and answers them instantly, offline, with zero API cost. When a question needs real reasoning — an open-ended doubt, personalized planning help, general conversation — the app escalates to the Claude API on a background thread, so the UI never freezes, and clearly labels the answer LOCAL or CLAUDE so the user always knows which engine responded.

Alongside the chat, a Study Planner tab tracks assignments with subjects and due dates (with overdue highlighting), and a Mood Check-in tab logs how you're feeling with a short, supportive, non-clinical response.

How I built it

The app is a Maven-based JavaFX 21 project structured around clean separation of concerns:

model/ — plain data classes (Message, Task) service/ — the actual logic: LocalKnowledgeService (keyword-matching engine backed by a JSON knowledge base), AIService (calls the Anthropic Messages API via java.net.http.HttpClient, maintains conversation history), PlannerService and MoodService controller/ — one controller per tab, wiring services into the UI util/JsonStore — local JSON file persistence (~/.campusmate/data.json), so tasks and mood logs survive restarts without needing a database

The routing logic in ChatController is the core idea: every message hits the local engine first; only a miss escalates to a background Task that calls Claude and updates the UI when it resolves. The whole UI runs on a custom dark "late-night study desk" theme (deep ink-navy background, amber accent for the AI's voice, sage green for the local-engine badge) defined entirely in CSS.

Challenges I ran into Keeping the UI responsive during API calls. JavaFX will throw if you touch the scene graph from a background thread, so the Claude call runs inside a javafx.concurrent.Task, with Platform.runLater used to safely update the chat bubble once the response (or an error) comes back. Deciding what "local vs. cloud" actually means for a hackathon project, not just as a cost optimization but as something visible and explainable to a user — hence the LOCAL/CLAUDE badges instead of hiding the routing decision. Designing a UI that didn't feel templated. I leaned into a specific theme (ink-navy + amber + sage) rather than defaulting to a generic dark mode, so the chat, planner, and mood tabs all feel like one coherent product. What I learned

Building the hybrid engine forced me to think about AI products the way a real team building on a budget would — not "call the API for everything" but "know when you don't need to." I also got much more comfortable with JavaFX's concurrency model (Task, Platform.runLater) and with structuring a desktop app into clean, testable service classes instead of putting logic directly in the UI code, which is a habit I'm carrying into future projects.

What's next Swap the keyword-matching local engine for a small embedding-based matcher so it scales past a fixed FAQ list Add lightweight user accounts so data isn't tied to a single machine Package with jpackage for a one-click installer instead of requiring Maven to run it

Built With

Share this project:

Updates