# 369: Thirteen Billion Reasons to Hug This Face
Duration: 63 minutes
Speakers: Justin, Justin Brodley, Matt Kohn, D
Date: 2026-09-01

## Transcript

[00:07] Justin: Welcome to The Cloud Pod, where the forecast is always cloudy.

[00:10] Justin Brodley: We talk weekly about all things AWS, GCP, and Azure.

[00:14] Justin: We are your hosts, Justin, Jonathan, Ryan, and Matt.

[00:19] Justin Brodley: Episode 369, recorded for August 25th, 2026. 13 billion reasons to hug this space. Good evening, Ryan. I'll hug you. Aw, thank you. You're welcome.

[00:30] Justin: I'll hug you too.

[00:32] Justin Brodley: Yeah, it's good. Uh, well, I would be hugging Face for sure if I could have $13 billion, but we'll get to that in a minute. How is, uh, your week going? I am, uh, in lovely, beautiful Omaha, Nebraska.

[00:43] Justin: Oh, continuing your tour.

[00:44] Matt Kohn: Nice.

[00:45] Justin Brodley: Yes, continuing my tour. It's, uh, it's lovely. Uh, you might hear the rhythm of, uh, cicadas in the background. Uh, They do stop making noise, which I did not know about cicadas. I was worried that was gonna be all night long and I was like, this is gonna be a long night. But it'll stop once it gets dark, which is good.

[01:00] Justin: So I didn't know it was when they get dark. I thought it was temperature related for some reason.

[01:04] Justin Brodley: I mean, maybe it's temperature related. I just know it got dark and they stopped making noise. So I'm gonna deal with it. As long as they don't keep you up all night, it's worth it.

[01:10] Justin: 'Cause they are loud.

[01:12] Justin Brodley: Yeah, they are super loud. And like, well, there's one, they got super loud and went over the window and it was just like sitting on the window just making noise.

[01:18] Justin: And I was like, Just staring at you.

[01:21] Matt Kohn: Yeah.

[01:22] Justin Brodley: It's like, me, they, gotta harass you.

[01:26] Justin: Yeah.

[01:26] Justin Brodley: Well, all right. Well, we got a bunch of news to get to once again, as always. So we last week mercilessly mocked GitHub and their August 17th outage. They have now come back to us with a formal blog post, which we were kind of waiting to see. They published this to basically cover the August 17th outage, which took about 8 hours and followed an earlier August 6th Actions failure. The root cause identified as a capacity failure, not a code or configuration change. A critical infrastructure component in the central US data center failed to scale at new traffic peak, triggering authentication failures and cascading disruption across services, including Copilot, which is prolonged by client-side retry loops. Central US data center gives you a clear, clear that this is on Azure, which has always had problems. So you're welcome. Since April, GitHub has added over 3 million CPU cores and 120 petabytes of storage, which is why no one could get Azure capacity. An accelerated Azure migration. Azure now handles approximately 58% of the platform load and half of the Git operations, up from 12% in May. Monday commit volume has roughly doubled since April, from 1.4 billion to 2.9 billion, underscoring the scaling pressure behind both incidents and explaining, though not excusing, GitHub for the repeated failures. Concrete remediation steps include consistent retry limits and budgets across service calls to prevent retry storms, a review of lower priority CPU and memory alerts, and continued work isolating critical systems to reduce shared dependencies. And blast radius. So, you know, I read through it, it felt a little woe is me, capacity is a problem, you know. But I don't know, it just feels like more of the same lip service from them. That's my final takeaway from it. I don't know, what do you think, Ryan?

[03:02] Justin: Yeah, I definitely was not impressed. I feel like it was a bit dishonest in the sense of lying by omission, more so. Like, they talk about the capacity and they talk about the inability to scale, and then they talk about all the CPUs and storage they added, and they're— it's just this vague upgrade to network capacity. And I'm like, but it wasn't— it wasn't, you know, like, it's a scaling concern, but it was because your automation did not scale, right? Like, it's— yeah. And, you know, there's probably other scaling thresholds that don't know the details, but it's, it's one of those things where they're so light on details, there's stuff that doesn't quite add up or, or make sense. And so it just feels like it lacks the transparency that it should. And so, like, it's a another black eye to me, which is, you know, like in, uh, what, a really bad year of black eyes for GitHub. So this is sort of rough. I don't like it.

[03:54] Justin Brodley: Yeah, well, I think the question is, okay, so, you know, you give us this chart that shows growth in completed GitHub Actions runs, you show us git fetch operations and they're climbing, you know, and then fetch throughput through history. But, you know, it's like, okay, so this is a pretty clear curve. Well, like, if you extrapolate out this curve a bit, like, can't you get somewhat predictable on capacity? I mean, like, you know, the— you're definitely in a hockey stick, like, no, no doubt about it. But, you know, if that trajectory continues, and assume it will, because AI is only getting more and more popular, it seems like every day. And so AI commits are going to keep going up, you're going to have more agentic capabilities, you're going to have all these things. Like, try to get ahead of it, try to flatten that curve out at least so you're getting ahead of this capacity thing. Maybe we need to rethink some core fundamentals about how Git works. Like, Git was designed for humans and Linus Torvalds and people running the Linux kernel who had a very specific need and desire that was around human speed and human scale. And so I almost sort of wonder, like, is it time for GitHub to like maybe go back to the drawing board a little bit and rethink how the GitHub service works and how Git works in general for this new age of AI? We, we may have just flat out outgrown Git's capacity. And I think, I think having that conversation, A, would be interesting. And I think people will come out of the woodwork, you know, from the Git open source side, and they'd have thoughts and feelings about this too. But like, at least it'd be a debate and we could have, and maybe there are options to change the way some of these things work. But you know, what they're doing right now, it doesn't seem to be working. So, and again, I don't know if they can fix it. Permanently or not, and is there enough capacity on Earth to handle the amount of GitHub commits that we're taking on if this, you know, if it continues at this level of pace?

[05:40] Justin: Yeah, I mean, if you look at the, the graphics that they provided, it's, it's, it's looks like exponential growth, right? Like they're not only is it just a linear, you know, growing from, from left to right, it's, it's also curving up in the sense of the rate that it's increasing is, is going up over time as well. And so I don't think you can solve that by throwing capacity at it, right? So I agree with you. I think that they're going to have to look at, if it's Git fundamentals directly, which it does seem like maybe, maybe it is, like in a sense, you know, there's like repo creations was one, throughput of pull requests was another, you know, Actions, you know, and as someone who has owned the Jenkins service for companies, like this is a problem. It was a problem. That's ancient and old, which is like your GitHub Actions run, your customers are incentivized to decrease the number of pipeline runs. And so that's just, you're gonna have to figure that out or you're going to have to price it in such a way where it makes sense for your customers to take action. And right now they don't, like it's, there's a whole bunch of different I think business sort of primitives that they're not following that's led to these outage things. And you know, like, I don't, I don't know how they recover 'cause I don't see the load going down. I don't see, you know, the, when I think about the, the numbers that they're quoting for number of repos created, it's because there's people who are not coders or not working in computer science or working in development teams that now are coding through AI and through AI bots. And those AI bots are, recommending the, the opening of a GitHub repo, if not just doing it themselves. And so like, this isn't something that's gonna stop.

