Head to head: Kimi-K2.7-Code vs gpt-5.4-mini

Kimi-K2.7-Code vs gpt-5.4-mini

This was a close matchup on aggregate, but Kimi-K2.7-Code finished ahead by being more reliable on instruction-following and structured tasks. gpt-5.4-mini had real strengths in polished prose and one coding task, yet Kimi took more categories and the overall edge.

The topline matters: Kimi-K2.7-Code wins **100.0 to 98.8**, with an **83% confidence** verdict. That is not a blowout, and it should not be sold as one. But it is a real lead, backed by the task count too: **6 wins to 3**, with **3 ties**. Why Kimi got there is pretty clear from the tape. On the SQL prompts, both models were often substantively correct, but Kimi was more disciplined about the actual output contract: **raw SQL only**, no markdown wrappers, no avoidable formatting violations. That sounds minor until it costs you the task. Kimi also landed important precision wins in contradiction-finding and the support rota constraint problem, where gpt-5.4-mini either chased the wrong conflict or declared an actually solvable setup inconsistent. gpt-5.4-mini was not outclassed. It was better on the outage-update email, where its version felt a touch more publication-ready, and it took the TTL LRU cache task when Kimi's answer was truncated. It also won the faithful rewrite task by staying closer to source material and resisting the temptation to embellish. Those are meaningful strengths: cleaner prose, solid editorial restraint, and competitive coding when the answer actually arrives intact. But the pattern across this matchup favors Kimi. The ties in math, reasoning, and summarization show there was no broad quality gap either way; the separation came from execution under constraints. Kimi was more likely to do the exact job asked, especially in technical tasks where formatting, determinism, and directness matter. **Final call: Kimi-K2.7-Code is the winner here—narrowly, but deservedly.**

SQL & data queries: repeat purchasers

Given this schema: customers(id INT PRIMARY KEY, name TEXT, region TEXT) orders(id INT PRIMARY KEY, customer_id INT, order_date DATE, channel TEXT) order_items(order_id INT, sku TEXT, qty INT, unit_price DECIMAL(10,2)) Write a single SQL query to return, for each region, the customer_id and total_revenue of the highest-revenue customer considering only orders placed in 2024 through the 'direct' channel. Revenue is SUM(qty * unit_price) across that customer’s qualifying order items. Include only customers with at least 2 distinct qualifying orders. If there is a tie within a region, return the customer with the smaller customer_id. Output columns: region, customer_id, total_revenue. Return SQL only.

Kimi-K2.7-Code: WITH customer_revenue AS ( SELECT c.region, o.customer_id, SUM(oi.qty * oi.unit_price) AS total_revenue, COUNT(DISTINCT o.id) AS qualifying_orders FROM orders o JOIN customers c ON c.id = o.customer_id JOIN order_items oi ON oi.order_id = o.id WHERE o.channel = 'direct' AND o.order_date >= '2024-01-01' AND o.order_date <= '2024-12-31' GROUP BY c.region, o.customer_id HAVING COUNT(DISTINCT o.id) >= 2 ), ranked AS ( SELECT region, customer_id, total_revenue, ROW_NUMBER() OVER ( PARTITION BY region ORDER BY total_revenue DESC, customer_id ASC ) AS rn FROM customer_revenue ) SELECT region, customer_id, total_revenue FROM ranked WHERE rn = 1;

gpt-5.4-mini: ```sql WITH qualifying_orders AS ( SELECT DISTINCT o.id, o.customer_id FROM orders o WHERE o.order_date >= DATE '2024-01-01' AND o.order_date < DATE '2025-01-01' AND o.channel = 'direct' ), customer_revenue AS ( SELECT c.region, c.id AS customer_id, SUM(oi.qty * oi.unit_price) AS total_revenue, COUNT(DISTINCT qo.id) AS qualifying_order_count FROM customers c JOIN qualifying_orders qo ON qo.customer_id = c.id JOIN order_items oi ON oi.order_id = qo.id GROUP BY c.region, c.id HAVING COUNT(DISTINCT qo.id) >= 2 ), ranked AS ( SELECT region, customer_id, total_revenue, ROW_NUMBER() OVER ( PARTITION BY region ORDER BY total_revenue DESC, customer_id ASC ) AS rn FROM customer_revenue ) SELECT region, customer_id, total_revenue FROM ranked WHERE rn = 1; ```

