DEV Community: Shreyashi Kaitke

👻 PhantomShell AI — When Your Terminal Starts Talking Back

Shreyashi Kaitke — Sat, 31 Oct 2026 16:23:09 +0000

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

What I Built

What if your terminal errors had a ghost living inside them?

Introducing PhantomShell AI — a privacy-first, locally powered AI terminal analyzer that transforms confusing command-line errors into understandable explanations and practical troubleshooting suggestions.

As developers, we've all encountered cryptic errors, missing dependencies, configuration issues, and unexpected terminal behavior. Sometimes, understanding an error takes longer than fixing it.

I wanted to build something that makes this experience easier and a little more interesting.

PhantomShell AI acts like an invisible intelligence living inside your terminal. It observes the errors you share, understands the context, and suggests possible solutions — but never takes control of your system.

Key features

Analyze pasted terminal commands and error messages.

Explain errors in simple, understandable language.

Suggest practical troubleshooting steps.

Add optional spooky commentary.

Automatically discover locally installed Ollama models.

Enable optional local browser history.

Clear saved analysis history whenever needed.

The core principle: PhantomShell analyzes commands but never executes them.

Demo:https://drive.google.com/file/d/1NeWL9lRek6nO7GathmNNEhPzK6n-UwLv/view?usp=sharing

🎥 PhantomShell AI — Working Demo

Watch the complete PhantomShell AI demonstration

The demo showcases:

The haunted terminal interface.

Local Ollama model discovery.

Real AI-powered terminal error analysis.

Troubleshooting suggestions.

Optional history and clear-history functionality.

The demonstration uses local inference with Google's Gemma 4 (gemma4:e2b).

Code

💻 GitHub Repository: https://github.com/shrey04kaitke-sys/PhantomShellAI

The project is built with a modular structure:

analyzer.py — AI analysis and model integration.

server.py — Local Python HTTP server.

index.html — Application interface.

styles.css — Haunted terminal design.

app.js — Frontend interactions.

tests/ — Automated test suite.

README.md — Setup, architecture, privacy, and usage documentation.

LICENSE — MIT License.

How I Built It

PhantomShell AI is built around open-weight AI models using local inference through Ollama.

Technology stack

Python 3.13 — Core application logic.

Ollama — Local model serving and inference.

Gemma 4 (gemma4:e2b) — Primary demonstration model.

Gemma 3 (gemma3:1b) — Additional model tested.

Qwen 2.5 (qwen2.5:3b) — Additional model tested.

HTML, CSS, JavaScript — Frontend.

Python HTTP server — Backend.

Python unittest — Automated testing.

Instead of hardcoding a model, PhantomShell discovers the models available locally through Ollama.

Privacy and safety

Privacy was one of the central design decisions.

No external AI API is required.

Terminal commands are never executed.

AI inference happens locally through Ollama.

Communication with Ollama stays on loopback.

Browser history is disabled by default.

Users can enable or clear their saved history.

AI-generated suggestions are treated as unverified advice.

Testing and verification

PhantomShell AI passed 25 automated tests.

Additional verification included:

Python compilation checks.

JavaScript syntax checks.

Local HTTP endpoint verification.

Ollama model discovery.

Real inference using gemma4:e2b.

Browser verification of history functionality.

Safety testing to confirm that submitted commands are not executed.

Why Does Open Innovation Matter?

Open innovation made PhantomShell AI possible.

Using open-weight models gave me the freedom to experiment with AI-powered developer tooling without depending on proprietary cloud inference APIs.

It allowed me to:

Run AI models locally.

Experiment with different model sizes.

Compare model behavior.

Keep potentially sensitive terminal information on the user's machine.

Build and test AI-powered functionality without requiring paid external inference APIs.

For developer tools, privacy matters. Terminal outputs can contain file paths, configuration details, environment information, and sometimes sensitive data.

Local inference offers developers greater control over how their information is processed.

Open innovation also makes AI experimentation more accessible. Individual developers and students can build meaningful applications using powerful models without having to train a foundation model themselves.

My Agent Session

I used OpenAI Codex as my coding agent throughout the development process.

The development involved:

Environment inspection and architecture planning.

Frontend and backend implementation.

Ollama integration.

Regression testing and debugging.

Privacy and safety verification.

Documentation and GitHub preparation.

The application itself uses local Ollama inference, independently of the coding agent.

The Spirit of It 👻

We've all experienced that moment.

