NVIDIA released a 64GB configuration of DGX Spark, its GB10 Grace Blackwell desktop system, available October 23 from Acer, ASUS, Dell, Gigabyte, HP and MSI.

• Up to 1 petaFLOP FP4 (with sparsity), 20-core Arm CPU
• 64GB coherent unified LPDDR5x, 273 GB/s memory bandwidth
• Fits 30–35B class open models: Qwen3.8-27B (~13.5GB at 4-bit), Muse Glimmer (~17GB quantized), Nemotron 3.5 Lightning (30B-A3B, NVFP4)
• 2 units over ConnectX-7: 128GB pooled, 546 GB/s combined
• NVIDIA says 2 × 64GB delivers up to 1.7x the performance of 1 × 128GB Spark
• NVIDIA Sync's Cluster Assistant configures up to 4 systems

Full breakdown: https://www.marktechpost.com/2026/10/02/nvidia-announces-dgx-spark-64gb-a-1-petaflop-grace-blackwell-desktop-for-local-ai-agents-fine-tuning-and-inference/

Product page: https://www.nvidia.com/en-us/products/workstations/dgx-spark/

Clustering with NVIDIA Sync: https://build.nvidia.com/spark/connect-to-your-spark/sync

Technical details: https://blogs.nvidia.com/blog/local-ai-dgx-spark-64gb-sync/

Datalab released an open benchmark for structured extraction: a system gets a PDF and a JSON schema, and every returned value is scored against gold data.

• Corpus: 620 docs. 329 from ExtractBench (LlamaIndex), 202 synthetic (Datalab), 47 from micro1, 42 from LongArray-Extract (Extend)
• Verdicts: each value is matched, misread, unfound, fabricated, invented_item or invented_field
• Row alignment: Hungarian matching by content. A 100-row table missing row 1 scores 0% by position, 99% this way (our rerun)
• Null rule: empty values are dropped, so padding a schema with 100 empty fields adds 0 verdicts
• Results: Datalab accurate 93.85, Datalab balanced 93.48, Reducto deep_extract 93.47, Claude Opus 5 90.96
• Precision vs recall: GPT 5.6-sol has 95.11 precision but 84.99 recall; LlamaExtract has 93.13 recall but 86.57 precision

Why it's relevant? precision vs recall shows how a system fails. Some skip fields, others invent values.

Full analysis: https://www.marktechpost.com/2026/10/02/datalab-introduces-omniextractbench-to-fix-bias-and-opacity-in-extraction-benchmarks/

GitHub: https://pxllnk.co/hxplrq

Blog: https://www.datalab.to/blog/omni-extract-bench

GitHub: https://github.com/datalab-to/omni_extract_bench

Dataset: https://huggingface.co/datasets/datalab-to/omni_extract_bench

AWS's Strands Agents team released Strands Decider 2B today. It's not a chat model. It never generates text. You give it a state plus typed questions, and it returns one of three things, each with a calibrated confidence:

• choice: pick 1 of N options
• noul: a yes/no probability
• score: a level on an ordered rubric

How it works

They take Qwen3.5-2B-Base, remove the language-modelling head, and replace it with a ~1M-parameter pointer head. That head scores each option's last-token hidden state against the hidden state at an <answer> position. One forward pass, no decoding loop, and it can only ever answer with an option you supplied. The torso gets a rank-16 LoRA. Because the head has no per-option weights, labels come from the request and there's no cap on option count.

Asking several questions about the same text is cheap: the state is read once and each extra question only adds its own tokens.

Numbers (v19 checkpoint, from the repo)

• JevBench v1 public set: 0.723 accuracy (167/231)
• Brier 0.342, ECE 0.052
• Tiers: easy 1.000 / standard 0.875 / hard 0.505
• RTX 3090: 115 ms median, 299 ms p95 per question
• M3 Pro: 153 ms warm median (under 300 tokens)
• On unseen short tasks, answers at 0.9+ confidence were right about 95% of the time

Context and caveats worth knowing

• This is the open, self-hostable counterpart to the class TypeSafe kicked off with Jev, which is a closed API.
• On the JevBench v1.4.2 board, v19 was 3rd of 33 in the 2B class. Mapika's decider-2b (same Qwen3.5-2B torso, different recipe) has a newer v11 that the Strands repo itself says scores 175/231, 8 tasks ahead.
• Long multi-step documents are the weak spot, and calibration was fitted on short classification tasks. The authors say to measure thresholds on your own traffic.
• The bundled HTTP server binds to localhost with no auth, so put something in front of it for anything real.

