1.18 Billion Tokens in Two Days: Recreating CS:GO with ChatGPT-Astra

An Extreme AI Programming Experiment

Bilibili creator Bai Ya did something that sparked considerable discussion: using ChatGPT's Astra model, he consumed 1.18 billion tokens over two days in an attempt to recreate a playable CS:GO (Counter-Strike: Global Offensive) demo in Unity, naming the project "Dust0."

This wasn't a simple AI code demo — it was a complete engineering exercise in taking an idea all the way to a playable program. It exposed both the capability limits and the real costs of AI-assisted programming, and both dimensions deserve a closer look.

1.18 Billion Tokens — Where Did They All Go?

Let's start with the bill. According to Bai Ya's independent stats, the project consumed 1.18 billion tokens and 8,695 requests over two days. That number sounds staggering, but breaking down the structure tells a more nuanced story:

• Approximately 1.034 billion were cache hits
• 141 million were new input tokens
• Output totaled only around 5.5 million

In other words, the vast majority of tokens weren't genuinely "new computation" — they were repeated reuse of the same context. In long-duration, multi-iteration coding tasks, the model constantly carries previous code state, requirement constraints, and known issues, so a high cache hit rate is inevitable. This is a reminder: looking at total token count alone can be alarming, but the real incremental cost is far less dramatic than 1.18 billion suggests.

Cache hit is a billing optimization mechanism in large language model APIs. When multiple requests carry identical prefix content (such as fixed system prompts or already-generated code context), the provider reuses the KV cache for that portion instead of recomputing it from scratch — typically billing at 1/4 or less of the standard input token rate. In long-running coding projects, each conversation turn requires passing in the current codebase state, requirement descriptions, and historical issues, making that "prefix" highly repetitive and naturally driving cache hit rates up. Both OpenAI's Prompt Caching and Anthropic's Prompt Caching use similar mechanisms. When evaluating the actual cost of experiments like this, it's important to distinguish between "total token consumption" and "actually billed tokens" — the gap between the two can be several times over.

What Actually Got Built

Dust0 is no longer a static demo — it's a coherent, runnable game flow. Based on Bai Ya's recorded footage, players can enter the Dust2 map and perform actions including buying weapons, switching guns, navigating the map, throwing and waiting for smoke grenades to form cover, and reloading. Rifles and sniper rifles each have independent interaction feedback — scoping in, firing, and smoke grenades going from throw to full obstruction all have corresponding behaviors.

More importantly, the purchased gear actually affects how each round plays out. Movement, weapon actions, and utility effects all need to work together in the same runtime — not as isolated demonstrations. The project also integrates an offline bot bomb-defusal mode, complete with a purchase economy system and round settlement. In the recorded footage, you can see teammate behavior, kill feedback, and win/loss notifications. The various phases of a game round have genuinely begun to connect.

Harder Than Graphics: Rule Consistency

The most technically demanding part of this project isn't the visuals — it's keeping the underlying rules unified.

According to Bai Ya, the project places combat logic in a shared core logic layer, allowing offline mode, client-side prediction, and the online server to all operate around the same ruleset. Core mechanics like shooting, damage, ammo, and rounds cannot each "do their own calculation" — otherwise the online mode would suffer the classic problem of prediction mismatches with the server.

This is precisely the hardest problem to crack in FPS game development. The most concentrated fixes in the development log were around details like: zoom sensitivity during reloading, weapon stance when jumping, alpha channel handling on transparent surfaces, smoke grenade lifecycle, and native runtime checks. Even after the AI generates code, there are still round after round of visible bugs to fix — and that workload is no smaller than the generation work itself.

Client-side prediction is a core networking technique in multiplayer FPS games, used to counteract the stuttering caused by network latency. The principle: the client doesn't wait for server confirmation and instead immediately executes player input locally (such as movement or shooting), delivering instant feedback. The server then performs authoritative calculation on the same input, and if the result differs from the client's prediction, it forces a rollback and correction. This mechanism requires the client and server to run completely identical game logic — any subtle discrepancy leads to frequent "rubber-banding" corrections that severely damage the feel of play. The CS series' network model has been known for precise hit detection and low-latency response since CS 1.6, which is why rule consistency is far harder to recreate in a project like this than visual fidelity.

An Essential Caveat: Original Assets

This achievement requires an honest footnote. As Bai Ya himself clearly stated, the map, characters, weapons, models, and animations all use original game assets.

This means the value of the experiment lies in rewiring existing assets, game rules, and a runtime environment together and getting them to run — not in creating visual content from scratch. Bai Ya himself emphasized that these ready-made art assets can't be counted as "conjured by the model." There's still a gap between this and the full original experience — smoke lighting, complete character animations, and some engine behaviors are still being calibrated.

This honesty actually makes the experiment more valuable as a reference: it clearly defines the boundary between what AI can and cannot do.

The Human-AI Division of Labor: Who Sets the Direction, Who Does the Work

Throughout the process, Astra handled a large volume of implementation and iterative revision work — but the steering wheel remained in human hands. In Bai Ya's own words: you still need a person to set goals, review results, and ask the right questions.

This may be the most memorable takeaway from the entire experiment. AI has compressed the "execution cost" of programming to near zero — a single person can drive a prototype in two days that would otherwise require a team over a longer cycle. But goal-setting, result verification, and problem identification — the steps that require judgment — remain the core value that humans bring.

Were 1.18 billion tokens worth it? The answer isn't in the number itself, but in the final real-world experience: feel, stability, and fidelity — those are the next exam that Dust0 faces. For the industry as a whole, this experiment offers a concrete data point: the ceiling for AI-assisted development is rising fast, but the "last mile" of polish still can't be done without people.

The "Astra model" Bai Ya used refers to the Project Astra capabilities integrated into ChatGPT — one of the directions that both Google DeepMind and OpenAI are exploring in the realm of multimodal real-time interaction. In this context, it more likely refers to a specific OpenAI API model (such as GPT-4o or the o-series). Given the token consumption structure and the multi-round code iteration task characteristics, this type of long-context programming workflow demands extremely high model capability for code comprehension and incremental modification — a scenario that major model providers are actively optimizing for. Positioning AI as a "high-speed execution layer" while humans retain "goal-setting and result verification" has already become a viable path for many independent developers and small teams looking to lower the barrier to prototype development.