[07:24] Justin Brodley: Yeah. Yeah. Well, and you know, I, there's other little things that jump out to me when I read through the formal RCA, you know, blog post they did, uh, or sorry, the GitHub status page where they have a little bit more detail about like the, the rate limiting and the failing traffic and how it moved around, et cetera. You know, there's a lot of mentions here about server-side sidecars and Istio and other technologies. And I also had to wonder, like, you know, okay, you're getting a ton of flexibility and speed from Kubernetes, but also, are you adding a lot of complexity to a scaling problem? That is, you know, should you simplify this architecture? Should you really think that through and say, is this the right way? You know, knowing, A, that, you know, that when we break things, it's a big impact. And do we want the speed of tokenization— or sorry, of, uh, Kubernetes and Docker and containerization to really do this, or do we want to have more truthful, steady-state, proven technologies that we know can scale? Like, not that Istio can't and not that containers can't, but again, I just sort of look at this and sort of my thoughts on this is too, is like, should I be simplifying? Should I be making this an easier set of knobs to twist versus, you know, dealing with a bunch of different components and parts and, you know, even in a, in a world where you've gone into several microservices, maybe You know, the microservices are adding a lot of additional latency and things to your infrastructure that are hurting you, that monolithic ideas might make more some sense and not in all the services, but maybe some of them, maybe you've over-microed. Again, this goes back to the point of like, at this kind of scale, you need reliable, proven technology and you need to have a system that can meet the needs you have today and into the future. And, you know, virtualization technologies, things like you're, you're carving up capacity to do all these things in Kubernetes. Maybe you should be putting that towards the thing that you need it most at.

[09:16] Justin: Yeah. And is this, are there compromises that you've made in order to be multi-cloud, serve this from multiple clouds at once, right? Like, is that, you know, a lot of people jump on the Kubernetes bandwagon for just that scenario. And this is, you know, what we've on this podcast largely railed against, which is like, you can do multiple clouds, but trying to spread out your application functional functionality across multiple clouds all at the same time. Is a lot of complexity to manage. And you know, if you've put in a whole bunch of Istio routing to address that complexity and not taking advantage of other technologies that are not cloud agnostic, this is sort of the downfall of that. And you have to manage that all yourself. So, and you know, they may be staffing it appropriately. It may be, you know, just other concerns, but it's, you know, it makes me question it.

[10:03] Justin Brodley: Definitely.

[10:04] Matt Kohn: Yeah.

[10:05] Justin Brodley: Again, it might still be the perfect architecture, but Like, these are the questions you and I are asking as technologists. And, you know, we're reading their RCA and we're leaving it non-impressed or like feeling like they're not telling us the truth or they're trying to market buzz this. And it's like, okay, well, these are the conversations you could be having on an engineering blog about why you chose certain things or why you're doing certain things to help rebuild the confidence. And there's ways to do that in a way that make you feel like, oh, I have faith in what they're going to do. Cloudflare is a great example. They write really great RCA blog posts. They flat out tell you how they messed up. They talk about what they're doing. They, you know, they went through their challenges a year ago and they've been, you know, they did a lot of work and they're in a much better place now, um, than they were a year ago. And I don't have the same concern about them as I did, but GitHub hasn't, isn't reaching out to the community who, people who really, you know, make GitHub popular. Like you need to be more transparent with the audience that you're talking about. Yeah.

[11:04] Justin: I mean, it's like when you work at a company at a large scale where you've got like sort of global, global recognition, like it's so much fun to contribute to those, like how we're addressing problems at that scale, right? Like I haven't had it in a long time, but I remember, you know, early in my career being able to contribute to those and at Yahoo and it was, it was kind of cool. It made you feel good and that you're solving a unique problem and you're communicating out to the world to sort of help other people and do that. And so it's, it's, it surprises me that GitHub's not taking that opportunity. 'cause everyone in the world knows about GitHub. People that aren't coders know that GitHub's a thing. They may not know what it does exactly, but, and so yeah, I just think that having a blog and, and how they're addressing these challenges, how, what they're doing would be super cool for them to add.

[11:49] Justin Brodley: I mean, and they do have, they do have an engineering blog, but like, you know, the most recent post was August 24th. Your alt text passes automated checks. It doesn't mean it's any good. Who cares?

[11:58] Justin: Like, nobody cares, but You know, but it's not, it's not the engineering challenges that we're talking about.

[12:03] Justin Brodley: Yeah, it's not engineering challenges. Like they're just, you're just telling a marketing, use GitHub Actions for better marketing, you know, for better QA or for, uh, you know, all kinds of little things here. But yeah, like I think we talked about the stacks, the GitHub Stacks the other day, uh, when they released that feature and we were like, we don't really understand how to use it, but like, there'd been a perfect place to come and use an engineering blog to talk about like what the challenge they were seeing and like really deep dive into this stuff. And I just feel like they're, continuing to miss an opportunity to engage the community in a way that would make them look better. Yeah. I think that's too bad. And I, you know, and if their stability issues continue to happen, I don't know, you know, how much longer people are gonna just stick with us.

[12:45] Justin: Oh, for sure. Yeah. They're already doing damage to their reputation. Right.

[12:48] Justin Brodley: So it's, yeah. So, you know, counterbalance it a little bit, but I'm not the CTO at GitHub and so I don't have to, uh, answer to the shareholders or to the people who care, but as a technologist who uses GitHub every day, I'd like you to be more transparent.

[13:02] Justin: Yeah. And if there's any of our listeners that do work for GitHub that want to come on our podcast, then, you know, we can definitely have a great conversation at Cloud Pod Talks.

[13:11] Justin Brodley: They also could send us anonymous feedback too about how bad it is, you know, what we don't understand. Because like, I definitely, maybe we don't get it. Again, like we're only interpreting the tea leaves that they're giving us and And that's how I'm interpreting them for sure. All right, moving on to general news. Hugging Face could be acquired for $13 billion amid the AI boom. Uh, this is nearly the triple its $4.5 billion valuation from 2023, according to PitchBook. The company functions as a repository and distribution platform for AI models, letting developers discover, share, and download models rather than building foundational models themselves. Uh, one of their core use cases though is you can also run inference there, which I just taught Ryan earlier before the call. Uh, and this is just one more company in the, in a long line of companies that seems to be, uh, getting a little bit AI acquisition juice after Stripe's agreement to acquire OpenRouter a couple weeks ago for approximately $8 billion. So if you can, uh, get $13 billion and be more than OpenRouter, why not? Yeah, the investment backing Hugging Face seem to agree, uh, and those included Lux Capital, Addition, and Salesforce Ventures. Uh, and this company was started in 2016, which I didn't even hear of Hugging Face until I think 2 years ago at this point.

[14:21] Justin: It started in 2016? What did it say?

[14:24] Justin Brodley: I have no idea. No idea. But, uh, yeah, so, uh, you know, if they can get $13 billion, congratulations to them. You know, remember all your friends and friend and family and, you know, help us out a little bit out there. So that's a lot of money.

[14:37] Justin: That is a lot of money. I mean, that's great. I mean, good for them. And, um, I, I was surprised to find out that A, they had a business model and they weren't, uh, cuz I've always thought of Hugging Face, it's like this open source sort of just helping out the community by providing sort of this marketplace or, you know, for downloading the models. And so I was, as Justin said, he had to teach me a lot today. I'm like, oh, that's what it does.

[14:59] Matt Kohn: So yeah, I mean, either I wasn't here 2016 to like 2022, like I have no idea what they were doing at that time.

[15:10] Justin Brodley: Yeah.

[15:10] Justin: Look who snuck in.

[15:12] Justin Brodley: How pretty is that? Yeah, which we do. Yeah, they also provide compute for endpoints, the inference stuff. They also do some type of training, I think too, is one of the other features they have. So yeah, they, they can do a bunch of, uh, different things, uh, if you care to talk to a salesperson there, which I have never done.