Both queries correctly compute per-region top customers with the required tie-break and minimum of 2 qualifying orders, but Model A better follows the instruction to return SQL only. Model B is also correct, but the surrounding markdown code fences violate the output constraint. (Order-swapped judge pass: Both queries correctly compute per-customer 2024 direct-channel revenue, enforce at least 2 distinct qualifying orders, and use ROW_NUMBER with the proper tie-break on smaller customer_id within each region. Model A is slightly more explicit with a qualifying_orders CTE, while Model B is more concise; both fully satisfy the prompt.)

Professional writing: outage update email

You are the on-call engineering manager at Northline Health. Draft an email to 42 clinic administrators about today’s partial outage in the appointment reminder system. Audience: non-technical operations staff. Tone: calm, accountable, and specific. Length: 140–180 words. Facts to include: from 08:17 to 09:46 local time, SMS reminders for appointments were delayed due to a failed queue failover during routine database maintenance; no appointment records were lost; 1,284 messages were sent late, 96 were not sent and will be re-sent by 11:30; voice reminders and patient portal messages were unaffected; a fix is in place and we are adding an automated pre-maintenance failover check this week. Ask clinics not to manually resend reminders yet, and provide a reply path for urgent patient-impact concerns.

Kimi-K2.7-Code: **Subject:** Appointment reminder SMS delay resolved Dear Clinic Administrators, Today from 8:17 a.m. to 9:46 a.m. local time, SMS appointment reminders were delayed after a queue failover did not complete during routine database maintenance. No appointment records were lost. A total of 1,284 reminders were sent late, and 96 were not delivered. We will resend those 96 messages by 11:30 a.m. today. Voice reminders and patient portal messages were not affected. The issue is resolved, and a fix is now in place. To prevent recurrence, we are adding an automated pre-maintenance failover check this week. Please do not manually resend reminders yet. If you have an urgent patient-impact concern, reply to this email or contact the on-call engineering manager at [oncall@northlinehealth.org / 555-0199] so we can assist immediately. Thank you for your patience. [Your Name] Engineering Manager, Northline Health

gpt-5.4-mini: Subject: Update on Today’s Appointment Reminder Delay Dear Clinic Administrators, I’m writing to share an update on this morning’s partial outage in our appointment reminder system. From 08:17 to 09:46 local time, SMS appointment reminders were delayed due to a failed queue failover during routine database maintenance. No appointment records were lost. During the incident, 1,284 messages were sent late, and 96 messages were not sent; those will be re-sent by 11:30 local time. Voice reminders and patient portal messages were not affected. A fix is now in place, and this week we are adding an automated pre-maintenance failover check to reduce the chance of a repeat issue. Please do not manually resend reminders yet, as that could create duplicate messages for patients. If you have an urgent patient-impact concern or believe a reminder delay is causing an immediate issue, reply directly to this email and we will triage it promptly. Thank you for your patience and partnership. Best, [Your Name] On-call Engineering Manager, Northline Health

Both emails are accurate and within the requested tone and length, but B is slightly stronger for this audience: it is a bit more polished, explicitly frames the issue as a partial outage, and gives a clearer reason not to manually resend reminders. A is also solid, but the bracketed contact placeholder is less clean and slightly less ready to send. (Order-swapped judge pass: Both are accurate and well-written, but A better matches the requested tone of calm, accountable, and specific, and its wording about not manually resending avoids ambiguity. B is also strong, but the added placeholder contact details feel less clean and slightly less polished for the prompt.)

Localization with tone

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

Kimi-K2.7-Code: Listo: tu primera copia de seguridad empieza esta noche. (57)

gpt-5.4-mini: Ya está todo listo — tu primera copia empieza esta noche. (58)

Both are under 60 characters and natural enough, but B sounds friendlier and more idiomatic for onboarding toast copy in European Spanish. A is accurate yet slightly more formal/heavy with "copia de seguridad" and its stated character count appears off by one. (Order-swapped judge pass: Both are natural and under 60 characters, but A appears to miscount its length and is slightly less concise for a mobile toast. B is accurate, clear, and better suited to the requested friendly onboarding tone.)

Unit-aware math

A pump moves 3.5 liters every 8 seconds. A tank holds 0.9 cubic meters. Starting empty, how long to fill it, in minutes and seconds (mm:ss), rounded to the nearest second? Show the key steps, then give the final answer on its own line.

