Head to head: Kimi-K2.7-Code vs grok-4.3
Kimi-K2.7-Code vs grok-4.3
This one is as close as the aggregate score suggests, but the task sheet tells a more useful story: Kimi-K2.7-Code was the steadier model across the set, while grok-4.3 won fewer categories and mostly on narrower formatting-faithfulness calls. The statistical edge belongs to Kimi-K2.7-Code, and the reasons are concrete
The topline is almost absurdly tight: 102.5 vs 102.6 on aggregate. But the better read is the statistical verdict and the task ledger, not the raw decimal. Kimi-K2.7-Code takes the match with **83% confidence**, and it did so by winning **6 tasks to grok-4.3’s 3**, with **3 ties**. That is not a blowout, but it is a real edge: Kimi was more often the model that actually got the job done. What stands out is where Kimi won. It was better on the kinds of tasks that expose whether a model can operate inside constraints without losing the plot: the constrained team blurb, the scheduling puzzle, the vendor status update, contradiction finding, the Spanish delay notice, and one of the two LRU cache implementations. In several of those, both models were close, but Kimi more consistently hit the required structure, included the necessary details, or avoided correctness traps. The TypeScript-style LRU result is especially telling: Kimi handled the `undefined`-value edge case correctly, while grok’s version could break on a perfectly valid stored value. Grok’s wins are real, but they are narrower. It came out ahead on the faithful rewrite, strict JSON extraction, and precise proofreading—tasks where restraint, normalization, and minimal-edit discipline mattered most. That suggests a model that can be cleaner when the assignment is to preserve source material exactly and avoid editorial drift. But those advantages were not enough to offset losing twice as many tasks overall, especially when some of Kimi’s wins were on higher-friction prompts with multiple moving constraints. The split decision pattern in the order-swapped judge passes also reinforces the basic takeaway: this was not domination by either side, and individual task calls sometimes flipped on presentation details. Still, the center of gravity favors Kimi-K2.7-Code. It was the more reliable finisher across the broader set, even if grok-4.3 remained highly competitive and arguably a touch sharper on a few exacting rewrite-and-extraction jobs. **Final call: Kimi-K2.7-Code wins on points, not by knockout. In a matchup this close, the model with more task wins and an 83% statistical edge is the one you back—and here, that’s Kimi.**
Instruction-following / constrained team blurb
Write a project update that follows ALL of these rules exactly: - Exactly 4 bullet points - Each bullet must start with one of these labels in this order: Scope:, Risk:, Next:, Ask: - Each bullet must be 7 to 10 words long - Include the numbers 14, 2, and 97% - Do not use the words delay, problem, issue, urgent, or help - Mention a migration, a vendor, and QA - Plain text only Context: a small team is moving a booking system to a new vendor and most tests passed.
Model A satisfies the required labels, includes all required numbers and mentions migration, vendor, and QA, but misses the 7-10 word minimum on every bullet. Model B also misses the exact bullet formatting and omits the required leading hyphen bullets, while additionally failing the word-count constraint on multiple lines. (Order-swapped judge pass: Model A better satisfies the structural and content constraints, including the required labels in order, all required numbers, and mentions of migration, vendor, and QA. Model B uses extra bullet markers and misses the exact 7-10 word requirement on multiple bullets.)
Constraint scheduling
Four talks (A, B, C, D) fill four 1-hour slots 9,10,11,12. Constraints: A is before D; C is not first; B is immediately after A; D is not at 12. Give the ONE valid schedule as 'slot: talk' lines, then a one-line justification. If impossible, say so and explain.
Both models give the correct unique schedule, but Model A follows the requested format cleanly and provides the required one-line justification. Model B adds extra redundant text beyond the requested output, so it is less compliant and slightly weaker in writing quality. (Order-swapped judge pass: Both models give the correct unique schedule, but B follows the requested format more cleanly and provides a clearer one-line justification without redundant extra text. A includes unnecessary repeated 'Final answer' content, making it less compliant and polished.)
Professional-writing / vendor status update
Draft a status update email to a retail client's operations director. Audience: non-technical business stakeholder. Tone: calm, accountable, and concise. Length: 120 to 150 words. Scenario: Yesterday, your warehouse labeling system "ParcelMint" printed duplicate labels for 43 orders between 2:10 p.m. and 2:42 p.m. The bug is fixed. No customer payment data was affected. 31 duplicate packages were caught before pickup; 12 went out and will need carrier intercepts. Your team has started intercept requests and will send a final incident report by 10:00 a.m. tomorrow. Include a clear apology, what happened in plain language, current impact, and next steps.
Model A better matches the requested calm, accountable business tone and more fully covers the required next steps by mentioning both the final report timing and preventive measures. Model B is concise and clear, but it is slightly less complete and a bit less explicit about the operational impact and plain-language explanation. (Order-swapped judge pass: Both are accurate and concise, but B better matches the requested audience and content by explaining the issue in plain language, clearly stating impact and next steps, and promising root cause and preventive measures in the final report. A is solid but slightly less complete and less explicit about operational disruption and follow-up.)
Editing-proofreading / memo cleanup
Rewrite the passage below to correct grammar, punctuation, and clarity without changing its meaning. Then add a second section titled "Changes" with 3 brief bullet points describing what you fixed. "Hi team — the inventory count from North Dock were entered twice on Monday, which make the variance look bigger then it is. I already ask Rene to compare pallet 7B against the scan log, but he haven't finished because the forklift battery died. Unless receiving sends the noon spreadsheet again, we can't tell if the missing filters was actually shipped late or just keyed under the old SKU."
Both outputs correctly fix the passage and provide the required three bullet points, but A is slightly better because it also improves capitalization for clarity ("Receiving") and presents the section title exactly as requested. B leaves that capitalization unchanged and formats the heading less precisely. (Order-swapped judge pass: Both outputs correctly fix the passage and add the required three bullet points, but A is slightly better because it avoids the unnecessary capitalization of “Receiving” introduced by B. A is fully faithful to the original meaning and cleaner overall.)
Translation-localization / app delay notice
Translate the following customer-facing notice into Mexican Spanish. Keep the meaning and nuance, use a warm but professional tone, and keep it to 2 sentences total. "Heads up: tonight's maintenance window for Pinecart will start 30 minutes later than planned because our payment partner found an issue during final checks. Your saved carts and order history are safe, but checkout may be unavailable from 11:30 p.m. to 12:15 a.m."
Both are accurate and keep the required two-sentence structure, but A sounds slightly more polished and customer-facing in Mexican Spanish. B is also strong, though leaving "checkout" in English makes it feel a bit less localized. (Order-swapped judge pass: B is more natural for customer-facing Mexican Spanish, especially by translating "checkout" as "proceso de compra" instead of leaving an English term. Both follow the 2-sentence requirement and preserve the meaning, but B sounds warmer and more polished.)
Algorithm-data-structures / LRU cache
Implement an LRU cache in Python 3. Requirements: - Class name: LRUCache - Methods: __init__(capacity: int), get(key: int) -> int, put(key: int, value: int) -> None - get returns -1 if the key is absent - Both get and put must run in O(1) average time - Use no external libraries beyond the Python standard library - Return code only, no explanation
Both outputs are identical and fully satisfy the prompt: they implement an O(1)-average-time LRU cache in Python 3 using only the standard library and return code only.
Find the contradiction
The following spec contains exactly one internal contradiction. Quote the two conflicting sentences verbatim and explain the conflict in one sentence. Do not fix it. Spec: "Free accounts may create up to three projects. Every account, regardless of tier, may archive unlimited projects. Archiving a project does not count against the project limit. Free accounts are limited to three projects total, including archived ones."
Both identify the correct contradiction and explain it accurately, but A is slightly better because it clearly labels the two conflicting sentences and presents the explanation more cleanly. B is also correct, just a bit less polished in formatting. (Order-swapped judge pass: Both models identified the correct contradiction and explained it accurately, but Model B is slightly better because it cleanly quotes the conflicting sentences verbatim and presents the answer more clearly. Model A is correct but a bit less polished in formatting.)
Faithful rewrite
Rewrite this blunt internal note as a warm, professional Slack message to the whole engineering team (60–90 words), keeping every fact intact and adding no new commitments. Return only the message. Note: "Deploy is frozen until the memory leak in the image service is fixed. Priya is on it. Do not merge to main. ETA tomorrow noon."
Model B is warmer and more professional while preserving the original facts without adding substantive new information. Model A adds unsupported detail ('making progress') and extra commentary, which makes it less faithful to the source note. (Order-swapped judge pass: Model A is warmer and professional while preserving the original facts without adding substantive new information. Model B reads well, but it adds unsupported details like "making progress" and "keeping everything stable while Priya sorts this out," which go beyond the source note.)
Strict JSON extraction
Extract every meeting from this text into a JSON array of {"title","day","start24","durationMinutes"}. Use 24-hour "HH:MM" for start24, integer minutes for duration, and title-case titles. Return ONLY valid JSON, no commentary. Text: "Standup is daily at 9am for a quarter hour. The design review runs thursday from 2:30-4pm. Payroll sync — first monday, 11:00 to noon."
Both outputs correctly extract the meetings and format valid JSON, but Model B better follows the title-casing/style expectation by capitalizing recurring day values consistently. Model A's lowercase "daily" is a minor inconsistency. (Order-swapped judge pass: Both outputs correctly extract the meetings and durations, but Model A is better because it normalizes the day value to title case for "Daily," aligning more closely with the formatting instruction. Model B's lowercase "daily" is a minor instruction-following issue.)
Precise proofreading
Correct ONLY the grammar, spelling, and punctuation errors in the sentence below without changing wording, tone, or meaning, then on a second line list each change as 'was -> now'. Sentence: "Its been a long time since we seen there new office, and me and him was suprised how quite it was."
Model B better follows the instruction to correct only grammar, spelling, and punctuation without changing wording unnecessarily; Model A improperly changes "me and him" to "he and I," altering wording beyond the minimal required correction. Both fix the main errors, but B is more faithful to the prompt despite formatting the change list on one line. (Order-swapped judge pass: Model A corrects the grammar, spelling, and punctuation errors while preserving the original wording as much as possible. Model B makes an unnecessary wording change ('me and him' to 'he and I'), violating the instruction to avoid changing wording, tone, or meaning.)
LRU cache
Implement a class `LRUCache<K, V>` in TypeScript with a fixed capacity set in the constructor, and O(1) `get(key): V | undefined` and `set(key, value): void`. Accessing or updating a key must mark it most-recently-used; inserting beyond capacity must evict the least-recently-used entry. Return ONLY the class, no prose.
Both are concise and follow the requested API, but A correctly distinguishes a missing key from a stored undefined value by checking has(key) before get(key). B incorrectly treats stored undefined values as absent, which breaks correctness for V types that may include undefined. (Order-swapped judge pass: Both implementations satisfy the LRU behavior in O(1) using Map insertion order, but B correctly distinguishes a missing key from a stored undefined value by checking has() before get(). Both follow the instruction to return only the class, with B slightly cleaner and more robust.)
Summarization / meeting notes in JSON
Summarize these meeting notes into valid JSON with exactly these keys: "decision", "open_questions", "owners", "deadline". Use arrays where appropriate and keep every value faithful to the notes. Notes: - Lila confirmed the spring webinar will stay on April 18. - Registration page loaded slowly on mobile after Raj added the sponsor carousel. - Team agreed to remove autoplay video from the top banner. - Mateo will compress the carousel images by Wednesday. - Priya will draft a fallback page in case streaming caps at 1,500 attendees. - Open question: should certificate emails go out immediately or next morning? - Open question: can support staff manually resend access links? - Budget unchanged at $6,200.
Model A is more faithful overall: it preserves the decisions, questions, owners, and correctly keeps only the explicit task deadline as Wednesday. Model B incorrectly places April 18 under deadline, which is the event date rather than an assigned deadline. (Order-swapped judge pass: Model A better adheres to the required JSON format without markdown fencing and stays closer to the notes overall. Model B adds extra explanatory detail in the owners field and omits the April 18 deadline/date from the deadline field, while also wrapping the JSON in code fences.)
Matchup powered by OpenRouter.