DEV Community: Kavyansh Kumar Baghel

Invoice Sorter: a private expense tracker for freelancers that runs on a laptop

Kavyansh Kumar Baghel — Thu, 15 Oct 2026 10:45:06 +0000

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

What I Built

Invoice Sorter is a small command-line tool for freelancers. You point it at a folder of PDF invoices and receipts, and it writes one clean expenses.csv with vendor, date, total, currency and category.

The people who would pay for it are freelancers, consultants and small studios who lose a weekend at tax time retyping receipts into a spreadsheet. Their invoices contain client names and amounts, so many of them don't want to upload those to a cloud service. Invoice Sorter does the whole job on their own laptop, so the data never leaves it.

Demo

Terminal recording (8 sample invoices in, expenses.csv out, about 45 seconds, all local): https://asciinema.org/a/CWEnTFK4dQxtn78a

Code

krish007code / invoice-sorter

Local invoice/receipt sorter for freelancers: PDFs in, expenses.csv out, powered by Ollama

Local Invoice Sorter

Freelancers and solo consultants who would pay for a lightweight bookkeeping helper can use this local invoice sorter to turn text-based PDF invoices and receipts into a tidy expense CSV, without hand-copying vendors, dates, totals, currencies, and categories. It saves time on repetitive expense entry while keeping client and financial documents on their own laptop.

Why local and open

Documents are read locally and sent only to your local Ollama instance, so client data never leaves your laptop. After downloading a model, processing works offline and has zero per-document API cost. The model is swappable through an environment variable, so you can use the open-weight model that works best for your machine without vendor lock-in. Extraction uses an LLM for extraction, rules as a safety net for common category keywords.

Requirements

uv
Ollama running locally

Setup and usage

uv sync
ollama pull qwen2.5:3b
uv run make_samples.py
uv

…

View on GitHub

How I Built It

Model: qwen2.5:3b, an open-weight model, served locally by Ollama. It runs on my 16 GB laptop with no GPU.
Pipeline: pdfplumber pulls the text out of each PDF. The model returns structured JSON (vendor, date, total, currency, category) in JSON mode at temperature 0. Polars writes the CSV.
LLM for extraction, rules as a safety net: The small model handled vendors, dates, totals and currencies well, including summing an invoice with two line items. Categories were its weak spot. On the first run it labelled almost everything "services", and after I rewrote the prompt with definitions and examples it still invented a category called "hosting" for a DigitalOcean invoice. I added a short keyword-rules fallback (under 25 lines) that corrects invalid or implausible categories. All 8 sample invoices now come out right.
Speed: on a CPU-only laptop it processes about one invoice every 5-6 seconds (8 invoices in about 45 seconds, measured from the demo recording). That's plenty for a freelancer's monthly batch.
Configurable: the model comes from an OLLAMA_MODEL environment variable and the output file from a --out flag, so trying Llama or Phi is a one-line change.

Why Does Open Innovation Matter?

Privacy: client invoices never leave the laptop. There is no upload and no third-party API to trust.
Cost: there is no per-document fee. Running 500 receipts at tax time costs nothing beyond electricity, which makes a low price viable for a side hustle.
Offline: the pipeline makes no cloud calls, so once the model is pulled it works without internet.
No lock-in: I can swap Qwen, Llama or Phi without rewriting anything, and no vendor can change the pricing under me.
Tinkering: because I run the model myself, I could see exactly where it failed (categories) and fix it with prompts plus rules. With a closed API I'd be stuck with whatever it returned.
Honest limits: it only reads text-based PDFs (scans need OCR), and a 3B model can still mislabel edge cases. Next up: OCR with Tesseract, Excel export, GST-ready columns and a watch-folder mode.

My Friend Has Five ChatGPT Accounts and Zero Shared Memory, So I Built LocalClip

Kavyansh Kumar Baghel — Mon, 05 Oct 2026 15:06:22 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

LocalClip is a local-first memory for ChatGPT. I built it for my friend mushe, who uses several free ChatGPT accounts. Each account is a silo, so when he hits a limit and switches, he has to re-explain everything from scratch.

LocalClip captures his chats automatically and turns them into a linked Obsidian vault on his own machine:

A Tampermonkey userscript captures each ChatGPT turn and tags it with an account label.
A local Python server queues the turns, and a local model extracts a title, topic and bullets for each one.
The vault gets one note per turn, with Prev/Next links and a hub note per topic that merges turns from every account.
A handoff command (python -m server.handoff --topic "...") builds a brief he can paste into a fresh chat to continue where he left off.

His problem was never "move to another AI provider". It was "my context is scattered across accounts, and I don't want it on someone else's server."

What already exists: I compared this with the native memory-import tools from Anthropic and Google, browser extensions like MemoryPlugin and Promptive Sentry, hosted memory services, and the open-source OmniContext. Most of them handle switching between providers, often through a cloud service. LocalClip targets several accounts on one provider, with automatic capture and fully local storage. I'm not claiming it's the first tool in this space.

Demo

LocalClip running on my machine: captured ChatGPT turns turned into linked notes in the Obsidian vault.

The workflow in short: chat as usual, LocalClip captures each closed turn, the vault updates with notes and topic hubs, and python -m server.handoff --topic "Quantum Computing" writes a brief he can paste into a fresh chat.

Code

krish007code / localclip

this is a ease tool that let you utilize multiple chatgpt free acounts and save that context in form of obsidian knowledge graph make it easy to interpret for human and ai agents

LocalClip

Capture ChatGPT conversations turn by turn into a local Obsidian vault — with [[wiki links]], Prev/Next navigation, and topic hubs. Processed by a local LLM (Ollama). Nothing leaves your machine.

Quick start

# 1. Clone and enter the repo
git clone <repo-url> localclip
cd localclip
# 2. Create your personal config
cp config.example.json config.json

# 3. Generate a token — paste it in BOTH places shown below
openssl rand -hex 16

#   → open config.json and set:  "token": "<your-token>"
#   → open userscript/localclip.user.js and set:  const TOKEN = "<your-token>";

# 4. Install Ollama and pull a model (first time only)
#   https://ollama.com/download
ollama pull llama3.2

# 5. Start the LocalClip server
uv run python -m server.server

# 6. Install the userscript in Tampermonkey
#   a. Open Tampermonkey → Dashboard → click the + tab
#   b. Delete the placeholder code
#   c. Paste the entire contents

…

View on GitHub

The userscript's token is a placeholder in the repo. Each user generates their own with openssl rand -hex 16.

How I Built It

Built with Kiro as the coding agent.

Open-source AI: the model is llama3.2, run locally through Ollama. It reads each closed turn and returns JSON with a title, topic and bullet points.

Architecture:

Capture: a Tampermonkey userscript reads the ChatGPT page, converts messages to markdown with Turndown, and posts them to 127.0.0.1 with a token.
Server: a local Python server dedupes and queues each turn. A turn counts as complete once the next question exists, so no streaming detection is needed.
Storage: an append-only nodes.jsonl. The next link is derived, never stored.
Rendering: the LLM returns JSON only, and my code writes every file. That keeps a small local model's output predictable.
Accounts: the label is part of the dedupe key, so the same conversation from two accounts stays distinct. Topic hubs merge all accounts.
Handoff: the brief is built deterministically from stored nodes, ordered by time across accounts. No extra model call is needed.

Bugs I hit and fixed: a wrong Turndown @require path, an import error from running the server directly, slow Ollama calls causing timeouts, resends and duplicate nodes (fixed with a queue and idempotency), and over-aggressive LLM skipping (now gated in code). The project has 199 passing tests (162 Python, 37 Node).

Limitations:

Tested live with one account so far. The multi-account path is covered by unit tests but not yet by two live accounts.
ChatGPT only. The Claude and Gemini selectors are stubs.
It depends on ChatGPT's page structure, which can change.
The account label is set per browser profile, so he needs one profile per account.
It needs Ollama and a running local server, which is more setup than an extension.
A small local model produces plainer summaries than a hosted one.

Why Does Open Innovation Matter?

My friend's chats are personal: study notes, half-formed ideas, questions he'd rather not hand to another company. Because the model runs locally, LocalClip never sends his chats anywhere beyond the ChatGPT page he already uses.

A closed API would have meant:

his conversations leaving his machine again just to be summarized,
a per-call cost or rate limit, for someone who is already working around free-tier limits,
no way for him to inspect or change what happens to his data.

With an open model, he can swap llama3.2 for any model Ollama runs, read every line of the code, and keep working offline.