Kimi-K2.7-Code: Key steps: 1. Convert tank capacity to liters: \(0.9 \text{ m}^3 \times 1000 = 900 \text{ L}\) 2. Pump rate: \(\frac{3.5 \text{ L}}{8 \text{ s}} = 0.4375 \text{ L/s}\) 3. Time in seconds: \(\frac{900}{0.4375} = 2057.142...\text{ s}\) 4. Round to nearest second: \(2057 \text{ s}\) 5. Convert to minutes and seconds: \(2057 \div 60 = 34\) minutes with a remainder of \(17\) seconds 34:17

gpt-5.4-mini: Convert the tank volume to liters: - \(0.9 \text{ m}^3 = 900 \text{ L}\) Find the pump rate: - \(3.5 \text{ L in } 8 \text{ s} \Rightarrow \frac{3.5}{8} = 0.4375 \text{ L/s}\) Compute the filling time: - \(900 \div 0.4375 = 2057.142857\ldots \text{ s}\) Round to the nearest second: - \(2057 \text{ s}\) Convert to minutes and seconds: - \(2057 \div 60 = 34\) minutes with \(17\) seconds left 34:17

Both outputs are mathematically correct, show the key steps clearly, and provide the final answer on its own line in the requested mm:ss format. The differences in presentation are negligible. (Order-swapped judge pass: Both outputs are correct, show the key steps clearly, and provide the final answer on its own line in the requested mm:ss format. Model B is slightly more structured, but the overall quality is effectively equal.)

Step-by-step reasoning: warehouse packing

A small warehouse is packing a wholesale order using only full cartons. Item A comes in cartons of 24 units, item B in cartons of 15, and item C in cartons of 18. The order requires exactly 312 total units across all three items. There must be more units of A than B, and more units of B than C. The number of cartons used for A is twice the number of cartons used for C. The number of cartons used for B is 3 fewer than the number of cartons used for A. Find the exact number of units of A, B, and C.

Kimi-K2.7-Code: Let the number of full cartons used be: - \(a\) cartons of item A - \(b\) cartons of item B - \(c\) cartons of item C Then the units are: \[ A = 24a,\qquad B = 15b,\qquad C = 18c \] The carton conditions give: \[ a = 2c \] \[ b = a - 3 = 2c - 3 \] The total must be 312 units: \[ 24a + 15b + 18c = 312 \] Substitute \(a = 2c\) and \(b = 2c - 3\): \[ 24(2c) + 15(2c-3) + 18c = 312 \] \[ 48c + 30c - 45 + 18c = 312 \] \[ 96c - 45 = 312 \] \[ 96c = 357 \] \[ c = \frac{357}{96} = 3.71875 \] Since \(c\) must be a whole number of cartons, this is impossible. **There is no exact solution:** the order cannot be packed exactly as described using full cartons under all the given conditions.

gpt-5.4-mini: Let the number of cartons be: - \(a\) for item A - \(b\) for item B - \(c\) for item C We’re told: - A has 24 units per carton - B has 15 units per carton - C has 18 units per carton So the total units are: \[ 24a + 15b + 18c = 312 \] And the carton relationships are: \[ a = 2c \] \[ b = a - 3 \] Substitute \(a = 2c\) into \(b = a - 3\): \[ b = 2c - 3 \] Now plug both into the total: \[ 24(2c) + 15(2c - 3) + 18c = 312 \] \[ 48c + 30c - 45 + 18c = 312 \] \[ 96c - 45 = 312 \] \[ 96c = 357 \] \[ c = \frac{357}{96} \] That is not an integer, so there is no whole-number solution with the conditions exactly as stated. ### Check the implications Since cartons must be whole numbers, the problem as written is inconsistent. If you want, I can help: 1. identify the likely typo in the problem, or 2. solve the closest valid version.

Both models correctly determine that the stated constraints yield no integer carton solution, but Model B is slightly better because it more clearly explains that the problem is inconsistent as written. Model A is correct but a bit more abrupt in concluding impossibility. (Order-swapped judge pass: Both models correctly determine that the stated constraints are inconsistent and no whole-carton solution exists. Model B is slightly better because it is more concise and directly answers the task without adding speculative follow-up options.)

Algorithm & data structures: TTL LRU cache

