DEV Community: Samridhi Gupta

🌶️ 11 PM. 47 Tabs. A 9 AM Deadline. And One Tiny Sloth to Save My Sanity. 🦥

Samridhi Gupta — Sat, 24 Oct 2026 11:26:22 +0000

🦥 I Built a Sloth for My 47 Tabs. Here's Why My Browser Needed One.

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

I opened a tutorial to learn one thing.

Forty minutes later, I had six new tabs, three half-read explanations, and absolutely no idea how to do the thing I'd opened the tutorial for.

One article linked to another. That one assumed I understood something else. The documentation explained the API but sent me down a rabbit hole of unfamiliar terminology.

I wasn't learning anymore. I was collecting browser tabs like they were going to give me extra marks.

And somewhere in that mess, I noticed the absurdity of it all:

I could find an explanation for almost anything online, yet extracting the one thing I actually needed was becoming a task of its own.

I didn't want AI to write my assignments or think for me. I wanted it to help me get my bearings—to show me the central idea, separate important points from the noise, and help me see how everything connected.

So I built Slothy. 🦥

Slothy is an open-source Chrome extension that uses Gemma 3 4B through Ollama to transform webpage content into a gist, key takeaways, action items, and a visual mind map—all through local AI inference.

Open the page. Click Get the gist. Start with the big picture instead of fighting your way through the entire wall of text.

No hosted AI inference API in the core summarization workflow. No need to copy the article into another AI website.

Just the page you're trying to understand, and a little sloth helping you make sense of it.

Because sometimes, the hardest part of learning isn't finding the answer. It's finding your way through everything surrounding it.

🦥 1. What I Built: A Sloth for Information Overload

Slothy is designed around one simple interaction: turn a long webpage into something easier to navigate.

Click Get the gist, and Slothy organizes the model's response into four views.

Feature	What it does
The Gist	Presents the central idea in a concise summary.
Key Takeaways	Pulls out the main points worth remembering.
Action Items	Turns the content into practical next steps.
Visual Mind Map	Shows relationships between ideas in a visual format.

The idea isn't to replace reading. It's to give readers a starting point—to help them understand the structure of an article before deciding where to spend their attention.

Why a sloth?

A sloth felt like the right mascot for a tool about slowing down.

The visual identity follows the same principle: warm cream backgrounds, dark-brown typography, muted olive-green accents, and a friendly leafy mascot.

The product should feel calm even when the page you're reading isn't.

Slow down. Get the gist.

That's Slothy in one sentence.

🎬 2. Demo: From Webpage to Gist

Slothy runs as a Chrome extension connected to a local Ollama instance.

The basic workflow is:

Open a webpage you want to understand.
Open Slothy and start the summarization workflow.
Let Gemma process the extracted page content locally.
Explore the gist, key takeaways, action items, and mind map.

There isn't a hosted demo in this submission. Slothy is designed to run locally, so you can try it by installing the extension and configuring Ollama on your own machine.

🔗 3. The Code: Open Source, Not a Black Box

Slothy lives in your browser, but its language model runs on your machine.

Explore Slothy on GitHub

To try it, you'll need:

Google Chrome with developer mode enabled.
Ollama installed and running.
The Gemma model pulled locally using ollama pull gemma3:4b.
The Slothy extension loaded into Chrome and configured to connect to your local Ollama endpoint.

Once the local model is available, Slothy can send the extracted webpage content to Ollama and present the generated reading results in the extension.

The setup requires a compatible local environment and enough system resources to run the model. The benefit is that the core summarization workflow doesn't depend on a hosted AI inference API.

⚙️ 4. How I Built It: From Browser Tab to Structured Output

I wanted Slothy to be more than a pretty interface wrapped around an AI API. The interesting engineering challenge was connecting webpage extraction, local inference, output handling, and the user interface into one coherent workflow.

The architecture

Here's the path a webpage takes through Slothy:

Webpage → Content extraction → Local Gemma inference → Response parsing → Reading interface

Each stage has a distinct responsibility.

Component	Responsibility	Why it matters
Chrome extension	Provides the browser interface and initiates the workflow.	Keeps the experience close to the content being read.
Content extraction	Collects relevant text from the active webpage.	Gives the model useful input instead of an entire page's interface clutter.
Ollama + Gemma 3 4B	Processes the extracted content locally.	Avoids a hosted inference API in the core summarization workflow.
Response parsing and validation	Converts the model's response into usable application data.	Helps prevent malformed output from breaking the interface.
Reading interface	Presents the gist, takeaways, action items, and mind map.	Turns generated text into a more navigable reading experience.

