Open-weight models: What are they and when should you use them?

Transcript

Ken Mugrage: Hello, everybody, and welcome to another edition of the Thoughtworks Technology Podcast. My name is Ken Mugrage. I am one of your regular guests. Very happy to have two folks from Thoughtworks specialize in some of our AI and platform things. I'll let them introduce themselves. First off, Caer Sanders, you want to go ahead?

Caer Sanders: Of course. Thank you. Hello, everyone. I'm Caer Sanders. I'm a principal product engineer focusing on AI and agent platforms at Thoughtworks.

Ken: And Andre Almar.

Andre Almar: Hello, Ken. Thanks for having me here. It's a pleasure. My name is Andre. Right now I'm working as a lead consultant inside the data and AI service line.

Ken: Great. We actually want to talk about open-weight models today. It's been something that's been a very hot topic for a variety of reasons that we'll get into, not the least of which are financial as well as just control of your own data and all of those things. I think first off, just so we're on the same page, because this is, like many terms, very overloaded, at least for the purposes of this conversation, and Andre, I'll give you a first shot, how do you define an open-weight model? What's it even mean?

Andre: Sure. I like to explain this using an analogy. For example, let's imagine that you sit down at a five-star restaurant. You order the dish, eat it, enjoy it, but you don't know the exact recipe. You cannot step into the kitchen, and you cannot tweak the dish. These are what we call the closed-weight model so things like ChatGPT, GPT-4o from OpenAI, Claude 3.5 Sonnet, Opus, Fable from Anthropic, Gemini from Google, et cetera, et cetera. You can only interact with these models via a website or an API. There is also an open-source code so PyTorch, Megatron by NVIDIA, vLLM. These are framework software tools and code-based frameworks used to train or run models.

Then, specifically talking about open-weight models, this would be the pre-cooked dish plus the full recipe. The original chef of the restaurant that you just spent millions of dollars and weeks cooking a massive meal. They package up, they finish the dish, and hand it to you, but they hand it to you along with the exact step-by-step recipe and ingredients list, so the weights. You can eat it right away, you can host it in your own house, you can toss in extra spices, change the flavor, whatever you want. The real world examples of that, bring it to the world of AI and machine learning. It will be models like DeepSeek, GLM, that Caer knows a lot about, Llama from Meta, Qwen from Alibaba, and so on and so forth.

Ken: Is it all financial? Is it access to the data? Is it tuning? Is it all of the above?

Andre: For example, using the open-weight models, you can download the file, the model containing the billions of weight numbers, because they are all trained. You have models with different parameters, like 30 billion parameters, 7 billion, 20 billion, you name it. You can use those open-weight models to run it on your own server, like Mac Minis are hot today because of that. You can run in your own laptops without needing permission from the original creator. You cannot take a closed-weight model like Fable or Sonnet from Anthropic or GPT-4o, 5.5, Sol from OpenAI, and run it in your own machines, but with open-weight models, you can do that, no problem.

Ken: I think I know the answer, but just for our listeners' perspective, why? Why can't I take their models and run it on my machine?

Andre: There is a financial aspect to this as well. For example, when we are talking about closed-weight models, we can only interact with these models via website or API. The creators of these models keep the training code, they keep the weights, they keep the parameters, but these are all locked in their own service. These are for economical reasons as well. We are getting more and more conversation about the AI FinOps, so to speak, because it's getting more and more expensive to use those API calls and to use those closed models from providers like OpenAI, Anthropic. That's why lots of companies right now, including ours and others out there, are taking a very close look at these open-weight models to run it in-house.

Ken: Why would anybody choose a frontier model then or maybe can somebody define frontier models for me?

Andre: Using the food analogy, for example, OpEx versus CapEx. OpEx, it will be the equivalent of ordering food delivery. You are renting access to closed models like OpenAI, Anthropic, Google via APIs. You pay a tiny fraction of a cent per input and per token, essentially. The advantage is zero upfront cost. You don't need to buy expensive computers, hardware, or have a farm of Mac Minis in your company or pay massive electricity bills. You just pay for what you consume, so pay per use, basically, but with a caveat.

As your application grows from hundreds of users to millions of users, your monthly bill grows linearly. A little spike in traffic.