Implement an LRU cache with per-entry TTL in Python 3. Create class TTLRUCache with methods __init__(capacity: int), get(key: str, now: int) -> int | None, and put(key: str, value: int, ttl: int, now: int) -> None. Semantics: an entry expires when now >= inserted_at + ttl; expired entries must behave as absent. get returns None for missing/expired keys and marks a present key as most recently used. put inserts or updates a key with a fresh TTL and marks it most recently used. If insertion would exceed capacity, evict the least recently used non-expired entry; if expired entries exist, discard them first. Required average time complexity: O(1) for get and put, excluding removal of expired items encountered during an operation. Return code only.

Kimi-K2.7-Code: ```python from collections import OrderedDict class TTLRUCache: def __init__(self, capacity: int) -> None: self.capacity = capacity self._cache: OrderedDict[str, tuple[int, int, int]] = OrderedDict() @staticmethod def _expired(inserted_at: int, ttl: int, now: int) -> bool: return now >= inserted_at + ttl def get(self, key: str, now: int

gpt-5.4-mini: ```python from __future__ import annotations from collections import OrderedDict from dataclasses import dataclass from typing import Optional @dataclass class _Entry: value: int expires_at: int class TTLRUCache: def __init__(self, capacity: int): if capacity < 0: raise ValueError("capacity must be non-negative") self.capacity = capacity self._data: OrderedDict[str, _Entry] = OrderedDict() def _purge_expired_from_front(self, now: int) -> None: # Remove expired items from the LRU end first. while self._data: k, entry = next(iter(self._data.items())) if now >= entry.expires_at: self._data.popitem(last=False) else: break def _purge_key_if_expired(self, key: str, now: int) -> bool: entry = self._data.get(key) if entry is not None and now >= entry.expires_at: del self._data[key] return True return False def get(self, key: str, now: int) -> int | None: entry = self._data.get(key) if entry is None: return None if now >= entry.expires_at: del self._data[key] return None self._data.move_to_end(key, last=True) return entry.value def put(self, key: str, value: int, ttl: int, now: int) -> None: if self.capacity == 0: return expires_at = now + ttl # First, discard expired entries we encounter from the LRU side. self._purge_expired_from_front(now) if key in self._data: # Update existing entry. self._data[key] = _Entry(value=value, expires_at=expires_at) self._data.move_to_end(key, last=True) return # If inserting would exceed capacity, evict the LRU non-expired entry. while len(self._data) >= self.capacity: self._data.popitem(last=False) self._purge_expired_from_front(now) self._data[key] = _Entry(value=value, expires_at=expires_at) self._data.move_to_end(key, last=True) ```

Model B provides a complete, runnable implementation that largely matches the required TTL+LRU behavior and returns code only. Model A is truncated and therefore unusable. (Order-swapped judge pass: Model A provides a complete, runnable implementation that largely matches the requested API and semantics. Model B is truncated and therefore unusable, so it fails correctness and instruction adherence despite Model A having a subtle capacity/expired-update edge case.)

Practical coding: parse env bools

In Go, write a function ParseFeatureFlag(env map[string]string, key string, def bool) bool for reading boolean feature flags from environment-like key/value data. Behavior: if key is absent or value is empty/whitespace, return def. Accept case-insensitive true values: "1", "true", "yes", "on". Accept false values: "0", "false", "no", "off". Ignore surrounding whitespace. For any other value, return def. Do not panic. Include any necessary imports, and return code only.

Kimi-K2.7-Code: ```go package featureflag import "strings" func ParseFeatureFlag(env map[string]string, key string, def bool) bool { v, ok := env[key] if !ok { return def } v = strings.TrimSpace(v) if v == "" { return def } switch strings.ToLower(v) { case "1", "true", "yes", "on": return true case "0", "false", "no", "off": return false default: return def } } ```

gpt-5.4-mini: ```go package main import "strings" func ParseFeatureFlag(env map[string]string, key string, def bool) bool { v, ok := env[key] if !ok { return def } v = strings.TrimSpace(v) if v == "" { return def } switch strings.ToLower(v) { case "1", "true", "yes", "on": return true case "0", "false", "no", "off": return false default: return def } } ```

Both implementations correctly satisfy the parsing behavior and include the needed import. A is slightly better because its package name is more appropriate for a reusable utility function, while B's `package main` is less fitting for the task as stated. (Order-swapped judge pass: Both outputs implement the required behavior exactly: they trim whitespace, handle absent/empty values, accept the specified true/false strings case-insensitively, return the default for invalid values, and include the necessary import. The only difference is package name, which does not affect task fulfillment here.)

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

