Running AI overnight not just in the day

For this episode I want to talk about one of the really big gaps I see in productivity and outcomes that people are getting from AI. In the last few months especially there's been the arrival of OpenClaw and the rise and fall of OpenClaw dominating the news and there's been a lot of reactive changes by some of the big vendors including changing their pricing models including changing their product offerings to push more towards 24/7 agents, AI agents. But the thing I see often, not just with this but with everything else in AI, is that most people, most organisations have no idea what good looks like in AI world and they're quite happily walking along while their competitors are driving past in a Ferrari or a Lamborghini. So we're going to focus on one of the big gaps in this episode. So the gap here is AI Agentec. We're going to ignore the frameworks and swarms of agents and I built a company where every person in the company is actually an agent. We're going to focus in on a much narrower, simpler, smaller problem which is one agent, just one. And even with that we're going to see that most companies are completely missing the point and the opportunity. And you can scale that up to more agents if you want but let's start with one. The common pattern looks something like this. You have an organisation, so people come to work in the morning and each day the day they work, working with AI. They do a bit of work themselves, they hand something off to the AI. They wait for it to finish, read the results, do another bit of work and another thing off to the AI and repeat. And to some extent this carries on throughout the day. So I was waiting back and forth between human work and AI work, planning, executing, checking, reacting, going to meetings, all sorts of stuff. And at its best this does produce some really impressive gains. We hear stories all the time about people who've compressed a week's worth of work into a single hour or five or six hours into a single minute or two. Or a few weeks into a day. And I've seen so many of those I've stopped counting, I've stopped tracking them, seen them firsthand and seen them secondhand. That's great, those gains are real. But the thing that we almost never hear people talk about is when you go home at night, when you switch off for the day, when you leave the desk, what's the AI doing now? Because there are 16 hours, approximately, until you come back to work the next morning. And why is your AI not working during those 16 hours? Why are you throwing away more than 120 hours a week of potential AI labour? That's three whole working weeks every week, just for one AI that you're losing. And until recently, before the pricing changes and the open-claw and the reactions from the vendors who decided they were losing, it was costing them too much money, we had genuine all you can eat subscriptions. And we were barely using them because people were only using them for a couple of hours a day. And in fact, what's happened, of course, is the vendors led by Anthropic and their new surge pricing. Thank you, Uber, for introducing the world to that concept. He went from clamping down on aggressive usage to just clamping down across the board. And now all you can eat basically doesn't exist. So using your extra 120 hours a week is not trivial and we'll come back to that at the end. But it's still worth looking at, it's still worth doing. So what I'm going to go through here is why it's difficult, some of what goes wrong, some of what people are trying right now, and some of the practical realities. When we talk about working overnight, there are two interrelated problems and we're going to cover both of them. So before we took, well, let's look at our overnight first of all. So overnight, fundamental question, what's the longest uninterrupted productive run you have ever achieved with an AI agent? And I don't mean overnight, I mean at any point in the daytime or whatever. It has to genuinely keep advancing the task and produce useful output. So obviously if it got stuck for two hours doing nothing and you killed it, it doesn't count. It turns out that getting beyond about 15 to 20 minutes reliably is really difficult. And most people only end up doing 10 to 15 minutes or 5 to 10 minutes. That's the longest they've ever seen. So how on earth are you going to get to 16 hours for a single, effectively for a single prompt? You can get it up with a bit of work. A lot of people manage to get up to say 40 minutes, 45 minutes. But then you start to hear other problems as well. You go on into practical problems like your context window is filling up. Easy to solve. But the point is how many people have ever seen it run for an hour? And certainly how many have seen it run for an hour consistently repeatedly. Because there's problem number two. Number two is you don't need to have ever tried to do a long run. Problem number two you will see every day in your normal work with AI. Suppose I give an agent a task in the morning that I think should take about an hour. I don't know how long it's going to take. There's no way to measure that in advance. It doesn't exist as a feature yet. So if it finishes in say one minute or gets stuck after a minute or has to ask a question after a minute. I can't just walk away confidently and come back in an hour's time. Because there's a reasonably high chance I'll come back and find that in one hour it's only done one minute of work and then it's just sat there doing nothing. And if a colleague stopped working after one minute I'd notice immediately and if they kept doing it, it'd probably get fired. But that doesn't apply. There's no kind of conversation or argument you can have with your agents. And they don't really learn. Is that a simple concept? But what matters is the practicalities of what that changes about how we tend to work with AI. So because we don't know how long it's going to run for. We don't know whether it will stop suddenly. We don't know if it will turn for, and it's not one minute, it's five minutes or it's seven minutes. And it could have a task that's definitely going to take 30 minutes, but it stops after four and a half minutes because it runs into a question or it runs into a third party service is down right now. Stuff like this is where OpenClaw really came to be a superpower because it's very good at restarting itself. It has a heartbeat and it continually pokes itself to see if it should carry on or resume or get moving. But for most agent work, what we're dealing with as human users is this uncertain, unpredictable, I have no idea how long it will run for before it next needs my input. So what happens? And this touches into all the things like a Skinnerboxes and Psychology experiments from the 1960s and 1970s. What happens is we as humans naturally fall into a pattern of sitting there and watching it like a monkey tapping on the keyboard and waiting for his reward. So we end up half working, half hovering over the screen, constantly waiting for the AI to either succeed or fail. And you can have pop-ups, you can have notifications on your screen, but they interrupt you by working. So you can't meaningfully go off and do a big piece of work and you certainly can't go off to a meeting. You can't leave the AI to do work in your absence. And then what happens is that this is a consuming attention and it's intellectually mentally exhausting. So could you permanently on this will it won't it waiting to see if the thing is ready to proceed or has stopped or needs more input, etc. And I suspect this is where most organisations that are failing to get real-world productivity gains from AI. This is where it's going. So when you see reports claiming 10 times or 20 times productivity improvements, those are real because I've seen them firsthand. But many companies will adopt the tools and the processes and then they report we don't even see 2x, we don't even see 50% improvement. In fact, when we measure it it comes out as a net negative. I strongly suspect that this watching the AI problem is a big part of that. Because the companies that have figured out how to not sit there, babysitting their AI, are immediately going to get massive boosts over those that haven't. We've got an obvious problem here. which is the agent just suddenly stopping because it has a question or it has a problem. But there's lots of techniques to work around and prevent or reduce that. So if we get past the sudden aggressive stops, we have a bigger existential problem. LLMs are very good at narrowing scope, but they struggle with broadening scope, and that's fundamentally tied to the nature of a context window. And to what an LLM is, so the original paper attention is all you need. LLMs have both a very small context window, but also they require focus for them to be effective. So when an LLM needs to narrow down, that's very good at that, because it just discards a lot of stuff and focuses in on something a subpart. But when it needs to broaden, it doesn't have a memory, it doesn't have a brain, it doesn't have any of the things that human has. And so how do you broaden without reconsidering everything? And this is a tough problem. At a basic level, it requires something more like a true artificial intelligence, a judgment maker with a huge repository of life experience. And that means it's going to be at least for now human-led somehow. As a quick aside, if you've been following my open source work, you'll know that I've been doing a lot of work with making humans and agents collaborate on knowledge bases. And one of the things we use that for, or one of the things we use it for is to provide external brains and external memory systems for agents, but in a way that your non-technical human staff can read, write, edit, and do compliance and governance on. But taking a step further in practice day to day, one of the things I use it for a lot is to explode an agent's concepts whilst it's working on them. And to expand the agent's thinking and reasoning, out into bigger concepts, but in a way that allows the agents themselves to intelligently pick how they expand a concept, where they broaden it, and so on. But that's very much an open-ended problem that we're still trying to find good solutions for. So, if our goal is to get the AI to do more work unattended, and not just a little bit more work, but a lot more, to go from tens of minutes to tens of hours, then broadly speaking, it's not going to be achieved by a single task. And a single context window could only be filled by an agent in minutes, so it's not going to be a single context window either. We know it's going to be some kind of list or set of tasks as many different frameworks people have been experimenting with to try and achieve this. But fundamentally, they all come down to one core problem or one core mission statement. That is, you want to spend a very small amount of time as a human, generating a, effectively, a very large amount of work for an AI, something that will spend a lot of time, a large amount of time executing, unattended without any further input. Simple. A really simple approach for this, which most of us have tried, is we create a prompt or a meta prompt to instruct our agent to work through a number of tasks independently. You typically put the tasks into one file, call it say to do.md, and then you put the prompt in a different file. Now, you have to put the prompt in a file. Let's say you're using Claude code, you have to put it in Claude.md. If you don't, this whole technique fails. Because back to that point about the context window, if you've got a to do list of the 100 items in it, and that's going to run for 10 hours, then Claude will saturate the context window within the first, I don't know, 30 minutes. And when it saturates the context window, it will automatically compact, when it auto-compacts, it will lose the information of your original prompt. It will preserve some of the thinking, but as we're about to see in a moment, preserving some but not all is a failure, and it's a source of immediate failure with this overnight work. However, if you put the instructions into Claude.md, Claude code, guarantee, and each of the agents, or the other agents has a similar mechanism, Claude code guarantees that after auto-compacting, it will reread the Claude.md word-for-word, and run with it faithfully. So, you've got to do with dot md with your to-do list, and you've got Claude.md with your special prompt, your meta-promped. And this is very simple. You just put a subheading in there, along with whatever else is in your Claude.md. Something like your overnight process is, with some number of bullet points. Step one, take the next uncompleted task from the to-do.md file, and mark it as in-progress. Step two, complete the task, and mark it completed in the to-do list. Step three, return step one. That's it. To run this, you then have to trigger it somehow, so you have to do a prompt, something like, run your process. It'll pick it up in the Claude.md, and it will also read the Claude.md, find the to-do.md, and run with it. If you haven't already done that, try it. Write that loop. Tweak it a bit. See what happens. How high do you get your unattended agent time? What works? What goes wrong? The big point here, and the thing that I think, before you get into looking at any of the frameworks, or techniques, or methodologies, the thing that you should look at first, is what did you just do, and what did I just describe? I called it a while loop, or a full loop, and I said it was a metaprompt. So really what I've just described is a form of programming. We've written a program to control the agent itself, and you've written the program inside a prompt that you triggered from a different prompt. Agents themselves have an internal set of scripts. They are a program, and they're speaking to other programs, and if you're using the Fisors coding, they're also writing programs. But this is a program to control that set programs. So I like to think of this as agent metaprogramming, obviously borrowing from the concept in C++ of template metaprogramming, where to oversimplify it, we used source code that rewrote itself at compile time. So in this case, we're providing a metaprogram that changes how the agent is going to run at runtime. When you look at it like that, you start to ask some immediate questions like, "Why am I doing agent metaprogramming in a badly written half-assed Claude.MD file in natural language?" "Why am I not writing it in a shell script or a high-level programming language?" "Something that's faster, more reliable, can be debugged, etc." In fact, debugged. "Do we even have a debugger for our prompting?" Yeah, not great. And this is where you should start playing with things like STD or backlog.MD, start adding paraphernalia. But I feel if you run into those too soon, without asking yourself where you're starting from, you miss a lot of opportunities to get a lot of improvements on this. Now, once you start this, the very first thing you're going to run into as problems is compaction. So I said stick everything in Claude.MD, the unpredictable but inevitable compaction, auto compaction, you don't lose all your work. Yes, sure, but you don't have control of when the compaction happens. Even though it's a very frequently asked for feature. And instead, the recommendation here is indeed write a shell script instead of the prompt. And the shell script is almost word for word what that prompt is. The one difference is that you invoke your agent from the command line. So the agent gets re-invoked at step one each time, which effectively acts as an automatic clear happening at a controlled moment of your choice. So you'll get a higher quality overall. So when you start thinking about this as a meta-program, you start to come up with a lot better optimizations just immediately. However, let's take a step back. How are we going to improve this? Let's be really clear. There's three elements to what our solution is. Number one, human time must be tiny, very, very small. Otherwise, we undermine the whole point. Number two, AI time must be huge, very large. Again, otherwise, we're missing the upside that we're looking for. Number three, the AI time must proceed without waiting for extra input, which can be a killer. But between those three, that's how we're going to get to 10 plus hours of runtime. We want to do better than this three-step loop I had. Let's look at the to-do list. We're going to have to fill the to-do list effortlessly, because if it's not effortless, that human time step one fails or point one fails. And we're back to the human babysitting the AI. And this is where some of the common approaches, like a Spectriff and Development, step in and provide a lot of value. But I think for the overnight problem, they're the wrong way. solution to this because they require a lot of human up front time in order to get that list populated and to keep it groomed. And while they work very well, so SDD in particular, while it works very well and I've used it a lot in day to day work, it doesn't work so well for unattended work. And the systems which try to clone SDD but instead have agents do all the different steps in SDD equally, they don't work because they have the AI make too many decisions and we see quality plummet. Although that may not be such a bad problem, I'll come back to that later. Just a couple of other things ways to fill the list, so I think one of the ones that's easiest to do but highly effective is accumulate work during the day and just add it to do list as you go along. So treat the to do list like a agile backlog that you're just spamming things onto as soon as you think of them. And what happens when a team does that is you'll notice you start phrasing things, you'll work during the day knowing that the agent is going to be working on them overnight. A common one is to do a day or several hours of bug fixing or bug hunting. We don't actually fix the bugs. Each conversation you do with your LLAM, you track down the root cause, you find the cause, you ask the LLAM to write a unit test that will fail because of the bug and will succeed if it's fixed. You check the unit tests are failing as expected. But then you don't fix it. You immediately just say to the LLAM, add a to do list item to fix this bug. And the LLAMs are extremely good at just dumping the right amount of context into that to do list. I would say 80% of the time they pick exactly the right amount of context, maybe 90, 95% of time. And you don't need anything. Don't need any framework to achieve that. But obviously you can tune that and prove it and get that 90%, 95% up to 99%. I've already mentioned SDD, of course, as we're doing this. One thing I don't like about SDD though is that it feels very much like waterfall to find everything in advance. Do the thing I told you to do. Check you did the thing I told you to do. And then I will come back and check that you checked the thing you did the thing. I just forget it. This is not the way of working and it's not the way that agents like to work. So I feel SDD is a band-aid at this point and I'm trying to let go of it. Let's go back to, yeah. So the next thing I want to talk about is assuming you fill up your to-do list, how long is that going to run for? You spend a whole day accumulating tasks and dump it in. That's not going to run for 16 hours, guarantee you. At best you'll probably find it runs for two to and a half hours. Which is great. That's a big improvement over what we had. But it is still far below where we're going aiming for. You've got maybe 50 or 100 to do list items. But you'll often come back the next morning, you look at the elapsed time and it says 47 minutes and you go, oh man, fixed 100 bugs in 47 minutes and then it spent the next 15 and a half hours doing nothing. And I've found that to get this next improvement, what you've got to do is you've got to add, I mentioned broadening of tasks, but I think of the next set as exploding tasks, tasks that themselves intrinsically generate a lot more tasks. So we need to run the the metaphor from itself in such a way that it can continuously not just shrink the to-do list by completing items but also grow the to-do list. And that's how, yeah, I mean, let's keep the AI busy for a longer. I think of this in terms of an agent meta program. It's been quite easy to think of ways to insert exploding tasks. So one of the most obvious is add a tech-step, tech-debt explosion. So in your to-do list file, at the top, put a counter of how many tasks have been completed and modify your agent meta program to say after each task is completed, update the counter by incrementing it by one. And then insert an extra step, which says something like, if the completed tasks counter is greater than 10, reset it to zero, and append a new task to the end of the to-do list, which is perform a tech-debt suite sweep of the code base. And the tech-debt suite of the code sweep of the code base should not fix any problems or change any code. It should only generate additional new tasks that are also added to the end of the to-do list. Great. And then you can obviously, you can tweak the numbers based on your code size, code base, and you can add your own specific house style for what you want tech-debt to cover, etc. But that approach works really well. And I think it's not accidental that something like this looks a lot like the other big successes we see a lot of in an AI agentic, which is just get the AI to keep doing stuff until it's until it works. Just let it invent stuff, find stuff, repeat stuff. But there's lots of other things you can come up with as well as exploding tasks. So the tech-debt one is just an illicit just for example. Yeah, so for another one, for example, if you're doing coding is to say every, maybe every hundred tasks that are completed, so have a separate counter, look for new system architecture paradigms that would work better with this code base than the current architecture. So this is not to say you're not going to do system architecture design on your code base. Just to say you need the AI to keep busy, so give it something useful to do. You don't have to adopt those paradigms, which is important. Let's come onto output because there's something I didn't mention in my list of our three core goals that we're achieving with this solution. There is a practical problem. It's not just we need it to work for 10 hours overnight. It's the best that we need the work it produces to be something we can use afterwards. One thing we all know about is AI Slop, which I hate. It's very real, it's everywhere, and it's horrible. It's effortless for someone to type in a couple of sentences. Write me a blog post that 30,000 words long on the topic of carrots. There I will go and do that for almost zero effort on my part. Similarly, if you're looking at a code base, for instance, doing actual real work, it's very easy to give the AI a fairly simple task and it can go and generate vast amounts of source code way more than we have time to read or can be bothered to read. And obviously there are things you can do to try and reduce that or re-review it or pre-review it. But this is where you can easily get hung up on worrying too much about the quality. It doesn't actually matter. These overnight loops. The thing that matters most is can you isolate the work that was done overnight because if you run it overnight and the results aren't great, just throw it away. Let it run again tonight but with some modified instructions. And that may not seem like a brilliant thing for me to be saying and I do feel a bit uncomfortable about it. But I'll refer you back to the start of this episode where I was talking about how long has anyone managed to get these things running overnight. Most people aren't running them at all overnight. Let alone more than five, ten minutes, twenty minutes, thirty minutes. So if you can get it to run once for sixteen hours, if you run it sixteen hours every single day and you have to throw away five in every six of those, you've still made a massive improvement on what was came before. So my argument is at least for today, do not worry about the quality so much. The quite a, quite a, quite a slippery is not the word. Quite slap dash with it. That's the word I was looking for. Just throw it against the wall, see what sticks. Last thing I want to say about this is what goes wrong. Now I've made minor mef references to lots of small different things that go wrong but there's two big things that go wrong. The first one is explosive tasks but a lot of teams I see doing this don't try to add explosive tasks so they just aren't getting beyond an hour or so, not reliably. The second big fundamental one is people not being inventive enough on the nature of the tasks. In general, because you don't know what's going to happen, you're not there, it's going to run unattended for a long time. People get scared and they fall back on command control. This is a standard psychology thing. And then this comes back to one of why I'm trying to move away from SDD because SDD is basically waterfall in disguise. It's command and control, it's great, it gives you lots of understanding of what was decided and why, but it's not great for what I really want, which is to say, I'm going to give you an open-ended task and I want you to run with it. To take us back closer towards that impossible thing of an art, a true artificial intelligence where it can broaden the scope for us. But in concrete in practical terms, this is things like, are you giving it tasks that say fix this bug, fix this big bug, fix that bug, fix this bug? Or are you giving it tasks like, or like the tech debt example, are you giving it tasks like, not the tech debt, the system architecture, are you giving it creative open tasks like, look at this code base, take a step back, see if there is a better architecture that could have been used. The last part of this episode is something I mentioned really right in the first opening statements, but cost elephant in the room. The vendors work very, very hard to make sure you have no idea how much it costs to use AI. They, like, class a drug deal with vendors, they want you to get addicted and not worry about the costs until it's too late and you are far, far down the rabbit hole and can't get out. There's a huge amount to say about this. I will be posting a lot more notes on this to my AI newsletter in coming weeks and months. In fact, actually, good point, I'm on the cost front, I'm not going to go too much detail here. I'm just going to give some of the headline stuff, but I'll post some additional notes to the newsletter probably next week because I've got a lot of the background working that I'll just copy and paste into the newsletter. But briefly, just to give a tiny bit of context, three years ago, 2023, OpenAI was charging $30 a month for all you can eat subscription. They were also charging pay as you go API key fees. Those two are still fundamentally the main options, subscription or pay as you go. Pay as you go fees are relatively easy for us to predictively measure if you already have evidence of how much you've been using it because they charge you per token usage and token usage varies a lot based on your use cases. But the subscription pricing is a wild, wild west. The vendors keep changing their undefined definitions of what they mean, generally not in our favour. So if we want to talk about 16 hours overnight or even 24 hours a day, what's that going to cost you? I remember we're only going to talk about one agent. We talk about multi-agent swarms is a massive overcompicates problem, but also b, once we look at the cost, you'll realise multi-agent swarms are mostly fake. Most of the people who say they're using them are lying because once you count the numbers you see they're not, they're just not doing that. Some are, but most aren't. They're more fun research projects and things to post about on YouTube than they are the reality. Obviously if you're one of the people who's genuine in the using multi-agent swarms for realsies every day, please get in touch because I would love to interview you and share with everyone a lot more about how, why, what, where and how you're paying for it as well. Anyway, so there's, well, I said there's two forms of pricing. I said subscription and pay as you go, but actually there are three. Because when they introduced enterprise accounts, they made enterprise accounts a weird mishmash between subscription and pay as you go. And I'm just going to take some of the headline values from my research on this. The, let's take, we'll just look at Anthropic and Open AI. Anthropic, you are currently paying. If you run 24/7, sorry, you are currently paying at maximum about $150 per hour of running an Anthropic agent at 4C. And on GPT Open AI, you're paying about $3,000 an hour at maximum. In practice, you're realistically running more like $50 to $100 an hour for each of those, maybe $150 an hour. But somewhere in the $50 to $100 an hour ranges, most people are doing that aren't actually running the agent continuously. So I normally use $150 to $200 an hour as my rule of thumb. And that's the, that is the subscription based pricing. No, sorry, that's the, that's the pay as you go based pricing. So that works out at, months the is well over $100,000. So about $150,000 a month. If you're doing this flat out for one agent, and then you think about those people claiming they have these swarms of 40 agents running continuously. And you look at them a bit funny and go, are you really interesting, interesting claim, bold, very bold. I have not mentioned GPT Pro there, which the costs for running GPT Pro are absolutely absurd. If you try and do this, you are measuring tens of thousands of dollars per hour for a single thing if you're pushing it to its max. Those aren't even real because you're rate limited by GPT Pro's slowness. But yeah, GPT Pro is a whole separate, careful, or fit. So in reality, most people do is they stack subscription accounts instead. And at the moment, you need about seven or eight subscription accounts at the top subscription tier to be able to cover a month. So for instance, if you're on an anthropic, you, you buy eight separate accounts in eight separate names at the 28 20 or 200 max, 20 x max. Can't remember what it's got max 20 thing, which costs $200 a month. It's by about eight of them. So you're paying about $1,500, well, $1,600 a month. And you use one until they block you and then you use the second until they block you, then you use the third. And by the time you've finished using the eighth, they've unblocked you for the first. So you go back to the first. So if you want to run one agent 24/7, you're looking about one and a half thousand dollars a month. And you're crossing your fingers and hoping you don't get banned because in their hatred of open claw and all it represents in destroying their cushy, claimed, or you can eat model, but not really. They have been, and not just anthropic, but the other vendors as well, aggressively clamping down on people who actually use the subscription they're paying for. I'm going to have to go back to cost because something big happened recently. And this whole thing is completely unrealistic if we ignore the practical realities of the cost of doing this. So until late 2025, this was all entirely viable and worked as intended. And then in early 2026, open claw happened. And possibly coincidentally, because the vendors already had problems of their profitability or possibly driven by open claw itself, the pricing models were aggressively made worse across the board. And this has got so bad that in the time I was recording this podcast, and Throffick, who most people's preferred vendor for agente-k-i work, did a radical change, even more radical than their previous ones. So previously they'd recently introduced surge pricing, which was pretty radical and not taken well. And they'd then banned open claw, which was also not taken well. And they have now reinstated the ability to use thing third party AI agents, which was what they'd banned to prevent open claw. But in doing so, they've come up with their nuclear option, which is to charge pay as you go prices on any use of scripting agents, AI agents, anything related to that. Now I said you can write the loop as a low quality, low performance prompt, but still is good. It will get you some overnight rolling work by the agent. So let's take a quick step back for anyone who's not intimately familiar with the cost models. And this is something I want to go into, if I get time into a future podcast, or I will post about it in a newsletter, because there's so much to say about the lies that the the end. industry and people within the industry tell themselves in each other about AI pricing. But key things, broadly speaking, three cost models that commercial vendors offer. You have subscriptions with secret fair usage caps. None of the vendors provide clear fair usage caps. They all hide it in different ways. And then you've got payers you go, which is the API key. And they'll let you use it as much as you want. And they charge you a flat rate. They charge you the same rate per usage, no matter how much you're using. And then finally, you've got enterprise, which is in some ways the worst of all options. You get the high base cost. You get unpredictable spend and you get unlimited total cost. So generally people don't really like spending on the enterprise versions. Very briefly, payers you go, realistic prices if you're going to try and use it properly is thousands of dollars per user per month as of mid to 2026. But at 24/7 usage on a single agent, you're looking at probably tens of thousands of dollars per month, low tens of thousands. And it varies from vendor to vendor, but that's the kind of scale. And that's why no one wants to use payers you go for a genetic work. The subscriptions are being aggressively cut back by vendors. The excuse that was given in late 25 early 26 was abusers who were spending hundreds of thousands of dollars a month on a $200 a month subscription. And vague assertions made on Twitter about compute farms that were abusing this pricing model. But that doesn't make any sense. It doesn't match reality. It's clearly a load of marketing crap. If that were the problem, they could cut those people off instantaneously. They have all the data to do so. They have all the machinery to do so. They've never had any problem of doing that. And yeah, the actions they've taken are completely unrelated to such parties. And instead have been targeted at the mass market audience of everyone who's using agents. So I don't buy it. And then enterprise, last thing to say about enterprise is because it's so expensive to do payers you go. The standard approach for a lot of the last three years was to buy multiple subscriptions per person and round robin between them. So you use a subscription from 9 a.m. in the morning until it runs out time limited or money limited. And then you switch over to subscription to for the rest of the day or the next few days, depending on how the caps work. It's different from vendor to vendor. And you typically need somewhere between 8 to 10 of those subscriptions if you're going to cover yourself for a whole month. So you're typically looking at a couple of thousand dollars a month per person. And you do that until your company gets to the point where you've got in the region of 100 plus users and the vendors then force you to become a enterprise. And the definition of enterprise is basically any small company, any small business who's actually using AI. This really leaves only one credible option or two credible options. One option is we can of course just not bother. Let's not use AI. Let's not get benefit from it. Let's be good little citizens and just slave away doing everything by hand until someone else takes our jobs. But the other option that the vendors are pushing us towards very, very fast is the frequently avoided self hosting. Self hosting is looking already at the end of 2025. It was commercially sensible, viable, valuable. Early 2026 it was looking commercially attractive. But now in mid 2026 it's looking like you're a fool if you're not doing it. I do want to do a whole podcast on that as well at some point, but very briefly the things to consider there. Your entry cost is much lower than people assume. Nvidia headlines with half million dollar, five million dollar, ten million dollar hardware options. Your entry cost is really an Apple Mac studio which for historic reasons to do with the M series chips are the best bang for your buck on self hosting. You're going to be using Chinese models or Chinese derived models, so quen, deep seek, things like that. The quality you can expect is somewhere around GPT-4 or GPT-5. It's faster, cheaper and better than most people expect. I'm going to stop there. I mentioned a few times that I have resurrected my AI newsletter. It will, I've decided I'm really just going to use it for posting more details about when I give conference talks, more details that I didn't include in the talk, extra slides, background thinking, and for these podcasts as well. I'm just going to post some of the background working. On the pricing thing, pricing's fascinating and important, but I don't think most people listen to this want to go into the fine detail and there is a lot of detail and there is a lot of hidden guesswork and heuristics. I will just kind of info dump that a bit into the newsletter. Final thoughts. If any of this stuff is relevant to you and you've been using it and you have, especially if you have conflicting opinions, please get in touch because what I like to do is to alternate between one podcast on a topic and in the next episode being an interview with someone who has different opinions and we can debate it out. So get in touch.