Intelligence with Everyone: RL @ MiniMax, with Olive Song, from AIE NYC & Inference by Turing Post

Hello and welcome back to the Cognitive Revolution. The presenting sponsor of today's episode is Granola, the AI Notepad that helps you get the doing done. Whether it's identifying to-do items after a call, turning a brainstorming session into a product spec, or looking back at multiple calls to identify cultural trends at your company, Granola takes your raw meeting notes and makes them awesome. Right now, Granola is featuring AI recipes from AI thought leaders, including several past guests of this show. My own contribution is a blind spot finder recipe that looks back at recent conversations and attempts to identify things that I am totally missing. This was immediately useful in the context of contingency planning for my son's cancer treatment. And the more data Granola collects, as I continue to use it, the more valuable it becomes for suggesting AI topic areas that I really ought to explore. See the link in our show notes to try my blind spot finder recipe and experience for yourself how Granola puts your meetings to work. Now today I'm excited to share a special combined crossover episode featuring Olive Song, a senior researcher specializing in reinforcement learning and model evaluation at the Chinese AI company MiniMax, creators of the M series of models, the most recent of which, M2.5, currently tops the OpenRouter usage leaderboard.

To give you the most complete picture possible, we're combining two sources. First, a presentation Olive recently gave at the AI Engineer conference in New York, where she had previously lived for 6 years. Second, an interview with Ksenia from her podcast, Inference by Turing Post.

Together, they provide an excellent overview of MiniMax's goals as a company, the capabilities they're prioritizing in their models, the techniques they're using to get there, and the day-to-day ups and downs of training frontier LLMs.

Highlights include how MiniMax's strategy of building both models and user-facing applications in-house creates tight feedback loops that enable their cross-functional research and engineering teams to identify and address model weaknesses as quickly as possible.

You'll hear an overview of how interleaved thinking, which allows the model to take an action, get feedback from the environment, and pause to think again before continuing, improves performance on long-horizon agentic tasks. Olive also describes the perturbation pipeline they use to systematically vary the model's training environment in order to encourage robust generalization.

She offers her perspective on the constant battle she and her teammates are fighting against reward hacking, as well as a window into the tedious debugging that is sometimes required to diagnose training issues and how they realized they needed to run reinforcement learning at FP32 precision. Finally, she explains how the team at MiniMax is using AI agents to keep up with the daily flood of AI news.

While Olive recognizes that MiniMax's models, like all open-source models in the world today, can't quite match the performance of top American models, I think there is still a lot of value in the details she shares about their approach to reinforcement learning and how they structure their team and work.

In any case, I always appreciate the opportunity to hear directly from Chinese AI researchers who, just like their American counterparts, are figuring things out step by step as they go, even as major questions about issues such as the governance of increasingly powerful open-source models remain fundamentally unanswered.

With that, I want to thank Swyx, the creator of the AI Engineer event series, which I absolutely recommend attending if you can, and Ksenia, the creator of Turing Post, which has what I find to be some of the very best topic selection of any AI newsletter, for allowing me to create and post this combined episode. I hope you enjoy this window into the development of some of the best open-weight models in the world with Olive Song of MiniMax.

Hi, everyone. I'm Olive. It's my great honor to present on our new model, MiniMax M2. I actually lived in New York City for 6 years, so it feels great to come back, but with a different role. I currently study reinforcement learning and model evaluation at MiniMax.

Let me get a quick sense of the room. Who here has heard of or tried MiniMax before? A couple of you. Not everybody, but I guess that's the value of me standing here today.

We are a global company that works on both foundation models and applications. We develop multimodal models, including text, vision-language models, our video-generation model Hailuo, and speech-generation and music-generation models. We also have many applications, including agents, in-house.

That's the specific thing that's different from other labs and companies: We both develop foundation models and applications. We have researchers and developers sitting side by side, working on things.

Our difference is that we have firsthand experience from our in-house developers when developing models that developers in the community would really need.

Here I want to introduce our MiniMax M2, which is an open-weight model with only 10 billion active parameters that was designed specifically for coding and workplace agentic tasks. It's very cost-efficient.

