GetOffCode🌿 — Your Best Debugging Tool Might Be a Break

Rishabh Gupta — Sun, 11 Oct 2026 19:44:38 +0000

GetOffCode 🌿 — Your Best Debugging Tool Might Be a Break

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

Developers spend a lot of time thinking about how to make software faster, how to debug more efficiently, and how to write better code. But there's another question we don't always ask ourselves:

What should we do when continuing to work is no longer helping us make progress?

That's the idea behind GetOffCode: an AI-powered cognitive-reset companion for developers that uses lightweight browser activity signals to evaluate when a break might help.

🌐 Live website: https://getoffcode.tech

🎥 Watch the demo: https://www.youtube.com/watch?v=ki9WYvnFCS4&t=19s

💻 Source code: https://github.com/RishabhGupta949/GetOffCode-Hacktoberfest

⬇️ Download the extension: https://getoffcode.tech/downloads/touchgrass-extension.zip

What I Built

GetOffCode is a browser extension backed by a Python/FastAPI service and an AI integration. Its purpose is simple: help developers notice potentially unproductive work patterns and make it easier to step away from the screen before they spend even more time repeating the same actions.

Think about a familiar debugging session.

You encounter a bug. You inspect the code, search for an explanation, open another tab, compare two possible solutions, and return to the editor. The bug is still there, so you repeat the process. You switch between documentation, search results, your editor, and perhaps a conversation with an AI coding assistant.

At some point, you may no longer be making meaningful progress. But because you're focused on solving the problem, you don't necessarily notice how long you've been sitting there or how frequently you're switching contexts.

A normal break timer can help with regular breaks, but it follows a schedule. It doesn't necessarily consider the activity taking place in the browser.

GetOffCode explores a different approach: use activity as context, ask an AI model to evaluate that context, and let the user decide what to do next.

The extension observes lightweight activity signals, including tab-switching patterns and active/idle state. Relevant activity summaries are sent to the hosted backend, where the application coordinates evaluation and the AI recommendation.

When a break suggestion is produced, the user can accept it or choose “Not now.” Accepting opens a dedicated break experience with a countdown. The user can also return early instead of waiting for the entire suggested duration to finish. After returning, the reflection flow gives the user an opportunity to consider whether anything became clearer while they were away.

This is not intended to be another productivity tool that constantly demands attention. It is an experiment in making a break feel like a natural part of the development workflow.

The Problem: We Measure Progress, but Often Ignore the Moment We Need to Step Away

Software development involves long periods of concentration. Sometimes those periods are productive; sometimes they turn into loops.

I wanted to explore three situations in particular.

1. Getting stuck in a debugging loop

A difficult issue can consume far more time than expected. A developer might try one fix, reject it, return to a previous approach, and repeat the same investigation.

The difficulty is not simply the amount of time spent. It is that the person may not notice when their current approach has stopped producing useful progress.

GetOffCode doesn't attempt to understand every line of code or determine whether a solution is correct. Instead, it uses browser activity patterns as contextual signals that may be worth evaluating.

2. Constant context switching

Moving between tabs is a normal part of development. Documentation, Stack Overflow, GitHub, issue trackers, dashboards, and editors all have legitimate roles.

The problem is not tab switching by itself. It is the pattern: frequent switches over a short period, combined with other activity signals, can be a reason to evaluate whether a short reset might be useful.

GetOffCode is built around this distinction. A single tab switch shouldn't automatically mean that someone needs a break.

3. Forgetting to take breaks

Traditional timers can be helpful, but they don't understand the context in which the person is working. A timer may interrupt someone who is making good progress, or it may go off at a time unrelated to the activity that prompted the need for a reset.

GetOffCode experiments with using activity summaries and AI evaluation to make break suggestions more contextual.

These signals are imperfect. They don't prove that someone is frustrated, mentally tired, or stuck. They simply provide information that the system can evaluate before offering a suggestion.

That limitation is important: the goal is not to diagnose the developer. It is to provide a useful nudge while leaving the decision in the developer's hands.

How GetOffCode Works

The core experience follows a straightforward sequence.

Step 1: Enable browser monitoring