Intended uses: model routing, tool selection, tool-argument checking, triage, guardrails, cheap evals, and hybrid agents where the LLM handles hard calls and the decider handles rote ones.

Our full write-up with an interactive explainer: https://www.marktechpost.com/2026/10/01/aws-strands-labs-releases-strands-decider-2b/

Blog: https://strandsagents.com/blog/introducing-strands-decider/

GitHub: https://github.com/strands-labs/strands-decider

Weights (HF): https://huggingface.co/StrandsAgents/strands-decider-2B-hobson-v19

JevBench comparison in the repo: https://github.com/strands-labs/strands-decider/blob/main/evaluation/jevbench.md

Cloudflare released Clef and Clef-flash today, the first models trained by its Workers AI team. They are decision models in the same family as TypeSafe's Jev: you pass a state plus a schema of typed questions (noul, choice, score), and you get back a probability for every allowed option. No free-form text, no output parsing.

Architecture

• Clef is post-trained from Qwen3.8-27B, Clef-flash from Qwen3.5-9B. Both keep the vision encoder, so the state can include images and video.
• The frozen backbone runs a single prefill-only pass. A small transformer "joint schema head" then routes evidence to each question, lets fields cross-attend, and scores all options jointly. The decision step is non-autoregressive.
• Training: rank-256 LoRA adapters trained jointly with the routing head, label-smoothed cross-entropy plus a Brier loss for calibration, and RLCD as a secondary objective.

Numbers from Cloudflare's own Decision Index run

	Clef	Clef-flash	Jev
Median latency	209.3 ms	38.8 ms	524.1 ms
BANKING77 (macro-F1)	94.20	90.93	79.74
CLINC150+OOS (macro-F1)	97.43	66.77	89.27
GPQA Diamond	48.0	51.0	78.3
MMLU-Pro	65.9	65.3	82.7

So it wins clearly on classification and tool-routing style tasks, and loses clearly on knowledge-heavy reasoning. All numbers are vendor-reported with no independent replication yet.

Running it

• Hosted on Workers AI: $0.24 / M input tokens (Clef), $0.09 / M (Clef-flash), 65,536-token context.
• Weights on Hugging Face under Apache 2.0. The model cards say they tested on a single H200 in BF16 with a custom loader.
• The API follows TypeSafe's System One format, so Jev code ports by changing the endpoint and model name.

Model: https://huggingface.co/Cloudflare/clef

Clef-flash: https://huggingface.co/Cloudflare/clef-flash

Cloudflare blog: https://blog.cloudflare.com/clef-decision-models/

Our full write-up: https://www.marktechpost.com/2026/10/01/cloudflare-releases-clef-and-clef-flash/

Google Research released Regularized Recursive Self-Improvement (RRSI): an LLM agent that edits its own harness (prompts, tools, memory, control flow, sub-agents) while the model weights stay frozen. The regularization is what stops the usual failure mode, where a self-improving loop overfits the tasks it evolves on and collapses on anything held out.

Numbers, with Claude Opus 4.8 as the frozen policy unless noted:

• Terminal-Bench 2.1: 74.2% → 80.2%
• SWE-bench Verified (held-out): 82.0% → 83.8%
• JobBench +4.7, GDPval +3.5, APEX-Agents +3.7, EngDesign +4.9, Frontier-Eng +4.3 (points)
• Harvey LAB: +1.1 on the evolve split, +2.3 on the held-out split
• Gemini 3.5 Flash on Terminal-Bench 2.1: 64.6% → 78.7%
• Policy tokens per trial on the agentic workspace instance: 2.42M for RRSI vs 3.80M for unregularized evolution (about 30% fewer)

Why its important: this is harness engineering done by the agent instead of by you, and the gains transfer. All 6 held-out splits improved, and RRSI is the only method in the paper whose out-of-distribution average lands more than 1 point above the H0 baseline (39.7).

The catch: RRSI has the smallest gain on the evolve split of the methods compared. You trade peak in-distribution score for generalization, which is the right trade for production agents but worth knowing before you benchmark it.