Let me go over the benchmark performance, because people care about it. We rank very highly in both intelligence benchmarks and agent benchmarks. I think we're at the top of the open-source models.

But numbers don't tell everything, because sometimes you get those super-high-number models, plug them into your environment, and they suck, right? So we really care about the dynamics in the community. In our first week, we had the most downloads, and we also climbed into the top 3 in token usage on OpenRouter.

We're very glad that people in the community are really loving our model in their development cycle. Today, I want to share how we actually shaped the model characteristics that made M2 so good in your coding experience.

I'm going to present the training behind it that supports each of those characteristics: coding experience, long-horizon state-tracking tasks, robust generalization to different scaffolds, and multi-agent scalability.

First, let's talk about coding experience, which we supported with scaled environments and scaled experts. Developers need a model that can actually work in the languages they use and across the workflows they deal with every day.

That means we need to utilize real data from the internet and then scale the number of environments so that, during training—for example, during reinforcement learning—the model can actually react to the environment, target verifiable coding goals, and learn from them.

That's why we scaled both the number of environments and our infrastructure, so that we can perform this training very efficiently. With data construction and reinforcement learning, we were able to train the model so that it's very strong, full-stack, and multilingual.

What I want to mention here is that, besides scaling environments, which everybody talks about, we actually scale something called expert developers as reward models. As I mentioned before, we have a ton of expert developers in-house who can give us feedback on our model's performance.

They participated closely in the model-development and training cycle, including problem definition, bug fixing, repository refactoring, and things like that. They also identify the model behaviors that developers enjoy, determine what's reliable and what developers would trust, and give precise rewards and evaluations for the model's behaviors and final deliverables.

That way, we have a model that developers really want to work with and that can add efficiency for developers. With that, we were able to lead in many languages in real-world use.

The second characteristic that MiniMax M2 has is that it performs well on long-horizon tasks—tasks that require interacting with complex environments, using multiple tools, and reasoning. We supported that with the interleaved-thinking pattern and reinforcement learning.

What is interleaved thinking? With a normal reasoning model that can use tools, it normally works like this: You have the tool information given to it, the system prompt, and the user prompt. Then the model thinks and calls tools. It can call a couple of tools at the same time. After that, it gets the tool response from the environment, performs a final round of thinking, and delivers the final content.

But here's the truth: In the real world, environments are often noisy and dynamic. You can't really perform a task just once. You can get tool errors, unexpected results from the environment, and things like that.

What we did is imagine how humans interact with the world. We look at something, get feedback, think about it, decide whether the feedback is good, and then take other actions and make other decisions. That's why we did the same thing with our M2 model.

If we look at the diagram on the right, instead of just stopping after 1 round of tool calling, the model actually thinks again and reacts to the environment to see whether the information is enough for it to get what it wants.

Basically, we call this interleaved thinking because it interleaves thinking with tool calling. It can do this a couple of times—it can be tens to 100 turns of tool calling within just 1 user interaction—so it helps with adaptation to environmental noise.

As I mentioned, the environment isn't stable all the time. Something may be suboptimal, and the model can choose to use other tools or make other decisions. It can focus on long-horizon tasks and automate your workflow using, for example, Gmail, Notion, and the terminal, all at the same time.

You just need to make one model call with minimal human intervention. It can do it all by itself. Here's a cool illustration on the right, because it's New York City. I feel the vibe of trading and marketing.

There were some perturbations in the stock market, I think, last week, and our model was able to keep it stable. Just like I said, there's environment noise, there's no new information, there's news, and there are other trading policies and stuff like that, but our model was able to perform pretty stably in these kinds of environments.

The third characteristic is our robust generalization to many agent scaffolds, which was supported by our perturbations in the data pipeline. We want our agent to generalize, but what is agent generalization? At first, we thought it was just tool scaling. We train the model with enough tools—various tools, including new tools we invent—and then it will just perform well on unseen tools. That was kind of the truth. It worked at first.

But then we soon realized that if we perturb the environment a little bit—for example, if we change another agent scaffold—it doesn't generalize. So what is agent generalization? We concluded that it's adaptation to perturbations across the model's entire operational space. If we think back to what the model's operational space is, as we talked about, it can be tool information, system prompts, or user prompts. They can all be different. They can be the chat template, the environment, or the tool response.