This translates directly to a massive recurring monthly cloud bill, so that will be costly for you. On the other hand, if you want to use an open-weight model, it's the equivalent of "Okay. I'm not wanting to order food anymore. I'm going to build my own commercial kitchen," so to speak. You make a large, potentially one-time investment in local physical hardware. This includes buying desktop, supercomputers like NVIDIA DGX Spark or Mac Studio, Mac minis workstations with unified memories, or even full enterprise GPU server racks.

The advantage is that once this hardware is paid for, running inference on an open-weight model like DeepSeek or GLM, this costs virtually nothing beyond basic electricity. Your cost per token drops to near zero. There are also other technical advantages, like the latency is lower because there'll be no round trips on network or third-party servers. Sensitive data stays entirely inside your building on your machine.

Caer: The other reason people use frontier models, though, is that, let's say Anthropic and OpenAI are some of the most familiar frontier models that we associate with them today, they have incredible funding and incredible researchers and an incredible head start. Those models tend to be more performant and more capable than the open-weight models, which have generally smaller funding, smaller teams, sometimes unpaid teams, that kind of thing.

For a long time, frontier model has directly equated to the best model. As we'll probably talk about over the past year with DeepSeek and the GLM series and the Qwen series, all of these models are starting to catch up rapidly to frontier. Now the conversation is shifting away from good model versus bad model and more towards model that somebody runs for you and model that you can run yourself.

Ken: How close is that gap now? I have to admit, as a user, I use these things, but I don't deploy them. I tend to want to use the most expensive model available always because, like most capitalists, I equate trust with cost. [laughs] What does that margin actually look like as far as efficacy?

Caer: I will say I am guilty of only using Fable when it's available to me and not using Opus or Sonnet or Haiku. What I've noticed recently over the past few weeks, I started to play with the GLM-5.2 models, which 5.3 has made waves for being almost as good as Fable, if not as good to the point where there's some controversy about, "Did they try to distill things from Anthropic and learn how they did it from the outside?" That's a little sketchy if they did that. Either way, that's an open-weight model that competes for performance with Fable potentially.

What I'm noticing in my own work is that the open-weight models are getting to a point where for most general tasks like searching knowledge, summarizing documents, or writing very well-scoped and well-defined code changes, the open-weight models are just as good, at least as Opus, maybe as good as Fable in some cases.

Ken: What does it take to run some of these? I early on tried to run some of it on my MacBook. I have a pretty decent MacBook, 48 gigs of RAM and the big processor, the big GPU, and most of the larger stuff couldn't even start unless I didn't know what I was doing, which is equally as possible. What's it take to really run these?

Caer: I will say these models, the ones that are truly competitive with frontier models like Opus and Fable, you're going to have a hard time running them on a private computer. If you have a specific kind of Mac Pro that has say 500 gigabytes of VRAM available to it, which they exist, but they're unavailable and unobtainable now for obvious reasons, if you have one of those, you could run these models locally. If you have a powerful Mac minis like Andre was saying, you could potentially run one of these with distributed inference, but it'll be a lot slower because it's having to do consensus and all the firm problems that come with a distributed system just to get you tokens.

What I do, and probably a lot of people do, is you can run open-weight models off of other cloud providers. You're still paying for your tokens, you're still paying an amount of money to do inference, but you are paying a lot less upfront than having to buy a GPU, for example. Generally, you're paying a lot less than you pay when you're using a frontier labs models. As an example, these aren't the actual numbers, but Fable feels like it would be $20 for a million tokens, whereas an open-weight model might be $1 by comparison. The actual numbers, who knows? It's that kind of difference that you see.

Ken: By way of experiment, I was generating some Word documents earlier because that's the format I had to deliver in, the person that needed the documentation. I got notified by, in this case, Claude Opus that I was nearing my monthly limit, which I don't generally approach. I have a pretty decent limit. I looked at it, and it was charging me $5 per doc, was basically what it was running. I dropped it to Sonnet, and of course it was a lot less. This is also something that I can't risk quality on. Are there experiments that you can run? Are there proof points? How do you identify a good model versus bad model? Is that even a fair thing to say?

Andre: I think in your case, in your example that you just said, for tasks like coding assistance, basic writing, document summarization, quick chat test, this kind of ordinary stuff, you can do this pretty much using compact models like Llama, Qwen, a distilled version of DeepSeek, something between 7 billion to 14 billion parameters. The only hardware needed, you need a standard GPU, anything between, I don't know, 10, 12 to 16 gigabytes of VRAM, like the RTX 360 from NVIDIA. You can also run on the Apple Silicon chips as well, Mac Studios, Mac Minis, whatever. If you have anything between 24, 32, 48 gigabytes of unified memory, you're good to go. Also, for those type of tasks, a compact model will work seamlessly, I would say.

