I found the cheapest AI Model for building workflows

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: I found the cheapest AI Model for building workflows · Channel: n8n · 29:44 · Watch on YouTube

Topics: AI agents, Task and workflow automation, AI evaluation and benchmarks, AI models

Summary

The video compares six frontier AI models on their ability to build two n8n workflows using MCP: an hourly RSS-to-data-table workflow and a news-question-answering agent with an API endpoint. All six models completed the first task, with GLM 5.3 being the cheapest at $0.68. For the more complex second task, the presenter disqualified several models for issues such as fetching every article instead of searching, returning all rows, or missing error handling. Under the presenter’s strict criteria, Grok 4.7 was the overall winner at $7.36 for both tasks, while Opus 5.5 cost $8.68; the video emphasizes that cheaper models may still be useful if users can review and correct their work.

Key points

The test used six models: Opus 5.5, GPT-6 Astra, Grok 4.7, GLM 5.3, Kimi K3, and Qwen 3.8 Max.
Task one was to build an hourly RSS workflow that normalizes articles, avoids duplicates, and stores them in an n8n data table.
All six models passed task one; GLM 5.3 was cheapest at $0.68, followed by Kimi K3 at $0.81 and Qwen 3.8 Max at $0.81.
Task two required a news agent usable in n8n chat and as a sub-workflow, plus a /news API endpoint with a default count of 10.
The presenter judged workflow quality, not just whether the workflow ran, and disqualified models for design flaws that could cause problems in real use.
Astra was disqualified for loading the latest articles before every agent response; GLM and Kimi were disqualified for tools that returned all matching rows, and both also lacked an API error response.
Qwen was disqualified for retrieving all articles, and its API workflow also lacked an error response.
Grok 4.7 and Opus 5.5 were the only models to pass both tasks under the presenter’s criteria.
Grok 4.7 won overall at $7.36 and about half an hour; Opus 5.5 cost $8.68 and took about 32 minutes.
The presenter recommends Grok for users who want a model to handle complex workflows automatically, while less expensive options may suit users willing to review and refine the results.

Chapters

Start	Chapter	Summary
00:00	Test setup and the RSS workflow task	The presenter introduces the six models, the MCP setup, and the criteria for a good hourly RSS-to-data-table workflow.
02:46	Task one: proprietary models	Opus 5.5, GPT-6 Astra, and Grok 4.7 each build a working RSS workflow, with Astra leading on cost and speed among them.
07:03	Task one: open-source models	GLM 5.3, Kimi K3, and Qwen 3.8 Max also complete the RSS task, and the presenter compares their costs and results.
11:51	Task two requirements	The presenter defines the news agent and API endpoint tasks, including chat support, article-search tools, and JSON responses.
15:05	Task two: Opus, Astra, and Grok	Opus builds a robust agent and API, Astra is disqualified for a poor data-loading design, and Grok passes after a longer build.
21:38	Task two: GLM, Kimi, and Qwen	The open-source models are evaluated, with the presenter disqualifying them for issues including unbounded article retrieval and missing API error handling.
27:06	Overall results and winner	The presenter totals the costs, names Grok 4.7 the winner under the stated criteria, and discusses when cheaper models may still be useful.

Quotes

is it going to cost me one or $15 to solve my problem? — 00:31

So Astra passed the test. It completed the task. — 05:26

So for me, GLM, we’ll check out the API, but but I’m sorry, you’re out. — 23:24

Grock seems to be the best right now. — 28:40

Grock’s our winner. — 29:13

Concepts and entities

n8n, MCP, Claude Code, OpenCode, Opus 5.5, GPT-6 Astra, Grok 4.7, GLM-5.3, Kimi K3, Qwen3.8 Max

Full transcript (original language)