What we did was design and maintain perturbation pipelines for our data so that our model can actually generalize to a lot of agent scaffolds. The fourth characteristic that I want to mention is multi-agent scalability, which is very possible with M2 because it's very small and cost-effective.

I have a couple of videos here. This is M2 powered by our own MiniMax Agent app. We can see different copies of M2. It can do research, write the research results, analyze them, and put them in a report. It can put them in some kind of front-end illustration, and they can work in parallel. Because it is so small and cost-effective, it can really support those long-running agentic tasks and tasks that may require some kind of parallelism.

So what's next for MiniMax M2? From what I've introduced, we gathered environments, algorithms, data, expert values, model architecture, inference, evaluation—all this stuff—to build a model that was fast, intelligent, could use tools, and generalized. What's next for M2.1 and M3 in the future? We think of better coding, maybe memory, context management, proactive AI for the workplace, and vertical experts. Because we have those great audio-generation and video-generation models, maybe we can integrate them.

Our mission is that we're committed to bringing all these resources—whatever is on the screen and maybe more—and our values together to develop models for the community to use. So we really need feedback from the community if possible because we want to build this together and this is kind of a race that everyone needs to participate in. We are committed to sharing it with the community. And that's all the insights for today. We really hope you try the model because it's pretty good. You can contact us up there. You can try the models by scanning the QR code. Basically, that's it. Thank you all for listening.

During reinforcement learning, the model tries its best to hack a lot of things. The current open models can achieve that level of understanding. It is a solvable problem, and we are working on it. Engineering is very, very, very important. I didn't know that during school.

Hey, we'll continue our interview in a moment after a word from our sponsors. The worst thing about automation is how often it breaks. You build a structured workflow, carefully map every field from step to step, and it works in testing, but when real data hits or something unexpected happens, the whole thing fails. What started as a timesaver is now a fire you have to put out. Tasklet is different. It's an AI agent that runs 24/7. Just describe what you want in plain English. Send a daily briefing, triage support emails, or update your CRM. And whatever it is, Tasklet figures out how to make it happen. Tasklet connects to more than 3,000 business tools out of the box, plus any API or MCP server. It can even use a computer to handle anything that can't be done programmatically. Unlike Chat GPT, Tasklet actually does the work for you. And unlike traditional automation software, it just works. No flowcharts, no tedious setup, no knowledge silos where only one person understands how it works. Listen to my full interview with Tasklet founder and CEO Andrew Lee. Try Tasklet for free at tasklit.ai and use code cogrev to get 50% off your first month of any paid plan. That's code cogrev at tasklit.ai. Hello, everyone. Today I have the pleasure of talking to Olive Song, a senior researcher at MiniMax. Recently, they've been launching very interesting open-weight models specialized in different areas. Olive is currently working on MiniMax's new version, MiniMax 2.2. Thank you for taking the time at 9:00 p.m. on Sunday night. Does everyone work like this at the company? I'm really impressed.

I think different people work on different schedules. We do have people who work overnight, but they sleep during the daytime. I feel like we have a very flexible schedule. It goes with your experiments. For example, if the experiments run all day, the person can take a break. If there are a lot of analyses to do, maybe because we're very curious about the results and we're very passionate, we can't really wait a very long time. So, yeah, everyone has their own schedule.

That's telling of the success of the models. I think that's influenced by the fact that you specialize in reinforcement learning and model evaluation, as far as I understand, which are two of the least forgiving parts of model development. You also have more constraints than the big American AI labs. What does a good day look like for you, and what does a bad one look like?

I can share something about our recent weeks. There isn't a whole good day or a whole bad day. We were joking that during one day, we have good results in the morning, and then sometimes they become bad results at night. Sometimes we call it—we have ICU in the morning and KTV at night.

Typically, a good time would be receiving some good results. Even if we run into new problems, that's a good time. For example, during reinforcement learning, we can see the model doing a lot of different things to achieve the results, and sometimes we discover new model behaviors. That's really exciting. Even though it might not be safe or expected, it's kind of exciting, so I call it a good time.