[15:29] Justin: Well, I knew they did some sort of benchmarking because that came out in the OpenAI, uh, news that came out a little while ago. And so it sort of, sort of made sense to me, but, uh, having more of the we'll run inference business model and stuff makes sense. From a business perspective, I know why they do it.

[15:42] Justin Brodley: I'm just surprised by it. Exactly. Well, in AI is How Machine Learning Makes Money this week, Anthropic gives a bit of a gift to Ryan with the new Enterprise Managed Authorization for Claude's MCP connectors now generally available, letting admins provision connector access org-wide through an identity provider starting with Okta instead of requiring each user to authorize connectors individually. Uh, the feature is built on an open enterprise managed authorization extension to the model context protocol, meaning any MCP connector or identity provider can implement the same standard rather than relying on proprietary integrations. At launch, it supports, uh, Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase, with Datadog, Notion, and Slack support, you know, being supported as of the August update, and Exa, Mira, and Zoom listed as coming very soon. Uh, admins can shorten access token lifetimes without hurting user experience since IDP checks are frictionless, allowing faster revocation when employees are deprovisioned. By reducing the risk of lingering access on old tokens. Early adopters rolling out the capability include HubSpot, Ramp, and Webflow, and it's currently available in beta for Cloud Team Enterprise plan customers with a waitlist for the broader access. But hey, the fact that it's coming at all is fantastic.

[16:51] Justin: Seriously. I mean, this is, this is a huge problem for me in the day to day is because it's, you know, without this, people are either doing local sessions, which is painful and people don't like that. And so since they don't like that, they're looking for easier integration options, which means that they're trying to provision service accounts or static API keys to manage these things and add that to their MCP configuration. But with that comes a whole bunch of other problems, which is how do you, you know, using a basically centralized API key, or, you know, like you have no way to sort of manage your identity as individuals anymore. And so you end up with these very big broad permission sets that people want to leverage for their MCP usage. And a lot of times the people managing these these tools don't really understand the access that they're giving away and the danger. Like, you know, people who are admins for Canva, for instance, right? Like, they're not, you know, security engineers. They're not, you know, necessarily even cloud engineers. They're people that work in the design space and, and want to provide a platform to enable, you know, making pretty things. And so knowing that they're basically granting access for one AI bot to come across multiple projects within Conva and make changes is not something they might know off the top of their head, right? Doesn't remove their responsibility, but it's also, it's a huge risk. And so I've been spending a lot of time educating internal teams on, you know, what type of access models work with MCP, what's good for today. And, and, you know, in a lot of cases saying this is why we can't do a full system administrator account for this MCP server is 'cause we have no way to, to manage the authorization of these things in a way that doesn't provide a long-lived static credential or broad access that's not least privilege.

[18:40] Matt Kohn: This is also the fear of when MCPs first came out, which was, oh my God, are you going to have the access controls in there? Are you going to have all these different layers? And is my identity going to go through to all these subsystems? And places that have to do, for example, like a, you know, service account or anything else, I've had to seeing people build out essentially their own internal user-based access. So either dumping everything over or doing something where they then build a separate system on top of whatever tool it is to manage it so that, until y'all choose SharePoint, you know, we're using a general SharePoint account, but you don't get access to all of SharePoint. You get, you know, access to just a small subsegment that you're supposed to and keep that permission set flowing. If that's the problem, and you know, hopefully this does actually solve the problem in the long term.

[19:35] Justin Brodley: Yeah.

[19:35] Justin: I mean, I think that's exactly what's been going on is like in enterprise platforms, they're sort of proxying that permissions, right? So that's, yeah, you have the service-to-service integration at the platform level, but then the, you know, the AI enterprise solutions doing some sort of proxying of permissions or, or looking at permissions so that it doesn't, so it scopes itself on demand. Which is great. That's what we need. And this is a very similar sort of, I think, model, I think, but I don't know about the permissions that you're granting in Okta, right? Like there's a, you know, what are you authorizing and how do you define those authorization targets of MCP is interesting. And I want to see how they're doing that.

[20:14] Justin Brodley: Yeah, I imagine that there's a reason why Okta is the partner on this, but that'd be some type of, you know, because again, like we always talk about on behalf of or as user impersonation as the two main agentic identity models. And so this to me sounds like, you know, you're giving the MCP the authorization, but then how do you, you know, how do you pass the access back to the user? I think that's the question I don't fully understand. It's gotta be something in the Okta layer, I would imagine, that controls some of that.

[20:42] Justin: I mean, I know some, but I don't know how much I'm allowed to say.

[20:47] Matt Kohn: So, I will say as an end user, not having to, reauthenticate to Granola and all these other tools that you gotta do on a daily basis. It's nice and will make my life easier if it can be done at an org level and it maintains it there versus, you know, at everyone's end device. And I'm sure IT people are gonna be very happy having less tickets open about things.

[21:08] Justin Brodley: Yeah.

[21:09] Justin: I mean, this is exactly what we talked about last show about having to authenticate and trying to script up your local OAuth, you know, MCP authorization across all these things. So this helps for me.

[21:18] Matt Kohn: Claude just yells at me every time I open my personal laptop, how many MCPs am I not connected to? I've just tried to remove, which nicely has actually caused me to clean up some of the random MCPs I played with and clean and, you know, still had.

[21:32] Justin Brodley: Yeah, that's what I did. I started deleting them. If they were annoying me too much, I'm like, I don't need to. Uh, or I, you know, move it to my, my local, uh, gateway that I run on my container. Uh, that way it's least centralized for those services, which is pretty nice too.

[21:47] Justin: Yeah. I mean, having an MCP server does have a certain amount of token cost, not very much, but, and so like, I definitely don't have things that auto-start and I've got skills and instructions to say like, hey, these are what's available, but let me know and I'll start 'em up for you.

[22:01] Justin Brodley: So, yeah.

[22:02] Matt Kohn: Well, I'm very much sure that's because you're paranoid.

[22:04] Justin: It's 'cause I'm paranoid and cheap.

[22:06] Justin Brodley: Yeah. I mean, this is kind of the reason why I, Also moved away from user-level MCPs and moved to repo-level MCPs. That way I just keep the ones that I want for that repo. Um, and that's been a little bit better. You know, it has caused some hygiene to happen, which is probably a good thing. All right, well, moving on to AWS. AWS IAM now supports 20 managed policies per role by default, up from 10. Uh, so this is doubling of it, applying automatically across all commercial regions, GovCloud, and China regions. No customer action required. This change reduces friction for teams following IAM best practices around granular purpose-specific policies such as previously, since previously they hit the 10 policy limit and need to file a service quota request just to stay organized. The update also helps with AWS Partner product onboarding where third-party tools often require attaching several managed policies alongside a customer's existing permission structure. For organizations that need even more headroom, quota increases up to 25 policies per role still available via the service quota. So I get 5 more with a quota increase. But this is a small, practical quality of life improvement from Amazon. So thank you.

[23:11] Justin: Yeah, this is one of those rough edges that when you hit it, it's sort of like, I don't know, like disheartening cuz you're like, IAM is already hard enough and you're trying to organize it. So you separate out and you, or, you know, you hit this because you've got one ginormous policy, which also has its own limitations in size. And then, you know, like you wanna have multiple policies so that you can update them individually and maybe even have them under version control where you can rollback and, you know, all kinds of things. And then you hit this limit. It's sort of your whole strategy of how you're gonna manage IAM policies can go down the tubes, right? 'Cause the first few are fine 'cause they don't, they're under the threshold. It's not until you hit that weird scaling one, you're like, no. So I'm happy.

