AI Testing Costs, How to Prevent Runaway Token Bills

Hey, picture this. You ship a shiny new AI-powered app on Monday. Week 1, your bill's like $127. No big deal. Week 2, $890. Hmm, not good. Week 3, $6,000. Week 4, $18,000. By the end of the month, you owe $47,000 on a system you budgeted $600 for. And that's not a horror story I made up. This has actually happened and it's happening more than anyone is talking about. It even happened to me just trying to get my own OpenClaw instance up and running. Also, did you know that Uber blew their entire annual AI budget by April? Agents are getting stuck in 11-hour conversation loops with other agents, quietly burning through tokens while everyone sleeps. And most teams shipping AI right now have no idea it's coming for them. Don't let this happen to you. If you're putting AI anywhere near production this year, this is the episode you can't afford to skip. Joining us today is Arthur Hickens. You may know him as the Code Kommodgen. He's back on the show. Arthur and I were hanging out at the TestGuild IRL in LA when we got into this topic, and he told me he's actually writing an article on it. So I told him, hey, I need to get you on the show to talk all about it. You don't want to miss it. Check it out. Hey, Arthur, welcome back to the Guild.

Hey, Joe, glad to be here.

Awesome to have you. So we were talking actually in real life. I did a TestGuild IRL in LA. You came on out and we got on the topic of AI and a bunch of things that can go wrong with AI. One of the top of mind things was, um, was billing. Uh, and, uh, you said, oh, I'm actually writing an article on this. You wrote the article and that's why you're on today to talk a little bit more about it. We'll see also what else we'll cover, but, uh, what I really like about this article is I think you coined a thing called a token tax. So then we kick things off with that. Like, what did you mean by that phrase? Where did it come from? What maybe some moments you've seen from a customer or conversations you had that made you realize that this is a real pattern that teams are going to need a name for coming up in the next few weeks and months?

I definitely wanted to have a name so that we can talk about what it is. It might be a combination of things. As I started doing things more myself and, you know, where I work and we started doing things at Parasoft, like using more and more AI and I'm working with customers who are consuming AI. And of course, when you move past cute image generation and short stories for your kids and whatnot, you quickly start bumping into times where the system says, "You haven't paid enough." And on a plan that I would have myself that might be $20 a month or $100 or $200 a month, it's just going to tell me. But when you get into like production systems, then you deploy things and they start running against, you know, a billing clock. And maybe there's a limit and maybe the limit is, you know, the size of the card you attach to it. So I started hearing people hitting limits, you know, customers who are trying to use AI LLM-enabled tooling, both in coding, vibe coding and vibe testing, and even in regular testing. And suddenly the limits placed on their freebie accounts at the various vendors just won't work, right? They just won't work. And so I started to get worried about this. I used to call it the Amazon problem. Right. But it's the AWS problem that most people are familiar with. And it's the, it's the billing transparency, right? Like one problem is, can you even reasonably estimate what a bill will be? And what things can cause the bill to move outside the realm of what your expectations are? And we see people doing super clever tricks Right? I think it's Netflix that like spins up a VM with the, you know, there's a range, right? Like it'll perform from this good to this good. But until you spin it, you could be at the low end or you could be at the high end, right? Right, right. And so what you do is you spin it, you test it, and if it's at the low end, you pitch it and spin a new one. Right? And so rather than, oh, well, I always need like the max, so I'll just buy the next tier. That's how the plan's designed to work. They created this elegant system that spins something up, runs a quick performance test, and if it's below their spec, they drop it. And that's how they keep their billing under control. There's lots of things like that people do, but I started to worry because I was working on just a unit testing article, like not a cost, sorry, a unit testing article and talking to some customers and to our developers. And I'm like, you know, what do I got to look for? Because some of the customers can't do this under their free account. And as they started to lay it out, I'm like, this could really go off the rails. Right. So I have to say that the token tax is fun and it's catchy. And so I think it's worthwhile statement. It's not a tax. It's just a bill that you didn't expect. But the kind of important thing is that when people build systems and they want to deploy them, you sort of plan ahead that, oh, I need 10 grand to get this off the ground, or I need $100,000 to get this off the ground. And then it'll just work. And with AI, like, the costs are ongoing, right? Like, every time that you pass something to the thing, you pay. When it passes something back, you pay. And when you turn an agent loose to do a background search for you, you pay. So a lot of customers, individuals, are on flat rate plans, right? But you know, when you deploy something for your business, you're not going to be on a flat rate plan. You're going to be on a token count and suddenly understanding what a token count is, being able to guess what it might be. So it's a, yeah, it's a real challenging problem that I've seen maybe a dozen stories now, like anecdotal stories.