A bad time would be—there really isn't a bad time, except for finding out the bad results. The moment itself is bad, but then trying to figure out the problem and breaking it down is a pretty good time.

What were the recent model behaviors that you didn't expect?

During reinforcement learning, the model tries its best to hack a lot of things. For example, it uses Bash a lot, and sometimes it might not exhibit very safe behaviors, as our expert developers say. Sometimes the expert developers have their own expectations for how the model works, but then it doesn't go that way if we don't constrain it. So we do a lot of alignment to solve that issue.

You just launched MiniMax Hailuo, and that went all over Twitter. How do you come up with those ideas? Role-playing is sort of like—is it an alignment question?

Frankly speaking, I'm not the expert person on that part. We have a whole team working on role-playing and that sort of thing. I'm not an expert, but we do have a lot of discussions.

We do believe that role-playing, or accompanying humans and human interactions, is very important in life with AI and in how it will change our social life in the future. It absolutely represents an ability that's very superior because it's human-like. It has emotions, and it understands your emotions. It's not just working out some exams; that's absolutely another side of AI capability.

What is “Intelligence with Everyone,” right, in MiniMax?

Yeah, it's “Intelligence with Everyone.”

“Intelligence with Everyone.” What does it mean for you?

For me personally, I feel like it's more about how it changes my life, enables me to do more work, and helps me connect better with different people. For example, before, I wouldn't have been able to understand a lot of very professional coding problems or optimization problems. Now I'm able to do that with AI, so I can communicate with more people and exchange more ideas.

That's one side. On the other side, it generally helps my daily life. It helps with my work, my daily routine, and my self-care. It changes life for me, and I hope that it changes life for everybody, obviously in a good way.

Can you tell me a little bit about how day-to-day work is organized in your lab? I remember from your talk at AI Engineer that it's very interconnected between developers and researchers.

I would love to hear more about that.

Absolutely. We sit around every day and share our experiment results. For example, during reinforcement learning experiments, we see some scores going up. We look at the model's behavior with the developers in that area as well. We sit together, and they spot the issue right away, so we're able to come up with new ideas to fix it or build more data on it.

If we can go into details about your current work on the current model, on the current version, what are the biggest problems you're trying to solve compared to the previous version?

One important thing that we focus on right now, and also in the future, is human alignment, because we are focusing on coding models for M2.1, M2.2, and the M2 series. What we realize is that, for it to become very productive in our daily work—or for it to be productive and safe at the same time—we have to do a lot of alignment on it. The model can't just grow on its own and then exhibit dangerous behaviors just to achieve the final goal. For us, the important thing is how we define human alignment, how we define expert expectations, and how we actually train the model to be more aligned with our expectations.

I want to go into some real detail here. You're an expert, so correct me if I'm wrong, but I saw that there was a recent interest in details like keeping the LM head in FP32 during reinforcement learning training. Why do small decisions like this end up mattering more than just a clever new algorithm?

It all ends up being about getting closer to the theoretical algorithm. We have the theoretical reinforcement learning algorithm, but when we implement it, it could be a little bit off. That creates a little gap from the theoretical extreme of the algorithm. That's how we think about and approach this problem: we try to scale to the theoretical extreme. For example, the precision part is one thing that we found could prevent us from being close to that extreme, and that's how we solved it.

That was actually a very funny story when we discovered it. I talked about it when we published MiniMax M1. During our experiments, we found that the accuracy didn't go up. We looked layer by layer, looked at the log probabilities layer by layer, and found that, theoretically speaking, it had to work. There had to be some gap between the theoretical algorithm and how we approached it. So we thought about the gap, analyzed it layer by layer, and eventually found it.

Is there anything like this happening now?

Definitely. Every single day, in every different group. I can't actually disclose something for which we haven't reached a concrete conclusion, because we want our conclusions about anything public to be very concrete, and we want to understand them very deeply. If we have breakthroughs, we'll definitely publish them later.

But I have to say, we do encounter these problems every day, and we think from first principles. We think about the fundamental part of the problem and then approach it.

The models that you launch are open weights. From your perspective, and from the alignment perspective, what do builders actually gain from open weights, and what responsibility do they have to take on? You don't have to take responsibility for this.