The technology stack

Technology	Role in Slothy
Gemma 3 4B	Open-weight language model for summarization and structured reading output.
Ollama	Runs the model locally and exposes its local API.
Chrome Manifest V3	Defines the browser extension and its permissions and behavior.
JavaScript	Handles the extension workflow and application logic.
HTML and CSS	Build and style the extension interface.
Native SVG	Renders the visual mind map.
Chrome storage	Supports browser-local extension settings and data where implemented.

The engineering decisions behind the interface

1. Extract content before asking the model to summarize it.

A webpage contains more than the article itself: navigation, menus, footers, and other elements can get in the way. The extraction stage aims to give the model relevant reading content rather than blindly treating the entire page as useful input.

2. Keep inference local.

Slothy communicates with Ollama on the local machine, using its local API endpoint. The extension doesn't need a hosted model API to generate its core summaries.

3. Treat model output as data that needs handling.

Language models don't always return perfectly structured responses. When an application expects specific fields, the response must be interpreted and checked before the interface relies on it.

This is an important distinction: generating a response is one problem; turning that response into reliable application behavior is another.

4. Make the result easier to navigate.

The output isn't limited to a paragraph of generated text. Slothy separates the gist, key takeaways, and action items, and presents relationships between ideas through a visual mind map.

That makes the interface a reading aid rather than just another chat window.

The lesson I took away

Building Slothy reinforced an important engineering principle:

A useful AI application depends on more than the model. It depends on the entire pipeline around it.

Input quality affects the response. Output structure affects the interface. Local setup affects whether the experience works at all.

The model is only one part of the product.

🌍 5. Why Open Innovation Matters: Your Reading Shouldn't Need a Cloud Address

A research paper. A client brief. A recruiter's message. A technical document you haven't fully understood yet.

Webpages can contain information people would prefer not to send to a remote AI service.

I wanted to explore a different architecture.

Slothy uses Gemma 3 4B through Ollama, allowing the model to process extracted webpage content locally on the user's machine.

There is no Slothy cloud server in the core summarization workflow.

That isn't just a privacy slogan. It's an architectural decision.

What open-weight AI makes possible

Benefit	What it means for Slothy
Local inference	The installed model processes content on the user's machine.
No hosted inference API bill	The core summarization workflow doesn't require a paid hosted model API.
More control	Users manage their local model and runtime environment.
Inspectable code	Developers can examine the extension and contribute improvements.
Room to experiment	The local model can be changed when the application supports the selected model and output format.

Local inference isn't magic. It uses your computer's resources, requires model installation, and can be slower or more demanding on some machines. Local processing also doesn't automatically guarantee that every part of an application is private; permissions, dependencies, and data handling still matter.

But it gives developers another way to build AI applications—one in which a hosted inference provider doesn't have to sit at the center of every interaction.

Open source makes the next step possible: other developers can inspect the implementation, learn from the design, adapt it, and help improve it.

The future of AI shouldn't be limited to whoever can afford another API bill. Sometimes, all you need is an open model, your own machine, and an idea worth building.

🤖 6. Building with an Agent—and Making the Work Traceable with Entire

Slothy wasn't built by writing one perfect prompt and watching a finished product appear.

It took an iterative approach: define the problem, build a piece, test the behavior, inspect what breaks, and refine the implementation.

I used Antigravity as my coding agent and integrated Entire into the repository to capture agent activity and connect checkpoints to Git commits.

Why did that matter?

Because AI-assisted development introduces a second problem alongside writing code: understanding how a change came to exist, what prompted it, and whether the resulting implementation actually works.

From agent activity to a Git checkpoint

I configured Entire's Antigravity hooks and verified the installation using entire doctor. Entire recorded checkpoint activity, and my first verified checkpoint was linked to commit 07fb197:

Document Slothy measurements and add agent workflow notes

That gave me a concrete link between captured agent activity and a version-controlled change—not just a claim that an agent had done some work.

The screenshots in this post show the relevant workflow and evidence. The important distinction is that a checkpoint and a successful Git commit establish traceability for that recorded change; they don't automatically prove that every earlier debugging conversation was captured.

When confident reports weren't enough

