Jev AI vs Open Source: Can GLiNER Replace It?

Author: James Briggs · Watch on YouTube

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: Jev AI vs Open Source: Can GLiNER Replace It? · Channel: James Briggs · 34:10 · Watch on YouTube

Topics: AI agents, AI models, Local and open-source models, AI safety

Summary

The video explains Jev as a fast, non-generative classification model designed to complement rather than replace LLMs. Its standout feature is calibrated probabilities, which make its confidence more useful for building predictable AI workflows, alongside high speed and strong performance on several classification and guardrail benchmarks. The video compares Jev with open-source GLiNER models, which can be much faster when run locally but do not provide the same calibrated confidence. In Doom experiments, combining a fast classifier with an LLM coach can improve strategic behavior, and the presenter argues that Jev and open-source alternatives both have a place in AI systems.

Key points

Jev is a System 1-style model: a fast classifier that returns decisions rather than generating natural-language text.
Its API accepts state and questions defined with choice, score, or null output types.
Jev’s calibrated probabilities indicate how often its predictions are expected to be correct, making them valuable for production workflows.
Jev is substantially faster than the compared LLM and can evaluate multiple decisions in parallel.
Benchmarks show strong Jev results for classification, guardrails, and some tool-selection tasks, but it does not replace LLMs for text generation.
Jev has limits, including a maximum of 255 parallel decisions and a state limit of about 32,000 tokens, with performance reportedly degrading earlier.
Open-source GLiNER models are small and can run locally; in the presenter’s tests, they performed well and were sometimes faster or stronger than Jev.
Unlike Jev, GLiNER does not provide the same calibrated probability guarantees, and different GLiNER variants serve different tasks.
In Doom experiments, an LLM can provide strategic goals to a fast model; the local GLiNER-plus-LLM setup achieved a much higher score than using GLiNER alone.
The presenter sees guardrails and tool selection as promising starting points for using Jev and open-source alternatives in AI workflows.

Chapters

Start	Chapter	Summary
00:00	Introducing Jev and System 1 models	The presenter introduces Jev as a hyped non-LLM model and frames it as a fast decision-making system alongside LLMs.
02:38	Jev’s inputs and output types	The video explains how Jev receives state and questions, using Doom as an example, and describes its choice, score, and null outputs.
06:17	Calibrated probabilities and reliability	The presenter explains calibrated confidence, compares Jev’s calibration with an LLM, and discusses why this matters for predictable AI workflows.
10:33	Speed, benchmarks, and Jev’s limits	The video compares Jev’s latency and benchmark performance with an LLM, then clarifies that Jev complements rather than replaces generative models.
14:48	Jev’s closed-source status and open alternatives	The presenter discusses Jev’s limited public technical details and introduces existing open-source models that can perform similar tasks.
17:24	GLiNER models and their capabilities	The video reviews GLiNER model sizes and benchmark results, then explains how GLiNER 2.5 represents tasks, labels, and input text.
23:12	GLiNER trade-offs and local speed	The presenter contrasts GLiNER’s lack of calibrated probabilities with Jev and highlights the speed of running GLiNER locally.
25:49	Combining fast and slow thinking	The video applies the System 1 and System 2 idea to Doom, with an LLM supplying strategic instructions to a fast classifier.
28:26	Doom experiments with an LLM coach	The presenter compares Doom maps and reports that an LLM coach improves GLiNER’s performance in a deathmatch scenario.
30:01	Local models, latency, and the future of Jev	The video compares local GLiNER and hosted Jev response speeds, considers Jev’s competitive moat, and concludes that both open and proprietary models belong in AI stacks.

Quotes

it changes what we can actually do with AI — 00:30

that means Jev will be correct on that particular item roughly 80% of the time. — 06:48

Jev does everything in parallel. — 11:35

It is a additional component that we can use alongside LMS, not a replacement. — 13:43

they absolutely deserve a place in our agentic workflows, in our AI stacks. — 33:08

Concepts and entities

Jev, GLiNER, GLiNER 2.5, GLiGuard, TypeSafe AI, Daniel Kahneman, Figure Robotics, VizDoom, DOOM, probabilidade calibrada, System 1, System 2, LLM

Full transcript (original language)

