DEV Community

Cover image for Claim Attention
Koushik Deb
Koushik Deb

Posted on Edited on

Claim Attention

GitHub β€œFinish-Up-A-Thon” Challenge Submission

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Claim-Attention is a real-time attention compass. It takes one webcam frame every two seconds, finds your face with MediaPipe, and places your attention as a moving dot on a five-point compass: present at the centre, with internal thought , external distraction , past memory and future planning pulling outward.

Two ideas sit underneath it. MCASE (Multi-Cue Attention State Estimation) reads eye-aspect ratio, gaze, head pose, blink rate and small expression cues, then scores the five states. TADV (Temporal Attention Drift Vector) treats the dot as a spring-damper particle, so the motion stays smooth instead of jittery.

The project began as a small experiment around a personal question: where does my mind actually go when I believe I am focused? It grew into something I wanted other people to try, which is why it now runs in the browser, on Windows and on mobile against one shared backend.

Demo

GitHub Repo

Claim-Attention

Real-time Attention Compass powered by the MCASE algorithm Built for the GCP Gemini 2.0 Hackathon.


πŸ“ Folder Structure

Code/
β”œβ”€β”€ cloud_functions/    # GCP Cloud Functions (Python) β€” backend
β”œβ”€β”€ terraform/          # Infrastructure-as-Code (Terraform)
β”œβ”€β”€ web_app/            # React web application (Vite)
β”œβ”€β”€ windows_app/        # Python Windows desktop app (CustomTkinter)
β”œβ”€β”€ mobile_app/         # Flutter mobile app (iOS + Android)
β”œβ”€β”€ .env                # Your secrets (gitignored)
└── .env.example        # Template β€” copy to .env and fill in

πŸš€ Quick Start Order

Before running anything, copy .env.example β†’ .env and fill in your GCP keys.

1. Deploy Backend (when ready)

cd Code/terraform
cp terraform.tfvars.example terraform.tfvars   # fill in project_id
terraform init
terraform apply                                 # creates GCS buckets + Functions
Enter fullscreen mode Exit fullscreen mode

2. Run Web App (local dev)

cd Code/web_app
cp .env.example .env                            # add VITE_CLOUD_FUNCTION_URL
npm install
npm run dev                                     # β†’ http://localhost:3000
Enter fullscreen mode Exit fullscreen mode

3. Run Windows App

cd Code/windows_app
cp .env.example .env                            # add CLOUD_FUNCTION_URL
…
Enter fullscreen mode Exit fullscreen mode

Live Software Link

The Comeback Story

I had left this half-finished few months ago. The backend and the React web app ran on my machine, but everything else had drifted out of sync:

  • The Windows and Flutter clients were stale and would not run against the current backend.
  • Calibration ran forever β€” it never completed, so you could never start a session.
  • The "Hide Camera" toggle did nothing.
  • Nothing was deployed, so there was no link to share.
  • The code map describing the project was out of date.

For the Finish-Up-a-thon I closed each gap:

  • Replaced the old Gemini-Vision validation with a provider-agnostic LLM second opinion (DeepSeek and Gemini through OpenAI-compatible APIs).
  • Added FocusWell , a predictive layer that estimates drift before it happens β€” a drift-risk gauge, a time-to-drift estimate, flow-streak detection and a pre-emptive nudge β€” then ported the same engine into the Windows (Python) and mobile (Dart) clients so all three behave alike.
  • Fixed the calibration hang (a renamed camera method that threw inside the capture loop) and the hide-camera binding.
  • Rewrote the Windows camera handling as a single reader to remove a frame race.
  • Deployed the whole project to Google Cloud Run as one small, scale-to-zero service that serves both the API and the web UI, which keeps the running cost close to nothing.

It now has a public URL and a working demo path: calibrate, start a session, watch the compass move, and get nudged just before you drift.

My Experience with GitHub Copilot

I built the original version with GitHub Copilot, and I finished it with Copilot too.

The part where it earned its place was porting FocusWell across three languages. The maths had to stay identical between the JavaScript reference, the Python desktop port and the Dart mobile port β€” same weights, same thresholds, same prediction steps. Copilot held the structure steady as I moved function by function, which is exactly the kind of careful, repetitive translation that is easy to get subtly wrong by hand.

It also carried the unglamorous finishing work: tracing the calibration bug back to a renamed camera method, writing the multi-stage Dockerfile that builds the React app and serves it from Flask, and settling the Cloud Run flags so the service scales to zero.

What I took from the finish-up is simple. The last ten percent of a project is mostly small, fiddly corrections across many files, and that is where an assistant which holds context across the whole codebase actually saves time.

Technical Details

  • Frontend: React (Vite) web app, Flutter mobile, and a Python CustomTkinter desktop app. Each runs a 2-second capture loop with client-side TADV smoothing and the FocusWell overlay.
  • Backend: Python Flask on Google Cloud Run, exposing six REST endpoints: /capture, /history, /latest, /sessions, /calibrate, /cleanup.
  • Vision and scoring: MediaPipe Face Mesh (478 landmarks) feeds MCASE features (eye-aspect ratio, gaze, head pose, blink rate, expression cues), which score the five states; TADV applies spring-damper physics for smooth motion.
  • Prediction: the FocusWell engine (drift risk, time-to-drift, flow streak, predicted path) is ported across JavaScript, Python and Dart with identical maths.
  • LLM check: every tenth frame, numeric features (not the image) go to an OpenAI-compatible model (DeepSeek via NanoGPT, Gemini via linkapi) and blend 70/30 with the local score.
  • Storage: sessions and readings as CSV plus JPEG media on the container disk (LOCAL_DEV); no external database.
  • Deployment: one Cloud Run service serves both the API and the built web app via a multi-stage Dockerfile (Node build, Python serve), scaling to zero when idle.

Koushik Deb
@debk

Top comments (0)