Paper: https://arxiv.org/abs/2609.24972
GitHub: https://github.com/google-research/rrsi
Hugging Face: https://huggingface.co/papers/2609.24972
Project page: https://regularized-rsi.com/
Full breakdown: https://www.marktechpost.com/2026/09/29/google-research-open-sources-rrsi-ai-agents-that-improve-their-own-harness-without-overfitting/

Fireworks AI released Ember-1, a post-trained version of Kimi K3. The goal is shorter reasoning traces without losing accuracy.

The interesting part is the approach. Fireworks says turning down K3's reasoning effort gave up too much quality. So they trained the model to reason more efficiently instead, using on-policy learning with task and environment feedback. The training mix covers math, coding, search, tool use and software engineering.

Benchmarks vs Kimi K3 at max reasoning effort

Benchmark	N	K3 Max	Ember-1
Terminal Bench 2.1	89	80.9%	82.0%
DeepSWE 1.1	113	66.4%	75.2%
SWE-bench Verified	500	93.2%	92.2%
SWE-Interact	75	21.3%	20.0%
τ-2 Bench Airline	50	64%	66%

Production A/B test (customer coding workload)

Metric	Kimi K3	Ember-1
Score	0.751	0.753
Steps per task	23.8	21.4
Output tokens per task	49.3K	29.9K
Reasoning token reduction	n/a	71.3%
Total token reduction	n/a	39%

How is this important for agents

Every turn replays prior reasoning, so context grows roughly quadratically with the number of turns. Cutting reasoning early compounds across the whole trajectory.

Ember-1 is priced the same as K3 on Fireworks ($3 input / $0.30 cached / $15 output per 1M tokens). All the savings come from generating fewer tokens. Quick math on output cost alone, using the A/B numbers:

PRICE_OUT = 15 / 1_000_000   # $ per output token

k3     = 49_300 * PRICE_OUT  # $0.7395 per task
ember1 = 29_900 * PRICE_OUT  # $0.4485 per task

print(f"saved per task: ${k3 - ember1:.4f} ({1 - ember1 / k3:.1%})")
# saved per task: $0.2910 (39.4%)

Trying it

It is served through the OpenAI-compatible Fireworks API. Model path from the model page:

from openai import OpenAI

client = OpenAI(
    base_url="https://api.fireworks.ai/inference/v1",
    api_key="YOUR_FIREWORKS_API_KEY",
)

resp = client.chat.completions.create(
    model="accounts/fireworks/models/ember-1",
    messages=[{"role": "user", "content": "Find the bug in this function: ..."}],
)

print(resp.choices[0].message.content)
print(resp.usage)  # compare completion_tokens against kimi-k3

To A/B it yourself, run the same prompts with model="accounts/fireworks/models/kimi-k3" and compare usage.completion_tokens.

Open question

Can a model learn when to stop thinking on hard problems, or does training for shorter traces always cost some exploration? The SWE-bench Verified dip hints at that trade-off. Curious what people think.

Sources:

• Marktechpost's Analysis on Ember-1
• Fireworks announcement
• Ember-1 model page and pricing
• Kimi K3 weights (Hugging Face)

Black Forest Labs, the lab behind the FLUX image models, just moved into robotics. They released FLUX 3 Action, a 7B world action model. It predicts future video frames and the robot's next actions in the same forward pass.

Numbers from their report and the model card:

• RoboLab-120: 42.92%, first place. Cosmos3-Nano-Policy (16B) scores 36.8% and π0.5 (3.3B) scores 28.0%.
• Size: 56% fewer parameters than Cosmos 3 Nano.
• Speed: up to 3.95x faster than Cosmos 3 Nano in FP8 (1.52x to 3.95x depending on GPU).
• Planning: each call plans 32 actions at 15 Hz, which is 2.13 s of motion. π0.5 plans 1.0 s per call.
• Real robot: a blind third-party test on a Franka arm completed 28/30 attempts. Cosmos 3 Nano got 27/30, DreamZero 20/30 and π0.5 13/30.
• Pretraining: without video pretraining, DROID-only training stayed under 1% on RoboLab.

Running it:

• It needs about 32 GB in BF16, or fits 24 GB cards with FP8 and text encoder offload.
• There are 3 checkpoints: base, guidance-distilled, and a 1-step distilled version.
• It's natively in LeRobot, with an SO-101 LoRA recipe. Their docs show an SO-101 pick-and-place task learned from about 200 demos.
• NVIDIA helped with Jetson support.

Caveats, before someone else posts them:

• License: it's open weights under the FLUX Kommunity License, not Apache or MIT. Non-commercial use is free, and companies under $5M revenue can use outputs commercially. Everyone else needs a paid license.
• Speed vs π0.5: the 1-step model beats π0.5 on real-time factor on datacenter and workstation GPUs, but is slower than π0.5 on an RTX 5090.
• Hard tasks: some tasks (ordered block stacking, pumpkins in clutter) still fail without a reasoning model in the loop. Their hybrid with GPT 6 Astra reached 90% of episodes at $8.77 per success.

The part I find most interesting is that an image and video lab reached #1 on a robotics benchmark mostly through video pretraining. Is joint video and action prediction where robot policies are heading, or will VLAs catch up once they're scaled?

Full analysis: https://www.marktechpost.com/2026/09/24/black-forest-labs-releases-flux-3-action-a-7b-open-weights-world-action-model-that-tops-robolab-120/

Report: https://bfl.ai/models/flux-3-action

Weights: https://huggingface.co/collections/black-forest-labs/flux-3-action

TypeSafe AI released Jev, a model from an RLHF (reinforcement learning from human feedback) co-inventor that does not generate text.

You send it state and typed questions. It returns decisions with probabilities
your code can branch on, so there is nothing to parse.

- Founder Diogo Almeida co-invented RLHF at OpenAI
- $40M seed round led by DCVC
- 3 primitives: Choice, Score, Noul
- Every question in a request scored in parallel
- $0.042 per 1M input tokens, output tokens free
- 70ms to 500ms end to end, vendor reported
- 0.114s vs 8.566s in TypeSafe's own recorded demo
- Vercel: up to 18x faster than GPT Luna, p95
- Listed on Vercel AI Gateway as typesafe-ai/jev

Confidence is the product. Your code sets the threshold where automation stops
and a human takes over.

The 193.6x faster and 444.6x cheaper claims come from TypeSafe's own evals, not independent tests.

Read the full analysis: https://www.marktechpost.com/2026/09/19/typesafe-ai-releases-jev/

Technical details: https://typesafe.ai/blog/introducing-system-one-models-and-jev

Join the waitlist: https://typesafe.ai/

NVIDIA Open-Sources OSMO: One YAML Orchestrates Physical AI Training, Simulation, and Robot Testing

Here's how it works. 👇

1. One YAML, three computers
Robot pipelines span 3 compute tiers: training on GB200/H100, simulation on RTX PRO 6000, hardware-in-the-loop on Jetson AGX Thor. OSMO treats all 3 as backends of one control plane.
→ Tasks name a platform (gb200, rtx-pro-6000, jetson-agx-thor), never a cluster

2. Dependencies are data
The README example chains 3 tasks: Isaac Sim → PyTorch training with 8 GPUs → ROS eval on Jetson, writing results to a named dataset.
→ Placement from platform, ordering from inputs, persistence from outputs

3. Same file, laptop to cloud
Runs on KIND locally and on EKS, AKS, GKE, on-prem, or air-gapped clusters. Release 6.3.0 added a multi-provider deploy script with MinIO, Azure Blob, or S3 storage.
→ Zero code changes between environments

4. Built for production
   NVIDIA KAI Scheduler by default, NVLink topology-aware placement, per-group timeouts, RBAC sidecar, OAuth2 login, TLS at the gateway, cloud workload identity.
   → Powers Project GR00T, Isaac Lab, Isaac Sim, and Isaac ROS internally

Full analysis: https://www.marktechpost.com/2026/09/14/nvidia-open-sources-osmo-one-yaml-orchestrates-physical-ai-training-simulation-and-robot-testing/

Repo: https://github.com/NVIDIA/OSMO

A Princeton Researcher Proposes Recurrent Looped Transformer (RLT): a decoder that carries its full state across every prompt and response token, with 96 logical blocks per token and no reset at the boundary.

Here's how it works. 👇