Again, I'm actually not an expert in building or developing things with models. I feel like, because it's open weight, people can use it freely. For example, they can deploy it themselves, or they can fine-tune it with the weights and have all their data on their own properties, where it's very safe.

But if we talk about alignment, how do you look at that from that perspective? When the model is out there in the wild, before you launch the model, before you publish it, what tells you that it's safe to publish?

We have some internal benchmarks in terms of safety, and they have different dimensions. We have sensitive safety and alignment safety as part of our evaluation. Then, about 1 or 2 weeks before launching, we do scaled-up evaluations and scaled-up alignment on the model. That's how we assess whether the model is safe.

But if it's already open weight and in the wild, people can do things with it. I guess that's what you're getting at, right? People can do more things with the model that we can't control. I don't know how we handle that, frankly speaking. There are laws around that, right? There are regulations where people agree on some moral standards.

Do you follow any reinforcement learning failure modes that haven't shown up in benchmarks but then become obvious in agentic use? How do you collect feedback for the next versions to improve the reinforcement learning process?

We collect feedback on the model itself first. When we publish a model, many developers and many other people use it. We collect feedback systematically and analyze each problem. Some of them are fundamental; some of them are just things that we missed and can fix very quickly.

So there are 2 parts. First, we do the internal evaluation with the developers, and they point out problems. That's how we can fix that part, but it's not enough. More feedback comes to us after we officially publish the models, and then we collect it.

The way we organize our group is that different people work on different capabilities of a general model. If we collect something that we think we should improve in the future, different people take responsibility for their parts. They're like, “Okay, I think I can solve this issue, and I'll solve it in the next generation.” That's how we collect feedback and improve the model.

How did you initially decide not to build one general-use model with everything for everyone, and instead move more toward specialization, like coding?

I think we're approaching generalized models. It's just that we're putting more emphasis on coding. For example, our model can also be taken into any general agent scaffold, including our own agent product, and that's for general-purpose use. We work on researching, report writing, PPT stuff, and things like that. That's more general.

Personally speaking, I feel like with coding, you can structure the whole world, or you can model a lot of things with—

Engineer it.

Yeah, with engineering. Behind it, it scales up humanity for me. It itself has a lot of intelligence and a lot of work to do. That's how we view this issue. But we do work on generalized stuff, and even more generalized stuff in later versions. For example, our model can handle some general workplace scenarios in the future, and that's not just coding, right?

If we talk about coding and using it, it requires a long horizon. How do you solve long-horizon problems for agentic use?

I think defining your goals well and defining the model's behavior well is important, and we also require great infrastructure—extraordinary infrastructure, for example, for reinforcement learning. The very important issue, besides the algorithms and the things that people have been working on for a very long time, is that what's special for agentic applications is how we define agents and how we define how an agent model would work.

First, you need to define the task. You need to define the model's goal. Especially in a long-horizon task, you need goals that are actually hard and diverse. The second part is that you need environments. You need great engineering environments, scaled-up environments, and different, diverse environments—not just coding, but, for example, workplace environments and different kinds of tools. That's great engineering.

Then you need great infrastructure. You need outstanding RL infrastructure to let the model really roll out over a very long horizon, with very efficient GPU use, very efficient training rollout, and so on. I feel like that's what's different in agentic reinforcement learning compared to before.

Are you affected by GPU constraints? How do you solve the compute problem?

We do have a team that works on how to utilize the compute most efficiently. That's actually one of the RL scaling issues: utilizing compute very efficiently. Their purpose is to minimize compute use while training more, right?

Personally speaking, I don't really have a GPU constraint, because we have a great team that works on utilizing the compute as much as possible while stabilizing the training.

But do you have problems that you need to solve with your expertise—how to use things more efficiently—or is it just that team?

We are actually the same team, because we're the reinforcement learning team. We view this issue from different perspectives. It can be implementation, it can be a data perspective, and you can view it from different perspectives, but our goal is the same.

We're always looking forward to new solutions that come from Chinese labs because they're always mind-blowing.