00:00 In this video, I’m going to find which Frontier AI model is the cheapest at automatically generating reliable NEN workflows from your favorite AI harness like Claude Code or Codeex using MCP. I’ve selected six promising Frontier models, including Opus 5.5 and some beefy open-source contestants to go head-to-head on two tasks. Task one is a data scraping flow for top news articles and a data table to store it in. And for task two, the models have to build an AI agent that can access this data table and be used inside the native Nitn chat

00:31 or wrapped as an API endpoint. And I’m finding the cheapest model because honestly all the Frontier models are pretty good at building codelike things these days. And the NAN MCP feature provides a lot of context and tools to the models on how to build a valid workflow. So what I really want to know is is it going to cost me one or $15 to solve my problem? To run the test, I’m using N version 2.40.6 six on a self-hosted instance with MCP connected to my harness. A slew of hot models with a mix of open- source and proprietary ones, including Opus 5.5, GPT6 Astra, Gro 4.7, GLM 5.3, Kimmy K3, and last but

01:09 not least, Quen 3.8 Max. For each model, we’ll set the effort level to a maximum available for a fair test. I’ll also use open code and open source AI harness like Claude Code to run our models. That way, no model gets an unfair advantage. All right, let’s find out which model is the most competent yet affordable. All right, let’s have a quick look at the prompt for task one. Implement the following use case on my end instance. Every hour, fetch all new news articles available on RSS feeds listed below and add each article to an end data table

01:41 called news articles. Only add each unique article once to the database. Data table should have headline, title, description, link to article, and the news outlet. In future, I should be able to easily add new RSS feeds to be monitored without needing to modify the workflow beyond. And then we have the RSS feeds. It’s an imperfect prompt, but it’s a realistic prompt. The kinds I might run when I need a quick workflow done. And then let’s go take a look at what a good workflow result would look like so we know what to compare to. I’m going to go into one that’s already built. Um, and here basically we should have a schedule trigger cuz we want this to run every hour. We need somewhere to store the list of those URLs because I need to be able to add to it. So a data

02:15 table where we can grab that, for example, counts. And then from there, if I just run the workflow, it basically needs to be able to fetch the URL and get all the news articles there. It needs to be able to normalize the schemas between these different news articles in there. So, it’s doing that. Ideally, it’s going to remove any duplicates in the run as well in case there’s some coming in from the RSS feeds. And then make sure that we’re not saving anything that already exists in data table. There’s an operation if row does not exist for that. And then we need to save the article in the data table. And then, of course, we need to have a data table. So I expect that a

02:46 news articles, data tables created with these columns. So that’s what good looks like for task one. So let’s move on to our first model. We’re going to start off with Opus 5.5. I think a model a lot of us have used. Let’s go over to open code. I’ve got the task one prompt in there. We’ve got it in max mode. My favorite. And let’s run it. All right, it’s gotten the SDK from Edit. Guess it’s off to the races. All right, so Opus did its thing. Let’s go over into N and check out its work.

03:19 So it’s created one workflow, hourly news articles from RSS feeds. That’s a pretty sensible title. I appreciate that there’s no EM dashes there. We’ve got a sticky note here. And we’ve got some groups. Actually, let’s just run it, too. We get the RSS feeds. We pull the RSS feeds. We got 96 items coming out for each one. Okay, that makes sense. We route that into formatting. Okay. So, unlike in our example, it’s using a set node in line, but that is normalizing to the output. That looks good. Yep. And then we’re filtering by valid articles.

03:54 So, if there’s no link, it doesn’t add it in. Oh, fair. Fair. And then we’re doing remove duplicates within the current input. Okay. So, it’s doing that for anything that it’s pulled from this list that’s duplicated. And then, yep, saving skipped articles. if row does not exist operation and then loading it into the data table with all these different values to insert. Final check is the data table. Go to news articles here and we see those have all loaded in there and we see it’s coming from the different outlets. Okay, so it passed

