DEV Community: Varun Fatehpuria

PHANTOM Terminal: Something Is Still Running 👻

Varun Fatehpuria — Tue, 27 Oct 2026 07:31:50 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

What I Built

What if your terminal could tell ghost stories?

Meet PHANTOM Terminal, a local-first, AI-powered haunted terminal inspired by the eerie feeling that something might still be running long after a machine should have gone quiet.

For this week's Ghost in the Machine theme, I wanted to combine the atmosphere of retro computer terminals with the possibilities of open-weight AI. Instead of building another chatbot with a conventional interface, I created a terminal-inspired experience where ordinary text fragments become mysterious transmissions.

PHANTOM currently has three modes:

Terminal Haunting: Feed it a harmless command or log fragment and receive eerie commentary.
Ghost Story: Turn a prompt about abandoned servers, forgotten software, or strange computer activity into an original horror story.
Memory Archive: Preserve meaningful stories, favorite songs, meals, traditions, and memories in a gentler experience inspired by remembrance and Día de los Muertos.

The interface uses a dark terminal aesthetic, phosphor-green accents, subtle CRT-inspired styling, and a minimal command-line layout.

The central idea is simple: a machine doesn't need to be connected to the cloud to feel alive.

PHANTOM does not automatically inspect your shell history or execute commands. You choose what text to share with it.

Demo

The project currently runs locally.

Run it yourself:

Install Python 3.10 or newer.
Optionally install Ollama to enable local AI inference.
Download the default model:

   ollama pull qwen2.5:3b

Start the application:

   python app.py

On Windows, you can also use py app.py.

Open http://127.0.0.1:8000 in your browser.

The application includes a template-based fallback, so you can explore the interface even when Ollama is unavailable. The fallback works offline but does not generate responses using an LLM.

A public deployment and recorded video demo are not available yet.

Code

Project: PHANTOM Terminal — Ghost in the Machine

The source code includes the Python backend, terminal-inspired frontend, local-model integration, offline fallback, documentation, and automated tests.