While debugging Slothy, I encountered a frustrating problem: on a long Wikipedia page, the model returned only two tokens, yet the interface displayed a misleading summary card. Later, even when the model generated a substantial response, the extension crashed with a ReferenceError because renderMindmapSvg() was missing.

During this process, some agent reports claimed that files had been created or fixes completed when the actual files and diffs told a different story.

I learned to verify claims against the source code, Git changes, browser Console and Network tab, and Ollama's runtime information rather than trusting a confident explanation.

Entire made it possible to inspect recorded agent activity alongside a commit, but I also encountered a limitation: its logs reported a transcript-preparation failure because the Antigravity IDE transcript path was outside the directory it expected.

I therefore don't treat the checkpoint as proof that the complete conversation was captured. I documented the earlier debugging separately in docs/AGENT_SESSION.md, distinguishing my notes from Entire-captured activity.

What I learned

Entire was useful not because it made AI-generated work automatically trustworthy, but because it gave me a way to inspect and connect recorded activity with a real Git change.

The process reinforced three habits:

Inspect the diff. A confident explanation isn't evidence that a file changed.
Test the behavior. A generated response isn't proof that the interface handles it correctly.
Keep the history honest. A recorded checkpoint is useful, but its limitations should be visible too.

For me, the best use of Entire is to make agent-assisted development traceable, inspectable, and easier to question.

And that fits the same principle behind Slothy: useful AI should help people understand what is happening, not ask them to accept a black box on faith.

🏆 7. Prize Categories

I'm submitting Slothy for:

Best Use of Gemma: Gemma 3 4B powers Slothy's local webpage summarization workflow through Ollama.
Slow and Steady: Slothy encourages a more deliberate way to process information: start with the big picture, understand the key ideas, and decide what to do next.
Best Use of Entire: I integrated Entire's Antigravity hooks into my repository, verified the setup, and linked a recorded checkpoint to a Git commit. The process also taught me to be transparent about the limits of transcript capture instead of overstating what the evidence proves.

🦥 One Less Rabbit Hole

Slothy started with a small frustration: opening a tutorial to learn one thing and ending up lost in ten other tabs.

I built it because I wanted a tool that could help me find the thread connecting all that information—without handing the entire task of understanding over to AI.

It's a work in progress, but it represents what I care about as a developer: building useful tools, experimenting with open-source AI, and learning by making things real.

If you've ever opened a tutorial and forgotten why you opened it in the first place, you understand the problem.

Here's to fewer rabbit holes, clearer thinking, and taking the slow lane when it matters. 🦥

Built with Gemma 3 4B, Ollama, JavaScript, and a browser full of ideas.

Explore Slothy on GitHub →

🚨 That APK Looks Innocent. Let's Interrogate It.

Samridhi Gupta — Sun, 18 Oct 2026 20:34:50 +0000

APK-Xray: Evidence-First Android Security Analysis, Enhanced by AI

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

What I Built

An APK named Wedding Invitation.apk arrives on WhatsApp. It looks harmless—but a malicious app disguised as a wedding invitation can steal contacts, SMS messages, bank OTPs, and notification data. CERT-In's Cyber Swachhta Kendra documented this threat in its June 2025 SpyMax Android malware alert.

The scale of the problem matters, too: India recorded 86,420 cybercrime cases in 2023, according to NCRB data published by the Ministry of Home Affairs. (Ministry of Home Affairs · National Crime Records Bureau)

That raises a question: before installing an APK, how can we understand what it might be capable of doing?

That's why I built APK-Xray, an evidence-based Android APK security analyzer.

It extracts security-relevant metadata, including permissions and application components, then evaluates them using explicit detection rules. The goal is to make potential risks easier to investigate by showing the evidence behind each finding—not simply producing another alarming warning.

I also explored AI-assisted explanations to make technical findings easier to understand, while keeping evidence—not AI-generated claims—at the center of the analysis.

The principle: Don't just flag a potential risk. Show the evidence behind it.

APK-Xray is a static analysis tool, not a guarantee of safety. It helps investigate an APK's declared capabilities, but cannot establish everything the app might do at runtime.

Frontend

React + TypeScript + Vite for a responsive, component-based interface.
APK upload and analysis workflow with clear loading, error, and report states.
Infographic security reports with finding cards, donut visualizations, pipeline steps, and progress indicators.
Evidence-focused findings that help users understand detected APK capabilities.
Multilingual interface with an English/Hindi selector.
Light and dark themes for a flexible viewing experience.
Reusable UI components with automated tests using Vitest and React Testing Library.
Production-ready build verified through TypeScript checks and Vite.