[23:51] Matt Kohn: Yeah, I've definitely hit that. I think my, not my first time, but up there my first time was with you, Ryan. We hit that 'cause, you know, do you really want to do true granular policies? It adds up so quickly, you don't realize it. And then if you're even doing conditional, like, I don't even want to just say, you know, update Load Balancer, I want to be able to update Load Balancer only if it matches this naming convention, like, that expands on the lists and everything else.

[24:19] Justin Brodley: So, all right, we're moving on to authoring Docker policies from natural language on Amazon Bedrock Agent Core. This lets you convert existing compliance documents into Dogwood, an open-source governance language, rather than hand-coding rules for AI agent behaviors. We talked about this a couple weeks ago when they first released it with the proprietary Dogwood, basically HCL-type language. But the tool supports time-based and directory constraints like rate limiting, cumulative gaps, and sequential ordering of tool calls, plus integration with Amazon Bedrock guardrails for detecting sensitive content like social security numbers in free text fields. The system is explicit about its limits. It flags rules that cannot be enforced, such as value judgment-based instructions. Action-based rules like redactions or day of week or holiday logic and constraints that span multiple sessions, pushing those back to teams as human processes or alternative controls. The 4-step pipeline: decompose, route, translate, validate, uses the Dogwood CLI compiler to check syntax and schema compatibility. The generated policy is shown alongside their source sentences, so a human reviewer confirms intent matches and enforcements. So I did look at Dogwood policy when they first came out with it, and I was like, yeah, that's going to be a bit for me to get to. Uh, so yeah, natural language, definitely much appreciated.

[25:26] Justin: Yeah, I definitely, I didn't have a use case right away, but I had sort of a similar reaction of like, oh, I'm gonna have to dig in a little bit. It's not something I'm gonna be able to just naturally like, oh yeah, it's just cool. I get this writes freely. So I imagine that this is, uh, very nice for the people trying to adopt it early. 'Cause it can be challenging. And then especially with the, the time-based evaluation that Dogwood provides.

[25:49] Justin Brodley: AWS Network Firewall now tracks rules hit counts, showing which stateful rules are actively matching traffic versus sitting unused, addressing a longstanding visibility gap for security teams managing complex rule sets. The feature is enabled by default at no additional cost, though standard CloudWatch logs or S3 Athena charges apply for storing and querying the underlying log data. Practical use cases include identifying stale rules for cleanup, validating the newly deployed controls like geofencing or AI/ML domain blocking, are actually functioning and accelerating incident response by quickly spotting suspicious traffic patterns like OAST domain hits. This directly supports compliance requirements like PCI 4.0 and DORA, which require organizations to prove security controls are actively working rather than just configured.

[26:32] Justin: Yeah, I mean, that's— it's kind of a cool, cool requirement. Like, the first time I saw that compliance requirement that it has to be proven that it's working, I was like, yes, because that's the big difference between security and compliance. Sort of compliance is a way to say that you're managing your security, but actively protecting it is, you know, requires visibility into what's going on and if it's working. And you don't always have that great visibility. And so I love rules, things like this. As a platform engineer, I've built, you know, a firewall automation service, you know, it was forever ago against network infrastructure. And so it's very different, but you know, using something like this for, you know, running back, you know, to the last version of changes is a super cool idea. Being able to alert, like it says, if there's a huge threshold spike on a certain rule being hit all the time, being able to sort of use that as an early warning account for maybe some other nefarious traffic that's going on that you can look. So I do like this a whole lot and it's very, very impractical at the scale for a lot of these network firewalls to be able to derive these metrics yourself from like parsing the logs and different transactions. So this is cool, I like it.

[27:51] Justin Brodley: Yeah, that's super cool. Yeah, initially it was kind of like, this is a snoozer. Then you pointed out the— I don't know, being able to know how many times the rules are being hit is a big deal. And I was like, oh yeah, hopefully you're right. And I kind of put it into Docker context. I was like, yeah, yeah, that's get. So yeah, you know, because I— how many times have you played that game of like, is this rule needed?

[28:08] Justin: I don't know.

[28:10] Justin Brodley: Yeah. So then you get the packet capture out and you're like capturing packets and hoping that something's going to hit it during that window. Yes, this is, uh, much better.

[28:18] Justin: It's really tricky. Yeah, no, it's, it's— I like it. And then sometimes there's, you know, expense to these things too. Like, you've got these rules and they, you know, there's certain— you only get certain capacities per, like, I mean, mostly in WAF, not so much in network firewalls, but you know, like it's a thing that is nice to have when you need the metric to know if it's actually being hit or not.

[28:41] Justin Brodley: AWS is launching their local zone in Las Vegas. We talked about it when it was announced, but it's finally ready. us-west-2-lost-2a. Ooh, just rolls off the tongue. Extending core compute, storage, and networking services closer to the metro area for single-digit millisecond latency use cases. and the zone supports EC2 C7i, M7i, R7i, and C8gn instances with the GB3, GB2, IO1, SC1, and ST1 volume types available for EBS, ECS, EKS, ALBs, and Direct Connect all available to you. Whether there's a Direct Connect going right from this local zone to the SANS Convention Center, then every year blows out, it makes sense for them to be able to do some low latency cool stuff at this year's re:Invent as we knew, I guess. So nice to see this one launch. If you're in the Vegas area, you now have a local zone to play with.

[29:30] Justin: Yeah, it's crazy that they're forking this off of us-west-2. I mean, there's not really another option, but it's like Oregon's so far away from Las Vegas.

[29:37] Justin Brodley: So yeah, I mean, they don't really— like other layer outs have Iowa, you know, more central. Um, but yeah, these guys never have had that. So, uh, you know, they've always been US-East-2 is in Ohio?

[29:52] Matt Kohn: Yep. Right? Yeah.

[29:53] Justin Brodley: So that's still considered east-ish coast, so it's not really central. But yeah, US-West-2 is the one that makes the most logical sense. I mean, you could have done, I guess, off of US-West-1, but no one uses that.

[30:04] Justin: Yeah, exactly. And it, that's already a more expensive region and, and barely more than a local, local zone itself, because it doesn't have all the services.

[30:14] Justin Brodley: Hopefully we can get these guys to go out and party with us in Vegas at re:Invent, you know, get back up those— that's the way to go. Uh, Amazon Bedrock is announcing a reduced pricing for OpenAI GPT-5.6 SOL. They're cutting the pricing for GPT on Bedrock, dropping to $4 per million input tokens, 20% lower, and $20 per million output tokens, 33.3% lower, following similar reductions for the Terra and Luna models.

[30:41] Justin: Yeah, so we've, we've long said that, you know, Amazon prices these things to, to sort of manage the initial load as they roll things out. But I'm just sort of surprised that, uh, an OpenAI model is kind of falling into that pattern. So I wonder if there's more to that story. I mean, I, I'm not gonna argue with cost savings, especially, uh, 20% and especially with tokens, 'cause I'm just always outta tokens these days. And having to manage that very closely. So that's great.

[31:09] Justin Brodley: That's cool. Yeah. I mean, the OpenAI in general lowered their costs as well as we saw Claude starting to lower their costs. So I mean, the price wars have begun between these models and they're all trying now to compete more with Deepseek and the other open models to basically address these type of issues. Well, good to see some price cuts. We'll see if it lasts forever, but for now, Yeah, enjoy your lower token costs.

[31:34] Justin: It's got to be such a balance, right? Because there's capacity is, is still constrained. So like, you know, the supply and demand dictates that the price go up, but then also like it does have a big impact on the user base. I know for me, I have zero interest in running my own model, but token expense was getting up there to give me that one Redis. So I was looking at like, how much would it cost to break even to run my own local version of something.