Caer: Anecdotally, like in our engineering teams, more sophisticated engineering teams will set up evaluation harnesses for their models so they can AB test different kinds of model architectures, whether it's going from Claude Haiku to Claude Opus or going from a Claude family model to GPT to GLM. Those evaluations you could do a whole podcast on because there are different kind of problems than conventional integration testing where there's one right answer.

Usually with LLMs and models, there's a broad spectrum of right answers and you want to make sure that whatever it's doing falls in that spectrum. It's a harder challenge, but that's what some engineering teams do is set up these harnesses. On a personal level though, when I'm looking at, do I want to use Opus for this change or Fable or do I want to risk it on GLM, I usually look at how well the model handles uncertainty because when I give a task to an experienced human engineer and there's uncertainty in that task, they'll ask me for clarification, they'll ask me questions about it and they'll try to minimize the assumptions they make.

What I found is that the less performant models make many assumptions and often they're disastrous assumptions. The more performant models make less assumptions and usually ask for clarification. If the model's asking me for more clarification and making less assumptions, I feel more confident using that model for a given family of work. If it just does it and doesn't even ask, I'm like, "Maybe I'll use a smarter model next time."

Andre: Let's say that nowadays, Caer, it's up to the user to choose or to do this kind of thinking on, "Okay, this model is good for this, that model is good for that." I think that maybe we're going to achieve a time that automatically the harness will choose, "Okay. This is a simple coding task. I'm going to use, I don't know, Llama local in your machine. Oh, this is like I get into part of the code that I need to run a complex task here, multi-step coding, deep analytical math or whatever, structured data extraction. It’s better to use a Fable or Sonnet for that. This is a problem that is still to be solved.

Caer: It is. To your point, like Claude Code right now, if you use it, it will do some of that internally. It will delegate your tasks to weaker models and make a judgment call on, "Could this coding be done by Haiku, or Fable, or Opus?" It is still not super advanced yet. It feels like you are rolling the dice every time you call it.

Ken: Another somewhat related topic, and this could definitely be a podcast or 12 on it, is around AI safety, and security, and all of those things that it is. I know when-- Gosh, it’s been 9 months already, or 10 months or something when OpenClaw came out. It came out right before a large event I was going to, and someone was talking about how they had done some pretty sketchy things with it, frankly. Some of that, if I had asked an Anthropic model to do it, it would have just flat declined. What are our concerns there with people using some of these models? There’re always going to be bad actors, so don't get me wrong. I’m not saying that OpenAI is the antidote to bad actors. What is being done to make sure that society isn’t being threatened by some of this stuff?

Caer: I know on the vendor side, if you’re using a Claude Code or Codex, one of the frontier-style, again, goes out to the frontier every time, they are trying to implement tons of guardrails in their systems so when you ask it to do something dangerous, it will decline, or it’ll at least be like, "Are you sure that you want to do that?" As an example of how far these guardrails have come, originally, when Claude Code came out, you had to hit confirm every time the model tried to do a specific action on your computer or make a specific code change. The idea was that, as an engineer, as a user reading it, making sure it looks legit and saying okay.

Then, pretty quickly, people started to turn on YOLO mode, which meant that the model could just go and not ask ever, which led to a lot of people to delete their computers and do other kinds of horrible things to their systems. Anthropic tried to double down on guardrails and try to make it so the model could predict when it was making bad choices sooner. That work has gotten to a point, at least for Claude Code, where I think it was last week or the week before, they changed the default feature in Claude Code so that it now accepts edits and runs autonomously without almost any clarification because it has gotten to a point where they trust it enough for users that it will do the right thing and not destroy your system. That’s for one frontier lab. That’s not for all labs.

The general discourse comes back to guardrails, guardrails, guardrails, and also the lethal trifecta, which I think we have-- I do not know if we talked about on the podcast before, but it’s the idea that a model should not simultaneously be able to take privileged action and also have access to privileged information. The two features should be separate. There is a third component of it that I forget the exact definition of. I think it was Simon Willison that coined it a few months back. That is a key thing is trying to separate, functionally, the concerns of how your agents interact with the world so they can’t both read all of your emails and send random strangers DMs on Slack or BlueSky.