We are actually working on some new agentic reinforcement learning stuff, but it won't really come out with M2.2, with the next-generation model. We are still working on it. I'm not sure what I can share, so I can share it later when I have concrete conclusions. As I said before, I can't really say something that we haven't documented yet.

Will it be available when the model is out?

That depends on our timing. I'm not very confident yet, but we are working on it diligently.

Yeah. There are a lot of constraints when talking to researchers. If we talk about openness, this whole conversation that I'm having with people right now in this quarter is about open source. I wonder if you can talk about the company strategy: why the company decided to publish open weights of the models. What are the benefits? What are the cons to that?

For our team, the research team, we always wanted to go open source because the open-source community is fantastic. I learned that from day 1 when I joined the team: the open-source community is fantastic. As researchers, we did want to join the open source, but, on the other hand, speaking of the cons, we are a company that people care about—whether this can make money or if this is a business.

The con would be that if the weights are open source, fewer people would use APIs. But as a researcher, that really isn't my focus that much, so I'm not very confident about the company strategy for the tech part. We just believe that we can build better models with the open-source community.

How much do you use open-source tools yourself from different other companies?

A lot. For example, for inference, we use—I'm not sure if I'm allowed to say specific open-source projects—but we collaborate with both vLLM and SGLang, and they have open-source code repositories.

How do you look at the open-source stack? Because when we talk about open source, sometimes it's perceived as one thing, but actually it's multilayered. How do you look at it?

For example, there are a lot of open-source agent scaffolds—both coding agents and agent scaffolds—that we use ourselves to test our models, and then we look at their logic. We look at their code to see how they design specific scaffolds and, for example, engines. Then we take what they worked on that was really good, and we reflect on how we think about the problem, how we structure the problem, whether we're on the same page, and stuff like that. So we learn from each other.

Do you think teams underestimate how much engineering discipline open models require compared with using closed APIs? It always requires a lot of setting up, and it's a different kind of compute, and you need to have talent for that—you need engineering talent—instead of just choosing a closed API, turning it on, and using it. Do you have any difficulty with that, or is the open-source stack inside the company established and working?

Personally, I don't have a problem with that. There are other open-source models, and if they publish, I'll just download them and deploy them on our machine, and then work with them if I want. Personally, I don't have that issue. If there are personal developers out in the wild, I understand the problem, especially when they don't have their own compute. Then it would be easier to connect to a model through, for example, OpenRouter and stuff like that.

Do you use a lot of other open models on that same OpenRouter, let's say? Do you play with them?

Yeah, I play with them. I would play with them on day 1. If they release at midnight, I play with them at midnight. [Snorts]

Are you taking notes? [Laughter]

I don't actually take notes, but I do have my personal evaluation stack: a list of fun questions that I like to test with every single model to see how they work.

Can you tell me about it? That's super interesting.

Yeah, I've been collecting a bunch of questions since I joined the company in different areas, including logical reasoning, mathematics, proofs, report writing, agentic tasks, and stuff like that—a lot. I just like to see how the model reacts to these problems and how it approaches them. Different models have different personalities when approaching them.

That's true. And you always need to adjust them. If we want to give people who want to evaluate a model themselves sort of a little guide, can you give me examples of the questions—say, 5 questions you need to ask the model to understand how it works, if it works well?

From a professional evaluation perspective, 5 questions isn't enough. If you want to do a very standard and very fair comparison among models, we have to make it a very confident test. There has to be a certain number of questions in each domain to see how the model performs, and usually you need to test it multiple times because models are not very stable themselves.

If you're testing for fun, use the fun questions, but if we are actually assessing the model's capabilities, we need some sets, and that's very fair among different models. That's correct, because some problems are not correct. For some questions, the answers are not single. For example, sometimes when we run the test, the environments are not fixed. For example, the gold patch wouldn't pass and stuff like that.

So if we're doing a professional evaluation, you have to make sure the evaluation is correct, diverse, and above a certain threshold, so that the test is confident.

You mentioned characters. How do you work with your model's character?

I don't work on my model's characters. Okay, that's how I think of this issue. A general model should have all characters, or it should be able to perform all characters. It might have a default character. If the user wants it to be a different character, and that is injected into the system prompt, it should be. That's how I view this issue.

