GLM-5.3 is live. Run Z.ai's latest model on Friendli Model APIs. Try it today ➜
khursheed
Available on FriendliAI
Run this model inference on single tenant GPU with unmatched speed and reliability at scale.
Model Details
Model Provider
khursheed
Model Tree
Qwen/Qwen2.5-Coder-7B-Instruct
Input Modalities
Output Modalities
Supported Functionality
“Prompt → playable game in 60 seconds” is the target. The measurements below show where this release lands.
Watch the 60-second walkthrough. Sixty seconds is the edited video's duration, not a generation-speed claim. This video is a success-only showcase: exactly the first three clean results in frozen prompt order. It is not representative of the model. All three recordings use untouched outputs, and the full 500-prompt results and actual times stay visible. The original benchmark sample slots 0, 200, and 400 remain unchanged in the evidence. Gameplay recordings use fixed timesteps without player input, so they cannot prove responsive controls or real-time generation speed.
Install Godot 4.5.1 and Ollama. Download the Q4_K_M file and Modelfile from the GGUF repository, then use the project source:
sh
# Point FROM in Modelfile at the downloaded GGUF.ollama create vibegame -f Modelfilepython scripts/generate.py --backend ollama --model vibegame \ --prompt "Make a tiny game where I catch falling stars and avoid meteors" \ --output my-game.jsonpython scripts/extract_project.py my-game.json --output my-gameThe generation command writes JSON with a files mapping. The extractor checks that format and writes into an empty project directory. Inspect the scripts, open project.godot in Godot, and press Play. Extraction alone does not check compilation; the included Linux validation harness tests import and runtime behavior in isolation.
LoRA adapter · Merged FP16 weights · Training data
The Codex assistant authored 100 distinct complete-project candidates during this build, plus nine earlier seeds, with original game logic and geometric visuals. Linux admission accepted 108 of 109, producing 97 training examples and 11 development examples. One failed and was discarded. Every admitted project imported and ran cleanly for 60 seconds. Those are data checks, separate from the model scores below.
The 180 MIT GDScript reference files are stored separately and were not loaded directly into training. Collection accepts only MIT, Apache-2.0, or CC0 code, pins repository commits, and keeps file origins and license notices. It excludes assets, copyleft code, and conflicting or ambiguous notices. Third-party source keeps its original license.
The Stack v2 contains GDScript but was excluded because its gated terms and bulk-download agreement need separate attention. Data notes and provenance also document the optional local 14B teacher pilot and its rejected attempts.
These scores evaluate the LoRA adapter on its 4-bit base, on NVIDIA A100-SXM4-40GB. The merged FP16 and GGUF files have not been separately benchmarked. Values are filled only from a completed run. This table reports the separate full A100 pass on Colab Pro. The partial T4 experiment is preserved under evaluation-t4-partial/; its results are not pooled with this pass.
| Check | Result |
|---|---|
| Frozen prompts | 500 |
| Strict project format and zero-error import | 6/500 (1.2%) |
| Clean 60-second run | 5/500 (1.0%) |
| Warm prompt-to-launch median, successful launches only | 282.75 seconds |
| Successful launches measured within 60 seconds | 0/500 |
Both success rates include all 500 prompts. Each gets one generation, with no repairs or retries. Invalid JSON, parse errors, rejected APIs, early exits, and script errors count as failures; infrastructure failures leave the evaluation incomplete. All outputs and logs accompany the summary.
The warm timer excludes model loading. Each prompt receives the full batch generation time, plus its queue, project import, and startup time. We never divide latency by batch size. Interrupted or resumed timings are excluded; the clean-run check then lasts another 60 seconds. In the separate partial T4 experiment, the median among measured successful launches was 1,394.69 seconds, with none within 60 seconds. CPU export overlapped parts of that T4 experiment and its timings include that contention. The A100 protocol, training-prompt capacity checks and budget receipts accompany its evaluation; those measurements are separate from model quality scores.
The benchmark crosses 25 game families with 20 rule variants. Its 500 frozen prompts never enter training, development loss, or checkpoint selection. These are compositional variants, and the base model's pretraining data is outside our contamination audit.
A clean run does not establish fun, correct controls, prompt fidelity, or even a useful visible scene. Expect broken collision rules, unreachable goals, blank screens, and wrong Godot APIs. The small dataset and 4096-token context limit complex games, 3D, multiplayer, custom assets, and long inventories. Human playtesting matters.
Inference runs locally. Publication creates no paid endpoint. Provider mappings are checked during release; account provider switches and spending limits are verified separately. inference: false only hides the widget.
Try a prompt and share the exact output, Godot version, and what happened when you played. Distinct permissively licensed examples, playtest notes, and checks for blank-but-running scenes would help. Keep blind prompts out of training and include source licenses with contributions.
# Point FROM in Modelfile at the downloaded GGUF.ollama create vibegame -f Modelfilepython scripts/generate.py --backend ollama --model vibegame \ --prompt "Make a tiny game where I catch falling stars and avoid meteors" \ --output my-game.jsonpython scripts/extract_project.py my-game.json --output my-game