Demo

Watch the APK-Xray Demo

Code

Explore the source code: GitHub Repository

Want to inspect the codebase with AI-assisted repository analysis? Explore APK-Xray on Gitingest.

Project Structure

APK-Xray/
├── backend/
│   ├── api.py                  # FastAPI endpoints and request handling
│   ├── parser/
│   │   └── apk_parser.py       # APK metadata extraction
│   ├── scoring.py              # Deterministic security rules and scoring
│   ├── gemma.py                # AI explanation integration
│   ├── report_builder.py       # Structured report generation
│   ├── report_store.py         # Report persistence
│   ├── sentry_setup.py         # Observability configuration
│   ├── schema/
│   │   └── report.schema.json  # Report contract
│   └── test_*.py               # Backend and integration tests
├── frontend/
│   └── src/
│       ├── api.ts              # Backend communication
│       ├── App.tsx             # Main application interface
│       ├── report.ts           # Report handling
│       └── components/         # Reusable UI components
└── README.md

The backend owns APK parsing, deterministic detection, scoring, report validation, optional Gemma explanations, and persistence. The React + TypeScript frontend handles uploads and presents the resulting security report.

🔗 Try APK-Xray

Live Demo: https://apk-xray.vercel.app/
Backend Health Check: https://apk-xray.onrender.com/api/health
Source Code: https://github.com/justsamridhi/APK-Xray
Gitingest Repository View: https://gitingest.com/justsamridhi/apk-xray

The live frontend lets you explore the APK-Xray interface, while the source code provides access to the implementation.

Note: The health-check endpoint confirms backend availability, not that every analysis or AI integration is functioning correctly. APK-Xray performs static analysis; APKs are not installed or executed.

🔍 The Problem: Security Warnings Aren't Enough

An APK requesting sensitive permissions isn't automatically malicious. A messaging app may legitimately need access to contacts, while an unrelated utility requesting SMS access deserves closer scrutiny.

The challenge is understanding which capabilities an app declares, why they matter, and what evidence supports a potential risk.

APK-Xray approaches this through three core ideas:

Evidence over assumptions: Extract APK metadata and connect findings to explicit detection rules.
Explainable findings: Make technical security signals easier to understand without presenting suspicion as proof.
AI with boundaries: Use AI-assisted explanations to improve readability, not to replace static analysis or invent evidence.

The goal isn't to label every APK as safe or dangerous. It's to give developers and security learners a clearer starting point for investigating what an Android application may be capable of doing.

⚙️ How APK-Xray Works

APK-Xray transforms an Android APK into a structured, evidence-backed security report through four stages.

1. Extract — Understand the APK

The uploaded APK is parsed to extract security-relevant metadata, including declared permissions and application components.

2. Analyze — Evaluate Potential Risks

A rule-based detection engine evaluates the extracted metadata against explicit security rules. Each finding connects a potential risk to observable evidence rather than relying on vague warnings.

3. Explain — Make Findings Understandable

AI-assisted explanations help translate technical findings into clearer language. The AI provides context; the extracted metadata and detection rules remain the basis of the analysis.

4. Report — Present Actionable Findings

The results are organized into a structured report that helps users understand flagged capabilities, inspect supporting evidence, and decide what deserves further investigation.

The Workflow, at a Glance

APK Upload → Metadata Extraction → Rule-Based Analysis → AI-Assisted Explanation → Structured Security Report

The core principle: AI can explain the evidence, but it doesn't replace it.

APK-Xray uses static analysis, so it identifies potential risks from the APK's available metadata. It does not guarantee that an app is safe or establish every behavior that might occur at runtime.

🛠️ Engineering Decisions That Matter

Building APK-Xray wasn't just about detecting suspicious permissions. It was about making the analysis traceable, structured, and honest about uncertainty.

1. Deterministic Detection Over Black-Box Judgments

Explicit rules evaluate extracted APK metadata, making findings easier to inspect and reproduce. A permission alone isn't proof of malicious intent; combinations of capabilities and contextual evidence matter.

2. Separate Detection from Explanation

The rule engine produces findings, while Google Gemma helps explain them in accessible language. This separation keeps AI-generated text from becoming the sole basis for a security verdict.

3. Structured Reports Over Vague Alerts