Andre: There is potentially a hidden malicious prompt on public skills or plugins, especially with the advent of OpenClaw. Of course, as you well said, Ken, malicious actors are everywhere. They can publish helpful-looking skills, but those skills secretly contain hidden system backdoors, credential stealers, this kind of stuff. We need to be very aware.

Ken: You were talking about models earlier, and you were talking about billions of parameters and still joke, a billion here, a billion there. Sooner or later, we’re talking about real dollars. What’s a big model, and what’s a small model for some of the listeners? Because these all sound huge.

Andre: At least from my perspective, I would say that a small model is something between 1 billion parameters to 14 billion parameters. There is medium ones between 15, 16 to something like 67 billion, and larger models that could be hundreds of billions. of parameters. This is not written in stone, but this scale is mainly categorized in those tiers, and specifically based on the parameter count, and also hardware requirements and practical use cases. For a small model, if you can run in your local machine, this could be considered a small model. That would be my take to easily explain to a user. "Oh, I want to run on my MacBook that has 48 gigabytes of RAM, a large model with 400 billion parameters." Good luck with that.

No, you're not going to do it. You're going to need a high-spec farm of Mac workstations, a cloud infrastructure, or multi-GPU setups in order to do that. When we say large models, we are not even talking about those very large frontier models. Those frontier models have trillions of parameters. They need way more compute power in order to run. That's why those companies are building data centers everywhere.

Ken: I asked because a friend that works for a bank, and his boss, who is very technical, was like, "Well, why are we paying Anthropic, or OpenAI, anything? I read the other day that you can just download DeepSeek." It's like, "It is not quite that easy." [laughs] When pushed back on, his response, I guess, was, "Look, I have enough problems keeping up with the banking regulations that I need to do IT in my industry. I can't keep up with what it takes to run it." Are there rules of thumb or resources or anything you can recommend where people can say, "This is reasonable for me to try to run this," or is every one of them really just to call?

Caer: I was talking to somebody yesterday, and they showed me a clear set of breakpoints from where it makes sense to go from API-based billing to renting GPUs that you run your own models on to buying your own GPUs. There's different schools of thought on it. I want to say the numbers, once you reach past, I think it was 4,000 tokens per minute or something, that part I'm not sure on. There is a breakpoint at which point you should start buying your own infrastructure and running it on there.

That said, like any service that you decide to build yourself instead of buying from somebody else, you're now inheriting all the operational burden that comes with it. Even if it makes financial sense, purely financially to rent a GPU versus pay for tokens, it might cost you more in terms of ownership and operations to actually operate that service correctly such that it still works for your engineering teams, because that is a very different part of the question entirely.

Ken: Sounds a lot like Cloud not that many years ago, where-

Caer: Exactly.

Ken: -when it first started, it was all the same CPUs, and then, oh, it's specialty, and now closest data center and what have you. Is all this shaking out? Are the big vendors responding and trying to find alternatives, or are they just saying, "Too bad, pay me"?

Caer: One of the interesting arguments I heard was that big vendors are coming under a little bit of, not like fire, but heavy competition from the smaller neoclouds, because you have these incumbents like Google Cloud, or Azure, or AWS who have these massive data centers, but their data centers are heterogeneous. They've got all kinds of different hardware, and they're doing all kinds of different things for different tasks. Only some of that is hardware that has GPUs that can run models.

Whereas the neoclouds are coming in and saying, "Hey, all we care about is serving models at scale." They're building more specialized data centers that are just GPU after GPU after GPU. Their unit economics are in favor of running models, so they can undercut these larger, more established cloud providers. At least that's the way the thinking goes. I don't know how that's playing out in reality yet.

Andre: I personally think that there are lots of hardware makers entering this space with the intent of intentionally redesigning the developer setup for this local execution. For example, I was reading on TechCrunch, I believe, this week or the week before that the new wave of Apple computers are going to be prepared for running AI locally, because Apple developed those silicon chips and whatever. Also, NVIDIA, for example. Last year, NVIDIA launched the DGX Spark which it's still expensive. It's around $5,000, if I'm not mistaken, for a little box with a GPU inside. It's bringing a desktop-class data center to your house. It's bringing power straight to your desk for local fine-tuning, heavy prototyping.

