cheap-eyes
cheap-eyes
Cheap eyes for an expensive agent.
An AI agent's context is expensive. When it reads a big log, a long doc, a web page or a whole code tree, it burns that context on lines it mostly doesn't need. cheap-eyes is an MCP server that hands the reading to a cheap model. It then checks every line of that model's answer against the source, so the agent gets back a short answer it can trust.
What it looks like
A real header from the server (trimmed), with a stubbed model answer. The agent asked for every ERROR line after 08:10 in an app log, plus the traceback that follows it:
eyes_run result: 2026-09-26_152246-extract-889090
model: alias fast -> qwen/qwen3.6-35b-a3b (used: qwen/qwen3.6-35b-a3b)
tokens in 412 / out 96; cost $0.000080; 2 ms
check (extract): refs ok 4 / bad 1 — ok 4, ok~ 0, partial 0, not-in-input 0
L9 [bad] text differs from the source line
--- untrusted model output ---
L3| 2026-09-20 08:14:09.031 ERROR [sync] upload failed: timeout after 30 s
L4| 2026-09-20 08:14:09.032 Traceback (most recent call last):
L6| TimeoutError: timed out
L8| 2026-09-20 08:15:31.550 ERROR [sync] upload failed: HTTP 503 from api.example.com
L9| 2026-09-20 08:16:00.000 ERROR [sync] retry 2/3 failed
--- end ---The model quoted five lines. In the real log, line 9 says INFO [sync] retry 2/3 ok,
so the model made up an error. The check compared each quote with the source line and
flagged L9 as bad. The agent sees that before it relies on the answer.
Related MCP server: delegate-mcp
Why you can trust the answer
The model has no tools. It can't open files, browse or call anything. It sees only the numbered lines cheap-eyes chose to send.
Secrets are masked before anything leaves your machine. Passwords, tokens and keys become
[token],[key]and so on, in the files and in the task.Only Zero Data Retention providers. Those are providers that don't store your prompts. cheap-eyes talks only to OpenRouter and asks for them on every call.
Every quote and line reference is checked mechanically against the lines that were sent. Wrong values and uncited claims are flagged.
What the check does not prove: that the answer is complete or relevant. It proves what was quoted is real, not that nothing was missed.
Requirements
Runtime | Node.js ≥ 22.17, or Docker, or Home Assistant OS / Supervised |
Architecture (Home Assistant app) | amd64, aarch64 |
Network | outbound HTTPS to |
Disk | about 56 MB installed, 33 MB of it |
OpenRouter | an API key with its own daily limit |
Installation
Claude Code / Claude Desktop (npx)
Write a config file at
~/.config/cheap-eyes/config.json, or%APPDATA%\cheap-eyes\config.jsonon Windows (see Configuration).Check it (no network, no secrets printed):
npx -y cheap-eyes check-configAdd the server to Claude Code:
claude mcp add --env CHEAP_EYES_OPENROUTER_KEY=<OPENROUTER_KEY> --transport stdio cheap-eyes -- npx -y cheap-eyesTry it: "Use eyes_run to list every TODO in /home/me/notes/**/*.md, with the line it's on."
Claude Desktop, .mcp.json and a global install:
installation.
Home Assistant app
Home Assistant renamed add-ons to apps in 2026.2; on older versions the same menus say Add-ons and Add-on Store.
Add this repository:
Or by hand: Settings → Apps → App Store → ⋮ → Repositories → + Add, paste
https://github.com/st412m/cheap-eyes, select Add.Find cheap-eyes in the store and select Install.
In Configuration, set
openrouter_key, anhttp_tokenof at least 32 characters (openssl rand -hex 32gives one) and yourread_roots.Select Start. The app serves MCP on port 3400.
Options and the connector URL: app documentation.
Docker / HTTP
cheap-eyes serve --http runs the same server over Streamable HTTP with a token; the
repository's Dockerfile and compose.example.yaml wrap it. See
installation.
Configuration
A JSON config file. The fields to set first:
Field | What it is |
| The folders (or single files) the server may read. Absolute paths. |
| Aliases: an alias like |
| The alias each mode uses when a call names none. |
| Local spending cap per UTC day, default |
{
"read_roots": ["/home/me/notes"],
"models": { "fast": { "ids": ["qwen/qwen3.6-35b-a3b"], "params": { "reasoning": { "effort": "none" } } } },
"defaults": { "extract": "fast", "draft": "fast", "edits": "fast" }
}The key goes in the env var CHEAP_EYES_OPENROUTER_KEY, never in the file. Every
field, env var and file location:
configuration.
Connecting to claude.ai
Run the HTTP server (or the Home Assistant app) and publish it through a reverse proxy that terminates TLS. The endpoint is:
https://<your-host>/private_<your-token>/mcpAdd it in claude.ai → Settings → Connectors → Add custom connector. A wrong path gets a bare 404, and there is no OAuth by design. See security.
Using it
You talk to your agent as usual. It calls cheap-eyes when a job fits. Pick the mode by what you want back:
extract when you need exact lines: errors in a log, a config value, every mention of something. Invented lines are flagged.
draft when you want notes or a summary. Every line must cite its source lines. Values that aren't in those lines, and lines with no citation, are flagged.
edits when you want fixes proposed. You get JSON edits whose old text is checked against the file. cheap-eyes never applies them.
schema when you want fields filled: a JSON schema in, the same JSON out with a line ref and a verbatim quote for every value. Conflicting values are reported, not resolved.
grep when you know the exact pattern: matching windows, no model, $0.
Files can be text, HTML, PDF (with a text layer), Word (DOCX, DOC), RTF, PowerPoint
(PPTX, PPT), OpenDocument text and presentations (ODT, ODP), EPUB, FB2 and mail (EML,
MSG, attachments included), or an http(s) URL that the server fetches itself.
Spreadsheets and scans are refused with the reason. Refs name the page, slide, chapter
or attachment of a line: L40 (slide 3), L12 (attachment: offer.pdf, p.2)
(formats).
Prompts you might type (the files must lie inside your read_roots):
"Use eyes_run to pull every ERROR from /var/log/app/app.log since 08:00 today, with the tracebacks."
"Have cheap-eyes draft a summary of /home/me/notes/deploy.md: versions, ports, backup times."
"Use eyes_run in edits mode to fix the dead links in /home/me/notes/*.md."
"Use eyes_run in schema mode on /home/me/docs/tender.pdf: customer, maximum price, deadline, and the list of items with quantities."
What each check catches and misses: checks.
When to use cheap-eyes and when grep
cheap-eyes pays off for reading by meaning over large text: logs, archives, long documents, web pages, "everything about X", chronologies. For exact lookups — a key, which blocks contain X, a list by a field, a value in a table — and for files under about 30 KB, grep, a ranged read or code is cheaper and more reliable. That is why spreadsheets are not read at all.
On a benchmark of 2026-09-30 with independent ground truth:
An 887 KB log archive, task "everything about power": recall 96 %, precision 100 %, $0.08, about 12k tokens of the agent's context instead of about 227k for reading it whole.
A structural task over Home Assistant automations ("who sends to Telegram"): precision 41 % with a green check. The check catches invented lines, not wrongly chosen ones.
A snippet for CLAUDE.md or your Claude settings:
Reading by meaning over large text (logs, archives, long documents, web pages, "everything about X") → cheap-eyes eyes_run (extract/draft; fields → schema). Exact values, structure, small files (< ~30 KB) → grep / ranged read (no model: eyes_run mode grep). Verify any value from cheap-eyes against the source (eyes_result source) before relying on it.To compare models on your own documents, run
cheap-eyes bench.
Tools
eyes_run— does the job and returns a short, checked header.eyes_result— reads a stored result: pages, grep, the check report, the source text the model was given; cancels a running job.eyes_stats— spend today and all time, your key's status; on request, the model table.
Inputs and outputs: tools.
Models and cost
No model is pinned in code. You name models in your config under aliases (fast,
long, …), and switching means editing the config and restarting. Each alias lists
model ids in priority order; if one can't be used, the next is tried. The example ids
were valid on 2026-09-26 and will age. To pick new ones:
cheap-eyes models --candidatesThis lists cheap Zero Data Retention models, and shows how well each of your aliases
passed its checks on your own jobs. If your OpenRouter account's Guardrails don't allow
a model, cheap-eyes skips it and marks it blocked by account. Allow it at
openrouter.ai → Guardrails if you want it used.
With cheap models a job costs fractions of a cent. Your key's own daily limit on
OpenRouter is the real ceiling. On top of that, daily_budget_usd (default $1 a day)
stops calls before they would go over. More:
models and spending.
Limitations
The check proves quotes are real, not that the answer is complete. A relevant line the model skipped is not flagged.
No OCR. Scanned PDFs are refused with the reason; layout and images are lost in extraction.
No spreadsheets. Excel and OpenDocument spreadsheets are refused: questions about a table are exact lookups, which grep or code answers and a model reading the table as text gets wrong.
Size caps. A text file (or the text extracted from a document) over 2 MB is refused, never truncated; a document over 50 MB and a URL over 10 MB likewise; a job is capped at 5 MB after filtering and 200 files.
No reduce pass for
draft. With several chunks, each chunk's notes come back under their own header.The hook covers Claude Code's
Readtool only. Shell commands are not intercepted.
Troubleshooting
OpenRouter answers 403 "Access denied by security policy". OpenRouter refuses some regions; route the calls through a proxy.
A model is
blocked by account. Allow it at openrouter.ai → Guardrails, or put another id in the alias.The server won't start and names an alias. A value in
defaultsis not defined inmodels.The client shows old tools after an update. Refresh the connector's tool list and start a new chat.
More: troubleshooting.
Security
The model gets no tools; everything it returns is framed as untrusted output.
Only files inside
read_rootsare read, after resolving symlinks;.env*, keys,secrets.yaml, databases and.gitare always refused.Secrets are masked before anything leaves the machine; model calls go only to
openrouter.ai, with Zero Data Retention required.URLs in a job are fetched by the server with private and local addresses refused, also against DNS rebinding.
The server writes nowhere outside its own state folder unless you opt into export.
In HTTP mode the token works as a password. It needs at least 32 characters and is never logged; put TLS in front.
More: security.
Links
Documentation — installation, configuration, tools, checks, models and spending, results, security, hook, formats, bench, troubleshooting, internals
Prior art
Both MIT-licensed; cheap-eyes is written from scratch (see NOTICE).
BardyLaw/claude-worker-delegation — the server reads files by path, short preview, usage log, daily budget, PreToolUse hook. cheap-eyes adds what it lacked: a
realpathpath guard, refusal instead of silent truncation, masking, line numbers and checking the output.aashahin/claude-opencode-delegate — async task registry, compact status header.
License
MIT — by st412m.
Available Tools
3 toolseyes_resultRead job resultAIdempotent
Read an eyes_run result by the id from its header: pages, grep, check report, the source text to verify a quote; cancel: true aborts a running job. No model call, free.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Result id from eyes_run | |
| full | No | Do not clip lines over 400 chars | |
| grep | No | JS regex over result lines | |
| check | No | Check report: true = items that are not ok; "all" = every item | |
| limit | No | Lines to return, max 200 | |
| cancel | No | Abort a running job | |
| offset | No | First result line (1-based) | |
| source | No | Page a stored source text instead (name as in the result); offset = its line number |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give idempotent/non-destructive but readOnlyHint=false, which the description justifies by disclosing that cancel:true aborts a running job. It also adds cost context not in annotations ('No model call, free'), useful for an agent deciding whether to call it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence with semicolons that front-loads the core read action, then sub-capabilities, then the cancel behavior. Every clause carries information; minor density cost from packing many features into one sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 8 parameters, the description covers the key result facets (pages, grep, check, source) and the cancel side effect; enough for an agent to invoke correctly, though pagination (offset/limit) semantics are left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 8 parameters are already documented in the schema. The description echoes the purpose of grep/check/source but adds no format or syntax detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Read) and resource (an eyes_run result by id) and enumerates what the result contains: pages, grep, check report, source text. It clearly routes from the eyes_run sibling, though it doesn't differentiate from eyes_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage by saying to read result 'by the id from its header' of eyes_run, and notes cancel: true aborts a running job. It does not explicitly say when to use this versus eyes_stats or when to run eyes_run first, so guidance is largely inferential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eyes_runRun cheap reading jobA
Hand reading by meaning over large text (logs, archives, long documents, web pages) to a cheap model; quotes and line refs come back checked against the source. For exact values, structure or files under ~30 KB use mode grep ($0) or your own file tools. Each call is a paid job within daily_budget_usd; full result via eyes_result.
| Name | Required | Description | Default |
|---|---|---|---|
| grep | No | Send only matching windows | |
| mode | Yes | extract: verbatim lines; draft: markdown with refs; edits: JSON line edits (never applied); grep: matches, no model; schema: JSON fields with refs | |
| task | No | What to look for or write (optional for grep and schema). Masked like file content. | |
| time | No | Keep log lines whose timestamp is in the window | |
| async | No | Return the result id at once; poll eyes_result | |
| files | Yes | Absolute paths or globs inside read roots, or http(s) URLs (fetched by the server). Range "#L100-L400" only with a single file | |
| model | No | Model alias from config; default per mode | |
| schema | No | mode schema: {"field": "number — description", "list": [{...}]}; max 60 fields, depth 4 | |
| dry_run | No | Build and store the request, do not call the model | |
| export_to | No | Also copy the result here (inside write_roots) | |
| overwrite | No | Replace an earlier export of this server | |
| max_tokens | No | Output cap per chunk; default extract 16000, schema 8000, draft/edits 4096 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-read-only, open-world, non-idempotent, non-destructive job, and the description adds the traits that matter beyond them: each call is a paid job charged against daily_budget_usd, quotes/line refs are validated against the source, and output is capped by max_tokens. It does not however explain the async lifecycle or export/overwrite side effects in prose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler, with the core action first, the cheaper alternative second, and the cost/result-routing constraints last. Every clause carries actionable information for the caller.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter, multi-mode, model-invoking tool with no output schema, the description covers purpose, cost, verification behavior, the free alternative, and where results are retrieved. It leaves the async polling path and export_to behavior to the schema, which is a minor gap rather than a blocking one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so modes, files semantics (globs, URLs, #L100-L400 single-file range), time window and schema dialect are all documented in the schema itself. The description adds only the cost cue for grep mode and the 30 KB threshold, so it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb+resource: hand a reading-by-meaning job over large text (logs, archives, long documents, web pages) to a cheap model. It scopes the tool ('large text', implicitly >~30 KB) and distinguishes itself from the free grep path and from the sibling eyes_result that returns the output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the when-not case and the alternatives: 'For exact values, structure or files under ~30 KB use mode grep ($0) or your own file tools.' It also tells the agent where the full result lands (eyes_result), which resolves the run-then-fetch workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
eyes_statsUsage and modelsARead-onlyIdempotent
Spend today and all-time, budget left, OpenRouter key limit; models: true adds the model table. Check it before a large job or when eyes_run hits the budget. Free.
| Name | Required | Description | Default |
|---|---|---|---|
| models | No | Add the model table per alias | |
| candidates | No | Suggest up to 10 cheap ZDR models not in config |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld/non-destructive. The description adds beyond them: it discloses that the call is 'Free' (no budget consumption) and that the models flag expands the response, which is genuinely useful behavioral context. It does not cover rate limits or response size, keeping it out of 5 territory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the return data front-loaded ahead of the usage tip; nothing is wasted. The telegraphic phrasing ('models: true') is efficient if slightly clipped.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so by naming the key figures returned. Combined with 100% parameter coverage and clear annotations, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters fully. 'models: true adds the model table' restates what the schema description ('Add the model table per alias') already says, and the candidates object is left entirely to the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates exactly what the tool returns (today/all-time spend, budget left, OpenRouter key limit, optional model table), so the resource is precisely defined. It stops short of a clean verb-phrase opening, but an agent can confidently tell this is the usage/cost reporting tool versus eyes_run and eyes_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger: check before a large job or when eyes_run hits the budget, naming the sibling that precedes it. No when-not or alternative-stats-tool guidance, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.2.0- First observed
eyes_result - First observed
eyes_run - First observed
eyes_stats
TDQS
Scored across 3 tools
Each tool has a clearly distinct role: eyes_stats monitors spend/budget, eyes_run launches a reading job, and eyes_result retrieves or cancels it. The descriptions make the workflow boundaries explicit, so an agent can pick the right one without confusion.
All three tools follow a strict prefix_noun pattern (eyes_stats, eyes_run, eyes_result) in consistent snake_case. The shared 'eyes_' prefix aids grouping while the suffixes stay distinct.
Three tools cover the core lifecycle (check budget, run job, fetch/cancel result) with no redundancy and each earning its place. It is on the lean side, but the scope is narrow enough that this is reasonable rather than thin.
The surface covers the essential flow: budget check, job execution, result retrieval, and cancellation. A way to list or revisit prior jobs/history is absent, which is a minor gap an agent can mostly work around via the run header id.
Maintenance
Related MCP Connectors
Extract, ask, compare and parse PDFs/images with source evidence. OAuth sign-in or API keys.
Summarize URLs, repurpose content, daily news digests, find competitors. Cost telemetry built in.
Cross-model evidence pipeline for financial filings & contracts. x402 pay-per-call.
Token counting, RAG chunking, truncation, HTML to Markdown and JSON repair
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to analyze large codebases and document collections by consulting large context window models (up to 2M tokens) via OpenRouter when files exceed the current agent's context limits.118 PyPI296MIT
- AlicenseNot gradedqualityAmaintenanceAn MCP server that delegates reading of files or long context to a cheap model, returning a tight answer to save the orchestrator's context window.17 npmMIT
- AlicenseNot gradedqualityBmaintenanceDelegates large file reads to a cheap worker model so coding agents avoid consuming context, with optional hook enforcement and per-call token savings.67 PyPIMIT
- AlicenseAqualityCmaintenanceEnables ranking large workspace search results and classifying English text into caller-defined labels using Jev via OpenRouter, with local secret filtering and spend guards.2MIT