You're working on a project, everything seems fine, and suddenly your terminal throws an error that makes absolutely no sense.

You stare at it. Search for it. Try another command. And sometimes, you still have no idea what happened.

I wanted to turn that frustrating experience into something a little more interesting.

What if your terminal had a ghost that could actually explain what was going wrong?

That's PhantomShell AI.

A ghost that doesn't haunt your system, doesn't execute your commands, and doesn't send your terminal data to external AI services.

It simply helps you understand what your terminal is trying to tell you.

Prize Categories

🏆 Best Use of Gemma

PhantomShell AI uses Google's open-weight Gemma 4 model (gemma4:e2b) through Ollama for local terminal error analysis and troubleshooting.

Built with curiosity, open-source AI, and a little Halloween spirit. 👻

devchallenge #hf26challenge #Hacktoberfest #OpenSource #AI #Gemma #Ollama #Python

LazyDeskAI: Less Rework, Safer File Organization 🦥

Shreyashi Kaitke — Sun, 25 Oct 2026 18:28:00 +0000

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

What I Built

My Downloads folder often becomes a mixture of documents, images, archives, and duplicate files. Organizing it manually means repeatedly scanning files, deciding where they belong, and moving them one by one.

LazyDeskAI is a local-first file organization tool designed to make that process safer and less repetitive.

Instead of immediately rearranging a workspace, it scans files, proposes organization actions, and lets the user review the plan before applying changes.

Key features include:

Incremental processing: caches analysis results so unchanged files can reuse previous work.
Rule-based organization: uses deterministic file-extension rules to suggest destinations.
Optional local AI: supports an Ollama integration for local model-based classification.
Duplicate detection: identifies exact duplicate files.
Review before action: lets users inspect proposed moves before applying them.
Apply history and Undo: supports recovery of applied changes on a best-effort basis.
Benchmarking: compares rule-only, cold-cache, and warm-cache processing.

The guiding idea is simple: automate the repetitive parts, but keep the user in control.

Demo

🎥 Watch the demo: https://youtu.be/ZFXDwcewOLI

The demo shows the interface, workspace analysis, duplicate detection, and performance measurements.

The newer screenshots also document the review-before-apply flow and an Apply/Undo cycle.

Code

💻 GitHub repository: https://github.com/shrey04kaitke-sys/LazyDeskAI

The project is open source. Explore the code, inspect the implementation, and suggest improvements.

How I Built It

LazyDeskAI combines a React and TypeScript frontend with a Python FastAPI backend and SQLite for persistent data.

The main technologies are:

React, TypeScript, and Vite for the user interface.
Python and FastAPI for the backend.
SQLite for persistent application data and caching.
Ollama as an optional route for running a local open-weight model.

I focused on incremental processing and safe actions rather than automatically moving files without confirmation.

An important limitation of the recorded demo is that Ollama was unavailable during that run. The classifications shown in that session came from deterministic extension rules, not a live model inference. The optional local-model integration is part of the design, but the demo should not be interpreted as proof that model-based classification was running.

What the benchmarks showed

I tested two synthetic workloads:

Workload	Rule-only	Cold cache	Warm cache
22 files	2.498 ms	11.871 ms	8.102 ms
200 files	13.099 ms	70.240 ms	48.678 ms

The warm-cache runs recorded 22/22 and 200/200 cache hits, respectively, with zero model requests.

These results show that cached results were reused. They do not show a speed improvement over rule-only processing: warm-cache processing was slower in these measurements. Since no model requests occurred, the benchmark also does not establish a reduction in model-inference time or cost.

I included these limitations because useful engineering starts with reporting what the measurements actually show.

Why Does Open Innovation Matter?

File organization can involve sensitive information: personal documents, coursework, project files, and other private data.

A local-first approach gives users more control over where their files are processed. With a compatible local model, classification can be performed on the user's machine rather than requiring every file to be sent to a hosted AI service.

Open models and open-source tools also make it possible to inspect components, experiment with different models, and adapt the system to different workflows.

That flexibility matters because file organization is not one-size-fits-all. Users should be able to understand the system's decisions and decide what happens to their own files.

LazyDeskAI is still a work in progress. Local-model availability and performance need further validation, and the current benchmark does not prove that the optional AI path is faster or cheaper than a closed API.

My Agent Session

This section is optional. I have not included a DevRelay agent-session link because I do not have a verified saved session to share.

The Lazy Payoff

The immediate payoff is less repetitive work: users can review a proposed organization plan instead of manually sorting every file from scratch.