The other thing that gets me more excited is the advent of physical AI. We have vendors now developing hardware. For example, I believe this week or last week Arduino launched the Arduino VENTUNO Q, which is powered by a Qualcomm chip design. Imagine having this kind of edge hardware in your table, in your desk, for you to play around. This piece of hardware is capable of running quantized LLMs, VLMs directly on a little machine, especially on robotics and industrial devices. This physical AI thing is one of the things that excites me the most, I would say.

Ken: You talk about hardware. You did a little bit in our prep when you mentioned a few different pieces of hardware. I know some gamers, we all do, and they wanted to go out and get a 5090 or whatever the card is these days. I have an older 4070, which is not old really, but it's only 12 gigs of VRAM. What it came down to is they just couldn't find one. When they could, the street price was double what NVIDIA's.

You just mentioned an NVIDIA offering. You said it was $5,000. I'll bet you can't get one for that price in the US. I'm sure people are marking them up. Are you seeing any light at the end of the tunnel for hardware availability for this? It's great if we can do it, but if there's no fuel for the car--

Caer: I have hopes and dreams. There was a split, was it last year or the year before? A major researcher, I believe it was from Meta, left to start a startup working on world models. World models are this idea that instead of having an AI agent that's trained on text and predicting text and doing all this stuff, it understands the actual world that it's operating in. It's like our physical space, the same way that we as humans understand our world.

These models can solve a wide range of tasks, presumably also text generation tasks, because that's part of our world. I just hope that as part of that line of research we might find an architecture that's not as GPU-heavy in the first place. That's more what I'm hoping for is that advances in AI will push us away from these billions of gradient descent-trained weights that we rely on and towards a slightly more intelligent architecture that doesn't need 500 gigs of VRAM to operate. That's a hope.

Andre: Also, on the other side, we hear that these memory makers, they are currently building new fabrication plants, new facilities to meet this AI memory demand. We hope that once these facilities come to life, so maybe next year, who knows, so the total global supply will surge. This extra capacity will relieve the pressure on the consumer of memory, GPUs, et cetera, et cetera.

Ken: Andre, you said a little while ago that you reduced it to the cost of electricity, which is certainly a lot cheaper than these vendors are. I was in London a little while ago during a heat wave, and electricity, it's not just the cost, it's availability. The air conditioner in my hotel didn't work, and it was 102 Fahrenheit, which I think the official measurement in Celsius is hot. It was pretty bad. It was because there wasn't enough power. It wasn't about the cost of the power, there just wasn't enough. Do you have any concerns there with people standing up their own data centers?

Andre: Yes. Electricity, the energy problem is an important subject because if we have the whole population of the Earth firing up tens of thousands of active parameters across those server racks, they are all drawing hundreds of watts per credit. This is a thing that we need to be aware. I think that one way of solving this is using-- I have an infrastructure background. I think that one way of solving this is having different deployment strategies to shift away from centralized cloud data centers. Again, run those models directly in our hardware, our laptops, our Mac Studios, our phone, our local edge servers because those locals devices, they draw a fraction of the power of a data center. This could be one thing.

Also, another thing is that at least here in Brazil, people are doing a lot, bringing your own power. People here are increasingly decoupling from public grids by using solar panels. There are a lot of houses using solar panels here in my region. I believe we can use this strategy, so to speak, to diminish our electricity bill and to save the planet.

Caer: I think one of the most staggering facts I learned, I think it was last year, and I think it was Microsoft, I'm not sure, but one of the major cloud providers has signed some contracts to bring nuclear power plants back online, specifically to power their AI data centers. I was like, "Well, nuclear power, if it doesn't melt down, is probably cleaner. Also, that's crazy that that's the point we have reached, is nuclear power plants to power data centers." I think that the major clouds are finding creative ways to get the energy.

To Andre's point, I think the real push needs to be more towards edge computing. We started to see that as a trend in systems engineering in general over the past few years, where more and more effort is being put into decentralized systems towards pushing compute to the edge, all that, which is a good thing. I love that. I think that'll be a key part of how I respond to what will probably be an energy crisis from AI at some point, if it doesn't stop.

Andre: We don't need another Chornobyl.

Ken: It's funny, I was talking to our chief AI officer, and he was looking at some of that. I don't remember the technical term, and I don't want to misquote, but he found it very promising, some of the little local things. I actually spent a bit of time on nuclear-powered ships [laughs] when I was not quite this gray. I admit I'm torn because I don't really want to be like Chornobyl, but we've been running small reactors pretty successfully for a very long time. I don't know. It's scary.