04:25 the test. That is we’re not going to disqualify it because it wasn’t able to do the workflow. It did great. All right, so looking at the leaderboard, it did it in $348 and it took 15 minutes. Is that long or not? We’ll see after we benchmark a couple more with Opus in. Let’s see how Astra does on this task. I got open code here. Astra set to max. Let’s run it. Let’s not read this and let’s go check out the workflow. So, hourly RSS news archive. Very nice. I appreciate there not being any EM dashes there. Let’s

04:56 expand these here. I Well, I guess that’s not ideal, but I’m not going to count that against it. Also, three groups. Just run this workflow. Okay. Also went for a data table. I’m not going to go check the table because it loaded these. So, it’s there. RSS feed reads those in. That works. Also going for the set node approach with inline stuff to trim those. Doing some pretty heavy logic there. But that is all turning into correctly shaped outputs. We are also filtering out things that are not filthy and things that are valid

05:26 URL. Okay, that’s pretty cool. Nice one, Astra. Good one, Sam. And then also ddup removing repeat items only articles already saved. And we can see that working because 91 articles went in. This already ran once, right? And so then only one new article since we ran it last time went in. Great. So Astra passed the test. It completed the task. But how did it do? So GPT Astra did it in $2.19. It’s currently in first place. Way cheaper. It’s way faster. I preferred its result compared to Opus. All right,

05:57 let’s see how Grock, our last proprietary model, cuz then we get into the open- source one, stacks up with Opus and GPT6 Astra. So, let’s go into open code. Grock 4.7. We got it on X High, which would have been cooler if it was named Max, but I won’t take it personally. All right, let’s run it. I’m really curious how this does cuz this is a pretty new model that just came out recently. So, let’s see. [music] All right, Grock is finished. Again, we’re not going to read any of this. We’re just going to go in the instance. So, let’s just run this whole thing. So,

06:30 we already ran it once. So, we see the dduplication is working because we got 90 items coming in there and two coming out of the skip articles already node. This looks basically the same as the other workflows. Yep, the mapping is happening in line. That’s mapping correctly. And the dduplication works. Yeah, this is I’ve seen enough. This is good. All right, let’s just check the data table for posterity. Our assess feed. Beautiful. And yeah, they’re all in there. So, it did the task. We’re not going to fail it. But how cheaply and how well did it do it? All right, let’s have a look. So, compared to Astra and

07:03 Opus, Grock did it in $2.51, about 10 minutes. So, Astra was way faster. It’s about in the middle there. So, it’s in second place right now. Interesting stuff. All right, let’s see how our open-source models compare to these heavily funded American proprietary models here. All right, let’s check that out. Okay, GLM 5.3, first of our opensource models we’re testing here. So, let’s go into open code. Let’s run that.

07:34 Let’s open up NN and let’s check out the hourly news RSS in store. Okay, so first off, the sticky note isn’t overlapping with this stuff. So, that’s pretty cool. It’s the wrong size, but you know, small wins. Trigger node also went for the data table. Let’s see if that pulls stuff in. Yep, we got those three right there. Then we fetch the actual articles and then we prepare them again. Normalizing the schemas and that’s working fine. Removing duplicates. Interesting. There were some duplicates and it removed them. Great. Let’s run that again. That should run exactly the same. Yep. And then keep only new

08:05 articles. That works beautifully. All right. Then just sanity check. Got the RSS feed with the three. Uh-huh. And the news articles are in fact loading in there. All right. GLM did do a working workflow. Looks great and actually positioned the sticky a little better than some of the proprietary models. How did it do on the leaderboard? All right, GLM did it in 68 cents. And look at the time as well. So tokens about the same as GPT6. So again, not all tokens are created equal, but look at the time. So it’s like this was about 3 minutes, so

08:35 it’s almost double, but look at that cost. Moving right along. Kimmy K3 task one. We’ll paste that in. We’re on Kimmy and we’re on my favorite mode, Max. Do it. really curious how these open source models work because I, for example, I’ve never used Kimmy before. This is going to be my first time. Let’s see if it knows how to put a sticky note in the right place. Let’s check its work. RSS news to data table. I’m really appreciating know dashes there to be honest. And yep, comment placement every hour.