A consistent JSON report makes findings easier to validate, display, test, and potentially integrate into other tools.

4. Static Analysis with Clear Boundaries

APK-Xray examines available package metadata without executing the application. It can identify declared capabilities and rule matches, but it cannot guarantee safety or reveal every runtime behavior.

These decisions reflect the principle behind the project: a useful security tool should explain not only what it flags, but also what its evidence can—and cannot—prove.

💡 What's Innovative About APK-Xray?

The innovation isn't simply using AI to scan an APK. It's separating evidence-based detection from AI-assisted interpretation.

APK-Xray is built around three ideas:

Evidence-first security: Explicit detection rules connect potential risks to extracted APK metadata instead of relying on unexplained AI-generated verdicts.
AI that explains, not decides: Google Gemma can help translate technical findings into understandable explanations, while the underlying analysis remains grounded in extracted evidence.
Reports developers can inspect: Structured findings make the output easier to review, validate, and build upon.

Frontend Design Exploration

🚀 From Open-Source Project to Potential Side Hustle

For independent Android developers, small development teams, and security educators, understanding an APK's declared capabilities can be a useful part of a security review.

APK-Xray explores how that analysis could become a developer-focused service: upload an APK, inspect potential risks, understand why a rule was triggered, and review a structured report.

The longer-term opportunity is to expand this into features such as historical report comparison, batch analysis, and multilingual explanations—subject to implementation and validation.

I'm not claiming paying customers or proven market demand yet. The next step is to put APK-Xray in front of real developers, learn which parts of the workflow save them time, and validate whether the tool solves a problem worth paying for.

The bigger idea: make Android security findings easier to understand without making them less rigorous.

🤖 Inside the Build: Agent Tracing with Sentry

To understand what happens during an APK analysis request, I instrumented APK-Xray's FastAPI backend with Sentry tracing. Instead of treating /api/upload as a single operation, I added spans around key stages of the pipeline so I could inspect their execution times, relationships, and status.

How the Tracing Works

When an APK is uploaded, the backend processes the request through several stages. Sentry records these operations as spans within the parent HTTP transaction.

Operation	What it tracks
`http.server` — `/api/upload`	Overall request duration
`apk.parse` — Parse APK manifest	APK metadata extraction
`apk.report` — Build and validate report	Report construction and validation
`ai.lifecycle` — AI explanation workflow	Execution status of the explanation workflow
`apk.persist` — Persist report to SQLite	Database persistence time

The trace waterfall shows how these operations relate to the parent request, while the span explorer exposes individual durations and recorded attributes.

What the Traces Revealed

One captured /api/upload transaction completed in 13.70 ms.

Span	Recorded duration
Overall HTTP transaction	13.70 ms
Report persistence to SQLite	Approximately 9.88 ms
Manifest parsing	Less than 1 ms
Report construction and validation	Less than 1 ms

These measurements come from one captured request, not a general performance benchmark.

The traces also showed an AI explanation not configured state in some executions. This helped distinguish a recorded workflow from an external AI integration that was actually configured and running.

Why This Matters

Sentry helps me inspect execution paths, investigate latency, and identify where further debugging is needed. For a security-focused application, I also want observability to respect privacy: operational telemetry should not unnecessarily expose uploaded APK contents or sensitive information.

Trace Evidence

The following screenshots show the actual instrumentation from three perspectives:

Trace overview: Recorded spans across multiple requests.
Request waterfall: The parent transaction and its child operations.
Span explorer: Individual span attributes and durations.

Together, they provide evidence that APK-Xray's backend has instrumented analysis stages and that the recorded traces can be inspected. They do not, by themselves, prove that every external AI integration is active in production.

🧠 Google Gemma 4: AI That Explains the Evidence

Most security tools can flag a suspicious permission. APK-Xray takes the next step: helping users understand what that finding means, without letting AI invent the evidence.

Here's how Gemma 4 fits into the actual analysis pipeline.

Static analysis comes first. Androguard extracts APK manifest metadata, and APK-Xray's deterministic rules identify security-relevant indicators and calculate the exposure score.
Gemma receives normalized evidence. When configured, the Gemma 4 integration sends the extracted evidence and relevant app facts to the model—not the original APK.
The model generates explanations. Gemma returns structured claims with evidence IDs and explanations in both English and Hindi. Each claim distinguishes between what the evidence supports, what something could indicate, and what cannot be proven.
The backend validates the response. Claims referencing unknown evidence IDs are rejected, and the expected output structure and both language explanations are checked.
The report remains usable if AI fails. If Gemma is unavailable or its response fails validation, APK-Xray preserves the deterministic findings and score rather than relying on an invalid AI response.

