Skip to main content

ClipboardFilter Overview

ClipboardFilter is a four-stage Python pipeline that turns raw clipboard history into a searchable, semantically-indexed DuckDB database of typed "atomic entries" (commands, code snippets, configs) — with local LLM extraction and vector embeddings, and a small React lookup UI on top.

Who it's for​

An operator who copy-pastes a lot of commands, snippets, and configs and wants that history to become searchable by meaning, not just exact text — "find that Docker command I used for X" rather than scrolling through a flat clipboard history.

The core concept​

The repository layout is the pipeline — four numbered stages, each a folder:

1-Input/     <-- raw clipboard history .txt files
2-Embed/     <-- typed TOML entries + vector embeddings (Ollama)
3-Database/  <-- clipboard.duckdb — the indexed, queryable store
4-Lookup/    <-- Express + DuckDB API, React + Vite web client
  1. Extract — raw clipboard .txt dumps in 1-Input/ are parsed and classified (command, snippet, config, etc.)
  2. Embed — entries are rewritten as typed TOML records and embedded using local Ollama models (phi4-mini for extraction, snowflake-arctic-embed2 for embeddings)
  3. Index — embedded entries are ingested into 3-Database/clipboard.duckdb
  4. Lookup — a small Express API (GET /api/entries, /api/categories, /api/entry-types, /api/embeddings/status, etc.) backs a React + Vite web client for browsing and filtering

Why this shape​

Everything runs locally against Ollama models rather than a cloud API — appropriate given clipboard history routinely contains credentials, internal paths, and other sensitive fragments an operator wouldn't want leaving the machine. The pipeline is explicitly "atomic entries," a deliberate simplification from an earlier tool/command schema (the 4-Lookup/README.md notes it's "intentionally leaner than the previous 3-CommandLookup") — it focuses on browsing and filtering rather than in-UI editing/importing.