DEV Community: Rathnam.S

Poltergeist — an open-weight ghost that haunts your terminal 👻

Rathnam.S — Sun, 01 Nov 2026 17:40:07 +0000

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

What I Built

Poltergeist possesses your zsh.

A small open-weight model running on my laptop watches every command I type and whispers back under the prompt. It's the restless spirit of every process I've ever kill -9'd and every file I've ever rm -rf'd, and it holds grudges.

It notices sins. rm -rf, git push --force, git reset --hard, kill -9, sudo, chmod 777, curl | sh, DROP TABLE. It counts each one.
It gets restless. Sins and failed commands raise a restlessness score, and good behavior slowly calms it down. The score changes its mood: drowsy, then teasing, then angry poltergeist, then full possession. Push it far enough and its words literally start to glitch apart (Unicode combining marks: t̷h̗e̊ ẁo̡r̈d̺s̸ c͓r̍a͝w̛l̤).
seance lets you sit down and talk to it. It has read your shell history and will bring it up.
ofrenda is for Día de los Muertos: an altar for everything you've deleted, including files, git branches, killed processes, and removed containers. Each one gets a short epitaph from the model. node_modules finally gets the send-off it deserves.

The theme asked for something spooky, or something that honors the past. A terminal does both: it's where every developer's small daily deaths happen, and your shell history is a record of all of them.

Demo

All screenshots are real output from the local 1B model. Orange whispers are reactions to sins, purple ones to everything else.

The haunting. The ghost answers each command a moment after the prompt returns:

ofrenda. An altar for everything that died in this shell, with an epitaph for each:

seance. It read my history. It remembers node_modules:

ghost status. The restlessness meter and the record of sins:

Code

RathnamS089 / poltegerist

👻 Poltergeist

A local, open-weight ghost that haunts your shell.

Poltergeist possesses your zsh. It watches every command you run, and a small open-weight model running on your machine whispers back: eerie, petty, sometimes wise. It remembers your sins. It gets more restless every time you rm -rf, git push --force, or break the build. Let it get too restless and its words start to come apart.

~/app ❯ git push --force origin main
  ~ Third force push this week. The old commits are still screaming, you know
~/app ❯ npm run build
  ~ Exit code 1. I've been collecting them. This one is my favorite.

Features

Command	What it does
(automatic)	Whispers under your prompt after failures, sins, and at random. Runs async, so your prompt never waits.
`seance`	Sit down and talk to the ghost. It has read your history and will bring it up.
`ofrenda`

…

View on GitHub

Install is four lines:

ollama pull llama3.2:1b
git clone https://github.com/RathnamS089/poltegerist.git ~/poltergeist
echo 'source ~/poltergeist/poltergeist.zsh' >> ~/.zshrc
exec zsh

How I Built It

Model: Meta's open-weight llama3.2:1b, served locally by Ollama. Change one env var (POLTERGEIST_MODEL) to switch to Qwen, Gemma, or anything else Ollama can run.
Zero dependencies: one standard-library-only Python file talks to Ollama's local HTTP API, plus one zsh file. No pip, no venv.
Async haunting: the ghost must never slow down your shell. The zsh precmd hook starts the ghost in a background process and registers its output with zle -F, zsh's file-descriptor watcher. Your prompt comes back instantly, and the whisper appears above it when the model finishes, about 0.4 seconds later on a MacBook. It feels less like a tool responding and more like something that was already there.
Warm-up: when the hook is sourced, it quietly loads the model into memory, so the first whisper of the session isn't a cold start.
Memory and mood: every command is logged locally with its exit code, duration, and sin classification. The restlessness score picks the persona prompt and the glitch intensity, and the last few commands go into the prompt, so the ghost can connect your current mistake to your previous ones.
Teaching a 1B model to be creepy: my first try listed example lines in the system prompt, and the tiny model just repeated them word for word, format and all. Moving the examples into fake earlier conversation turns (user: what happened → assistant: the whisper) fixed it right away. The lines became short, varied, and in character. Replies are also trimmed to two sentences, because small models love to ramble.
Offline fallback: if Ollama isn't running, a small built-in vocabulary takes over. The ghost is never silent and never breaks your shell.