Why This Design Matters

APK-Xray's deterministic engine	Gemma 4
Extracted evidence and rule matches	Human-readable explanations
Controls findings, severity, and score	Produces evidence-linked claims
Establishes what the analysis observed	Explains what those observations may mean
Remains available if AI fails	Is an optional explanation layer

This separation is deliberate. Gemma cannot add evidence, change a finding's severity, or modify the exposure score. It never receives the APK itself.

For example, if an APK declares SMS-reading permissions, the rules engine can flag that capability. Gemma can help explain why it deserves scrutiny—but that permission alone does not prove the application is malicious.

The integration also supports English and Hindi explanations, making technical findings more accessible to a wider range of users.

The principle behind APK-Xray: let rules establish the evidence, let AI explain it, and never confuse an explanation with proof.

🏆 Prize Categories

1. Sentry — Agent Tracing & Observability

APK-Xray uses Sentry tracing to make the backend analysis pipeline observable at the request and operation level. Traces capture stages including http.server (/api/upload), apk.parse, apk.report, ai.lifecycle, and apk.persist. This provides visibility into request execution, parsing, report construction, AI-explanation handling, and SQLite persistence.

In one captured trace, the request completed in 13.70 ms, with SQLite persistence accounting for approximately 9.88 ms. These traces help identify performance bottlenecks and investigate failures across the pipeline. The captured telemetry also shows when AI explanations are not configured, helping distinguish deterministic analysis from optional AI functionality.

2. Google Gemma 4 — Evidence-Grounded Security Explanations

Gemma 4 provides the natural-language explanation layer on top of APK-Xray's deterministic security analysis. The backend sends normalized application facts and security evidence to the configured model endpoint—not the raw APK file.

The model generates structured explanations in English and Hindi, linked to evidence IDs and constrained to the classifications Can, Could, and Cannot Prove. The backend validates the response structure and evidence references before accepting the output. Unknown evidence IDs and invalid responses are rejected.

Crucially, Gemma explains findings; it does not perform the underlying rule-based detection or determine the exposure score. If the model is unavailable or its response fails validation, the deterministic report remains available.

3. Render — Cloud Deployment for the Analysis API

APK-Xray's backend is deployed on Render using FastAPI and Python, connecting the deployed React + TypeScript frontend to the static-analysis pipeline. The API exposes endpoints for health checks, APK uploads, and report retrieval:

GET /api/health — checks backend availability.
POST /api/upload — accepts and processes an APK for analysis.
GET /api/report — retrieves the generated report.

The upload workflow validates file properties, processes the APK using Androguard, evaluates deterministic security rules, and constructs a structured report. APKs are analyzed statically; they are not installed or executed.

Live endpoints: Backend Health Check · Deployed Application

4. GitHub Copilot — AI-Assisted Engineering

GitHub Copilot supports the development workflow through AI-assisted coding, implementation exploration, and testing. For a security-analysis project, the important distinction is between assistance during development and behavior in the shipped application: Copilot is a development tool, not part of APK-Xray's runtime detection pipeline.

The core analysis remains explicit and testable through Python rules, structured report generation, and schema validation. This separation keeps security findings auditable instead of relying on an opaque, AI-generated verdict.

👥 Team

Built by Samridhi Gupta — project design, implementation, and integration of the APK-Xray analysis pipeline.

Contributor: Aditya Modani (DEV: @modapk06).

SUNDEBT: I Made My Phone Charge Me Rent in Sunlight

Samridhi Gupta — Fri, 09 Oct 2026 10:30:11 +0000

SUNDEBT ☀️ — Earn Your Screen Time

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

What I Built

I open my phone to check one notification, and somehow, thirty minutes disappear.

I didn't want to build another app that shames me for scrolling or simply locks me out. I wanted to flip the idea:

What if I had to earn my screen time by spending time outside?

That question became SUNDEBT — Earn Your Screen Time.

SUNDEBT turns outdoor time and movement into a currency for screen time. Spend time outside, earn Sun Minutes, pay off your Sun Debt, and unlock screen time through the Scroll Gate. Along the way, Sol, a companion powered by a local AI model, suggests small outdoor missions to get you moving.