[32:00] Justin Brodley: Like, yeah, so, you know, running your own models is definitely getting more and more attractive. So if they can counteract some of these things, uh, people will start doing it. Although they'll have data center capacity or power to do it, but different problems.

[32:14] Justin: Yeah, exactly.

[32:16] Matt Kohn: It's not even just the cost, it's if the local one gets so much better. And, you know, from just playing with them, not as much as, you know, Justin, Jonathan, I know, have Ryan, I don't know if you play with them that much, but they've gotten significantly better.

[32:31] Justin Brodley: Matt, I heard you have Cylon completely destroyed the network.

[32:34] Matt Kohn: Oh, all right, I give up.

[32:37] Justin Brodley: You're starting to get a little bit choppy. Your audio is pretty bad.

[32:40] Justin: Yeah.

[32:41] Justin Brodley: Sorry, Matt.

[32:42] Matt Kohn: All right, I'll just listen.

[32:44] Justin: Maybe the local audio will save it.

[32:49] Justin Brodley: Maybe, maybe it will.

[32:50] Justin: I don't know.

[32:51] Justin Brodley: But for us, trying to listen in that way, it's really hard.

[32:53] D: Yeah.

[32:54] Justin Brodley: Yeah, AWS Agent Registry is now providing a centralized searchable catalog for agents, MCP servers, tools, and skills within an AWS environment with approval workflows and both IAM and JWT-based authorizations. Agentic Resource Discovery is a separate open specification released under Apache License 2.0. Those registries across different clouds, on-premise systems, and SaaS platforms describe resources in a common format, avoiding the need to— for custom connectors between each pair of systems. ADOS frames ARD as analogous to DNS, enabling federation across independently controlled registries rather than requiring a single centralized catalog or migration to one platform. The design keeps enforcement local. Each organization retains control over what it publishes and who can access it, with ARD serves purely as an interoperability layer for discovery.

[33:44] Justin: I mean, this is great. I mean, this is— I'm hoping that this gets traction, or at least there's something that Kubernetes, you know, becomes sort of the de facto format for this because it's, you know, like it's just becoming more and more of a problem to, to have sort of agent-to-agent communications with the proper authorization and, and visibility into what's going on.

[34:06] Justin Brodley: Right.

[34:06] Justin: And so it's like within a little ecosystem, it's easy if you're running all in Gemini Enterprise, for instance, you can see all the, the agent transactions that are happening on that within Cloud Enterprise. You have visibility. To see the agent-to-agent transactions. And then those platforms themselves are sort of managing the sharing and who can use those agents. But it's not, it doesn't take a whole lot of imagination to see the future where you're gonna have agents running on, on each of those platforms that then need to hand off tasks between one another. And the only thing that's gonna work out is, is being able to sort of look up information about an agent and derive what what it has access to based off of who's calling it. So the more, more we can provide sort of that catalog where we can some sort of policy enforcement, whether, you know, has that source of truth that can read that agent configuration, is going to be super key. And so like having this registry, like I can see not even being in an AWS workload and still wanting to use this and the Dogwood policies in order to manage it, to manage, you know, communication and authorization across multiple platforms. So I think this is a pretty good, good thing to release and I hope it gets traction.

[35:19] Justin Brodley: Yeah, me too. Well, happy birthday EC2, launched 20 years ago with a single instance type in one region and has grown to over 1,200 instance types across 39 regions, reflecting AWS's expansion from basic virtual machines to specialized compute for AI, HPCs, and Apple development workflows. Uh, the AWS Nitro System in 2017, the Graviton processors in 2018, mark key architectural shifts. With Graviton5 now offering 192 cores and 33% lower inter-core latency, targeting Anthropic AI workloads requiring sustained high-throughput compute. AWS has built a full-stack AI hardware lineup with Inferentia for inference and Trainium for training, culminating in Trn3 Ultra servers that interconnect up to 144 Trainium3 chips for training frontier models at scale. I mean, that's a big box. EC2 FastBox for ML introduced in 2023 now support provisioning in minutes and reservations for up to 6 months across GPU types including P6b300s, and P6b200s, giving customers more predictable access to scarce accelerator capacity. The 2026 Nitro Isolation engine uses a formal verification to provide mathematical proof of workload isolation, addressing customer demands for verifiable security guarantees rather than relying solely on AWS's take my word for it. EC2 remains the underlying compute layer for higher-level services like ECS, EKS, and many more. So yeah, happy birthday. Amazon would not be where they are today without EC2.

[36:36] Justin: No, not at all. As these services get older, like I just, it makes me feel old. Like, you know, this predates me, fortunately, but you know, like it's kind of nuts. Like, been doing cloudy things for a long time now.

[36:51] Justin Brodley: Yeah. I mean, it feels like it's been in my entire career and my career is longer than 20 years, but it's really still a young child, you know, compared to some of the compute technologies that still exist out there, like mainframes. And others. So, you know, it's a, yeah, it's a pretty early technology in the big scheme of things, but yeah.

[37:10] Justin: And it's just crazy to think about like, you know, what the alternatives were before having cloud providers. And so like, you know, a lot of ways EC2 is, I think, you know, to, to blame for a lot of the success between, you know, like there can be an argument for S3 as well, but like I think that someone else running VMs and the networking to make that all work is, I think, what was the initial sort of booster for cloud because it's difficult to run that for a small business. And you know, like it's, especially if you're a single engineer or a couple engineers that don't have, you know, a data center team or something around those lines, you just had the, what was the terrible like hosting of PHP apps before, right? Like it was, wasn't fun. So this is, I think is cool. I love it.

[38:00] Justin Brodley: Yeah, definitely made my career on, you know, helping companies build EC2. So yeah, I was doing fun stuff before it, but definitely doing more fun stuff after. So AWS Lambda now supports full IAM resource-based policies, letting admins define multiple principals and actions in a single document instead of adding permissions one at a time. The update unlocks the full range of IAM condition keys, enabling access restrictions based on source IP, principal tags, or other conditions directly in the resource policy. This simplifies permission management for multi-account setups and multi-service integrations, since teams can now grant several service invokes access via one policy statement rather than maintaining separate entries. Policies can be edited through the Lambda console, JSON editor, AWS CLI, SDKs, or infrastructure as code tools like CloudFormation and SAM. Fitting existing deployment workflows is available to all regions where IAM exists.

[38:55] Justin: Yeah, I didn't hit this particular edge case, but I can see how this would be useful. You know, like I do hate it when I'm trying to use a conditional tag in an IAM policy and it's not supported for that resource. Like that's infuriating and it happens in odd times and there's just edge cases everywhere where that's the case, especially for Lambda functions not being able to gate permissions conditionally on incoming IP address, I can see how that's a real big problem for certain workloads. And so I, this would be a great thing for people to use either as like an additional security check for that conditional or being able to sort of, you know, have a broader set of principles defined by, you know, an asterisk that as long as it's coming from our internal trusted network, we can do something internally, which is cool. So I like that and I can see, usefulness of this.

[39:45] Justin Brodley: Yeah, I mean, I definitely have thought it was weird some of the ways that you do like things with Lambda, with IAM, and, you know, definitely ran into some of those edge cases, you know, on newer services trying to get Lambda to be able to access them and then not have the security concept. So maybe this also helps unify some of that on the backend. So it's one IAM solution versus a slightly scaled-down version for Lambda. I don't know, we'll see. But, uh, Definitely interested to see how this one evolves. ECS now automatically detects agent connectivity failures caused by infrastructure issues like EBS segregation, host thermal events, or network problems, surfacing a new agent connectivity health event across Fargate, ECS Managed Instances, and ECS on EC2. For Fargate and ECS Managed Instances, recovery is fully automated. ECS will drain the running tasks, deregister the impaired service, and launch replacement capacity without customer intervention. ECS on EC2 customers don't get automated automatic remediation, of course, but can consume the new health event to build their own instance replacement workflows, giving them more control while still improving visibility into agent-level failures. This addresses a gap where connectivity loss between the ECS agent and control plane could previously go undetected, leading to silent workload failures without clear alerting.