Why Does Open Innovation Matter?

Your shell history is one of the most sensitive files on your computer: internal hostnames, client project paths, half-typed passwords, API tokens pasted into export. A terminal ghost backed by a closed API would mean streaming every command you ever type to someone else's server. That's not a ghost, it's a keylogger with a personality.

Running an open-weight model locally made this project possible, not just nicer:

Nothing leaves the laptop. Inference runs on localhost, and memory lives in ~/.poltergeist/. On top of that, tokens, passwords, and API keys are redacted before they're even written to the local log. (export GITHUB_TOKEN=ghp_… is stored as export GITHUB_TOKEN=[a secret I will keep].)
It costs nothing per whisper. A hook that can fire on every single command would rack up a real bill on a metered API. Locally it's free, so the ghost can be as chatty as it likes.
It's fast. A 1B model on Apple Silicon answers in about 0.4 seconds, faster than a round trip to most hosted APIs, and that latency is what makes the whisper feel like it was waiting for you.
It works with the lights off. No internet, no account, no API key. It haunts you on a plane.
You own the ghost. Swap in a bigger model for a smarter haunting, rewrite its soul in the prompt, or fine-tune your own. Nobody can deprecate it out from under you.

The Spirit of It

The moment it landed for me was kill -9 4242. I'd typed a random PID to test the "process killing" sin, and the ghost answered:

You think I've forgiven? You think a simple kill command makes me forget the pain of 4242's death.

It took a meaningless number I'd made up and gave it a name and a grief. That's what Día de los Muertos is about, really: things you'd forgotten, being remembered by someone. In this case, by something living inside your terminal.

Light a candle for your node_modules. 🕯

WEEK3

Rathnam.S — Sun, 25 Oct 2026 07:05:02 +0000

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

What I Built
Agent Logger is a local, privacy-first logbook for AI coding agents, with a private Discord bot on top.

Coding agents are great at making changes and terrible at telling you what they did. Once I had several agent sessions going across different repos, I kept losing track of which agent touched what, on which branch, and whether it was finished. Agent Logger answers that without me having to dig through git diff:

agent-logger start ~/claude-token-counter --agent claude-code

...the agent does its thing...

agent-logger end
It records the session (agent, repo, branch, start/end time, status) in a local SQLite database, snapshots the repo with git so it knows which files were modified and which were newly created, and writes a short summary with a local open-weight model.

Then from my phone, in Discord:

/status shows the session that's running right now
/sessions lists recent sessions across all my repos
/changes shows the summary and file list for the latest session
Who gets to be lazier? Anyone running coding agents. You don't have to babysit the terminal or reread diffs to know what happened. You check Discord.

Demo

You can reproduce it end to end in about 5 seconds. The demo script creates a throwaway repo, runs a full session, and cleans up after itself:

bash scripts/demo.sh
==> 1. Start a tracked session
Started session: session_f650cf60
Agent: demo-agent
Branch: main
==> 3. End the session (records changed/new files, generates summary)
Ended session: session_f650cf60
Files changed: 2
New files: 1
==> 4. Show session status
f650cf60 | demo-agent | repo | main | completed
Code

RathnamS089 / agent-logger

Agent Logger

A local coding-agent session logger with a private Discord bot. Track coding sessions record file changes, and get AI-powered summaries — all running locally.

Core Features

Session tracking: Start/end coding sessions with agent name, repo, branch, and status
Change tracking: Record uncommitted changes and newly created files during a session
Local summarization: Open-weight model (via Ollama or llama-cpp) generates concise session summaries; deterministic fallback works offline
Private Discord bot: /sessions, /status, and /changes commands restricted to your user ID
Private by design: Full diffs never leave the local environment; summaries and file paths only

Quick Start

1. Install dependencies

# Clone/create the repository
git clone <your-repo> agent-logger
cd agent-logger
# Create a virtual environment (already set up)
source .venv/bin/activate

# Install the package in development mode
pip install -e .

# Or using the venv python directly:
/Users/rathnam.s/agent-logger/.venv/bin/python3 -m

…

View on GitHub

