Kimi K3 Coding Review: Three Reproducible Tasks Through Our API

The test intentionally used small, inspectable tasks rather than claiming to simulate an entire software project. Task one repaired an interval merge function with three failure modes: input mutation, touching ranges not merging, and an empty-array crash. Task two implemented a TypeScript CSV-line parser requiring quoted fields, doubled-quote escaping, empty fields, a final empty field, and an explicit malformed-input error. Task three rewrote a minimal React modal to meet labelled-dialog, Escape, focus, click, cleanup, and server-rendering requirements.

These tasks cover different reasoning shapes. The interval task is a focused bug repair with precise edge cases. The CSV task requires a small state machine and careful parsing. The modal task combines React lifecycle behavior, DOM access, accessibility semantics, event propagation, and focus management. They are reproducible and easy to audit, but they do not test large repositories, dependency discovery, visual fidelity, multi-hour autonomy, or model-to-model ranking.

The primary run called `https://kimik3.online/api/v1/chat/completions`, not the Moonshot endpoint directly. A temporary test account, 10,000 temporary credits, and one API key were created specifically for the run and deleted afterward. The production route authenticated the key, checked credits, forwarded the request, received usage, charged the temporary balance, and returned the response. This exercises the same server-side API path documented for users.

Each task used one request, model `kimi-k3`, high reasoning, temperature 1, and a maximum of 4,096 completion tokens. Kimi K3 rejected temperature 0 during the upstream baseline because the endpoint currently permits only temperature 1; the production run therefore used the allowed value. There were no retries, prompt changes between runs, hidden follow-ups, or manual edits to outputs. The JSON evidence contains prompts, responses, timings, token usage, finish reasons, and the earlier direct-upstream baseline.

The production API returned in 16.1 seconds using 234 prompt tokens and 458 completion tokens, 692 total. The response copied each interval before sorting, avoiding mutation of both the outer list and inner range pairs. It returned an empty array for empty input and used a less-than-or-equal boundary so touching intervals merge. The response was code only, as requested, and stopped normally. On the stated criteria, the implementation is a usable pass.

This task also shows why code review remains necessary. A stronger test suite should include nested ranges, negative numbers, duplicate ranges, a single range, invalid intervals, and a policy for reversed endpoints. Those requirements were not in the prompt, so their absence is not counted as failure. The correct claim is that K3 repaired the specified defects cleanly in one response—not that the function is validated for every production data contract.

The CSV parser returned in 13.7 seconds using 178 prompt tokens and 506 completion tokens, 684 total. It maintained an `inQuotes` state, converted doubled quotes inside quoted fields into one literal quote, pushed fields at commas, preserved a final empty field by pushing after the loop, and threw the exact requested error when the line ended in quotes. It returned TypeScript code only and completed normally.

The output is suitable for the narrow grammar requested, but it is not a complete RFC-grade CSV parser. It allows a quote to become ordinary content after characters have already accumulated and does not reject every malformed transition, because the prompt required only an unclosed-quote error. It parses one line and therefore does not support quoted multiline records. These limitations illustrate a central review rule: judge against explicit acceptance criteria, then separately identify what a production specification would need.

The modal response took 80.0 seconds—far longer than the other tasks—and used 221 prompt tokens plus 2,639 completion tokens, 2,860 total. It added a labelled `role="dialog"` with `aria-modal`, focused the Close button on open, restored the prior active element during cleanup, installed and removed an Escape listener, closed from the overlay while stopping panel propagation, and guarded document access for server rendering. It also used a portal and a mounted state.

The implementation satisfies the listed checks, but “accessible modal” can imply more than the prompt required. It does not trap Tab focus inside the dialog, mark the background inert, prevent background scrolling, or support an `aria-labelledby` heading relationship. The overlay is a clickable `div` without separate pointer semantics, though the dialog itself is labelled. We count it as a pass on the stated requirements while clearly recording these production hardening gaps.

Across the production run, total wall time was approximately 109.9 seconds. The first two focused tasks completed in about fourteen to sixteen seconds. The React task took about eighty seconds and generated substantially more completion tokens. That variation matters for product design: a single “K3 speed” number would conceal the long tail. Interfaces should stream, support cancellation, display active state, and use timeouts appropriate to reasoning-heavy coding rather than short chat.

The production response reported cached prompt tokens equal to prompt tokens for these requests, while completion usage included reasoning details. Billing and cache interpretation belong to the serving provider and may change. The review preserves the raw fields instead of converting them into a universal cost because Kimi Platform, Kimi Code membership, and KimiK3.online credits are different systems. A larger evaluation should report median and tail latency over repeated runs.

Before the user requested a site-API test, the same prompts were sent once to the official Moonshot endpoint as a baseline. Those outputs are retained inside the evidence file but are not presented as the primary review. The direct requests took roughly 12.2, 24.9, and 32.2 seconds. The production run took 16.1, 13.7, and 80.0 seconds. With only one sample per condition, the difference cannot be attributed confidently to the proxy, model variance, caching, or transient load.

The value of the production rerun is functional: it confirms that the deployed authentication, credit check, forwarding, non-streaming response, usage capture, and charging path worked for all three tasks. It is not a rigorous overhead benchmark. Measuring gateway overhead would require matched repeated calls, server timing instrumentation, network-region control, and separation of upstream generation time from application processing.

The evidence supports a modest conclusion: Kimi K3 produced usable first-pass code for three bounded tasks spanning bug repair, parsing, and React accessibility requirements. It followed the code-only format, used requested language types, and completed without retries. The results justify placing K3 on a shortlist for focused coding and support the site’s Playground and API as functioning ways to evaluate it.

The evidence does not support claims that K3 replaces Claude Fable, Opus, GPT, or DeepSeek; that it wins repository-scale benchmarks; that every task passes in one shot; or that the observed latency is stable. Three prompts are a demonstration, not statistical proof. The outputs were inspected against explicit checks but were not compiled inside isolated fixtures in this first run. Future iterations should add executable tests and repeated samples.

Download the raw JSON evidence linked on this page. It contains the exact prompts and both sets of outputs. Create a KimiK3.online API key, ensure the account has sufficient credits, and send each prompt as a fresh conversation to the documented production endpoint with `model: "kimi-k3"`, `reasoning_effort: "high"`, `temperature: 1`, `max_tokens: 4096`, and `stream: false`. Store the HTTP result, model, usage, finish reason, and elapsed time.

Because model output is probabilistic at the allowed temperature, reproduction means repeating the conditions and checks, not expecting byte-identical code. Run multiple samples for a stronger estimate. Execute the returned code against visible tests and add adversarial cases. Publish failures as well as passes. Never expose a key in the artifact, and use a restricted test account rather than spending a customer’s credits without permission.

The next useful expansion is a small public fixture repository. It should include executable tests for the interval and CSV tasks, a browser accessibility test for the modal, and a repository-level issue requiring discovery across files. Run K3 at low and high effort, repeat each condition, and report pass rate, tokens, median and tail latency, intervention, and review time. Add screenshots captured from the rendered modal and test report rather than decorative model imagery.

A later model comparison can run the same fixture through Claude Fable 5, Claude Opus 5, GPT-5.6, and DeepSeek V4 Pro with equivalent budgets. The test harness, prompts, environment, and scorer must remain public. Until then, this page stays deliberately narrow: it is a transparent snapshot of Kimi K3 through this site’s production API on July 25, 2026.