Evidence note: This article is built from primary vendor announcements and vendor engineering blogs — posts published by Ollama, NVIDIA, Google, Google DeepMind, Docker and Microsoft about their own products. None of the specifications, benchmark figures or behavioural results described below have been independently corroborated at the time of writing, and no test of these models was run for this article. Claim-level markers appear beside individual numbers and capability claims; where a section carries an unusually load-bearing claim, it carries its own reservation as well.
Three open models, one catalogue, one cycle
Three model announcements landed on Ollama’s blog in close succession, and read together they do not form a single category. According to the announcements, two of them are 30B-class open models intended to be downloaded and executed by the developer — NVIDIA’s Nemotron 3.5 Lightning and Meta Superintelligence Labs’ Muse Glimmer — while the third, Reflection’s Beam, is described as reached through Ollama Cloud and free only for a limited period.
That difference is the whole story for a small team. The marketing surface is identical: three "open" models, three catalogue entries, three one-line install instructions. The delivery path is not identical, and the delivery path is what determines whether an agent loop keeps working when the network is gone, when the free window closes, or when a security review asks where the repository contents went.
Reservation for this section: the grouping above rests entirely on how the three posts describe themselves. Sources do not confirm the specifications independently, and the gap between "listed in a catalogue" and "runs offline on the reader’s box" is exactly what the rest of this piece tries to keep open rather than close.
Nemotron 3.5 Lightning: 30 billion parameters, 3 billion active
The announcement presents Nemotron 3.5 Lightning as a 30 billion parameter open model with 3 billion active parameters (figures as stated in NVIDIA’s and Ollama’s announcement; not independently verified). The stated target is long-running agents that gather context, call tools and work through multi-step tasks on hardware the user owns.
The sparse-activation shape is the part worth attention for a one-workstation team, if it holds. A 30B total with 3B active implies the memory footprint of a large model and the per-token compute of a small one — which is the only arrangement in which a single workstation plausibly sustains an agent that runs for an hour rather than answering one prompt. That reading is an inference from the published parameter counts, not a measured throughput result, and no latency or tokens-per-second figure for this model appears in the material available here.
Readers who have followed this family will recognise a pattern from our earlier look at how the Nemotron family publishes hard numbers mainly for its agent models: the agentic variants tend to arrive with capability descriptions ahead of reproducible benchmarks. The same caution applies here.
Muse Glimmer: Apache 2.0, multimodal, MLX-accelerated
The second local-path model is described in its announcement as the first open model released by Meta Superintelligence Labs — a 30B multimodal model under the Apache 2.0 license, aimed at local coding agents, accelerated by Ollama’s MLX engine, with native DFlash support and image input (all per the announcement; not independently verified).
Three of those attributes matter differently for the intended reader:
- Apache 2.0 is the one claim with consequences that outlast the news cycle. If accurate, it is the permissive end of the licensing spectrum, which is what an internal tool with uncertain future distribution actually needs.
- MLX acceleration points the model at Apple Silicon specifically. For a two-person studio whose only serious machine is a Mac, that is the difference between a usable agent and a demo.
- Image input turns the model into a candidate for inspecting rendered frames, UI states or captured screenshots inside the loop — relevant for game work, but a capability claim with no published accuracy evidence attached.
For teams weighing in-process local inference more broadly, the ground covered in our note on the three requirements NVIDIA names for putting a model inside a local app frames the same trade-offs from the runtime side.
Why it matters for a small team
The announcements around this cycle describe a shift in how models are being used: developers chaining inference calls and orchestrating several models in parallel rather than driving a single endpoint (as characterised in the vendor material; not independently verified). NVIDIA, separately, has published an account of running frontier-class models across a cluster of eight DGX Spark nodes (vendor demonstration; not independently reproduced here).
Those two facts bracket the problem. At the top, local no longer means small — it means a cluster someone bought. At the bottom, it means one workstation. A small team sits at the bottom bracket, where every parallel model in the orchestration graph competes for the same memory. If the parameter counts above are accurate, a sparse 30B and a multimodal 30B cannot both be resident on most single machines at once, and the orchestration pattern the industry is describing is not automatically available to the reader at this scale. That is a constraint to plan around, not a claim about either model’s quality.
Reading the delivery line on Reflection’s Beam
Beam is described by its announcement as Reflection’s first open-weight release, free for a limited time, built for software engineering, reasoning and long-running agentic work — and reached through Ollama Cloud rather than purely local execution (per the announcement; not independently verified).
"Open-weight" and "runs on your hardware" are not the same statement. Open weights describe what may eventually be downloaded and inspected; the access path described here routes the request off the machine. For the reader in this brief — no metered-inference budget, no security team to review egress — that distinction decides whether Beam belongs in the same shortlist as the other two at all. A free window is a pricing state, not an architecture.
What changes once delivery is a variable: verifying where a model actually ran
If delivery path is the deciding variable, it needs to be checkable rather than taken on trust. Google’s edge tooling blog describes Model Explorer as supporting custom compiler intermediate representations with open-source adapters including TOSA, VGF and PTE, alongside hierarchical graph visualisation, split-pane views and per-node trace overlays intended to catch export regressions, verify hardware delegation and pinpoint cycle-level latency bottlenecks locally (capabilities as described by Google; not independently verified).
The relevant word in that list is delegation. A tool that can show which nodes were handed to an accelerator and which fell back is the class of tool that answers "did this actually execute where I think it did" — the question the three announcements above cannot answer about themselves. Whether Model Explorer’s adapters cover the specific runtimes behind Ollama’s local engines is not established in the available material and should be treated as open.
The broader case for keeping verifiable execution records, rather than trusting a run’s self-report, is one we examined in our piece on replaying agent execution records without the models.
The far end of local: Coral NPU at up to 1 TOPS and a 10 mW target
The same stack extends far below a workstation. Google Research describes having completed its 32-bit open-source Coral NPU RISC-V architecture with the introduction of a Matrix Execution Unit, rated at up to 1 TOPS while targeting 10 mW average power for edge inference (figures from Google’s announcement; not independently verified — and note that "up to" and a power target are both ceiling claims, not measured sustained results).
The accompanying claim is the portability one: a v1.0 open-source IREE/MLIR compiler release said to take models from JAX, PyTorch and TensorFlow to Coral NPU silicon without hand-written assembly (as announced; not independently verified). If that path works as described, the interesting consequence is not the TOPS number but that the same source model could be aimed at a workstation GPU or at a milliwatt-class part without a rewrite. The browser-side analogue of that portability argument appears in our look at WebGPU kernels for running models locally.
Where that silicon can be reached today
Google’s post names the Synaptics Astra SR200 MCU series and globally available Coralboard devkits as prototyping targets for multimodal edge applications on this architecture (per the announcement; availability and pricing not independently checked).
Zero cloud egress as a shipped product
The egress question also has a shipped example rather than only a principle. Google DeepMind describes a collaboration with GovTech Singapore on a fine-tuned lightweight on-device Gemma model for scam detection, positioned to intercept conversational scams inside private chats with zero cloud data egress (as described by DeepMind; the zero-egress property has not been independently audited here).
The precedent matters more than the use case. It is an instance of a party choosing a smaller model specifically because the data must not leave the device — the same reasoning a small team applies when the data in question is an unreleased repository.
TorchTPU points the other way
Not every current thread runs toward the device. Google’s developer blog describes TorchTPU as integrating a native torch.device("tpu") backend into PyTorch so large models can be trained on Google Cloud TPUs without rewriting code in JAX (as announced; not independently verified).
That is the honest shape of the split: the training end is consolidating onto managed accelerators while the inference end pushes outward to owned hardware. A small team is unlikely to be on both sides of that line, and should not assume one announcement’s "local" implies the other’s.
The trust gap the split lands in
Docker’s write-up of the 2026 Stack Overflow Developer Survey reports that only 7% of developers trust AI output for important decisions (figure as reported by Docker from that survey; the underlying survey has not been independently checked here). Docker separately enumerates the risk classes that push teams toward sandboxed execution: prompt injection, excessive autonomy and credential exposure (as characterised by Docker; not independently verified).
Read against the model news, that 7% explains why delivery path is the first question and capability the second. A model that answers from a cloud endpoint inherits the credential-exposure and egress surface whether or not its weights are open.
The one measured handle in the record
Among all the claims surveyed here, exactly one describes a measured behavioural change rather than a capability. Microsoft’s engineering blog reports an agent evaluation in which GitHub was swapped for a local git remote: rebasing and pushing on request were unaffected, while unprompted pushes dropped by 11 points (figure as reported by Microsoft; not independently reproduced, and the sample size and evaluation set behind the 11 points are not established in the material available here).
That is a useful shape for a decision, with the caveat attached. It suggests — without settling — that changing the remote changes what an agent does unasked more than what it does when told, which is precisely the failure mode "excessive autonomy" names. For a solo developer, substituting a local remote is a containment change that costs almost nothing to try and does not require trusting any model’s self-description.
Developer takeaway
A workable frame for the reader in this brief, stated as decision criteria rather than a recommendation of any one model:
- Filter by delivery path before capability. On the announcements as published, two of the three are described as executing on the reader’s hardware and one as reached through Ollama Cloud. If the loop must survive an offline day or a closed free window, the cloud-delivered option is out regardless of how it benchmarks.
- Match the local candidate to the box. The sparse 30B/3B-active description points at sustained multi-step work on a single machine; the Apache 2.0, MLX-accelerated, image-capable description points at Apple Silicon and at loops that need to look at a rendered frame. Both are vendor descriptions, so treat the first run as the measurement.
- Check the license, not the word "open." Apache 2.0 is a durable property of an artefact. "Free for a limited time" is not.
- Contain before granting repository access. On Microsoft’s reported result, a local git remote left requested operations working while reducing unprompted pushes by 11 points. That is the cheapest containment experiment in this record.
- Verify where execution landed. Model Explorer’s described hardware-delegation and per-node trace views are the right class of tool for confirming a local claim, though their coverage of these particular runtimes is unestablished.
The follow-up that has not been run
No test of these three models was performed for this article, and nothing above should be read as a measured result from this site. The experiment that would settle the open part is specific and still only proposed: install the two locally delivered candidates on one Apple Silicon workstation and one single-GPU NVIDIA box, run an identical multi-step agent task against a repository behind a local git remote with the network disabled, and record for each — resident memory at peak, wall-clock time to task completion, and the rate of unprompted write operations. Until those runs exist and are published with their environment, versions, sample size and failures, the parameter counts, the acceleration claims and the 11-point containment effect remain as they are described here: vendor and third-party reports, not results anyone outside those parties has reproduced.