00:00 Jev is one of the most hyped AI models of the year. And what is most interesting about that is that it’s not an LLM. It’s not coming from OpenAI anthropic deepseek. It’s a new lab that has just come out of stealth type safe AI. And the architecture that they’re using here is not generative, which has been the entire focus of AI for the past four or so years. So it’s very

00:30 interesting that all of a sudden the mainstream hype is over something that is not an LLM. In this case, I actually believe the hype is justified. It’s typed. It’s ultra fast. It very importantly includes calibrated decision making and through those things it changes what we can actually do with AI and I think importantly everything that type safe have done with Jeff makes AI feel a little less dystopian and I’ll

01:02 explain more about that later. So, we’re going to explore Jevit’s its place in the broader AI stack, the very real and capable open-source alternatives to Jev, and how we can think fast and slow to beat solo Jev at doom. So, let’s jump in with what Jev is. So, Typesafe have announced Jev as a new type of model. It fits into the AI stack alongside LMS, not replacing them. and Typesafe have

01:34 coined this a system one model. And they’re not the only AI company to do this. Figure Robotics, for example, have their three tiered system where they call their models system zero, system one, and system two. And the idea behind those naming conventions is from Daniel Cayman’s work and particularly well-known book, Thinking Fast and Slow. Ga argues that we have two like modes of

02:05 thinking. We have the slow reasoning and that’s called system two and then we have the faster intuition biases our fast monkey brain intuition. Those are called system one. Jev and we’ll see other models as well draw a imperfect parallel to system one thinking. It is a ultra fast decision making model which in simpler terms we would typically call

02:38 a classification model. So let’s put some shape around Jev. Okay. What are the inputs? What are the outputs that we would get from this system? So Jev is API only and through the API we send questions and state. Those are our inputs. [clears throat] They look like this. So we send our request to post v1 system one define our model but more importantly we have state and questions here. So state you can see in this

03:10 example we are using jev to control a player in the video game Doom. So in this Doom demo, we are getting us a state from our where we are in Doom at that current point in time. What is our health, our ammo count, where are enemies in our view and also where are like key items like a medkit or a particular weapon and all of this is

03:40 coming through this library called vizdoom. Also in the Jev examples where we saw it playing Doom, it’s not looking at the actual video or the images, it’s using this vizdoom library which translates the Doom state into a JSON object describing where everything is. So all that information that we’re getting from Doom goes into our state as you can see here. Health, weapon, ammo, enemies, where things are like the

04:10 medic. Then we have questions and the questions are decided by us or decided by our code based on that state. What are the decisions we need to make? Each decision ties itself to a question. Now you’ll see each one of our questions they have a a different structure, a different purpose. That structure is one of the specific qualities of Jev. Jev allows us to define three different types of objects

04:43 and you can see them here. We have the choice type, we have the score type and we have the null type. Now what do they mean? So here we have action the type is choice defines a fixed set of options categories and Jeff is going to output a probability distribution over that set. Importantly and the thing that distinguishes this specific type is that

05:14 there is no order to these choices and that is different to our next type which is score. score is very similar but there is an order to the different choices. Okay, in this one we have retreat saying we’re actually in reverse we are going backwards then we have whole position neutral we have advance going forwards and charge going forwards faster okay so there is this sliding

05:45 scale and you’re seeing the output here Jev will output a value depending on how many criteria options we provided we go zero to one if we provided just two options Then from one to two if there’s three options, two to three if there are four options and the score output can obviously land between those options which represents the not fully discrete nature of the score type. New is very simple. It’s just a it’s a yes or a no

06:17 but again that can land on a scale. There is zero which is just a straight no. One would be a super confident yes. 0.5 is in the middle. Jeb doesn’t really know whether it’s a yes or a no, right? And then you have the the scale in between those. Now, very importantly, every single one of these choices returns what type they’ve called a calibrated probability. And this is one of the most important things about Jev

06:48 because it is what allows us to use Jev in our in actual code bases and be able to do so confidently. What it means is that when Jev outputs a probability of 0.8, that means Jev will be correct on that particular item roughly 80% of the time. That maybe doesn’t seem like much, but it does give us measurable confidence and a level of interpretability into what these scores genuinely mean. With LMS, they will also

07:18 output probabilities if you ask them to, but those are not necessarily calibrated particularly well. Although recently they are better calibrated as we’ll see, but they’re still generative and they’re actually not as well calibrated as Jeff’s probabilities. And the way that we know this is we can actually look at the model’s reported probability for something. look at how often the model is actually correct on those things. And

