Committee

Multi-agent workflows have changed the shape of local inference. A lead agent decomposes a task and spawns subagents. What looked like one user request becomes dozens of independent model calls. Pointed at a single local engine, those calls compete for the same execution slots. The queue grows while a workstation, laptop, or DGX Spark on the same network sits idle. NVIDIA Personal AI Router (PAIR) targets exactly that bottleneck. Announced this week, PAIR is a virtual inference router. It discovers compatible machines on a home network and schedules independent inference requests across them. It is not a new inference engine. Ollama or LM Studio still executes the model on whichever node PAIR selects. Is it deployable? Yes. PAIR ships today as a public beta (v0.1.1) with signed installers for Windows, macOS, and Linux, and the full source is on GitHub under Apache 2.0. It runs entirely on the local network, with internet needed only to download models. No new API The design decision that matters most is that PAIR introduces no cluster API. It proxies the Ollama-compatible and LM Studio-compatible interfaces agents already speak, taking over the default port each engine uses. If a harness listens elsewhere, the proxy port is configurable in PAIR’s engine settings. The repository also exposes OpenAI-compatible proxy endpoints. The consequence: existing agent harnesses need no changes. The agent decides what work to request. PAIR decides where it runs. Discovery, pairing, and transport PAIR uses mDNS to find nearby systems automatically. A node can be added by IP address when discovery fails. Trust is established by a six-digit PIN shown on the inviting machine and entered on the invited one. All node-to-node communication is blocked until that pairing completes. Traffic between paired nodes is then secured with mTLS using generated certificates. Each node runs Ollama or LM Studio. PAIR can install an engine and start model downloads on paired systems, removing most cross-machine setup work. How the scheduler picks a node A node becomes eligible for a request only when the required engine is enabled and the exact requested model is present. Models do not need to be identical across the cluster, different systems can hold different models, and PAIR routes according to model location. Loading the same tag on more nodes simply widens the eligible pool. For each 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 node and engine job load. What is existing GPU utilization. This is workload-level concurrency, and the boundary is explicit. PAIR assigns each request to one eligible node, where it stays for its lifetime. It does not pool VRAM, merge GPUs into one larger accelerator, or shard a single request across machines. The demo numbers, with their caveats NVIDIA’s demonstration pairs PAIR with Hermes Desktop, which creates a five-subagent workload over a synthetic household inbox. Ollama executes Qwen 3.6 35B A3B on each selected node. On one RTX Spark laptop, the workload took 18 minutes on average. On a three-device PAIR cluster consisting of an RTX Spark laptop, a DGX Spark, and an RTX 5090, it averaged 8 minutes and 48 seconds. Supported hardware and requirements PAIR supports GeForce RTX 20 Series GPUs and newer, RTX PRO workstation GPUs from Turing onward, DGX Spark, and Apple M4 or newer silicon. Windows, Linux, and macOS nodes can all be paired with each other, on x64 and arm64, though Windows on ARM is experimental. Validated configurations list 8 GB RAM or higher and a recommended 20 GB of disk. Other Linux distributions build from source. Key Takeaways PAIR routes each independent request to one node; it never pools VRAM or shards a model. It proxies existing Ollama and LM Studio endpoints, so agent harnesses need no changes. Eligibility depends on node readiness, enabled engine, exact model presence, job load, and GPU utilization. NVIDIA’s five-subagent demo went from 18 minutes on one laptop to 8:48 on three devices, unofficially. Apache 2.0 and beta: one scheduling policy today, blind to VRAM, GPU class, and model warmness. Check out the NVIDIA PAIR product page, NVIDIA Technical Blog, GitHub repository, Playbook and FAQ. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post NVIDIA Releases Personal AI Router (PAIR): An Open Source Virtual Inference Router that Distributes Local AI Requests Across RTX, DGX Spark, and Mac Nodes appeared first on MarkTechPost.