Yeah, I was going to ask you, like, I know it's something I've been scared of, but like, have you actually seen in the news real, real concrete, like someone ran up a bill of X amount of money or something?

Yeah. Yeah. That's so like the most exciting one was a little company that got a $47,000 bill.

Oh my gosh.

Right. And it's fun because let me see if I look at the notes here. Yeah. Week 1, $127. Okay, cool. You can live with that. Week 2, $890. This is problematic. Week 3, $6,000. Week 4, $18,000. The total bill for the month, $47,000, when it looked like it was going to be $600. Now, the story's probably real. But the point of the story is that they're trying to build a tool that'll help you manage this. Okay. So, so I don't know, but the very day that I published my story, I caught in my, my news aggregator, Uber, who turned out they burned their AI budget in April. Their annual budget is empty. Right? It's just gone. And theirs is, is not from a, hey, we just did a bunch of stuff. It was like, it's just not understanding how much is going to happen, right? It's that in AWS, we would have called it the lack of transparency. Sometimes Sometimes a lack of transparency is that the system's got hidden gotchas, but sometimes it's just you didn't really know how this was going to work in the wild. The other sort of hidden one that I start to see stories about is the scaling nightmare, right? Like, you know, in the early days of viral behavior and we're building little applications, you're your hope is always that you'll go viral. You know, it'll break your website, but that's okay. You'll get it back up on a secondary or you'll move it to AWS. You'll pay the cost because being viral means money should be coming in. But this, okay, so a million years ago, I worked in a camera store. My boss had a saying, we lose on every sale, but we make up for it in volume. Okay. That's a place you could easily find yourself. And in fact, it takes us back to something interesting, right? Because token costs are down at the moment for us, for users, right? Like, they're down by like 90+ percent, right? Again, as individual users, you may not see it because you don't realize that, you know, you're on a flat rate and that the token rates there, but they're down, but they're down because the AI providers are losing on every sale and making up for it in volume. This is not sustainable, right? We ran through this with cell. You remember that, Joe, right? Like we all got our cell plans and we used to, for those of you that are young, there used to be this thing called block distance, right? And if a phone call was more than, you know, 15 miles or 10 miles or whatever it was, you had to dial a 1 and an area code to get to it. And then when you put that area code in, you knew that you were paying per minute. And like a call to Europe would be like a buck a minute, which is horrific. And then we added this new thing with smartphones, right? Like suddenly our phones started not just using like data for the call, but data for the sake of data. Right? We got internet on the phones and smartphone came out. And there was this tension between the phone companies that wanted to push more data on us so that they could sell more data to us, but they couldn't make their stuff too expensive. Right? And, you know, 15 years ago, it was a pretty serious issue. Right? Like the, you'd suddenly get, hey, you can stream Netflix now, but it's going to cost you, you know, $5 an hour to watch TV. Well, you're not going to pay that, right? For the experience. So a lot of monkey business went around, but they kind of solved it, right? Like they essentially, the cell phone companies are subsidizing it into flat rate plans, knowing that some users consume very little, but are paranoid about costs and some users consume a ton. But there's really not that many of them. And so they can deal with it.

Right, right.

I don't know. I don't think this problem can be solved that way. Right. So I don't know if you'd thought about it yet or not.

No, I was just, uh, yeah, I've just been worried because, uh, you know, management's saying just use AI, but they're not thinking through these issues on on paying and things like that, how much it's going to cost. And what I've been thinking more of is how tokens may go down in cost, but would probably be taxed on them somehow, like an environment tax on top of it, or like almost like how they tax gasoline, uh, so that eventually it's not going to be free, even if the cost goes down. I don't know. Anyway, I think that's it.

And then, and I think it's important to think about because a lot of people's response to the article can end up being, hey, you know, we went through this with Cell and we solved it.

Yep. Right.

