Viktor.comAn AI coworker that actually does the work
Promoted
Claude Overlay
A floating Claude Code chat that sees your screen
208 followers
A floating Claude Code chat that sees your screen
208 followers
Claude Overlay is a frameless, always-on-top chat window for Claude Code that floats over everything you do. Summon it with a hotkey, ask about whatever's on screen, and Claude captures and reads your monitors before answering. It runs the full Claude Code agent on your own subscription - no API key - so it can edit files and run commands, not just chat. Open source (MIT), Windows.
Nice itch to scratch β I run Claude Code daily plus scheduled headless sessions on the same subscription, so "no API key, uses your existing login" jumped out. Do overlay chats share the same rate limits as terminal sessions, and do screenshot-heavy questions burn through them noticeably faster? +1 on a Mac port, happy to test.
Claude Overlay
@mystorylandΒ Great questions β and yeah, that "no API key" bit is exactly the itch.
β
β Rate limits: same pool, no separate quota. The overlay just drives your own claude CLI through the Agent SDK on the same login, so it draws from the exact same rate limits as your terminal sessions and your scheduled headless runs β they all share one bucket. Nothing about the overlay gets its own budget, so running it alongside everything else just adds to the same usage.
β
β Screenshots: yes, images cost vision tokens on top of the text, and by default it captures one image per monitor β so on a multi-monitor setup a screenshot-heavy back-and-forth does eat in noticeably faster. Two things help: there's an Auto-shot toggle to send text-only when you don't need vision, and I literally just shipped (v1.12.0/1.12.1) a Window-only mode that captures just the active window instead of every monitor β cuts the vision-token cost to a fraction on multi-monitor. Images are also downscaled before sending, and you can force JPEG. So it's pretty controllable.
β
β Mac: it's the #1 request, and honestly the main blocker β the Windows build leans on Win32 for DPI-awareness, rounded frameless corners, per-monitor capture, and the taskbar button, so a port means reimplementing those platform bits. It's MIT, so a PR would be very welcome β and I'll absolutely take you up on the testing offer when there's something to try.
@shengyanlinΒ "One bucket" is exactly what I needed to know β my scheduled runs already budget against that pool, so the Window-only capture is the right kind of lever, and shipping a vision-cost control mid-launch-week is a good sign. Will keep an eye out for a Mac build β the testing offer stands.
One thing I'd love to see is cross-monitor support for the screenshot capture, specifically the ability to pick which screen Claude reads instead of grabbing everything at once. Would make it way more useful when working across a laptop and external display setup.
Claude Overlay
@apiliogull53162Β Yeah, this is a good one β and it's squarely on my list. Right now it grabs every monitor and hands Claude one labelled image per screen (primary vs. secondary), with no way to say "just this one." On a laptop + external-display setup that's exactly where it gets clumsy β you end up spending tokens (and Claude's attention) on the screen you don't actually care about.
Good news: this one's very buildable. Under the hood it already enumerates each monitor and captures + tags them separately, so adding a "which screen(s)?" picker is a natural next step rather than a rewrite β probably a little per-display toggle. It's open source (MIT) if you'd ever want to take a swing at it; otherwise it's going on the roadmap.
Quick workaround in the meantime: since each screen is labelled in the prompt, you can just tell Claude "only look at my external display" and it'll focus there. Thanks for the great suggestion π
I really like that this is more than just a screen-aware chat. The fact that Claude can act on the file thatβs already open makes it feel like part of the workflow rather than another window to manage.
Are you considering making context and permissions configurable for each overlay? For example, one overlay could be tied to a specific project in read-only mode, while another could be allowed to edit files. That could make using multiple overlays feel much safer and more predictable.
Nice work, Jason!
Claude Overlay
@yuri_liubymovΒ Thank you β "part of the workflow rather than another window to manage" is exactly the feeling I was going for, so it's really good to hear it lands that way.
And yes, this is a direction I find genuinely exciting. Some of the pieces are already there: you can run multiple overlays side by side today β but right now they share one global config, so they aren't independently scoped yet. What you're describing β pin overlay A to project X in read-only, let overlay B edit β is very much the right model, and the building blocks exist under the hood (Claude Code already has permission modes and working-directory scoping; it's mostly a matter of surfacing them per instance). Making each overlay its own little sandboxed context is high on my list. It's MIT if you'd ever want to help shape it β otherwise it's going on the roadmap. Great suggestion
Really like that this sits on top of the existing Claude Code login instead of adding another agent layer.
One thing Iβd want for daily coding use is a small run receipt after each screen-driven action: screenshot source, files touched, commands run, and which step came from what was visible on screen. When the input is a screen, debugging a wrong action later gets harder than with a normal prompt.
That kind of trace would make the overlay feel safer for long work sessions, not just faster.
Claude Overlay
@grace_lee26Β Thanks β "on top of your existing login, not another agent layer" was a deliberate choice, so I'm really glad that lands.
And this is a great ask β honestly the missing half of the safety story a few people have raised in this thread. You're right that screen input makes provenance murkier: with a text prompt you can re-read exactly what you asked, but "what was on screen" is fuzzier to reconstruct later.
Where it stands today: every command and file edit already streams into the chat as a visible tool chip as it happens, and each turn notes which monitors were attached β so there's a live trace, just not a consolidated, reviewable receipt. Under the hood the captured frames are saved to a temp folder and there's a debug log, so the raw material for a proper trace already exists.
What you're describing β a compact per-action receipt (screenshot source β commands run β files touched) you can scan after the fact β is very buildable and I want it. Honest nuance: the coarse version (this turn captured monitors 1+2, ran X, edited Y) is straightforward; the fine-grained "this specific edit traces to this region of the screen" is harder to do reliably, so I'd likely ship the per-turn receipt first. It pairs naturally with the read-only mode a couple of others asked for β trace + scoped permissions is exactly what makes it feel safe for long sessions, not just fast. Going on the roadmap; MIT if you'd ever want to help shape it. Excellent suggestion
The screenshot-as-untrusted-input point is the real one. What's worked for us: observed content (screen, docs, pages) is always data, never instructions, and any write/run action needs a separate human confirm the on-screen text can't trigger itself. Read β act. Great ship β the real-CLI-login approach is clever.
Claude Overlay
@ryan_davis23Β This is the most useful design note in the whole thread β thank you. You've drawn the exact line I want: "read β act," observed content is data not instructions, and write/run needs a gate that on-screen text can't reach.
Honest status on where the overlay sits against that. The first half it gets for free: the agent underneath is Claude Code, which is trained to treat screen/doc/page content as data to reason about, not instructions to obey. The second half is the gap I'll own β because it's a no-TTY GUI, it currently auto-approves tool calls (otherwise a permission prompt would just hang with nowhere to answer), so there isn't yet a separate human confirm before a write or a command. Everything's at least visible as it streams, but visible β gated, and I won't pretend otherwise.
The encouraging part: the hook for exactly what you describe already exists β there's a single can_use_tool chokepoint every action flows through. Today it returns "allow," but that's precisely where an in-app approve/deny for write/run tools belongs, with reads staying instant so "read β act" is actually enforced, not just intended. That, plus the read-only mode a couple of others asked for, is clearly the next thing to build. Really appreciate you sharing what's worked for your team
@shengyanlinΒ @jasonlin One thing that's saved us at that chokepoint: gate by classification, not prompting. Hardcode the tool split (read tools β instant; Write/Edit/Bash/anything that mutates β in-app approve), and make unknown tools default-deny β MCP servers can add write-shaped tools you never enumerated. Read-only mode falls out for free: same classifier, gate welded shut.
And watch approval fatigue β if every write prompts, users click yes without reading and you're back to auto-approve with extra steps. Per-project "always allow" scoping keeps the gate meaningful.
Nice, neat demo! Is this constantly recording the screen and if yes, is that something token efficiient. Also it is also paired with voice input along with screen share thing?
Claude Overlay
@shekhar_upadhaya_1Β Thanks! Nope β it's not constantly recording. It grabs a single still frame per monitor at the moment you hit send (or reuses one it pre-grabbed a couple seconds earlier while you were typing) β no video, no continuous feed. That's exactly what keeps it efficient: one bounded still per screen, downscaled to 1568px on the long edge (Claude's own internal ceiling) and JPEG-compressed, so it's ~1.5K tokens per screen rather than a stream. There's also an "Auto-shot" toggle β off means it captures nothing unless you explicitly attach it, so a text-only question costs zero image tokens.
On voice: not right now β input is text + screen capture + pasted images (Ctrl+V). And to be precise it's not a live "screen share" feed either, more an on-demand snapshot attached to your message. Voice pairing is an interesting idea though β noting it
nice, any plan to do that with Codex as well?
Claude Overlay
@luca_arditoΒ Not right now β it's built specifically on the Claude Agent SDK, which drives the claude CLI directly (that's how it avoids needing an API key). Making it work with Codex would mean a different driver underneath, so it'd be a real fork rather than a flag. It's MIT-licensed though, so if someone wants to take a crack at a Codex version I'd definitely point people to it