07:49 what we should see when the model says it is 60 or 80% confident, we should see it is actually correct 60 or 80% of the time on those specific answers. And we see that in these charts here. Okay. So here we’re calculating the expected calibration error, which is what I just described. the dash line in the middle there. That is the ideal calibration. It’s perfect calibration. And you can see that Jev, that little green line is

08:25 is pretty accurate. And with a GP 5.6 Luna, it is still not bad. It’s not as good as Jeb, but it’s not bad. But what is kind of hidden in these charts is that we’re only really getting values from Luna that were, hey, I’m 95% confident all the time. So it generally Luna is just going through very high confidence scores, which we didn’t

08:56 always see with Jev. Jev when it was wrong, Jev tended to actually say, “Hey, I’m might be wrong here.” Which is very, very powerful when you consider building actual pipelines, workflows, processes with Jev versus an LLM. You can genuinely say, “Hey, my pipeline here is going to be wrong about 80% of the time.” We can’t do that as well with LLMs. And this is really pushing us

09:29 towards filling one of those one of the earliest visions of AI [clears throat] which is combining neural processes I using neuronet networks with symbolic logic like code. What we rarely have here is the ability to build more predictable neurosymbolic systems. And very importantly with Jev we can do this very quickly. we can bring truly fast neurobbased decision- making to our code. In my view, that’s the biggest

10:02 deal with Jev. The model itself isn’t necessarily super impressive in in my view, but that use or that focus of making sure that the probabilities are calibrated so that we actually know roughly how often the model is wrong. that that’s something that’s really been missing from AI and it generally holds us back in how much we can trust and therefore

10:33 integrate AI into production systems. So beyond that Jev as I mentioned is ultra fast that takes us to latency. If you look at this you can see how long it takes Luna to generate some choices. Luna’s, you know, the fastest, one of the faster models uh that we get from OpenAI at the moment. In the time that it takes Luna to generate a single decision, Jev has output between sort of

11:04 12 14 decisions. All right, this is this is server time. This isn’t including network latency, but both of these models suffer the same network latency. So this is roughly the difference you’re going to be looking at. And then to take this further, if we stack many parallel decisions to be made into the same call, right? If there are 10 decisions to make, in this example, there’s only three. If there are 10, Luna is going to take longer to generate more tokens for

11:35 those 10. Jev does everything in parallel. So the the 10 decisions you made are happening in the same amount of time that you see here. So it gets even faster. So that seems pretty impressive, but we can’t use Jev in place of LLMs all the time. Jev is phenomenal at fast decision-m if we can define all potential decisions to be made ahead of time and where we have no need to output natural language. Okay, Jev cannot

12:07 generate tokens like an LLM. It’s a classifier. But in those scenarios where we do just need classification, you can see the benchmarks here. This is Jev versus Luna. Jev for the most part is either matching or surpassing Luna, which is pretty incredible, especially given the latency and and cost difference between them. The only benchmark here that Luna outperformed on

12:38 is a intent classification benchmark for banking the the banking zone 7 one at the top there. The rest Jev’s doing pretty well and particularly on more guardrail focused benchmarks. So prompt injection and toxic check at the bottom there. Jev outperformed Luna pretty significantly. So what we see from this is that Jev has very strong performance for guardrails and also tool selection which are both huge use cases for LMS at

13:10 the moment. So Jev can genuinely you know with some testing and validation replace some parts of both of those guardrails in particular. tool choices a little more nuanced. In cases where our tool choices require generated text, of course, Jev can’t do that. So, we have to stick to an LLM. But not all tool choices need text generation. So, in those cases, we can genuinely use Jev. So, what we see from that is Jev does

13:43 not replace LMS. It is a additional component that we can use alongside LMS, not a replacement. LMS are still the go-to for anything that needs generated text, chat, search, code generation. Yeah, we we still need LMS for that, but Jev can be used elsewhere. It’s also worth noting that Jev even in decision making it is a little limited, right? performance is good, but we can’t scale to very large numbers of decisions to be