But at the moment, there's this hidden problem that the AI companies aren't profitable. Right. And at some point, right, they can operate this way for a while, for another year or two or whatever it is, but but not in perpetuity. And so, you know, will we be back to a, you know, per every token charge for everybody, or are we going to have flat rate tiers? I don't know, but the problem isn't going to simply go away because there's underlying infrastructure behind it. So the reason that I bring that up, you know, none of us have any control over that, right? We have zero control over it. It's just knowing that the problem isn't going to go away. Like, now we need to start taking steps. Then I need to reduce my count, right? Like, I just need to reduce the tokens I'm using, right? I've got to make sure that things are effective. And that, that to me was kind of the important part, right? There's, there's a there's a general AI principle that I feel is important. You know, when you turn the AI loose, you can't, you can't turn your back on it. You know, it's a capricious prodigy. You'll look at what it's doing and you'll go, wow, this thing is smart. Wow, this thing is smart. Wow, this thing is smart. Wow, how did it ever do something so stupid? And that's just how it works. Totally. The smartness is so frequent and frankly sometimes so amazing that trust builds much faster than it should be earned.

Right, right. And I guess another spin-off to that is you trust it so much that you don't realize ways that it could be consuming tokens without you knowing. I think in the pre-show you mentioned something about security. How do you know what to look for then when you're trying to minimize your token usage when you don't necessarily know, like security could add token usage without you even thinking about it?

Yeah, and in fact, some of the stories I found, and I'll put them in the list, is people breaching some AI security thing and then pushing it to its limit. There was a Starbucks incident where somebody like, you know, got into somebody's Starbucks account somehow, and they just started creating gift cards and sending them out, right? So, and the person didn't notice, like, at first until they went somewhere else and their card got declined because they bought $7,000 worth of gift cards in, you know, 5 minutes. So yeah, rate limiters and monitoring and things like that. The trick with AI applications is that you know, and not by that, I don't mean like, you know, chatbots. I mean AI augmented, like you using it for your own application, either to write code, which should be a bounded exercise. You should understand that, right? The testing can get expensive. The deployment, the actual AI augmented application where you're now using, you know, LLMs to do something cool for your end users. That's where it gets problematic. And I think service virtualization, right, might be one of the ways, right? Because what we haven't done typically is any hardcore performance testing on these apps. And I would say out of most of the stories I'm seeing, a lot of them, probably the majority, are based on people just not understanding what the usage was going to actually come out. And so, right, right. You know, my thought is that you use service virtualization to act like an LLM. You use it if necessary to act like an MCP server. You give it some known things. You look at some traffic through your, you know, existing testing system, whether it's you know, Selenium or Playwright or manual testing or whatever. You scale that sucker up without the billing running. Okay, yeah, maybe it's better to spend like $300 or $1,000 in one day and realize that it's not scalable, but maybe don't even spend that, right? Like, and start to look at, you know, scale the thing up and see where it's going and what the number of tokens would have been. I think that might be the right answer. And I didn't put that in the article because I hadn't really thought about it. Right.

That's a good—

so new information, right? Like you heard it here first. Right.

But yeah, yeah.

I think, I think that's a solution for helping to understand what happened to you. I think there's some more fundamental issues and, and I do like that $47,000 article. It's got a really, really long title, so I can't like I can't remember it, right? But it's like you spent $47,000. I think the bigger point is, and it's what I've seen in other cases, sometimes things don't need LLMs. You know, like if you've got a deterministic problem, you don't really need a non-deterministic solution. Yeah.

True. Right, right.

We've seen that, for example, with, you know, unit test generation, right? And the same would go for like functional test generation. If you can definitely use an LLM for creating unit tests, there's caveats, right? Will the machine hallucinate? Will it invert the logic? I've seen unit tests that were literally the opposite of what they should have been in terms of the assertion and at first glance, they look like well-formed tests, right? The inverted less than, greater than is something, you know, it's the bane of software, right? Like, it's just the bane of software. Maybe we should be forced to spell it out. We should not be allowed to use the less than, greater than signs, right? But you can use it in those quantities. And again, you're probably under a, you know, a flat rate plan and you use it a few times, what happens is when you scale the practice up, it's slow. Okay. It's really, really slow compared to what you think. It's faster than a human. If it wasn't, we wouldn't do it. Right. Okay. But, you know, if it takes 2 minutes to create a really cool end-to-end test, you don't care. But if you look and go, I need 10,000 tests, I'm gonna assume that you're gonna go past the limit that your AI will allow you, right? I've, I've done that with, with some work where I've dumped in tons of stuff trying to distill, you know, some thoughts on core technologies and, and found that, you know, the AI sent me back the the AI equivalent of the middle finger, very politely telling me I'm done. See you tomorrow. You can't work today anymore. But when you scale that up, the slowness and the need to validate it, right, like the human in the loop, at this point, you can't walk away from human in the loop. You know, you might be able to in testing purely on your desktop on a flat rate plan, but you cannot afford to deploy these applications without some reasonable amount of human review. And hopefully it's really easy review, like with the unit test there and the explanation of why the unit test is the way it was and what it thought that the, you know, the system was trying to do so that you can go, That's not what it's trying to do. And you can, you know, some way for you to correct it beyond staring at beautifully formatted code.