09:08 Interesting. Kimmy chose to put this in a code node. It’s not as usable. I would have to do this. This is a way to enter it. And I could probably prompt it to tweet that and I’m confident it will do that. So that for me is coin. It then let’s see it creates one item that’s an array of those things and then it splits those out. So then we have three items and then it processes for each item in the RSS node. So it understands N items which means that N’s piping in the context. That’s pretty cool. It’s done that. It’s running another code node to do the normalization. Great. And that’s Yep. They’re all coming out all the same

09:39 there. It’s saving the article. Interesting. With an upsert. So an upsert, if you don’t know what that is, it’s an update or an insert. So it updates if it exists and it inserts if not. Technically, that wouldn’t lead to duplication. So nice one. Kimmy did it in not a lot of nodes, but this is fully valid just cuz we checked for all the other models so far. Check news articles here, and those are all coming in. All right, Kimmy, elegant job. But how did Kimmy do on cost? All right, looking at the leaderboard, let’s see if Kimmy unseats GLM 5.3. And it didn’t. But so far they’re cheaper than all of the

10:13 proprietary models. It makes sense. You don’t got to go pay Dario and Sam. Interesting thing is that tokens. All right. Quen 3.8 Max. Last of our models on task one. A model I’ve never used before. I’m really curious to see how this one stacks up. Let’s make sure it’s in my favorite max mode. And let’s run that. Let’s see how this stacks up. Okay. 3 minutes later and Quen has output. I’m actually a little nervous to look at this cuz I don’t know, for some reason I’m rooting for the open source

10:45 models. We’re not going to be biased when we review them, but would be cool to have some nice cheap open source models that you guys can use when you’re building your flows. All right. Yeah, sticky note placement’s garbage. All right, let’s do that. Okay, so far so good. Trigger. Yeah, let’s just run this. Okay, so it also went for the data table approach for the RSS feeds, which I like honestly. Doing the RSS feeds continue on fail because then we can filter them if link’s not empty. That’s nice. We normalize in the set node. Similar to what some of the other ones were doing. We’re dduping again with a dduplication node. Uh, and using the link as the ID. That makes sense. Skip

11:18 existing articles. That’s working. And then, yeah, it didn’t save the new articles cuz I mean, it had just run this when it was testing. So, there’s no new articles to add. And of course, just to be fair, let’s check. It added this table for the RSS feeds. And it also added these articles as well. Okay. So, it doesn’t get disqualified. So, that’s nice. But given it’s the last model, drum rollah, how did it do compared to I guess GLM 5.3, that’s the one to beat. And it did it in 81. Okay, interesting. So for task one, for cost, I guess it’s kind of unsurprising.

11:51 Open source is dominating here. And in terms of time, we got some options. So if you’re kind of building simpler workflows like this, GLM’s a great bet. I guess if you’re really crunched for time or doing some sort of something where you may be generating thousands of workflows or personalizing them, maybe um probably Quen seems like a pretty good option for you. So that’s task one. Next, let’s do task two and then we’re going to basically sum the cost and stuff between task one and task two and see the result for all the models and pick our winner. So before we find out who the winner is for task two and go test these models,

12:23 let’s have a look at what a good task completion looks like. So we have the prompt for task two. It’s implement the following use case on my end instance. An AI agent workflow can access existing news articles data table and can answer questions about recent headlines using only news article data table as source of truth. Agent can be used inside the native edit end chat feature and as a subworkflow but other workflows. And then two an API endpoint workflow. Endpoint is / news. When invoked, it calls the AI agent above to get a summary of latest articles defaulting to 10 unless a count parameter is included