1. One state, never reset
A causal encoder builds KV memory in parallel. A recurrent decoder merges each token's encoder feature with the previous final hidden state, then runs sliding-window attention, cross-attention to encoder memory, and an FFN. The state H_t = (s_t, C^D_t) crosses the serving split untouched.
→ Proposition 3.1: moving the prompt-response split does not change the conditional distribution

2. Fixed work, growing depth
Reference config ties 48 encoder and 48 decoder layers with shared attention and FFN weights.
→ 96 logical blocks per token, fixed
→ 48t decoder blocks on the state path after t tokens

3. RL replay under current parameters
The sampler records behavior log-probs. The trainer rebuilds encoder memory, recurrent output, and every SWA cache from H_0 before scoring each action.
→ Old rollout states are never reused; weight updates invalidate all caches

The key takeaway: a design spec that makes pretraining, SFT, sampling, and RL replay share one transition.

Full analysis: https://www.marktechpost.com/2026/09/13/a-princeton-researcher-proposes-recurrent-looped-transformer-rlt/

Paper: https://github.com/yifanzhang-pro/recurrent-looped-tranformer/blob/master/Recurrent_Looped_Transformer.pdf

Git Repo: https://github.com/yifanzhang-pro/recurrent-looped-tranformer

Amazing explanation in author's research blog: https://yifanzhang-pro.github.io/recurrent-looped-tranformer/

Sparse attention already cut long-context compute. The KV cache sitting in HBM and on SSD is now the bottleneck DeepSeek AI went after, and they cut theirs to 890 bytes per token.

They released DeepSeek-V4.1-Flash, a 552B MoE model with 1M-token context that activates only 8B parameters per token during prefill and 16B during decode. The global KV cache footprint is roughly 1/4 of DeepSeek-V4-Flash and about 437x smaller than DeepSeek-V1, and the weights are open under an MIT license.

Here's what's actually interesting:

→ Causal Encoder-Decoder: prompt tokens stop at layer 20, decoder global KV is projected from the encoder's final hidden state, prefill compute nearly halves

→ Compressed Sparse Attention 2: three statically assigned layer modes, Reindex reuses main KV and indexer K, Reuse also reuses Top-K indices

→ FP4 main KV cache via quantization-aware training, SWA Bounded Replay replays only 128 tokens instead of layers times window

→ Terminal-Bench 2.1: 90.6 vs 89.1 for Opus-5

→ DeepSWE v1.1: 74.2 vs 74.0 for Opus-5 and 73.0 for GPT-5.6 Sol

→ Terminal-Bench 4.0: 31.2 vs 51.8 for Opus-5, so the gap on expert-level science tasks is still real

Full analysis: https://www.marktechpost.com/2026/09/10/deepseek-ai-released-deepseek-v4-1-flash-with-1m-context-fp4-kv-cache-and-cross-layer-attention-reuse/

Technical Details: https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash

Paper: https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash/blob/main/DeepSeek_V41_Tech_Report.pdf

Google DeepMind Releases AlphaGenome Atlas: Precomputed Molecular Effect Predictions and AVI Scores for All 9 Billion Single-Letter DNA Changes in the Human Genome.

No lab assay. No per-variant model run. No coding required to query it.

Here is how it works:

1. Precompute instead of predict on demand AlphaGenome was run across every possible single-nucleotide variant in the human genome and the outputs were stored. Researchers now look up a variant instead of running a model on it.

→ 9 billion variants scored

→ 1 petabyte dataset, over 30x the size of the AlphaFold Database

2. One score for coding and non-coding DNA The AlphaGenome Variant Impact (AVI) score folds AlphaGenome's regulatory predictions together with AlphaMissense's protein-impact predictions into a single rankable number.

→ Works across the 2% coding genome and the 98% non-coding genome

→ DeepMind reports best-in-class results on variant pathogenicity and rare disease benchmarks

3. The score is decomposed, not opaque Each AVI score splits into additive feature attributions across categories like chromatin accessibility, splicing, and conservation, so you see which process a variant is predicted to disrupt.

→ Paired with a compendium of 2,500+ recurrent DNA motifs and their locations

4. Rare disease result At the Broad Institute, the AVI score reprioritized variants that earlier analyses had missed and surfaced one in DNM1, a gene linked to epileptic encephalopathy. The prediction: an incorrect splice site extending the protein.