Project repository: [https://github.com/Varun-666/ghost-in-the-machine]

Project structure:

ghost-in-the-machine/
├── app.py
├── static/
│   ├── index.html
│   ├── style.css
│   └── app.js
├── tests/
│   └── test_app.py
├── README.md
├── LICENSE
└── .gitignore

The project is licensed under MIT.

How I Built It

I built PHANTOM using Python, HTML, CSS, and JavaScript, with Ollama serving an open-weight language model locally.

The default model is Qwen2.5 3B, which can be replaced with another compatible model by changing the configuration.

The architecture is intentionally straightforward:

The user selects a mode and enters a text fragment.
The frontend sends the input to the local Python backend.
The backend attempts to generate a response using Ollama's local API.
If the model service is unavailable, the application switches to its built-in fallback.
The frontend displays the response in the terminal interface.

The application does not require a hosted AI API, a cloud account, or a paid inference service.

I also included basic input validation, safe rendering of generated text, a prompt-length limit, and automated tests.

The current version is a local web application rather than a fully autonomous agent. It deliberately avoids executing shell commands or accessing system files automatically.

Why Does Open Innovation Matter?

For PHANTOM, open innovation is not just a technology choice. It is part of the project's identity.

A haunted terminal is an interesting experiment, but the idea becomes much more meaningful when the underlying AI can run on your own machine.

1. Privacy by design

A user might want to turn personal notes, old logs, or meaningful memories into a story. Running inference locally means those prompts do not need to be sent to a third-party AI provider.

PHANTOM has no cloud AI API integration, and it does not automatically save prompts or responses. When Ollama is enabled, the application sends prompts to the local Ollama service on the same machine.

2. Offline access

After the required software and model have been downloaded, the application can generate responses without an internet connection. This makes experimentation possible without relying on the availability of an external AI service.

3. Freedom to change models

The model is not permanently tied to a single provider. Users can experiment with different compatible models, compare their writing styles, and adapt the experience to their hardware and preferences.

4. No per-request API fees

Local inference avoids per-request charges from a hosted AI API. It still has hardware, electricity, storage, and setup costs, but there is no mandatory cloud inference bill.

5. Long-term ownership

An application built around replaceable models and an open codebase is easier to inspect, modify, self-host, and maintain independently of a single AI provider.

A closed API could also generate convincing ghost stories. What it would not inherently provide is the same combination of local execution, model choice, inspectable application code, and freedom from a required hosted inference service.

That is the part of open innovation I wanted to explore: making AI something people can run, understand, and adapt themselves.

My Agent Session

PHANTOM currently uses a local model interface rather than an autonomous agent harness. I have not recorded a DevRelay session for this project, so I am leaving this section out rather than linking to a session that does not exist.

The Spirit of It

There is something unsettling about an old computer that still has one process running.

Maybe it is an abandoned game server. Maybe it is a log file with a timestamp that makes no sense. Maybe it is a forgotten program that someone wrote years ago and never finished.

I wanted PHANTOM to capture that feeling without needing an elaborate horror game or an expensive cloud model.

But there is another side to the idea.

For Día de los Muertos, the same technology can be used to preserve the small things that make memories meaningful: a family recipe, a favorite song, a familiar saying, or a story that deserves to be told again.

One mode lets a machine whisper fictional horrors. Another lets it help keep real memories alive.

The machine doesn't have to forget just because we stopped listening.

Sometimes, the most interesting thing about a ghost is what it helps us remember.

Prize Categories

Primary fit: Open-Source AI / Local Inference.

PHANTOM is built around open-weight AI served locally through Ollama, with a replaceable model configuration and a functional offline fallback.

I am entering the main Ghost in the Machine challenge. I have not selected additional partner prize categories because I have not verified which specific partner categories and eligibility requirements apply.

Built for the Hacktoberfest Open-Source AI Challenge — Week 4: Ghost in the Machine.

# LazyDesk: Let Local AI Handle the Mess — Slow and Steady

Varun Fatehpuria — Wed, 21 Oct 2026 05:39:01 +0000

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

What I Built

Ever opened your Downloads folder looking for one file and ended up staring at hundreds of documents, screenshots, archives, and random files instead?

I wanted to build something that could take care of that boring work for me.

Meet LazyDesk, a local-first, AI-assisted file organizer built as a command-line tool. It helps organize cluttered directories by categorizing files, suggesting meaningful filenames, and generating an organization plan that you can review before applying.

The idea is simple: let AI handle the thinking, while predictable rules handle the actual file operations.

LazyDesk is designed to:

Scan directories without modifying files.
Classify files into categories such as Documents, Images, Code, Archives, and more.
Use a locally running AI model to suggest categories and clearer filenames.
Preview proposed changes before applying them.
Keep a local transaction history and support best-effort undo.
Work without a cloud AI API once the dependencies and model are installed.

Instead of spending time manually sorting files every few weeks, you can let LazyDesk prepare the plan and review it when you're ready.

Code

The project is written in Python and follows a modular architecture so that AI classification, planning, filesystem operations, and recovery can evolve independently.

The core principle is that the AI suggests; LazyDesk validates and executes.

Rather than letting a language model manipulate files directly, the application validates its output and generates a proposed plan. File changes happen through a separate, explicit command.

The project is released under the MIT license.

Repository: https://github.com/Varun-666/LazyDesk

How I Built It

I built LazyDesk around Python, Typer, Rich, Pydantic, SQLite, and Ollama.

Here's how the pieces fit together:

Python provides the cross-platform foundation.
Typer handles the command-line interface.
Rich makes scan results and organization plans readable in the terminal.
Ollama provides a local inference interface for an open-weight language model.
Pydantic validates the model's structured output.
SQLite stores transaction history and recovery information.
pytest and GitHub Actions support automated testing and continuous integration.

The workflow has six main stages:

Scan: Collect file metadata without changing anything.
Classify: Use extension-based rules and, when available, local AI suggestions.
Plan: Generate destination paths and check for potential conflicts.
Preview: Display the proposed changes for review.
Apply: Revalidate the plan and execute approved operations.
Recover: Use the transaction history to attempt to undo eligible operations.

The AI provider is kept separate from the core organizer. That means the project can evolve to support different local inference runtimes without rewriting the filesystem logic.

The initial model configuration uses qwen3:4b as an example, but the model can be changed in the configuration. Actual performance depends on the model, hardware, and type of files being processed.

Why Does Open Innovation Matter?

For me, the most important part of this project is not simply adding AI to a file organizer. It's making that AI usable without requiring a cloud AI service.

Personal folders can contain financial documents, study materials, source code, private notes, and other information that users may not want to upload to a third-party service.

By running inference locally, LazyDesk can keep the AI processing on the user's machine when configured correctly.

Open-weight models also make experimentation possible. Users can choose a different model, adjust the instructions, customize categories, and change the classification strategy without being locked into one proprietary AI API.

There are practical benefits, too:

Privacy: File contents can remain on the user's machine instead of being sent to a hosted AI provider.
Control: Users can inspect and modify the code that decides how files are organized.
Flexibility: The model and classification rules can be customized.
Cost: Local inference avoids per-request charges from a hosted AI API, although running the model still uses hardware and electricity.
Offline potential: Once dependencies and model weights are installed, ordinary organization workflows can operate without an internet connection.

Open innovation also means being honest about limitations. Open-weight models have different licenses, resource requirements, and capabilities. They do not automatically guarantee perfect privacy, accuracy, or unrestricted redistribution.

LazyDesk is designed to make those choices more transparent and give users control over their own workflows.

My Agent Session

I haven't attached a DevRelay session yet.

Once I have a shareable development session, I'll add it here so others can follow the implementation process and see how the project evolved.

The Lazy Payoff

The goal is to turn a repetitive, manual task into a short review process.

Instead of opening files one by one, deciding where each belongs, renaming them, and moving them manually, users can generate an organization plan and inspect the proposed changes in one place.

I haven't measured real-world time savings yet, so I won't invent a number. The next step is to test LazyDesk on a representative folder, measure the time required with and without the tool, and evaluate how often its suggested categories and filenames need corrections.

The other important payoff is peace of mind: scanning and planning are read-only, and applying changes requires an explicit command.

LazyDesk is still an early-stage project, so its file operations and recovery behavior need further testing before it should be trusted with important data. Always keep backups of irreplaceable files.

Prize Categories

Primary theme: Slow and Steady — local-first AI that reduces repetitive work.

Technology focus: Open-weight models and local inference through Ollama.

I'll add any specific partner prize categories after confirming the current challenge's eligibility requirements.

The philosophy behind LazyDesk is simple:

You shouldn't need to spend your time organizing everything manually when your own machine can help you do the boring parts.

Build once. Configure it your way. Let the computer do the repetitive work.

Slow and steady.

CraftContent.AI

Varun Fatehpuria — Tue, 13 Oct 2026 06:03:19 +0000

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

What I Built

CraftCopy AI — Product Listings for Handmade Businesses

CraftCopy AI is an AI-powered writing assistant designed for independent makers and small handmade businesses.

Selling a handmade product involves more than making it. Sellers also need to write product descriptions, create social media captions, research searchable tags, and prepare listings for different platforms. For someone running a small shop alone, these repetitive tasks take time away from creating products and serving customers.

CraftCopy AI aims to simplify that process. A seller enters basic product information, such as the product name, materials, dimensions, price, target audience, and key features. The application generates editable product titles, descriptions, social media captions, search tags, and image alt text.

The initial audience is crochet artists, handmade jewellery makers, and independent online sellers.

The side-hustle opportunity is to help these sellers prepare marketing content more efficiently. Future versions could introduce batch listing generation, reusable brand presets, and specialized templates for different product categories.

Code

GitHub repository: [https://github.com/Varun-666/CraftContent.ai]

The project includes a Python backend, a browser-based interface, model integration, a fallback generation workflow, and automated tests.

How I Built It

CraftCopy AI is built with Python, FastAPI, HTML, CSS, and JavaScript.

The AI integration uses Qwen2.5-0.5B-Instruct, an open-weight language model, through Hugging Face Transformers.

The intended workflow is straightforward:

The seller provides structured product details.
The backend prepares the input for the language model.
The model generates draft marketing content.
The seller reviews, edits, and copies the results.

The application also includes a template-based fallback when model inference is unavailable. This keeps the basic workflow accessible while distinguishing fallback output from genuine model-generated content.

The model can be downloaded and run locally, subject to hardware requirements and the model's license. This avoids requiring a paid proprietary model API for every generation request.

Why Does Open Innovation Matter?

I wanted to explore how open-weight AI could make a small business tool more accessible to independent developers and sellers.

A commercial writing tool built entirely around a proprietary API may introduce recurring inference costs, dependency on a third-party provider, and restrictions on how its underlying model can be customized.

Using an open-weight model provides a different approach.

Control over inference: The model can run locally, allowing users to keep product information on their own machines rather than sending every prompt to an external model provider.

Control over costs: Once the model has been downloaded, local inference does not incur a per-request fee from a third-party model API. Hardware, electricity, storage, and maintenance still have costs.

Freedom to experiment: Developers can evaluate different compatible models, adjust prompts, and explore specialized workflows for handmade product categories.

Accessibility: The project can be cloned, inspected, modified, and extended by other developers.

Local operation does require an initial model download and sufficient computing resources. The goal is not to claim that open models are automatically better at every task, but to make experimentation and deployment more accessible without making a proprietary API a mandatory dependency.

For a small side-hustle product, that flexibility matters: it creates room to experiment with different approaches without tying every generation to someone else's pricing and service availability.

My Agent Session

Optional. I will add a DevRelay session if I capture one that demonstrates the development process.

My First User

CraftCopy AI is intended for independent makers and small handmade businesses. The next milestone is to test it with a real seller and collect feedback on listing quality, editing effort, and missing features.

I have not yet established whether a seller would pay for the product, so validating that demand is part of the next stage.

Prize Categories

I will select the applicable partner categories according to the official challenge rules before publishing.

Touchgrass.AI

Varun Fatehpuria — Thu, 08 Oct 2026 09:34:41 +0000

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

What I Built

I built TouchGrass AI, an open-source AI companion designed to help people spend less time on their screens and more time outdoors. 🌱

The idea is simple: use AI for a few seconds, then put the phone away.

Users can choose an activity mode, available time, energy level, outdoor setting, and personal interests. TouchGrass AI then generates a short, practical outdoor mission that they can actually go outside and complete.

The app currently includes three modes:

🌿 Nature — discover and observe things around you
🚶 Explore — generate small outdoor exploration challenges
🌱 Garden — get simple gardening and plant-care activities

It is designed for anyone who wants a simple reason to step outside, whether that's a short walk, exploring a local park, observing nature, or spending some time in the garden.

The goal isn't to make people spend more time interacting with AI.

The goal is to make the AI interaction as short as possible.

Code

💻 GitHub: [https://github.com/Varun-666/touchgrass.ai]

The repository contains the complete application, including the frontend, FastAPI backend, AI integration, prompts, fallback system, PWA support, tests, and documentation.

How I Built It

TouchGrass AI is built around open-weight AI and local inference.

The AI component uses Qwen2.5-0.5B-Instruct, accessed through the Hugging Face Transformers ecosystem.

The basic flow is:

User
  ↓
TouchGrass Web UI
  ↓
FastAPI Backend
  ↓
Qwen2.5-0.5B-Instruct
  ↓
Outdoor Mission
  ↓
Put the Phone Away
  ↓
Go Outside 🌳

The user provides a few preferences such as:

Activity type
Available time
Energy level
Outdoor setting
Interests or goals

The local AI uses these inputs to generate a structured outdoor mission containing a title, description, steps, duration, things to bring, and safety information.

The project uses:

Python
FastAPI
Hugging Face Transformers
Qwen2.5-0.5B-Instruct
HTML/CSS/JavaScript
Progressive Web App support

There is also a fallback system so the application can still provide useful outdoor activities if the AI model is unavailable.

No paid AI API or API key is required.

Why Does Open Innovation Matter?

Open innovation is important to TouchGrass AI because the project is intended to work with people in the real world, not just inside a cloud-based chat window.

🔒 Privacy

Outdoor experiences can involve personal information such as photos, gardens, homes, and surroundings.

With local inference, the project can process AI requests without requiring everything to be sent to a third-party AI provider.

📡 Offline Potential

The places where people want to use TouchGrass AI may not always have a reliable internet connection.

Using an open-weight model gives the project a path toward running the AI locally and eventually supporting completely offline experiences.

🔧 Freedom to Experiment

The AI isn't locked to a proprietary API.

Developers can experiment with:

Different open-weight models
Smaller models
Quantized models
Fine-tuned models
Different prompts
Different local hardware

This makes the project much easier to modify and extend.

💰 Accessibility

There are no per-request API costs.

Once the model is available locally, users can experiment with the application without needing a paid AI API subscription.

For me, that's one of the biggest advantages of open AI: the technology becomes something developers can actually take apart, modify, and build on.

My Agent Session

[Add your DevRelay agent session here if available]

Prize Categories

Touch Grass
Open-Source AI

Less screen. More outside. 🌱

Project TouchGrass.AI for HacktoberFest2026 Week 1

Varun Fatehpuria — Thu, 08 Oct 2026 09:30:49 +0000

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

What I Built

I built TouchGrass AI, an open-source AI companion designed to get people off their screens and into the real world.

The idea is simple:

Use AI for a few seconds. Then put the phone away. 🌱

Instead of building another AI assistant that encourages people to spend more time chatting with a model, TouchGrass AI generates small, practical outdoor missions based on:

🌿 Activity type
⏱️ Available time
⚡ Energy level
📍 Outdoor setting
🎯 Personal interests and goals

The app currently has three modes:

Nature — activities focused on observing and exploring nature
Explore — small outdoor exploration challenges
Garden — simple gardening and plant-care activities

For example, a user can select:

Explore → 30 minutes → Low energy → Park

and receive a short outdoor mission designed to be completed away from the screen.

The goal isn't to keep the user inside the app.

The goal is to make the app unnecessary as quickly as possible.

The ideal interaction is:

10 seconds on the phone → 30 minutes outside. 🌳

Code

GitHub Repository: [https://github.com/Varun-666/touchgrass.ai]

The project is completely open source and includes the application code, AI integration, prompts, fallback system, frontend, backend, and documentation.

How I Built It

TouchGrass AI is built around an open-weight AI model rather than a proprietary AI API.

The AI layer uses:

Qwen2.5-0.5B-Instruct

The model runs locally through the Hugging Face Transformers ecosystem.

The basic architecture is:

User
  │
  ▼
TouchGrass Web UI
  │
  ▼
FastAPI Backend
  │
  ▼
Local Qwen2.5-0.5B-Instruct
  │
  ▼
Outdoor Mission
  │
  ▼
📱 Put Phone Away
  │
  ▼
🌳 Go Outside

The user provides a few simple preferences such as their available time, energy level, environment, and interests.

The local model then generates a structured outdoor mission containing things like:

Mission title
Short description
Steps
What to bring
Safety notes
A suggested duration
A reason for doing the activity

I also included a fallback mission system so the application can still demonstrate its core experience if the AI model isn't available.

The project uses:

Python
FastAPI
Hugging Face Transformers
Qwen2.5-0.5B-Instruct
HTML/CSS/JavaScript
PWA support

No paid AI API or API key is required.

Why Does Open Innovation Matter?

This project is specifically designed around the idea that AI shouldn't always require sending everything to a remote server.

🔒 Privacy

Outdoor activities can involve photos, locations, gardens, homes, or other information about someone's surroundings.

A local AI architecture provides a path toward keeping that information on the user's own device instead of automatically sending it to a third-party AI provider.

📡 Offline Potential

People don't necessarily use TouchGrass AI while sitting next to a perfect internet connection.

The whole point is to use it while going outside.

Using an open-weight model means the project can be developed toward offline/local inference rather than depending entirely on an external API.

🔧 Model Freedom

Because the project isn't tied to a proprietary API, the AI component can be modified or replaced.

Developers can experiment with:

Different open-weight models
Quantized models
Fine-tuned models
Smaller models for mobile devices
Different prompting strategies

The application isn't locked into one company's AI infrastructure.

💰 Accessibility

There is no per-request AI API cost.

That makes experimenting with the project much more accessible for students, hobbyists, and other developers who want to build AI applications without maintaining a paid API subscription.

The Interesting Part

Most AI applications try to maximize the amount of time users spend interacting with them.

TouchGrass AI tries to do the opposite.

A successful interaction isn't:

"I spent 30 minutes talking to the AI."

It's:

"The AI gave me something to do, and then I put my phone away."

That's the behavior I wanted to build around for this challenge.

My Agent Session

[ADD DEVRELAY AGENT SESSION HERE IF AVAILABLE]

Prize Categories

Open-Source AI
Touch Grass

Built with open-source AI for Hacktoberfest 2026. 🌱

Less screen. More outside.