This week, Adaption Labs released Invent a Dataset. The feature generates a structured, training-ready dataset from a description of the behavior you want a model to learn. You do not arrive with a seed corpus, a predefined schema, or a labeling guide. Is it deployable? Yes, with one caveat. Invent a Dataset is live now in the Adaption app and through the Python SDK and REST API. Generated rows download as JSONL, JSON, CSV, or Parquet, so the artifact is a portable file you own and can train on anywhere. Generation itself runs on Adaption’s hosted platform and consumes credits. No self-hosted generation path is documented. The problem being targeted Most dataset workflows begin with data that already exists. Teams then spend weeks labeling, filtering, and reshaping it to approximate the target task. Adaption’s argument is that this caps model quality at how closely the available data matches the intended behavior. For proprietary and specialized tasks, the relevant signal usually sits in internal systems, unstructured text, or workflow logs. It rarely converts cleanly into a focused training set. The research team also draws a line against existing synthetic-data tooling. Those tools automate generation after a human has already defined the schema, task distribution, and generation strategy. Invent a Dataset starts one level earlier, at the behavior itself. How the API works The mechanics are documented and concrete. A single call to datasets.invent creates the dataset and starts generation, returning immediately with status running. You then poll datasets.get until the status reads succeeded or failed, and download the rows. Domain codes are the primary control. You fetch current codes with datasets.invent_domains rather than hardcoding them. You then pass values such as medical, optionally narrowed by qualified subdomain codes such as medical.symptoms_diagnosis. At least one domain or subdomain is required. Multiple domains contribute to the same run. A domain passed without subdomains draws from its full scope. Two output formats are supported. instruction_dataset is the default and produces prompt-completion pairs for supervised fine-tuning. preference_pairs produces chosen and rejected completions for preference-based training such as DPO. Three parameters matter for production use. estimate=True prices the exact request and returns estimated versus available credits without creating or charging anything. prompt accepts up to 10,000 characters to steer what the rows are actually about. idempotency_key accepts up to 255 characters and makes network retries safe by returning the original dataset instead of launching a second run. Row counts are subject to a per-launch limit set by your plan. Language and locale expansion language_expansion runs in two modes. translate produces a new row variant for each target language. localize produces a variant for each country and language pair, using locale-specific wording rather than direct translation. A sample_rate between 0.01 and 1 controls what fraction of invented rows gets expanded, and credits are billed on the expanded output row count, not the original. Unsupported codes return a 400 with a sample of valid values. The zero-data loop Invent a Dataset is the first half of a loop. The dataset ID passes directly to autoscientist.create, which co-optimizes the data and the training recipe against your objective. AutoScientist launched in May 2026 and is the training-side counterpart to the Adaptive Data pillar. Adaption reports that AutoScientist beats training configured by its own research staff, by an average of 35%. Win rates moved from 48% to 64%. Those figures come from in-house domain-specialized evaluations across eight verticals. Dataset sizes ranged from 5,000 to 100,000 rows, on architectures offered for fine-tuning by Together AI. Key Takeaways Invent a Dataset generates training rows from a task description, with no seed corpus, schema, or labels. One datasets.invent call sets domains, row count, format, and language expansion; generation is async. Output is instruction pairs or preference pairs, downloadable as JSONL, JSON, CSV, or Parquet. Dataset IDs feed straight into AutoScientist, closing an intent-to-trained-model loop. Check out the Technical details here. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Adaption Labs Introduces ‘Invent a Dataset’: Training Data Generated From a Task Description, Not a Seed Corpus appeared first on MarkTechPost.

