Navier–Stokes 공로 논쟁, Mistral AI 투자, 오픈소스 스택과 에이전트 컨텍스트 최적화

Mathematics is a team sport for all of humanity and it transcends the competition between companies. Everyone in AI is under a huge amount of pressure to be the first to post a key result, to not see the accolades go to a competitor, but that should not override the bigger things at stake here. There are many, many transformational results to drive for, and I feel strongly that staff in every lab should internalize that if one goes to a competitor, another can always happen at home. Credit assignment is one of the most painful problems in frontier AI research because it often feels like there are so few big moments and it can be so zero sum, but the best way to solve this is to become more generous and comprehensive about credit rather than more burned and pressured by it. My sincere hope is that the field of mathematics experiences the introduction of advanced AI as a boon, rather than something painful or threatening. A big part of whether that's true is determined by the diplomacy and grace of individuals involved at every point where the frontier of math touches the frontier of AI. I hope we can all be very sportsmanlike and supportive of one another as we proceed through discoveries that will reshape the world. Re: ongoing issue on Navier-Stokes: I'm going to withhold judgement until everyone involved has shared their side of it. If reports are accurate, an apology is in order. If the problems have indeed been solved, many accolades for many people across multiple organizations are also in order; what an extraordinary set of human accomplishments!

Putting the generative drama aside a nice write up by Terry Tao on the Navier Stokes advances It would seem that Buckmaster & Apolge were well on the way & OpenAI has a full solution already with the same approach

We have just raised 3B€ to accelerate our R&D. We are scaling up our training and inference compute to build future generations of our models, and expanding our Science team across all our offices -- Paris, Palo Alto, SF, London, Zurich, and Warsaw. Join us !

More than 250 organizations across China contribute to PyTorch Foundation projects, including @DeepSpeedAI , Helion, PyTorch, @raydistributed , Safetensors, and @vllm_project . “Open source has become the default way the world builds AI, and the PyTorch Foundation is a leading hub for this innovation,” said @sparkycollier , Executive Director of the PyTorch Foundation. “Welcoming @alibaba_cloud , Cambricon, and @AntGroup as members alongside @Huawei further strengthens the global open source AI ecosystem and community building the open source intelligence layer developers rely on for training, optimizing, serving, distributing, and running models. PyTorch Conference China brings that community together in Shanghai to continue learning from one another.” Alibaba Cloud and Cambricon have joined the PyTorch Foundation as Platinum members, and Ant Group has joined as a Gold member. Representatives from the three new member companies and Huawei are delivering keynotes at PyTorch Conference China on advancing the open AI stack, covering hardware, models, and infrastructure throughout the conference. Alibaba Cloud’s Qwen infrastructure team is walking through how they serve Qwen at massive scale. Huawei will explore hardware-software co-design and the interoperability needed between Chinese and global AI technology stacks. Cambricon is detailing how the company is hardening PyTorch’s device-agnostic foundation so any backend can offer broader reach and richer native capabilities. Ant Group is showing how existing cloud native building blocks can be assembled into a secure, on-demand runtime for AI agents. Taken together, these keynotes move from silicon to software to deployment, giving conference attendees a full-stack view of how open source is being built into every layer of AI in China. 🔗 Read the press release: https:// pytorch.org/blog/alibaba-c loud-ant-group-cambricon-and-huawei-come-together-in-shanghai-to-advance-the-open-source-ai-stack-at-pytorch-conference-china/ …

A stronger open AI ecosystem is built by communities 🌏 Great to see @PyTorch bringing the community together and the open AI ecosystem continuing to grow across China ❤️

A smarter Claude model burns more tokens, not fewer. And it is not a minor 3-5% difference. MCPMark V2 measured 54% higher token usage across 21 backend tasks. That sounds counterintuitive until you look at what the agent must do before writing code. Claude Code first needs to understand the tables, RLS policies, storage buckets, auth providers, and edge functions already configured. Most backends do not provide that picture cleanly. Supabase is a good example. An OAuth request through MCP can return the entire auth documentation, covering email and password, magic links, phone auth, SAML, and SSO. That can be 5 to 10 times more text than needed. Yet the agent still makes separate calls to `list_tables`, `execute_sql`, and `list_extensions` to reconstruct the backend state. Some info, such as configured auth providers, is not queryable through MCP at all. Debugging has the same problem. A 401 may come from the platform layer or the function code. The agent cannot reliably tell which one failed, so it starts changing code for a problem that may live elsewhere. A better model has no special way around this. If anything, it works harder to resolve the uncertainty. That means more discovery calls, more reasoning, more retries, and ultimately more tokens. A better approach is actually implemented in InsForge, an open-source backend (self-hostable via Docker) that offers the same primitives as Supabase but structures everything around the assumption that an agent is operating the backend, not a human on a dashboard. Before writing code, one CLI call returns the full backend topology in roughly 500 tokens. Every table, auth provider, storage bucket, and available AI model appears in one structured response. Its instructions are split into four narrow skills for CLI operations, debugging, frontend work, and third-party integrations. Only the skill matching the current task enters the agent's context. CLI operations also return structured JSON and semantic exit codes. The agent knows what failed and why instead of guessing what an ambiguous 401 means. I tested both backends on the same full-stack RAG app. Supabase: - consumed 10.4M tokens - needed 10 manual interventions InsForge: - consumed 3.7M tokens - completed the entire build without any errors This goes beyond Supabase. Backends were designed for humans who can inspect dashboards and interpret raw errors. Agents need the same context supplied upfront, or they burn tokens discovering it through calls and retries. InsForge is an open-source implementation of that idea, self-hostable through Docker. GitHub repo (13K stars): https:// github.com/InsForge/InsFo rge … (don't forget to star it ⭐) I wrote a full walkthrough on building the full-stack RAG with Supabase and InsForge. Read it below.

Claude Code used 3x fewer tokens with one change: - Before: 10.4M tokens · 10 errors · $9.21 cost - After: 3.7M tokens · 0 errors · $2.81 cost I used InsForge Skills + CLI as the backend context engineering layer for Claude Code (open-source and local). With Supabase, tables, RLS policies, auth providers, storage buckets, and edge functions were retrieved through separate calls. Each response entered the conversation history, so later calls carried more context. But InsForge returned the backend topology in one metadata call of roughly 500 tokens. InsForge repo: https:// github.com/InsForge/InsFo rge … (don't forget to star it 🌟) Its instructions were also split into narrow skills for CLI operations, debugging, SDK usage, and integrations. Claude loaded only the instructions needed for the task. The CLI returned structured JSON with semantic exit codes as well. This made it clear whether a failure came from the operation itself or the code being executed, avoiding several retry loops. The token savings essentially came from replacing repeated backend discovery and debugging calls with one structured view of the backend. I wrote a detailed walkthrough of both builds, including where the extra calls, tokens, and errors came from. Read it below.

I recently tried Sakana Chat and it feels like it's been massively upgraded with performance that's shot way up. You all should give it a try too. Now you can use up to Namazu and Fugu in model selection.