Today's 5 most interesting new AI & ML papers, in one short listen.
Alex: Welcome back to AI Daily, your short digest of the most interesting new work in AI and machine learning.
Sam: Today we’ve got a nice spread: a harder benchmark for coding agents, a modular system for continual learning, a compact reasoning model that does well on ARC, a very large mixture-of-experts language model, and a self-developing coding agent that treats its own system as something to be improved over time.
Alex: First up, SWE-Bench ProMax, which is basically asking a sharper question than the usual coding benchmark.
Sam: Right. The core idea is that a lot of coding agents have gotten pretty good at narrow bug-fix tasks, especially when the change is small and local.
Alex: But real software work often looks more like refactoring a house while people are still living in it.
Sam: Exactly. You need to move pieces across multiple rooms without breaking the plumbing. Here that means coordinated, behavior-preserving edits across several files and, importantly, across seven languages: Python, Java, TypeScript, Go, C, C plus plus, and Rust.
Alex: And the benchmark is curated carefully, not just scraped and thrown together.
Sam: They use a three-stage pipeline. First they collect real refactoring commits from GitHub. Then they isolate each task in a Docker environment. Then comes the heavy manual work: removing weak tasks, checking the tests for flaws, and rewriting the issue descriptions so the task spec is precise enough that a correct patch is actually identifiable.
Alex: That last part matters a lot, because if the description is vague, you’re not really measuring coding skill so much as guesswork.
Sam: Exactly. And the scale is intentionally tougher than many older benchmarks. About thirty percent of the tasks require changing more than ten files, with an average of eleven point four files and around two hundred sixty-two lines of code per task.
Alex: So what happened when they ran agents on it?
Sam: The best model only solved about forty-one percent. And interestingly, giving the agent more interaction rounds didn’t reliably fix the failures.
Alex: Which suggests the bottleneck isn’t just persistence.
Sam: Right. The hard part is coordinating changes consistently across a codebase, not just editing one file well. They also found that open-weight models can get fairly close to proprietary frontier systems at much lower cost, which is useful because it means the benchmark is discriminating without being automatically dominated by the most expensive models.
Alex: So the practical takeaway is that if you want to know whether a coding agent can do real maintenance work, this is a more honest test than a single-file bug hunt.
Sam: Yes. It pushes the field toward the kind of work software engineers actually spend time on.
Alex: Next up is Macaron-V1, and this one is less about a single model and more about how to build a model that keeps improving after deployment.
Sam: The phrase they use is experiential intelligence, which is a fancy way of saying: can the system learn from what it actually encounters in the world, not just from a one-time training run?
Alex: So instead of freezing everything and hoping post-training covers all future use cases, they make the system modular.
Sam: That’s the key design choice. They keep a base model frozen, such as GLM or Qwen, and then put specialized LoRA adapters on top. LoRA is a lightweight way to add task-specific behavior without retraining the whole model.
Alex: And the “mixture” part means different specialists get picked depending on the turn?
Sam: Yes. A routing loop chooses the right adapter for the current user turn, so the same system can handle chat, coding, and generative UI without one monolithic model needing to absorb everything.
Alex: That sounds like a practical way to avoid constantly rebuilding the whole model when one capability needs a tune-up.
Sam: Exactly, and they extend that idea beyond the model itself. They treat the harness, meaning the tools, runtime, memory, and protocols around the model, as something to optimize too.
Alex: That’s interesting, because a lot of failures in agent systems come from the environment, not the weights.
Sam: Precisely. Their Harness Context Protocol is meant to make those runtime details portable and auditable. Then their MindForge loop uses task discovery and trajectory expansion to gather new experience, which can feed back into updating the specialist adapters.
Alex: So it’s a continual learning system, but with a lot of emphasis on governance and traceability.
Sam: Yes, and they also provide infrastructure pieces like MinT for managing adapter revisions and LongStraw for long-context execution. On benchmarks covering personal intelligence, generative UI, and general capabilities, the system validates the architecture, though the authors are careful not to overclaim that they’ve solved long-term continual learning yet.
Alex: The important part is the direction: smaller updates, clearer boundaries, and a system that can evolve without full retraining.
Sam: That could lower the barrier for teams that want to specialize an agent without owning the entire base model lifecycle.
Alex: The one I keep thinking about is BDH-CQ, because it tries to reason without talking itself through every step.
Sam: Right. It combines in-context learning with recurrent latent reasoning, which means the model updates an internal memory as it sees demonstrations, then iteratively computes a solution in hidden space rather than spelling out a chain of thought.
Alex: So instead of writing notes to itself, it’s more like silently rearranging an internal workspace.
Sam: That’s a good analogy. The model takes examples at inference time, updates a recurrent state, and then solves the query through repeated latent computation. The point is to see what it can infer from demonstrations and how consistently it can apply the transformation it has inferred.
Alex: They test it on ARC-AGI-1, which is all about pattern completion and abstract transformations.
Sam: Yes, and they also use ARC-like controlled interventions to probe what the model actually learns. That helps separate “it got the answer” from “it learned the right rule.”
Alex: And the result?
Sam: A one hundred fifty million parameter version reaches twenty-nine point five percent pass at two, at an estimated inference cost of seven ten-thousandths of a dollar per task.
Alex: That’s tiny.
Sam: It is, and the important part is that this lands beyond the previously reported cost-accuracy frontier for ARC-AGI-1. So it’s not just about accuracy in isolation; it’s about getting that accuracy at a much better operating point.
Alex: Why does that matter beyond the benchmark?
Sam: Because a lot of useful systems live under strict latency or cost constraints. If you can get decent reasoning behavior from a relatively small model with careful latent computation, that opens up practical deployment options.
Alex: It also suggests that “reasoning” doesn’t have to mean verbose explanation.
Sam: Exactly. Sometimes the interesting part is what the model can do internally, not what it can narrate.
Alex: Next is Motif 3, which is the largest system in today’s set and very much in the “scale plus engineering” category.
Sam: Yes. This is a decoder-only mixture-of-experts language model with three hundred fourteen billion total parameters, but only thirteen point two billion active per token.
Alex: So the model is huge, but each token only wakes up a small slice of it.
Sam: That’s the basic efficiency trick. Each sparse layer has three hundred eighty-four routed experts, and eight are selected per token. That gives a lot of capacity without paying full computation on every step.
Alex: And the architecture is doing a lot of work here.
Sam: It is. They build around Grouped Differential Latent Attention, which combines grouped differential attention with a compressed key-value representation. Then they add a few more pieces aimed at stability and specialization: modified manifold-constrained hyper-connections, Expert Specific PolyNorm activations, and multi-token prediction.
Alex: That’s a lot of machinery. What’s the practical reason for all of it?
Sam: Mostly to make a very large sparse model train stably and use its experts well. With mixture-of-experts systems, one recurring problem is that experts can collapse into generic behavior or training can become numerically fragile at scale.
Alex: So they’re trying to keep the model both efficient and disciplined.
Sam: Exactly. They pretrain on about twelve point five trillion tokens across web text, STEM, code, math, multilingual data, and domain corpora. They also use expert-balancing and numerical stabilization techniques, plus selective low-precision computation, memory-efficient kernels, and window-aware context parallelism so they can train with context lengths up to two hundred fifty-six thousand tokens.
Alex: That’s a serious engineering stack.
Sam: It is, and the post-training pipeline is equally layered: supervised fine-tuning, specialist teachers trained with reinforcement learning, a software-engineering teacher, and multi-teacher on-policy distillation.
Alex: So the final model is trying to unify reasoning, coding, tool use, professional tasks, long context, and calibrated abstention.
Sam: Yes, and on a broad evaluation suite it performs competitively with leading open-weight models, with especially strong results on long-horizon agent tasks, math, science, and hallucination-sensitive tests.
Alex: The main significance here is that the frontier on open models is increasingly about systems design, not just parameter count.
Sam: Exactly. It’s a reminder that the difference between a big model and a useful big model is often the training and routing discipline around it.
Alex: Last up is Ouroboros, which is probably the most philosophically interesting paper in the set.
Sam: It’s a self-developing coding agent where the harness, prompts, context assembly, and even core implementation improve through reviewed commits that later become the runtime for future work.
Alex: So the agent is not just using tools; it’s changing the tools it uses.
Sam: Right. They split that into two modes. In recursive free evolution, improving the system is itself a task, and finishing one improvement can trigger the next. In experience-driven core evolution, ordinary work and social interaction reveal bugs and inefficiencies, which then lead to reviewed structural changes.
Alex: That sounds powerful, but also risky.
Sam: The authors treat that as central. If a system can rewrite its own code and choose new model APIs, then safety can’t be an afterthought. Guardrails have to stay authoritative even when the system is under evolutionary pressure.
Alex: What do they show empirically?
Sam: On Terminal-Bench two point one, an Opus five run scores eighty-six point seven four percent, which they report as the best result on that benchmark. On OSWorld-Verified, they reach ninety point six nine percent, also above prior results. And on CL-Bench, a five-rollout campaign sets a new state of the art with a normalized reward of zero point two three zero one.
Alex: So the self-improving setup is not just a thought experiment.
Sam: No, and they also describe Hope, a one hundred sixty-one day public deployment where the agent continuously evolved under governed human communication across seven surfaces.
Alex: I like that they distinguish live evolution from benchmark runs.
Sam: That distinction matters. The benchmark campaigns use frozen snapshots, while Hope keeps evolving on a separate lineage. That makes the results more interpretable, because you can study performance without conflating it with ongoing mutation.
Alex: The broader lesson, I think, is that agent systems are starting to become software ecosystems, not single models.
Sam: Yes, and that raises a new question: how do you keep a system improving without losing control of what it is?
Alex: That’s a good place to end. If any of these papers caught your eye, tap it to add it to your library.
Sam: We’ll be back with more from the fast-moving parts of AI and machine learning.