[40:53] Justin: Yeah, remember last week we were talking about, you know, the EC2 health checks and how we abuse terrible things? It was exactly for this.

[41:00] Justin Brodley: Yeah.

[41:03] Justin: Yeah, so this is, you know, it's funny that it's still not automatic remediation on EC2 'cause that was exactly what we were enabling as well, which is the ability to sort of nuke a container hosting instance and have it restart. And so like, it's weird that they didn't put that in 'cause it's not that hard to do, but I guess that does really rely on an auto scaling group technology, so that's probably why. But yeah, no, and I think as Matt was referring earlier too, the terrible policies we're running into, weird conditionals and running out of policy constraints was also with this project. So it's pretty funny. It's all kind of coming together. Amazon finally fixing issues that Matt and I had a decade ago.

[41:42] Justin Brodley: Amazon's AI is kind of fixing issues. Yes. Product manager approved this for feature development. Like, well, this doesn't grow revenue. It doesn't do anything.

[41:51] Justin: It's just, yeah, it's just quality of life.

[41:54] Justin Brodley: Quality of life.

[41:55] Justin: Yeah.

[41:57] Justin Brodley: Moving on to Google. If, uh, you've been patiently waiting for Google Anti-Gravity to come to your enterprise account, uh, it's finally here. The agent encoding platform announced at I/O in May is now bundled into eligible Gemini Enterprise Standard, Plus, and Standard emerging market subscriptions, eliminating separate licensing, billing, and Admin Console management, uh, for AI developer tools. Or if you're a Google Workspace shop, you could also buy like the most high-level version of Google Workspace ever. To get the sphere. The new IDE extensions bring Antigravity into VS Code, Visual Studio, JetBrains, and Zed alongside the existing Antigravity 2.0 desktop app and CLI, letting developers work in the preferred environment rather than switching tools. Enterprise cost controls include pooled token quotas across teams, project-level spend caps set in the billing console, and optional overage handling with monthly spend limits addressing finance team concerns about idle prepaid tokens and runaway usage. Security features consolidate under the Gemini Enterprise admin console, including workspace sandboxing, GCP server access controls, single-tile audit logging, and support for workforce identity federation and application default credentials for identity management. Early adopters cited in this include Accenture, AirAsia, CGI, Cognizant, and many more.

[43:09] Justin: Yeah, I just still haven't used Anthra Gravity, so I don't know how impactful this is. Like, I'm I'm guessing it's more like a cursor-based browser where it's a little bit more—

[43:19] Justin Brodley: I mean, originally it was an IDE and there's an Antigravity IDE, but then it's turned into more of a AI, you know, chat system that's more like Claude Code over the last few months is my sort of, you know, I don't use it a lot, but as I open it, that's sort of my following on it. It's like, oh, we're now doing more like we embed the smarts of Antigravity into any place you want to do the code writing, just like you do with Cloud Code. And now, or you can use our IDE if you prefer that, or your own IDE if you prefer your old IDE that's busted compared to them. So that's your choice.

[43:53] Justin: I mean, it seems like everyone's sort of copying that Cloud Code model because even, uh, you know, GitHub or yeah, VS Code Go Pilot is, uh, absolutely like they have this new agent, agent mode, which is, it's just Cloud Code. You know, like it's, it's exactly the same thing. And so whether, if you don't want, you still open your IDE to get into agent mode to do coding. But the only reason I like, uh, Copilot or VS Code Copilot is that I get to see the changes directly in the source code and interact with it. But not everyone's a nerd, I guess. Not everyone has, or paranoid as Matt says, cause I am.

[44:30] Matt Kohn: Yeah.

[44:31] Justin Brodley: Yeah. So not everyone's as paranoid as you are.

[44:32] Matt Kohn: That's really— yeah.

[44:35] Justin Brodley: Uh, well, also on the Gemini Enterprise feature set, they're releasing two specialized Gemini Enterprises, one for financial services and one for legal teams. The financial services one targets capital markets and corporate banking workflows with four components, purpose-built skills, MCP connectors, and a Juntik financial research agent and a partner ecosystem, all governed by control plane-enforced VPC and CMAC policies. The financial research agent ships with more than 50 foundational skills and provides confidence scores explicit methodologies, data snapshots, and source citations for audibility, addressing the need for verifiable data lineage in regulated environments. And then the legal version gives you the same type of capabilities, but the platform connects to existing legal tech stacks including IAManage, NetDocuments, DocuSign, Everlaw, RelativelyOne, and Thomson Reuters IQ, and research tool— research tools like CourtListener inheriting existing permissions rather than requiring new access models. Current workflows there include contract review and redlining, DSAR fulfillment, regulatory horizon scanning, playbook generation, and litigation document redaction. So this is a tool for agentic execution rather than simple query responses. So Google had talked about building models specifically targeted at different business sectors a couple years ago, but it sounds like they've pivoted over to giving you a very custom wrapper around Gemini Enterprise to add in these specialized tools. So interesting approach, and, uh, I'm sure we'll see a bunch more of these coming out over the next couple months.

[45:55] Justin: Yeah, like, this is kind of when they talk about the, the, you know, the industry-specific models, I, I wasn't really sure about the use case. Like we talked a little bit about financial just 'cause of our day jobs and, and the need there. But like it's more and more people aren't using a whole lot of custom models. They're using, you know, different things where they're enhancing the metadata. And this is, I think I, I like this a whole lot. I think I can see this being very powerful and replacing a ton of, you know, apps on the marketplace for, 'cause this'll make it a little easier to, you know, you don't have to build your own full app. You can sort of have agentic sort of chat conversations to review your financial data, or you can have chat, you know, to get legal assistance, like maybe look up sites or, you know, for cases or determining like, you know, whether there's precedence for in other case law that's harder to find. And so like, I think that these are, pretty powerful. And then the integrations are gonna be super key, which is always, you know, always the case with AI. Like AI is only as powerful as the data that it can access and manipulate and how it does that safely is key. And why I like having Agentic workloads run on these like enterprise-level systems. And so I can see for these specialized, you know, areas, those applications that are being integrated with are very specialty and there's probably a lot of visibility and concerns. For both finance and legal. So it makes a lot of sense to me.

[47:26] Matt Kohn: Yep.

[47:26] Justin Brodley: I mean, there's all kinds of things with legal stuff too, where, you know, potentially your AI chats can become part of case, uh, you know, part of evidence and things. So there's lots of, uh, special controls in some of these spaces. They're being able to get, you know, think about the regulatory frameworks that apply to legal and to finance data. There's lots of opportunity for specializing some of these tools. Now I get into this weird place with some of these where I'm like, okay, so you're at a company and you're in the legal team and you want this legal Gemini for Enterprise, and then you're in the finance team and you want the finance tool. And like, do you end up with like a bunch of like license, um, specialization or is this something where I can enable like these as roles to people? Like, so I have some implementation questions that I would ask Google if I had a chance to, but On the surface of this, I really like this, but I don't want to license 3 different products. Gemini Enterprise for normal people, Gemini Enterprise for legal, and Gemini Enterprise for financial services. Hopefully these are just things I can enable on a per-user basis.

[48:26] Justin: Well, yeah, and hopefully they don't bundle them. And, but it, you know, if they are completely separate SKUs and at least maybe they'll give you a price break on licensing all 3.

