Sylinko/Everywhere: an on-screen AI assistant that reads your desktop before you ask

The problem Everywhere targets: context you have to retype

Most desktop AI tools make you describe your situation before they can help. You copy an error message, paste it into a chat window, explain which application produced it, and then wait. Everywhere takes the opposite position. The README frames the product as something that "instantly perceives and understands anything on your screen," so the trigger is a keyboard shortcut rather than a clipboard round trip. The stated examples are ordinary and specific: an error dialog you do not recognise, a long technical article you want summarised, a foreign phrase you want translated, a draft email whose tone needs lifting, a claim you want checked. In each case the assistant is invoked over the material rather than beside it. That is the whole pitch, and it is a narrower one than the phrase "AI assistant" usually implies. Everywhere is not trying to be a chat client you live inside. It is trying to be a layer that sits over the applications you already use and answers questions about what is currently visible. The intended user is someone who moves between apps all day and does not want to break that movement to ask a model a question. If your work is already centred on one chat interface, the shortcut-driven model buys you less.

How the on-screen capture and model routing fit together

The repository describes an architecture in which screen context is gathered first and then handed to a model. The README calls this "on-screen awareness" and lists it as a topic alongside ai-agents and mcp. What the material does not do is specify the capture mechanism, whether it is an accessibility API read, a window handle lookup, or a screenshot passed to a vision model. That distinction matters for privacy and for performance, and it is not answerable from the README alone. What is clear is the routing layer. Everywhere supports OpenAI, Anthropic (Claude), Google (Gemini), DeepSeek, Moonshot (Kimi), MiniMax and a local deployment through Ollama, plus custom API endpoints and an Everywhere Cloud Service. That is a wide set, and it means the assistant is not tied to one vendor's pricing or availability. The agent side runs in parallel with the model side. The README lists a web browser, dispatch of sub-agents, local file system access, terminal script execution, MCP tools, Everything Fast Search on Windows, and integrated system apps on macOS. A memory system is marked as work in progress. So the data flow is roughly: screen context plus your typed instruction goes to the selected model, and the model may in turn call one of those agent capabilities. The build stack is C# on .NET 10 with Avalonia for the UI, which is why the application can present a consistent interface across Windows and macOS rather than two separate codebases.

The agent surface is the part that needs scrutiny

Terminal script execution and local file system access are listed as currently supported agent capabilities, not as experimental ones. Read that list again in the context of an assistant that also reads your screen. The combination is powerful and also the main reason to think carefully before installing. A tool that can see what is on your display and can run scripts and touch files is operating with a broad permission set, and the README does not describe a sandbox, a confirmation prompt, or a per-tool allowlist. MCP tools extend the same surface further, since any MCP server you connect adds its own capabilities to what the agent can reach. The README does not document how tool permissions are scoped or whether the user approves each invocation. That is not an accusation, it is a gap. For a personal machine where you are the only user and you understand what you have connected, the trade-off may be acceptable. For a shared or managed endpoint, the absence of documented permission boundaries is the first thing an administrator would want resolved. The documentation also does not state whether screen capture is continuous or only on shortcut invocation, which changes the privacy picture considerably.

Getting it running: what the README actually gives you

This is where the material thins out. The README has a Getting Started section with two subsections, Acquisition and Installation, and Help and Community, but the cleaned text does not include the commands or download steps inside them. So the honest answer is that the installation procedure is not reproducible from what is available here. What can be confirmed is the release history. The most recent tagged release is v0.8.1 from 2026-08-29, and alongside it there are canary builds with names like v0.8.2-canary.20260909.22, published on the same day as the last push to main. The naming convention tells you there are two channels: a versioned release and a dated canary. If you want something closer to stable, v0.8.1 is the one to look at. If you want the newest behaviour, the canary builds are dated and clearly labelled as such. Beyond that, the README points to the official documentation site at everywhere.sylinko.com and to a trailer video, and those are the places to look for the actual acquisition steps. The repository also carries translations of the README in Chinese and Japanese, which suggests a user base that reads those languages, though the README does not state where that base is concentrated.