Right, right. And you actually bring this up in your article, Arthur, where you talk about it looks good, but as you scale up, it gets worse. But you had like some stats, I think, where you said even though it was generated by an LLM, there was like 41% test accuracy, something about 30% branch coverage and 60% of injected bugs go undetected.

Yeah. So, yeah. And I'll have to send that, that article reference in. Yeah. Yeah. It's like independent research. LLM branch coverage averages 30% on complex code. So, you know, a third of the stuff gets tested, if I'm generous. Tops out near 40% after multiple attempts. Right? So at some point you can't keep doing it. And this is the— I love MCPs, okay? And I love that some sci-fi nerd decided to name a core useful technology of the modern computing era that's AI-enabled after a character in Tron. Like, if you don't know that MCP is Tron, go watch Tron and come back and finish the podcast. I love that. But the way that it works, when you give it a problem that it's not going to solve, and then you put it like, instead of a process that you kicked off one time manually, you tell it an agent and you give it a goal that's unachievable. Your best case scenario may be Hal and it tells you, no way, I ain't doing it. In a good scenario, right?

Right, right.

Bad scenario is that it quietly just empties your bank account, right? Because these things are going to loop, trying and trying and trying and trying. And the further the agent gets from you, the agents start talking to other agents. And there's one of the articles, I'll give it to you, that the agents spent, it might even have been the $47K one, that the agents got in a conversation with each other and it went on for like 11 hours, right?

Oh my gosh.

So, you got an 11-hour token loop occurring.

Yep.

So, it's really easy for agents to dive into loops. That's kind of how they're built, right? Like, take these stuff, and, you know, a classic case in testing, right? Test it, look at the bad line, fix the test or fix the application, and then test again and see if it got fixed, right? And if it didn't, or you find another test, loop it again and loop it again and loop it again. And obviously, guys like you and me that want good code coming out there have set the Oh, well, you know, when you find no bugs, then stop.

Right.

Yep.

Right.

Or when you hit 100% coverage, then stop. Right? Yeah, you're right. We found this years ago when we first started doing unit test generation, right? That you could go deeper and deeper and deeper and deeper and deeper, you know, creating symbolic values and trying to run the system to see if you got in a different path. But the truth was that at a certain point, there was extreme diminishing returns. Extreme. And that's what you see from these numbers, right? The 30% and the 40%, right? That you can take a second pass, right? You get 30%, you take a second pass, you get 40%. After that, you know, like, go home and try it again tomorrow, you know? But the cool thing is, you know, AI applies different ways at different times. Like, when does the human work? When does the AI work? I feel like if I'm unit testing something that's got zero coverage on the desktop level, I'm running the LLM first. If I get 30% for free, great. If I'm a really good coder and I have well-structured code, that 30% might be 70%, right? Like on good code, well-structured, well thought out, properly compartmentalized, right? But then I can fill in what the AI can't do. Right? Normally what people do is they do what they can and they try to get the AI to backfill, but probably the stuff you skipped is the tedious, weird, hard to reproduce stuff. And guess what? The AI is going to struggle the same way. Then you stick it into a loop. So I think that that's a more effective way. Is let the AI do what it does best and then backfill it. But also, there are other tools. Okay. I'm saying AI here when I mean LLM. Right. We have to recognize that LLMs are not there to replace all previous AI technologies. They don't replace—

That's a good point. People get confused. They associate AI with just LLMs, but there's other types of AI that on LLMs that may make more sense that are more deterministic.

They're more deterministic. They require less memory, less compute power. They have more understandable, transparent cost mechanisms, hardware, software, and the billing mechanism itself. And so I would probably today in an area of unit testing where there's tools, right? I would probably start with a deterministic machine learning neural net kind of a tool, let it generate whatever tests it could, and then I might backfill with the LLM. And then as the human, I've got the last mile. Right? And that's it. And, and by the way, you know, just as a testing— you won't get to that last mile without serious mocking and service virtualization infrastructure, right? Like, you—

