Nachrichten

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.

This week, Meta Superintelligence Labs released Muse Spark 1.3. It is the fourth Muse Spark release in five months, and the target is long-horizon agentic and coding work rather than single-turn generation. The framing in Meta’s post is usability: sustaining a long thread, collaborating with the user, and knowing when it is stuck. Is it deployable? Yes, but with two limits. Muse Spark 1.3 ships today in Muse Code and the Meta Model API, so you can call it in production now. You cannot self-host it, because the weights are closed, and the max reasoning mode is still gated behind further safety testing. What actually changed for agents Meta trained Muse Spark 1.3 across multiple agent harnesses so behavior generalizes past one environment. The model is built to hold several workflows inside a single long thread. Given an open-ended objective, it gathers its own context from messy and conflicting sources, then patches gaps in its plan. The collaboration changes are the more practical part. Muse Spark 1.3 asks clarifying questions on ambiguous prompts, pulls the user in when it stalls, and confirms before consequential actions. On long runs it adapts to preference: frequent status updates, or silent background execution. Meta also reports better calibration on the model’s own limits, so it flags hurdles instead of hallucinating an outcome. Multitasking improved too. Meta says the model maps an incoming prompt to the correct task inside a cluttered single thread, whether the user is steering or interrupting. Coding and efficiency Muse Spark 1.3 was trained on more long-horizon coding tasks. Relative to Muse Spark 1.2, Meta describes fewer unnecessary turns, less verbosity, and a cleaner code style. In internal comparisons by Meta engineers, it used approximately 20% fewer tool calls and approximately 25% fewer tokens. For agentic workloads, that is the number that maps to cost: fewer round trips and fewer billed tokens per completed task. Benchmarks On Meta’s own numbers, Muse Spark 1.3 posts 75.4 on DeepSWE v1.1, ahead of Claude Opus 5 at 74.0 and GPT-5.6 Sol at 72.7. It reaches 59.4 on SWE-Atlas Codebase QnA and ties GPT-5.6 Sol at 88.8 on Terminal-Bench 2.1, with Opus 5 at 86.7. Long-context retrieval is the widest gap: MRCR v2 scores of 98.5 (256K–512K) and 98.1 (512K–1M), against 91.5 and 73.8 for GPT-5.6 Sol. The mode split matters on agentic rows. Meta reports OSWorld 2.0 at 66.9 for max versus 57.2 for xhigh, GDPval-AA v2 Elo at 1,754 versus 1,709, and JobBench at 64.9 versus 61.2. DeepSearchQA ties at 89.4 for both. Since Muse Spark 1.2 was evaluated at xhigh, part of the generational jump is a reasoning-tier change. Artificial Analysis scores the shipping xhigh variant at 61 on its Intelligence Index and the preview max variant at 62. That places xhigh level with GPT-5.6 Sol (max) and Grok 4.6 (high), behind Claude Opus 5 (max, 63) and Claude Fable 5.1 (max, 66). Artificial Analysis also measured Tau3-Bench Banking at 47% for xhigh and 52% for max, the top score it has recorded on that evaluation. Key Takeaways Muse Spark 1.3 is live in Muse Code and the Meta Model API, with a 1M-token context window. Meta engineers measured ~20% fewer tool calls and ~25% fewer tokens versus Muse Spark 1.2. Meta’s launch scorecard uses the max mode, which is not the mode developers can call today. Pricing is unchanged at $1.25/M input and $4.25/M output, with a $0.10/$0.20 contributor tier. Weights stay closed, though Meta lists a Muse Spark open weights release on its roadmap. Check out the full release post and the evaluation methodology report. 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 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 appeared first on MarkTechPost.