The licence is unresolved, and that is a blocker for some teams

The repository metadata reports the licence as NOASSERTION. That is not a licence. It means an automated classifier could not match the licence file to a known identifier, or that the file is a custom or modified text. The README has a License section in its table of contents, but the cleaned text does not include its contents, so the terms are not determinable from this material. For an individual running Everywhere on a personal laptop, this may not matter much in practice. For anyone considering it inside an organisation, it is the first question to answer, because a custom licence can carry restrictions on commercial use, redistribution, or modification that a standard permissive licence would not. I am not giving legal advice here, and the point is not that the licence is bad. The point is that it is unknown, and unknown is a different state from permissive. The project also lists a sponsor section and a star history section in its table of contents, which is normal for a project of this visibility, but neither tells you anything about the terms under which you may use the code.

Where Everywhere is the wrong tool

The clearest failure case is the one the README itself hints at: a memory system is still marked as work in progress. If your use case depends on the assistant remembering what you discussed last week, or building a persistent picture of your projects, Everywhere does not yet offer that, at least not as a documented supported feature. The second case is anything requiring a documented, stable interface. The release cadence shows canary builds appearing within hours of pushes to main, and the gap between v0.8.1 and the canary line suggests active development. If you need to pin a version and know that the behaviour will not shift under you, the canary channel is not for you and the tagged releases are spaced far enough apart that you will wait. The third case is a locked-down environment. With terminal execution, file system access and MCP tools all listed as supported, and no documented permission model in the README, deploying this on managed hardware without first establishing what the agent can reach is not something the documentation supports. Finally, if your question is about a document you already have open in a chat tool, the on-screen capture adds nothing over typing.

How it differs from a plain chat client with a screenshot button

The obvious comparison is to any desktop chat application that lets you attach an image. The difference in approach is the trigger and the scope. A chat client with image attachment is pull-based: you decide what to show it, you frame the screenshot, you send it. Everywhere is shortcut-based: you invoke it over whatever is currently in focus, and the context is gathered from the active window rather than chosen by you. That is a real design difference, not a marketing one, because it shifts the effort from composing a request to simply asking a question. The second difference is the agent layer. A chat client answers. Everywhere, per the README, can also dispatch sub-agents, browse the web, run terminal scripts, touch the file system, and call MCP tools. That puts it closer to an agent runtime with a desktop front end than to a chat application. The third difference is model portability. Because OpenAI, Anthropic, Gemini, DeepSeek, Moonshot, MiniMax, Ollama and custom endpoints are all supported, you can move between providers without changing tools. A chat client tied to one vendor cannot do that. Whether those differences justify adopting Everywhere depends on how often you find yourself describing your screen to a model instead of just asking about it.

Maintenance cost and what to check before you commit

The maintenance picture from the available material is a project in active development with two release channels and a documentation site that carries the operational detail the README omits. The last push to main was 2026-09-09, the same day as the newest canary, which indicates a fast cycle. The tagged release v0.8.1 is eleven days older than that canary. If you track canary, expect to update often and expect the version string to tell you the date. If you track tagged releases, expect longer intervals. Either way, the README does not describe a migration path between versions, so upgrading is something you would verify against the official docs rather than assume. On licence, the NOASSERTION label means you should read the actual licence file in the repository before using Everywhere in any context where terms matter, because the metadata alone will not tell you what you are agreeing to. The practical next step is narrow: open the repository, read the licence file, then read the Getting Started section on everywhere.sylinko.com to get the real install commands, since the README in this material does not contain them.

Editorial conclusion

Adopt Everywhere if you want a single shortcut-driven assistant that already understands the window you are staring at, and you are comfortable building from source or tracking canary releases. Do not adopt it if you need a settled licence before shipping it inside a company, or if you want a stable release channel with documented upgrade steps. Verify three things first: the actual licence text behind the NOASSERTION label, what the agent permissions allow by default once terminal and file system tools are enabled, and whether the release you pick is a canary build or a tagged one such as v0.8.1.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Sylinko/Everywhere on GitHub