Across four tasks that the author says used the same OpenCode harness, the same prompt, and a Gemini 3.6 Flash high-thinking versus Kimi K3 comparison, Gemini delivered usable form-builder functionality and was clearly better at video analysis, but failed at frontend requirement compliance and racing-game interaction. This suggests that "strong multimodality at a low price" and "reliable code for fine-grained interaction" are two different capability axes.
Good for: Direct analysis of video/audio/documents, structured form backends, cost-sensitive research, and multimodal agents.
Not good for: Frontend visual details, complex interactive games, and single-shot generation where every requirement must be completed item by item.
Applicable model version: Gemini 3.6 Flash; the comparison model was Kimi K3, so the differences should not be treated as an absolute ranking.
Applicable client, agent, or API: OpenCode; the author also tested video uploads in the Gemini app.
Recommended reasoning level and parameters: The author used high thinking; the article says both models used the same setup, but does not disclose the complete system prompt, temperature, tool schema, or original prompt files.
The author used the OpenCode coding harness, with Gemini 3.6 Flash set to high thinking; Kimi K3 used the same settings to reduce harness bias.
Four tasks: a frontend landing page, the Neo Circuit browser racing game, the FormCraft AI form builder, and analysis of a two-minute Instagram video.
The author says each prompt was sent only once, without repeated retries until satisfied; however, part of the comparison output reused results from an earlier Kimi K3 session.
The frontend task required scroll scatter, scroll pointers, animated counters, parallax, and a responsive palette.
The racing game required a vehicle picker, start sequence, controls, and nitro boost.
FormCraft required login/registration, dashboards for three role types, form submission, CSV export, and editing.
The video task involved uploading a two-minute Instagram video, analyzing its hook, engagement, and retention, and generating a script in the same style.
Price comparison: Gemini costs $1.50 per million input tokens and $7.50 per million output tokens; Kimi K3 costs $3 / $15.
| Task | Gemini 3.6 Flash | Kimi K3 | Conclusion |
|---|---|---|---|
| Frontend design | Missed multiple interaction requirements; responsiveness and visuals were poor | Implemented as requested | Kimi wins |
| Neo Circuit | Nitro and driving controls did not work; graphics were weak | Vehicle selection, Start, driving, and nitro worked | Kimi wins |
| FormCraft | Forms, login, CSV, and editing functions worked, but the dashboard looked outdated | Not tested in this round | Only shows that Gemini's functionality worked; no win/loss comparison is possible |
| Video analysis | Accepted video natively and provided analysis and a script in about two minutes | The author says it could not accept video directly | Gemini wins |
This is a field benchmark with clearly defined tasks and a one-shot sending rule. Its most reusable lesson is to route work by task type: prioritize Gemini for multimodal files, require visual and behavioral regression testing for fine-grained frontend/interaction code, and keep a coding-oriented model as a fallback. The author also recommends using thinking_level instead of the old manual chain-of-thought approach and reducing legacy sampling parameters, but these settings should be checked against Google's current API documentation.
The comparison was not run entirely afresh at the same time: some Kimi results were reused from an earlier session, and the author did not publish all original prompts or links to the outputs.
The sample contains only four tasks, run once each; the results cannot represent every coding, game, or video workflow.
The article extensively cites Google's official benchmarks and other secondary sources; the hands-on results must be kept separate from the official figures.
The judgments that the visuals looked "outdated" and "rough" are subjective assessments by the author; functional usability also has no publicly available automated test logs.
In OpenCode, fix the same versions, permissions, tools, context, and high-thinking configuration, then connect Gemini 3.6 Flash and Kimi K3 separately.
Use the same frontend, game, form, and video prompts, run each once, and save the complete outputs, screenshots, console logs, and token/time data.
Validate item by item with a task checklist: every visual requirement, every interaction event, form data persistence/export, the video timeline, and script accuracy.
Use medium/low thinking to build a cost curve, reporting the pass rate, manual revision time, and per-task cost for each item—not merely which one "looks better."
The article discloses OpenCode, high thinking, the four tasks, the one-shot rule, input/output prices, and specific success/failure descriptions for each task. It does not provide downloadable prompt files, so the reproducibility of the "same configuration" is lower than in a fully open-source test.
The author summarizes the hands-on conclusion as "mixed results"; this better reflects the boundaries of the data than reducing the four tasks to a single winner.
Gemini 3.6 Flash