→ Experimental screens validated it and found nearby variants with similar effects....

Full analysis: https://www.marktechpost.com/2026/09/08/google-deepmind-releases-alphagenome-atlas-with-precomputed-molecular-effect-predictions-and-avi-scores-for-9-billion-human-dna-variants/

Paper: https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/alphagenome-atlas-a-predictive-map-of-every-possible-dna-letter-change-in-the-human-genome/alphagenome-atlas.pdf

Technical details: https://deepmind.google/blog/alphagenome-atlas-a-predictive-map-of-every-possible-dna-letter-change-in-the-human-genome/

H Company Releases NeoMME: A Family of 260M and 800M Single-Tower Multimodal Encoders That Drop the Vision Tower and Causal Decoder

No SigLIP2 tower. No causal decoder. No VLM to repurpose.

Here's how it works. 👇

(1) Raw patches, not vision-tower features Images are split into non-overlapping 32×32 RGB patches and projected by a 2-layer MLP trained from scratch. Text enters through a 256-dimensional factorized embedding. Both then share every Transformer layer. → 16,384-token context, enough for two 3840×2160 4K UHD images

(2) Masked diffusion, not masked language modeling Pretraining is a discrete masked-diffusion text denoiser. Text-only segments draw a corruption rate from U(0,1). Multimodal segments draw from U(0.30,1), which kills the "guess it from the surrounding words" shortcut. → +38.4 points masked-token accuracy from visible page patches at 90% masking (260M)

(3) Trained from scratch on a small budget About 524B packed input tokens, roughly 290B of them text-only. ModernBERT saw around 2T text tokens. They used the NorMuon optimizer to squeeze more out of the smaller budget. → 16 H100s for the 260M run, 32 for the 800M

Full analysis: https://www.marktechpost.com/2026/09/06/h-company-releases-neomme-a-family-of-260m-and-800m-single-tower-multimodal-encoders-that-drop-the-vision-tower-and-causal-decoder/

Paper: https://arxiv.org/pdf/2609.01657

Technical details: https://huggingface.co/blog/Hcompany/neomme?

HF: https://huggingface.co/collections/Hcompany/neomme

Meta FAIR Releases AI Research Preference Models (RPMs): Frozen LLM Judges That Decide Which ML Experiment Gets the GPU, Lifting AIRS-Bench From 0.684 to 0.729.

No fine-tuning. No reward model. No new weights.

Here's how it works. 👇

(1) Ranking, not forecasting The team found language models unreliable at predicting absolute metrics or execution outcomes. So an RPM never guesses what a candidate will score. It only answers which of two unexecuted candidates is more promising.

(2) It plugs into one spot: child creation AIRA-dojo is an evolutionary tree search — greedy parent selection, Draft / Improve / Debug operators. Normally it generates one child and runs it. With an RPM, the operator fires 15 times in parallel, and a pairwise knockout tournament picks the single candidate worth executing. → 15 proposed, 1 executed per step → Each comparison is grounded in context nodes pulled by BFS from the tree, each shown with the validation score it earned

(3) Inference-only RPM A frozen LLM judging plans, code and search history. The prompt was optimized with MIPROv2, converging on a principal-investigator rubric that tolerates fixable bugs and penalizes redundant directions. → Offline selection accuracy 57.7% → 59.0% from prompt optimization alone → Accuracy climbs with context: 60.7% at zero context nodes, 65.0% at 100...

Full analysis: https://www.marktechpost.com/2026/09/06/meta-fair-introduces-ai-research-preference-models-rpms-ranking-ml-experiments-before-spending-gpu-hours/

Paper: https://arxiv.org/pdf/2608.13940

NVIDIA Releases Personal AI Router (PAIR): An Open Inference Router That Turns The RTX, DGX Spark And Mac Boxes You Already Own Into One Local AI Cluster.

No new cluster API. No agent harness changes. No prompts leaving your network.

Here's how it works. 👇

1. It routes, it doesn't execute
PAIR is not a new inference engine. Ollama or LM Studio still runs the model on whichever machine PAIR picks. It takes over the default port each engine uses, so the agent keeps talking to the endpoint it already knows.
→ Proxies Ollama-compatible, LM Studio-compatible and OpenAI-compatible endpoints
→ The agent decides what to request, PAIR decides where it runs

