The file was a picture. The name did not help, and the only clue was the error painted on it: CUDA out of memory on gpu 0. A text search walks through letters that were stored as letters. A picture stores colors, so that search walked past the file. Kensaku vs grep starts there. Kensaku is a local app that copies file names, the text inside documents, and the letters inside pictures into a list, then searches the list. Use the plain text search when you know the exact word and the files are text. Use Kensaku when the word lives in a picture, or when you only remember a nearby phrase.
Grep finds exact words in text files, and it cannot read a screenshot. Kensaku can, after it has copied those words into a local list, if you search the words you can still see.
What is Kensaku
Kensaku is a search box for your own disk. It is not a website, and nothing in the search I ran left the machine.
Before a search can be fast, something has to read the files once and write down what it found. That prepared list is an index. The first search pays for the reading. Later searches look at the list. Kensaku builds that list from the folders you choose. It keeps the list on your computer, in the normal place that apps store their settings. On Linux that place is the kensaku folder inside your config directory. The list holds names and extracted text, so treat it like a copy of those files. Do not sync it to a shared drive.
I pointed it at one small folder with three files. One was a note that mentioned a design retainer and a nightly index rebuild. One was a log line about a docker error and a refused connection on a port. One was a picture whose only text was painted on, the CUDA line above. The scan finished with text stored for all three. A later lookup of the log phrase came back with the log file and the sentence itself.
The app also has a command you can run after that first scan. It does not build the list by itself. I tried the command before any scan, and it exited with code 3 and said no list was found. After the scan, the same command answered.
How Does Kensaku Find Words in a Screenshot
It finds them by reading the letters out of the picture first, then searching those letters like any other text.
A screenshot is a grid of colored dots. The word CUDA is not stored as the four characters C, U, D, and A. It is stored as pale shapes on a dark background. A text search never sees characters that were never written down. The missing step is OCR (reading letters out of a picture). Kensaku does that step while it builds the list, using a letter-reading pack that landed in the config folder. Those files were about 6 MB.
I then asked the old text search to find CUDA inside the picture. It found nothing. I asked Kensaku for the same word. It returned the picture. It also returned the picture for “out of memory” and for “gpu”. The picture’s result did not include a sentence snippet. The path was enough: it was the picture, and the words on it were the words I had typed.
That is the whole trick. If the letter reader misreads a word, the search cannot find the word you remember. If it reads the word, you do not need the file name.
Kensaku vs Grep
Grep is the right tool for exact words in text. Kensaku is the right tool when grep walks past a picture, or when a small misspelling would make grep miss.
Grep does not build a list first. It opens files and looks. That is why it is honest and why it is blind to paint. On my three files it could not see the error in the picture. Kensaku could, because the scan had already copied the letters.
The same run showed a second difference. Grep would not treat that as retainer. Kensaku still returned the note, and it marked the hit as a folded content match, meaning the letters lined up even though the spelling was not exact. The log file also appeared, with a lower score and a different mark. I will come back to that mark. The useful part here is the spelling slip: the note was still first.
| grep | Kensaku | |
|---|---|---|
| Exact word in a text file | Finds it. I confirmed this kind of search on the log. | Finds it, and returns the sentence. |
| Word painted in a picture | No match on my picture. | Match on CUDA, gpu, and out of memory. |
| Small typo | Misses. | Still found retainer from retaner. |
| Needs a first scan | No. | Yes. Before the scan the command exits 3. |
| Where it looks | The files you name. | The folders you chose to copy into the list. |
On that tiny folder each Kensaku search came back in under 10 milliseconds. That number is not a promise about your whole disk. It only says the lookup, once the list exists, was not the slow part of a three-file test.
If you are searching one code project and you know the exact word, stay with grep. You do not need a background scan for that. If the word might be in a screenshot, grep is the wrong tool no matter how careful the pattern is.
Kensaku vs Recoll
Use Recoll when you already keep a library of documents and you trust that index. Use Kensaku when the lost file is a screenshot, or when you want one box for names and for words inside files.
Recoll is the older open-source program that indexes the text inside a folder of documents and then searches that index. The split is the job. Recoll’s usual path is documents. Reading letters out of pictures is an extra helper you add, not the thing it does on a fresh install. Kensaku’s fresh install already tried to read my picture, and the search for the painted error worked.
People on Windows often compare this kind of app to Everything, which is fast at file names and does not read inside documents or pictures. The public split is enough to avoid a wasted install: if you only forgot the file name and the name contains the word, a name search is enough. If the name is screenshot.png, a name search cannot save you.
| Question | Kensaku, from my run | Recoll, from the job it is built for |
|---|---|---|
| Text inside a note or a log | Yes | Yes, that is its main job |
| Letters painted in a picture | Yes, on this picture | Only after you add a letter-reading helper |
| A phrase that is not the exact words | Sometimes, see the next section | Not the reason you install it |
| I already have an index I trust | You would be starting another one | Keep the one you have |
Do not run both scans over the same huge folder just to feel covered. Each list is a copy of the text. Two copies mean two places a secret can sit.
Does Kensaku Search by Meaning
Sometimes. In this build it is a small stand-in, not a chat model, and it will also return a file that does not contain your words.
Meaning search here means the app turns a chunk of text into a row of numbers, and rows with a similar shape sit near each other. A later question becomes another row. Nearby rows come back even when the exact words differ. The status command on my run named that ranker static-embed-256 and marked it as not a real model. Read that as a small fixed table, not as a general chat system that understands your files.
Three questions showed the edge of it.
I asked for “nightly rebuild”. The note does not contain those two words. It says the index rebuild happens at night. Kensaku returned the note and marked the hit Semantic. That is the good case.
I asked for “database port failure”. The log does not say database or failure. It says a docker error and a refused connection on a port. Kensaku returned the log as Semantic. That is also a good case, and it is the case grep cannot do. If you need this kind of jump inside a code project, a tool built for that job is a better fit than a desktop launcher. The measured version of that trade is does jevgrep cut coding agent cost.
I asked for “graphics card ran out of space”. The picture says CUDA out of memory on gpu 0. Kensaku returned nothing. The letter reader had the words. The meaning ranker did not connect “graphics card” to CUDA. So a paraphrase of a screenshot can miss even when the exact words hit.
There is a worse case than a miss. When The log, which does not contain retainer, still showed up as Semantic with a lower score, about 0.46 against about 1.07 for the note. The typo “retaner” kept the note first and pulled the log up further, to about 0.71, still as Semantic. If you open the second file without reading the match type, you will think the search lied. It did not lie. It guessed a neighbor. Open the content hit first. Treat a semantic hit as a maybe.
The list is a copy, and a copy can go stale when the file changes. That is a separate failure, already tested on another tool: does serviette update when files change. Kensaku’s scan is supposed to pick up changes in the folders you chose.
How Do I Find a Screenshot by the Words in It
Install the app, let it scan the folder that holds the picture, then search the words you can see on the picture.
Kensaku ships for Linux, macOS, and Windows from the project releases. I only ran the Linux build. The first run asks which folders to include. Pick the folder. Do not point it at your whole home directory on the first day. Wait until the first scan has something to say. Then search.
The command, after that scan, is:
kensaku-cli state
kensaku-cli search "out of memory" --jsonstate tells you whether any files are in the list. If it says no list exists, you have the command without the app’s scan, and the next search will not save you. search prints one JSON object. Look at match_type and path before you celebrate. On a picture, snippet was empty for me. The path was the answer.
A few filters are on the same command.
kensaku-cli search "invoice" --ext pdf --since 30dThat limits the lookup to pdf files touched in the last 30 days. It still only sees folders that were scanned.
If the screenshot is actually a Word or Excel file that only looks like a picture in your memory, you do not need letter reading. You need a reader for that document type. That is a different tool: OfficeCLI.
When is Kensaku the Wrong Tool
Skip it when grep already answers, when the folder holds secrets, or when you hoped a paraphrase would understand a picture.
Grep is enough for a repository of text when you know the word. A desktop index is extra moving parts: a scan, a copy of the text, and a background watcher. Do not add those to feel modern.
The copy is the sharper limit. Letter reading will store whatever it can see. A screenshot of a password, a key, or a customer list becomes text in the list. The defaults skip hidden names, and they skip files that end in .pem, .key, and .pfx. That does not protect a png. If you would not paste the picture’s text into a note, do not scan the folder that holds the picture.
Meaning search is the other limit. It helped on “nightly rebuild” and “database port failure”. It missed “graphics card ran out of space”. It also offered the log as a neighbor of retainer. If you need a reliable answer from a pile of documents, do not stop at the first semantic row.
I would keep grep for code. I would open Kensaku for the screenshot whose name I forgot, and I would type the words still visible in my head, not a cleaner sentence.
Common questions about kensaku vs grep
can grep search a screenshot
No. Grep searches text. A screenshot is a picture. On my file, grep did not find CUDA. Kensaku did, after the scan had read the letters.
does kensaku need the internet to search
No. The search I ran used the local list. The first setup can download the small letter-reading pack. After that, the lookup does not need a network.
why did a file without my words show up
Because the hit was marked Semantic. The meaning ranker returns neighbors, not only exact lines. Read match_type. Open a Content or ContentFolded hit before you open a Semantic one.
where does the kensaku index live
On your machine, in the app’s config folder. On Linux that is ~/.config/kensaku. It contains file names and extracted text, including letters read from pictures. Do not copy that folder to a shared disk.
The program and the install files are at the Kensaku repo. Recoll’s own site, if you already live in that tool, is recoll.org.
What release did we read?
Cloned yjid/kensaku; package.json reports version 1.0.16 (9 November 2026).
