Original video in Chinese.
What you’re seeing now is Codex playing the card game Slay the Spire. It makes strategy decisions based on the enemies, our hand, and the basic rules of the game, then plays its cards.
But the hardest part of this is not actually teaching AI to play cards; it’s designing a decision system that’s reliable enough to make the right judgment, and to verify that judgment.
I discussed, iterated, and optimized with Codex along the way, spending most of the day on it, and finally got it to complete battles relatively smoothly.
You see, at the beginning, Codex was reading game data by recognizing screenshots, but that was very slow. Later I changed it to only capture key areas like the hand, but it still wasn’t fast enough.
Then I suddenly thought there should be a Mod that could read the game data directly. I had Codex search for it, and sure enough, there was one. It’s called CommunicationMod, and it can send the game state to an external program in JSON form, and also receive action instructions from an external program. That made the speed much better.
So now the workflow is:
Read state → local program calculates a card-playing plan → model makes a choice if necessary → execute action → read new state and verify.
Honestly, this is pretty interesting; it even gives me more of a sense of accomplishment than playing the game myself.
I even started thinking that maybe there will be “AI game streamers” in the future: not playing themselves, but teaching AI to play and watching AI play, like training a Pokémon.
The reason I wanted AI to play games is that a very popular model called Jev came out recently.
It’s not a general-purpose model like the traditional GPT or Claude. Its design goal is not to generate articles or code, but to do one kind of thing specifically:
Given the information you provide, it gives judgments that programs can use directly. For example, making choices, scoring, or determining yes/no.
Seeing this, you’re definitely going to ask: can’t models like GPT already make choices? Why build a new model just for this?
Of course GPT can. But the problem is that, compared with a model specialized for judgment, they’re usually larger, more expensive, and slower to respond. For tasks with a clear scope, relatively simple judgments, and frequent calls, asking a large model to answer every time just isn’t cost-effective in terms of expense and latency.
So a more reasonable approach is: predefine the options, let Jev choose and give a confidence level, and call a large model again when content generation is needed.
You see, last year when I introduced the n8n model selector in the Knowledge Planet, I had a similar idea: use a faster, cheaper model to make judgments. For simple requests, output 1; for complex ones, output 2; then follow different branches based on the result and call different models.
Because the conditions weren’t mature enough before, these ideas were never implemented very well. Now that there’s Jev, this path is much easier to make work.
To verify its effectiveness, I chose Slay the Spire.
One reason is that its controls aren’t complicated, unlike real-time strategy games that require extremely high APM; another is that it requires strategy and constant choices, which makes it a perfect test for Jev.
Using Jev isn’t complicated either. After installing the Skill provided by TypeSafe and configuring the API Key, Codex can call Jev successfully.
But simply integrating the model is still far from enough. The real difficulty is system design. This is also why I strongly dislike some self-media accounts mindlessly hyping Jev. Just to have Codex play Slay the Spire, if you want to do the whole thing properly, the system has to consider at least six parts.
First, state reading. Figure out what cards you have now, how much energy is left, and what the status is on both sides.
Second, rules calculation. Calculate damage, block, and trigger order.
Third, plan generation. Put together the possible actions for this turn, and cover different conditional branches.
Fourth, strategy judgment. You need to compare immediate gains with future costs, as well as the deck build itself.
Fifth, execution control. Execute the actions that have already been decided; once new information appears, stop and recalculate.
Sixth, logging and evaluation. After something goes wrong, you need to know exactly where it went wrong, and then measure the gain and the cost.
In such a huge system, Jev only handles the judgment steps where there is a real tradeoff.
For example, drinking a potion can let you kill the opponent faster and lose less health, but that potion may be more important for the next boss fight.
Codex wrote a locally running program responsible for reading the game state, generating candidate plans, and calculating the results. This program passes the relevant background, candidate plans, and the consequences that can be calculated to Jev, and then Jev helps make the tradeoff.
So you see, Jev is not an all-purpose model. It’s not that once you integrate it, the whole system suddenly becomes much better. How much value it can actually deliver depends on where you place it and how the entire system is designed.
So, in this project of having Codex play Slay the Spire, how did Jev actually perform?
I had Codex disable the local scoring and fallback mechanisms. The program continued to provide candidate plans and computed results, and then among those candidate plans, Jev decided which one to use.
The next fight happened to be an elite battle. The plan Jev helped Codex choose ultimately got through in four turns.
This test at least shows that this route is feasible: Jev can participate in this kind of structured plan selection.
However, its judgment was not perfect. On the third turn, it clearly could have played one more card, but Jev kept the energy and directly chose to end the turn.
So I would still use a “double insurance” approach, meaning using both the local scoring program and Jev. The advantage of doing this is: if the situation is very simple, it can just execute directly without calling Jev; and if Jev’s request fails, there is still a fallback.
What really interested me about this experiment wasn’t how strong Jev is, but rather that it made me see more clearly that:
A model is just one part in a system.
Whether a model can actually work depends on what project you use it for, where you place it, and how the whole system is designed. That’s my conclusion about Jev.
The same old point: in the AI era, what’s truly worth mastering is the ability to design systems, call models, and keep the initiative in your own hands.
OK, that’s all for this episode. If you want to learn about AI, want to take back individual sovereignty, and want to find like-minded people, come join the newtype community. See you next time!