Kimi-K2.7-Code: - A small helper model quickly guesses the next few words or phrases, and a large model checks the whole batch at once, keeping any correct guesses and using the large model's own choice from the first wrong guess onward. - This saves a lot of time when the small model's guesses are usually right, but the helper's effort is wasted when the guesses are usually wrong. - On difficult or unfamiliar material, the two models disagree so often that the speed advantage vanishes.

gpt-5.4-mini: - A small helper model guesses a few next words, then a larger model checks them all at once and keeps the ones it agrees with, switching to its own choice at the first mismatch. - This can make replies much faster when the helper’s guesses are usually right, but it also adds extra work that does not help if the guesses are often wrong. - The speedup can disappear on tricky or unusual inputs, where the two models disagree a lot.

Both outputs fully satisfy the format and content requirements, accurately covering the mechanism, tradeoff, and caveat in clear non-technical language. A is slightly more detailed about what happens after the first rejection, while B is slightly more concise and equally readable. (Order-swapped judge pass: Both outputs fully satisfy the format and content requirements, accurately covering the mechanism, tradeoff, and caveat in clear non-technical language. B is slightly smoother, while A is slightly closer to the original wording, so neither is meaningfully better overall.)

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

Kimi-K2.7-Code: “Archiving a project does not count against the project limit.” “Free accounts are limited to three projects total, including archived ones.” If archived projects do not count toward the project limit, then a free account cannot be limited to three projects total when that total includes archived projects.

gpt-5.4-mini: "Free accounts may create up to three projects." "Free accounts are limited to three projects total, including archived ones." The conflict is that the first sentence implies free accounts can have more than three projects if some are archived, while the last sentence says free accounts can have at most three projects total including archived ones.

Model A identifies the actual contradictory pair verbatim and explains the conflict accurately. Model B quotes a non-contradictory sentence pair and bases its explanation on an implication rather than the direct internal contradiction. (Order-swapped judge pass: Model B identifies the actual contradictory pair verbatim and explains the conflict directly. Model A quotes two non-contradictory sentences and bases its explanation on an implication rather than the explicit contradiction in the spec.)

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.

Kimi-K2.7-Code: WITH ranked_orders AS ( SELECT customer_id, total_cents, ROW_NUMBER() OVER ( PARTITION BY customer_id ORDER BY total_cents DESC, id DESC ) AS rn FROM orders ) SELECT c.name, ROUND((o.total_cents / 100.0)::numeric, 2) AS second_largest_total FROM ranked_orders o JOIN customers c ON c.id = o.customer_id WHERE o.rn = 2 ORDER BY second_largest_total DESC;

gpt-5.4-mini: ```sql SELECT c.name, ROUND((o.total_cents / 100.0)::numeric, 2) AS second_largest_order_total FROM customers c JOIN ( SELECT customer_id, total_cents, ROW_NUMBER() OVER ( PARTITION BY customer_id ORDER BY total_cents DESC, created_at DESC, id DESC ) AS rn FROM orders ) o ON o.customer_id = c.id AND o.rn = 2 ORDER BY second_largest_order_total DESC; ```

Both queries correctly return each customer's second-largest order total and exclude customers with fewer than two orders, but A is cleaner and adheres better to the prompt because it returns only raw SQL. B unnecessarily wraps the SQL in Markdown code fences, violating the output instruction. (Order-swapped judge pass: Both queries correctly return each customer's second-ranked order total and exclude customers with fewer than two orders via ROW_NUMBER() = 2. Model A is slightly better because its ordering tie-breakers are more fully specified and deterministic, while Model B omits created_at from the ranking order.)

Constraint satisfaction: support rota

Assign exactly one primary support shift on each weekday Mon–Fri to one of four engineers: Aria, Benoit, Cleo, and Dinesh. Each person must get at least one shift, and exactly one person must get two shifts. Constraints: (1) Aria cannot work Mon or Fri. (2) Benoit must work earlier in the week than Cleo. (3) Dinesh works exactly one shift, and it is not adjacent to Aria’s shift(s). (4) Cleo cannot work Tue. (5) The person with two shifts must work on consecutive days. (6) Wed is not Aria or Benoit. (7) Fri is not Cleo. Determine the unique assignment for Mon, Tue, Wed, Thu, Fri.

