AI:AM LIVE — July 2, 2026 — The Export Regime Blinks and Washington Eyes a Stake in the Frontier: Kunle Olukotun

The rundown

1. 7:04Opening86 min

   Opening: The Export Regime Blinks, Washington Eyes a Frontier Stake, and Open Weights Priced Out LoudCommerce withdrew the export-control requirement on Fable 5 and Mythos 5 after an 18-day freeze — and Anthropic restored Fable 5 globally under new terms, including deeper pre-release US-government testing of future models. In the same window, the FT reported OpenAI floated a ~5% stake (~$42.6B) to Washington, with the same proposed of every leading US lab. Then the closed-vs-open fight got quantified: GLM-5.2 ranked the top open-weights model and #3 overall on agentic work (but verbose and hallucination-prone), with a Chamath n=1 pilot showing ~16× cost savings vs Opus 4.8 — and, if time, two fresh research directions in Meta's Brain2Qwerty v2 and the language-free NEO world-model.

   Watch

   ▶Play this segmentYouTube · from 7:04

   As aired

   Nathan and Prakash opened Fable Day — the relaunch of Anthropic's Fable model after a roughly two-week suspension tied to a government review. They traded theories on what triggered the pause (unclear whether Amazon raised the alarm, and why), debated whether the episode reflects a healthy oversight regime or governmental confusion, and compared notes on how the relaunched model behaves: Prakash found looser classifiers and fewer production-database refusals in his own testing, while Nathan cited reports of more frequent fallbacks to Opus hurting some coding benchmarks. They also previewed GPT-5.6's same-day launch and joked about the industry's increasingly obtuse model-naming conventions.

   The conversation turned to pricing and subscription strategy — Nathan expects Fable to return to the Claude Max bundle to keep pace with a token-rich ChatGPT Pro, and both discussed personal strategies for routing between Fable, Sonnet, Haiku, Codex, and GPT-5.5 to manage a self-imposed $1,000/month AI budget, including Prakash's account of a developer who avoided hitting Fable's usage limits entirely through disciplined, manual model-routing rules.

   They pivoted to enterprise AI adoption, sparked by Alex Karp's recent broadside against the frontier labs (and Hugging Face's Clément Delangue calling out Palantir's own free-tier hypocrisy in response). Prakash argued Karp's 'they'll steal your IP' framing really only bites for paperwork-heavy, IP-based businesses — banking, compliance, software — rather than physical ones like Nike or Walmart, and shared frontline reports from the AI Engineer World's Fair showing real ROI already emerging at the implementation level, even if it hasn't filtered up to enterprise leadership yet. Nathan pushed back that the 'workflow paradigm' enterprises are building may itself be racing to get automated by ever-smarter frontier models before it pays off, and the two debated whether AI-native companies like Tasklet and Lindy — who bet everything on Claude before recently diversifying — model the right playbook for everyone else.

   They closed on bigger structural questions: Prakash laid out a 'zero-to-one' thesis that Claude Tag's shared multiplayer context solves the hard problem enterprises actually have, eventually letting one model allocate its own compute and dissolve the standardized red tape (and the SaaS layer) that businesses build to manage humans at scale. Nathan and Prakash then discussed Anthropic's new cross-investment with Micron and the strategic logic of frontier labs eventually acquiring companies like Slack or Salesforce, before landing on Sam Altman's proposed 5% OpenAI equity giveaway — debating whether distributing shares to households versus the government is the smarter political move, with a nod to Dean Ball's take (posted the morning he starts at OpenAI) that household distribution is far preferable to direct government ownership.

   Key moments

   It would be horrible if we just had Anthropic — we'd all be suffering terribly.

   I guess I kind of still feel like all roads lead back to Fable, if you're really going for performance.

   They're just going to drink the milkshake.

   What we covered

   Fable comes back — the export regime blinks. A June 30 letter from Commerce Secretary Howard Lutnick withdrew the export-control license requirement on Fable 5 and Mythos 5, ending an 18-day freeze that began when Amazon researchers found a jailbreak getting Fable to flag software flaws and write exploit code. Anthropic is restoring Fable 5 globally, but with a new cyber-classifier (routine coding temporarily falls back to Opus 4.8), a self-run HackerOne bounty program, a cross-lab jailbreak-severity framework with Amazon/Microsoft/Google, and — the load-bearing part — earlier pre-release access for the US government to test future frontier models. Is a standing lab-government testing pipeline a safety win, or the government embedding itself inside every frontier release?

   Source post ↗

   OpenAI offers Washington ~5% — the frontier goes partly public. Per the FT (confirmed across CNBC/CNN/Forbes; OpenAI unconfirmed), OpenAI proposed giving the US government a ~5% stake — roughly $42.6B against its $852B March valuation — and Altman reportedly floated the same 5% from each leading US lab (Anthropic, Google, Meta) into a sovereign-wealth vehicle modeled on the Alaska Permanent Fund. In the same week Washington moved from gating who can use frontier models to potentially owning a piece of the companies that make them.

   Source post ↗

   Closed vs. open, priced out loud — GLM-5.2 is #3 overall and far cheaper. Palantir's Alex Karp went viral asking why labs 'charge for tokens if it's so valuable' — enterprises want to own their compute, models, and data. Underneath the rhetoric: independent evals now rank GLM-5.2 the top open-weights model and #3 overall on agentic knowledge work (beating GPT-5.5), though it burns ~141M tokens to run the index and scores near-bottom on hallucination. Chamath posted an n=1 pilot where pairing GLM-5.2 with an agent harness cut a code-modernization task's cost ~16.4× vs Opus 4.8.

   Source post ↗

   Research kept shipping: models that theorize, brains that type. Meta's Brain2Qwerty v2 (building on a v1 in Nature) reports the highest-performing non-invasive brain-to-text pipeline yet — advancing from character-level to real-time word- and sentence-level decoding. NEO (Neural Theorizer), an ICML 2026 oral, learns compositional, transferable theories of the world from raw observation with no language or LLM supervision — a bet against 'just scale the LLM.'

   Source post ↗

   Full transcriptLightly edited · timestamps jump to YouTube

   7:04

   Prakash: So, good morning. It's Thursday, 07/07/2026, and welcome to Fable Day.

   7:14

   Nathan Labenz: We're back, baby — both live here on AI in the AM, and with our favorite America's-top-model back to clean up all the messes we've made with lesser intelligences over the last couple weeks. So, very glad for that.

   7:35

   Prakash: I remember we had some bets — I thought it'd be before July 4 for sure. And it landed basically on July 1: we got the model on July 1, the announcement came June 30. So —

   7:52

   Nathan Labenz: Yeah, I originally set the over/under for the Friday before, so it's definitely the over relative to my guess — though not by a crazy amount. I think Sam Altman's public statement that it's not crazy for the government to want to take a look at these things for a couple weeks before they go live is true. And if we can get into a sane regime and a reasonable cadence, and this becomes part of the prerelease process, there's still some chance for it to be all to the good. I do appreciate that folks are at least waking up and starting to take this stuff more seriously.

   There are still a lot of open questions, though, including just generally: what the hell happened? We're still kind of piecing it together through reporting and hearsay. What exactly caused this in the first place? Was it really Amazon that called the government in a panic? If so, why — were they confused about what was going on? That would be weird. Is there some sort of intrigue between Amazon and Anthropic? Amazon has a big share of Anthropic, and as big as Amazon is, that stake is starting to become pretty material to their overall market cap too.

   It would be strange for this to be some sort of sabotage, but I have a hard time telling a story that doesn't leave me with weird open-ended questions: what was seen, why was it reported this way, how did we end up in this panic situation, and then how was it fixed? The best information I've seen suggests that the way they mostly reassured the government was by painstakingly pointing out that the capabilities observed had already been in the wild with other models for some time.

   That's a strange way to get back into the approved column — 'everybody else was doing it too' is kind of like something my kid would try. It's a strange way to get out of the frontier-model penalty box. If you fill in the gaps charitably, you can tell a Judd Rosenblatt-type story where this is a clumsy but ultimately enlightened step for the government to take. Fill the gaps in uncharitably, and you're just left shaking your head, thinking: who's making these weird moves and causing these hiccups?

   I'd love to see better information, at a minimum — at this point it really seems like the conversation can and should be more public than it has been. So that's what I'll be watching next, in between prompting Fable. Do you have any thoughts on where we are? There's also the question of how nerfed it is coming back. I don't have enough information yet to really render a good judgment. For my personal use, it doesn't seem to have been affected so much that I can't do what I want to do. But I've seen some reporting online suggesting that Fable's fallbacks to Opus are more frequent now, and that on some coding and terminal-style benchmarks, overall performance is worse because of those higher fallback rates. What do you make of it at this point?

   11:52

   Prakash: So in my testing, the fallback rates were lower than before — mostly because I was dealing with a production database, and the old Fable, the moment you mentioned the word 'production,' it was out. Now Fable is happy to address production databases. So I think what actually happened is they sat down and loosened their classifiers for a lot of things. I've also seen people online say that when they get dropped for cybersecurity-research reasons, they can appeal — the company does a quick 'why do you need this access?' and then grants it.

   So there's a kind of defense-in-depth concept — classifiers first, then permissions for certain people — that's basically been accepted by the government. That's where we are with Fable. People are still saying the capability is a significant upgrade. It's very hard to judge these things at this point, so we'll see. GPT-5.6 is coming out today, I hear.

   2:15 Pacific time today. And I think the OpenAI guys are saying GPT-5.6 Sol Ultra is the version they're standing behind as better than 3. But it just shows you: how is anyone not part of this AI bubble supposed to know which model to choose? GPT-5.6, full, Ultra — the versioning is just so obtuse at this point.

   14:05

   Nathan Labenz: I think the fact that they dialed this in — and again, we're inferring this from limited data points — matches my expectations. Even a two-week break, and the two or three days of data they got on initial usage, would be enough for them to meaningfully dial in the precision of their defense-in-depth safeguards.

   We've talked about this before — it's just how just-in-time all of this stuff is. I mean, obviously they've been working on these safeguards and iterating on them for a while, so the whole program isn't new, but the iteration cycle is pretty fast. If you map back two weeks before they actually launched Fable, and look at how much progress they made in the immediate run-up to the first launch, it really does show that so much of this is just-in-time and fundamentally iterative.

   I continue to be of two minds on all of this. I do think iterative deployment has served us pretty well so far. If I critique the OpenAI strategy at a high level, that's one thing they've gotten quite right — more so than Anthropic. This is one way Anthropic has kind of converged on the OpenAI paradigm: initially their whole thing was much more conservative around deployment. At one point they were broadly understood to have made some sort of commitment to never advance the frontier — obviously they'll say now that they never actually said that, and I'm pretty sure it was meant to be understood rather than stated outright. But regardless of how firm that commitment was, clearly they're doing it now, and clearly they've bought into the OpenAI view that iterative deployment is the best path to things going well broadly.

   I still think that makes sense, but all these models start to come under strain as you get to sufficiently powerful capabilities, or regimes where a small enough gap in the defenses is enough to create a huge problem. It feels like in multiple ways we're riding paradigms that have worked well so far, and we just don't know if and when they might break — and if they do break, it might be at critical times, which is a strange juxtaposition on multiple levels. People talk about that all the time with alignment, but I think it extends to these defense-in-depth safeguards, and at the highest level it extends to the whole iterative-deployment model. So, as always, confusing. But selfishly, I'm glad to have it back, that's for sure.

   And I'm excited to check out 5.6 as well. For multiple reasons — one, they're obviously going to start charging; we'll see how that plays out. I expect it'll be interesting to watch Anthropic dance around limits and usage, because OpenAI is going to offer a ton more tokens with 5.6 at their $200 price point than Anthropic is going to offer for Fable at their $200 price point. As of now, from what we've seen with the relaunch, it goes until July 7 on this preview-access basis, and then you have to pay API rates — which will be an order of magnitude, maybe more, more expensive than 5.6 tokens on the Pro subscription.

   So it'll be interesting to watch how they manage that. I'd bet Fable comes back to the Claude Max subscription — it seems very hard for them to not have Fable there, because that would make ChatGPT Pro just a better product for a lot of people, and I don't think they want that. So I think they'll want some access to their top model in that bundle. It'll depend on their limits, though — they've got to destroy demand to clear their own market, so it might come down to just how strong demand is.

   I do think people, as we discussed, will be willing to pay the API rate — things like frontier code-success rate, and what that implies about general taste and quality of work, judgment, quality of writing, make paying a little less than 2x for that much improvement worth it for a lot of people. But in the meantime, we'll also all be figuring out how to create our own little neutral platform that does model routing in just the right way. Will people outsource that to providers — go to Sakana and have them handle the routing, plug into OpenRouter, or just keep it to a couple of core subscriptions and have Fable decide when to send work over to Codex? That's going to be a definite area of exploration for a ton of people, and I'm already doing a bit of that myself, because my default assumption is I'm going to spend $1,000 a month on AI tools.

   And yet if I don't do any optimization, I could blow past that real quick just using Fable for everything. So even for someone with a plan to spend $1,000 a month without thinking twice about it, it's going to force some thinking about how to allocate these tokens and when to use Codex. It'll be really interesting to see if 5.6 is better at general-purpose knowledge work too — that's the other huge thing. It's clearly going to be good at coding, probably best at math, probably the most steerable for coding. The vibe check I get is that if you really know what you want coded and spell it out in great detail, Codex is probably a bit better — more reliable at doing exactly what you told it to do, better at instruction-following.

   Whereas if you don't know what you're doing and you're just kind of vibing it, Fable's probably better. Will 5.6 start to catch up on some of the softer skills — theory of mind, for when you don't explicitly say everything you want — or will it continue to be more literal-minded, an assistant that struggles more to fill in the gaps? I'll definitely be watching that and trying some things. This is the first one in a while where I feel like they've sent signals that maybe it could have a different kind of character, and I'll be really interested to see if it can help me with writing. Can it do a good job on intro essays for the podcast? Claude has had the top spot on that for all but about a week out of the last few years — there was one moment where Gemini 3.5 Pro took the lead in the write-as-me test I always run. GPT has never had the lead. Claude has almost always had the lead, but I'll definitely be interested to try it again with this one.

   22:52

   Prakash: I wonder if there's a big difference between giving it your writing from before any AI help as reference, versus your writing from after AI help. I wonder if there's a significant difference between the two.

   23:08

   Nathan Labenz: Well, probably not too much for me. That is something I think people in general should watch, though.

   I've continued pretty much to rewrite everything Claude gives me, out of some sort of masochistic commitment to full authorship, and really haven't compromised on that much. As we talked about in the first days of the Fable launch, I do think now is the time to start rethinking some of those commitments. But I think this will be the dividing line for me, at least — where co-authorship might mean there's a meaningfully different input as part of the prompt going forward. Thus far, I'd say all my historical stuff still counts as mine enough that I can claim authorship, but I wouldn't worry about that too much.

   I should try Pangram Labs on myself — that would be interesting, and pretty easy to test. If I took all my intro essays through the history of the podcast and plotted their Pangram Labs score over time, would I see a drop-off in my 'human' number as I potentially leaned more and more on Claude than I even realized?

   It's certainly a possibility, but I'd bet against it — I'd bet I still get something like 100% human on pretty much everything up through the present. But that could be something we report back on in our next live session. I do like sitting here sometimes just riffing on ideas that we can then vibe-code and bring receipts on, rather than purely speculate.

   25:03

   Prakash: I do see a lot of people trying to go down the model-routing route — starting to use open-source models. There was a little interview with Alex Karp of Palantir yesterday where he just goes ballistic on the frontier model companies, saying they're going to come in and steal your data, steal your business, steal your IP, and you're going to have nothing left — that this is unacceptable, and we should all be using open-source models.

   The really funny thing is, right after that, Clément Delangue, the CEO and founder of Hugging Face, responded with, well, Palantir is a free member on Hugging Face — doesn't even have a subscription as a business. So why don't you actually put some money toward open source, if you're so keen on it? And I think that basically describes most US tech firms — they're in that position where they don't like the frontier labs, but they don't really want to use open source either, not in any way that costs them anything.

   They kind of want to use open source if it's free and they don't have to do anything. But if they had to do anything at all themselves, they'd prefer to use closed source and just pay for it, or use a SaaS product. I also believe the frontier model companies can model-route at any time internally — they're playing a revenue-maximization game, deciding whether to route internally depending on whether they think there's enough revenue there or not.

   So if they say, okay, there's $100 million at a 30% discount — can we serve that $100 million of revenue without using Fable, say, but using Sonnet 5 instead? How would we structure that to hit the required capability and also hit the cost? The frontier lab can always do this kind of adviser strategy, where Sonnet 5 is the core model and pulls in Fable as an adviser for specific tasks.

   In fact, on the API, that's actually what Anthropic's product team has been promoting: if you're using Sonnet and Haiku for your classification systems and customer service, but pull in Fable when things get too difficult. So this is basically model routing — but model routing driven by the enterprise customer themselves, taught to route effectively using a smaller model. You can also route using a better model as part of splitting tasks into a to-do list and sending out independent agents.

   Some people right now on Fable in Claude Code, if you set it to Ultra mode, actually get this experience — though Fable doesn't tell you whether it's using sub-agents on lower models. But you can explicitly ask Fable to use Sonnet sub-agents, and it'll use those sub-agents and check their work. So you can stream a lot of the work to other agents on the existing model and cut down on usage. I hit my Fable limit yesterday — the five-hour limit. And I saw one of the software-engineer influencers online who said he'd done 16 pull requests since Fable came out and hadn't hit his limit at all.

   He had a structured strategy — he'd already told Claude, these are the models you can use: you have Fable, you have this, and you have GPT-5.5, available via the command line as an MCP tool. And he told it the cost, the effectiveness, and the taste for each, and told it, depending on cost, taste, and task complexity, how to allocate the to-do list across them. So he hadn't run out at all.

   Effectively, these firms are capable of doing model routing internally on their own — that kind of structured process could be moved into the model very easily. They just haven't, because it's not a necessary optimization right now. But the moment they think it's necessary, they'll do it. So I don't really know that model routing is going to be a long-term thing, but it is a negotiating tactic against the firms, on price. It's very helpful right now that we have OpenAI and Anthropic close to each other — it would be horrible if we just had Anthropic. We'd all be suffering terribly.

   31:04

   Nathan Labenz: Tactically, for what it's worth, I like to start with the smarter model and have it delegate to the lesser model. I've been a little confused by the idea of starting with a Sonnet, or even a Haiku, and routing up — though I could see that working too. There's always this question of how much you're going to control and map out the structure of the work you're trying to do, versus how much you're going to control the inputs. Going back a couple of years, I think it was already possible, even with GPT-4o and fine-tuning, to get virtually all routine tasks done on an AI workflow basis.

   If you're a company that employs people to do roughly the same thing over and over, I'd bet that with 4o and fine-tuning you could get human-level performance on a large majority of those tasks. So we've had, for a long time, the ability to get there if you control the environment, map it out, and are willing to do the evals, the prompts, and the fine-tuning. The hurdles there are high, but they've been brought down with smarter models.

   What do people really want to do? I want a smart, general-purpose assistant I can throw anything at, that intelligently decides when a subtask doesn't need its full force behind it. That comes up a lot for me — I'm planning a trip to China, breaking news — and one of the things I'm trying to do is go through all my contacts on all the different social platforms and figure out who I know in China, or who follows me that I don't even know but could reach out to, or who might connect me.

   If it's going through thousands of individual profiles and classifying whether each one is someone we should consider reaching out to for this purpose, sure — probably any number of models can handle that. I'd certainly expect Haiku to be good enough to do a good job and not miss obvious stuff. But I want Fable to construct the overall strategy, sanity-check the final results, and do the prioritization. I think that's what most people want intuitively from their AI experience. What's unclear to me is what enterprises really want.

   Do they want the experience where you just hand it to all your people and say, here's an incredible source of help, use it on the fly in a flexible way, and it'll give you leverage, buy your time back, help you focus on the more important things? Certainly a lot of lip service gets paid to that. But the Alex Karp point of view — which I think is implied by this lesser-to-greater model routing — is, I think, more of a callback to the workflow paradigm, where you're not leaning into the flexibility or general-purpose nature of the model so much, and instead really controlling the plumbing: putting Haiku in a situation where it's told, 'you are a customer-service triage agent.'

   'You're going to get these things, and you'll be able to handle 90% of them. There's going to be maybe 10% you can't — here's a taxonomy of those, we've worked this out — and under these circumstances, you call up to a higher-intelligence model when you need to.' I mean, 'everything, everywhere, all at once' is a good general prediction here — it's not going to be one or the other. But maybe the question is: what's the winning strategy for an enterprise right now? I don't have a great intuition for which strategy enterprises should be pursuing, or with what balance between the two paradigms.

   35:50

   Prakash: I think, number one, enterprises only want an increase in revenue and a decrease in cost — that's the basic fundamental. If you can't deliver value that way, and can't get some metric they can use internally to show that return on investment, it's not going to fly. Alex Karp is bringing in this other thing: risk. You can get increased revenue, decreased cost, but these guys are going to wipe you out in the future — that's the risk perspective he's trying to inject.

   That speaks to why enterprises that are actually getting increases in revenue or decreases in cost, plugging into the existing models, can kind of see where it's going — that's why he's trying to inject the risk perspective. I'm also very confused by the 'they're going to take all your IP' framing. Look at the Fortune 500 — Nike. What does Nike have to fear from Anthropic? Anthropic isn't going to go make shoes, build a shoe brand, or have the expertise to approach athletes for sponsorships. What exactly is Anthropic's threat to Nike, or to Nike's IP?

   Once you start thinking about that — what about Freeport-McMoRan, the largest copper and gold miner in the world? Where's the threat? What about Linde, which does all the materials and gases used for chemical production — what's Anthropic's threat to their IP? Once you go down that route, you discard all the physical businesses. Walmart isn't getting disrupted by Anthropic. Once you set the physical businesses aside, what you're left with is the pure IP businesses — software, software production, maybe pharma.

   Maybe pharma — I'm not so sure. The paperwork businesses: banking, compliance, accounting, tax, regulatory — all these businesses where you have IP or relationships built up over years, where if Anthropic goes in and reads through your entire workflow, it can absorb all of that into the model. That's where I think the real risk is. So when Alex Karp talks about this, he's really creating this aspect of fear and risk, but it's only going to affect a portion of the economy.

   And unfortunately, that portion is the one that's grown dramatically over the last 30 or 40 years — the paperwork, white-collar professions. The physical stuff hasn't grown nearly as much; physical build-out in the US hasn't grown much in the last 30, 40 years. So I think that's really the perspective he's coming from. Yes, the paperwork businesses are under threat, because this stuff is going to be great at complying with rules and reading regulations way better than any human ever will — that's a bridge they have to cross. Besides that, enterprises are concerned about the cost of these things.

   They're a little worried the return on investment isn't there. But on the other hand — this is a good segue — I was at the AI Engineer World's Fair the first two days of this week. Shout out to Swix, who organizes it — it's been going about three years now, and he brings in everyone involved in implementing models at their companies. All the top companies are there as sponsors with booths, and so on. I was speaking to people who weren't in tech at all — a logistics CTO from the Midwest, and another guy running an accounting firm's back office somewhere. A lot of these people weren't in Silicon Valley full-time, but they run teams using AI to solve customer problems day to day.

   The logistics guy told me his CEO is completely AI-built, the management is completely AI-built — which is probably why the team was at the AI Engineer World's Fair at all; otherwise your logistics IT team isn't getting sent to SF. They'd tried working with external vendors before and found it difficult, because external vendors hadn't delivered as fast as they wanted — which you can imagine, sitting out in the Midwest with a local vendor who's a year behind the frontier and has no idea what's going on. So his team internalized everything. They're building evals, building out these systems, using people like Arize and Braintrust, who've built frameworks to evaluate models as you implement them in enterprises. And as they implement, they see the results immediately, because they're right up against that edge.

   They see that customer-service calls or exceptions that used to happen are now getting handled immediately, and the harder stuff they used to have to jump on, they can now start to address. So they're seeing the return on investment day to day. That's very different from the story you get from the big enterprise CTOs, who are so far from the front line that they don't actually know what's going on closely — they're just looking at the numbers, and by the numbers, token spend is going up, but are they really seeing the ROI? If you go down to the working level, though, and look day to day at the customer calls coming in — the handling rate going up, the exception rate falling — that's where we are.

   The people actually implementing and close to it are seeing the results. It hasn't really filtered up to the top layer of enterprises yet. The CEOs who are AI-pilled kind of know what's coming, and they've made the commitment and the investment. The CEOs who aren't are kind of sitting by, saying we'll wait and see what happens. That's really where we are. And I think it's just not very visible — it wasn't visible to me until I went to this conference. I think of AI people as just the people on Twitter — for some reason my world had gotten constrained into this small bubble, and I didn't have a good sense of what people outside the bubble were actually doing or thinking. But you go there and meet these implementers, and you realize all the stuff we talk about and produce in the bubble is getting used outside. People are learning how to use these tools, deploying them, seeing the return on investment — but it's at a very micro, granular level right now. It's going to take some time for the numbers to filter upward.

   44:14

   Nathan Labenz: So coming back to the two paradigms — a lot of what you're describing there sounds like people successfully implementing the workflow paradigm. If they can measure things like the handled rate and the exception rate, that by definition means they're doing this more controlled, structured workflow-style build-out. I still kind of wonder, though — for me, that work is very quickly becoming Claude's work. So we're in this weird spot again where, with this latest tick of the model — and even before, with Opus — the frontier models have a pretty good intuition, certainly better than the vast majority of people, and probably better than all but a small minority of people who've really honed the skill of building a deterministic, structured AI-powered workflow.

   As such, it still feels to me like enterprises mostly should be embracing: let's just pay up for a bunch of Fable and let our people use it. The organizations that are like, 'we're going to go make GLM-5.2 work for whatever, we don't need that, you don't need superintelligence to write your email' — I think that's true, but I think we're still in this weird middle moment where if you try to economize by having your people set up all these workflows so you can use an open-source model and save money, you're signing up to go kind of slow — with a lot of committees and a lot of people in meetings talking about how to do this and how to eval it.

   It still feels to me like there's a lot of advantage in just throwing high-value tokens out to your whole employee base and saying, develop your own workflow solutions as needed — the frontier model you have is really good at that. Maybe your strategy is, specifically, we want to delegate to our own internal GLM-5.2 inference capacity, or whatever inference partnership or provider we have. But how much does that save versus just having Fable natively delegate to Sonnet and even Haiku, where it's clearly going to be more closely trained to do that well, know when they can handle the tasks accurately, and prompt them well? I really don't have a great sense for that.

   I was just talking to a former investor of mine — still an investor, in the sense that we haven't liquidated the investment yet — who's working on a sort of 'Red Hat for AI' thesis at the moment. We came to the same conclusion. I think, as so often, Tasklet, Lindy AI, and the Elicit product folks are really at the frontier of this — they're wrestling with how to carve out any relevance for themselves in a world where Claude can do it all, in a world of Claude for Science.

   Their answer is kind of, 'we have to be the best at routing, so we can deliver results without compromises but do it as efficiently as possible — and we have to be cross-provider.' That's the one thing the frontier labs probably aren't going to do, though we even see a little of that: there's been some direct integration or plug-in relationship between Claude and Codex. But they have to do such a great job of it that they can amortize the cost of that work across all their customers and deliver savings relative to what you'd get on your own — which is hard, given the price discrimination between the API and the subscription level.

   We also have to remember, for enterprise, the 150-seat cutoff Anthropic has is another weird discontinuity in these curves — depending on which side you fall on, you're in a very different world, price-discrimination-wise. But Tasklet and Lindy have both put things out recently. Tasklet's strategy was basically: Claude is the only thing good enough, we're just going to ride Claude and make the best product we can and grow as fast as we can. Lindy had a similar strategy — they had a lot of different models you could use, but Claude was the default for pretty much everything. Both were prioritizing making the thing work even if it was low-margin, or at times negative-margin.

   Lindy has also been, without disclosing numbers, pretty transparent that inference is their biggest cost — so a small swing on inference matters. Tasklet said that when 4.8 started using a new tokenizer that was 30% more tokens, they opted not to move from 4.7 to 4.8 right off the bat, just because that 30% input-token bump was enough to mess with their economics. But, nevertheless, they couldn't compromise on customer experience, so they waited, and built, and built with Claude until they could finally get to the point of diversifying across providers.

   Notably, this has just happened for both of them — Tasklet bringing on other inference providers, leaning into OpenAI most of all; Lindy starting to do open-source inference, but through a really intensive process, with many failures under their belt from previous models they'd thought might be good enough, until finally they found one they had confidence in and launched it — not for all use cases, but enough to meaningfully change their economics.

   So it seems like that's the play — if I'm advising an enterprise, or a 'Red Hat for AI' type company serving enterprise, I'd say the same thing: the frontier models still have the juice. If you're using them ad hoc, you're going to get value, you'll know where the money went. And even if you're structuring things — which is a good goal to have — you probably don't want to rush into structuring them around a much cheaper model, because it's only recently become possible, with a lot of work, to get comparable results. And even once you can do that, who's going to do it best? Probably still the frontier models, more than your own people, in the vast majority of cases. And while you wait, of course, they're doing all this native-routing integration themselves. So I guess I kind of still feel like all roads lead back to Fable, if you're really going for performance.

   If you're not going for performance — if you're really prioritizing risk, or IP — then you have another question on your hands: how long can you hold that position, given that, in addition to Claude for Science, they just announced a whole biomedical initiative? They're going to try to cure rare diseases, which everybody should be excited about, except maybe the pharma companies trying to do highly controlled, structured build-out, while Anthropic is revving tokens at the frontier and potentially coming for you real quick.

   53:58

   Prakash: So, the way I saw it — Flo Crivello's post, as they started to switch into open source, was explicit that they'd spent so much money on Claude, and open source was finally good enough. I think open source being finally good enough is just an artifact of the slowdown the frontier labs have had. If the frontier labs had been allowed to release Mythos-level Fable models back in February, we wouldn't be having this conversation, and the pricing would have dropped.

   I do have an endpoint I think enterprises will eventually look like. A lot of what businesses do is try to standardize in order to reduce cost. If you're an entrepreneur and someone comes into your restaurant and you don't like the look of them, or they're making too much noise, you have the right to just say, I don't like you, please leave. But if you're a McDonald's, you need rules and structure — because if you throw people out and your manager tends to throw out people of a certain kind, that's discriminatory, and it's a problem you'll get sued over and have to fix.

   So, in order to follow the rules and not get into that position, you create a whole level of compliance and structure, and a whole structured workforce and training regime, to get your frontline staff into that consistency zone. All of that kind of melts away with a good AI. If you have a good multiplayer AI that can hold the context of the entire enterprise at once, all the intermediary paperwork and red tape melts away. Your manager at McDonald's could say, 'here's the video of the guy — I don't feel comfortable, am I allowed to kick him out or not?'

   You don't need the training, you don't need any of that — you make a quick call, and the model looks at all the rules and says, is this discriminatory, is there cause, what do we need to document? It could say, take a photo of this and this, and you can proceed. Or: call the cops, don't do it yourself, show them what happened and let them handle it, or engage private security. All of this stuff the enterprise does on a standardized basis can become customized now — the same way your clothing measurements, whether things fit you well, become customized.

   The way your customer-service people talk, the vibe you set in your shop — all of that becomes customizable, because you have a central entity holding the entire context of the business. And once you have that, your people aren't doing paperwork anymore — they're there to make decisions. Your people are there to make the vibe calls and then decisions based on those calls, within whatever set of choices they're allowed to make. So eventually, all this stuff about having different models address different things kind of melts away, because the model itself will allocate its own compute — figuring out how much compute a given task needs.

   When we talk about all these different-sized models, what we're really saying is compute — how much compute should I use to solve this task, and is that deployed via a small model that thinks for longer, or how much thinking time do I give it? All these names — Sonnet, Haiku, low, high — boil down to how much compute you need to solve a task. And the problem of not being able to allocate compute appropriately for the larger model is what all this fragmentation really is.

   The moment the larger model solves that problem — being able to judge how much compute to allocate to a task — all this stuff melts away. Then it's just: who does the task best? If you have a context window large enough for the entire enterprise, you don't have individual instances anymore, no transfer of context or summarization — the model handles all of that, plugs right into your CRM and databases. We're on a path toward that: one model that can decide how much compute to allocate, hold the context of the entire enterprise, talk to individuals within your company, and advise them.

   And be able to drive strategy from the CEO level down, with everyone on the same page at the same time. That's going to happen — we're on that journey. This is why I've been excited about Claude Tag — it's the beginning of that. I've had this vision for a while. Claude Tag has solved multiplayer: independent threads, managing large amounts of shared context. Now it's a question of getting it better and better. They've solved the zero-to-one problem on multiplayer. Now the problem is the one-to-n — and the one-to-n, as Peter Thiel points out, is actually easier than the zero-to-one. The zero-to-one problem is the hard one.

   And I don't think this has been very well recognized, generally. Andrej Karpathy made a post, and people were like, oh look, now he's promoting Slack — one of the greatest AI people in history joins Anthropic, and all of a sudden he's an influencer for SaaS? They really dislike that Anthropic is coming into SaaS, because SaaS is where the easy money for tech people has been — consumer, you get hit on the head a couple times when you're young, then you come out and do SaaS, and it's been stable, and you've been able to make money. Anthropic is coming for all of SaaS right now because all of SaaS melts away as the model becomes the connective tissue of the enterprise.

   All of SaaS melts away. And I think people are still having trouble wrapping their minds around what's going to happen and the pace at which it'll happen. I didn't expect to see Claude Tag so soon — I thought it'd be two or three years from now. Things are actually happening way faster, and Anthropic is downplaying it so much — they put up a tweet and promote it like a SaaS product. How could you? If you solve the one-to-n problem, you could have something like a Claude Tag running the US government. It's the same thing — a singleton that runs for multiple people, has a shared context, keeps threads separate, and follows the rule set. They've crossed the zero-to-one.

   So, yeah — it's good that people are optimizing on smaller models, that's great. But that problem has basically been solved. I think the allocation of compute is almost there, and we're only not seeing it yet because they slowed down a bit due to the regulatory issues. By the end of the year, I think it'll be more evident how powerful this paradigm is going to be.

   1:02:24

   Nathan Labenz: So is there a steelman of the Alex Karp thing? How much of it really centers on trust and IP concerns — the idea that we're all kind of training our own replacements, from the highest levels of humanity training the AIs, down to the individual customer-service rep now babysitting bots? Is there more to the steelman case than that enterprises are worried they're doing that too, training their own future competition — or is that really the heart of what you think he's channeling?

   1:03:10

   Prakash: I think he's actually using the exact same selling point that's always been used by enterprise SaaS — you have to own your own stuff. That's why people had racks on-premise 30, 40 years ago. That's why Amazon created GovCloud. That's why you have all these VPCs. It's the same thing: you have to have your own setup, you can't depend on others — and within that setup, there are vendors who give you that setup. It's why Microsoft has a business — Microsoft was already inside enterprises, banks, and so on, and banks aren't going to move to Gmail. Gmail came along after most banks were founded.

   Banks aren't moving to Gmail. Banks are Microsoft Outlook, Microsoft Teams — that's basically impossible to change. It's the same selling point. The problem is, for industries sheltered by government regulation, they get stuck — banks can't easily migrate to better software vendors, so they get stuck in COBOL, stuck in these old systems. Alex Karp is like IBM now — he's basically trying to sell lock-in to enterprises into these older, inferior products, and it works.

   IBM has had a business for 30, 40 years servicing mainframes while everyone else moved to cloud servers. It can work. The key difference is that AI can also do migration much more easily, so the cost of migrating is lower — so he's got to push the trust angle, because the cost angle isn't going to be enough. But they'll come up with new things — 'you can manage your own singleton inside, and the Claude singleton outside will just come in to do maintenance on your singleton once in a while.' People will find sales strategies around this stuff.

   It's going to be a battle. These firms — the frontier labs — have raised so much money, and there are only two ways: you either eat someone else's lunch, or you create new abundance. And as long as the new abundance seems slow to arrive, they're going to eat someone else's lunch. They're just going to drink the milkshake.

   1:06:02

   Nathan Labenz: Do you think he's right about the attitude? When he says companies don't like the frontier labs and they love Palantir instead — obviously he's talking his own book — but do you think companies really don't like the frontier labs? In some ways, general-purpose intelligence on demand, pay-by-use, would be the ultimate dream for the enterprise, and the adoption has clearly been super strong. Do you think that's true, and if so, why?

   1:06:48

   Prakash: I think a lot of this is driven by where you sit in the food chain. If you have to pay for a product, that upsets you — if you're the Uber CTO and you've run out of budget and have to go back to your CEO for more, that upsets you. Enterprises don't like the cost, that's clear. But they're being forced into it, by competition, by AI-forward CEOs — and they dislike that the change is coming at all, that's the real fact.

   Palantir, by contrast, has a very clear value proposition when they go in: this is what we're going to do, this is how much it'll cost, this is how much money you'll make or save. They'll tell you they'll help prevent fraud and by how much your fraud rate will drop. So up front, you know how much you're going to pay before you engage Palantir — you don't get sticker shock. The problem for the labs is that people get sticker shock because they implement, then pay per token, and the token cost explodes — you have to change your budget for the year mid-year. That's not a happy thing for any enterprise CTO or CEO.

   The frontier labs are also horrible at sales. Look at IBM — something like 70% of their staff are sales engineers, there to help you implement, maintain, do the grunt work. The labs aren't doing that. Anthropic especially has decided on a very lean structure — almost no people, just put out the models and tell enterprise teams, here, use it or don't. The CTO signing nine-figure deals at Uber isn't going to get sales calls and hand-holding. That level of customer service isn't being provided by the frontier labs, and they're not positioned to provide it.

   That's why they started the whole FTE program. People thought it was a sales-engineers program — it's actually a program to extract data and workflows and implement them inside the models themselves. That's what Alex Karp is really alluding to: the FTEs come in, and they're not there to help you, they're absorbing your workflows, and once they've absorbed them, you won't have a business, because it'll be retaken. And it's true — we spoke to two of Anthropic's FTEs, and they went into a company Thrive owned rather than an external company, took apart the workflow, and are basically absorbing it, with the intention to absorb more in the next round.

   So that's where enterprises are upset about costs — they don't like paying, they don't like sticker shock, and I think that's why they're annoyed. This whole open-source-model conversation is really about the sticker shock. These are all negotiating positions: open-source models help enterprises negotiate against OpenAI, and help CEOs negotiate against their own CTOs. A CTO wants budget — 'use GLM-5.2' — so the CEO has to decide, do I let them use GLM-5.2, or put token-spend limits on the engineers? They're trying to get the costing back into a proper bound and hoping it doesn't blow up again.

   If the Uber CTO can say, 'I've got $3 billion allocated to AI, and we'll use Anthropic — but if it's too expensive, switch over to GLM-5.2' — that's the play: switch if it's good enough, but maintain the cost within that bracket, don't let it push out. And the model companies will negotiate to take that spend — they have something like a 90% margin, so they'll negotiate their pricing to capture 80-90% of whatever budget's been allocated. That's happening right now.

   1:12:00

   Nathan Labenz: Overall, I feel like this comes down to political economy. It's just hard to imagine American business broadly — probably the most dynamic business culture in the world, though China might like a word — navigating all of this, even something as simple and fundamental as annual budgeting, working all that well anymore, I'm afraid. In a laissez-faire market, I'd bet on the big-tech singularity ultimately winning over a lot of legacy companies stuck in those processes, even the ones really trying.

   The question then might be, are these companies even allowed to enter new markets? Which connects to the equity-sharing proposals we've talked about a little, which seem to be getting more real. In a way, some form of equity sharing — where everybody gets an account to watch their slice of the AI pie — could be the most genius move the frontier companies ever make, from a purely selfish standpoint. Right now, apparently, we're talking about 5% of OpenAI being given to somebody — the federal government, households, something else. I don't think we have clarity on that yet. Will it be liquid? That's another interesting question.

   The precedent for just handing out shares — from what I understand of the post-Soviet world — didn't work super well; markets got cornered, and people didn't really realize what they had. There are a lot of practical implementation questions. But 5% — even 50% — could look small relative to the binary question of whether these companies are going to be allowed to enter new markets and compete directly across a vast array of markets against all their current customers.

   If they're allowed to do that, it probably more than doubles their valuation versus if they're not. My gut says: give away half the company to the public, if you're them, so everybody has a little ticker to watch and is cheering for you — and then you'll probably be allowed to go do these things. Like Amazon, you'd probably also end up really well-loved at the consumer level.

   Amazon, despite the hate in certain corners, has a favorable-brand rating that's super high — I think the last number I saw was in the seventies, maybe even 80%. Why so high? They do what people want: great selection, fast delivery, all the things Bezos says will never change, great prices. Yes, they're squeezing people left and right — they look into their small-business marketplace, find hot sellers, clone the products, sell them for half or less.

   There's a whole Lina Khan school of thought that says this shouldn't be allowed — it's an abuse of power, hollowing out small-business culture by undercutting sellers so dramatically off a data and visibility advantage they don't even need to make margin on. Should this be allowed or not? The public broadly comes down, time and again, on: I want the best stuff for the cheapest and fastest. Small-business owners pay lip service to supporting small business philosophically, but aren't willing to pay twice as much on an ongoing basis for products Amazon would sell them directly for half.

   Now take that to the enterprise level: Anthropic comes in and potentially revolutionizes drug development — still somewhat speculative, obviously — and it's not good for Eli Lilly. I don't think anybody cares, especially if they have a little slice of Anthropic they can watch tick up over time.

   1:18:08

   Prakash: Yeah — so speaking of that, Anthropic and Micron have taken stakes in each other, and Anthropic is cooperating with Micron. That's actually happening. Anthropic needs memory, wants to co-design the memory because they don't have that capability themselves, but they also can't compete head-to-head with Micron — Micron has all the manufacturing. So they're a buyer, strategically partnering with Micron to design the memory and the chips, and Micron takes a stake in Anthropic. There's cross-share ownership.

   I don't know to what extent Anthropic will ever — I think the pharma thing is a bit more difficult, because Dario's view in Machines of Loving Grace was an AI that can do the entire pharma research process end-to-end, from idea generation through clinical trials. It's very difficult for them to just offer API access to, say, Eli Lilly, and have Eli Lilly be able to implement it, because it's hard to design the right workflows if you don't know what the AI is capable of.

   I've thought for a while that this will happen — my expectation was that Anthropic would IPO, and a bunch of people would leave to found companies attacking each of these markets separately. I don't think non-AI-native companies can move that quickly; I'd expect the AI-native companies to be the ones. There are a few ways this could play out. One is acquisitions — Anthropic might buy Slack, or Salesforce.

   They really like Slack — Claude Tag has launched in Slack, and they clearly want to make it their central platform. If Anthropic's at a couple-trillion valuation and Salesforce is at a couple hundred billion, there could be a deal: pay $100 billion and take Slack. Salesforce gets $100 billion in cash, stays as the CRM system of record, and Slack goes to Anthropic. You'd start to see this kind of deal — taking over key strategic assets — rather than buying shares in Anthropic directly.

   They'd pay you for the asset, and you could use those funds to buy shares in them if you wanted — they're happy to have you as a shareholder, it's just not a special stake, the shares are just available. If Anthropic wanted to enter, say, logistics, and needed physical facilities, they'd have to buy them — and the people who exit that way can then choose to buy shares in Anthropic or do something else with the cash. That's different from when OpenAI gives shares directly to people — those people can't sell them and buy something else, they're limited.

   That's actually less valuable than owning the stock outright and being able to sell it and buy something else — that option of choice is worth something. But a lot of people who'd get these shares won't understand their value — they won't understand that superintelligence might be more valuable than anything else on Earth in ten years, and they'd sell early. Same thing that happened with Bitcoin — people sold early, not understanding what it would become.

   So with our existing commercial structures — pure acquisitions, without any of the offering-shares-to-the-government stuff — you can resolve all of this. I think offering shares to the government is really a political move, to diffuse things. What Sam is doing is essentially: we can either have the Democrats come into power and take it away from us forcibly, or we can give it voluntarily and set our own terms for how ownership is structured.

   The 5% is obviously a starting stake — if Bernie Sanders wants to push for 20%, I'm sure Sam would go to 20. But after that, what can Bernie Sanders really do? The state already has a stake in the firm — what else do you want? That's the question I think the Bernie Sanders wing can't really answer, because what they actually want is to freeze progress — to freeze wages, rents, the value of what people who already have homes and jobs currently hold, so things don't get more expensive for them and don't get taken away.

   The way they'd go about it is, I'm going to take your money, but here, I'll give some back — and then what happens? They don't really know, because you can't just stop progress. That's created a political conundrum for the left, and Sam knows the left is probably going to have more power come November, so people are placing their bets now. I saw, for instance, Karlie Kloss — Jared Kushner's brother's wife — in an interview saying she's a Democrat, that she's never met President Trump, that they live in St. Louis and are unaffiliated with all of that.

   The reasoning is that as more comes out about the Trump-crypto stuff — billions of dollars — there are a lot of Democratic lawyers sitting around collecting evidence in DC right now, and the winds will change. Trump plans to pardon a bunch of people, but the proceeds are already under scrutiny, and as those get used for other things, they'll find ways to put people in prison. There's a guy, Tanner Greer, who goes by Scholar Stage on Twitter — a right-wing lawyer, but not a Trump-y one — who's basically said, I told you guys not to do this, and when the Democrats come into power, hundreds of people are going to go to prison.

   That's where things are right now — Sam's getting ready, and everyone's getting ready, because the winds are going to change. Trump can pardon a bunch of people, but he's not going to pardon, say, analyst number two on some investment bank's trading desk. What the Democratic lawyers did in the Clinton years was go after the smaller people — the big guys get away, but it inflicts a level of fear on the staffers that makes them very aware. Trump isn't going to pardon ten million people; there are thousands of Republican influencers and right-wing people, and it's all being tracked. Is he going to pardon Tim Pool, who took money from the Russians? I don't know.

   So there's a lot of this happening in the background that people are getting ready for. Sam has played his cards well — the 5% looks good to Republicans and to Democrats, and it diffuses the situation. If you've discovered an ASI, this is an infinite money pool anyway — why care if it's 5%? Give up 20%, 25%, become a tax-free company, give up 49% ownership, whatever. It's a very odd situation, because the infinity number on future proceeds makes all the numbers wonky. And Sam is a good player — excellent, really.

   What does Elon do now — does he offer a 5% stake? What does Dario do — 5%, 10%? What about Mark Zuckerberg — he's already public, he's not going to give you a 5% stake. It's genius, politically — absolutely genius. So, I don't know — how do you feel about the politics and the appearance of this right now, given Sam has clearly made this a political move?

   1:28:36

   Nathan Labenz: Well, I was just reading commentary from Dean Ball, friend of the show, this morning — he officially starts at OpenAI on Monday. He said he's not talking with Sam or anyone at OpenAI about this yet, so this is just his own view — which is also a good sign that he'll hopefully be free to speak his mind even once he takes the role. He basically said he thinks it's viable, maybe even a good idea, if ownership goes to households, and a terrible idea if it goes to the government.

   That resonates with me. I don't like the idea of the federal government picking winners between one company and another. I think we still risk a lot of those dynamics even with broad distribution to households, but it seems like it'd be a lot worse if the government were a direct stakeholder — especially if the government then becomes dependent on this asset as a backstop or collateral for its borrowing, and we run that up even further.

   We're already in a world where the stock market basically can't go down without real problems, but you can imagine that starting to threaten something bigger. We're still in a world where the government can be the bailout, the equity investor of last resort, when needed. I don't think we want to cross that third rail of intermingling the government's balance sheet with these companies to the point where it can no longer play that role, because it's already partway down that same path.

   So I'm probably a less sophisticated thinker on this than someone like Dean, but I do think the household-distribution idea sounds a lot better. I do have big questions, though, about how this squares with OpenAI's mission — how does putting it all in the hands of 5% of people benefit all humanity? Would they have to bundle this with something like a universal basic compute commitment?

   They've done something like that with medical — they made their latest medical experience free and unlimited globally, so they're making moves in that direction. But it's going to be a tough sell to the other 95% of humanity to say only Americans get any of the upside — especially since all the same concerns we've talked about for American companies, like with Europe 2031, probably apply even more to companies around the rest of the world.

   1:32:24

   Prakash: I've always thought the whole 'we're going to benefit all of humanity' framing from the labs never quite worked for me — I just don't think it's really possible to execute that in the US. So I've always been like, okay, sure, that's what you say, I'll take your word for it, but I don't really believe you. I don't think it's really feasible for them to do. Let me segue here — we have with us —

