eyehands 1.7.0: compiled binary, 7-day trial, browser screenshot bridge

14 April 2026 · ~6 min read

by Fireal Software · ~6 min read

1.7.0 is the biggest release since 1.0. Three things changed at once, and they’re all connected: how eyehands is distributed, how you pay for it, and how it takes screenshots. The 1.6.0 notes said 1.7 would focus on a Claude Code plugin wrapper. That turned out to be the wrong problem to solve first. This is what shipped instead.

Compiled to a single .exe

Before 1.7.0 eyehands was a Python package on PyPI. pip install eyehands, python -m eyehands, done — as long as you had Python 3.11+, the right Visual C++ redistributables, and a willingness to debug whatever pip did to your site-packages.

1.7.0 ships as a Nuitka-compiled standalone Windows executable. Download the zip from GitHub Releases, extract it, run eyehands.exe. No Python install, no virtualenv, no pip resolution. The .exe bundles everything the server needs — including the DLL surface for DXGI capture and SendInput.

A few things fell out of this:

The _COMPILED flag gates the few code paths that need to behave differently in a binary. Data directory is next to the exe instead of inside the package, update mechanism is a PowerShell helper instead of pip install --upgrade, version comes from the bundled VERSION resource instead of importlib.metadata.
OCR is not bundled. EasyOCR pulls in PyTorch (~2 GB), which would blow the installer size past any useful threshold. /find returns HTTP 501 in compiled mode. If you need OCR, install the source build (pip install eyehands-sdk — see below) and run it alongside.
Updates use PowerShell. The helper downloads the new zip, verifies the SHA-256 against the release manifest, backs up the old install, and relaunches. Running /update on the old pip-installed version will just tell you to migrate.

Source is no longer distributed. The server code is proprietary as of 1.7.0. The reason is the same reason most indie tools eventually go this route: the business model needs to match the distribution. Selling licenses for an MIT-licensed package on PyPI is a coordination problem I don’t want to solve.

eyehands-sdk: the Python side stays free

The parts of eyehands that actually make sense as a library — the Python client, the MCP server wrapper, the OpenAI tools adapter — are split into a new package on PyPI called eyehands-sdk. This stays MIT-licensed and has no license check. It assumes you’re talking to an eyehands server running somewhere (yours on localhost, or someone else’s on a remote host) and just handles the HTTP and auth plumbing.

pip install eyehands-sdk

Typical setup now: install eyehands.exe on the Windows machine you want to control, run it, then pip install eyehands-sdk anywhere you want to call into it from Python. MCP clients get the same pattern — the SDK ships a stdio MCP server that proxies to an HTTP eyehands.

Trial model replaces freemium

Old model: free tier (most endpoints), Pro tier ($19 one-time, unlocked OCR + UI Automation + a few other endpoints). New model: 7-day trial (everything works), then either a $49 license (everything still works) or 402s on most endpoints until you buy.

Why the change:

Freemium split was hard to explain. People kept asking which endpoints were Pro. Splitting the docs and the AGENT_PROMPT around it was painful, and most users bounced off the friction before ever getting to the Pro features that sold the thing.
7 days is enough. If eyehands doesn’t prove useful in a week, it’s probably not going to. Longer trials mostly just delay the decision.
$49 funds the work. $19 priced the Pro tier like an impulse buy and implied this was a side project. It isn’t. $49 is a closer match to what it costs me to keep shipping.

Existing Pro licenses keep working and auto-upgrade to full. There’s no downgrade path — if you bought Pro, you get the full thing. Trial days are counted from first run, tracked in %APPDATA%/eyehands/.trial_start. The activation server enforces a 2-machine simultaneous limit per license.

Browser extension screenshot bridge

Screen capture on Windows normally goes through DXGI via BetterCam. This is fast (57ms cold, <10ms warm) but has two problems: it doesn’t capture WSL windows, and it occasionally grabs a black frame when the compositor is mid-transition.

1.7.0 adds an optional browser extension (Chrome, Firefox, Opera) that captures the visible tab using the native chrome.tabs.captureVisibleTab API and pushes it to eyehands over a local WebSocket. It’s not a replacement for DXGI — it only sees the browser — but when your target is a web app, it’s both more accurate and more resilient than capturing the desktop.

/ext/setup — guided install page that detects your browser and points at the right store listing
/ext/screenshot — async endpoint that asks the extension for a fresh capture
/ping now surfaces whether the extension is connected so agents can choose the right capture path

For agent authors: /ext/screenshot is now the primary screenshot method in AGENT_PROMPT.md when the target is web-based. The documentation rewrite prioritizes it explicitly.

Upgrade

If you’re on 1.6.x from pip:

pip uninstall eyehands (this removes the old server; the CLI and SDK become eyehands-sdk)
Download eyehands-v1.7.0-win64.zip
Extract, run eyehands.exe
Trial starts on first request; license via the portal when you’re ready

If you want the Python-side tooling back:

pip install eyehands-sdk

Scripts that imported from eyehands directly keep working — the symbols moved, but the package name for the client lives on as eyehands-sdk. The CLI eyehands command from the old package is gone; use eyehands.exe for the server and python -m eyehands_sdk.mcp for the MCP server.

What’s next

The Claude Code plugin wrapper is still on the list — just behind a couple of things that got pulled forward. Realistically 1.8 will focus on macOS support (cross-compiled via Nuitka, AVFoundation for capture, CGEvent for input) and a Godot-specific capture path that pulls directly from the editor’s framebuffer. Extension support for Safari is further out.