[48:36] Justin Brodley: Uh, I don't think that's going to happen.

[48:38] Matt Kohn: Nope.

[48:38] Justin: Me either.

[48:40] Justin Brodley: Google is very proud of Gemini, I can say. Yeah, it's not cheap. Uh, they have not gone onto the price war that we talked about earlier.

[48:47] Justin: They have not.

[48:48] Matt Kohn: No.

[48:49] Justin: So, um, yeah, I mean, they're offering a lot of Gemini Enterprise for free on the internet, and, and so I think that they're, that's where they're investing.

[48:57] Justin Brodley: They're free. Their money is going to free, as you hope.

[49:00] Justin: Yeah.

[49:02] Justin Brodley: Moving on to Azure, and you know, Matt's listening in here, but, uh, we kill all your stories. Because they were terrible. So we only kept one. This feature lets Azure Gateways advertise a single Sunrise prefix like 10.0.0.0/16 instead of hundreds of individual spoke virtual network address spaces to on-premise networks, addressing route limit constraints and large hub and spoke topologies. Supported on both the ExpressRoute Gateway and VPN Gateway and works across IPv4 and IPv6, giving customers flexibility regardless of their connectivity method. The key benefit is scalability, of course, and backwards compatibility is reserved. So if you have already typed in all those addresses, you don't have to untype them, you can just leave them there.

[49:38] Justin: So, yeah, it's funny because we mainly kept this in here just so that we can sort of sympathize with, you know, our Azure users who have to use this, because it's, it's, you know, in, in line with a lot of the network releases for Azure in the last, what, 2, 3 weeks, where it's like BGP routing policies and, and internal east-west routing policies, and now there's this one. So like you can see where the pain points are for, for these customers, like for all these things. And so like, it is sort of a pain if you have to define every single VPC as its own little route to advertise to a data center, you know, who needs to connect to all these things in virtual networks. So combining the two things together is, it's hard. And, uh, I definitely am glad I don't have these problems anymore because I don't have a big data center in the sky or a huge workload that has to go across multiple clouds or data center and clouds, hybrids.

[50:35] Matt Kohn: Yay.

[50:35] Justin Brodley: Yep, that's the problem you have. Yeah, I might have this problem, I'm not sure.

[50:40] Justin: Yeah, you do, you just don't know it yet.

[50:46] Justin Brodley: Uh, in our emerging cloud section, we have something from CloudFront here. They're moving OAuth consent from all or nothing to task-based scope selection, letting users deselect optional scopes at authorization time rather than approving an app's entire requested permission set. The use case driving this is MCP servers and agents, of course, which often request broad permissions an agent could theoretically use, even though most users only want to grant a narrower subset of their, their specific task. Developers configure clients as scope list and optional scope subset. Required scopes are still enforced, but users can opt out of the optional ones during consent, and evaluation only applies to scopes actually requested in that specific auth flow, not the full client configuration. This changes the integration contract for developers. Apps must check the granted scope set after code exchange rather than assuming the full request was approved. So agents integration need to handle partial grants gracefully, which they won't. Backward compatibility observed since clients that don't opt into optional scopes see no change of behavior. And CloudFront plans to expand its account and zone level role surface to cover more products, additional API token roles, and OAuth scopes. I mean, overall, I like the idea of this because that is one of the problems with OAuth is, you know, if you are giving a third-party service access to this thing through OAuth and it's the whole permission set and you don't want to, there's no choice. There's no recourse.

[51:56] Justin: And scopes are hard, right? Like, do I need this scope for when I'm setting up this client, which is typically, you know, not once your application's tried and true and like well-worn all the pathways, like it's something you set up at the beginning. And so in order to not just shut down your entire workflow, you typically, you know, like either you grant every scope, which people do, or, you know, you grant scopes in, in the hopes of like you've covered them all. And it's not very least privileged. It's better than full access for sure. And so I like the idea that at the client and initiation sort of deselecting optional scopes is making it an application concern, which is neat. Although it's a little strange, like, 'cause it's—

[52:41] Justin Brodley: You're trusting the app, right?

[52:43] Justin: Trusting the application, which is typically the thing that you're giving, like, trying to figure out, like, you know, like in a perfect happy path world, great, this is awesome. But in, in an exploit world, isn't the client just always gonna request more scope if they're up to no good?

[52:59] Justin Brodley: So, and also, like, I don't know how, like, okay, so I granted you 3 things, but now I ran into a different use case where I need the 4th thing. Like, how do I reforce the authorization flow? You know, you had to build all that into your app now.

[53:12] Justin: It's a nice all that work. So, and the client setup on the other side is probably going to be fully scoped, right? In order to support that.

[53:20] Justin Brodley: Yeah. So there's definitely going to be some weird edge cases or something like this, but I think, you know, granularity is still good. So implementation will be where it gets a problem.

[53:31] D: Yeah.

[53:31] Justin: Yeah. Uh, all right.

[53:33] Justin Brodley: Well, that wraps up our week in news. Once again, glad to be here with Ryan and maybe Matt, who is driving 70 miles an hour trying to talk to us on a podcast. He's committed like that.

[53:45] Justin: So we appreciate you, Matt, uh, even though your audio was terrible.

[53:48] Justin Brodley: So see you next week here on The Cloud Pod.

[53:51] Justin: All right, bye everybody.

[53:54] D: Another week of cloud news wrapped up. Bolt will collect the news. Justin will get the notes. Jonathan will write some code. Ryan will watch the perimeter. And Matt will reluctantly watch Azure till next week for AI, Amazon, Google Cloud, and Azure. And hey, maybe even Oracle, who knows? Check out TheCloudPod.net for our newsletter. Join our Slack, message us on socials, or leave a review.

[54:27] Justin Brodley: So this morning Apple dropped new Mac Minis and Mac Studios. Which, whoo-hoo, I think we've talked about on the show that I've been kind of patiently waiting for the new Mac Studio to come out to see what they're gonna do for AI. And you know, and at the time I was thinking about it, I was thinking about buying the same processor GPU thing that Jonathan has where he, you know, he runs basically a workstation-grade GPU in his home computer and he runs all the models locally and he's a nerd like that and he enjoys it. And I also wanted to kind of get on that plane as well 'cause you know, I still think tokens are heavily subsidized and we're likely going to end up paying more for them. Although, you know, right now tokens are going down in price, so maybe I'm wrong. So yeah, so I was hoping for a new Mac Studio. Of course, that was before hardware and memory prices just continued to skyrocket through the world. And so at that time, I think it was like $12,000 to build my own custom workstation. I was like, well, the Studio probably won't be that expensive. Uh, well, I was wrong. It's, uh, the new refresh for Mac Mini and X Studio have two new chips, the M6, which is the first 2-nanometer chip in the M series and the M5 Ultra are positioned as the most capable chip in the lineup for AI workloads. Uh, the update is primarily a specs bump rather than a redesign, but Apple's marketing signals a deliberate focus on local AI inference. Uh, so that's good, means Apple realizes people want to use this. macOS 26.02 enabled low-latency Thunderbolt 5 communication between hosts supporting distributed AI inference via the MLX framework, which lets multiple Macs be networked together to run larger models than a single device could handle. And this positions Mac hardware as a lower-cost alternative to specialized NVIDIA GPU setups. And then I priced it out, and you know, the M5 Ultra Mac Studio with 256GB RAM is, uh, $12,300. So should— Purview a while ago, I went in cheaper. Uh, and then they're having a 512GB version coming out, uh, later this fall, but I'm sure that was going to be like going to cost a small, uh, car to basically buy. Uh, but you know, we need, we need some more people to come and sponsor the show so I can afford one of these bad boys. Yeah, right.