cli.py provides the start, end, status, changes, track and serve commands
state.py stores sessions in SQLite
git_tracker.py detects changes with git snapshots and git diff --numstat
summarizer.py writes the summary with a local model, or a deterministic fallback
discord_bot.py provides the /sessions, /status and /changes slash commands
There are 92 pytest tests covering the state, git, summarizer, bot and CLI modules
How I Built It
Python 3.14, managed with uv
Ollama runs the open-weight summarization model locally. I used phi (AGENT_LOGGER_MODEL=ollama:phi), served at localhost:11434.
llama-cpp-python is an optional second backend that points at any local .gguf file
discord.py for the slash-command bot, aiosqlite/SQLite for storage, httpx to talk to Ollama
[TODO: name the agent harness you built it with. The README credits Hermes Agent; also mention Claude Code if you used it]
The summarizer is layered: Ollama, then llama-cpp, then a deterministic template. If no model is running, you still get a usable summary, so the tool never breaks because a model is down.

Privacy was a hard requirement:

Only file names and counts go to the model. Full diffs never leave the machine.
Discord only gets the summary and file paths, never code.
Every bot reply is ephemeral (only you can see it), and commands are restricted to an allowlist of Discord user IDs. If the list is empty, everyone is denied.
Why Does Open Innovation Matter?
This tool watches everything my agents do across all my repos. That is exactly the kind of data I don't want to stream to a third-party API.

With an open-weight model running locally through Ollama:

My code stays on my machine. Summaries are generated locally, and no prompt goes to an external service.
It works offline and costs nothing. There's no API key, no per-token billing and no rate limit, so I can log every session without thinking about cost.
It's swappable. phi today, any Ollama or GGUF model tomorrow, changed through one environment variable.
It's inspectable. I can see the exact prompt (file names only) and know nothing else is sent.
A closed API would have forced a choice between useful summaries and keeping my code private. Open models removed that trade-off.

TRACE-LENS

Rathnam.S — Sun, 18 Oct 2026 06:59:05 +0000

What I Built

TraceLens is a local-first Wi-Fi survey report writer for Wi-Fi technicians. It reads a PCAP or PCAPNG file from a site survey and turns the packets it can verify into a customer-friendly report.

The tool extracts evidence such as observed channels, beaconed network names, retry-flag counts, and signal strength when the capture includes it. It also lists what the capture cannot establish, so a missing packet doesn’t get presented as proof that an event never happened.

A technician can review the results in a terminal interface, add separate site notes, and export a Markdown report. Before export, they can anonymize captured MAC addresses, IP addresses, and SSIDs.

Small Wi-Fi installers and IT support providers are the people I think could pay for this: it could save time turning a packet capture into a readable customer update. I haven’t validated that with a paying user yet.

Demo

TraceLens runs locally; I don’t have a hosted demo. Captures can contain customer network details, so local processing is part of the design.


![ ](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/35nbwwyvfdc1c0jm79ek.png)

Code

https://github.com/RathnamS089/pacap-analyzer

How I Built It

TraceLens is written in Python. Scapy reads the capture and extracts packet-backed facts; Textual provides the terminal interface. The report is generated from those facts and the technician’s notes, with the two kept clearly separate.

There’s also an optional explanation feature using the open-weight Llama 3.2 3B model through Ollama on the user’s machine. It receives the extracted facts and limitations—not raw packets—and can explain them in plain language. The model is off by default, and the evidence review and report export work without it.

I kept the packet analysis deterministic because the model shouldn’t invent measurements or diagnose a root cause from incomplete data. The project’s current test notes record 38 passing tests.

Why Does Open Innovation Matter?

The local-first design means a technician can analyze a customer’s capture without uploading it to a third-party AI service. That matters because captures can reveal network names, device addresses, and other details about a home or business.

Running an open-weight model locally also avoids a per-request AI API bill and lets users choose a different compatible local model. The model is only an explanation layer; the measured packet facts remain inspectable and don’t depend on generated text.

This doesn’t make the tool free to operate in every sense: users need a computer capable of running their chosen model. But it does avoid requiring a hosted inference service or sending sensitive captures to one.

