senn-techAn AI agent that presents itself as a keyboard: the capability is real, the number on the product page is not
A click that nobody else can place on a Mac. Since macOS Mojave, the system discards synthetic input the moment it targets a permission dialog. A software agent sends a fabricated mouse event, the OS sees software and drops it. In a test video on Alex Ziskind's channel from September 19, 2026, an unfamiliar box sits next to the MacBook and confirms the dialog anyway. It installs nothing. It enumerates as a keyboard and a mouse, and as far as the OS is concerned, that is what it is.
The device is Violoop, from BVIO Technology Limited, live on Kickstarter since September 15, 2026 at US$399 against an expected US$699 retail. The product page carries one figure that cannot be produced on the silicon it names. We are recomputing it, because it is not a marketing detail but the core assumption of the product: local enough to keep most of the work out of the cloud.
What the device is
| Component | Claim on violoop.ai | Status of our check |
|---|---|---|
| SoC | RK3576, eight cores | vendor claim, typical for this class |
| AI accelerator | "26 TOPS" | Rockchip itself lists 6 TOPS for the RK3576 |
| Local model | Qwen 8B at Q4, 53 tokens/s | not reproducible, arithmetic below |
| Reference | Mac mini M4, 20 tokens/s | plausible for 8B at Q4 |
| Screen capture | HDMI 2.0, 4K | passive branch, cleanly separable |
| Input | USB-HID, no drivers | this is the actual mechanism |
| Confirmation | physical key on the case | demonstrated, firmware not inspected |
| Vendor | BVIO Technology Limited | EU responsible party under GDPR and GPSR: not stated |
Two of those are solid. The capture is passive, the computer notices nothing. The HID input is a real keyboard, not a trick. Together they produce a capability no software agent has.
The 53 tokens per second do not survive a division
The sentence on the page: a full 8B model, 100 percent on the device, 53 tokens per second, 2.7 times faster than a Mac mini M4 at 20 tokens per second. Same model, same precision, Ollama as the reference. Against it stands a division.
A model with 8 billion parameters occupies about 4.25 GB of weights at 4-bit quantization. Decoding produces one token at a time, and each token reads those weights in full, in principle. Throughput is capped by memory bandwidth, not by compute. The RK3576 has two 32-bit channels: at LPDDR5-6400 that is 51.2 GB/s theoretical, at LPDDR4X-4266 about 34 GB/s.
| Calculation | Value |
|---|---|
| Weights, 8B at Q4 | 4.25 GB |
| Theoretical bandwidth, best case | 51.2 GB/s |
| Ceiling at 100 % utilization, no KV cache | 12.0 tokens/s |
| Realistic with KV cache and activations | 6 to 9 tokens/s |
| Figure on the product page | 53 tokens/s |
The 6 TOPS of the NPU are not the problem. Counting two operations per parameter and token, 6 TOPS at full utilization gives well over 300 tokens/s on paper. The bottleneck is the path the weights take through memory. That is a ceiling, not a benchmark.
There are also public measurements on the same chip family. Turing Pi measured in August 2026 on the larger sister chip RK3588, RKLLM 1.3.0, fixed clocks, five runs per model:
| Model | Format | Decoding on the RK3588 |
|---|---|---|
| Qwen2.5-1.5B-Instruct | W8A8, NPU | 9.50 tokens/s |
| Qwen2.5-3B-Instruct | W8A8, NPU | 4.94 tokens/s |
| Qwen2.5-1.5B-Instruct | W8A8, Rockchip reference | 16.69 tokens/s |
| Qwen2.5-1.5B-Instruct | Q4_K_M, llama.cpp on CPU | 22.57 tokens/s |
| Extrapolation to 8B on the NPU | W8A8 | about 1.9 tokens/s |
None of these reaches the claimed 53 with a 1.5B model, let alone close to it. The 8B class on a chip with half the memory path sits an order of magnitude below. The chosen comparison, a Mac mini M4 with 120 GB/s at 20 tokens/s, is almost fair. Only the vendor's own number is not.
Our rule here is the same one we applied to the cross-user leak in our own inference engine: a version number is not a finding, and a banner is not a benchmark.
What is genuinely new about it
We are not going to let the wrong number cost us the right detail. The capability is real, and the video demonstrates it twice: a permission dialog the device confirms on its own, and a cleanup command in a Finder folder that stops before anything is deleted.
The tester separates seen from believed. Seen: the click on the dialog, the stop before deletion, the key press. Not verified: that raw frames really stay on the device and get discarded, and that the confirmation key sits on its own chip. That board's firmware will be open, the vendor says; it is not published. The feature the product is sold with, noticing repeated patterns in a workflow and offering to take them over, did not trigger once.
That is an honest demonstration, and nothing more can be written about a pre-production unit. It is also the full width of the finding: one proven capability, two unverified claims, one core feature with no effect.
Why the picture changes in production
On a single curious desk, this is a toy with use. In a company network in the Tyrolean Unterland, where ERP screens, bills of material and customer names sit on the displays, the construction itself becomes a decision. Four questions, in our NIS2 lead categories:
| Question | What we would have to answer | Category |
|---|---|---|
| Who sees all the screens? | A vendor whose EU establishment we cannot name | Confidentiality |
| Who gets to type? | Anything that can send something to this USB device, update channel included | Access control |
| What is logged? | Nothing on the endpoint. No driver, no agent, no inventory entry | Logging |
| What on compromise? | Forms operated beyond the OS boundary, on every device at once | Integrity |
The point that held us longest is the protection itself. macOS discards synthetic input on security dialogs so malware cannot press "Allow" by itself. A device that presents as a real keyboard walks past that line. Phrased neutrally that is a feature, in a network with 40 to 110 workstations it is an attack surface with a network connection. "No drivers" means no trace in endpoint inventory and no group policy that applies. Our NIS2 self-assessment treats such devices as an access someone must be able to attribute.
Then there is "local-first". Bring your own key with Claude, OpenAI or Gemini is explicitly supported, and in the video the chain also ran through a local DeepSeek endpoint on the tester's network. So the device can understand locally and still send derived screen content to third parties the moment a cloud key is configured. What counts is not how far the data was processed, it is where it flows. A screen with customer names stays a screen with customer names, even if only the summary leaves.
What we take from it
The parts for the same capability sit open on the shelf: an HDMI capture device, a microcontroller that enumerates as HID, an own AI chain on LiteLLM and vLLM, and a gateway that decides per key what may leave the building. What is missing is the image-to-action layer, and that is a software problem, not a hardware problem. The part of Violoop worth considering is the input path, not the box.
Our decision: not on a production or domain-joined host, not with a cloud key, not without a documented EU responsible party. It stays on the watch list for an isolated test machine against an endpoint we own. The assessment flips when the confirmation board's firmware is published and re-checked by someone else, and when a vendor with warranty becomes reachable under EU law. Until then, the 8B figure on the front page is the best indicator of how carefully the remaining claims are handled. For internal security training, the frame sits in security awareness for SMEs.
Further Reading
- Violoop product page, specifications and claimed measurements, September 19, 2026
- llms.txt from violoop.ai, vendor identification BVIO Technology Limited
- Test video: My AI Agent Lives OUTSIDE My Computer, Alex Ziskind, September 19, 2026, sponsored, unit V3
- RKLLM on RK3588, Qwen2.5 benchmarks, August 1, 2026, basis of the measurements above
- RK3576 product page, 6 TOPS rather than 26 TOPS
- Violoop download page, shipped platforms and versions
- Launch report with pricing, September 15, 2026
Isn't such a device just a KVM over IP?+
In its mechanics, yes, and that is not a dismissal. A KVM over IP is a real keyboard as far as the operating system is concerned, and it can confirm the same permission dialog. The difference sits one level higher: with a KVM, a human is on the other end and knows which button to press. With Violoop, a model decides which button is meant based on a screen image. That decision is the new part, and it is also the hard part to verify.
Why is the 53 tokens per second claim not just optimistic but impossible?+
Because autoregressive decoding is bound by memory bandwidth, not by TOPS. A model with 8 billion parameters occupies about 4.25 GB of weights at Q4, and every new token reads them in full, in principle. The RK3576 has two 32-bit memory channels. Even at 51.2 GB/s theoretical bandwidth with 100 percent utilization, no KV cache and no activations, the arithmetic ends at roughly 12 tokens per second. Publicly measured values on the larger sister chip RK3588 sit at 9.5 to 16.7 tokens per second for 1.5B models.
Are we allowed to put such a device on the corporate network?+
On a production or domain-joined host, our reading is no. The device holds a continuous capture of every screen plus the ability to operate any form as an input device. It appears in no endpoint inventory, and no group policy applies, because it deliberately runs without drivers. Then there is the data flow: bring your own key with Claude, OpenAI or Gemini means derived screen content leaves the building. If at all, then on an isolated test machine, not domain-joined, no ERP access, and pointed only at an inference endpoint we own.