14:16 made at once. So, if you’re wanting to do, you know, more than I think the limit is 255 parallel decisions to be made, you you can’t do that. You need to separate those out. And the state of Jev is limited to about 32,000 tokens, and that includes the longest question. So that is something to be aware of. You can’t have very long conversations, for example, going into Jev. [snorts] And it’s also reported that Jev does degrade

14:48 in performance long before you hit that 32,000 token limit. So very large states, not necessarily a good fit for Jev. So overall, very interesting, very impressive results from Jev. But one wrinkle with Jev is that it is closed source and it is proprietary and this is probably one of the more confusing things that type safe went with in in my view you know we’ll get to that Jev is marketed as this big new

15:20 advancement maybe that’s true but we can’t know it’s all closed source or proprietary only details we have are relatively sparse we do know that Jev’s post training process has been coined Edin reinforcement learning for calibrated decisions or RLCD which mirrors the earlier if you remember the reinforcement learning with human feedback which is one of the key components that made chat GBT uh a a possibility and beyond that we also know

15:52 that Jeff is not an auto reggressive model and what I mean by auto reggressive is it’s it’s not generative it’s not like an LLM it’s generating tokens sequentially. Instead, Jev pose probability values directly out of a network. It’s probably still a transformer, but it’s a transformer with a a different head or a different layer fitted onto the end of it versus the auto reggressive layers that we would get out of LMS. There was a very good

16:23 article actually from a guy called Archer Hume called Jeb’s Architecture Mast. I would recommend you can you can take a look at this if you more if you’re interested in trying to understand a little bit more of the architecture behind Jeff. None of this is confirmed but beyond that we don’t really know much and regardless maybe we don’t need to because there are actually plenty of open- source alternatives to Jev which is where I get

16:54 a little more confused about type safe’s approach. You see what Jev does is for the most part reproducible with open source models that already exist even before Jev and even after Jev. There have been many copies of Jev that have been released you know within days. So it’s really not a necessarily hard thing to do with some caveats. But what Jev is is not as hard to

17:24 reproduce and even run locally versus you know something like Fable or GPT6 Opus those are huge models would require a huge amount of training and although we don’t know much about Jev we can see open source models getting pretty close already. So let’s have a look at some of these models. A lot of these are being called either system one models are being called open jevs. There are various names. We have Jev

17:55 released 15th September. Long before this we had the glina models. So glina 2.5 which is the most recent one from Fino AI. I’ve been testing Gler 2.5 and we’ll talk about it in a minute. It does very well and it was released in August and and there were models before then. There was a Gler 2, Glardard, Glide Class, and the original Gliner as well, which was, you know, 2023, I think. They’ve been around for a while. And

18:26 look at the size of these models. So, for the Gl 2.5 models, we’re looking at 74 to 300 million parameters. That’s tiny and very runnable on consumer hardware. Especially this 74 million parameter model. This is actually the model that we use in our test to play Doom. And in many instances, it actually outperformed Jev, right? Which is interesting at at the very least. Gliggard in our tests actually outperformed Jev

18:59 on a few guardrail benchmarks. Very interesting. Again, we’re looking at 300 million parameters there. And then we have these new like copycats of Jev. these, you know, they’re getting a lot of attention online, but honestly, I haven’t seen much necessarily much value in these. They they work well in some areas. They do outperform in some areas, but for the most part, honestly, the Gler models seem to do better. You can see that here. So you know between these

19:31 benchmarks I I showed before we can see okay Gliggard is doing very well on the guardrail focused benchmarks jailbreak and toxic chat doesn’t do so well on prompt injection in that case actually Jev and Leia seem to work better von is pretty close to jev on tool selection and does beat gl 2.5 but overall looking at the glider models so glide 2.5 or glig guard we get either you better performance [snorts] than

20:02 other models or pretty close. And then you look at the model sizes of all these models and the glider models are just smaller and they’re faster. So really, you know, when testing these, I I’ve just found glider to be looking at the open source alternatives seems to be the better option if you’re going to s want those. But of course, you know, you can they’re open source, you can mix and match. There’s nothing wrong with that. So, Gliner is quite interesting. It is a family of models and you you see from

20:34 the name, right? Gler, the original idea was actually named entity recognition and that’s what the original model did and it’s still what Gler 2.5, the most recent model does. It can still do that, but it can do other things as well. So the glider models they do things very differently but the things that they share is that they place labels and input text. So that’s kind of like questions and state into the input of a model. They are all