The idea is simple: put your phone down, get moving, earn your minutes, and make screen time something you work toward.

☀️ How It Works

☀️ Sun Sessions: Start an outdoor session, put your phone down, and spend time outside. The intended experience uses available sensor signals to assess sunlight and movement.
👟 Steps as Currency: Estimated steps contribute to your Sun Minutes, turning movement into currency you can use toward screen time.
✨ Sun Minutes: Your earned minutes pay off Sun Debt first. Any remaining balance becomes spendable screen time.
🤖 Sol: A companion powered by a local AI model that suggests short outdoor missions.
🌱 Sol's Growth: Earn XP as you progress. The longer-term vision is a personalized digital forest that grows with your outdoor habits.
🚪 Scroll Gate: Adds a pause before selected web links, encouraging you to choose intentionally instead of scrolling on reflex.

SUNDEBT includes a 90-minute daily earning cap and a step-based bonus. Your wallet and session history stay in your browser, with no accounts or database.

I built this for the Touch Grass challenge because I wanted to explore a different relationship with technology—not one based on guilt or punishment, but on making real-world experiences rewarding.

🎬 Try SUNDEBT

🌐 Live frontend: https://sundebt.vercel.app/

💻 Source code: https://github.com/justsamridhi/SUNDEBT

📖 README and setup guide: https://github.com/justsamridhi/SUNDEBT/blob/main/README.md

🔧 Merged Ollama configuration fix: https://github.com/justsamridhi/SUNDEBT/pull/1

🎥 10-second demo: Watch on Google Drive

📱 A Look Inside

🛠️ How I Built It

SUNDEBT combines a mobile-first progressive web app with a local AI-guidance pipeline and durable session workflows.

Tech stack

Frontend: React, TypeScript, Vite, PWA
Backend: Express, TypeScript
Agent framework: Mastra
Local inference: Ollama with llama3.2:3b
Workflow orchestration: Temporal

Architecture

The AI-guidance path connects the PWA to the backend, where a Temporal workflow coordinates the session and Sol's AI activity.

React PWA
   |
   v
Express API
   |
   v
Temporal Sun Session Workflow
   |
   v
Sol Activity -> Mastra Agent -> Ollama
   |
   +-- Invalid output or failure
                |
                v
      Deterministic mission fallback

🤖 Sol: Local AI That Fails Gracefully

I wanted Sol to be helpful without making the entire application dependent on an AI response.

Sol uses a Mastra agent backed by Llama 3.2 3B through Ollama. The model receives limited context, including Sun Minutes, Sun Debt, recent session durations, and time of day. Its output is parsed and validated before a mission is displayed.

A safety filter rejects unsafe guidance, including medical claims and risky location suggestions. If the output is empty, malformed, invalid, unsafe, or the model is unavailable, SUNDEBT falls back to a deterministic mission.

The goal wasn't just to make AI work. It was to make the experience useful when AI doesn't.

🐛 The Bug That Taught Me the Most

For a while, Sol kept showing the offline mission.

The app appeared to work because the fallback was reliable, but it also hid whether the AI path was actually succeeding.

My local RTX 3050 has 4 GB of VRAM, and Mastra's structured-output approach caused memory problems. I switched to plain-text generation and wrote a tolerant JSON parser that strips code fences, extracts the JSON object, and validates the result.

Then I discovered a timeout mismatch.

I added logging for fallback reasons such as empty output, timeout, parsing, schema validation, safety rejection, and provider failure. My observations showed:

Cold model call: approximately 7.2 seconds
Warm model call: approximately 1 second
One observed call: 10 seconds
Original Temporal Activity timeout: 8 seconds

A valid response could arrive too late and be discarded.

I increased the Activity timeout to 40 seconds, aligned API and frontend waits, added a startup warm-up request, and introduced a visible “Sol is thinking…” state.

That debugging process changed how I thought about reliability.

A fallback can keep an application alive, but observability tells you whether the primary system is actually working.

⏳ Why Temporal?

A Sun Session isn't a single API request. It involves a Sun Check, phone-down phase, outdoor timer, interruptions, resumes, and completion.

Temporal models this progression through a sunSessionWorkflow, event signals, and workflow state. Sol runs as an Activity, while reward logic handles the daily cap, step bonus, debt-first repayment, and XP.

Backend tests cover duplicate event IDs and repeated completion to help prevent the same event from awarding the same reward twice.