12:57 in the call. So, we’re basically having it create two workflows. The agent an API wrapper workflow that consumes that and then separately it needs to be able to be used inside of Nen’s chat. What does good look like for task two? Let’s have a look at the agent first. We’re expecting there’s two triggers because we wanted to use it with NN’s native chat feature here and also as a subworkflow by the API wrapper. So, we’ve got these two. Um, we need some sort of normalization of input because these kind of have different inputs. And then we expect an AI agent. It’s got to have a chat model. We expect to have conversation memory because we want it

13:29 to work with chat. So, it has to have statefulness. And then ideally, it needs to have at least two tools, I would say, to search for articles. There’s the get recent, which is from the API endpoint use case. It’s going to need that. But then, if we’re chatting, it might need to be able to search articles. And that one’s a bit more complicated because when you’re doing search, the filters that it defines, let’s say for the title or for the description, they need to be keywords and you need to make sure to set it to contains because if it’s looking for an exact match of a sentence, for example, it’s very unlikely to find itself in the results. So, looks like a pretty simple use case,

13:59 but I specifically picked this because it has subworkflows interacting with parent workflows. We have multiple triggers. We’ve got tools with sort of nuance in those tools. So even though this might not be a use case that you’re trying to build, I picked use cases where the building blocks for most use cases are represented in it. So that’s the AI agent and then we have the API that consumes that AI agent. Pretty simple workflow, but again we’re just seeing if it can handle the concepts of multiple workflows. We expect to have a trigger. It’s got to set the path to /ne because we told it it’s going to be a / news endpoint. And then here it’s extracting the count of that because we

14:33 expect that we can send in a count parameter. And if not, it’s setting that as 10. And then we got to call the AI agent itself. And then it’s an API endpoint. If it errors out, which we’re using AI in the sub workflow, that very well could happen. We want to have proper error response and a proper JSON response here. It’s an API endpoint, so I need JSON back, not just like a text response or something like that. That’s what good looks like for task two. Let’s get into it. All right, let’s see how Opus 5.5 does on task two. In open code, we’ve got the N instance still in the state from task one. All right, let’s

15:05 run it. All right, Opus finished task two. It did a bunch of stuff here. Deployed them. Uh, let’s go check it out. We have the agent first. Let’s check that out. Okay, we got a sticky note. We’ve got a chat trigger. Nice. Cool. It even filled out these suggestions and whatnot, which is nice because then in the edit in

15:36 chat, if we go ahead and chat with this agent, we can see that it’s got those in there. All right, let’s go back. Let’s see. So, we got a sub workflow trigger and it’s defined some workflow inputs. Let’s see. Okay, the chat input and the session ID. That makes sense because we might need it for statefulness. We have a set node here that’s basically normalizing the inputs cuz we get a different structure from one versus the other. And then the agent itself. Okay, let’s have a look in here. We have Sonnet, we have conversation memory that putting in that session ID from the normalized node. Very nice. And we got

16:10 three tools. Okay, interesting. We got get latest articles. Get the most recent articles. We got a description. That’s nice. We’ve got a limit here. And it shows how to use that limit. Nice. We’ve got search articles by keyword. Also got a description. We’ve got must match any condition. And we’ve got a contains for both of these. Very nice with descriptions. Okay. Very well done here. Let’s check the agent though. See based on the chat input there and it normalized that. So that works. And then let’s check out the prompt. You’re a news agent and then assistant source of truth tools to use. Okay, that’s pretty

16:43 robust, I would say. Let’s check the API endpoint that’s supposed to use that. We’ve got a description bucketed this out. See, it’s a little bit different from what we had in the example. Let’s see if it’s feeling the same. Here we’ve got the news path from the web hook trigger. We’re extracting that count and it’s got basically very similar expression here and it’s doing some data validation on the count and it gives an error message if not. Okay, we call the sub workflow and we’ve got a success and error as well. Just check the success. Nice. We’re returning a valid JSON response. All right, so it passed the