21:06 birectional encoder models which is a a type of transformer which lacks the auto reggressive head that we see in LMS. Now here you can see the differences between glider and glide 2.5 but looking at the named entity recognition part of it but it doesn’t only support NE right that’s also a big difference between glina and glide 2.5 2.5 can do more by changing the schema that we input in this example

21:38 we’re doing classification and this is how glider 2.5 would do classification in the the same structure as Jev And you can see that this is all defined using these special tokens that you see at the top. We have this P description L set stroke step text whatever else. All of those define what glide 2.5 is needing to be needing to do and the way to do it and the particular output structure to use. So we can see here P defines the

22:10 task name and optionally any instructions around it. It’s the prompt. Okay, P means prompt. So before we were looking at jev and these were called questions. So we had the action advance and switch to shotgun questions. Then we have labels. So these are the the criteria that we saw before for two of the examples. And it’s a yes or no for the null type of Jev. Description here is where we for the criteria with Jev,

22:41 we had a description for each one of our criteria. And this is how we do that here. So description we have to pass in the label right. So you can see in this example we have shoot aim left aim right and then the instructions for that label. And then finally we have set text that separates out our input schema the labels the questions from our state or the input text which follows the set

23:12 text token. And then finally, when we do have multiple questions in parallel, multiple prompts, we do use this septstruct token to separate those out. So here you can see on the left how Jeff’s structure, questions, and state map to Gler 2.5’s structure on the right. Now that takes us to one of the drawbacks of using Gliner or from what I’ve seen any open source model versus Jev. Jev, as I mentioned before, one of

23:44 the key things that makes Jev special is that calibrated probability. You can see here with Glider 2.5, the there isn’t really there’s no no guarantee of calibration here, right? Jev will say, hey, I want the action right now to be shoot and I am 98% confident in that. Glina on the other hand is one not giving us a probability distribution over all of our choices and further it’s

24:14 not calibrated. So a score of 60 0.65 65 here for aim left doesn’t it doesn’t mean that this is correct 65% of the time we lose that calibrated probability that Jev gives us which in all fairness to Jev and type safe is a huge huge reason to use Jev and further you do need to use a different model for the different uh different use cases right you with Jev you can kind of use it for almost anything from the benchmarks that

24:46 we saw whereas the glider models, you need to use glider 2.5, glide guard, whatever else. So, there are some drawbacks, but if you can handle those drawbacks, the latency improvement that you get is phenomenal. The server time, reported server time of Jeff, you’re looking at 88 milliseconds here on average. That’s for one classification for Doom. Looking at Glina 2.5 small, which is is the one

25:19 I actually use for most of my tests and it performed very well. This [snorts] is on a MacBook M4 Pro running it on the GPU. We’re looking at 8 times faster, which is insane. It’s just so so much faster. It’s definitely something that you need to be thinking about when considering which one of these models to actually use. Looking at those times, everything is so much faster than using an LLM. But LM come with some benefits.

25:49 Reason sequentially over tokens because they are auto reggressive. They’re generating these tokens. That means an LLM can use compute to think in a way, right? It’s slow, but an LM can use compute to reason and think and you know explore ideas. these classification models we’re talking about, you know, Jev, Glina, and the others, they can’t do that. They’re not autoaggressive. Yeah, it’s a pro and a con. So, returning to this idea of thinking fast

26:21 and slow from Kimon’s work, our brains operate two systems, system one, system two. Although [clears throat] it’s not a perfect parallel, we can consider adopting a similar strategy, especially when it comes to Doom. What I’ve seen during benchmarking and and testing these is that when we use a fast model alone, so when we use Gal 2.5 or Jev, the model goes more tactical. It’s just like, okay, shoot, point, shoot, point, shoot, point, shoot. It doesn’t tend to think too much about, okay, maybe I

26:52 should go get some weapons. Maybe I should go get some health, whatever else. But when we add an LM, so we had G GPT 5.6 6 Luna to the mix without reasoning. The LM can provide instructions, more strategic instructions to our faster system one model. So we can say, “Hey, go to that room and get the plasma gun. Go to that room, get a mediit, and the system one