Video has been the most expensive modality to reason over. A Gemini model handed a 90-minute lecture has, until now, ingested the whole thing at a fixed one frame per second, whether the question was ‘summarize this’ or ‘what time does the speaker switch to the pricing slide?’ That single-pass design forces a bad trade: pay for the full timeline in context, or pre-chunk the video and risk dropping the detail that mattered. This week, Google launched agentic video understanding across its Flash models. Instead of ingesting the timeline, Gemini navigates it deciding what to watch, at what frame rate, and through which modality. Google reports up to 88% fewer tokens, up to 66% lower cost, and up to 7% higher accuracy on standard video benchmarks. Is it deployable? Yes, but only as a hosted API feature. There are no open weights and nothing to self-host. It ships through the Gemini API in Google AI Studio and the Gemini Enterprise Agent Platform, works with both file uploads and public YouTube URLs, and bills at standard Gemini API token pricing with no additional feature fee. What actually changed Static processing, still the default on every Gemini model, extracts frames at 1 FPS in a single pass, processes audio at 1 Kbps single channel, and inserts timestamps every second. Agentic processing replaces that with a loop. The model pairs its own reasoning with native video tools to search, scan, and inspect target segments across frames, audio, and transcripts, loading only what the prompt requires. Developers could already assemble this by hand; the change is that Gemini runs the loop internally, which is where the development overhead disappears. Across Google’s evaluations, Gemini 3.7 Flash with agentic understanding lands on the accuracy-to-cost Pareto frontier for video analysis among the models tested. The efficiency gains concentrate on long-form content, from 10-minute how-to guides to multi-hour recordings. What the API returns Agentic processing adds two step types to the response steps array: a processing_call when the model requests a segment or transcript, and a matching processing_result when that load completes. They interleave with thought steps and precede model_output, so they can drive a live progress trace in your UI. Their presence is also how you verify agentic mode actually ran. Token accounting splits accordingly. Navigation reasoning bills as thought tokens (total_thought_tokens); frames, audio, and transcripts loaded on demand bill as tool-use tokens (total_tool_use_tokens). Enabling it is one field on the video part: Copy CodeCopiedUse a different Browser interaction = client.interactions.create( model=”gemini-3.7-flash”, input=[ { “type”: “video”, “uri”: “https://youtu.be/7Z5Vy9JBANs”, “processing”: “agentic” }, { “type”: “text”, “text”: “What are the 3 most important announcements in this keynote?”, }, ], ) You can also mix modes per video inside a single request, agentic on the long lecture, static on the short clip. Key Takeaways Agentic mode lets Gemini navigate a video timeline instead of ingesting it at a fixed 1 FPS. Google reports up to 88% fewer tokens, 66% lower cost, and 7% higher accuracy on video benchmarks. Supported on Gemini 3.8, 3.7, 3.6 Flash and 3.5 Flash-Lite; enabled by one processing field. Static remains better for clips under five minutes and for frame-by-frame precision work. Standard API pricing applies, but navigation reasoning is billed as thought tokens. Check out the Google blog, Gemini API video understanding docs, Developer guide in AI Studio and Agentic vision announcement. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Google Launches Agentic Video Understanding for Gemini Flash Models, Cutting Video Tokens by Up to 88% appeared first on MarkTechPost.

GitHub has released Project HydraFusion, a research preview that stops treating model choice as a one-time setting. Instead of routing your prompt to a single model, HydraFusion builds an execution plan per request. It can draft with one model, have a second model critique the draft, or escalate to a stronger model when a quality gate rejects the first attempt. Models come from multiple providers. The developer picks HydraFusion once, the same way they would pick any other model. Is it deployable? Yes, but narrowly. HydraFusion is live as a research preview for users on all GitHub Copilot plans, inside GitHub Copilot CLI only. There are no open weights and no self-hosted path. Run /update, then /experimental on, then /model and select HydraFusion (Research Preview). Billing is per token consumed by whichever models the workflow invokes, at each model’s standard rate. What the system actually does HydraFusion follows Auto model selection, which GitHub shipped earlier in 2026 to match a task to one best-suited model. HydraFusion goes a step further and treats workflow selection as an optimization problem. It reads capability signals for reasoning, code generation, debugging, and tool use. It then picks the least complex workflow expected to clear the quality bar, spending extra model calls only where they are likely to help. The three execution patterns For each request, HydraFusion currently selects one of three patterns: Single: One selected model solves the task directly. Cascade: An efficient model drafts a solution. A quality gate then either accepts it or escalates to a stronger model. Critique: One model drafts, an independent read-only critic from a different model family reviews it, and the drafting model revises once. The review follows the same pattern as Rubber Duck. Each pattern trades quality against cost differently. Single preserves speed. Cascade keeps a path to stronger inference open. Critique adds an outside perspective where review beats another unaided attempt. Engineering guardrails GitHub built the runtime around five operating principles that matter for repository-level work: Complete accounting across every leg, including drafting, critique, revision, escalation, retry, and fallback. Bounded execution with explicit timeout and cancellation per leg. Isolated review, where critics run in tool-less contexts and cannot modify the repository. Fail-safe application, applying no patch when a workflow is cancelled or fails validation. Validated routing, verifying model bindings, fallback behavior, and availability before execution starts. Internally the runtime logs role, outcome, cost, latency, and diagnostics per leg. Externally the developer sees one coherent response and one permission-aware change set. Benchmark results GitHub team evaluated fixed HydraFusion policies on three agentic coding benchmarks, using Claude Opus 5 and GPT-5.6 Sol as baselines. All models ran at medium reasoning level. The reported figures below are relative to Opus 5. Benchmark Estimated cost vs Opus 5 Verified task quality vs Opus 5 TerminalBench 2.1 67% lower +4.9 points DeepSWE 36% lower −1.5 points CheckpointBench 65% lower −0.1 points CheckpointBench is GitHub’s internal multi-turn set, curated from real Copilot sessions and anchored to immutable public commits so runs are replayable. Key Takeaways HydraFusion picks a workflow per request, not just a model, across multiple providers. Three patterns ship today: Single, Cascade with a quality gate, and Critique with a cross-family reviewer. Best result: +4.9 quality points at 67% lower estimated cost on TerminalBench 2.1. On DeepSWE and CheckpointBench it trails Opus 5 slightly while cutting cost 36% and 65%. Available now in Copilot CLI via /experimental, billed at each underlying model’s standard rate. Check out the GitHub Blog announcement, and GitHub Community discussion #206492. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post GitHub Introduces Project HydraFusion: Runtime Multi-Model Orchestration That Builds a Workflow Per Coding Task in Copilot CLI appeared first on MarkTechPost.

arXiv:2606.06350v2 Announce Type: replace Abstract: Reliable rubric grading requires more than accurate score prediction. Each judgement must be grounded in the mark scheme and evidence from the student answer. Existing credit-assignment and intervention methods, primarily designed for self-contained reasoning tasks such as mathematics reasoning, struggle in this setting because they do not identify where grading reasoning goes wrong or how the model’s belief about the final mark changes during reasoning. We propose Evidence-Diagnosed Intervention Training (EDIT), a two-phase framework for training more rubric-faithful LLM graders. First, EDIT-SFT locates problematic reasoning steps using internal model signals: posterior belief over the final mark and input-grounding scores. It then revises only these local steps with help from a rubric checklist. Second, EDIT-RL calibrates the grader with belief-guided reward shaping, penalising large harmful belief drifts while still allowing helpful exploration. Experiments on two real-world, multi-subject grading benchmarks demonstrate that EDIT consistently outperforms strong supervised fine-tuning and reinforcement learning baselines on both in-domain and out-of-domain splits, with ablation studies confirming that internal-state diagnostics drive these gains. Under deterministic rubric-edit interventions, EDIT-SFT is the most rule-responsive of all evaluated systems, and EDIT-RL largely retains this responsiveness while improving accuracy.

Battlefields in Ukraine are littered with the remnants of drones, which are now firmly established as a critical weapon of modern warfare. But behind all that wreckage, there’s a new gold mine for the defense sector. The data drones generate will far outlast the wars in which they are used to fight, increasingly becoming part of the AI architecture that shapes even civilian life.   For every flight, unmanned systems collect thousands of points of data, from images and video to controller inputs. Together, those records show how a machine and a person responded to constantly shifting circumstances.  Ukraine has now begun converting that experience into a resource. Its Ministry of Defense announced in January that it would make millions of data points gathered during tens of thousands of drone flights available to both military contractors and commercial companies, and since then more than 100 companies and the UK government have gained access. For a country at war, it’s a quick way to attract funding and partnerships. But this step turns the front line into an active site of model training, taking advantage of how the chaos of war creates conditions that AI companies struggle to reproduce on their own. Other countries and battlefields are likely to follow Ukraine’s lead, but the responsibility for governing this new industry cannot fall solely on a country fighting for its survival. That legal vacuum has to be filled together by the countries and companies involved in this industry’s development.   Explosive growth Ukraine’s battlefields are not the first to produce records used to train and develop models: American drones over Syria and Yemen collected data that informed the first generation of semiautonomous military hardware in the late 2010s. The difference now is that access to that data is being used to develop a wider ecosystem. And the financial value to defense firms is immense: Battlefield data offers large volumes of machine experience gathered under conditions that no laboratory can produce. That’s because the data that’s most valuable for training AI models comes from exceptions: the moment visibility disappears, a signal jams, or a human operator improvises. AI companies spend years and enormous sums trying to capture enough of these moments to make their models more robust. But war produces them at a frequency controlled testing cannot match. This constantly changing terrain is what makes drone data valuable far beyond the battlefield. A commercial drone used for delivery or remote sensing may never encounter artillery fire, but it must still operate with incomplete information in a world where people behave unpredictably. The same problem is compressed by war into a much shorter timeline.  Processed and matched against records of what its operator was doing, that data turns operational records into training sets. Combat becomes a commercial asset. Many conflicts have already seen this training loop happen as drone footage feeds subsequent generations of military technology, and the market is set to grow. Enabled Intelligence, an American company that specializes in processing data to become usable in AI training, says it has already made more than half a million hours of Ukrainian drone footage available to feed into the next round of models, advertising possible uses in both military and commercial systems. Closing the data loop Many of the drones that now define our modern age of warfare began as civilian technology. But they’ve recently been turbocharged by new, commercially available AI systems, which allow cheap machines to operate autonomously—either individually or as a flock—as the environment changes around them. Each flight then creates a record of what the system encountered. The resulting data is critical. The controlled lab environments usually developed to train these autonomous systems can approximate failure but are no match for  the live conditions of a battlefield with very real risks. Military intelligence programs have held data generated by sensor-heavy systems like Predator and Reaper drones for nearly a decade through programs like Project Maven, but access remained entirely within the defense world. The data generated was available only through restricted, classified channels for the sole purpose of developing new weapons systems that would feed back into the same military that produced the data in the first place. That experience is now being shared to a much broader development network.  The loop now closes. Commercial technologies adapted for the battlefield are generating data that can flow back into the industries from which they came, becoming part of the data infrastructure relied on by governments and the private sector alike.  Drones that were trained in the signal-jammed airspace over Ukraine are now being deployed in the agricultural sector to help farmers map and survey their fields in places lacking the cell signal necessary for previous generations of technology.  Other countries are likely to follow Ukraine in selling their battlefield data, and we are not ready for the new marketplace this will create. Bad actors could acquire the data, but purchase controls already mitigate that risk. Intelligence operatives scrutinize potential customers’ infrastructure for ways that data could reach enemies or nefarious actors.  Training data creates a new tracing problem, though. Whereas the movement of commercial datasets can be followed when planted contact details appear two steps from the original buyer, the provenance of AI training data vanishes in a manner embedded in the technology itself. Another risk is that this use of the data creates an extractive economy in which wealthier countries far from danger benefit from the mortal threat borne by frontline states, potentially creating a market incentive for war to continue as an unending mine for digital gold.  A fraught new frontier Existing laws regulate how militaries may conduct war. But they say almost nothing about what happens when records created in combat are stripped of their operational context, packaged as data, and licensed to companies whose products circulate far beyond where they were made. The responsibilities of the companies that design these systems remain unsettled. Ukraine is building access controls, which are mentioned in the newly signed UK-Ukraine AI agreement, but

Scalar defaults work the way you’d expect, and batch_size: int = 500 is all you need.