2. Discovery and trust
mDNS finds nearby machines automatically, or you add a node by IP. Trust is bootstrapped by a six-digit PIN shown on one machine and entered on the other.
→ All node-to-node traffic is blocked until pairing completes
→ Paired nodes then communicate over mTLS with generated certificates

3. The eligibility filter
A node only becomes a candidate once it can actually serve the request. The scheduler weighs five signals: is the node online and ready, is a supported engine enabled, is the exact model present, what is the current job load, what is GPU utilization.
→ Models don't need to be identical across nodes — PAIR routes by model location
→ Loading the same tag on more nodes just widens the eligible pool

Full analysis: https://www.marktechpost.com/2026/09/04/nvidia-releases-personal-ai-router-pair-an-open-source-virtual-inference-router-that-distributes-local-ai-requests-across-rtx-dgx-spark-and-mac-nodes/

Repo: https://github.com/NVIDIA/Personal-AI-Router

Technical details: https://www.nvidia.com/en-us/ai-on-rtx/personal-ai-router/

Meta AI Released Muse Spark 1.3: An Agentic Coding Model Doing the Same Work With ~20% Fewer Tool Calls and ~25% Fewer Tokens Than Muse Spark 1.2.

No price increase. No new harness. No open weights either.

Here's how it works. 👇

1. Fewer round trips, not just better answers

Meta trained 1.3 to take fewer turns where they aren't needed, with less verbosity and a cleaner coding style.

→ ~20% fewer tool calls and ~25% fewer tokens in Meta's internal engineer comparisons

2. It asks instead of guessing

On ambiguous prompts it asks a clarifying question. When it stalls it invokes you. Before consequential actions it confirms.

→ Better calibration on what counts as irreversible

3. One thread, several workflows

Given an open-ended objective, it generates its own context from messy and conflicting sources and patches gaps in its own plan.

→ Maps an incoming prompt to the right task inside a cluttered thread, whether you're steering or interrupting

4. The numbers (Meta's launch scorecard)

→ 75.4 on DeepSWE v1.1, ahead of Claude Opus 5 at 74.0 and GPT-5.6 Sol at 72.7

→ 88.8 on Terminal-Bench 2.1, tied with GPT-5.6 Sol

→ 59.4 on SWE-Atlas Codebase QnA

→ 98.5 and 98.1 on MRCR v2 long-context retrieval, inside a 1,048,576-token window

Full analysis: https://www.marktechpost.com/2026/09/03/meta-ai-released-muse-spark-1-3-an-agentic-coding-model-that-uses-20-fewer-tool-calls-and-25-fewer-tokens-than-muse-spark-1-2/

Technical details: https://research.meta.ai/blog/introducing-muse-spark-1-3

Most "runs locally on your Mac" stacks are a general-purpose runtime pointed at whatever model you downloaded. Perplexity just argued that the generality itself is the bottleneck.

They open sourced Lily — the local inference engine behind Hybrid Compute in Perplexity Computer. A Rust runtime with hand-written Metal kernels, built for exactly one model (Qwen3.6-35B-A3B) on exactly one chip family (Apple silicon). Neither PyTorch nor MLX is anywhere in the execution path.

Here's what's actually interesting:

→ 4,156 vs 3,388 prefill tokens/s and 170.0 vs 126.4 decode tokens/s against MLX-LM — mean across ten lengths from 256 to 128K tokens, batch 1, one 40-core / 128 GB M5 Max

→ Fusing 4-bit dequantization into the grouped GEMM, so the expanded weight array never touches unified memory: +77.4% prefill at a 512-token prompt

→ Keeping the whole routing sequence — histogram, prefix scan, scatter, block map — inside one GPU command buffer: +89% prefill at 512 tokens

→ GQA packing, so four query heads share one KV row load: +23.8% decode at 32K context

→ Fixed-block attention layout above 32K: +40.2% decode at 128K

Full analysis: https://www.marktechpost.com/2026/09/02/perplexity-open-sources-lily-a-rust-metal-inference-engine-for-qwen3-6-35b-a3b-on-apple-silicon/

GitHub: https://github.com/perplexityai/pplx-garden/tree/main/lily

Technical details: https://www.perplexity.ai/hub/blog/optimizing-on-device-inference-for-apple-silicon