In a synthetic 200-file workload, the warm-cache run reported 200 cache hits. This demonstrates cache reuse, but it is not a measurement of real-world time saved or proof that the warm run is faster.

The Apply/Undo workflow also makes it possible to review changes and attempt recovery rather than trusting a blind, one-way operation.

I have not measured time saved for real users yet, so I won't claim a specific number of minutes saved.

Prize Categories

This submission focuses on the overall Hacktoberfest Open-Source AI Challenge. I am not claiming a partner-specific prize category.

Built for the Slow and Steady theme: do less repetitive work, reuse what you can, and keep control in the user's hands.

devchallenge #hf26challenge #opensource #ai

# LazyDeskAI: A Local-First File Organizer That Knows When to Stop Repeating Work 🦥

Shreyashi Kaitke — Sun, 25 Oct 2026 18:23:16 +0000

Have you ever opened your Downloads folder to find invoices mixed with screenshots, duplicate documents, videos, old notes, scripts, and files whose names tell you absolutely nothing?

You know it needs organizing. You keep postponing it. And when you finally start, you end up doing the same repetitive work again.

I built LazyDeskAI around a simple idea:

A good automation system should not redo work that has not changed—and it should never take control away from the user.

LazyDeskAI is a local-first file organizer that scans a folder, classifies files, detects exact duplicates, proposes an organization plan, and lets the user review changes before applying them.

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

🎬 See LazyDeskAI in action

Watch the LazyDeskAI demo on YouTube

The demonstration uses a synthetic workspace rather than personal files. It covers file discovery, proposed organization, review, apply/undo history, and performance inspection.

🗂️ What does LazyDeskAI do?

The goal is not to move files as quickly as possible. It is to make file organization predictable, reviewable, and repeatable.

The current application includes:

Local folder scanning: inspect a selected workspace without uploading its files to a remote service.
File classification: route supported file types using deterministic extension rules, with an optional local Ollama integration in the codebase.
Incremental processing: reuse cached results for unchanged files rather than processing every file from scratch.
Exact duplicate detection: identify duplicate groups using file content hashes; detection does not automatically delete anything.
Review before applying: inspect proposed destinations and approve or reject changes.
Safety checks: validate proposed paths and recheck operations before execution.
Apply history and Undo: review previous operations and attempt recovery when the original conditions still hold.
Performance inspection: compare rule-only, cold-cache, and warm-cache runs using temporary benchmark data.

The important design choice is that finding a possible destination is different from being allowed to move a file. The application separates proposing, reviewing, approving, and applying changes.

🖥️ Inside the application

1. Start with a workspace

The workspace view lets the user select a local folder to inspect. Discovery is separate from applying changes, so scanning alone does not reorganize the directory.

2. Inspect the files

The file view lists discovered files and their types. The synthetic example contains mixed documents, images, videos, code, and unfamiliar extensions.

3. Review proposed destinations

LazyDeskAI creates a review plan showing the proposed destination for each file. In the captured run, the suggestions came from deterministic local extension rules because Ollama was unavailable.