17:17 test. It was able to complete the task and we have $5.20 minutes. Not the shortest time to be honest. Could have probably built it in that time. All right, let’s see how GPT6 Astra compares to Opus on task two cuz I mean in task one it did pretty good. We’ve got this set to max. All right, let’s run it. All right, Astra did its thing on task two. We’re going to not read any of this. We’re just going to go into the instance and check it out. All right,

17:48 it’s put those in some sections. Interesting. What’s going on here? We uh got a chatbased trigger beforehand. Okay, looks legit. And we got the subworkflow trigger with three inputs. Let’s see. We’ve got the chat input. Okay, we’ve got the count. Yeah, that makes sense cuz that’s something that’s sub workflow, for example, the the API input we asked it to do. And the session ID if we be using this in in some other way that’s not the API. We got to normalize these. Yep. Same thing as the other one was doing. Interesting. Load the latest articles before we get to the agent. Okay. So, what’s it what’s it

18:23 doing here? It gets the count. This is This is no good. In the chat example, every time I chat with this agent, it would pull this latest articles on every single response. That is a poor shoddy design. It got this wrong. I honestly kind of don’t care what’s happening next. Like, that’s just like no good. That’s a terrible design. Um, and it’s just got the ability to search tools. Let’s see if it did this well. But I’m thinking we may have to disqualify this one. Contains case insensitive. If you’re not an expert end user, you might not understand that that’s a really dumb thing to do and you’re not supposed to.

18:53 So Astra for me, let’s see how it did on the cost, but it’s disqualified in my opinion. So let’s see. Okay, it did it in $4.86. It’s faster than Opus. So it’s cheaper, it’s faster, but you would have to be really knowledgeable in it and have to be prompting it to get the result that you want there cuz it did some stuff well, but rules of rules. This here, that’s just shoddy. Poor design, so it’s disqualified. Say what you like in the comments, but this is my video, so it’s out. All right, let’s see how Grock 4.7 is doing on task two. We’ve set the instance to the state that it was from task one. Let’s run it. Oh,

19:27 this is getting interesting. Okay. And yep, it found the tools and the stuff and it’s off. [music] All right, Grock just finished task two. It took a long time. It’s almost 20 minutes. Let’s see if it did a good job. Let’s check out the news article agent. And okay, so so far Grock’s pretty terrible at putting sticky notes in and sizing them, but again, that’s not really that critical. Okay, we got a chat trigger. It’s got the things pre-filled. That’s nice UX. Cool. This

20:01 trigger, we’ve just got the question to ask for subworkflows for the API. And then a set node to normalize those like the other ones. An AI agent without some BS in front of it. That’s nice. chat model, chat memory with the basically normalized session ID that would come from either one of these branches and the tools. Okay, get latest. It’s hasn’t set a tool description, but the title is get latest news articles, so I think that’s sufficient. And it’s got limit. Okay, must match any condition. Yep, found. And then search news articles. A

20:33 more complicated tool. No tool description there. I don’t think necessarily needs in this case. I would have liked to see that, but must match any condition. Case insensitive short phrase to find. Okay. I would have liked to see short phrase or word, but this is pretty good there. Mhm. And then the agent itself. Let’s see the system message. You answer questions about recent news headlines. This looks decent. It’s maybe not as nice as Opus is, but all right, that’s the agent. I say right now it’s passing. It looks very much like the um what we expected there. And yeah, it’s working. It’s running. Gorgeous. All right. So, the API that consumes the agent. I’m going

21:06 to move this cuz that’s going to be poorly placed. Yep, I was right. And then it’s doing a get and a post. Get all post. Let’s see. Normalize the count. Yeah. Okay. So, if there is a count, do that. Otherwise, set it to 10. Call the newest agent with success and error. That’s cool. And then what’s happening here? Um, if it’s success, okay, it’s building the response before it goes in there. Uh-huh. And then sending it and otherwise responding with error with a response code. Yep. Okay. Grock did its job. Don’t love this here, but this is working. The get would work. So, it completed the task. How did it do

