Trending ML Papers

What it is. JoyAI-VL-Interaction is an open-source AI assistant from JD.com that continuously watches a live video feed (a webcam, security camera, or livestream) and decides on its own, second by second, whether to speak up, stay silent, or hand the question off to a more powerful 'background brain' model. Unlike today's voice assistants that only react after you ask, it is designed to notice things in the moment — a fire on a security monitor, a fleeting expression on a video call, a product flashing by on a livestream — and respond proactively. The team is releasing an 8-billion-parameter model along with the full deployable system, training data, and recipe.

Where it fits. Most large language models and even 'real-time' voice models from the big labs are still organized around turn-taking: you talk, they respond. A growing line of work has been trying to break that loop by adding event-driven behavior — proactive vision models, streaming video understanding, and 'always-on' agents. Consumer products like ByteDance's Doubao and Google's Gemini have inched toward this by polling video every few seconds, but they remain fundamentally question-and-answer in design. JoyAI-VL-Interaction goes further by training the model itself to make the 'should I speak now?' decision, rather than relying on external triggers.

Why it matters. If this approach works as advertised, it could change what AI assistants are good for — from chatbots you query, to ambient observers that notice things as they happen. Use cases range from elderly-care monitoring to live shopping guidance, sports commentary, and security. In head-to-head human evaluations on six real-world streaming scenarios, raters preferred JoyAI over Doubao's video assistant 78% of the time and over Gemini's 88% of the time. The fact that it is fully open — weights, system, training recipe — also matters: it lowers the bar for anyone wanting to build a 'present in the world' assistant rather than another chatbot.

What it is. Moebius is a tiny image inpainting model — the kind of model that fills in or replaces parts of a photo, like erasing an unwanted person from a vacation shot or 'extending' a background. It has 220 million parameters, which is less than 2% the size of leading industrial models like Flux.1-Fill-Dev (about 12 billion parameters), yet matches or beats them on standard quality benchmarks while running more than 15 times faster end-to-end. The authors achieve this by redesigning the core building blocks of the diffusion architecture (the family of generative models behind most modern image tools) and pairing it with a 'student learns from teacher' training technique called knowledge distillation.

Where it fits. Image inpainting has been a flagship demo for diffusion models — the same generative approach that powers Stable Diffusion, Midjourney, and Adobe's Firefly. The dominant trend has been bigger is better: industry models like Flux and SD3.5-Large keep scaling up parameter counts to push quality. But that makes them too heavy and expensive to run on phones, in browsers, or inside creative apps at interactive speeds. A counter-current of research has been asking whether a much smaller, specialist model can match a giant generalist on one specific job. Moebius is a strong data point for that thesis.

Why it matters. Inpainting is one of the most-used features in consumer photo apps — 'magic eraser', generative fill, background extension. Moebius's 15x speed-up and 50x parameter shrink would make high-quality versions of these features cheap enough to run on-device, with lower latency and without cloud round-trips. That has real product implications: better mobile photo apps, image editing inside lightweight tools, and lower inference bills for any service offering inpainting at scale. The catch is that this is a specialist trained for inpainting specifically — it does not replace big generalist models for arbitrary image generation tasks.

What it is. LoopCoder-v2 is a 7-billion-parameter coding model that explores a clever architectural trick: instead of stacking more layers to make a model 'think harder,' it reuses the same block multiple times in a loop, giving the model extra computation without extra parameters. The team trained four versions of the model from scratch — looping once, twice, three times, and four times — on 18 trillion tokens of text and code. Surprisingly, two loops is the sweet spot: it dramatically boosts performance on real software engineering tasks (the SWE-bench Verified score jumps from 43.0% to 64.4%), but a third loop actively hurts performance.