The user installs the extension and reviews its requested browser permissions. When monitoring is enabled, the extension observes lightweight activity-related signals.

The extension uses Chrome's Manifest V3 APIs, including tab and idle-related capabilities. This allows it to reason about browser activity without requiring the user to run a separate application alongside the browser.

Step 2: Build an activity summary

Rather than treating each individual event as proof of a problem, the system evaluates activity in context.

Signals such as tab-switch frequency, session duration, and active/idle state can help characterize what has been happening in the browser. The application combines activity handling with its existing evaluation logic.

This step matters because raw events are not conclusions. Switching tabs may mean that someone is researching effectively, comparing implementations, or simply navigating between ordinary work tasks.

The system needs context before it can make a useful recommendation.

Step 3: Send relevant context to the hosted backend

The browser extension communicates with the FastAPI backend deployed on Render.

The backend coordinates activity evaluation, application state, and AI requests. This separation also means the extension doesn't need to contain the AI provider's API credentials.

The hosted architecture is an intentional part of the user experience: people who install the published extension should not have to install Python or operate their own backend server.

Step 4: Let AI evaluate whether a break might help

The application sends relevant activity context for AI evaluation. The model is used to support contextual recommendations rather than merely firing a notification whenever a fixed timer expires.

The important distinction is between detecting a signal and deciding what to recommend.

An activity signal can identify a pattern worth examining. The AI can evaluate the supplied context and contribute to the recommendation, including the suggested break. That recommendation is still an estimate, not a guarantee that the user needs a break.

Step 5: Give control back to the user

When a suggestion is available, the user can choose to take a break or select “Not now.”

This is a central product decision. The extension should help someone make a decision, not take over their work session.

If the person is in the middle of a productive debugging session, they can continue. If a short reset seems useful, they can accept the suggestion.

Step 6: Provide a dedicated break experience

Accepting a suggestion opens a dedicated break screen. The screen displays a countdown and supports returning before the suggested duration has elapsed.

The user doesn't have to wait for the full countdown if they are ready to continue working.

When they return, the existing reflection flow asks them to consider whether anything clicked while they were away. This helps connect the break back to the original task rather than treating the break as an isolated timer.

The complete loop is:

Browser activity → Contextual evaluation → AI break suggestion → User decision → Break → Return and reflection.

Why Not Just Use a Normal Timer?

A timer is useful when the user wants a predictable schedule. It is easy to understand and simple to operate.

GetOffCode explores a different question: can activity context make a break suggestion more relevant?

A rigid timer primarily asks, “Has enough time passed?”

An activity-aware system asks, “Given the signals available right now, is this a useful moment to suggest a break?”

The second question is harder. It requires gathering context, deciding which signals matter, integrating an AI model, and handling the result within a browser extension without interrupting unrelated functionality.

It also introduces uncertainty. Browser activity is not a direct measure of productivity. A developer may switch between many tabs because they are making progress, or remain on one tab while being completely stuck.

That is why GetOffCode treats the model's output as a suggestion. It does not claim that AI can reliably identify every unproductive loop, and it does not force the user to accept a recommendation.

The project is an exploration of contextual break suggestions, not a claim that AI can measure human focus perfectly.

How I Built It

The project is divided into a browser extension, a backend, and a public landing page.

1. Chrome Extension — The User Experience

The extension uses Chrome Manifest V3, with JavaScript, HTML, and CSS.

The extension is responsible for browser activity signals, extension interactions, the break experience, and the return flow. Its manifest declares the permissions needed for the implemented browser behavior, including storage, alarms, idle state, tabs, scripting, and active-tab access.

The user-facing experience includes the extension popup, a break suggestion, the dedicated break screen, and the reflection flow.

One of the practical challenges was keeping the extension lifecycle reliable. A browser extension doesn't run like a single continuously active webpage. Its background service worker and its individual extension pages have different responsibilities and lifecycles.

That means state and requests must be coordinated carefully. A break should not accidentally be started twice, the timer should reflect the active break state, and returning early should follow the existing return flow rather than simply closing a screen.

The project went through iterative debugging to get these interactions working together.