I find it hard to adjust to the new models because they're so different in terms of character all the time. I just don't even understand why it happens. I think it has to be something related to the data that the model was trained on, the different patterns the models have been trained on, and also different people. A different team might have their own constitution in the system prompt, or as the model's default behavior.

If you look at open models in production today—I don't know if it's a relevant question—but where do they fail first? Open-model-specific reasoning, tool use, state tracking, evaluation blind spots—there are all those risks for open models. Where does it break first?

I think open models are not very good at adjusting to different environments. From what I see right now, we can see, for example, Claude, right? People use Claude in different coding environments, and then people think it performs well in all environments or with different tool definitions and stuff. But I don't feel like current open models can achieve that accuracy [Snorts], or that level of understanding of different environments.

Why? Where is the problem?

I don't know how Claude does it. But for me, I think it is a solvable problem, and we are working on it. We are improving it in MiniMax-M2.2, but it's still not as good as, for example, Opus. But for MiniMax-M2.5, it might be. We do have some systematic research going on in the area that has shown some results now, but there still isn't a concrete conclusion, so I won't say it.

I'm so curious, but do you think it's the problem of compute because they have this infinite amount they can just throw at it?

I feel like compute is one side, but how we structure the problem and how we approach it is another side, and that's where we're more confident that we can solve the issue.

What can you tell me about MiniMax-M2.2 if it's launched by the time the interview is out? Can you give me some overview?

Better coding, obviously, and better multilingual coding, obviously, and more stable than before. It has better performance than M2.1 in different areas; it's better and more stabilized, with longer horizons and stuff like that. We are testing it in different environments right now, and we believe that it's better than before.

So, different coding environments, right? Even environments that we haven't seen before, even environments that are totally out of distribution, we see some very promising scores that are higher than M2.1.

I wonder how you stay updated with everything that happens, which is super hard because the pace is just insane. You said when the models are out, you play with them. Do you read research papers? What are your other interests that help you cross-pollinate with what you do? Can you tell me how you stay up to date and what inspires you?

There are different articles, different blogs, and papers coming out every single day—a bunch of information. How we deal with it is that we have an internal agent that tracks all the new articles, blogs, and papers, and then it dispatches them to different subject areas. Then it summarizes and analyzes them for researchers.

So we have an internal researcher, if I call it that, that does some filtering by itself, and then it gives what is filtered to us. Then we can improve the researcher if we think it doesn't do well, and that's how we filter out a lot of information first. Then we play with new code repositories with coding agents so that we can understand them more quickly and play with them more quickly. So we're keeping up with all the improvements with agents and with our models, for our models.

That's fascinating. When you became a researcher, when you chose this path, what did you think you would be doing, and what are you actually doing? Is it close to what you thought?

That's a really good question. When I joined the team, I thought I would be reading papers every day, because that's what I was doing in school, in a lab. We would read papers, come up with ideas, implement ideas, and run experiments. If the experimental results were good, we would run them on a larger scale.

I thought I was about to do that. But then what I realized was that when joining the company and working for a couple of months, you already become pretty much top of the area, or of the industry, and you have to come up with something that's really new. Or you encounter problems that you just don't know how to solve.

It's not like you can read a lot of papers and then build up your thinking based on the papers. It's more like you need to really understand the problems from the fundamentals and then think about them from the fundamentals so that you can find the right solution.

Another thing would be that engineering is very important. I didn't know that during school because during school, or during labs, it's more toy-like compared to companies. It's not scaled up. But when you really do scale up data, compute, and people, right, you encounter engineering issues that you need to tackle very elegantly, and engineering is very important. That's part 2 that was different from what I imagined. Pretty much these 2 things.

When you work on the model currently, is it mostly that you're solving problems that you see immediately from your hands-on work, or is it that the company says, “Oh, we have to achieve, let's say, Opus results”? How do you set the goals?

We have a meta-goal at the company level. For example, we want to improve the AI's capabilities in improving productivity, because that's how people view it. We have a company mission. As a single researcher on the team, we have our own missions, and we set our own goals.

What is your goal currently?

