Perceptron Mk1.5: A Perception Model That Drives the Loop

A perception model that only describes what a camera sees still needs something else to decide what to do. In a robot or a drone that something else is usually a second model, a hand-written state machine, or both, and every hop adds latency and a place for the two halves to disagree.

Perceptron Mk1.5, released on 25 September 2026, is the company's attempt to close that gap. Perceptron describes it as a model for controlling embodied agents and says it already runs on drones, robotic dogs, smart glasses and phones without platform-specific retraining. The pitch is not better captions. It is that the same model can see, hear, track and call the functions that move the hardware.

What changed from Mk1

Perceptron Mk1, released in May, was a closed vision-language model that answered in coordinates: points, boxes, polygons and timecodes. Mk1.5 keeps that output vocabulary and adds five things:

• Audio input. Text, images, video and now audio, which enables time-aligned transcription and sound-based event detection.
• Object tracking. It emits timestamped geometries through a video rather than independent per-frame detections, which can save some of the re-identification work a tracking pipeline usually needs.
• Tool calling. Any function declared in the OpenAI format with a JSON Schema. The OpenRouter listing accepts tools and tool_choice, which the Mk1 listing does not.
• Sub-agents. Perceptron says it can spawn sub-agents to parallelise work.
• Lower latency. Covered below, because it is the change that matters most for physical systems.

What did not change: the model is closed, Perceptron has not published a parameter count or architecture, and the vendor states the same 32K tokens of multimodal context. Price is unchanged too, at $0.15 per million input tokens and $1.50 per million output on Perceptron's own listing, matched on OpenRouter at the time of writing.

Controls as tools

The design idea is simple. Each platform exposes its controls as functions, say move_forward, rotate, take_photo, and Mk1.5 runs inside an ordinary agent loop deciding which to call. That is the same shape as a coding agent, with a camera feed in place of a file system.

It also inherits the same risks. A model that can call move_forward can call it when it should not. Put hard limits outside the model: speed caps, geofences, an emergency stop that no tool call can override. Best model for tool calling covers why schema discipline and argument validation matter more than raw intelligence, and that applies twice over when the tool has wheels.

Latency is the headline

Perceptron reports median end-to-end times, Mk1 against Mk1.5:

• Chat: 5.2 s to 1.1 s
• Image question answering: 1.7 s to 0.51 s
• 60-second video: 19 s to 9.1 s

For a chat product, half a second is nice. For a control loop it decides what the system can do at all. A drone that waits five seconds for each decision cannot follow anything that moves; one that waits half a second can, if the rest of the loop is fast too. Measure on your own network path, because the vendor's medians exclude your round trip.

There is a catch in the defaults. OpenRouter lists Mk1.5 with reasoning effort levels from none through minimal, low and medium to high, and high is the default. Reasoning spends output tokens and time. For per-frame control decisions start at none or minimal and raise it only for the planning steps that need it. Best model for low latency explains why time to first token dominates in this kind of loop.

Reading the benchmark tables honestly

Perceptron's launch post is more candid than most, and it is worth reading both columns. On its own egocentric evaluations it reports hand localisation roughly 50 percent better than the strongest Gemini model it tested, and on the LiveVQA-W multimodal search set it reports 56.0 against 53.2 for a Gemini Flash model with Google Search grounding.

It also shows where Mk1.5 trails. On Perception Test it reports 67.6 against 84.1 for Gemini 3.1 Pro, and on TempCompass 78.0 against 88.2. On the DailyOmni audio-visual set it reports 74.67, behind Qwen3.5-Omni-Plus, Qwen3.5-Omni-Flash and Gemini 3.1 Pro Preview, and says plainly that Mk1.5 is not at the frontier of audio-visual understanding in this first release.

The pattern is coherent: strong where the task is spatial and first-person, behind on general video comprehension and on audio. All of these numbers are vendor-run, several on Perceptron's own harness. Treat them as a map of where to test first, not as a verdict.

Where it fits

• Good fit: egocentric video from glasses or a robot's camera, grasp and hand localisation, object tracking for inventory or sports analytics, annotating robotics training data.
• Weaker fit: long-form video comprehension, audio-heavy understanding, anything that needs more than 32K tokens of footage in one pass.
• Wrong fit: projects that need self-hosted open weights. On-premises deployment is a conversation with Perceptron's sales team, not a download.

Against Mk1 the decision is short. Same price, faster, more capable: use Mk1.5 for new work and keep Mk1 only where a validated pipeline depends on its exact behaviour. OpenRouter lists Mk1.5 under a dated canonical slug, perceptron-mk1.5-20260925, so you can pin this build in the same way.

Testing it in a loop

Single-image accuracy says little about a controller. Test the loop:

1. Record ten real sessions from your platform, with the control decisions a competent operator made.
2. Replay the sensor stream offline, frame by frame, and let Mk1.5 choose tool calls at none and at medium effort.
3. Score agreement with the operator, wall-clock time per decision and how often it calls a tool that should not have been available in that state.
4. Only then run it live, behind the hard limits above.

Offline replay is cheap, repeatable and safe. How to benchmark LLMs on your own work covers the harness side; the physical version adds one rule, which is that nothing reaches a motor until it has passed on recordings first.