27:23 models for the most part will actually go and do it.” So, we’re taking that idea from Cayman of thinking fast and slow and actually applying it to to the Doom demos. And I’ll also flag that it’s not just us doing this. This is actually something that you see in in AI, particularly in robotics. I think probably different robotics companies are doing some level of this. But I know Figure Robotics I think with their Helix 2 model they explicitly described how

27:54 they have system one and system 2. System 2 is their like reasoning LLM taking language instructions. System one is their faster smaller neuronet model for applying those instructions to movement goals or objectives. And then they actually also have a system zero. And then system zero is the it’s almost like the stabilizers for the robot. So it’s kind of like with humans in a in a way. So when we touch something that’s very hot, our body just jumps in and

28:26 forces us to pull that away. We have the reflex to pull away from that. That is how I read their system zero. So we implement system one and two obviously in this example. So when you look at the the maps and these are the maps actually that Jev demoed. There is [clears throat] defender center, defender line and deadly corridor. These are like the twitchy point andoot maps. What we found is that the LM is not really needed in these scenarios. Gler

29:00 and Jev work perfectly fine and adding an LM to coach those models doesn’t make a difference. So there wasn’t much point. The LM was generally not used. It was just idle most of the time. Every now and again it might you know give some input but nothing particularly useful. That changed however with the death map match. On the left we have just gler operating alone and glider is just like shooting point shoot point

29:30 shoot. It’s not you know it’s not doing anything else. On the right, we see Gler with an LM coach, and it will do some things every now and again where it’s like spinning in a circle or something. But what you do see is that the LM is saying, “Go into the side room, get the plasma gun, fight the enemies.” Then when the player ends up low on health, the LM says, “Okay, go and get a

30:01 medkit.” And and Gler does so. and [clears throat] then continues attacking the enemies. So the the score that we actually see from the Gler plus LLM coach system is far far better. Now how does that compared to Jev? This is where the latency difference between using an API and having a local model makes a big difference. When we have Glina everything is run locally and we have that you know 12 milliseconds response

30:32 time. So Gler can just respond much faster to what is happening in the game compared to Jev. And so the Jev paired with LLM is okay, but it doesn’t actually make a big difference. So it’s a small increase in the in the average score with Gler. The score more than doubles as you as you can see, which is is pretty huge. And that’s because of this, right? the the number of decisions that the game gets from Glina is it’s

31:04 8.8 decisions per second. With Jev, because it’s hosted, you we’re getting 2.5 per second. And granted, I’m as far away as possible as I can possibly be while still being on Earth from where Jev is hosted, which is US West. But nonetheless, even if we half the time that Jev takes to respond there when we’re still nowhere near as fast as Gler. So this is where the approach of Jev doesn’t fully make sense to me. I

31:35 think some of the qualities that make Jev very good make it hard for Typescape to capitalize on. Jev as a model has to be fast, which means it’s it needs to generally be smaller, which means open source can probably will probably catch up very quickly to where Jev is. They will probably find a way to bring calibrated probability into Jev because calibrated probability is not necessarily a new thing. It just hasn’t been used in open source as far as I’m

32:05 aware. So in general, I’m not sure how deep type’s moat is with Chev although I think what they’ve done is amazing. One of the reasons I think it’s amazing is becauc is that they’ve taken smaller more specialist models and brought them to everyone and made made everyone aware that we can actually use these and I think that leads us to a less dystopian future with AI because if we just have these huge models and the only way you run these huge models is you’re a big

32:37 company with loads of compute what we get is this future where intelligence is owned by just a few huge companies and the rest of us. We don’t have that, right? We can we can maybe pay those companies for some access to some of their intelligence, but we don’t we don’t own any of it. What Jeb has done has eaten a little bit of that lunch that the current, you

33:08 know, main labs have and they’ve done it with a model that probably most of us will be able to run locally soon enough with a I expect soon to be released open- source alternative that matches Jev in performance and calibrated goodness. But beyond that, Jev, the open source alternatives, they absolutely deserve a place in our agentic workflows, in our AI stacks. I think the

33:38 clearest place to start is guardrails and then beyond that tool selection, considering the nuance of of text generation and beyond there just exploring where we can actually use these new models [music] in AI and the broader software stack. So I think this is all very exciting and an amazing direction for AI to be going into. But that is it for now. [music] I hope this has all been useful, interesting, insightful. So thank you very much for watching and I will see you again in the

34:10 [music] next one. Bye. [music] >> [music]