Tres usos de Claude Fable 5 que perduren més enllà de la promoció
Auditar habilitats, trobar problemes d’arquitectura i planificar funcions complexes: tres usos de Fable 5 amb valor més enllà de l’accés promocional.
Claude Fable 5 no va desaparèixer al cap de cinc dies. El que acabava el 7 de juliol de 2026 era l’accés promocional inclòs en determinats plans de Claude; després, el model continuava disponible mitjançant crèdits d’ús. A partir d’aquesta urgència, el vídeo de Nate B. Jones proposa aprofitar-lo per crear actius que continuïn sent útils quan ja no es faci servir el model cada dia.
Els tres casos que mostra són auditar habilitats reutilitzables, detectar problemes estructurals en projectes existents i preparar l’especificació d’una funció complexa. Són exemples personals, no una comparativa científica entre models, però deixen una idea útil: reservar el model més capaç per entendre el sistema i traslladar-ne la intenció a un pla que altres models puguin executar.
1. Què acabava realment al cap de cinc dies
El punt de partida apareix a 00:00. El creador explica que Fable 5 havia tornat a Claude, però que aviat deixaria d’estar inclòs en el seu pla i passaria a facturació per consum. El vídeo es va enregistrar el 2 de juliol i ell mateix dubta entre el 7 i el 9 com a data límit.
L’anunci d’Anthropic sobre el retorn de Fable 5 concreta la situació: després d’una suspensió temporal, el model es va restablir globalment l’1 de juliol. Fins al 7 de juliol, alguns plans Pro, Max, Team i Enterprise seleccionats podien destinar-hi fins al 50% del límit setmanal; després quedava disponible amb crèdits d’ús.
Per tant, el títol del vídeo dramatitza el final d’una promoció, no la retirada del model. Aquesta distinció importa perquè la recomanació no és “fer-ho tot abans que desaparegui”, sinó aprofitar un període de cost reduït per resoldre treballs d’alt valor.
2. Primer ús: millorar habilitats i processos reutilitzables
A 00:25, Jones comença per les seves habilitats, és a dir, paquets d’instruccions i recursos que reutilitza en tasques habituals. L’exemple és una biblioteca de màrqueting que ajuda a definir canal, posicionament, preu, estructura de la pàgina de destinació i text comercial.
En lloc de demanar una nova pàgina, executa una auditoria oberta de tot el procés. El resultat, que comenta a 03:52, no qüestiona l’esquema general, sinó els enllaços entre fases. Informació treballada al principi —veu de marca, llenguatge del client o criteris de disseny— no sempre arriba a les sortides posteriors.
També detecta que una bona estructura i un bon text no garanteixen un disseny memorable. La proposta és crear adaptadors de lliurament per a cada eina: Claude Design, Figma, Stitch o altres sistemes no necessiten el mateix format ni responen igual al mateix volum de context.
La lliçó és invertir en allò que es farà servir moltes vegades. Una millora petita en una plantilla, una habilitat o un connector es multiplica en totes les tasques futures; una demostració improvisada només produeix un resultat puntual.
3. Com auditar sense acceptar cegament el resultat
El vídeo atribueix a Fable una capacitat superior per preservar la intenció entre molts detalls. És una apreciació del creador basada en els seus projectes. No hi ha metodologia, conjunt de proves ni revisió independent que permeti convertir-la en un rànquing general davant d’Opus.
La part transferible és el mètode. A 01:38, l’auditoria comença amb un objectiu obert, però el sistema demana context addicional abans de proposar canvis. Després, el creador revisa si el diagnòstic concorda amb el funcionament real i separa planificació d’implementació.
Aquesta supervisió és necessària. La recerca d’Anthropic sobre l’ús de Claude Code i l’expertesa humana associa els millors resultats amb coneixement del domini i capacitat per dirigir i validar el treball. Un informe convincent no substitueix proves, documentació ni revisió del codi.
4. Segon ús: buscar l’arrel d’un problema recurrent
El segon cas arrenca a 07:51. En una aplicació mòbil, Jones havia afegit un bucle d’agent propi i acumulava correccions: l’assistent oblidava informació, emprava malament les eines o no reprenia correctament una acció després que l’usuari respongués.
En lloc de corregir un altre símptoma, demana una revisió de nivell superior. El model llegeix el projecte, reconstrueix el flux i contrasta pràctiques del domini. A 12:22 formula el diagnòstic central: el bucle del servidor és sense estat, però la conversa no ho és.
La interfície del client mantenia massa responsabilitat d’orquestració. Quan el procés s’interrompia per demanar una aclariment, el servidor no conservava prou context per continuar exactament on s’havia aturat. Les correccions locals podien alleujar cada error sense resoldre aquesta asimetria.
Jones reconeix que havia delegat massa i que probablement haurà d’eliminar una part del treball. És una observació més valuosa que qualsevol victòria de model: quan l’arquitectura és incorrecta, continuar afegint pedaços fa créixer el cost de rectificar-la.
5. Del diagnòstic a una especificació executable
A 14:04, la solució proposada és un sistema de punts de control que persisteixi l’estat al servidor. Si l’agent s’atura esperant l’usuari, la resposta posterior ha de reprendre la mateixa execució amb els passos i el context previs, no iniciar una operació desconnectada.
El creador no encarrega immediatament tota la reescriptura. Primer demana una especificació que conservi l’objectiu, les decisions crítiques i el perquè de cadascuna. A 15:00 explica que un model menys costós pot implementar el pla després.
Aquest repartiment és una política de costos raonable: utilitzar més capacitat en arquitectura, ambigüitats i riscos, i eines més barates en canvis ben delimitats. Ara bé, l’especificació encara necessita criteris d’acceptació, proves de represa, control de concurrència i verificació de les migracions. El model que planifica no converteix automàticament la implementació en segura.
6. Tercer ús: investigar una funció amb moltes dependències
L’últim exemple, des de 16:10, és planificar la transmissió de tokens i esdeveniments del servidor a la interfície. L’aplicació ha de mostrar text a mesura que es genera i representar crides d’eines o fites internes sense perdre coherència amb l’estat persistent.
Jones dona al model el codi, la finalitat de la funció i el context acumulat, i li demana recerca i planificació. Després executa el mateix encàrrec amb Opus i fa revisar-ne la proposta. Segons la seva anàlisi a 20:13, el segon pla reintroduïa errors ja corregits, invertia el tractament de les interrupcions i contenia afirmacions incorrectes sobre Supabase.
La comparació és informativa sobre aquest projecte, però no controla diferències d’historial, configuració ni variabilitat entre execucions. La conclusió prudent és una altra: abans d’implementar una funció transversal, convé confrontar el pla amb l’arquitectura real, la documentació oficial i els errors ja resolts. Un segon model pot servir de revisor, però no de prova definitiva.
Conclusions
Els tres usos formen un mateix embut. Primer es milloren els actius reutilitzables; després s’audita l’arquitectura per trobar causes estructurals; finalment es converteix una funció amb moltes dependències en una especificació que es pugui implementar i provar.
El valor no depèn que Fable 5 continuï inclòs en una tarifa. Depèn de deixar enrere millors instruccions, decisions documentades i plans que segueixin sent útils amb altres eines. L’anunci original de Claude Fable 5 i Mythos 5 descriu les capacitats del model, però cap fitxa substitueix l’avaluació sobre el projecte concret.
La pauta més sòlida del vídeo és dedicar el model més potent als punts on una decisió equivocada es propaga: interfícies entre processos, estat del sistema i arquitectura. I mantenir sempre una persona capaç de verificar fonts, qüestionar el diagnòstic i decidir què s’ha d’implementar.
Contrast i context
Fonts consultades
- 01
-
02
Anthropic Redeploying Claude Fable 5
- 03
- 04
Font de treball
Transcripció amb marques de temps
Consulta la transcripció
-
0:00
, obre el vídeo en una pestanya nova
So, Fable 5 is officially back in the wild, but realistically it's only going to be around for a few more days until it's no longer available in your Max plan and you have to like pay for the extra credits. And so I think there's really two things that you can do in this situation. Number one is that you can just do a bunch of random shit and try to like one shot designs on throwaway projects or number two, you can do the three things that I'm about to show you in this video. And so the first thing up on this list is improving our skills. So, Fable 5 is really great at understanding context and intent. It is significantly better than Opus 4.8 at that. And so we should be using this unstoppable power that was so powerful that U.S. government had to tell people they couldn't use it. We want to use that in order to improve the things that outside of the context of having access to Fable, we will still want to use on a daily basis. How can we use this to improve the things that are our daily drivers? And so what we'll go through as an example here is my go-to market skill library, which shameless plug you get if you're inside of my paid community, link in the description below. But inside of this we have like a few different skills that help you pick out like you're going to market strategy. So what's the actual channel strategy? How are you going to position yourself against other options? How are you going to determine your pricing? Decide the structure if you're landing page, like write the copy for the landing page, all of those types of things. And I want to make sure, obviously, since I give this skill to people, that it says dialed in as it can be. And so this is a good example of where we can run this type of audit. So we can pop into our command line here. Now, if you want to know how to use Fable, It doesn't show up by default in the drop-down, so you can just type slash model
-
1:47
, obre el vídeo en una pestanya nova
fable, and that will set fable to the active model. And so I'm going to run this skill audit skill, which is just a custom skill that I created to audit other skills very meta. And in this case, I'm just giving like a very generic open-ended prompt where I want it to look for general areas of improvement, particularly in the context of like this skill library, where it comes to copywriting and like landing pages, because this is something that I think a lot of of people rely on to be done well, especially if you don't have a background in marketing. I've codified this thing with all of my experiences having run like successful marketing agencies before and building and selling apps. And so I wanted to make sure that it's like really dialed in and that it's successfully translating those like resources and rules that I've created so that they're actually being enforced properly by the skill. And then I just want to make sure that there's no other areas inside of the other skills that feed into this one that are potentially causing issues. So we just want to make sure this thing is super dialed in. Now you can apply the same approach to pretty much anything. Last time, Fable was accessible to us. I used this to dial in my actual like development skills. So I have like a custom plugin that I use personally that combines spectra development and the best of all of the libraries I use. So compound engineering, over superpowers, all of those different skill libraries that we all know and love. I've taken what I like from all of them and combined them into like one system that works for me. And I used Fable to help me do that and help dial it in and make sure all the pieces were connecting properly, making modifications to those skills where I need it to. That's like a really strong use case that you can run to. And so the way that I've configured this skill, It's going to go through and try to like ground itself in in context. So it's asking me a lot of questions about like what specifically I want audited.
-
3:41
, obre el vídeo en una pestanya nova
And so in this case, I've gone through and I've answered all of these questions based on like what I think could be improved from the skill because there's always room for improvement. And now we're kicking it off and letting it letting it go. All right guys. So this thing is done now and we can kind of walk through what its findings were. So in this case, it says that the actual like process of how this actually moves through and like the different pieces that we have are genuinely strong. And so, I mean, this makes sense. I use this or like codified this based on like real world processes and used opus to build these things. But the issue comes in with like these little details. And I think that's something that fables actually really good with. It can understand the larger picture. But it can really audit like these smaller seemingly smaller like edge cases where important details would otherwise slip through the cracks. In this example, We have a lot of these inputs that we take time to build, like the brand voice and customer language and design specifics, and they aren't being properly translated downstream to other phases. And so that's one big piece. And the second piece is that part of what the skill is is meant to be able to do it will tell you like the sections that your page should have in order to be like a high converting, you know, SaaS or mobile app landing page. But what it doesn't necessarily do well is translate into something that like you could just pass this as a Spectaclode code and it will like build you something that's like genuinely memorable from as like a landing page and so it can produce copy really well But there's nothing that's like pushing it into this like wow factor state and so in this case It's found a few different issues that could be rather like driving that number one is again these seams that we talked about where like details that we've decided aren't making their way through. A second thing, which I think is a really valuable convention. I do this with other skills that I have for building, especially when I'm working with cloud design, is building like hand-off systems. So if you were to think of tools like cloud design versus you know other tools like Google stitch or Figma or pencil.dev or whatever,
-
5:48
, obre el vídeo en una pestanya nova
they all have like different ways of prompting them that work better. And so having little adapters that can take a plan and convert it into whatever tool you want to work with is super valuable. And so one of the failure modes I think in this case is that I'm pasting in like a ton of context to claw design and it's not what it needs. Like it needs that adapter step so that we can format everything in the way that it needs to be for design tools specifically to be able to work with it. And so again, the reason this is better than something like opus is that I've already run this audit several times with opus and every time we make a skill, it's attempting to optimize this piece, right, like, is the process strong, but it's not going to the level of looking at like all of these, like seemingly smaller individual things that can force this deviation from what you as a user, are like actually most likely wanted. So if we were to think of this concept of like a motivational intent or like a goal, it's a lot better at seeing the goal through the details of things and taking those things through to completion. So this is pretty awesome audit that we've done again. In this context, I would apply this same exact thing to like any dev tooling that you use or really any sort of skills that you like to use on a regular basis that you're thinking like, Sometimes it's good, sometimes it's not, but it's never wowing me. This type of workflow is going to be super, super, super valuable for you. And so now we have a very concrete plan. And the nice thing is that we don't necessarily need fault implementus. We could implement it in subagents with opus, have fabled be the orchestrator. Like a sky is the limit type of situation. So for me, skills are like a daily driver. It's what I use probably the most.
-
7:35
, obre el vídeo en una pestanya nova
I often will create like my own versions based on things I found in like open source that I want dialed in for me. And so taking the time to like audit those things and make them super locked in is I think one of the most valuable things you could possibly do with your time. But what about the features that we would actually build with these types of skills? So if you're not a trained engineer by background, but I mean, shit, even if you are using these tools to audit through things that you have already built is an incredibly valuable thing to do. So in this project, we have something that has been driving me a little bit crazy. This is the design for this, this mobile that I've been working on. And what happened was I started adding in these agent loops. So when I built the first iteration of this thing It made a few language model calls, but it wasn't anything crazy. And then I started adding in and building my own agent loop and that is where the bugs started. And so I've been working through this trying to fix the thing, but I want to make sure that It is 100% dialed in because we're getting ready to take this thing to market and so I need to, you know, So rubber needs to meet the road and we need to make sure this thing is actually bullet proof. And so good at time as any to test out how fabel can audit what we have built. And so again, we're going to come down into our project and we're going to run this, again, custom command that I have called zoom out and think. And so I use this type of skill when I'm in a situation where we're just running into the same issues over and over and over and over again. And it seems like we're just, we're too much in the nuance and the system needs to be able to look at things from a higher level and really try to understand like what is the root cause of this at like the system level. So instead of looking at a specific bug and just constantly trying to patch it and then other bugs pop out like based on what I am trying to do with this project, what are the core issues that we need to actually think through and resolve. And so we have Fable 5 going out and running this zoom out and think command. Okay, so this thing is now finished running through. So it basically read through everything in the project and then it did a web search to find like what are the modern best practices for like this specific domain, which in this case is like constructing your own like agent loop like a React loop here. And so we can read through them and see like what exactly did it find?
-
9:54
, obre el vídeo en una pestanya nova
And I'll talk a little bit about like where I think this is a lot different from the type of analysis you would get with a tool like Opus. So how the system actually works. So it has gone through now and broken down like precisely how the the system itself functions. We don't need to read through this entire thing. It's specific to this project. But we have this homegrown React loop that we run. And so it can go through. It can accept the message from the user. It has a bunch of tools that it can use. And the fundamental thing here that I think is the core issue is that the state of things, right? So we're having this conversation from like our app in this case back to the server. The the state of the thing is only living really on the client side. And that's going to be a big problem. And this is something that like Opus entirely missed. So I've gone through so many of these debugging exercises, running this exact same command with a tool like Opus. And again, it's always finding these like duct tape bandaid type of solutions. And that's why we have so many commits because like every time we patch something, we're just patching that thing. And then the next time you run into an issue, it's like, okay, well, now I need to patch whatever that thing is to because I'm not solving for what the underlying problem actually is. So it's grounding itself in how the system actually works. And then it's moving to like, what is the real ask that we have of this? And so in this case, if we were to read through this, I want the agent to feel coherent across the conversation. It needs to be able to like log meals for people, do planning properly, clarify ambiguous asks or food items, commit those changes, allow users to correct them. And we need to do this in a way where every single time we want to handle one of these things. We're not just patching, patching, patching, patching, patching, patching, our way through the entire thing, just making all of these individual fixes that are not fixing the actual core underlying problem. And again, this is something that Opus has failed to diagnose, even with me pointing it to the fact that I think the loop is the problem.
-
12:01
, obre el vídeo en una pestanya nova
I've kicked off many chats with Opus saying, hey, I think that this loop that we have is fundamentally what the issue is. it's not using tools correctly. It's not remembering what a person said. It's not kicking off things in response to like a user's reply properly. Like it's not doing any of that and it needs to be. And it kind of failed to find these types of issues. And so the core thing here is that the loop on the server side is stateless. Like it doesn't know what happened before, but the conversation isn't. And that is like fundamentally what the issue is now inside of this project. And so it has basically broken down for us, like the specifics of that. And so one last thing, again, is that what is the difference between something like this and Opus? We like came to a lot of these conclusions already in research that was being done. So when I was using Opus, kicking off all these like sprawling research agents to try to figure out like what could be the cause, we came to conclusions about like the interrupt pattern and how users need to be able to interact with the system. Like we decided some of those things, but opus, or I mean, can't blame everything on the model, the human driving the process with opus, like not all of the patterns that needed to be there were actually implemented. Now, if you're a user that just lets a lot of things go hands off,
-
13:21
, obre el vídeo en una pestanya nova
which if we're being honest, a lot of people do that, these are the types of issues you can run into, right? When you're doing things that are like are a little bit more basic, I think, you tend not to either notice them or the things are a lot more straightforward, and so they don't really rear their head, and it doesn't become a problem. But if you're starting to get into like, I don't know, like, agent patterns and like building things that are kind of complicated, this is why you need to like slow down when you're doing spec processes and like make sure all of the bases are actually covered. And so we're gonna summarize all that down, like what is kind of like the needle in the haystack, thing that it found in again that something that fables really good at, what is that like that really seemingly obscure, but actually really important to the system working type of thing. We need to have a check pointer that persists the state on the server. So when it's interrupted and it needs a response from the user, that it remembers everything that's happened so far. And then the user, replying, is just like continuing the execution and it actually has the full context of what has happened before. And so fundamentally, we have this issue where we're actually relying
-
14:27
, obre el vídeo en una pestanya nova
on the client side to do too much of the orchestration of things. right like the client should just be responsible for rendering things ultimately and it's doing too much of the orchestration which it shouldn't be doing and so this is obviously a situation where like we need to make some sort of like meaningful update to how this works so that it's like actually a proper agent loop and so in this case this is a situation where I would use fable to like actually build my specs and that is exactly what I'm going to do and so I'm going to come down here and I'm going to tell it use open spec propose to create new specs to fix one, two, three. The implementation will take place with a lesser model like Opus, so make sure the plan carries forward, motivational intent, and all critical details of what needs to be implemented and why. So again, wrapping all this up, I think Fable is really good at auditing things, you know, in the case of my project, I was trying to build a loop in a way where honestly, like I probably wasn't in the loop. As much as I should have been, and this thing has gone a little bit sideways, and it's not so far down the road that it's not reversible. It's just we're going to have to delete a lot of work that we already did. But at least now, we know precisely what the problem is, and it's very clear to me, reading this that the system understands what the problem is. And so now again, And we're kicking off proposals and we'll be able to like systematically work through this thing and build it even if we're not using Fable right even we're using something like like opus to actually do the implementation We're gonna rely on Fable to actually build that plan out. So this is all well and good But what about if we want to build like net new things? Especially again like in a system like this where there's a lot of different pieces and we want to make sure it all integrates Propelete together. So the last thing that I really love using Fable for or whether it's in the context of like building features, even for knowledge work, I think a lot of people when Fable first came out said it wasn't good at knowledge work. I think that's complete bullshit. I think it's really good at it.
-
16:32
, obre el vídeo en una pestanya nova
But either way, it's very good at taking in a lot of different contexts from different places. This could be like year background knowledge on something, what you want to accomplish, notes you've taken on something in the past, your ideas for a feature, whatever it is, it's really good at taking that understanding the goal and the intent behind it and then going out, doing a bunch of other research and like properly marrying those two things together. And so that is what we're gonna kick off here. So like this entire process of like doing research, exploring an idea, ideating around it, executing through like the full lifecycle, it's really good at doing that compared with, again, tools like Opus. And so if I were gonna do something like this again, with a tool like Opus or even like Chachit BT5, you would have to go through and really break this thing down into like a ton of different parts, even from like the research and exploration phase, you would need to research all of those things individually and then attempt to like bring them back together and back into like a little bit of an arduous process. And so we're gonna see how well, I hope it's, or sorry, we're gonna see how well,
-
17:38
, obre el vídeo en una pestanya nova
fabel can do that just like kind of vanilla out of the box. And so just so you guys know like exactly what we're like trying to plan through in this one, we're now like in that like first thing that we went through with the feature brainstorming, we're trying to resolve how all of this stuff actually functions on the server side, like on the backend, but we needed then to be able to like specifically stream these events through to the front end as they're happening, so that we can even like surface this type of stuff, right? So like the UI that we're building needs to be like tightly coupled to what the backend can actually surface for us. So that all of this stuff like can actually render in a smart way. And so this is basically the UI that this streaming is going to allow us to enable. And that is why we are working on it. This is one of the last things we need to dial in before the app can actually get launched. So just to put pictures to what I say, when I'm saying like streaming the events back and like streaming the tokens, streaming the tokens means that like this is going to type out as it appears, right? So it's not just gonna pop up in one block.
-
18:39
, obre el vídeo en una pestanya nova
It's gonna actually stream the tokens to us. And then we need to also like stream the events that are happening on the server. So when tools are being called, when it's hitting like important markers and things are happening, we want to be able to send that to the back to the front end as well. All right, guys, so this thing fully finished through and it planned out the entire system. There's like a lot of really nice research, like finding out like what are the potential, like, caveats, like what's actually the real grounded state of things and all of that. But one thing that I wanted to do is try to think through, like, where is this actually different from what you would get out of a tool, like, like, opus? And so I went through and I actually kicked off the same exact. And the only difference was I said, you can't go look at past chats. I didn't want to read that and come up with the solution. And then I gave it the same exact prompt. Okay, I gave it the same exact, same exact prompt. It went through, it came up with, you know, all of the things that we would probably go through and start implementing on. Unless we were really spending time to challenge through. And so what I did was I moved through that. And then I had a fabel look through it and tell me, like, based on what we just came to the conclusion about, What did that other chat get wrong? And again, they had the same exact context and the same exact command to kick this thing off. Again, the only difference is that in one, I said, like, hey, you can't read other chats.
-
19:56
, obre el vídeo en una pestanya nova
What is actually the difference? And this is important because it's going to give us a sense of, like, where fable is super valuable and give you an understanding of based on, like, the apps you have now. And you want to really make use of this, like, now, while you still can. What are the types of, like, heavy problems you should be putting it on? So I had a categorized into things that are dangerously wrong, like they would really drive a bad implementation. And so the first thing is that Opus was about to just like reintroduce a new class of bugs that we had already fixed. And so based on like the the way that like events are going to get emitted and like shown to us in the front end, it was completely wrong about how to actually do that. And so this is where we get into those things. like you're constantly running into the same errors and like a slightly different form. This is like the type of thing where that would happen. We're just relying on OPEC we think it's smart, it goes out and it's just doing the same things over and over again in slightly different ways and just reintroducing bugs. That's part of the reason why Fable's really great because it can think through these things in like a way that's pretty impressive I think. So it found a few of these things another one that was pretty big is the way that it's planning to do it is simply going to break. And so in this case, what happens when a user actually interrupts things or it pauses? What actually happens in terms of the agent responses and things like that? It was going to implement this thing completely backwards. It also had some things that were just factually incorrect about what Superbase was actually capable of or not capable of doing. Now something like this, the things in this category. I think these are things where you could obviously go through and point it at like tools like context 7 or forcing it to go out and look at documentation and things like that. But again, this is something that I've been able to just do on its own without that extra direction because it knows that it really needs to resolve this thing. So the I think the way that it plans and executes on things that are important to the goal is really good.
-
22:01
, obre el vídeo en una pestanya nova
And so a few other things that could found some structural issues with what it was going to be implementing and like what it thought was like the core of the thing and the most authoritative piece of the system that needed to be done well and it didn't actually handle that properly. So again, we would have structural issues if we moved through just implemented blindly with what it was outputting for us. And then there's some smaller things where like it didn't actually explore other relevant pieces of the code base. So all in all, Fable 5 when it comes to like, I would categorize this as like more complex brainstorming, like trying to implement a server side streaming in the context of our app from scratch. Fable was significantly better at doing this and I'm gonna actually move through after this video's over and implement all of this. So all in all, we're only gonna have this for a few more days. I'm recording this on July 2nd and this is only gonna be available to July 7th. Though I thought I saw in my UI somewhere it was gonna be till July 9th. So I could be wrong about that. And so again, after this is over, it's gonna go to like a usage-based thing and this model is super expensive. So I don't think it's gonna be reasonable
-
23:07
, obre el vídeo en una pestanya nova
for the majority of people to use this on usage credits. So I highly recommend you go through and think about either like one or all three of these things that I've gone through in this video. So like improving our skills, auditing, existing features that we already have in place that we need to make like more robust and better or using this to brainstorm some of those more ambitious features that seemed like they were going to be a little bit too complicated for you to maybe do and seeing if Fable can help you bridge that gap. Now if you want help with any of this type of stuff, like I said earlier I do have a paid community that is growing and there's a bunch of like custom skills and plugins and people are actually building awesome stuff in there and getting paid for them which is nice. So if you like this video and you don't subscribe yet make sure to subscribe but that is it for this one, I will see you in the next video.