2. Python and FastAPI — The Backend

The backend uses Python, FastAPI, and Uvicorn.

It coordinates incoming activity summaries, application state, AI evaluation, and the break workflow. Keeping these responsibilities behind an API allows the extension to remain a relatively lightweight browser client.

The backend also contains services for activity handling, session management, break behavior, snapshot handling, caching, and AI interaction.

SQLite is used for application-state and related records in the current implementation. The backend configuration also includes settings for snapshots, semantic-cache similarity, the embedding model, and AI request timeouts.

This structure helped keep the browser interface separate from the application logic. The extension handles the interaction with the user, while the backend coordinates evaluation and state transitions.

3. Open-Weight AI Through OpenRouter

GetOffCode uses an open-weight model through OpenRouter for its hosted AI integration.

I chose to keep model interaction behind FastAPI rather than embedding provider requests and credentials directly in the extension. That provides a boundary between the browser experience and the AI provider.

It also makes the model layer easier to change as available models and requirements evolve. The extension does not need to be rebuilt around every provider-specific detail.

This is hosted inference, not a fully local AI application. The model runs through the configured provider, and the backend communicates with it. Consequently, model availability, provider limits, network requests, and backend configuration matter to the overall experience.

The application should also handle model failures honestly. An unavailable model should not be represented to the user as though an AI recommendation was successfully generated.

4. Render — Hosting the Backend and Website

Both the public landing page and the FastAPI backend are deployed on Render.

The live website is:

https://getoffcode.tech

The extension communicates with the hosted backend.

This setup removes an unnecessary installation step for the end user. Someone downloading the extension doesn't need to install Python, create a virtual environment, configure a local API key, or run Uvicorn themselves.

The public website explains the project and distributes the extension ZIP. Installation is handled through Chrome's extension interface rather than requiring a separate backend installation.

One practical limitation is the current Render free-service configuration: after inactivity, the service can take longer to respond while it wakes up. The application also uses SQLite, so its current deployment should not be confused with a fully managed, durable production database setup.

For this challenge, the objective was to get the complete browser-to-backend experience deployed and accessible while keeping the architecture understandable.

5. The Landing Page and .TECH Domain

I also built a public landing page for GetOffCode using the existing frontend project and 21st.dev components.

The site introduces the problem, explains the solution, presents the product experience, and gives visitors a way to download the extension.

The live domain is getoffcode.tech.

I wanted the project to feel like a product someone could actually discover and try, rather than only a repository with a video attached. The landing page, extension package, and hosted backend form a more complete journey from discovery to installation.

The landing page and backend share the same GitHub repository, but they are deployed as separate Render services. This keeps the source code together while allowing the website and API to have their own runtime configurations.

Privacy and User Control

A browser extension that observes activity must be clear about what it does.

GetOffCode is designed around lightweight browser activity signals rather than trying to judge the contents or correctness of a developer's work. Signals provide context for a recommendation; they do not establish what the person is thinking or feeling.

The extension requests browser permissions for its implemented behavior, and users should review those permissions before enabling monitoring.

It is equally important to be transparent about the hosted architecture. Relevant activity summaries are sent to the backend for evaluation, and the configured AI provider participates in the request flow. This project should not be described as fully offline or as keeping every piece of activity data on the user's device.

The current implementation uses backend state and cache records, so retention and persistence depend on the deployed configuration. The application should communicate these facts clearly rather than making broad promises that the technical design does not guarantee.

The product also isn't intended to be an employee-surveillance tool or a medical or mental-health diagnostic system.

The intention is much narrower: use relevant signals to offer a possible break, and let the developer decide whether to take it.

Testing the Real User Journey

For this challenge, I wanted to demonstrate the actual product experience—not just a mocked screenshot of an AI interface.

The live demo shows the website, extension download and installation, activity-based suggestion flow, and break screen.

During my own testing, the system surfaced a summary reporting seven tab switches over the previous five minutes and suggested a five-minute walk outside. That was a useful example of the kind of contextual recommendation the product is built to make.

The demo also includes the “Not now” decision, because user control is as important as the recommendation itself.