right, right.

Code Permutations rule of thirds, okay? A third of application functionality is the normal stuff that we use every day. A third of it is all those other special features that advanced users hit, right? That you may or may not, you know, using Word to look at a JSON table properly formatted is not a normal use case and probably should never be a use case.

Okay.

But the last third is the stuff hitting the fan. It's the plug got pulled. It's the disk failed. It's the, you ran out of memory, you know, it's the bogus input that I can't understand, or the network's too slow or whatever. It's all tricky. It's all tricky, right? And it might be that LLMs are useful there in a narrowly bounded human-ordered sequence, right? The LLM as a tool in the hand of a tester, not as you know, as a— what were we talking about before? Like having a servant, right? That's, you know, an intern that's given projects and come back and you check their work, but more of a, let me get you to do one thing exactly and do it exactly right. Because by the way, in the space of error reproduction, maybe that's the most dangerous time that you turn LLM lose. But I do think you can get really good results and let the LLMs do what they do well. And, you know, overall, just resist that urge that LLMs were going to replace everything that you ever knew and loved about AI. I mean, God forbid that your car should be using an LLM for choosing a lane and when to turn lanes, right?

Right, right, right. Yeah, it's dangerous how people, you know, don't apply the right AI to the right, uh, the right problem. LLM doesn't fit all. And for some reason, it's super great at certain things, right?

And, and, you know, in testing, when you're testing a non-deterministic system, right, we used to have this thing that, okay, I'm looking for yes, right? Or I'm looking for a very properly formatted response. And now I can write an LLM assertion that says, hey, I need some kind of a positive response that contains a number in the range of blah, blah, blah. And that should be the answer. And even the example that Igor uses all the time at work is that that it's a reasonably polite answer. And I'm like, my first thought was, okay, that's silly and unnecessary assertion. On the other hand, given that these systems sometimes do really weird things in their responses, it might be that reasonably polite check might be the most critical piece against an LLM system. So, there's one other thing I wanted to, like, point out too in this looping, right? Like, and we see it. We're all moving from generating tests to auto-remediation, right? I mean, that's the dream. You know, people say that's the dream, but that's the dream, right? Like, that the system finds the problem, diagnoses it, and applies not just a plausible fix, but an appropriate, effective, high-performance fix that meets whatever constraints I'm required to, whether it's minimal memory usage or performance levels or privacy levels because I'm doing credit card data or safety levels because it's involved in first responders. And that the fix isn't just different code, but appropriate code, right? And if you don't know how to do that, the system's behavior, the default behavior of the LLM is to write different code, right? Ideally, when you have a senior developer, the We used to call them, you know, non-functional requirements. I like to call them unwritten requirements. The code should go slower than before. The code should be secure, right? The code should have a reasonable response to oddball inputs because that's how people break in. Okay? And under normal oddball responses, it should tell people, hey, Your phone number needs to be in digits and not written out. Here's what a proper format phone number looks like. Here's what we're expecting. Please put it in. It needs to be friendly to the user. It needs to be robust. None of this is written every time for everything, but it, it, that's the expectation you have from your LLM. And guess what? It, it doesn't have those instructions. So. Yeah, but the bill, I worry about the bill. I'm actually shocked, Joe, that the number of stories I found that were legitimate runaway agentic behavior was small. But I'm afraid it's—

So do you think then it's a ticking bill bomb?

That's what I think. I think that we're at the front. And the wave is coming. I think that I managed to get out in front of the wave for once.

Right.

And I believe that the, right. That's why I want to, you know, do something to aggregate these stories because I, I do think that the quantity and the size is going to increase this year, right? This is the year people are putting AI into their pipeline. This is the year to get out of control and building.

They're seeding it. Yeah, right, right, right. It's almost like security too, though. Either they don't want to report it because they don't want to be known that they had a security issue, or people don't care until they get hit by a security issue and all of a sudden security is important. Either way, you know, it's not, it's not a good, good place to be in.