For the next generation, I really want the model to work elegantly with experts. It's more like better collaboration with experts and developers. That's my goal as well, but that's maybe 2 versions away. I think we're launching 1 version about every month or month and a half, right?

For a longer horizon, we are definitely working on it. But for me, the goal that I set along that path, that's a 3-month-away thing. For the better collaboration thing, that's a 1- or 2-month-away thing.

I wanted to ask you a little clarification question about interleaved learning, where you were talking at AI Engineer as well. The model doesn't settle on 1 action; it's constantly in the loop of asking more questions and trying things. How do you look at it? Is it continual learning? Is it part of it? What do we need to solve to have the model continuously doing this learning for longer and longer horizons?

That has some overlap with the well-defined concept of continual learning. By overlap, I mean I think both conceptually and technically, but I don't feel like they are exactly the same. What I talked about at the summit was not at the level of full continual learning. It's more like on the path to that.

How do you see it being solved? Any ideas?

We do think that's a different problem definition, or a different way of the model working with people, and we are working on that now with our own defined question. But if I need to say how we approach it, I would say we would approach it through experiments.

That's a very interesting question on continual learning, and it's still very exploratory. That's definitely what we are working toward. But it has different phases, or different stages. We might approach stage 1 first while exploring more stages later.

And the stages aren't yet outlined?

We do have our internal definitions, but I didn't prepare them today. I would say the first would be to be more stabilized in long-horizon tasks, what I said at the summit, right? And then the next thing would be optimization.

Can you repeat it? People don't know what you said.

For example, we see a model. It receives environmental feedback in a new environment. It needs to know what to explore and which environments to see because it's a partially observed environment. It needs to know which actions to take to receive better information, then have a better reaction, and then perform harder, more complex tasks in the environments.

That's more of stage 1, right? That's pretty simple. Basically, all agent models can do that to some extent. Maybe not perfectly, but to some extent. That's how we can actually solve it with our current algorithms.

But we do see different forms of how a model improves itself in the environment, and we don't have a concrete conclusion on that yet. Maybe in 2.5 we will. That will be a different definition than what I said. The model itself would be defining its own goal. That's something that would be different.

Thank you so much. My last question is about AGI. Do you believe in AGI? And if yes, what does it look like to you?

Okay, that's a very large question. People talk about AGI and ASI every day. Actually, when I was interviewing with MiniMax, when I was interviewing with our CEO, I said the same thing. He asked me the same thing, right?

What I said was that I think people talk about AGI, and people have different definitions of AGI. But we can only know the definition of AGI when we achieve it. It's still progressing so fast that the definition even changes every day, and people have different comments on it.

What I think is more important is that we actually work toward it, work toward our own definitions of AGI. As long as we figure it out, it becomes true. That's what I said during the interview, and that's still my view today. The definition will become true when it becomes true.

When we see it, we know it's AGI.

Yes, exactly.

But we're not there yet.

No, there can still be better AI intelligence, for sure.

Thank you. One more last question. What was the book that influenced you the most? It can be a recent book or a book from your childhood.

Let me just double-check the name, though. Something like The Art of Creativity, or something, that I read during undergrad. So it's a long time ago. I don't remember the exact name.

Yeah, there is a book called The Art of Creativity. How did it influence you?

It opened up how I think of my own mind a lot, and then how I view the world and how I view problem-solving. For me now, problem-solving is more of a discovery. That's how I would summarize it in 1 quote.

Thank you so much. Thank you for your time. That was very interesting.

Thank you for having me. If you're finding value in the show, we'd appreciate it if you take a moment to share with friends, post online, write a review on Apple Podcasts or Spotify, or just leave us a comment on YouTube. Of course, we always welcome your feedback, guest and topic suggestions, and sponsorship inquiries, either via our website, cognitiverevolution.ai, or by DMing me on your favorite social network. The Cognitive Revolution is part of the Turpentine Network, a network of podcasts, which is now part of A16Z, where experts talk technology, business, economics, geopolitics, culture, and more. We're produced by AI Podcasting. If you're looking for podcast production help for everything from the moment you stop recording to the moment your audience starts listening, check them out and see my endorsement at aipodcast.ing. And thank you to everyone who listens for being part of the cognitive revolution.