Head to head: Muse Spark 1.1 vs Kimi-K2.7-Code

The topline number says Kimi-K2.7-Code is ahead, 101.8 to 97.7. The stats say not so fast. At 62% confidence that either model is genuinely better, this matchup is a dead heat in any honest editorial framing. There is no defensible winner here—just two models landing in the same performance band and splitting hairs on task-specific details.

Muse Spark 1.1 had the cleaner edge on instruction discipline and a few high-value practical tasks. It was better on support-ticket labeling, summarizing a dense passage, SQL window query, and precise proofreading, mostly by sticking closer to the requested format and keeping prose more accessible. Its strongest substantive win came on the concurrency bug fix, where it handled in-flight promise memoization and cache cleanup more safely, while Kimi’s answer had a meaningful implementation caveat and formatting sloppiness.

Kimi-K2.7-Code answered with wins in places that matter too: nuanced classification, Mexican Spanish ops translation, warehouse restock math, and Python log redaction. The translation result was notably more natural in workplace Spanish, and on the redaction task Kimi’s code was judged the stronger implementation in one pass. That said, several of these wins were razor-thin—and the order-swapped judge passes repeatedly undercut any claim that one model consistently outclassed the other.

Just as important, three tasks were outright ties: clinic shift assignment, constraint scheduling, and messy expense extraction. And across the full slate, the pattern is not dominance but alternation. Muse looked a bit more reliable when exact output format and editorial restraint mattered; Kimi looked a bit sharper on concision, natural phrasing, and some coding/math tasks. The problem for anyone trying to crown a champion is simple: the evidence never separates them for long.

Final call: too close to call. Muse Spark 1.1 and Kimi-K2.7-Code are effectively even in this matchup, and declaring a winner would be more confidence than the results justify.

How they were tested

We ran 12 fresh text tasks, generated on the fly for this matchup so neither model could prepare in advance, and had gpt-5.4 score each one. Muse Spark 1.1 scored 97.7 to Kimi-K2.7-Code's 101.8.

1. support-ticket-labeling

Classify each support ticket into one category: billing, bug, feature_request, account_access, or how_to. Return a JSON array of objects with keys id, category, justification. Tickets: 1. T-901: I was charged twice for the Pro plan after changing cards yesterday. 2. T-902: Where do I export all responses as CSV? I can't find the menu in the new dashboard. 3. T-903: After I click Save on the shift template, the page spins forever in Firefox 128 on Ubuntu. 4. T-904: Can you add a way to lock a form after 200 submissions instead of closing it manually? 5. T-905: My sign-in link expires instantly and password reset emails never arrive. 6. T-906: Need help setting automatic weekly email summaries for store managers.

Winner: Muse Spark 1.1 — Both outputs classify all tickets correctly with clear justifications. Model A is slightly better because it follows the requested output format exactly, while Model B wraps the JSON in a Markdown code fence instead of returning only raw JSON. (Order-swapped judge pass: Both outputs classify all six tickets correctly, follow the requested JSON structure with the required keys, and provide clear justifications. Model A wraps the array in a code block in its displayed output, while Model B does not, but both substantive answers are equally strong for the task.)

2. clinic-shift-assignment

Assign each person to exactly one role for Tuesday morning at a small clinic: Triage, Vaccines, Phones, Inventory. People: Amina, Bruno, Celia, Dev. Use all four people once. Constraints: 1) Amina cannot do Phones. 2) Bruno must be either Triage or Inventory. 3) Celia cannot do Vaccines. 4) Dev must be scheduled later alphabetically than Bruno's role, using role order: Inventory, Phones, Triage, Vaccines. 5) Triage is not Amina. 6) Phones is not Celia. 7) Inventory is not Dev. Return just the final assignment as Amina=..., Bruno=..., Celia=..., Dev=...

