What an assistant sends when it looks at your screen
We put a capture proxy in front of our own app and read every byte it sent. One question with the eye open was 327,877 bytes. 89 percent of it was one PNG.
A whole tool class arrived without a single measured answer
Assistants that watch your DAW, listen to your output and read your plugin folder now exist in every producer's feed (what this category actually is). The question underneath them is old and simple: what leaves my machine. Search for it and you get forum threads guessing at each other, marketing pages promising that privacy matters, and almost no bytes.
So we measured our own app, on 15 August 2026, against the real production endpoint, with a real Ableton Live 12 window open. Not a review of the design. The actual request bodies.
Key takeaways
- With the eye on, one question produced a request body of 327,877 bytes, and 218,911 of those bytes were a single 1200 by 792 PNG. That is 89 percent of the message.
- With the eye off, the same question in the same session produced 31,763 bytes and no image field at all.
- Pressing the manual capture button produced 3,158,107 bytes, of which 97 percent was one 6250 by 4126 PNG.
- Sitting idle for 120 seconds with the app and the DAW open produced zero open sockets across 12 samples, and zero requests in the proxy log.
- The plugin inventory travels with every single message. On the machine under test that is 1105 names and 20,924 bytes.
- The measurement contradicted a sentence in our own privacy copy, and that sentence is the reason this post exists.
The setup
The app was pointed at a capture proxy on the local machine. The proxy wrote each request body to disk exactly as it arrived, forwarded it to the real production endpoint, and streamed the real response back. The session, the answers and the streaming were all genuine. The only difference from a normal day is that a copy of every body was kept.
Nothing persistent was changed on the machine, and no product code was touched for the run. A measurement that requires a special build measures the special build.
Three runs, one session
| run | condition | body | image field | pixels |
|---|---|---|---|---|
| 2 | eye on, asked what is on my screen | 327,877 B | vision_frame | PNG 1200 by 792, 218,911 B |
| 3 | eye off, same question | 31,763 B | none | none |
| 4 | eye off plus manual capture button | 3,158,107 B | images | PNG 6250 by 4126, 2,300,127 B |
Run 3 is the control, and it is the run that matters most. Turning the eye off did not shrink the picture or lower its quality. The field is not in the body.
The model's own answer in run 3 confirms it from the other side: it said no fresh frame had arrived with that message. In run 2 it described the browser panel on the left, the empty arrangement view, and the track names down the right side. It was reading the picture, because the picture was there.
What is actually in that frame
The decoded PNG is the whole arrangement window: the library and device tree on the left with hundreds of preset and device names legible, the track list on the right, the device panel along the bottom.
That is worth stating plainly, because it is the part a feature description tends to skip. The frame is a visual superset of the written session context. It contains things the text fields never carried, and anything visible inside that window at the moment you ask is inside it.
The capture itself is limited to one window at the operating system level rather than by cropping afterward, so other applications are not in the image. That is a real boundary and it is worth knowing where it sits: the boundary is the DAW window, not the DAW project.
What travels even when nothing is looking
The body carries ten top level fields. The image is the loud one, so the quiet ones deserve naming:
- The plugin inventory. On this machine, 1105 names and 20,924 bytes, on every message. Names and categories only. Paths, versions, formats and vendors do not travel. The scan runs locally, but the result of the scan does not stay local, and those are two different sentences.
- The local clock, as a time of day. No date, no timezone, no location.
- A device header, a local hash of the hardware identifier, used as a quota anchor. It does not resolve back to a person, and it is still something that leaves the machine.
- Session context in words: track and device lists, tempo, listening state, consent and status objects for the eye and the ear.
Proving an absence is harder than proving a presence
Showing that something is sent takes one capture. Showing that nothing else is sent takes a different kind of work, so here is how the negative side was built.
- Count the exits. The application has five places where it reaches the network. Four of them carry sign in codes, ear training results, share metadata and a file the user explicitly picked. Exactly one can carry pixels.
- Check the disk. The frame is never written to a file. After the run, the local conversation history contained zero PNG signatures.
- Check for passengers. No analytics, telemetry or crash reporting library is linked into the binary at all, so there is no second path a picture could ride out on. Diagnostics go to the local system log and have no upload route.
- Watch it do nothing. With the app and the DAW open and untouched for 120 seconds, open sockets were sampled every 10 seconds. Twelve samples, zero sockets, and zero requests reaching the proxy. Across the whole run there were three requests, which is exactly the number of messages that were typed.
On the server side the frame is handed to the model as an image block for that one request. There is no path that writes it to storage. It lives for the duration of the request, and it does go to a third party, because the model is one.
The sentence this measurement killed
Our own privacy copy said, in as many words, that your screen never leaves and that what travels is session context written out in language.
The second half is true. The first half is false, and the measurement is what proved it. The picture leaves. It is not an accident or a bug, it is the intended behaviour of a feature that has to look at something to answer a question about it.
The sentence never reached a reader, because that page sits behind an approval gate and was still showing a skeleton. That is luck as much as process, and it is not the interesting part. The interesting part is that the honest replacement is narrower and more useful than the promise it replaces:
Your screen has no video. What leaves is one still, of one window, taken at the moment you ask, and the still is neither written to your disk nor kept in your history.
That replacement is now the live sentence on our privacy page, which came out from behind its approval gate on the day this post was published.
A privacy claim you have not measured is a wish. This one now has a byte count behind each half of it, and where the count contradicted us we changed the sentence rather than the measurement.
Run this on any tool you are unsure about
The method is not specific to us, and nothing here needs source code access:
- Put something between the tool and the internet. A local proxy the app can be pointed at, or a system proxy with a certificate you trust.
- Ask the same question twice, once with the feature on and once with it off, in the same session. The difference between the two bodies is the feature, with nothing else moving.
- Compare sizes before you read anything. A body that jumps by two hundred kilobytes is carrying an image whatever the field is named.
- Search the raw body for image markers, then decode what you find and look at it. What is inside the frame is a separate question from whether a frame exists.
- Then leave it alone and watch. Idle traffic is the claim most tools never test, and it is the easiest one to check.
Questions
Does turning the eye off actually stop the capture, or just hide it?
In this measurement it stopped it. The image field is absent from the body rather than empty, and the model reported having no fresh frame. Absence of the field is a stronger result than a blank value, because a blank value still implies a code path that fills it.
Is a screenshot worse than sending audio?
They are different exposures rather than a ranking. Audio carries the music. A window still carries names: tracks, presets, devices, whatever is on screen. Producers usually worry about the first and get surprised by the second.
Why publish a measurement that contradicted your own page?
Because the alternative is publishing only the measurements that agree with us, which would make every one of them worthless. The same rule applies to the numbers behind band balance and to how key detection fails: the limits get published with the result.
What is still not measured here?
Retention on the model provider side, which is not ours to assert. Our own storage durations left this list on the day this post went up: they are now published as numbers, printed from one place in the code rather than typed into a sentence. An invented retention figure would make the measured ones look invented too, which is why they waited for a real one.
The short version
An assistant that looks at your screen sends a picture of your screen. That should be obvious and yet it was wrong on our own page until somebody counted the bytes.
If you use a tool in this class, ask its makers for numbers rather than for promises. We publish ours because Miles has to be worth trusting with a window open.