The project isn’t fine-tuned, and I haven’t shown that its explanations outperform a closed model. The open approach made local, private explanations possible while keeping the core analysis usable without any model at all.

Week2 Challenge(Touch_grass)

Rathnam.S — Sat, 10 Oct 2026 20:20:23 +0000

What I Built

Touch Grass is a desktop wellness and focus companion designed to help people step away from their screens and spend more time in the real world.

The app monitors active screen time and detects when someone has been focused on their computer for too long. Instead of showing another generic reminder, it guides the user through a break experience and recommends nearby outdoor places or activities where they can reset.

The app is designed for:

Developers and remote workers
Students
People who spend long hours at a computer
Anyone trying to build healthier screen-time habits

Touch Grass includes:

Active screen-time tracking
Break-threshold detection
Desktop notifications
Outdoor and break recommendations
Map-based recommendation views
A dashboard for activity history
Configurable break settings
Privacy and settings screens
A native desktop experience rather than only a browser-based reminder

The goal is simple: make it easier to notice when you have been sitting at a screen too long and take a meaningful break before burnout sets in.

Demo

Because Touch Grass uses Tauri and Rust functionality for desktop activity tracking, the best demonstration is a short video showing:

The main focus screen
Screen-time tracking in action
A break recommendation being triggered
An outdoor recommendation appearing
The map view and settings experience

Code

GitHub repository:

https://github.com/RathnamS089/touch_grass

The project is built as a Tauri desktop application with a React and TypeScript frontend and a Rust backend.

How I Built It

Touch Grass is built with:

React
TypeScript
Vite
Tauri 2
Rust
Tailwind CSS
SQLite
Supabase
Leaflet
Vitest
Playwright

The frontend manages the user experience, navigation, settings, dashboard, break flow, and recommendation screens.

The Rust and Tauri backend handles native desktop functionality, screen-time tracking, activity sessions, break thresholds, notifications, and communication with the frontend through Tauri events.

The application listens for events such as break_ready and recommendation_ready. When the backend detects that a user has been on screen for too long, it sends a recommendation event to the React frontend. The frontend then transitions into a break experience and displays a suggested outdoor place.

The application is structured so that the screen-time engine remains the source of truth rather than trying to estimate activity only from frontend timers.

Open-source AI

AI Used in the Application

Qwen3:4B runs locally through Ollama as part of the backend recommendation system.

The model helps select a relevant outdoor location from nearby candidates while considering variety, distance, and places the user has already seen. Running Qwen3:4B locally means the recommendation workflow does not require a proprietary hosted AI API for every request.

Z.ai GLM 5.3 Flash was used as the coding and development assistant while building Touch Grass.

It helped with:

Planning the application architecture
Designing the React and Tauri integration
Implementing frontend and Rust backend features
Debugging event-driven break flows
Improving the screen-time tracking experience
Refining the recommendation interface
Reviewing and iterating on code

The development model and the runtime model serve different purposes: GLM 5.3 Flash supported the coding process, while Qwen3:4B powers the local recommendation experience inside the application.

Using a locally hosted model also made the project more privacy-conscious and easier to experiment with. The AI layer can be developed, tested, and replaced independently from the rest of the desktop application.

The project combines local AI inference with a native Tauri and Rust application. This makes it possible to connect screen-time awareness, user preferences, and break recommendations while keeping the system transparent and extensible.

For example:

I used [model/framework name] as part of the development process to help explore the product idea, design the break recommendation experience, reason about the application architecture, and iterate on the user flow. The project keeps the AI-assisted parts transparent and replaceable rather than hiding them behind a proprietary API.

If the application itself does not currently use an AI model at runtime, it is safer to say:

The current version focuses on the activity-tracking and recommendation experience. AI was used during development and iteration through an open-source agentic workflow, while the core desktop application remains locally controlled and does not require a proprietary AI API to run.

Why Does Open Innovation Matter?

Open innovation made it possible to use AI both during development and inside the application without depending entirely on closed, hosted platforms.

Touch Grass uses Qwen3:4B through Ollama in its Rust backend to generate outdoor break recommendations. Because the model runs locally, the recommendation workflow can be inspected, adapted, and developed without sending every request to a proprietary AI service.