You know, if, if you had a really cool thing that you spent a lot of time building and, you know, you're using AI to help you build it and test it and whatnot, and you're, you're ready to go and you're you're extremely happy that you're on schedule because you took good advantage of these LLM tools, and then you deploy it and, you know, smoke's coming out. And smoke's not coming out because of bugs, but because the LLM was an inappropriate choice for what you were doing. Right. Right. Besides guardrails and monitoring and learning to minimize token use and actively working toward minimization. But there's a core question, right? Does this need a non-deterministic solution?

Yes. Right.

Yeah.

So it's education because people are just being told use AI and they just grab LLM because it's so available. They probably don't know there's other options. So there's other AI techniques.

So Joe, can we put up like a betting thing on TestGuild with the over-under for the first, you know, million-dollar unexpected?

Right?

Maybe we put it up and the earliest correct answer gets like a Code Curmudgeon hat and a TestGuild t-shirt.

Yeah, we should do it. Good idea.

On your, on the TestGuild. And let's, uh, let's, uh, see what people, when people think it's cut. Maybe we'll craft 2 or 3 questions. Right. And yeah.

Yep. But also, Arthur, I know we're kidding aside, you know, in your article, you do have a practical thing that people can do before that does happen. Uh, you had something about do the math on tax on your token tax. before it does it for you. So for teams that haven't done that math yet, can you talk a little bit about maybe what doing the math means, what it actually looks like? Is there like a back of napkin type of calculation you can walk through to get people to say, okay, I'm semi-confident?

Yeah, yeah, a structured, walled-off, time-boxed deployment. Again, it's, it's like load and performance testing, right? I, I won't necessarily see it in an hour, but I need to have a feel for what it's going to do And people probably, most developers have in their head some kind of an expectation about how things will operate, right? Hopefully. If you do and the thing falls way outside the range, then you need to investigate. If you don't have an idea, then the actual number is probably going to surprise you. So again, it might be that you take the cost hit for a day or an hour or whatever is necessary and craft up the traffic. See, there's some big assumptions here, right? I'm assuming that you're a mature organization that's doing good testing, right? That's always my assumption. That's never a real assumption, right? It's always wrong.

No, no doubt. Never.

And maybe I come back to you and I talk about coverage in the article, right? You need to have good tests. The good tests will help you make sure the program doesn't fail, but they'll also help you leverage proper performance tests to understand what the performance profile is and scale that sucker up. You know, like, it might be that we just scale it up to what we expect, but I might go, how much usage would I have to get to hit $1,000 a day. That's where you want virtualized system, right? You don't want a real system, right? But it would be interesting, right? Like, not, not what's my expected load and what's double my expected load, but what's the load that's going to make me unhappy, right? And, and again, you know, coming back to then It's kind of like performance testing, looking at who's creating these tokens. Where are they coming from?

Right?

Where did I say something I didn't need to say? And where should something have been sitting in a, you know, in the memory for the LLM so I'm not passing these things back and forth? And where am I doing Where am I lazily leveraging an LLM in a production system for deterministic use? Right.

Great advice. Okay, Arthur, before we go, one piece of actual advice you'd give to someone to help them with their tax API tokens or AI tokens or anything else in general with AI and best way to contact you.

Watch what the system's doing. I guess with AI, everything today, like put boundaries, put monitors, put tripwires, watch what they're doing, measure it. And again, you know, scale it up if you see things happening. If you've got a system and it's working, simply measure it and see what it's doing in, you know, whatever time box you can put it in, right? Probably the easiest way to email me is always codecurmudgeon@gmail.com. And, uh, you know, go from there.

Awesome. We'll have links to all these articles we covered down below. Check them out. Let us know the thoughts in the comments as well. Thanks again for your automation awesomeness. The links to everything of value we covered in this episode, head on over to testguild.com/a588. And if the show has helped you in any way, why not rate it and review it in iTunes? Reviews really help in the rankings of the show, and I read each and every one of them. So that's it for this episode of the TestGuild Automation Podcast. I'm Joe, and my mission is to help you succeed with creating end-to-end full-stack automation awesomeness. As always, test everything and keep the good. Cheers. Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing, and DevOps. If you haven't yet, join our vibrant community at TestGuild.com, where you become part of our elite circle driving innovation in software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real-world challenges, we're excited To collaborate, visit testguild.info to explore how we can create transformative experiences together. Let's push the boundaries of what we can achieve. Oh, the Test Guild Automation Testing Podcast. With lutes and lyres, the bards began their song. A tune of knowledge, a melody of code. Through the air it spread like wildfire, through the land, guiding testers, showing us secrets to behold.