The extension has a demo mode that makes it easier to demonstrate the flow without waiting through a long work session. That mode is useful when recording or testing a predictable interaction. It should not be confused with the normal activity-monitoring behavior.

I tested the extension manually in the browser and worked through issues involving the timer display, the early-return action, and application state transitions. Those debugging cycles were a reminder that a feature isn't complete just because the initial happy path works: the user must be able to dismiss a suggestion, begin a break, return early, and continue working without the application becoming stuck in an invalid state.

The project is open source so other developers can inspect how these pieces are connected and contribute improvements.

Why Does Open Innovation Matter?

Open innovation matters to GetOffCode in two ways: the AI layer and the project itself.

First, an open-weight model gives the project flexibility. The model behind the backend can be evaluated or replaced without tying the browser experience to a single proprietary model API. The FastAPI boundary makes that separation practical.

Second, a public repository makes the implementation inspectable. Other developers can look at the extension, API, state handling, and landing page instead of taking a product description on trust.

That is particularly relevant for a project that interacts with browser activity. Being able to review the code and understand the system's boundaries is valuable.

Open source doesn't automatically guarantee privacy, correctness, or reliability. Those properties still depend on how the application is implemented, configured, deployed, and maintained. But public code makes it easier for others to ask questions, identify issues, and propose improvements.

This project also helped me explore the practical work involved in taking an AI-powered idea beyond a local prototype: coordinating a browser extension and backend, handling model requests, dealing with state, deploying the services, packaging an extension, and making the installation journey accessible to someone who hasn't seen the source code before.

The result is an experiment that can be tried, inspected, and extended.

What I Learned

One of my biggest takeaways was that the AI model is only one part of an AI-powered product.

The surrounding system matters just as much: what signals are available, how those signals are represented, when the backend is called, how errors are handled, how the result is displayed, and what happens when the user declines or returns early.

A recommendation can be sensible in isolation and still create a frustrating experience if the UI shows the wrong timer, the backend state becomes inconsistent, or a button doesn't complete the expected transition.

I also learned how important it is to distinguish between a demo and the normal product experience. A short demo trigger is useful for showing the workflow, but it should not become a hidden fixed threshold that determines every real-world recommendation.

Finally, deployment changed how I thought about the project. A public site, extension ZIP, and hosted backend make the product easier to try, but they also introduce operational realities such as cold starts, provider availability, environment configuration, and storage limitations.

These aren't reasons to avoid building an end-to-end product. They are part of building one honestly.

Try GetOffCode

You can explore the live project here:

🌐 Website: https://getoffcode.tech
⬇️ Extension ZIP: https://getoffcode.tech/downloads/touchgrass-extension.zip
🎥 Video demo: https://www.youtube.com/watch?v=ki9WYvnFCS4&t=19s
💻 GitHub repository: https://github.com/RishabhGupta949/GetOffCode-Hacktoberfest
🏆 Hacktoberfest Week 1 challenge: https://dev.to/challenges/hacktoberfest-week1-2026-10-05

The extension is currently distributed as a ZIP for manual installation in Chrome. Download and extract it, open chrome://extensions, enable Developer mode, choose Load unpacked, and select the extracted folder containing manifest.json. You don't need to install Python or run the backend locally; the published extension is configured to use the hosted service.

If you try it, I'd love to hear about the experience. Were the suggestions relevant? Did the break flow feel natural? Were there situations where the extension interrupted you at the wrong time?

Those are exactly the questions I'd like to explore through feedback and future contributions.

My Agent Session

I used OpenCode as an agent-assisted development workflow while building and debugging GetOffCode. The work involved iterating on the extension, backend, and landing page, then checking the real browser experience.

I have not included a shareable DevRelay agent-session link in this submission.

Prize Categories

Best Use of Render — the FastAPI backend and public landing page are deployed on Render.
Best Use of .TECH — the live product website and extension-download experience are available at https://getoffcode.tech.

GetOffCode is built around one small idea: sometimes progress means stepping away for a moment.

Notice the loop. Take a break. Come back clearer. 🌿

hf26challenge #devchallenge #ai #opensource

DEV Community: Rishabh Gupta