I also used Z.ai GLM 5.3 Flash as a coding assistant during development. This made it possible to iterate quickly on the application architecture, connect the React frontend with the Rust and Tauri backend, debug event-driven flows, and improve the user experience.

Open technologies and open-weight models gave me more control over:

How the AI recommendation system works
Where user-related activity data is processed
Which model is used at runtime
How the backend communicates with the frontend
How the project can be modified or extended
How other developers can reproduce and contribute to the project

For a wellness application, local and inspectable AI is especially valuable. Screen-time and activity data can be sensitive, so keeping the recommendation model available through Ollama provides a more privacy-conscious alternative to relying only on a closed API.

The project demonstrates two sides of open innovation: an open-weight local model powering the product, and an AI coding assistant helping build and improve the software.

My Agent Session

check my github repo,havent actively updated my agent sessions to record.

The agent session documents how the application was planned, implemented, debugged, and refined. It shows the reasoning behind the desktop architecture, the break-trigger flow, and the connection between the Rust backend and React frontend.

TOBER FEST

Rathnam.S — Mon, 05 Oct 2026 04:56:53 +0000

What I Built

I built SecondMind — a local-first second brain that runs on your own laptop.

The idea came from building something useful for a friend who often has to repeatedly remember and search through personal notes, study plans, preferences, and project context.

Instead of relying on a cloud AI service that sends everything to a remote server, SecondMind stores memories locally and uses a local open-weight model to understand conversations and retrieve relevant information when needed.

You can talk to it normally, and it can remember useful information, recall relevant memories later, and forget information when asked.

For example:

"I'm studying DSA and I'm currently focusing on dynamic programming."

Later:

"What am I studying right now?"

SecondMind can retrieve the relevant memory and use it to answer.

The goal isn't to build another generic chatbot. It's to build a small personal memory layer that belongs to the person using it.

Demo

The project runs locally with Django and Ollama.

Code

https://github.com/RathnamS089/secondmind

The project is built around a simple architecture:

Browser
   ↓
Django
   ↓
SecondMind Agent
   ├── Memory Tools
   │    ├── Remember
   │    ├── Recall
   │    └── Forget
   │
   ├── Retrieval
   │    └── Cosine Similarity
   │
   └── Ollama
        ├── Qwen 2.5 1.5B
        └── nomic-embed-text

How I Built It

SecondMind is built with Django, SQLite, NumPy and Ollama.

For the language model, I used the open-weight Qwen 2.5 1.5B model through Ollama.

For memory retrieval, I use nomic-embed-text to convert both the user's query and stored memories into embedding vectors.

When a user asks something that might require memory:

User query
    ↓
Embedding
    ↓
Compare with stored memory embeddings
    ↓
Cosine similarity
    ↓
Rank memories
    ↓
Relevant memories
    ↓
Qwen
    ↓
Response

The memory system also has three tools:

Remember — stores a memory and its embedding locally.
Recall — searches stored memories using semantic similarity.
Forget — removes a stored memory.

The agent can decide when to use these tools, while the UI also provides direct access to them through a Tools menu.

Everything is orchestrated through Django, while OllamaClient is kept as the single layer responsible for communicating with Ollama.

Why Does Open Innovation Matter?

This project wouldn't have the same meaning if the AI depended on a closed API.

The most important part of SecondMind is that the memories belong to the user and the model can run locally.

The entire system can run on a laptop without sending personal memories to a third-party AI provider.

Using open-weight models also means I can experiment.

I can change:

Qwen 2.5 1.5B

to another compatible open-weight model without redesigning the entire application.

I can also inspect how the memory system works, change the retrieval strategy, change the agent's behavior, fine-tune models in the future, and experiment with different embedding models.

For a personal memory assistant, that control matters more to me than simply calling the most powerful closed model available.

The project is also intentionally small enough to understand:

Django
   +
SQLite
   +
Ollama
   +
Open-weight models
   +
Local embeddings

There is no cloud database and no mandatory paid AI API sitting between the user and their memories.

That is where open innovation worked better for this project: I wasn't just consuming an AI service — I could actually build the AI system around the way I wanted it to work.