Anyhow, I digress on purpose somewhat. I guess, where do y'all see this going? Is this a flash in the pan because OpenClaw want everybody to have their own thing? Is this, no, finances are going to do it? I'll have to admit that I do this technology podcast, but I also do some of our business-facing things, and it's been very rare. You both have mentioned either CapEx or OpEx during this podcast recording. For those that aren't familiar with those terms, it's the capital expense, a thing I buy, versus an operating expense, a person I pay or a thing a bill, or whatever. That hasn't crept into technology conversations since cloud 15 or 16 years ago. Are you now hearing these terms from your technology clients?

Caer: Most of my work at Thoughtworks is admittedly internal, so my clients are Thoughtworkers and Thoughtworks leadership. Concretely, the CapEx versus OpEx conversation has shifted with this frontier models especially, because we saw just a month ago when Fable got shut down for a few weeks because it was a little bit too dangerous.

That's not an OpEx cost issue, but it highlights the fact that if you had depended on Fable and it was an external resource that you didn't control, you were suddenly in a lot of trouble. That's an operating risk that you're carrying by using a frontier model that you have no way to run yourself.

Then in addition to that, prices for models have been going up and down a little bit and are a little unpredictable. The OpEx for these frontier models is very unpredictable and scary if you're a technology leader saying, "I'm going to build this platform, and it's going to cost this much." You can't say that because you don't know what it's going to cost in six months. Whereas with the CapEx conversation of, "I'm going to buy a GPU and run this model on it," that's an expense you pay once, and you know what it is, and you can amortize it, and it's great. It's a very different conversation. What helps the conversation is that the gap between frontier and open-weight models is closing. Frontier models are getting smarter and smarter, but there is a certain point of smartness where it's good enough. The open-weight models are really starting to cross that, especially with the GLM-5.3 and the Qwen 3.8s.

Andre: The industry is moving away from the paradigm of let's only use those larger models hosted in giant cloud data centers. It's moving away from that toward efficient, localized, specialized AI execution. As you perfectly pointed, Ken, it's the same thought of Cloud Computing 2015. I always joke that our area, our field, IT, is like software, it runs in circles. [laughs] Is that time again?

I believe the macro trends to shape this next era of AI is like using frontier models in the cloud for ultra-heavy reasoning or base model training. For the majority of tasks, we are going to run specialized small language models for domain-specific tasks because those have fixed costs, the latency is better. Also, companies are doubling down on local hardware execution, as we just said before, like running on your own device or on micro data center. We can say that the right sizing replaces this giant scale.

Ken: We could keep this going for a very long time. For the sake of our listeners' sanity, what can people do tomorrow when they go to work, or Friday, as we're recording this, so Monday morning? What is actionable? Is it just run experiments? Is it read more? What's an action that people can take when they get back to work? I guess Andre, you started, so this time I'll start with Caer.

Caer: For me, if somebody is in an engineering function and so they're writing code every day and they're using agents to do it, I would encourage them to experiment with using an open-weight model as an alternative to whatever frontier model they might be using today, especially with the fact that GLM-5.3 has become widely available this week. That one is a great one to try first because I think you'll find that it works almost as good as or better than Opus for a lot of tasks. That was the premium premier model for a while now.

Ken: Andre?

Andre: Yes, I agree with Caer. I would add don't wait for a formal enterprise budget approval in order to use your experiments. Download local model, local runner like Llama, vLLM, grab a terminal harness like OpenCode, pull up an open-weight coding model, and do your thing. Don't spend $5 per document. That's the most important thing.

Caer: The compliance, Andre. The compliance.

Ken: Yes. I wish this was a video blog, not an audio podcast, because Caer has an internal role, and I work for the office of the CTO. I agree with Andre, but both of our faces went, "Oh, no." [laughs]

Andre: If it was that easy, right? Sometimes it's not that easy. I say, yes.

Ken: Just please be careful if you do that.

Caer: I heard about many executives running OpenClaw over winter break without asking their IT teams and getting all their inboxes deleted. I guess that's a warning. Be careful.

Ken: On that note, thank you, Caer. Thank you, Andre, for your participation. Thank you, as always, for the listeners, and we look forward to hearing more from you soon.

Andre: My pleasure. Thanks for having me.

Caer: Thank you.