21:38 though? Okay. First place so far. So, I completed the task. It took the longest so far, though, by quite a bit. And it’s $4.85. I’m really curious how these open- source models are going to perform on this. So, let’s go check that out. Okay, let’s see how GLM is stacking up against our proprietary models in task two. I got it prepped in here. We’re in max mode, and the instance is in the same state as it was for task one. Let’s run it pretty quick already. Been a fast one so far. Let’s see how it does.

22:14 All right, GLM’s done. But was it any good? Let’s open up the agent. Okay, sticky notes. We’re going to stop commenting on how these models do sticky notes. Get better models. Okay, chat trigger. Yeah, this kind of stuff populated sub workflow. What parameters? Good. That works. We’re normalizing. Yep. Yep. Yep. And then we have the news agent. Okay, we have only one tool, the news articles tool. We do have chat memory correctly piping the session key depending on which one it would come from. But this one would never have a session key which means it would be blank which means if there is no key

22:48 let’s see let’s see in this workflow it’s not going to set a key which means in here we would ah ah ah nice otherwise execution ID that’s really smart from GM. So what’s happening basically the chat trigger provides a session ID. So if a session ID exists by the time we get to this node, we choose a session ID. If there isn’t a session ID cuz we’re using the sub workflow, it will use the execution ID of the current workflow which always exists. You stunt me glam, but that is elegant. Okay, use article tool. Let’s have a look in here. And then must match any condition and return all the Okay, I mean this

23:24 workflow is supposed to run every hour. So there will be thousands of articles in the database and so this will break it. Why would you think that’s a good idea? I’m so disappointed. GLM, you may disagree with me, but this is a shoddy tool. And if you looked at this, that’s the thing. If you’re not knowing what you’re doing in edit, this problem is only going to surface itself after days or weeks where it really builds up and then it starts breaking. So that’s the kind of problem I really don’t like when these AIs do because you’re going to latently figure that out maybe in production. So for me, GLM, we’ll check

23:54 out the API, but but I’m sorry, you’re out. We have an API. Normalize it. Calls the agent. There’s no error response either. Ah, GM, I had high hopes for you. Let’s look at the numbers, though. But it did not complete the task. So, it did it in ah $18. It would have been our cheapest model so far on this task as well. Um, it did it quickly though. So, it did a bad job quickly, but we’re going to keep going. So you might disagree with me, but I want to set a relatively high bar for its understanding of your intent with an imperfect prompt. Cuz that’s the whole point. If you have to like perfectly tell these things what to do, then you’re serving it. These are tools that

24:27 are supposed to help you. And I think for a lot of NN users on a complex workflow, that could be dangerous to use that unless you really know what you’re doing. So I’d use GLM with caution at this point. So after an unfortunate performance from GLM being disqualified, it’s on Kimmy K3 and Quen 3.8 Max from the open source camp. So, let’s see how Kimmy does on this second task. I’ve got it loaded in. Same state as from task one and max mode. Let’s run this and let’s see if Kimmy’s the cheapest model so far.

24:58 Okay, Kimmy was lightning fast, but let’s see if that translates to an actually good workflow. So, agent. Okay, we’re not normalizing data here, but let’s see. Let’s see. Maybe maybe it did something inside the workbook cuz we had we had one of these models tricking me for a bit and then it was very elegant. Okay, but the chat trigger set up execute workflow trigger. What do we have? We had the query. Okay, and the session ID. It’s got a pretty simple thing there. Okay, let’s check inside the news agent. Okay, nice. So, this is

25:28 why it doesn’t have to normalize right now the input because this is the prompt coming from earlier in the workflow. So, chat input is where that value would be in the chat trigger here and doquery is the one that it’s set here. So that’s pretty elegant. Okay, let’s check conversation memory. It asks for session ID. This is automatic. And from the connected chat trigger node. So basically, okay, interesting thing is so the chat trigger will furnish this. Um, but then the execute workflow trigger, they set it to the same name. So it would also technically work even though this isn’t necessarily set the way a