The wallet remains browser-local. Temporal stores workflow state and event history—not a cross-device account or wallet.

🌱 The Vision for Sol's Digital Forest

Sol currently has a progression system based on XP. The larger idea is to make that progress visible through a personalized digital forest.

Imagine earning sunlight and movement minutes to help your digital world grow. Returning to social media during an outdoor session could put that progress at risk, making the choice to stay outside more meaningful.

The forest and tree-dying mechanic are future ideas, not features currently implemented. They represent the direction I'd like to explore next: making time away from the screen feel as rewarding as time spent on it.

✅ Verification

I ran the following checks locally:

Backend typecheck: Passed
Backend tests: 19 passed, 0 failed
Backend TypeScript build: Run without errors shown in the shared terminal output
Frontend production build: Passed

The tests cover Sol output validation, safety rejection, fallback and retry behaviour, event deduplication, and reward calculations.

🌍 Why Open Innovation Matters

Open innovation gave me the freedom to experiment, inspect failures, and change the implementation instead of treating AI as a black box.

With Ollama and an open-weight model, I could explore local inference within my hardware limits. Mastra provided the agent layer, while Temporal helped model a multi-stage session that needs predictable behaviour.

These tools didn't remove the difficult engineering. They gave me the means to investigate it, learn from it, and build something more resilient.

That's what makes open innovation valuable to me: the ability to understand a system, adapt it, and share what I learn.

🧑‍💻 My GitHub Copilot Workflow

I used GitHub Copilot's VS Code agent/chat workflow for repository inspection, scoped code changes, debugging, tests, and README updates.

I used narrow prompts and explicit file scopes, asked the agent to preserve existing behaviour, and avoided automatic commits or pushes. Copilot assisted with Sol's integration and fallback path, output validation, logging, Temporal workflow reliability, reward handling, tests, and documentation.

One limitation was that Copilot's command environment couldn't find PowerShell, so it couldn't execute the requested local checks. I ran the typecheck, backend tests, and production builds in my own VS Code terminal and reviewed the resulting changes myself.

I also caught and corrected configuration drift between the model used by the code and the README/environment example.

The process reinforced an important principle: AI-assisted development still needs human review, deliberate debugging, and independent verification.

🏆 Prize Categories

Best Use of Temporal

A multi-stage session workflow with event handling, Activity timeouts, and idempotent reward logic.

Repository: https://github.com/justsamridhi/SUNDEBT

Best Use of Mastra

A local-model agent with validated output and deterministic fallback handling.

Repository: https://github.com/justsamridhi/SUNDEBT

Best Use of GitHub Copilot

Scoped agent-based development, debugging, tests, and documentation, with local verification of the resulting changes.

Merged configuration fix: https://github.com/justsamridhi/SUNDEBT/pull/1

🚀 What's Next?

I'd like to explore a native Android version with stronger, platform-supported app blocking, more reliable outdoor-session signals, and the digital forest concept.

The frontend is deployed on Vercel. The full AI and durable-workflow path requires the backend, Temporal service and worker, and Ollama running locally. If those services or the model are unavailable, the app can continue with deterministic offline guidance and its browser-local wallet.

The current web app cannot guarantee that a phone remains locked, conclusively prove outdoor presence, measure Vitamin D, or block every installed app. Browser and device support also determine which sensor readings are available.

SUNDEBT is an experiment in making a small change feel rewarding.

The phone can wait. Go see what's outside.

Contributor: Aditya Modani — @modapk06

Launch Weekend challenge

Samridhi Gupta — Tue, 06 Oct 2026 08:18:45 +0000

Hi DEV Team,

I’m reaching out regarding the Virtual Sticker Launch Weekend DEV Challenge. I participated as part of a team in the submission "ExpenseAI".

Project Details:

GitHub: https://github.com/Aditya4453/DEVchallenge
DEV Submission: https://dev.to/challenges/hacktoberfest-weekend-2026-10-01

The project was submitted as a team entry, and I am listed as a team member in the submission:

Name: Samridhi Gupta
DEV Profile: @justsamridhi (https://dev.to/justsamridhi)

The challenge rules state that team submissions are supported and that collaborators’ DEV handles should be listed so the entire team can receive the completion badge. However, I have not yet received my virtual sticker for this challenge.

I wanted to check whether there is any additional action required from my side, or if there is a different process for team members to be awarded the virtual sticker.

Thank you for your help!