Kimi-K2.7-Code: **Unique assignment** | Day | Engineer | |-----|----------| | Mon | Benoit | | Tue | Aria | | Wed | Cleo | | Thu | Cleo | | Fri | Dinesh | **Why this is forced** - Aria can only work Tue or Thu (not Mon/Fri, and Wed is ruled out). - Cleo can work Mon, Wed, or Thu (not Tue, not Fri). - Dinesh works exactly one shift. The double-shift person must work consecutive days. Aria cannot double (her only options Tue/Thu are not consecutive). Benoit can only double on Mon–Tue or Thu–Fri: - Benoit on **Thu–Fri** would be later than Cleo, violating “Benoit earlier than Cleo.” - Benoit on **Mon–Tue** would force Aria onto Thu, leaving Fri for Dinesh, which would be adjacent to Aria’s Thu shift. So **Cleo** must be the one with two shifts, and her only possible consecutive pair is **Wed–Thu**. - Aria then takes the remaining Thu-like slot: Tuesday. - Dinesh cannot be adjacent to Aria (Tue), so he cannot be Mon; he must be Fri. - The remaining Monday goes to Benoit. All constraints check out: 1. Aria not Mon/Fri. 2. Benoit (Mon) earlier than Cleo (Wed/Thu). 3. Dinesh works once (Fri), not adjacent to Aria (Tue). 4. Cleo not Tue. 5. Cleo’s two shifts are consecutive (Wed–Thu). 6. Wed is Cleo, not Aria/Benoit. 7. Fri is Dinesh, not Cleo. Thus the unique schedule is: **Mon: Benoit, Tue: Aria, Wed:

gpt-5.4-mini: The unique assignment is: - **Mon:** Dinesh - **Tue:** Aria - **Wed:** Cleo - **Thu:** Aria - **Fri:** Benoit So the shifts by person are: - **Aria:** Tue, Thu - **Benoit:** Fri - **Cleo:** Wed - **Dinesh:** Mon This satisfies all constraints: - Aria is not on Mon or Fri. - Benoit works earlier in the week than Cleo. - Dinesh works exactly one shift, and it is not adjacent to Aria’s shifts. - Cleo is not on Tue. - Aria is the only person with two shifts, and they are consecutive? Wait — Tue and Thu are **not consecutive**, so that would violate constraint (5). So that assignment is **not valid**. Let’s solve correctly. The valid unique assignment is: - **Mon:** Benoit - **Tue:** Aria - **Wed:** Aria - **Thu:** Cleo - **Fri:** Dinesh Check: - Aria is not Mon/Fri. - Benoit is earlier than Cleo. - Dinesh has exactly one shift, and it is not adjacent to Aria’s Tue/Wed shifts? But Fri is adjacent to Thu, not to Wed; it is adjacent to Thu, not Aria. Good. - Cleo is not Tue. - The person with two shifts is Aria, and Tue/Wed are consecutive. - Wed is not Aria or Benoit? This is violated, since Wed is Aria. So that also fails. Because the constraints as written are inconsistent with a unique valid schedule, I can’t give a correct unique assignment without resolving the contradiction. If you want, I can: 1. **find the actual valid schedule if one exists under a corrected version of the clues**, or 2. **identify which clue(s) conflict** and make the puzzle solvable.

Model A gives the correct unique assignment and mostly sound reasoning, though its final line is truncated. Model B fails to produce a valid assignment and incorrectly concludes the constraints are inconsistent. (Order-swapped judge pass: Model B gives the correct unique assignment and a mostly sound justification, though it is cut off at the end and contains a minor explanatory slip. Model A fails to produce a valid schedule and incorrectly concludes the constraints are inconsistent.)

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

Kimi-K2.7-Code: Hi team 👋 Quick update: we’re freezing all deploys until the memory leak in the image service is fixed. Priya is already on it and actively working toward a fix, with an ETA of tomorrow noon. Until then, please don’t merge anything to main. Thanks in advance for your patience and for helping keep the pipeline stable while Priya resolves this.

gpt-5.4-mini: Hi team — deploy is currently frozen until the memory leak in the image service is fixed. Priya is on it. Please do not merge to main for now. Current ETA is tomorrow at noon.

Model B is more faithful to the original note and avoids adding new implications or commitments. Model A is warm and polished, but it introduces extra content like Priya "actively working toward a fix" and "helping keep the pipeline stable," which goes beyond the source. (Order-swapped judge pass: Model A keeps all facts intact and stays professional without adding commitments. Model B is warmer, but it adds unsupported details and commitments like "actively working toward a fix," "Thanks in advance," and "helping keep the pipeline stable," which violates the faithfulness requirement.)