Fable 5 vs Kimi K3 vs Qwen-3.8-Max: same scroll-driven story page, a 3.2x price gap for near-identical code

Three models, one prompt, a genuine side-by-side code read of a cinematic scroll-driven landing page. Part of our ongoing /design benchmark series in Command Code.

The prompt

Create a cinematic scroll-driven storytelling single-file HTML landing page for an eco-luxury brand "LUNAR". Tailwind CSS. Full vertical scroll experience with Intersection Observer + GSAP chapter reveals: The Problem, The Journey, The Solution, Impact. Include subtle 3D elements (Three.js spheres representing earth/moon) that move with scroll. Beautiful typography, nature color palette, very emotional and creative. End with strong CTA. Output full self-contained HTML.

Models and cost

Fable 5 and Kimi K3 are treated as single one-shot generations - one call, no re-rolls. Cost uses the same floor formula as the rest of this repo's one-shot builds: kept file's output bytes ÷ 4 × the model's published output price per MTok.

The two files are within 3% of each other in raw size - 548 vs. 583 lines, 28,032 vs. 28,986 bytes. Kimi K3 actually wrote slightly more code. The entire cost gap is priced in, not written in: Fable 5's output rate ($50/MTok) is 3.33x Kimi K3's ($15/MTok), almost exactly matching the ~3.2x gap in estimated cost.

What the code shows

Both builds independently converged on the same overall structure - Tailwind (CDN) + GSAP/ScrollTrigger (CDN) + Three.js r128 (CDN) for a persistent scroll-linked moon/earth, five chapters (Hero → Problem → Journey → Solution → Impact/CTA), IntersectionObserver-driven text reveals, and animated stat counters - despite the prompt not dictating that specific stack pairing.

Three.js scene complexity: Fable 5 keeps it minimal - a single displaced-vertex moon sphere, a small flat-shaded earth, and a 400-point starfield, all solid-color MeshStandardMaterial. Kimi K3 goes further, hand-painting canvas textures for both bodies via a makeTexture() helper (continent blobs and cloud wisps for earth, crater speckling for the moon) plus additive-blending sprite glows behind each - more visual fidelity per body, at the cost of a bit more code.

Scroll-to-3D binding: Fable 5 samples a hand-authored 6-waypoint path keyed to overall scroll progress with a smoothstep interpolant, driving position/scale/color every animation frame. Kimi K3 instead builds a single GSAP timeline with scrollTrigger: {scrub: 0.45} and explicit .to() keyframes for earth/moon position, scale, and color - same intent, different mechanism: a manual sampling function versus a GSAP-owned timeline scrub.

Reduced-motion handling: both respect prefers-reduced-motion, but Fable 5 hides the Three.js canvas outright, while Kimi K3 keeps the canvas and timeline running, just switching to scrub: true and static counter values instead of a scrubbed float - Fable 5's approach is the safer one for genuinely motion-sensitive users.

Accessibility and nav extras: Kimi K3 adds a fixed side dot-nav tied to the active chapter, aria-labels on decorative SVGs and canvas, and a focus-visible outline style - none of which Fable 5 includes. Fable 5's markup is comparatively leaner overall: no dot-nav, no focus-visible styling, no aria-hidden on decorative layers.

Neither ships a Content Security Policy or subresource-integrity hashes on its three CDN <script> tags - expected for a single-file demo, worth flagging if either were promoted past a showcase.

Qwen-3.8-Max, added to the same benchmark separately, wrote nearly double the code of the other two (1,083 lines) at the lowest floor cost of the three (~$0.055) - though as with its other appearances in this repo, that floor likely understates the real cost of a full agentic /design session with in-loop verification.

Verdict

Kimi K3 wrote about 6% more code than Fable 5 and spent it on extra visual and accessibility polish - textured 3D bodies, a dot-nav, focus states - while Fable 5 stayed leaner and slightly more conservative under reduced-motion. Neither is a strictly better implementation of the brief; the difference is a matter of where each model chose to spend its lines, not a quality gap.

The estimated cost story is driven entirely by per-token pricing, not code volume: two files within 3% of each other in size land 3.2x apart in price because Claude's output rate is 3.33x Kimi K3's. If you're choosing a model purely on "will it write comparable code for this kind of scroll-driven page," this comparison suggests the answer is yes - the deciding factor here is what you're paying per token, not what either model is capable of writing.

Limitations

• n=1 per model, no re-rolls, no variance estimate.
• Cost is a floor, not a metered figure, for all three models - it only counts the kept file's output tokens, not input tokens or any hidden reasoning/verification overhead. Qwen-3.8-Max in particular has shown, in this repo's other benchmarks, a real metered session cost that can run well above its floor once full agentic overhead is counted.

Try this yourself

Full command reference: commandcode.ai/docs/slash-commands/design. More one-shot comparisons: CommandCodeAI/slash-design-showcase.