{"slug": "head-to-head-kimi-k2-7-code-vs-gpt-5-4", "title": "Head to head: Kimi-K2.7-Code vs gpt-5.4", "summary": "In a head-to-head benchmark of 12 fresh text tasks, Kimi-K2.7-Code scored 103.5 against gpt-5.4's 101.5, with only 50% confidence that either model is better. The results show a near tie, with Kimi slightly stronger on code reasoning and gpt-5.4 on format-sensitive writing, but neither model consistently dominates.", "body_md": "This matchup is as close as it gets: **Kimi-K2.7-Code 103.5 vs gpt-5.4 101.5**, with only **50% confidence** that either model is actually better. That is not a win; it is a coin flip dressed up as a scoreline.\n\nThe task-by-task results back that up. Kimi takes the concurrency bug fix, localization, and the tricky SQL window query, while gpt-5.4 edges the constrained outage note, messy vendor extraction, and LRU cache task. The rest are dead even, including the repeat-buyers SQL, classification, ticket labeling, release notes, and manager update prompts.\n\nWhat matters here is how evenly the strengths cancel out. Kimi looks a touch sharper on code-centric reasoning and one translation task, while gpt-5.4 is a bit more polished on format-sensitive writing and extraction. But neither model consistently dominates the other, and several of the “wins” are narrow enough to be academic.\n\n**Final call: tie — effectively even, and too close to call.**\n\n### How they were tested\n\nWe ran 12 fresh text tasks, generated on the fly for this matchup so neither model could prepare in advance, and had gpt-5.4-mini score each one. Kimi-K2.7-Code scored 103.5 to gpt-5.4's 101.5.\n\n#### 1. Top repeat buyers SQL\n\nGiven this schema: customers(customer_id, customer_name, region) orders(order_id, customer_id, order_date, status) order_items(order_id, sku, quantity, unit_price) Write a single SQL query to return, for completed orders in Q1 2025 only, the top 3 customers by total revenue from customers in the 'Northwest' region. Revenue is sum(quantity * unit_price). Return columns: customer_id, customer_name, total_revenue. Sort by total_revenue descending, then customer_id ascending.\n\n**Winner: Tie** — Both queries correctly filter Northwest customers, completed orders, and Q1 2025, aggregate revenue properly, and return the requested top 3 sorted as specified. B is slightly more SQL-dialect-specific with DATE/FETCH syntax, but A is equally valid in many common SQL dialects, so overall they are equivalent. (Order-swapped judge pass: Both queries correctly filter Northwest customers, completed orders in Q1 2025, aggregate revenue as SUM(quantity * unit_price), group by customer, and sort as requested. The only difference is dialect-specific row limiting (FETCH FIRST vs LIMIT), so neither is clearly better without a specified SQL dialect.)\n\n#### 2. Constrained outage note\n\nWrite a customer-facing service notice about a brief outage in our invoice export feature. Follow ALL rules exactly: - Output exactly 4 bullet points. - Each bullet must start with these labels in order: Impact:, Cause:, Status:, Next step: - Each bullet must be 9-12 words long. - Include the timestamp \"2026-03-14 09:20 UTC\" exactly once. - Mention product name \"LedgerLane\" exactly once. - Do NOT use the words: sorry, apologize, issue, bug. - The final bullet must contain a URL placeholder in parentheses, like (link).\n\n**Winner: gpt-5.4** — B is closer to the required format and content, though both violate the 9-12 word constraint and the exact bullet-label ordering requirement. A also has a wording error and is less polished overall. (Order-swapped judge pass: Both outputs violate the strict formatting rules, but B is closer overall: it includes the required placeholder in the final bullet and avoids banned words. A misses the required exact bullet-label pattern and final-bullet URL placeholder format more clearly, while B still has a timestamp phrasing issue and other length/format problems.)\n\n#### 3. Concurrency bug fix\n\nThis TypeScript function is meant to memoize an async loader but has a race: concurrent callers can each trigger the underlying fetch. Fix it so the fetch runs at most once per key, and a rejected fetch does NOT poison the cache (a later call must retry). Return ONLY the corrected function. `ts const cache = new Map<string, Promise<string>>(); async function load(key: string, fetcher: (k: string) => Promise<string>) { if (cache.has(key)) return cache.get(key)!; const value = await fetcher(key); cache.set(key, Promise.resolve(value)); return value; } `\n\n**Winner: Kimi-K2.7-Code** — Both outputs correctly memoize the in-flight promise so concurrent callers share one fetch, and both delete the cache entry on rejection so later calls can retry. They are equally valid and similarly well-written for the task. (Order-swapped judge pass: Both fixes correctly memoize the in-flight promise and delete the cache entry on rejection so retries work. B is slightly better because it preserves an explicit Promise<string> return type and is a bit clearer/cleaner in its TypeScript signature.)\n\n#### 4. Localization with tone\n\nTranslate this app onboarding line into natural, friendly European Spanish suitable for a mobile toast (keep it under 60 characters, no exclamation marks): \"You're all set — your first backup starts tonight.\" Return only the translation, then the character count in parentheses.\n\n**Winner: Kimi-K2.7-Code** — A is more faithful to the source by preserving the meaning of \"backup\" as \"copia de seguridad,\" while still sounding natural and staying within the character limit. B is fluent, but \"copia\" is less precise and slightly weakens correctness. (Order-swapped judge pass: Both translations are natural and meet the length and punctuation constraints, but B is more faithful by using the full phrase \"copia de seguridad\" instead of the less precise \"copia.\" A is slightly more concise, but B better preserves the app/onboarding meaning.)\n\n#### 5. Nuanced classification\n\nClassify each review's sentiment as \"positive\", \"negative\", or \"mixed\", and give a 6-word-max reason. Return ONLY a JSON array of {\"text\",\"label\",\"reason\"} in input order. Reviews: [\"Fast shipping but the fabric feels cheap.\", \"Absolutely love it, wearing it daily!\", \"It broke after a week. Refund was quick and painless though.\"]\n\n**Winner: Tie** — Both outputs are correct and follow the JSON-only format, but B is slightly more concise and cleaner while still meeting the 6-word reason limit. A is also strong, but B has marginally better writing quality and compactness. (Order-swapped judge pass: Both outputs are correct and follow the JSON-only format, but B is slightly cleaner and more concise in its reasons while staying within the 6-word limit. A is also strong, but B has marginally better writing quality.)\n\n#### 6. Messy vendor info extraction\n\nExtract the requested fields from this messy text and return ONLY valid JSON with keys exactly: vendor_name, contract_id, renewal_date, monthly_fee_usd, seats, billing_contact_email, support_sla_hours. Text: \"Notes from Priya's call — vendor is Northbeam Metrics LLC (sometimes written Northbeam). New paperwork supersedes draft CB-771A; signed contract ID is CB-771A-REV2. Starts now, renews on 2027/01/31 unless canceled 45 days prior. Pricing: 36 analyst seats at $1420 per month total, not per user. Billing goes to [ap@northbeammetrics.com](mailto:ap@northbeammetrics.com), while technical help still uses [support@northbeam.io](mailto:support@northbeam.io). They promised a 6-hour response SLA for Sev-1; ignore the old brochure mentioning 12h.\"\n\n**Winner: gpt-5.4** — Both outputs extract the requested fields correctly and return valid JSON, but B is slightly better because it is more compact while still fully compliant. A is also correct, but B has cleaner presentation with no extra whitespace. (Order-swapped judge pass: Both outputs extract the same fields correctly and return valid JSON with the required keys. Model B is slightly prettier formatted, but both are equally correct and compliant.)\n\n#### 7. Summarize dense passage\n\nSummarize the passage below in exactly three bullet points, each one sentence, capturing the mechanism, the tradeoff, and the caveat — no jargon a non-specialist couldn't follow. Return only the bullets. Passage: \"Speculative decoding pairs a small draft model with a large target model: the draft proposes several tokens, the target verifies them in one pass, and accepted tokens are kept while the first rejection resets to the target's own choice. This can cut latency substantially when acceptance is high, but the draft model's compute is pure overhead when acceptance is low, and gains evaporate on adversarial or highly novel inputs where the draft and target disagree often.\"\n\n**Winner: Tie** — Both outputs are accurate and follow the three-bullet, one-sentence format, but B is slightly clearer and more faithful to the passage’s mechanism and caveat. A is also strong, but B’s wording is a bit smoother and more precise overall. (Order-swapped judge pass: Both outputs follow the three-bullet, one-sentence, plain-language format and capture the mechanism, tradeoff, and caveat accurately. B is slightly tighter and more faithful to the passage’s wording about wasted effort and disagreement on unfamiliar inputs.)\n\n#### 8. LRU cache\n\nImplement a class `LRUCache<K, V>`\n\nin TypeScript with a fixed capacity set in the constructor, and O(1) `get(key): V | undefined`\n\nand `set(key, value): void`\n\n. 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.\n\n**Winner: gpt-5.4** — Both implementations satisfy the LRU behavior, but B is more robust and explicitly maintains O(1) operations with a proper doubly linked list. A is concise and likely correct in practice, but it relies on Map iteration order and has a minor edge-case risk around eviction handling and capacity validation. (Order-swapped judge pass: A correctly implements O(1) get/set with a proper doubly linked list plus map and returns only the class. B is simpler and mostly correct, but it relies on Map iteration semantics and includes markdown code fences, which violates the 'Return ONLY the class' instruction.)\n\n#### 9. Ticket intent labeling\n\nClassify each support message into one category: Billing, Access, Feature Request, Incident, or How-to. Return exactly one line per item in this format: <number> | <category> | <8 words or fewer justification>. Items: 1) \"I was charged twice after upgrading to the cedar plan.\" 2) \"Where can I export all audit logs for February?\" 3) \"The mobile app shows a blank white screen after login.\" 4) \"Please add SAML login for Okta tenants.\" 5) \"My reset link expired before I clicked it.\"\n\n**Winner: Tie** — Both outputs are correct and follow the required format, but B is slightly cleaner and more concise while still staying within the 8-word justification limit. A is also strong, though B’s justifications are a bit tighter and more direct. (Order-swapped judge pass: Both outputs are mostly correct and follow the required format, but B is slightly clearer and more precise in its justifications. A is also good, though item 5 is a bit less accurate than B's explanation.)\n\n#### 10. SQL window query\n\nGiven Postgres tables `orders(id, customer_id, created_at, total_cents)`\n\nand `customers(id, name)`\n\n, write ONE SQL query returning each customer's name and their SECOND-largest order total (in dollars, 2 decimals), excluding customers with fewer than two orders. Order by that value descending. Return ONLY the SQL.\n\n**Winner: Kimi-K2.7-Code** — A correctly returns the second-largest order total per customer, excludes customers with fewer than two orders, formats to two decimals, and orders by the computed value. B misses the fewer-than-two-orders exclusion, orders by the wrong column, and uses TO_CHAR instead of a numeric result, making it less correct for the prompt. (Order-swapped judge pass: B is closer to the requested result: it returns a numeric dollar amount with two decimals, excludes customers with fewer than two orders, and orders by that value descending. A uses TO_CHAR, which returns text rather than a numeric value, and its ordering is less aligned with the requested output.)\n\n#### 11. Release notes summary\n\nSummarize the following changelog into exactly 3 bullets. Each bullet must start with one of these headers in order: Added:, Fixed:, Known issue:. Keep each bullet to 12 words or fewer. Source: \"Version 4.8.2 shipped to all tenants Friday evening. We added CSV export for warehouse cycle counts and a new filter for suppliers marked probationary. We fixed a rounding error that occasionally overstated carton weights on pick tickets, and corrected a timezone problem that made some Dublin users see next-day delivery slots as unavailable after 11 PM local time. Known problem: barcode scans from the older H7 handheld can duplicate the final digit when battery level drops below 9%. Support has a workaround: disable predictive scan mode.\"\n\n**Winner: Tie** — Both outputs follow the exact 3-bullet, header-order, and word-limit constraints, while accurately capturing the changelog. Model A is slightly more literal; Model B is slightly smoother, but neither is clearly better overall. (Order-swapped judge pass: Both outputs follow the required 3-bullet format, use the specified headers in order, and stay within the word limit. Model A is slightly more complete in the fixed bullet, while Model B is slightly tighter, so overall they are effectively equivalent.)\n\n#### 12. Manager status update\n\nDraft a Slack update to your manager after a product launch delay. Context: the Aurora Claims portal launch moved from Tuesday to Thursday because the claims PDF renderer failed in staging for policies with more than 12 attachments. Engineering has a patch under review, QA will rerun regression at 3 PM, and customer success has already alerted pilot clients. Audience: your direct manager. Tone: calm, accountable, concise. Length: 70-90 words. Include a clear ask for one decision.\n\n**Winner: Tie** — Both are accurate and appropriately concise, but B reads a bit more polished and directly frames the single decision for the manager. A is strong, though its explicit question about a broader customer notice is slightly less aligned with the requested manager-status style than B’s clearer decision ask. (Order-swapped judge pass: Both are accurate and appropriately concise, but B is slightly stronger because it is cleaner, more direct, and includes a clearer decision ask. A is solid but a bit more verbose and slightly less polished for a Slack update.)\n\nSee every prompt and the full side-by-side outputs in the [interactive Head-to-Head](/head-to-head/head-to-head-kimi-k2-7-code-vs-gpt-5-4).", "url": "https://wpnews.pro/news/head-to-head-kimi-k2-7-code-vs-gpt-5-4", "canonical_source": "https://runtimewire.com/article/head-to-head-kimi-k2-7-code-vs-gpt-5-4", "published_at": "2026-07-16 14:06:35+00:00", "updated_at": "2026-07-16 14:12:34.386936+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-research"], "entities": ["Kimi-K2.7-Code", "gpt-5.4", "gpt-5.4-mini", "LedgerLane"], "alternates": {"html": "https://wpnews.pro/news/head-to-head-kimi-k2-7-code-vs-gpt-5-4", "markdown": "https://wpnews.pro/news/head-to-head-kimi-k2-7-code-vs-gpt-5-4.md", "text": "https://wpnews.pro/news/head-to-head-kimi-k2-7-code-vs-gpt-5-4.txt", "jsonld": "https://wpnews.pro/news/head-to-head-kimi-k2-7-code-vs-gpt-5-4.jsonld"}}