Where it fits. There is intense interest in 'test-time compute scaling' — letting a model do more thinking at inference time rather than at training time, the way OpenAI's o1 and DeepSeek's R1 spend extra tokens reasoning. Looped or 'recurrent depth' transformers are a different bet on the same idea: rather than generating long chains of thought, do extra hidden computation by re-passing through the same parameters. Previous work has shown this can rival deeper models, but no one had a clear theory for how many loops to use. LoopCoder-v2 offers both a large empirical study and a principled explanation.

Why it matters. Software-engineering agents are now one of the biggest commercial use cases for LLMs — Cursor, Devin, GitHub Copilot, and the like. A 64% score on SWE-bench Verified at only 7 billion parameters is competitive with much larger frontier models, which would shift the cost structure for any company running coding agents. The broader takeaway is also interesting: 'more compute is always better' may not hold for these looping architectures, and the paper offers diagnostics to figure out where the sweet spot is for a given model. The caveat is that the gain-cost analysis is specific to one architectural variant (parallel loops), and the right loop count may vary for other tasks beyond coding.

What it is. Data2Story is an AI system from Oxford and Stanford that tries to do the job of a data journalist end-to-end: take a raw dataset and produce a finished, interactive news feature — with charts, narrative, and even audio or maps — that a general reader can follow. It is a multi-agent setup, meaning several specialized AI roles (analyst, designer, narrator, fact-checker) work together like a small newsroom. A key piece is the 'Inspector,' an automated fact-checker that links every claim and chart in the finished story back to the underlying data, code, or external source, so readers (or editors) can audit it.

Where it fits. There has been an explosion of 'agent' systems where multiple LLM-powered roles collaborate on complex tasks — coding agents like Devin, research agents like OpenAI Deep Research, and design agents that build websites from prompts. Most have focused on a single discipline. Data journalism is an interesting stress test because it combines several hard skills: statistical analysis, editorial judgment, visual design, and verifiability. The Data2Story team also pushes hard on a problem most agent papers skirt — every output has to be traceable to evidence, not just plausible-sounding text.

Why it matters. If agents can credibly produce verifiable, multimodal journalism, the same architecture could power analyst reports, internal dashboards, marketing case studies, or sales briefings — anywhere people turn data into narrative. In a human study with 53 participants comparing Data2Story output to expert-written pieces from real news outlets, the AI was particularly strong on transparency and data-claim alignment, but human writers still won on editorial angle, creativity, and visual polish. The authors explicitly frame this as a tool for journalists rather than a replacement, and the verifiability framing is timely as media organizations weigh how much AI-generated content they can stand behind.

What it is. OmniDirector lets you 'clone' the camera moves from a reference video — say, a swooping drone shot, an inverted perspective, or a sequence of different cuts in a film — and apply them to a brand new scene of your choosing. It is built by the team behind Kling, Kuaishou's video generation model. The clever idea is the 'camera grid': instead of describing camera motion with abstract numbers (rotation matrices, coordinates) or words, the system represents the camera as a video of itself moving through an empty 3D scene. That visual representation is easier for video models to learn from, and it works across multi-shot sequences, not just single takes.

Where it fits. Video generation is one of the hottest battlegrounds in generative AI, with Kling, OpenAI's Sora, Runway, Google Veo, and others trading punches every few months. Once basic quality plateaus, the next frontier is creative control: getting the model to do exactly the shot you want. Existing approaches either let you type a description ('drone shot pulling back') or feed it explicit camera parameters — both have well-known limits. Reference-based camera cloning is more intuitive, but earlier methods needed paired training data (the same scene shot with different cameras), which is extremely scarce. OmniDirector's grid trick sidesteps that constraint.

Why it matters. Cinematic camera control is one of the missing pieces between AI video being a novelty and being a real tool for filmmakers, advertisers, and game studios. By making multi-shot, director-level camera control work without expensive paired data, this lowers a real barrier — you can grab an existing reference clip and 'redirect' a new scene with the same camera language. Whether this holds up against the next generation of integrated video models (which may bake camera control into their training pipelines) is the open question, but for now it points at a more controllable, more director-friendly future for AI video.