26:02 human might do it, but it works. But it’s only got one tool. See what this does. Row get must match any condition. Ah, return all. H I mean, what? We we failed GLM for that reason, right? Because again, this would explode. So, I feel like it’s not fair to not fail Kimmy just for posterity. Let’s check the API. Ah, didn’t have an error response either. All right, Kimmy, let’s see how you did in terms of cost and that kind of thing. Kimmy got $1.76. So, yeah, also cheap, but not as cheap as GLM. A lot faster, though. But pretty subpar performance, especially if you were someone that doesn’t know what

26:35 you’re doing. I mean, it doesn’t mean that it didn’t put together some notes, but it’s in that nuance where these models are actually helpful because then otherwise if you’re just like fixing broken workflows and have to know everything about those workflows, then it’s not really that helpful. So, unfortunately, Kimmy, you’re out. And I hope for a cheap open-source model that’s not going to be five bucks, basically runs with Quen 3.8 Max. Let’s see how that does. Wow, this is getting crazy. Time for the last model of our last task, Quen 3.8 Max. It could take home gold or it could get disqualified

27:06 and we would have zero opensource models in our list. It’s going to open code. Let’s run that. And you’ll obviously get a nice fancy time lapse and see this in about 5 seconds. I will have to wait a bit longer, but let’s see. I’m kind of stressed. It’s kind of a big deal. Let’s open up the AI agent and let’s hope it’s not doing some ridiculous stuff cuz I’d love for one open source model to not get disqualified. Okay. get news articles and ah it’s getting all getting all the articles and we said that would be a

27:39 reason to disqualify it. These guys did everything else. So wow. I mean let’s let’s go check out the the API here. Uh it’s got a get and a post wired to there for the same thing. No error response. Quen did it in $2.19 but unfortunately got disqualified which means that only Grock and Opus remain technically based on on the rules that I set for this challenge. Yeah, let’s have a look overall what we got here. We got Grock in number one for

28:10 a total of $7.36 and about half an hour to build those two workflows. Opus $8.68 took about 32 minutes. tokens. I guess again doesn’t really matter cuz tokens aren’t one for one. And then looking at some of the ones that were disqualified, which again I was pretty stringent in what should be in and should be out. I could have loosened that up. Maybe this would be a more fun video. But again, I wanted to be kind of brutal there because if you’re going to use a model that costs dollars to do something for you, I want you to know if you have to be an expert at the thing that you’re working on to use that because if you

28:40 have no idea what you’re doing and use a more expensive model, probably seven bucks is like an amazing deal for you because like an engineer would be like way way way more. But if you do know what you’re doing and you see a cost difference where you can maybe do it for $1.76 and you know you’re just going to have to like tell it what to do a bit more, that could be really useful for you. So the cheapest model so far was GLM 5.3, but Srock seems to be the best right now. And then I think from the open- source models in terms of cost, GLM’s the best, but in terms of output, they were all kind of pretty similar. They all kind of got the same things a little bit off there. So with all that in mind, Grock’s our winner. Rock’s the best model to use. If you don’t know

29:13 what you’re doing and you want it to do it automatically and had all complex stuff, if you’re willing to do a bit of work, you can go with Quen. Well, at that point, Kimmy probably, right, cuz Kimmyy’s was pretty fast there and and relative around the same price. In any case, if you want to see more comparison videos like this, NN actually invited me on their channel to give this video. So, big shout out to the Naden team for letting me do that. Uh, this was a ton of fun. I’m a little devastated, to be honest with the open source models. But if you want a follow-up to this, maybe we drill down open source models, let me know. Drop a comment. It’ll let the NEND end team know that you want me back here

29:44 um again. So, thanks for having me. I hope you learned something from this. This was a saga for me. And as always, happy flow programming.