Six models · high reasoning Custom skills supplied: 0
Build a polished 3D driving game that runs directly in a desktop browser. Prioritize convincing vehicle physics, realistic rendering, and smooth performance. Include one car and a complete circuit with straights, tight corners, elevation changes, and trackside scenery. Provide a chase camera, keyboard controls, speed display, lap timing, and a reset control. The car should respond convincingly to acceleration, braking, steering, tire grip, suspension, and collisions. Handling should remain consistent across different rendering frame rates. Aim for smooth 60 FPS at 1920×1080 on a typical modern laptop. Choose suitable libraries and techniques, balance visual quality against performance, and provide adjustable graphics quality. No signup or backend is needed. Test driving, collisions, reset, and lap timing. Provide a public playable preview, run instructions, and an honest account of limitations.
Make the driving game mobile friendly as well. Add usable touch controls for steering, acceleration, braking, and reset. Make the layout fit phone screens in portrait and landscape without hiding essential controls or information. Preserve the desktop controls, vehicle physics, graphics options, and existing gameplay. Test the mobile layout and controls, rebuild the final app, update the public preview, and update benchmark-result.json. Continue the same task and session; do not delegate or change model or reasoning settings.
One independent task per model, with fresh Boat workspaces and identical task and platform instructions. Model effort names do not imply equal compute budgets. Timings exclude setup, independent review, and publication; token-cost estimates exclude VM, proxy, tool, subscription, and tax charges. Apps retain the generated gameplay code. Publication adds the model name to each browser title. Browser checks use headless Chrome and SwiftShader software graphics on a shared CPU host. Host load was not controlled; frame-rate samples are not comparable across apps and do not establish real-device FPS. This single comparison does not establish a quality winner. The mobile requirement arrived after launch. Each agent received the same follow-up in its original session. Execution time and cost include both turns; total time also includes the wait between turns.
Execution time, seconds
Priced token subtotal, USD · * incomplete · — unknown
| Model | Harness | Run | Total | Input tokens | Output tokens | Cache read | Reasoning | Original preview | Publication check | ||
|---|---|---|---|---|---|---|---|---|---|---|---|
| GPT-6 Astra | Codex | Complete | 1321.1s | 1333.5s | 137,030 | 60,817 | 5,048,659 | $9.4598 | high | Published | Browser checks passed |
| GPT-6.1 Sol | Codex | Complete | 2312.1s | 2325.7s | 170,154 | 87,176 | 10,248,509 | $2.2369 | high | Published | Browser checks passed |
| DeepSeek V4.1 Flash | DeepSeek Harness | Complete | 2914.6s | 2980.7s | 374,695 | 317,964 | 39,778,304 | $0.9154 | high | Published | Browser checks passed |
| Claude Opus 5.5 | Claude Code | Complete | 3658.8s | 3673.3s | 218 | 219,360 | 18,463,518 | $9.5146 | high | Published | Browser checks passed |
| Claude Fable 5.1 | Claude Code | Complete | 4534.6s | 4544.9s | 244 | 194,419 | 17,300,772 | $18.1141 | high | Published | Browser checks passed |
| Claude Fable 5.2 | Claude Code | Complete | 6482.7s | 6489.5s | 246 | 361,508 | 31,787,591 | $28.2208 | high | Published | Browser checks passed |
Sorted by time taken, fastest first.
1321.1s · $9.4598
Browser checks passed
Agent-reported limits: The measured environment did not meet the requested smooth 60 FPS target. No claim of 60 FPS on a typical modern laptop is made. Procedural scene and car are stylized, not photorealistic.
Custom skills supplied: 0
2312.1s · $2.2369
Browser checks passed
Agent-reported limits: The 60 FPS goal was not met in this sandbox. The browser reports Intel UHD 620 through ANGLE/Mesa; software rendering was an initial assumption, not established by the diagnostic. Physical modern laptop performance is unverified. Quality controls adjust forest density, resolution, and shadows. Vehicle dynamics use a planar axle tire model and visual damped suspension. There is no independent four-wheel rigid-body suspension, jumping, rollover, or deformation.
Custom skills supplied: 0
2914.6s · $0.9154
Browser checks passed
Agent-reported limits: Frame-rate target could not be validated on real hardware. This environment exposes no GPU (/dev/dri is absent) and no GPU passthrough, so WebGL runs on Mesa's software rasteriser. Measured FPS at 1920x1080 was single-digit and did not improve at 1280x720 or on the 'low' preset, which is the signature of CPU rasterisation rather than a geometry or shader bottleneck. The evidence that the 60 FPS target is plausible is indirect: 121-123 draw calls, 151k triangles at high / 77k at low, no post-processing chain, one shadow-casting light, mostly instanced or merged geometry, and a physics + game-update cost of ~0.09 ms per 60 Hz frame on the CPU. Real-GPU verification is still required. Mobile layout and touch controls were validated by automated geometry assertions in emulated phone/tablet viewports (headless Chrome with isMobile + hasTouch) and by synthesised CDP multi-touch events - not by a human holding a physical phone. Real-device quirks (iOS Safari fullscreen restrictions, Android soft-keyboard insets, browser chrome overlapping the viewport) are handled defensively with safe-area insets and fullscreen guards but were not exercised on hardware.
Custom skills supplied: 0
3658.8s · $9.5146
Browser checks passed
Agent-reported limits: Real-GPU frame rate was not measured. The sandbox only had software rendering, so the 1920x1080 / 60 FPS goal is untested. On weak integrated GPUs, Medium or Low (or the dynamic-resolution fallback) may be needed. The car, trees, buildings and terrain are procedural and low-poly. They are stylised rather than photoreal, and there are no artist-made or scanned assets. There is no post-processing (bloom, SSAO, motion blur) and no day/night or weather.
Custom skills supplied: 0
4534.6s · $18.1141
Browser checks passed
Agent-reported limits: Performance on real hardware is untested: the sandbox renders with SwiftShader (software), so the 60 FPS @ 1080p target is a design budget, not a measurement. Lower the Quality preset if a laptop struggles (Low disables shadows and halves resolution). The vehicle uses a Bullet-style ray-cast vehicle model (Rapier's DynamicRayCastVehicleController): suspension, slip-limited tyre friction (friction ellipse), load transfer, drag/downforce and engine/gearbox are modelled, but there is no tyre slip-curve (Pacejka), no differential and no ABS/TC; keyboard steering is smoothed rather than analogue. Grip tuning is 'sporty arcade-sim', not a validated real car.
Custom skills supplied: 0
6482.7s · $28.2208
Browser checks passed
Agent-reported limits: Mobile support was tested only in emulated phones in headless Chrome; behaviour on real phones, tablets and iOS Safari (touch feel, performance, audio unlock, notches) is unverified. Frame rate on real hardware is unmeasured; the 60 fps at 1080p target rests on the scene budget and on Auto quality stepping down, not on a measurement.
Ferrari 458 Italia model by vicent091036 · CC BY 4.0 · Licence record. Licence recorded by the three.js asset tracker. Materials reassigned in code by the generated app.
Custom skills supplied: 0