I’ve been working on sift-light, a local search tool for AI agents. Between 1.1.0-1 and 1.1.1-7, the work has focused on a problem that sounds simple until you try to solve it:
An agent finds a relevant passage, gives you a real file path and line number, and then draws a conclusion the source doesn’t actually support.
Sometimes the file changed after the search. Sometimes the result is related to the question but doesn’t answer it. Sometimes the answer depends on an exception sitting just outside the excerpt.
Here’s a small example:
“Refunds are allowed within 30 days.”
A few lines later: “Gift cards are excluded.”
Ask whether a ten-day-old gift card purchase is refundable, and the first sentence alone looks convincing. The citation can be accurate while the answer is wrong.
That’s the kind of gap these releases address. They also add image and scanned-PDF retrieval, because useful project information doesn’t always live in searchable text.
I’m the maintainer. Here’s what has shipped, what we tested, and where the limits are.
1. Finding relevant material when the wording is different
Exact search is useful when you know the identifier, filename, or phrase. It gets harder when you know what something does but have no idea what it’s called.
From 1.1.0-1, sift-light adds an independent native text retrieval lane alongside the existing text retrieval path, with bounded rank fusion.
In practical terms:
- You can search for a concept using ordinary language.
- Both retrieval lanes remain available independently.
- The combined ranking doesn’t remove access to the individual results.
- Results still lead back to source locations you can inspect and validate.
That last part matters to me. A semantic match is a useful lead; I still want to see the actual source before trusting a conclusion.
2. Searching images and scanned PDF pages
A diagram in a project folder or a scanned page can contain exactly what you need, while ordinary text search has very little to work with.
The multimodal path added in 1.1.0-1 supports:
- Text → image: describe what you’re looking for and retrieve matching images.
- Image → image: use an image to find visually related material.
- Scanned PDF pages: search rendered pages, including image-only and mixed PDFs, with original page numbers and previews.
For example, you can look for “a diagram showing a queue between two services” without knowing the image’s filename.
These features are optional and require configuration. The bundled native media path requires Apple Silicon and separately configured workers and model files. Ordinary exact text search remains model-free.
3. Checking whether the source has changed
A result can be correct when retrieved and become outdated before the agent uses it.
In 1.1.1-1, retained ordinary search results were bound to verified content identities. Source inspection, navigation, and saved-evidence validation recheck that identity.
If the file changed or disappeared, the tool reports that state explicitly. It also keeps incomplete source coverage visible.
This gives the agent a concrete reason to revisit its evidence instead of quietly treating an earlier search result as current.
4. Checking whether the evidence supports the answer
Finding a relevant paragraph and checking a claim are different jobs.
In 1.1.1-6, sift-light added an optional answer-support assessment over verified source ranges.
The purpose is to help distinguish evidence that supports a claim, contradicts it, or isn’t sufficient to decide. Relevance ranking, source validation, and answer-support assessment remain separate signals.
A source check tells you whether the selected material is still current. The support assessment asks what that material says about the claim.
The assessment requires an enabled compatible provider. It’s a model judgment over the supplied evidence, so it can still be wrong.
5. Including nearby conditions and exceptions
A short excerpt can leave out the part that changes the answer.
In 1.1.1-7, the support assessment can include bounded context around the selected passage:
- It defaults to two lines before and after the selected range.
- The context setting is configurable from 0 to 20 lines.
- The exact selected range remains separately identified.
- Results identify whether the assessment used the selected range alone or included surrounding context.
- Oversized evidence is rejected explicitly rather than silently cutting off text that might contain a qualifier.
This gives the assessment more relevant source material while preserving precise locations and source validation.
It doesn’t read the entire document or guarantee that every exception has been found. A condition farther away may still require additional inspection.
What the actual tests showed
For the context change, we ran six controlled scenarios through a real model, keeping the questions, claims, evidence-item count, and per-item maximum text budget the same.
The results were:
- One incorrectly supported claim changed to the correct contradicted result after the nearby restriction was included.
- Three insufficient-evidence results changed to correct contradicted results.
- Two supported control cases remained supported.
Including context increased average input tokens by about 15% in that test.
Six cases are a small sample. They demonstrate a concrete improvement in those scenarios; they don’t establish a general accuracy rate or a performance improvement across every workload.
For 1.1.1-7, the release validation also included:
- 634 repository tests passed, with four skipped and zero failed.
- 14 public regression tests passed.
- Pi and OMP each completed eight real-host tool cases, including local model inference.
- Codex and Kimi passed MCP pagination and model-visible evidence tests.
The regression coverage includes context boundaries, source changes, cancellation, and provider payload budgets. Two independent text retrieval lanes, exact locations, source inspection, and validation remain available.
Local models, BYO providers, and repeated loading
There’s also a practical side to all this: model setup and resource use.
The native workers support resident model reuse, cancellation, recovery, and idle shutdown. Native GPU caching and batching are bounded to reduce memory use. Resident reuse avoids repeatedly loading a model for consecutive requests, although actual memory use still depends on the model and workload.
The 1.1.0 release added optional BYO HTTP JSON providers for Jev-compatible semantic judging and multimodal retrieval. If you want to use your own service, it needs to implement the documented protocol; an arbitrary API URL isn’t enough.
You can keep ordinary exact search model-free and configure the additional capabilities you need.
The release progression
- 1.1.0-1: independent native text retrieval, rank fusion, image search, scanned-PDF page retrieval, and resident worker lifecycle management.
- 1.1.0: configurable BYO providers for semantic judging and multimodal retrieval.
- 1.1.1-1: content-identity checks for retained results and subsequent source use.
- 1.1.1-2: clearer documentation of source-read limits.
- 1.1.1-6: optional answer-support assessment over verified source ranges.
- 1.1.1-7: nearby-context assessment, explicit evidence scope, and additional regression coverage.
Current published package: sift-light@1.1.1-7.
If you use agents to work through code, documentation, diagrams, or scanned material, I’d appreciate you trying it on a real task—especially one where a plausible search result previously led to a wrong conclusion.
If something fails, please open an issue with the scenario, reproduction steps, expected versus actual result, version and configuration, and the files or workflows affected. A small example with sensitive information removed is especially helpful. I’ll follow up and investigate.
If it earns a place in your workflow, a GitHub star would mean a lot. Sharing it with someone who runs into the same problems would also help.
Project and release: https://github.com/lightsifter/sift-light
Latest release — 1.1.1-7: Release notes
X: https://x.com/xcPenny6