Winner: Tie — Both outputs are identical, satisfy all constraints, and match the required response format exactly. There is no quality difference between them. (Order-swapped judge pass: Both outputs are identical and incorrect: with Bruno=Inventory, Dev must be later alphabetically than Inventory, but Dev=Phones violates that because Phones comes immediately after Inventory in the given order? Actually Phones is later than Inventory, so that part is fine; however Celia=Triage and Amina=Vaccines leaves Dev=Phones, which satisfies all listed constraints. Since both are equally valid and follow the required format, they tie.)

3. Nuanced classification

Classify 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."]

Winner: Kimi-K2.7-Code — Both outputs classify all three reviews correctly and follow the JSON-only requirement. Model B is slightly better because each reason is concise, natural, and clearly within the 6-word limit without awkward phrasing. (Order-swapped judge pass: Both outputs correctly classify all three reviews, keep reasons within the six-word limit, preserve input order, and return valid JSON arrays. The wording differs slightly, but neither has a meaningful quality or instruction-following advantage.)

4. Summarize dense passage

Summarize 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."

Winner: Muse Spark 1.1 — Both summaries are accurate and clear, but A better matches the requirement to avoid specialist jargon and uses exactly three clean bullet points. B is also strong, but it uses more technical phrasing like "model," "batch," and "single step," and its formatting includes blank lines between bullets. (Order-swapped judge pass: Both are accurate and follow the format, but B is slightly better because it is cleaner, more concise, and more accessible to a non-specialist while still capturing the mechanism, tradeoff, and caveat. A is also strong, but its first bullet is a bit more technical and wordier.)

5. Concurrency bug fix

This 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; }

Winner: Muse Spark 1.1 — Model A correctly memoizes the in-flight promise and safely removes it only if it is still the cached entry, avoiding accidental deletion after a later retry. Model B fixes the main race but unconditionally deletes on rejection and also violates the instruction to return only the corrected function by re-declaring the cache. (Order-swapped judge pass: Both fix the race by caching the in-flight promise and removing failed entries so later calls retry. B is slightly better because its conditional delete avoids deleting a newer promise that may have been stored for the same key before the rejection handler runs.)

6. 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.

Winner: Tie — Both outputs give the unique valid schedule and a correct one-line justification that satisfies the prompt. Model B is slightly more polished, but not enough to outweigh that both are fully correct and compliant. (Order-swapped judge pass: Both outputs give the unique valid schedule and a concise justification that satisfies the prompt. Model B is slightly more compact, while Model A is slightly more explanatory, but neither is meaningfully better overall.)

7. es-mx-ops-translation

Translate the following into Spanish (Mexico) for a polite but direct message from an operations manager to store staff. Keep it under 55 words, preserve the meaning, and sound natural for workplace chat: "Please stop leaving the freezer door propped open during deliveries. It raises product temperature and triggers an alarm reset. If you need the doorway cleared, ask Marcos or me and we'll help immediately."

Winner: Kimi-K2.7-Code — B sounds more natural and workplace-appropriate in Mexican Spanish while preserving the meaning clearly and staying concise. A is understandable, but "atorada abierta" is less natural here and "obliga a reiniciar la alarma" is slightly less precise than "provoca el reinicio de la alarma." (Order-swapped judge pass: A is more natural and workplace-appropriate in Mexican Spanish while preserving the meaning clearly and politely. B is also strong, but "atorada abierta" sounds less natural here and slightly awkward for this context.)

8. SQL window query

Given Postgres tables orders(id, customer_id, created_at, total_cents) and customers(id, name), 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.

Winner: Muse Spark 1.1 — Model A returns valid Postgres SQL that correctly yields each customer's second-highest order total and excludes customers with fewer than two orders via the lateral join. Model B is also logically correct, but it violates the instruction to return only SQL by including Markdown code fences. (Order-swapped judge pass: Both queries are valid and exclude customers with fewer than two orders, but B is simpler and directly returns the second-largest order via OFFSET/LIMIT. A is also correct, though slightly more verbose and includes unnecessary counting logic.)

9. warehouse-restock-math

A warehouse packs solvent bottles into cartons of 12. On Monday it had 37 cartons and 5 loose bottles. It shipped 18 cartons and 9 loose bottles to clinics. Then it received 11 cartons and 8 loose bottles from a supplier. Later, 17 bottles were found damaged and discarded. Finally, all remaining bottles were repacked into full cartons plus leftover loose bottles. How many full cartons and loose bottles remain at the end? Show your steps.