[56:26] Justin: Uh, but you'll do ad reads. We, we will do a lot for a Mac mini, it turns out.

[56:32] Justin Brodley: So yeah, exactly. If you just wanna send us some Mac Studios, you know, that's fine too.

[56:36] Justin: That'd be okay.

[56:37] Justin Brodley: Yeah. We'll, we'll take that as well in lieu of payment.

[56:39] D: Yeah.

[56:39] Justin Brodley: Mm-hmm. We'll read your ad for a while and then send us a Mac mini. Uh, but yeah, so the, uh, M6, uh, of course is pretty nice as well. That first 2nm chip, uh, those are showing up in the Mac mini., for all those people who like to run OpenClaw on the Mac mini. Uh, those aren't cheap either though. Uh, you know, the, uh, the one with, you know, the higher end one, I think I saw was like almost $3,000 for a decent AI configuration. And then if you go with a cheaper option, you can get it for the starting at the $899, which seems to be the promise of the Mac mini. But that one has 12 CPUs or 12 CPU cores and 12 GPU cores. So it's not anywhere close to the M5 or the M6. For true AI workloads. So you're definitely not running the model locally, you're definitely still using a third-party service for the model, uh, on that Mac Mini if you're doing that path. So good to see though.

[57:30] Justin: Yeah, I mean, it's, it's funny because it's sort of, you know, I've been playing around with this more. We talked a little bit on the show like with the, the cost of these things, and you know, some— I always get like annoyed when I'm like, I waste tokens on like going down some random path. And so I feel like if I could have like a local sort of system that's sort of the front part of that and then outsource to cloud models as I need for different questions or I don't know what I would do. But, um, like I, you know, I like the idea of having something local and, and something that's not, you know, going out to the internet. I can keep all my data private, but, oh yeah. I mean, if you want to pay this much money.

[58:08] D: Yeah.

[58:08] Justin Brodley: Yeah. Something before the Trump administration basically prevents you from using open models. Which they were, there was some chatter about in the news last week, you know, like, oh, I just downloaded now. I don't have to worry about them shutting it down, you know, for current models at least, you know, future ones I won't be able to access. But yeah, it's, uh, could get interesting in the AI space for sure.

[58:26] Justin: Yeah, no, I mean, it's just, and it's just crazy cuz yeah, it's, I think that I'm speccing out my Mac Mini and it's, yeah, it's, it's $2,500.

[58:35] Justin Brodley: Uh, I, on the Mac Mini, I think you can get the M5 Pro and then the M6. The M6 are the lower powered ones than the M5 Pros. It's also in MacBook Pros right now, so it's, it's a reasonable upgrade. But yeah, the higher powered M6s on the 2nm core are not out yet.

[58:51] Justin: They're not out yet. And there's, uh, memory, memory limitations. So you can only get up to 32GB of RAM. Can't go up from that with the M6.

[59:00] Justin Brodley: Oof.

[59:00] Justin: Yeah, that's small. Mm-hmm.

[59:03] Matt Kohn: Yeah.

[59:03] Justin Brodley: I mean, the 256, you know, on the, on the Mac Studio. So just getting the, the M5. Ultra chip, uh, with the default amount of memory that comes in the system is $6,700. And then if you want— that's with 96 gigs of RAM. If you want to go 256, it's an additional $4,000. So I imagine to go to 512 in October, it'll cost another $4,000. Yeah, yeah, memory is, uh, expensive, unfortunately. So it's GPUs, it really is. Yeah, never, never was faster. It never really recovered post the, uh, you know, pandemic and coming back down to normal price. But I mean, a 96GB one isn't terrible, but you really— to be able to do the GPU, you know, to load the models into memory, which is really neat for performance, you're going to have to get more memory than 96 for some of the bigger models. Uh, you can do like the QuenCoder and some of the smaller DeepSeq models will fit on 96 gigs, but you're at least looking at 256, and you really probably want 512.

[60:03] Justin: For memory, for loaded into memory, you can get the smaller QIN models will run on 24, but you know, like you're, well, you know, it's what can you do with those models at, at what speed, right?

[60:13] Justin Brodley: And it's just not, right.

[60:14] Justin: I mean, you know, I, and so I haven't really played around too much with personal, but I'm doing the research trying to figure out what my price point is. And so it's like, okay, you know, I still, in order to get, you know, like an old 3090 GPU card, like it's still $1,500 to $2,000 something that's, you know, less cores than right now and just 24 megabytes of RAM and you know it's not gonna run half the models that are out there and I'm already up to like $3,000 to build my own computer for that. And it's just sort of like, that's nuts.

[60:45] Justin Brodley: Yeah. Yeah.

[60:48] Justin: Like it makes the Mac mini price not so unreasonable. Like it's sort of like, okay, well, yeah, I mean, the GPU card is, is, is $2,000 by itself. This Mac mini is not too crazy.

[60:57] Justin Brodley: Yeah. I mean, it's, it's not as bad as you would maybe worry about, but it's still, yeah, it's still pricey.

[61:04] Matt Kohn: Yeah.

[61:04] Justin Brodley: Yeah. Comparatively to the Windows boxes or Linux boxes running the same thing, it's, it's not that crazy different. That is a true statement. Mm-hmm. Yeah. The, uh, the 4000, the RTX Pro 4000 and 5000 and 6000s, I think the one that, uh, Jonathan recommends is the 6000, which only requires a 300-watt power supply to run, which is nice. Those bots, those guys are, are not cheap.

[61:29] D: No.

[61:31] Justin: Yeah.

[61:32] Justin Brodley: Well, uh, I will, uh, keep hoping to get some more sponsors to get my new Mac. Yeah. Or about this new leasing option, which I'm sort of intrigued by. I can very lease it for 36 months for $150 a month. So maybe, maybe it isn't as bad, uh, because $150 a month, I could maybe do that.

[61:49] Justin: I don't know.

[61:50] Justin Brodley: I don't know if I want to lease hard work. It's a—

[61:52] Justin: what a weird idea. These really are turning into like cars, right? Like, at this point, like, they cost as much as a car, and then now you're leasing them like a car. You're gonna give them back.

[62:02] Justin Brodley: I mean, I— looking at cars right now, I can tell you that lease prices are not that cheap.

[62:06] Justin: No, they are not. As someone who is—

[62:08] Justin Brodley: nor car payments right now either. Like, I don't— I mean, I know cars have gotten more expensive, but like, even cheap cars seem to have really expensive car payments. I'm like, I don't really understand.

[62:17] Justin: I think there's all the GPUs and memory that's in them now.

[62:20] Justin Brodley: I think that, I mean, the price, like if you look at the price, like, okay, so let's say a $50,000 car today versus a $50,000 car back in, you know, 2010, like the, the car payment, because the interest rates were so much higher, is just crazy. Where before it was like, I mean, I know it's mostly, it's mostly interest rates, but you know, and probably lack of incentives from manufacturers and things cuz everyone's struggling.

[62:44] Justin: But yeah, and you're getting a lot less luxury for that money too, right? Like, it's— I mean, they're normal cars with their plastic interiors and stuff like that, or, or $50 grand, you know, starting there. And then it used to be get a nice Mercedes for $50 grand.

[62:56] Justin Brodley: Yeah, yeah, $50 grand in 2010 was, you know, yeah, practically a luxury vehicle. So compared to what you get for $50 grand now, which is plastic interiors and, yeah, a V4 that barely putters up a hill. So yeah, so different world. All right, I will see you next week.

[63:13] Justin: All right, yeah, have a good one.

[63:15] Justin Brodley: Bye.