2. 1:33:19Interview52 min

   Interview: Kunle Olukotun — SambaNova Dataflow Inference and Surviving the Alt-Silicon ShakeoutKunle OlukotunKunle Olukotun — co-founder & Chief Technologist of SambaNova, Stanford's Cadence Design Systems Professor and a father of the multicore processor — joined for the architect's-seat conversation on whether reconfigurable-dataflow silicon (the RDU) finally wins the economics of reasoning-model and agentic inference. The through-line: why mapping a model's dataflow graph onto silicon beats streaming instructions through fixed GPU cores, the SN40L three-tier-memory bet, and the Composition-of-Experts thesis (many specialized models resident on one system, which the newly announced SN50 is purpose-built for). Nathan pushed the contested economics against a brutally consolidated 2026 field — Nvidia bought Groq for ~$20B, Cerebras IPO'd at ~$66B, and Intel took a Series E stake in SambaNova's down round after reportedly exploring an outright acquisition — and pressed on recency: SambaNova's DeepSeek-R1 671B speed record (~198 tokens/sec/user on 16 SN40L RDUs), verified by Artificial Analysis in February 2025, is now ~17 months old, so the live question is where custom silicon durably wins on cost-per-useful-token and whether the independent inference-chip bet ends in absorption or independence.

   Watch

   ▶Play this segmentYouTube · from 1:33:19

   As aired

   Kunle Olukotun joined AI:AM to talk dataflow inference at SambaNova, the company he co-founded in 2017 with Chris Ré. Prakash introduced him with his academic pedigree — the Stanford Hydra project that helped establish the modern multicore processor in the late 1990s — before framing the segment around SambaNova's Reconfigurable Dataflow Unit (RDU), the recent SN50 chip launch, an architecture partnership with Intel, an enterprise rollout with Vista Equity Partners, and reports of a roughly $10 billion valuation target.

   The core of the conversation was Kunle's case that inference, unlike training, is not a compute problem but a data-movement problem: moving model weights and the KV cache from memory to compute units, and between chips. He argued GPUs typically use only 10 to 20% of their peak memory bandwidth and communication resources, whereas SambaNova's RDU architecture targets 70 to 80% of peak — a 5 to 10x improvement — by fusing decode into a single kernel ('kernel looping') and routing chip-to-chip communication through SRAM rather than HBM, so communication becomes just another overlapped pipeline stage instead of a synchronization bottleneck. He framed the commercial goal as producing 'premium tokens' — output from large, accurate models delivered at high speed, which he sees as the currency of the agentic-AI era.

   Nathan pushed Kunle to taxonomize the broader chip landscape — Cerebras, Groq, GPUs, and dataflow — across three axes: flexibility versus specialization, which tier of memory a design leans on, and whether communication is orchestrated by software or by hardware. Kunle argued reconfigurable dataflow sits in the sweet spot: flexible enough to adapt across model architectures (he was explicit about not wanting to burn any single algorithm, including today's transformers, permanently into silicon), while using hardware-driven pipelining to overlap computation and communication in a way GPUs — and, in his view, SRAM-only rivals like Cerebras and Groq — cannot.

   The discussion also covered concrete trade-offs: SambaNova's SN40 could match GPU throughput at 3 to 5x higher speed, while the newer SN50 trades some raw compute for the ability to scale tensor parallelism far wider, winning past roughly 250–500 tokens/second/user; disaggregated GPU-plus-RDU deployments (GPUs for prefill, RDUs for decode); and how SambaNova builds its own compiler around a PyTorch-level dataflow representation to avoid CUDA entirely. Kunle laid out a roadmap built on an 18-month chip cadence, closing the HBM generation gap with Nvidia, and continuing to bet on architectural flexibility as models evolve toward state-space and other more linear approaches.

   The segment was repeatedly interrupted by audio and connectivity problems, costing several minutes of live troubleshooting. In the closing stretch, Nathan asked what would ultimately gate SambaNova's ability to scale — echoing the recurring 'what is Nvidia's moat' question — but the connection dropped again before Kunle could answer fully. Prakash filled the gap with his own read: SambaNova's chairman is Intel's Lip-Bu Tan, tying the company to Intel Foundry capacity, while Nvidia appears to be sidestepping antitrust exposure by funding new manufacturing capacity (such as a glass-optics factory with Corning) rather than simply buying up existing supply, and smaller chip startups typically access fab capacity by paying Broadcom or Qualcomm for a cut of their allocated wafer slots at TSMC.

   Key moments

   If you do it right, you can get a 5 to 10x improvement over where GPUs are today.

   Premium tokens are tokens that you can charge the most money for because they are premium. Why are they premium? Because they come from very large models, so they're accurate, but they're also provided to you at high speed.

   I've learned never to bet against the innovation capabilities of software people and algorithm people.

   Questions asked

   1:36:24Can you tell us how SambaNova's paradigm addresses the issues with GPUs and brings down the total cost of ownership for enterprises?

   SambaNova, founded in 2017 with Chris Ré, designed from scratch an architecture optimized for inference rather than training. GPUs were built for graphics and HPC and are matrix-multiplication/compute-optimized, but inference is a data-movement problem — moving weights and the KV cache from memory to compute units and between chips. SambaNova's focus is minimizing communication overhead and maximizing memory-hierarchy utilization, yielding a 5-10x improvement over today's GPUs.

   1:42:15Chip users often focus on model FLOPS utilization (MFU) — is that SambaNova's North Star, or are other metrics more important?

   The real 'speed of light' for high-speed inference is memory bandwidth utilization, not FLOPS. In the agentic-AI era, the goal is 'premium tokens' — accurate output from large models delivered fast — which is bottlenecked by moving the KV cache and parameters from HBM to compute, not by floating-point throughput; most inference workloads are memory- or communication-bound rather than compute-bound.

   1:44:48Can you taxonomize the whole chip space — Cerebras, transformer-burned-into-silicon approaches, and so on — the strengths and weaknesses of each strategy, and whether there are 'cliffs' where a paradigm stops working as models scale?

   Three axes: flexibility versus specialization (CPU/GPU instruction-driven flexibility versus burning a fixed algorithm into silicon, which breaks if the algorithm changes — he's wary of over-fixing given how fast ML algorithms evolve); which memory tier a design leans on (on-chip SRAM vs. off-chip HBM vs. terabytes of flash/DDR); and how memory transfers and communication are managed (software/instruction-driven vs. hardware). Reconfigurable dataflow hits the sweet spot: flexible at the timescale that matters for AI (per inference session, not per cycle), while using hardware-level pipelining to overlap communication and computation — the key advantage over GPUs, which synchronize data movement in software and add overhead.

   1:53:46Can you contextualize the HBM difference for a model like Llama 3 on an H100/B200 versus an RDU?

   It's not a capacity question, it's a bandwidth-efficiency question. GPUs waste HBM bandwidth two ways: executing the decode algorithm one kernel at a time (moving intermediate data to HBM and back between kernels) and losing time to kernel-launch/synchronization overhead. SambaNova fuses the whole decoder into a single kernel ('kernel looping') and communicates cross-chip results via SRAM-to-SRAM transfers that bypass HBM entirely, keeping HBM continuously and efficiently utilized — this is also what lets SambaNova scale tensor parallelism far wider than GPUs, which struggle beyond 4- to 8-way.

   2:02:30What trade-offs ('bullets') does this architecture require you to accept, and how does your Pareto frontier — throughput versus speed-per-user — compare to GPUs? Who's the sweet-spot customer?

   On the previous-generation SN40, SambaNova matched GPU throughput at 3-5x higher speed; SN50 has less raw compute, so GPUs still win at very large batch sizes, but past roughly 250-500 tokens/second/user SambaNova is 3-5x better than GPUs — the sweet spot for frontier labs and neoclouds serving 'premium tokens' on open-source models (e.g., 5-10x faster serving of MiniMax models via SN40). SambaNova also supports disaggregated GPU-plus-RDU deployments — GPUs handle prefill (more raw compute), RDUs handle decode — at ratios like one or two GPUs per RDU.

   2:12:43What have you seen using AI within your own design and software process, and what does the roadmap look like on a three-to-five-year mark for the firm?

   SambaNova uses a mix of open-source and frontier-lab models internally to manage token cost, running models efficiently on its own hardware and escalating to frontier models for the hardest tasks. On tooling, they never adopted CUDA — they built their compiler around a PyTorch-level dataflow representation, so developers describe parallelism (tensor/data/pipeline) at a high level and the compiler maps it to hardware. Roadmap: continue an ~18-month chip cadence (five or six chips taped out over seven years), close the HBM-generation gap with NVIDIA (currently HBM2e versus NVIDIA's HBM3), adopt 3D packaging and chiplets, and keep architectural flexibility as models evolve toward new transformer variants and more linear, state-space-style approaches — with SN50 shipped and SN60 next.

   2:20:15If SambaNova achieves all its design goals, what becomes the barrier to scaling up — is NVIDIA's moat really supply-chain lockup via balance-sheet dominance, and how is a company like SambaNova, aiming to be the next decacorn, getting the capacity to ship on a meaningful timescale?

   Kunle didn't get to answer directly before the connection dropped again; Prakash answered instead: SambaNova's chairman is Intel's Lip-Bu Tan, so SambaNova will fab through Intel Foundry, which needs customers and has also invested in SambaNova. On NVIDIA, Jensen is under antitrust scrutiny and appears to be responding by funding new capacity (e.g., co-funding a glass-optics factory with Corning) rather than simply buying up existing capacity, which is harder to challenge legally. Smaller chip startups typically get capacity through Broadcom or Qualcomm, who hold swing allocation at TSMC and take a cut for granting access — that's largely how smaller players have secured fab capacity over the past year.

   Related

   SambaNova Systems ↗SambaNova on X (@SambaNovaAI) ↗Kunle Olukotun on LinkedIn ↗SambaNova Cloud launches the fastest DeepSeek-R1 671B (Feb 2025) ↗Kunle Olukotun on TWIML — Dataflow Computing for AI Inference (Oct 2025) ↗

   Full transcriptLightly edited · timestamps jump to YouTube

   1:33:19

   Prakash: Our first guest of this morning — we have Kunle Olukotun. He's the Cadence Design Systems Professor of Electrical Engineering and Computer Science at Stanford University. But to the hardware engineering world, he's widely recognized as the father of the multicore processor. In the late 1990s, his Stanford Hydra project proved that the future of computing was not about making a single processor run faster, but about putting multiple processors on a single chip to handle many tasks at once — a fundamental design that powers almost every server, laptop, and mobile device we use today.

   Today he serves as co-founder and Chief Technologist at SambaNova Systems, a company that has completely rethought how artificial intelligence processes are built. Instead of relying on traditional graphics processing units — GPUs — which constantly shuffle data back and forth to memory, his team developed the Reconfigurable Dataflow Unit: a chip designed to stream data continuously, like an assembly line. This approach drastically cuts down the time and energy required to generate AI responses, specifically for complex, multistep, autonomous AI agents.

   He joins us at a critical moment for the AI industry. Over the past few months, SambaNova has launched its massive SN50 processor, announced a groundbreaking architecture partnership with Intel to split AI workloads across specialized chips, and secured a massive enterprise rollout with Vista Equity Partners. With reports circulating this week that SambaNova is targeting a staggering $10 billion valuation, Kunle is here to explain why the era of using one giant GPU for everything is coming to an end, and how dataflow architecture is making highly advanced AI practical and profitable for the enterprise. Hi, Kunle — welcome to the show.

   1:35:35

   Kunle Olukotun: Hi, Prakash. Thank you for having me. Hi, Nathan.

   1:35:39

   Nathan Labenz: Hi. Great to meet you — quick check, did we say your name right?

   1:35:44

   Kunle Olukotun: I think you cut out for some reason.

   1:35:46

   Prakash: Did we get your name correct?

   1:35:50

   Kunle Olukotun: Yeah, yeah — my name's just spelled phonetically, so you pronounce every letter, and you got it right.

   1:35:56

   Nathan Labenz: Amazing. Prakash, you take it — I'll refresh and come right back.

   1:36:00

   Prakash: Okay, so Kunle — this is, I think, a critical moment in the chip industry, because everyone is complaining about GPU prices, especially our friend Jensen Huang, NVIDIA's power and influence on the market, and the profit margins of NVIDIA.

   1:36:23

   Kunle Olukotun: Right.

   1:36:24

   Prakash: And can you tell us a little bit about how SambaNova has this different paradigm that addresses the issues with GPUs and brings down the total cost of ownership for enterprises?

   1:36:43

   Kunle Olukotun: Yeah, so SambaNova was founded in 2017, and it came out of ideas from Chris Ré, my co-founder — he's also a professor at Stanford, and a certified genius. The idea was: if you could bring software and algorithm ideas together with hardware architecture ideas — and as you said in your introduction, I've been working in the hardware architecture space for a long time — starting from a clean slate, how would you design an architecture that's optimized specifically for inference?

   Everybody thinks about GPUs as a kind of general-purpose computing substrate, but originally they were designed for graphics, and then they made a foray into high-performance computing. For high-performance computing, of course, you need a lot of matrix calculation capability, and at some point people realized you could use these things for executing machine learning models — the core of machine learning, and of course AI, is matrix multiplication.

   But when you want to train a model, clearly the core of the problem is how quickly you can do very, very large matrix multiplications. So what happened over time is GPUs put more and more of their silicon area into making bulk matrix multiplication better, using tensor cores. But once you've trained the model, you now need to use that model — that's the inference problem. And the inference problem is not really a compute problem, because as models get bigger, you now need to move the weights and what we call the KV cache into the compute units. That is essentially a data movement problem — a data movement problem from memory to the compute units, and a data movement problem between chip compute units. And, of course, you need to scale to multiple chips to handle the computational requirements, especially for very low-latency, high-speed inference.

   So our focus was: how do you design an architecture that minimizes the overhead of communication, and makes sure you most efficiently use the core resource in the system, which is memory? And memory isn't just one thing — it's a hierarchy of memories. The key is how you orchestrate that hierarchy, how you orchestrate the communication, such that you keep everything as efficiently utilized as possible. And if you do it right, you can get a 5 to 10x improvement over where GPUs are today.

   1:40:17

   Prakash: It strikes me that NVIDIA's solution around this has just been to increase the bandwidth — through NVLink, advanced HBM integration, and software optimizations like TensorRT-LLM and vLLM. So are they actually trying to brute-force their way into this?

   1:40:40

   Kunle Olukotun: Yeah — you definitely want to keep getting peak improvements on HBM bandwidth and chip-to-chip communication by using the latest technology. But the key is how effectively you use that bandwidth, how effectively you use that communication, and making sure you don't waste it. Whereas GPUs are often running at maybe 10 to 20% of the capability of their resources — the memory bandwidth and the communication resources — our goal in a SambaNova system is to push that to 70 to 80% of peak. So yes, everybody wants more capability from the underlying resources, but the key is keeping those resources as effectively used as possible. And that gives you more benefit for the cost you spend on providing higher memory bandwidth with the latest HBM, higher signaling frequencies, and communication bandwidth between chips using the latest variety of NVLink and so on.

   1:42:15

   Prakash: For a lot of the chip users, they often focus on this number — the model FLOPS utilization, the MFU. What's your North Star as you're designing the chip? Is that the strongest consideration, or are there other metrics you focus on?

   1:42:34

   Kunle Olukotun: No — the speed of light for doing inference, especially high-speed inference, is really the key thing. Everybody knows we're in the agentic AI era, and what one wants is what we call premium tokens. Premium tokens are tokens you can charge the most money for, because they're premium — they come from very large models, so they're accurate, but they're also delivered at high speed, so they're useful for an agentic environment that needs many turns through the models, and potentially has multiple models interacting.

   So the question is, how do you provide those premium tokens? You provide them by having very fast inference, and that's not going to be limited by floating point — it's going to be limited by moving the KV cache and the parameters from HBM memory to the compute chip. We like to think of this as memory bandwidth utilization. The speed of light is one — you use your memory bandwidth completely for one thing, or maybe two: moving the KV cache, and moving the parameters from HBM to the compute unit, every time you generate a token.

   In fact, in many instances you're underutilizing the FLOPS on the GPU or the compute unit, because you're running a memory-bound problem. Most of the problems one runs on GPUs, especially inference, are not compute-bound — they're memory-bound, or memory- and communication-bound.

   1:44:48

   Nathan Labenz: Could we zoom out and have you taxonomize the whole chip space? I know it's a big question, but people are familiar with things like Cerebras, which has this giant chip with a ton of memory on it. We've also seen instances of people burning the transformer architecture directly into silicon, with varying degrees of flexibility remaining as they pursue that strategy. I'm curious how you see the menu of different strategies — the different bets people are making — and the strengths and weaknesses of each.

   When you talk about the KV cache, for example — maybe we're in a world where we just keep pushing attention forever, and it always has to be dense at least at some layers, so that's a persistent bottleneck all the way to the singularity. Or maybe we're in a world where somebody figures out a state space model approach, and we move to a more linear paradigm where the KV cache isn't the constraint it is today. There are a lot of different directions this could go, but I'm really interested in your high-level map of the strategies people are pursuing, and what would tip you to think 'this pays off in this world' versus 'this pays off in that world.' Are there cliffs — places where, if models hit a certain size, a certain paradigm just stops working?

   1:46:45

   Kunle Olukotun: Yeah, that's a really interesting question — I think you can think about it along three different axes.

   One axis is flexibility versus specialization. Extreme flexibility might be something like a CPU, or to some extent a GPU — an instruction-driven execution engine. That's pretty flexible, but you always pay overhead for executing instructions, in terms of both silicon area and time. On the other extreme would be something very specialized for a specific algorithm — if that algorithm changed in any way, the silicon would no longer be useful. Fixing your architecture to transformers and burning your weights into the design would be an extreme case of that. But I've learned never to bet against the innovation capabilities of software and algorithm people — even over the time I've been looking at ML and AI, there's been tremendous change in algorithms. We're kind of fixated on transformers now, but transformers aren't just one thing — you've got various types of transformers, state space techniques, different ways of doing attention. So I'd be very wary of fixing any particular algorithm into architecture, because then you can't innovate.

   Another axis is what kind of memory you use. You've got very fast SRAM on-chip — probably half a gigabyte — you've got hundreds of gigabytes, or tens of gigabytes, of HBM off-chip, and then you've got terabytes of either flash or DDR. That's the memory access axis. And a third axis would be how you manage the memory transfers and communication — do you do it with instructions, making it very flexible, or do you do it completely in hardware?

   The way I like to think about dataflow is that it gets you into the sweet spot — especially reconfigurable dataflow — because it allows you to be flexible, but on the time scale that makes sense for AI models. You're not changing things every cycle; you basically fix the model for the duration of the inference. When another prompt comes along you may switch models, but typically you're going to fix that model on the machine for a while. So you don't have to be completely flexible, but you should be able to change the model and optimize for it. Reconfigurability gives you that capability.

   Now, on the memory access side: think about the size of the models — you need trillions of parameters. If you limit yourself to the memory you can fit on a single chip or a wafer, you're limited to maybe 40 or 50 gigabytes — half a gigabyte for a single chip, 40 to 50 gigabytes for a wafer. But a trillion-parameter model needs a lot more than that. So what you really want is to put the model in HBM, but use that HBM as effectively as possible — which you do with hardware mechanisms for moving data from memory to the chip and between compute chips. The idea is: how can you be completely flexible with very, very low overhead, almost none? The problem with GPUs is that they do use HBM and can run large models, but they synchronize the data movement and communication between chips all in software, which adds overhead — and that means they have a lot of trouble overlapping computation and communication.

   That overlap is, in fact, the key. You don't want to communicate by waiting until you need to, then running instructions to move the data — you want to construct a pipeline where communication is just one component. In dataflow execution, communication is happening all the time; it's just one of the pipeline stages, happening for one piece of the model's computation while computation for another piece happens in some other stage of the pipeline. It's a classic idea from computer architecture — pipelining, and using a memory hierarchy to move data where you need it, when you need it. The nice thing about AI models is that you have a graph of computation, and the whole idea of dataflow is to take that graph and map it onto the machine spatially, so you keep all the pieces of the model operating at the same time, on different components of the computation.

   1:53:46

   Prakash: Can you contextualize a little bit? Let's say you have a Llama 3 model, and you have a normal NVIDIA H100 or B200 chip versus an RDU chip — what's the difference in the amount of HBM required? Is there a sense of, like, you'd say, 'okay, this—'

   1:54:10

   Kunle Olukotun: It's not really a capacity question — it's really a bandwidth question. There are two ways the GPU uses bandwidth in ways that aren't optimized. One is that they divide the decode algorithm — to decode a single token, you've got multiple steps of the decoder. Take one step of the decoder and think about all the kernels that have to execute to run that decode step.

   The way the GPU typically does it is to execute the decode algorithm one kernel at a time. There are some big kernels, like flash attention, that have been optimized, but in general there are multiple kernels, and two overheads happen. One is that you have to move data from the GPU's registers, from one kernel, to HBM, and then the next kernel has to go fetch that data back into the GPU. That's wasted HBM bandwidth.

   1:55:38

   Prakash: Right.

   1:55:39

   Kunle Olukotun: The other aspect is that you spend time launching that kernel and synchronizing between the two kernels — time when HBM isn't actively being used. So you're wasting bandwidth you shouldn't waste, and you're not fully utilizing HBM during that time either. The way things work on an RDU, in dataflow, is you take the decoder and make it a single kernel. Then you go further, with a technique we've developed called kernel looping — because you've got a single kernel, and, thinking about Llama 3 70B, for instance, you have to run that decoder 32 times. You keep that single kernel decoder resident on the array of chips the whole time and just keep looping. The net result is you keep the HBM completely occupied.

   1:56:48

   Prakash: Right.

   1:56:49

   Kunle Olukotun: And you never send any intermediate data between the kernels across the GPU-or-RDU-to-HBM boundary. So you get both a more efficient use of the HBM bandwidth and a more complete use of that bandwidth. But we're not done yet, because the key innovation I alluded to earlier is that, since you're running across multiple chips using what we call tensor-level parallelism, at some point you need to gather all those results together — in an all-reduce.

   1:57:25

   Prakash: Mhmm.

   1:57:26

   Kunle Olukotun: That's communication, and you don't want that communication to be something that stops the pipeline. What we're able to do is communicate from one RDU chip's SRAM to another RDU chip's SRAM without going through HBM — we terminate the communication inside the SRAM. So we don't use HBM bandwidth for that, and more importantly, it means we can treat the communication as just another pipeline stage that overlaps with all the other kernel components of the decode algorithm.

   That gets us this more effective use of HBM bandwidth — we keep the HBM running, utilized all the time, which is that metric we talked about, memory bandwidth utilization. This is how we push it as close as possible to one: we only move the data we absolutely have to move from HBM — the KV cache and the parameters of the model — and make sure that interface is used close to 100% of the time.

   Going back to why we can do this extreme fusion into a single kernel: it's because we have more SRAM on the chip. You could say, well, I'll put everything on SRAM — the intermediate data between kernels, and also the KV cache and parameters — but if you only use SRAM, you end up with a very expensive system. So the key idea is to build a system that's scalable. With our latest version, the SN50, you can scale all the way to 32,000 chips if necessary — in scale-out and scale-up, we can go to hundreds of chips. That gives you the ability to run these large models very cost-effectively, while also getting very high-speed decode by using dataflow to effectively exploit tensor parallelism. One of the limits of GPUs is that, because they don't effectively overlap communication and computation, they have a hard time using tensor parallelism beyond 4- or 8-way. We can go to much wider levels, which means we get higher-speed token generation.

   2:00:44

   Nathan Labenz: This has been fantastic.

   2:00:45

   Kunle Olukotun: To your question, Nathan — if you think about where the different architectures sit: GPUs are, in terms of flexibility, highly flexible — they're instruction-driven — but their overheads mean they're limited by that instruction overhead. They do have the advantage of using HBM capacity to run very large models.

   If you're thinking about Groq and Cerebras, they're SRAM-based, so they can't very cost-effectively handle very large models — once you get to trillion-parameter scale, it's unclear how you gang enough systems together to handle models that size. And they might claim to be dataflow, but I'd say they're not quite dataflow, because they still involve instruction overhead in synchronization and orchestration. The key to dataflow is to hide all the overhead of communication by putting that synchronization and orchestration in hardware — and that's what we do in the RDU design at SambaNova.

   2:02:30

   Nathan Labenz: We're at the time we had booked — do you have time for a couple more questions? Great. Could you talk a little about what bullets you have to bite with this architecture? You alluded to at least one, on not targeting the training market. Curious if there are other big trade-offs you're accepting. And I'm also curious how this translates to the Pareto frontier for your customers — we see the emergence of 'fast mode,' and there's clearly a trade-off between speed of response and batch size, which obviously translates to cost. Could you characterize how the Pareto curve you offer customers compares to other Pareto frontiers, in terms of volume-versus-speed trade-offs? And what kind of customer is the sweet spot for you — someone who needs more of one or the other, versus the hardware we're more familiar with?

   2:03:55

   Kunle Olukotun: Can you say that last bit just again?

   2:03:58

   Nathan Labenz: Yeah — with the idea in mind that there are these trade-offs, and probably the trade-offs with a SambaNova system are different from other available systems one could buy, what does that translate to in terms of the most natural customers for you?

   2:04:13

   Kunle Olukotun: Yeah, that's a really good question. Everybody's seen the Pareto curve Jensen put out — the trade-off between throughput on the y-axis and speed-per-user on the x-axis. What we see is that on our previous generation, like SN40, we could match GPU throughput at 3 to 5x higher speed. On the SN50, we don't have quite as much raw compute, so at very, very large batch sizes GPUs do very well. But once you get over 250 into the 500-tokens-per-second-per-user range, we can achieve those speeds at throughputs 3 to 5x better than what a GPU can provide. So if you're a frontier lab or a neocloud that wants to provide premium tokens — especially serving open-source models — that's the sweet spot. If you look at a MiniMax coding model, for example, going through our service you can get speeds 5 to 10x faster on MiniMax 2.7 compared to other providers, because it's powered by our SN40 capability, our previous generation. SN50 provides even more, because it can scale to a much larger number of chips using the techniques I described.

   So going back to the premium-token idea — that's the ideal customer for us, somebody who wants to provide premium tokens to their users. Another good use of our system is something we announced at Computex a few weeks ago: the idea that you can pair an RDU system with a GPU system in a disaggregated manner. Because GPUs have more raw compute capability, they're better at prefill, and RDUs are much better at decode, which is the ultimate limit. So you can do prefill on a GPU — using existing systems you already have in the data center — and then bring in RDUs at some ratio, one-to-one or two GPUs to one RDU, to get very fast decode capability.

   2:07:25

   Prakash: One of the questions I had for you — we've had a guest, Bing Zhu, on the show before, and they were doing PTX-instruction-level optimization models.

   2:07:37

   Kunle Olukotun: Might be Mark.

   2:07:43

   Prakash: They were doing PTX instruction models?

   2:07:47

   Nathan Labenz: We can hear you. Hearing.

   2:07:54

   Kunle Olukotun: Are you hearing me?

   2:07:56

   Prakash: Yes, we can hear you fine. If you switch from earbuds to your computer mic and then back, it'll refresh — so, we can hear you fine.

   2:08:13

   Kunle Olukotun: I'm not hearing.

   2:08:30

   Prakash: So maybe just refresh — just press refresh on the page. Oh, he can't hear us, I see. We're going to drop off. Oh, well.

   2:09:33

   Nathan Labenz: Never a dull moment in the live-streaming game.

   2:09:36

   Prakash: Yeah, doing it live always has a bit more risk. Alright, we'll see if we can — or we'll just message, I think. So, sudden drop-off. Let's see, I don't know if we—

   2:10:04

   Nathan Labenz: —have Brian here as well in the background. Brian, if you can hear us, maybe send a ping for just a quick page refresh — I think that would be all we need. I sent that via email too.

   2:10:27

   Prakash: Notes for improvement — room for improvement here.

   2:10:32

   Nathan Labenz: This is the — shouldn't the banner's attention, whatever API is filling in the headlines on the screen, send a signal to have him refresh the page? Let's see if that works — prompt-injecting our headline writer. I could also come back — he might hear me if I come back. It'd be another—

   2:11:14

   Kunle Olukotun: Yeah.

   2:11:15

   Nathan Labenz: —possible switch. Alright, let me refresh as well, and then maybe you'll also get the hint if I refresh.

   2:11:21

   Prakash: Yeah.

   2:11:30

   Nathan Labenz: Alright, I'm back — can you hear me now?

   2:11:34

   Prakash: He saw the refresh, I think — so maybe once he comes back we'll do a quick roundup and let him go, we'll stretch his time a little bit. So the whole architecture question is fascinating, because it indicates that there are ways around the NVIDIA monopoly, and people are working hard on them, so one does hope that we can — there we go.

   2:12:22

   Kunle Olukotun: I'm not sure what happened there. I'm sorry.

   2:12:25

   Nathan Labenz: That's on us.

   2:12:27

   Prakash: Yeah, sometimes it's our fault, sometimes it's LiveKit's fault. I get emails from the dev team like, 'oh, we had an outage.' I'm like, 'you should have told us that before.'

   2:12:37

   Kunle Olukotun: Yeah, okay.

   2:12:42

   Nathan Labenz: But we're back.

   2:12:43

   Prakash: We're back, okay. Let's just round up — what have you seen in terms of using AI within the design process, within your firm, to build software and build better tools around this whole idea? And where do you see things going? And the second question — what does the roadmap look like on a three-to-five-year mark for the firm?

   2:13:14

   Kunle Olukotun: Yeah, well, I think this is something I'm interested in both within SambaNova and, it's a big component of my research at Stanford — how do you use AI tools to speed up the design process. Of course, like every other firm, we're actively using AI, both open-source AI models and frontier-lab models, in conjunction, because you want to control token cost. We've got models that run very efficiently on our own machines, so we combine them for tasks the open-source models can handle, and then for the very challenging tasks, of course, we'll go to the frontier models to take advantage of those capabilities. So yeah, that's used throughout the firm for all sorts of software development. We never use CUDA in our software stack — we never thought CUDA was the right way to think about designing these compilers. We started with the PyTorch representation of the dataflow in the AI model, and our whole goal was to take that representation and map it into our machine in a dataflow way — which completely sidesteps CUDA. From the developer's point of view, what we wanted them to do is describe how they want to optimize their model at the PyTorch level. Parallelism in these models happens in multiple dimensions — tensor, data-parallel, pipeline-parallel — and you should be able to describe those dimensions, and then our compiler takes those directives and does the appropriate mapping. So that removes the need for the user to write low-level code like CUDA, but still achieves the performance levels and mapping control they need for high performance.

   2:15:59

   Prakash: Yeah.

   2:16:00

   Kunle Olukotun: Yeah, so we'll continue to push on that. Over seven years we've taped out five or six chips — we're on a cadence of roughly every 18 months for a new chip. We continue to push on our ability to provide premium token inference, which means focusing on more bandwidth. Traditionally we've been one generation behind NVIDIA in terms of technology, definitely HBM technology — our current designs use HBM2e, and we're able to compete with their HBM3. But we want to keep using higher-performance, more recent HBM, take advantage of new packaging ideas like 3D packaging and chiplets, and think deeply about how we design the next generation of architecture to take advantage of both new memory bandwidth capabilities and the ability to scale out and up.

   We want to make sure we can get very, very fast inference on very large models, and the key to that is exploiting parallelism — especially the kind that requires communication between multiple RDUs. Figuring out how to do that without the inter-chip communication getting in the way is going to be the key challenge, and we've got all kinds of interesting ideas about how to do it. We want to be the highest-performance, lowest-cost inference provider, in terms of the capabilities we provide from RDU technology — with the SN50, which we've announced, the SN60 coming down the pipe soon, and future generations focusing on the same thing.

   We also want to maintain flexibility, because I see the landscape of AI models continuing to change — there will be new varieties of transformers, there will be state space models, there will be ways we fundamentally have to transform the algorithms to make them more linear, because we can't keep going in this quadratic direction if we really want to enable everybody to use AI in a cost-effective manner.

   2:19:24

   Nathan Labenz: This has been fantastic, and I really appreciate you staying a little long with us. If I can dare to ask just one more question—

   2:19:32

   Kunle Olukotun: Sorry, I can't hear what Nathan said.

   2:19:35

   Nathan Labenz: Can't hear me again? Oh my god — Prakash, can you hear me? Alright.

   2:19:39

   Prakash: I can hear you. Kunle, can you hear me? You can.

   2:19:43

   Nathan Labenz: Okay, I may not hear Prakash either — so bizarre.

   2:19:47

   Prakash: So bizarre. Alright, let me switch this.

   2:20:00

   Nathan Labenz: Note to our agents as they go through the transcript — we need, like, a refresh button in our producer view to just refresh somebody's—

   2:20:12

   Kunle Olukotun: Okay. Thank—

   2:20:15

   Nathan Labenz: —you for joining us. Sorry for the technical difficulty, but this has been great. That was a little rough. The last question I wanted to ask is: let's say you achieve all your goals in terms of design — what will be the barriers to scaling up? Maybe we can send you an email and get a little extra thought on this to share back. But in previous rounds of going down the 'what is NVIDIA's moat' rabbit hole, one candidate answer has been conviction, balance sheet, and lockup of the supply chain — that they're just willing and able to buy out capacity from key suppliers for years to come. I've heard that for a while, but we've seen there's at least enough slack in the market for decacorn companies to pop up. And it seems like, as you mentioned in the intro, SambaNova is trying to be the next decacorn in the space. So what's happening there? Have the suppliers said, 'we're going to cap what NVIDIA can buy so we don't lock ourselves into a monopsony future'? Are there clauses that allow for that kind of flexibility? How is it happening that somebody can come into this supposedly — and I think not just supposedly — super input-constrained, super complicated supply chain, and buy their way into being able to ship finished product on a timescale that matters? I don't have a great sense for that, so—

   2:22:15

   Prakash: I kind of have a sense for what's happening right now. Number one, SambaNova's chairman is Lip-Bu Tan at Intel, so they're definitely going to use the Intel Foundry — and the Intel Foundry doesn't have enough customers. Lip-Bu has been signing with Apple and others, trying to get them to use Intel packaging and Intel chip manufacturing fabs. Intel has also put in an investment in SambaNova, so I think it's clear they're going to tape out and produce at Intel.

   On the NVIDIA side — I think Jensen is always under antitrust-type scrutiny now, and he's got all these very powerful hyperscalers around him, annoyed with his pricing, so he's got to be aware of it. He is making deals — he signed a deal with Corning, a glass manufacturer for optics, this week, and he's co-building a factory with them. I think he's put in something like 40 to 50%, they put in the expertise, and basically he'll buy the product. So he's building out factories, and it's a little hard to call that an antitrust issue, because the factory wouldn't exist if he hadn't put the money in — it's not him buying out capacity that already exists, it's creating capacity that didn't exist in the market. That's harder for an antitrust case, and I think they're aware of that, so they're targeting things where they can start to own pieces of the supply chain directly.

   For the smaller chip startups, what ends up happening is that Broadcom, or some of the larger players, have allocated wafer capacity at TSMC, so the smaller guys end up going through Broadcom, and Broadcom takes a cut on that — they basically manufacture through Broadcom's relationship at TSMC. Qualcomm also has some allocated capacity, so Qualcomm can swing a little bit too. So these bigger players have some allocated swing capacity in the industry that smaller guys can use if they pay for it. That's roughly what's happened over the past 12 months or so — it's not that you can't get capacity, it's that you have to go through the people who already have it, and do deals with them to make it work.

   2:25:05

   Nathan Labenz: Nice — great answer.

3. 2:25:10Closing26 min

   ClosingThe hosts stayed on to decompress after Kunle's departure — pulling on the threads from the interview and the morning's news: where the economics of reasoning-model and agentic inference are actually heading, and what the government-fuses-with-the-frontier week means for who captures AI's gains.

   Watch

   ▶Play this segmentYouTube · from 2:25:10

   As aired

   Prakash and Nathan closed out the show by circling back to the frontier-chip-architecture conversation from earlier in the episode — Prakash summarizing the guest's explanation of SambaNova's "conveyor belt" dataflow chip against the GPU "hub-and-spoke" model, and Nathan flagging his general wariness of new-architecture-vs-baseline comparisons. They traded theories on Nvidia's blocking constraints, the two-wave pattern of frontier chips falling into inference use (citing H100s and xAI's Colossus clusters), and why the chip business overall is set to get much bigger as it fragments into niches.

   Nathan revisited a prediction he got wrong — that inference would become "too cheap to meter" — walking through GPT-3-era pricing versus today's token hunger and the shift to a "market-clearing-price" era where chip scarcity, not model economics, now sets the floor. Both hosts speculated about whether 2026 brings another capability step-up (Nathan bet yes, citing Fable and historical cadence) and whether that translates into real revenue growth for mature consumer businesses like Nike, using Nathan's recent conversation with Neural Concept (aerodynamic-validation agents for Formula 1 and automotive) as a template for how an agentic design-and-validation loop could eventually apply to shoe design.

   They wrapped with a lighter aside about Elon Musk's under-exploited materials-science data, a nod to America's upcoming 250th anniversary, and a sign-off until next week.

   Key moments

   All compute is food for these AIs.

   Here's to virtuous leadership long into the future.

   Full transcriptLightly edited · timestamps jump to YouTube

   2:25:13

   Prakash: I finally kind of understood what the new paradigm is. So, correct me if I'm wrong, but basically what he said is that a normal GPU acts a little bit like a hub-and-spoke system: for every step of the decode process, it goes back to the hub and then to the spoke for processing, then comes back. Whereas for these new chips like SambaNova, they're acting like a conveyor belt — it goes to the first one, the second one, the third one, the fourth one, which is what it's supposed to do anyway because that's the defined sequence of steps. So that's the difference between the GPU paradigm and this paradigm. Is that roughly what was going on?

   2:26:05

   Nathan Labenz: Yeah, I think that aligns with my understanding. I mean, I'm always, in general in AI, a little wary when people compare their technique to some baseline, depending on how well I understand that baseline versus what's actually running in optimized form in production. I'm always like, okay, that sounds right — are they actually doing it that way, or do they have some other workaround or optimization that narrows the gap relative to the naive path? We've seen this with transformers a million times, where people say, 'Oh, my new architecture outperforms the transformer.' But it's like, well, which transformer? If you're using the 2017 initial transformer as reference, you're obviously way underselling what it is today in fully optimized form. So I'm always a little wary of that kind of thing, at all levels of the stack. But I think that what you're saying there adds up. And then there was also this other big concept of blocking versus non-blocking.

   2:27:19

   Prakash: Yeah.

   2:27:20

   Nathan Labenz: And I don't quite understand that as deeply as I'd like to either, especially when it comes to how hard it is for Nvidia to get out of that problem. Is there a reason that's sacred in their architecture, or is there an opportunity for them to relax an assumption or two and get to where SambaNova is on that dimension with the next generation? I'd be speculating — definitely out of my wheelhouse and out of my depth to say much more than that. But, yeah, what bullets would Nvidia have to bite to not have these blocking issues? Unclear.

   2:28:13

   Prakash: So let me give you kind of an industry-structure framing. Maybe — Nvidia chips are good for the frontier because the GPUs are eminently reprogrammable, and you can run multiple architectures on them, and you can develop new architectures on them. So what ends up happening is that if the frontier advances quickly, the GPUs get utilized for that. If the frontier advances slowly, people start optimizing for inference. So you have two waves: on one side, the frontier advancing — if it's advancing fast, people need to be at the frontier, and there's not enough time to optimize the inference. But as the frontier advances, and then six, nine, or twelve months behind that frontier, you get the inference-optimization wave following up. So the frontier chips first get used for the frontier, and then they fall into inference. The GPUs are imperfect for inference, but they're also depreciated, because they were used for the frontier and now they can be used for inference. That's why the H100s are still being run for inference, for example — people no longer develop leading-edge frontier models on those chips anymore, but they're good enough for inference. So you get these two waves, and it's kind of similar to the two waves we see in the model labs versus open source — you have the leading edge creating the new stuff, and then you have this optimization, distillation, and consolidation wave following up, reducing cost. So you have these multiple waves proceeding through the industry at multiple layers simultaneously. Does that make sense?

   2:30:10

   Nathan Labenz: Yeah, I mean, he did specifically note that they've historically been one generation behind Nvidia, so that definitely reinforces that notion. We also heard something similar from xAI — they were willing to rent Colossus 1 to Anthropic, probably because they didn't have a lot of inference load themselves, but also because it was a mixed-chip environment, and that was becoming problematic for training. Colossus 2, which is a more homogeneous environment, is just a better place to train, and so they didn't really need the first one as badly anymore — they didn't feel like they were sacrificing their frontier work to rent out what had kind of become more of an inference-capacity facility. So I'm trying to think of what the complications of that would be, or if there's a counter to it, but all the data points coming to mind so far support the general paradigm you're laying out.

   2:31:33

   Prakash: I think the chip business in general is just going to get so much bigger. There's enough food for everyone — the entire business is going to get so much bigger because you're going to get all these different niches where different players can thrive. It's really a swing back to, like, the mid-nineties chip era again. So—

   2:32:05

   Nathan Labenz: Yeah — all compute is food for these AIs. That was the title, and a song lyric, from an episode of the podcast I did with Jeffrey Ladish from Palisade. And I've got one coming up with Ramin, the CEO of Liquid AI, too. I'm just thinking more about how even small bits of compute are starting to become relevant. The cell-phone market is $500 billion a year — it's been at the scale of the data-center buildout for quite a while now. The data-center buildout has now surpassed it in terms of annual scale, I think, but not by that much, and not for that long. So I do think we're going to see — it always comes back to everything, everywhere, all at once. Pretty soon — this is also, as I look back and think about the predictions I got wrong — one big one I think I got wrong was that inference would be really cheap. There was a time — in a way I'm still right, depending on how you want to look at it, but it's definitely not as cheap as I thought. It doesn't feel super abundant, to the point where it's too cheap to meter. We have not hit that level. And I don't know if I was expecting too cheap to meter, but I was definitely expecting closer to that than where we are right now. The way in which I was right is that Fable is still cheaper than the original GPT-3 — that was $60 per million input tokens, $60 per million output tokens, no caching, twice as much if you did fine-tuning, and obviously dramatically less capable in all regards. I think what I underestimated was just how many more tokens a frontier model would use. We were putting in a couple thousand at a time to GPT-3 and thinking, 'Oh my god, this is fifteen cents to make one API call.' That felt like a crazy thing when, in general, API calls in any other kind of API were like a tenth of a cent or less. But then we saw dramatic cost reductions with 3.5 and Turbo and those kinds of models — they dropped costs by almost two orders of magnitude, like a 98% cost reduction with a performance improvement. And at that point, it wasn't so much token hunger. Now we see this incredible token hunger. I still think there's an interesting question there. Another thing that's really changed is we've moved to a world where we're now in the market-clearing-price era, as opposed to the labs trying to use up — trying to create the market out of nowhere and get the whole thing going era. So now we're at a place where you could run things for a lot less, but it's just not available, because the market for chips continues to push prices up, as we've discussed many times, even on old chips. So I underestimated token hunger, and I underestimated demand bidding up compute regardless of all other progress.

   2:35:49

   Prakash: Mhmm.

   2:35:50

   Nathan Labenz: Even still, cost per million is down, which isn't amazing, but we're in a metered world. That's for sure.

   2:36:02

   Prakash: I suspect the metered world is temporary, because I think what ends up happening is people have budgets, and firms have to capture wallet share, basically. The whole sticker-shock thing, I think, doesn't work — they either have to pay for performance, in the sense of, okay, you get a new cancer drug, you get paid for that — that's something measurable, like return on investment. Or you're a cost, not a revenue item — you're a cost item, and then it becomes, okay, this is how much I can afford, I will buy all of the most intelligent stuff that I can get within this budget. And I think that's what's happening right now — this reconfiguring of the market. We had this first expansion, we had the blowup earlier this year, and now this is reconfiguring to, okay, this is my wallet share, what can I get with this wallet share? The one thing I think is the X-factor here, which I don't know how it's going to work out, is whether these models become so much more intelligent this year that you again get this expansion of budgets — 'we've got to have it,' everyone has to spend tokens, this is the most important thing — which is basically what we had earlier this year. Do we get another capability step-up where that kind of thing happens, you think?

   2:37:43

   Nathan Labenz: Yeah, I'd bet on one more this year. The first hinge point was probably — whatever people date it to — Opus 4.5 to 4.7, somewhere in there. The second one is Fable. Fable was done training early this year — it took us a while to get it, we've obviously had drama around it, but it's hard to imagine there's not a significantly better step coming in the second half of the year. And maybe two, if you listen to the people closest to it — and it's always served me well to take their statements, both publicly and reading between the lines, and any private statements where I'm not told secrets but given general direction as to what they're expecting — it's always served me well to take that at pretty much face value. And what I think the signal is from the folks at the frontier companies is: things are speeding up, they're not slowing down. We're entering the era of recursive self-improvement. There's probably still a lot of low-hanging fruit at all kinds of different levels of the stack. So, yeah, we probably should expect at least one more significant turn within the calendar year. I'd be very surprised — I mean, it would be the first time in many orders of magnitude of inputs that we wouldn't get another significant step on that timescale, if we were not to see one the rest of this year. So I'd have to imagine it really is coming. And certainly they're building out with the conviction — they're doing everything they can to secure capacity — with the conviction that something like that is coming, and that the exponential of demand for their products will continue, or super-exponential, potentially even.

   2:40:06

   Prakash: Yep. They do have to start providing significant value — that's the thing. The first step, coding — okay, yes, now everyone has software coders on standby, like infinite software coders. Okay, great. But, you know, like a Nike, for example — okay, so now your team is using tokens, but what else can you do for me? How else can you increase my revenue? Cutting cost is not that significant — American firms rarely focus on cutting cost that dramatically, except if it's a downturn. And if it's a downturn, they have a stash of employees they're prepared to let go, who've already been pre-identified, and they just let go. So I think the key thing that makes people buy something is revenue increase. How do these models increase Nike's revenue? They have to do something for the marketing, or make people buy more shoes — how does that work? I don't know — I can see it for coding, but for Nike, how do you get them to allocate their IT budget almost exclusively to you? That's still—

   2:41:41

   Nathan Labenz: Yeah, I mean, how elastic is demand for shoes? I'm not super sure. I'm personally making progress on my 2026 goal of spending more time outside, getting more exercise — I think there's probably an extra pair of shoes in 2026 for me as a result of pounding the pavement more, liberated from my desk via AI. So that's one happy story, but my guess is that doesn't move aggregate shoe demand in the immediate term. So I'd say it's probably tough for a business like that immediately. But then I think about — I just did this episode, came out yesterday, with Thomas von Chalmer, who runs the U.S. division of a company called Neural Concept. They may provide some inspiration for how you could imagine a company like Nike taking their business to the next level. So basically what they do is, traditionally, they provide models that validate designs — engineering designs, CAD designs — on a variety of dimensions, one big one being aerodynamics. And they actually work with Formula 1 teams, which I didn't realize — I've never been a Formula 1 fan, but they actually have rules around how much compute teams can use from week to week to optimize their design for aerodynamics, and whatever else. You're literally compute-limited as an F1 team. And if I understood correctly, there's also a kind of handicapping where the best teams actually have lower compute limits than teams that aren't doing as well. That's fascinating in itself. They have Formula 1 customers, they also have major automotive manufacturers, and their break-into-the-market point was these models that allowed you to run validation of things like aerodynamics or heat dissipation much faster than physics-based simulations would allow, so you could more deeply explore the design space and get your designs more optimized before you ever have to make a prototype, etcetera. Now they're also bringing an agent to market at the same time — so now you can have a Neural Concept agent that actually works in your CAD platform, similar to your human engineers, and it can call out to these models and say, 'Hey, I just made a tweak — validate me with the aerodynamic model,' or whatever, give me that feedback, and they can run this tight loop of agentic exploration, validation, and optimization — which is the perfect formula for reinforcement learning. To the degree that they want to take a hand in training models, it's going to allow their agents to get quite good at climbing these hills. We should, of course, expect — I actually think Grok is a good candidate to get really good at that kind of thing.

   2:45:18

   Prakash: I always thought Elon should just focus on that. They have so much, like, you know—

   2:45:24

   Nathan Labenz: He's so distracted by various kinds of porn and whatever. Yeah.

   2:45:28

   Prakash: They have so much internal data, which no one else has, on airflow and material science and all this stuff, and he ends up focusing on LLMs — Grok, Imagine, whatever. Google would love to have all that aerodynamic data, all that data on that stuff — you would love to have it. And they have a team that can do experiments too, so you could set up what Periodic Labs has done — set up a robotic experimentation lab, and get a hit on material science and all of these things. And he ends up, you know, back in LLMs. So that's a little bit disappointing, I think. So—

   2:46:20

   Nathan Labenz: Yeah, I wouldn't count him out just yet. Never bet against Elon has always served me pretty well too. I mean, to land the plane on the Nike analogy — if you can get that loop closed, and you get this sort of agentic model making design tweaks, getting validated, getting really good at climbing that hill — that's a pattern that basically works for everything. I'd bet that Nike has — clearly they have some way to forecast demand for products — does that extend to the point where they have a sort of black-box ML model that takes in just a design of a shoe and predicts how popular that will be? Maybe, maybe not. It'd be interesting to see if we can get an answer to that question. If they do have that—

   2:47:15

   Prakash: Mhmm.

   2:47:16

   Nathan Labenz: Then you can imagine them having an agent that actually does the shoe design, and kind of closes that loop again. So how can they drive more revenue? One big answer, which they're already quite good at — but you can imagine another order of magnitude — would just be infinite designs, an even more extreme long tail, and personalization even. And if that becomes a token-budgeted process as opposed to a human-shoe-designer process, then if we're all rich and enjoying abundance in general, maybe we buy, like, two times as many shoes, along with a bigger basket of everything else. But maybe they can only realize that if they can really scale that design-and-validation loop to the point where I can get something nobody's ever seen before, and you can too.

   2:48:21

   Prakash: Which is an ROI loop, right? Which is a reinforcement-learning loop at the end of the day — a reinforcement-learning loop with human input for taste. Yeah.

   2:48:35

   Nathan Labenz: So, I mean, Nike — I think you're right to say Nike seems like one that's relatively mature, not as likely to see massive growth as a result of AI as some other things might. But still, we can tell a story.

   2:48:56

   Prakash: You know, basketball shoes weren't a big thing in the 1970s — it was really post-Michael-Jordan, like late-eighties-ish, when Michael Jordan signed with Nike, and then it took off. So you could maybe see Nike get a marketing proposal of that kind for some other segment — maybe old people's shoes, or orthotics, whatever — some other segment of the market, and all of a sudden that segment also becomes a place where you can take five dollars of plastic and sell it for a couple hundred bucks. So maybe that's the thing. Maybe that's the thing that happens. Who knows?

   2:49:48

   Nathan Labenz: All the senior living communities are gonna be on fleek with the shoes, perhaps.

   2:49:56

   Prakash: Do we—

   2:49:57

   Nathan Labenz: Do we still say 'on fleek'? I don't know. I don't know where that came from — that's a deep cut. But, yeah, we'll know if my mom's wearing multicolored custom designs in the next 12 months, we'll know how it happened.

   2:50:12

   Prakash: Yeah, indeed. And on that note, Nathan — good morning. So, it is two days before America's 250th anniversary.

   2:50:26

   Nathan Labenz: Amazing. How about that?

   2:50:27

   Prakash: How about that? So, happy birthday to the republic, and we will see viewers and listeners next week.

   2:50:37

   Nathan Labenz: Here's to virtuous leadership long into the future.

   2:50:42

   Prakash: Indeed. Bye bye.

   2:50:44

   Nathan Labenz: Thanks, Prakash. Bye for now.