Winner: Kimi-K2.7-Code — Both models reach the correct final answer and show steps, but Model B is cleaner and avoids an arithmetic slip in presentation risk that appears in Model A’s carton/loose handling after discarding. Model B is more direct, fully correct, and easier to follow. (Order-swapped judge pass: Both models reach the correct final answer and show steps, but Model A is cleaner and fully consistent. Model B introduces unnecessary carton/loose-state manipulations and contains an internal inconsistency in step 4 when converting the damaged-bottle removal back to cartons/loose form.)

10. python-log-redactor

Language: Python 3.11 Return code only. Write a function redact_log(line: str) -> str for a support tool. It must replace any IPv4 address with [IP] and any ticket ID of the form INC- followed by exactly 6 digits with [TICKET]. Do not alter invalid IP-like strings such as 999.1.2.3 or 10.2.3, and do not partially mask longer digit runs like INC-1234567. Preserve all other characters exactly. Examples: - "db timeout from 10.44.3.9 on INC-482901" -> "db timeout from [IP] on [TICKET]" - "weird 999.1.2.3 and INC-1234567 stay" -> unchanged - "src=172.16.0.12,dst=172.16.0.13 ticket INC-000042" -> "src=[IP],dst=[IP] ticket [TICKET]"

Winner: Kimi-K2.7-Code — Model B provides valid, well-structured Python code that correctly handles valid IPv4 addresses and avoids masking longer ticket digit runs. Model A is effectively invalid Python as presented and its regex uses unescaped dots, making the matching behavior incorrect. (Order-swapped judge pass: Model A is valid Python, correctly matches only valid IPv4 addresses and exactly six-digit ticket IDs without partial masking, and preserves surrounding text. Model B is effectively invalid/unreadable as provided and its regexes are flawed, using unescaped dots that would overmatch and risking incorrect replacements.)

11. messy-expense-extraction

Extract the expense data from the messy note below into a JSON array. One object per expense with keys exactly: date, vendor, amount, currency, category, billable. Rules: use ISO dates YYYY-MM-DD; amount as number; billable as true/false; ignore non-expense lines and duplicates. Note: Mon 4 Aug 2025 - North Quay Taxi £18.40 to airport (client billable) coffee w/ Mira 05/08/25 Bean Loft EUR 6,80 not billable IGNORE: card check 1234 balance ok Hotel: Cedar Rooms | 2025-08-05 | USD 129.00 | billable | category lodging Duplicate? Cedar Rooms 2025-08-05 USD129.00 billable lodging Aug 06 2025 printer paper from OfficeNest $14.25 admin not-billable refund from North Quay Taxi -£18.40 on 2025-08-07 (not an expense)

Winner: Tie — Both extract the same valid expenses, ignore the duplicate and refund, and normalize dates and amounts correctly. Model A is slightly better because it outputs a plain JSON array as requested, while Model B wraps the JSON in a Markdown code fence, which is a minor instruction-following issue. (Order-swapped judge pass: Both outputs correctly extract the four expenses, ignore the refund and non-expense line, and deduplicate Cedar Rooms. Model A is slightly better because its category choice for the taxi expense ('transport') is more directly grounded in the note than Model B's broader 'travel', and it presents fully valid JSON in a fenced block.)

12. 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."

Winner: Muse Spark 1.1 — Model A makes only necessary grammar, spelling, and punctuation corrections and lists the changes in the requested format. Model B changes the wording more substantially by rewriting "we seen" as "we've seen" and adds an extra "Changes:" label, making it less faithful to the instruction. (Order-swapped judge pass: Model A better preserves the original wording while fixing the errors, though it still changes 'we seen' to 'we've seen,' which alters wording more than necessary. Model B makes a less faithful tense change to 'we saw' and also formats the second line less cleanly.)

See every prompt and the full side-by-side outputs in the interactive Head-to-Head.