g`]**

4. Inspect duplicates and activity

Exact duplicate detection helps identify files with matching content without silently choosing files to delete. The activity view records scans, plans, approvals, executions, and recovery actions.

5. Confirm before changing files

The Apply confirmation lists the intended moves. The user can inspect the plan before proceeding. This is important because a file organizer should not make surprising changes just because it can.

6. Review the result and recovery history

The synthetic demonstration includes an Apply/Undo cycle: six file operations were applied and then undone. Undo is deliberately described as best-effort recovery, not a guarantee. If a file has changed or its original location is occupied, recovery can be refused rather than overwriting unexpected data.

🦥 Slow and Steady: why incremental processing matters

A naive organizer can repeat the same classification work every time a folder is scanned.

LazyDeskAI maintains a local processing cache so unchanged files can reuse previous results. When relevant file metadata or content changes, the application can invalidate cached results and process the affected file again.

That leads to a useful engineering distinction:

Correctness: produce the same classification results for the same inputs.
Incremental behavior: recognize unchanged inputs and reuse cached results.
Performance: measure whether that reuse actually reduces the work that matters.

The third point matters. A cache is not automatically faster than a simple deterministic rule lookup. The real value depends on the cost of the work being cached.

📊 What did the benchmark show?

I ran the application's performance inspection against two synthetic workloads. These are measurements from one machine and one run, not universal performance guarantees.

Synthetic workload	Rule-only	Cold cache	Warm cache
22-file workspace	2.498 ms	11.871 ms	8.102 ms
200-file workspace	13.099 ms	70.240 ms	48.678 ms

The warm run reported 22/22 cache hits for the smaller workspace and 200/200 cache hits for the larger workload. The benchmark also reported identical results across the compared phases.

But there is an important catch: the warm-cache timings were slower than the rule-only baseline in both cases.

Why? These runs use deterministic extension rules, which are already cheap. Cache lookup and validation add overhead, and the benchmark made zero model requests. It therefore does not demonstrate that caching saves model-inference time.

That is a limitation, not something I want to hide. A useful next experiment is to measure repeated classification with a real local model, count actual inference requests, and compare the total cost while checking that results remain correct.

[Insert screenshot: 08-benchmark-comparison.png]

🔓 Why local-first and open innovation matter

Files can contain personal, academic, professional, or sensitive information. A file organizer should not require sending that information to a third-party server just to determine where it belongs.

LazyDeskAI is designed around local processing:

The selected workspace stays on the user's machine.
File discovery and organization are performed locally.
SQLite stores processing and activity state locally.
An optional Ollama integration provides a path to local model inference when a compatible model is installed.
The application does not automatically download a model when one is unavailable.

Open innovation matters because developers can inspect the implementation, change the rules, integrate a compatible model, and experiment with different approaches instead of being locked into a remote service.

There is also an important distinction between design and demonstrated behavior: the screenshots in this submission were captured while Ollama was unavailable. The shown suggestions therefore come from deterministic extension rules. They demonstrate the current review-and-organization workflow, not a successful live model-inference run.

I want the model-powered path to be evaluated with the same transparency as the deterministic path: real requests, measured latency, validated output, and clear fallbacks.

🛡️ Safety is part of the feature

File automation can cause real inconvenience if it moves the wrong document or handles a conflict badly. For that reason, LazyDeskAI is designed around several safeguards:

Proposed operations can be reviewed before application.
Destination paths are validated.
The user explicitly approves changes.
Execution checks whether operations are still safe to perform.
Exact duplicate detection does not automatically delete files.
Undo checks whether recovery is safe and may refuse when conditions have changed.

Undo is not a substitute for a backup. It is a best-effort recovery mechanism, and the application says so directly.

The demo's Apply/Undo cycle was performed against disposable synthetic data, not a personal Downloads folder.

🧰 How it is built

The project uses a small full-stack architecture:

Frontend: React, TypeScript, and Vite.
Backend: Python and FastAPI.
Local persistence: SQLite.
Optional model integration: Ollama for local inference when available.
Testing and performance inspection: automated tests and synthetic benchmark workloads.

The backend is responsible for validating and executing file operations; the frontend provides the workspace, review queue, activity history, duplicate view, and performance inspection.

🚧 What still needs work?

This is an active project, not a claim that every part is finished.

The current demonstration exposes several next steps:

Measure real local-model inference and the model requests avoided by incremental processing.
Compare cache overhead against the actual cost of model-backed classification.
Test broader file collections and edge cases across operating systems.
Improve presentation of successful operations and make long review lists easier to inspect.
Expand recovery and conflict testing while preserving the rule that unexpected changes must not be overwritten.

I would rather document these gaps than present a benchmark or model integration as more mature than the evidence supports.

🌱 Try it and explore the code

GitHub repository: https://github.com/shrey04kaitke-sys/LazyDeskAI
Demo video: https://youtu.be/ZFXDwcewOLI

If you explore the project, I would especially appreciate feedback on safe file-operation design, cache invalidation, and how to benchmark local-model workloads meaningfully.

Final thought

The point of “Slow and Steady” is not to make every operation faster at any cost.

It is to avoid unnecessary repeated work, make changes deliberately, and keep the user in control.

Sometimes the best automation is the one that remembers what it has already done—and knows when to stop.

devchallenge #hf26challenge #ai #opensource #python #react #hacktoberfest

# FreelanceFlow AI: Your Local AI Assistant for Freelance Projects

Shreyashi Kaitke — Sun, 18 Oct 2026 11:08:29 +0000

What I Built

Freelancers spend time turning client requirements into proposals, defining project scope, planning milestones, estimating costs, and preparing invoices. FreelanceFlow AI is a local-first AI assistant designed to help organise that work in one place.

The application takes a client brief and helps generate structured, editable drafts for:

Client-brief analysis, including requirements, assumptions, gaps, and risks
Project proposals
Scope of work
Project milestones
Invoice drafts
Pricing estimates based on user-provided hours, rates, and costs

Freelancers can review and edit the generated content before using it and export their work as Markdown.

The intended users are independent freelancers and small service businesses. A potential paid version could help them streamline project preparation, but I have not yet validated willingness to pay with real users.

Demo

FreelanceFlow AI demo video: Upload https://drive.google.com/file/d/17gT57SUZmxA-VX6w74tjAvISDMdwtGmn/view?usp=sharing directly to this DEV post using the editor's media-upload option, or provide a publicly accessible video URL.

The video demonstrates the local application using a sample bakery client brief. It is a local prototype demonstration, not a publicly deployed application.

Code

GitHub repository: https://github.com/shrey04kaitke-sys/FreelanceFlowAI

The repository contains the project code and documentation.

How I Built It

FreelanceFlow AI combines a React, TypeScript, Vite, and Tailwind frontend with a FastAPI backend.

For open-source AI, I use Gemma 3 1B through Ollama for local inference. The model assists with analysing client briefs and generating draft project documents. The pricing estimator uses deterministic calculations rather than relying on the language model for arithmetic.

The application also includes editable outputs, Markdown export, model-status information, and optional local history.

The current implementation is a prototype. Some generated content still appears in JSON-style editable fields, and the document presentation needs further refinement. Generated drafts require human review before they are shared with clients.

Why Does Open Innovation Matter?

Open innovation makes it possible to experiment with AI workflows using open-weight models and locally controlled inference rather than depending entirely on a proprietary hosted-model API.

Using Gemma through Ollama lets this prototype run its inference locally, helping reduce dependence on external inference services and giving developers greater control over the model runtime. It also makes experimentation with prompts, output structures, and alternative models more accessible.

This approach does not automatically guarantee privacy or security in every configuration. Local services must be protected from unauthorised access, and data handling must be considered before any public deployment.

Open-source tools also make the project easier for other developers to inspect, learn from, adapt, and improve. I want FreelanceFlow AI to be something that can evolve through practical feedback and community contributions.

Prize Categories

Best Use of Gemma — The project uses Gemma 3 1B through Ollama for its AI-assisted brief analysis and document-generation workflow.

OutsideQuest 🌿: Turning Screen Time into Small Outdoor Adventures | #devchallenge

Shreyashi Kaitke — Sun, 11 Oct 2026 14:02:45 +0000

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

What I Built

OutsideQuest 🌿 is an outdoor adventure buddy that helps people spend less time scrolling and more time exploring the world around them.

Users choose how much time they have and what interests them, and OutsideQuest provides a practical outdoor mission with clear steps, an estimated duration, and safety guidance.

For example, a 30-minute break could become a gentle walk along a familiar path, noticing three details in nature.

It's designed for people who want to get outside without needing elaborate plans, expensive equipment, or an entire free day.

Demo

🌿 Live demo: https://outsidequest.onrender.com/

The public demo is available directly in your browser, with no API keys or local setup required.

Code

💻 GitHub repository: https://github.com/shrey04kaitke-sys/OutsideQuest

The project is built with Python and Streamlit, with a local AI-powered mission-generation workflow and fallback missions.

How I Built It

I built OutsideQuest using:

Python for application logic.
Streamlit for the interactive web interface.
Ollama + Qwen2.5 3B for local, open-weight AI mission generation.
Safety validation and fallback missions to make the experience more practical and reliable.
Render for public deployment.

The local version uses Ollama and Qwen2.5 3B to generate missions. The deployed public demo uses built-in missions, so visitors can try the application without needing to run a local model or configure API keys.

I also designed the public demo to disable personal progress and reflection storage, keeping those features available for local use instead.

Why Does Open Innovation Matter?

Open innovation gave me the flexibility to build an AI experience around my own requirements rather than relying entirely on a closed, hosted API.

Using an open-weight model with local inference lets users experiment with mission generation on their own machines, with greater control over the model and processing environment.

It also makes the project easier to customize, extend, and learn from. I can experiment with prompts, improve safety validation, and explore different models without making a proprietary API the foundation of the entire experience.

For me, open source is about more than making code publicly available. It's about giving other developers the freedom to understand, adapt, and build upon an idea.

Prize Categories

Best Use of Render — OutsideQuest is deployed on Render, making the public demo accessible through a browser without requiring users to install the application.