Head to head: grok-4.6 vs Codestral-2501

grok-4.6 vs Codestral-2501

By Ryan Merket · Published Aug 28, 2026, 9:19am CT

This wasn’t a close call. grok-4.6 dominated the practical workload, winning 29 tasks to 4 with a 95% confidence verdict and a massive aggregate-score gap.

grok-4.6 wins this matchup cleanly. The topline is brutal for Codestral-2501: **109.4 to 79.7** on aggregate score, with a **29–4 task record** and **95% confidence** behind the result. That is not a vibes-based edge or a narrow points decision; it’s a broad, repeatable advantage across the set. Where grok-4.6 separated itself was on the unglamorous stuff that actually matters: constraint handling, correctness, and format discipline. It repeatedly beat Codestral-2501 on both Python and JavaScript **LRU cache** tasks by meeting the required **O(1)** behavior while Codestral often reached for list operations or scans that broke the core requirement. It also kept winning on extraction and formatting-heavy work — the **shipping incident JSON** task, the **classification** task, the **project summary**, the **Mexican Spanish localization**, and the **constraint scheduling** puzzle — because it followed the brief tightly instead of drifting into code fences, extra prose, wrong labels, or invalid schedules. The pattern is even clearer in coding. On the **concurrency bug fix**, the models were effectively even: both fixed the race correctly, and all three versions landed as ties. But once the task demanded not just plausible code, but code that satisfied performance or output constraints exactly, grok-4.6 pulled away. Codestral-2501 repeatedly lost on avoidable violations: non-O(1) eviction logic, extra scaffolding when only a function was requested, markdown wrappers around strict JSON, and edge-case bugs like mishandling zero capacity. Codestral-2501 did have a real bright spot: it won the **faithful rewrite** task consistently, where its Slack-style prose came off warmer and more natural. It also stole one **Go slugify** variant, though that result was mixed across repeats and undercut by other runs where it violated the ASCII-only requirement or added unnecessary harness code. That’s not enough to change the overall read. Codestral showed occasional stylistic polish; grok-4.6 was the model you’d trust to actually satisfy the assignment. **Final call: grok-4.6 is the clear winner — substantially more reliable on correctness, stricter about constraints, and decisively better across the benchmark.**

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

grok-4.6: ```ts const cache = new Map<string, Promise<string>>(); async function load(key: string, fetcher: (k: string) => Promise<string>) { const hit = cache.get(key); if (hit) return hit; const promise = fetcher(key).catch((error) => { cache.delete(key); throw error; }); cache.set(key, promise); return promise; } ```

Codestral-2501: ```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 fetchPromise = fetcher(key).then( value => { cache.set(key, Promise.resolve(value)); return value; }, error => { cache.delete(key); throw error; } ); cache.set(key, fetchPromise); return fetchPromise; } ```

Model A and Model B both correctly store the in-flight promise before awaiting completion, preventing duplicate concurrent fetches, and both delete the cache entry on rejection so failures do not poison the cache. Model A is slightly simpler, while Model B is a bit more explicit, but both fully satisfy the prompt. (Second judge pass, order swapped — scores are the average of both: Model B and Model A both fix the race by storing the in-flight promise before awaiting, ensuring only one fetch per key, and both remove failed promises so rejections do not poison the cache. Model B is slightly more explicit about success handling, while Model A is simpler, but both fully satisfy the task.)

Python LRU cache

Write Python code only. Implement an `LRUCache` class with methods `get(key)` and `put(key, value)` and constructor `LRUCache(capacity: int)`. Requirements: both operations must be O(1) average time; evict the least recently used item when capacity is exceeded; updating an existing key must refresh its recency. Do not use `functools.lru_cache`. Use only the standard library.

grok-4.6: ```python from collections import OrderedDict class LRUCache: def __init__(self, capacity: int): self.capacity = capacity self._cache = OrderedDict() def get(self, key): if key not in self._cache: return -1 self._cache.move_to_end(key) return self._cache[key] def put(self, key, value): if key in self._cache: self._cache.move_to_end(key) self._cache[key] = value if len(self._cache) > self.capacity: self._cache.popitem(last=False) ```

Codestral-2501: ```python class LRUCache: def __init__(self, capacity: int): self.capacity = capacity self.cache = {} self.order = [] def get(self, key: int) -> int: if key in self.cache: # Move the accessed item to the end to mark it as recently used self.order.remove(key) self.order.append(key) return self.cache[key] return -1 def put(self, key: int, value: int) -> None: if key in self.cache: # Update the value and move the key to the end to mark it as recently used self.cache[key] = value self.order.remove(key) self.order.append(key) else: if len(self.cache) >= self.capacity: # Evict the least recently used item lru_key = self.order.pop(0) del self.cache[lru_key] # Add the new item to the cache and mark it as recently used self.cache[key] = value self.order.append(key) ```

Model A correctly uses OrderedDict from the standard library to achieve O(1) average-time get and put, refreshes recency on access/update, and evicts the least recently used item properly. Model B is readable but does not meet the O(1) requirement because list remove/pop(0) are O(n), so it fails a core constraint of the prompt. (Second judge pass, order swapped — scores are the average of both: Model A is better because it satisfies the required O(1) average-time operations using a standard-library OrderedDict and correctly refreshes recency on both get and put. Model B uses a list with remove and pop(0), which makes operations O(n) and therefore fails a core requirement despite otherwise implementing basic LRU behavior.)

Localize app notice to Mexican Spanish

Translate into Mexican Spanish for an in-app notice. Tone: friendly and clear, suitable for everyday users. Keep it to at most 26 words. Source: "We couldn't back up your photos last night because your phone was in battery saver mode. Plug it in and try again tonight."

grok-4.6: No pudimos respaldar tus fotos anoche porque tu celular estaba en modo ahorro de batería. Conéctalo y vuelve a intentarlo esta noche.

Codestral-2501: "Lo sentimos, no pudimos respaldar tus fotos anoche porque tu teléfono estaba en modo ahorro de batería. Conéctalo y vuelve a intentarlo esta noche."

Model A is concise, natural for Mexican Spanish, and stays within the 26-word limit while preserving the full meaning. Model B is also accurate and clear, but it exceeds the word limit and adds an unnecessary apology, making it less compliant with the instructions. (Second judge pass, order swapped — scores are the average of both: Model A is better localized for Mexican Spanish because "celular" sounds more natural than "teléfono" in this context, and it stays friendly and clear without adding extra wording. Model B is accurate, but "Lo sentimos" is unnecessary and makes the notice slightly less concise for an in-app message.)

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

grok-4.6: [{"text":"Fast shipping but the fabric feels cheap.","label":"mixed","reason":"Fast shipping, cheap fabric"},{"text":"Absolutely love it, wearing it daily!","label":"positive","reason":"Strong love and daily wear"},{"text":"It broke after a week. Refund was quick and painless though.","label":"mixed","reason":"Broke fast, refund easy"}]

Codestral-2501: ```json [ {"text": "Fast shipping but the fabric feels cheap.", "label": "mixed", "reason": "Fast shipping but fabric feels cheap."}, {"text": "Absolutely love it, wearing it daily!", "label": "positive", "reason": "Absolutely love it."}, {"text": "It broke after a week. Refund was quick and painless though.", "label": "negative", "reason": "It broke after a week."} ] ```

Model A is better because all three sentiment labels are appropriate and each reason stays within the six-word limit while remaining clear. Model B misclassifies the third review as negative instead of mixed and also wraps the output in a code block rather than returning only the JSON array. (Second judge pass, order swapped — scores are the average of both: Model A is better because it correctly classifies the third review as mixed, reflecting both the product failure and the positive refund experience. Model B follows the format well but makes that key sentiment error and also uses a first reason that exceeds the six-word limit.)

Customer delay apology email

Draft an email to a small-business customer, Maya Chen at Larkspur Studio, whose custom signage order is delayed because one powder-coat color failed inspection. Audience: customer. Tone: accountable, calm, professional; do not sound defensive. Length: 120–150 words. Must include: apology, plain-English cause, revised ship date of 22 September, assurance that the rest of the order passed QA, and a goodwill offer of free expedited shipping. Subject line required.

grok-4.6: **Subject:** Apology and update on your Larkspur Studio signage order Dear Maya Chen, I am writing to apologize for the delay in fulfilling your custom signage order. We take full responsibility. During quality inspection, one powder-coat color failed because the finish did not meet our standards for even coverage and color accuracy. We will not ship a piece that does not look and last as promised, so we are recoating that component now. The rest of the order passed QA completely and is ready to go. Our revised ship date is 22 September. To offset the inconvenience, we are offering free expedited shipping at no cost to you. Thank you for choosing us and for your understanding. Larkspur Studio’s project matters to us, and we will keep you updated if anything changes. Please contact me directly with questions. Sincerely, [Your name]

Codestral-2501: Subject: Update on Your Custom Signage Order - Delay Notification Dear Maya Chen, I hope this message finds you well. I am writing to inform you that there has been a slight delay in your custom signage order from Larkspur Studio. We regret any inconvenience this may cause. The delay is due to a technical issue with one of the powder-coat colors failing our quality assurance inspection. This is a rare occurrence, and we are actively working to resolve it. The rest of your order has passed our quality checks and is ready for shipment. We have revised the ship date to 22 September. As a token of our appreciation for your understanding and patience, we would like to offer you free expedited shipping on this order. Please let us know if there is anything else we can do to assist you. Thank you for your continued support. We value your business and look forward to serving you again in the future. Best regards, [Your Name] [Your Position] [Your Contact Information]

Model A better satisfies the brief with a clear apology, a plain-English explanation of the failed powder-coat finish, the revised 22 September ship date, confirmation that the rest passed QA, and the goodwill offer, all in an accountable, calm tone. Model B is solid but slightly less direct and more generic, and phrases like "technical issue" and "This is a rare occurrence" make it less plain-English and a bit more defensive than requested. (Second judge pass, order swapped — scores are the average of both: Model A better matches the requested accountable, calm, professional tone and explains the delay in clearer plain English without sounding defensive. Model B includes all required elements, but phrases like "This is a rare occurrence" and the more generic wording make it slightly less aligned with the brief.)

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.

grok-4.6: ```typescript class LRUCache<K, V> { private readonly capacity: number; private readonly map = new Map<K, V>(); constructor(capacity: number) { this.capacity = capacity; } get(key: K): V | undefined { if (!this.map.has(key)) return undefined; const value = this.map.get(key)!; this.map.delete(key); this.map.set(key, value); return value; } set(key: K, value: V): void { if (this.capacity <= 0) return; if (this.map.has(key)) this.map.delete(key); this.map.set(key, value); if (this.map.size > this.capacity) { this.map.delete(this.map.keys().next().value!); } } } ```

Codestral-2501: ```typescript class LRUCache<K, V> { private capacity: number; private cache: Map<K, V>; private usage: Map<K, number>; private timestamp: number; constructor(capacity: number) { this.capacity = capacity; this.cache = new Map<K, V>(); this.usage = new Map<K, number>(); this.timestamp = 0; } get(key: K): V | undefined { if (!this.cache.has(key)) { return undefined; } this.usage.set(key, ++this.timestamp); return this.cache.get(key); } set(key: K, value: V): void { if (this.cache.has(key)) { this.cache.set(key, value); this.usage.set(key, ++this.timestamp); return; } if (this.cache.size >= this.capacity) { let lruKey: K | undefined; let oldestTimestamp = Infinity; for (const [k, ts] of this.usage.entries()) { if (ts < oldestTimestamp) { oldestTimestamp = ts; lruKey = k; } } if (lruKey !== undefined) { this.cache.delete(lruKey); this.usage.delete(lruKey); } } this.cache.set(key, value); this.usage.set(key, ++this.timestamp); } } ```

Model A correctly implements LRU behavior in O(1) average time using Map insertion order, and it follows the instruction to return only the class. Model B does implement eviction logic, but eviction is O(n) due to scanning timestamps, so it fails the required O(1) set behavior. (Second judge pass, order swapped — scores are the average of both: Model A correctly achieves O(1) get and set by using Map insertion order to track recency, and it cleanly evicts the least-recently-used entry. Model B violates the O(1) requirement because eviction scans all entries, making set O(n) when at capacity.)

Constrained project summary

Write a project status summary that follows ALL rules exactly: - Exactly 4 bullet points - Each bullet begins with one of these tags in this order: `[Scope]`, `[Risk]`, `[Next]`, `[Ask]` - Each bullet is 11–15 words long - Total response under 90 words - Include the numbers `37%`, `11`, and `Q4` somewhere in the response - Do not use the words `delay`, `problem`, `issue`, or `urgent` - Context to summarize: migration of 11 retail kiosks to a new payment gateway is 37% complete; certificate renewal is the main risk; next milestone is pilot in Q4; team needs one security reviewer for two days.

grok-4.6: - [Scope] Migration of 11 retail kiosks to the new payment gateway is 37% complete now. - [Risk] Certificate renewal remains the primary risk for the payment gateway migration work. - [Next] The next milestone is a limited pilot of the new gateway in Q4. - [Ask] The team needs one security reviewer assigned for two days of review.

Codestral-2501: - `[Scope]` Migration of 11 retail kiosks to new payment gateway is 37% complete. - `[Risk]` Certificate renewal is the main risk. - `[Next]` Next milestone is pilot in Q4. - `[Ask]` Team needs one security reviewer for two days.

Model A better satisfies the constraints: it has exactly four bullets, uses the required tags in order, stays under 90 words, includes 37%, 11, and Q4, and each bullet appears to meet the 11–15 word requirement. Model B is concise and accurate, but several bullets are far under the required 11–15 words, so its instruction following is substantially weaker. (Second judge pass, order swapped — scores are the average of both: Model A better satisfies the strict length constraints: all four bullets appear to be within 11–15 words, while Model B has multiple bullets that are too short. Both are factually aligned and avoid banned words, but Model A follows the formatting and constraint requirements more completely and reads more smoothly.)

Extract shipping incident fields

Extract the requested facts from this messy note and return a single JSON object with keys exactly: incident_id, customer, callback_number, damaged_items, replacement_by, refund_amount_usd, address, tracking_numbers. Text: "Spoke w/ Nira Patel from Juniper Dental at 8:12a. Ref: INC-48271-B. She says 2 boxes arrived wet; contents damaged: 1x sterilization pouch roll 200m, 3x Sapphire bib clips. Please send replacements before Tue 14 May 2024 if possible. Refund approved for freight overcharge: $18.40. Call back on (312) 555-0189 ext 4 — but if unreachable use her cell 312.555.0190. Ship to: Juniper Dental, Attn Nira Patel, 1840 W Cermak Rd, Suite 2B, Chicago, IL 60608. Tracking stickers mentioned: 1Z9X44A20301984562 and 9405 5118 9956 1034 7712 88. Ignore prior draft with wrong ref INC-48217-B."

grok-4.6: { "incident_id": "INC-48271-B", "customer": "Juniper Dental", "callback_number": "(312) 555-0189 ext 4", "damaged_items": ["1x sterilization pouch roll 200m", "3x Sapphire bib clips"], "replacement_by": "2024-05-14", "refund_amount_usd": 18.4, "address": "Juniper Dental, Attn Nira Patel, 1840 W Cermak Rd, Suite 2B, Chicago, IL 60608", "tracking_numbers": ["1Z9X44A20301984562", "9405 5118 9956 1034 7712 88"] }

Codestral-2501: ```json { "incident_id": "INC-48271-B", "customer": "Juniper Dental", "callback_number": "(312) 555-0189 ext 4", "damaged_items": ["1x sterilization pouch roll 200m", "3x Sapphire bib clips"], "replacement_by": "Tue 14 May 2024", "refund_amount_usd": 18.40, "address": "Juniper Dental, Attn Nira Patel, 1840 W Cermak Rd, Suite 2B, Chicago, IL 60608", "tracking_numbers": ["1Z9X44A20301984562", "9405 5118 9956 1034 7712 88"] } ```

Model A better follows the likely normalization expected for extracted facts by converting the replacement deadline to an ISO-style date while preserving all requested fields accurately. Model B is also largely correct, but it wraps the JSON in a code fence and leaves the date less normalized, which is a weaker fit for a strict extraction task requesting a single JSON object. (Second judge pass, order swapped — scores are the average of both: Model A is slightly better because it normalizes the replacement date to an unambiguous ISO-style format while preserving all requested facts accurately. Model B is also highly accurate, but its date string is less standardized for downstream JSON use.)

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.

grok-4.6: 9: A 10: B 11: D 12: C Only AB@9-10 leaves a later non-12 slot for D while keeping C off 9.

Codestral-2501: To determine the valid schedule, we need to consider the given constraints: 1. A is before D. 2. C is not first. 3. B is immediately after A. 4. D is not at 12. Let's analyze these constraints step by step: 1. **A is before D**: This means A cannot be in the 12 slot. 2. **C is not first**: C cannot be in the 9 slot. 3. **B is immediately after A**: If A is in a slot, B must be in the next slot. 4. **D is not at 12**: D cannot be in the 12 slot. Given these constraints, let's try to find a valid schedule: - **Slot 9**: Cannot be C (C is not first). - **Slot 10**: Cannot be A (A is before D, and D cannot be at 12). - **Slot 11**: Cannot be D (D is not at 12). - **Slot 12**: Cannot be D (D is not at 12). Let's try placing A in the 9 slot: - **Slot 9**: A - **Slot 10**: B (B is immediately after A) Now, we need to place C and D: - **Slot 11**: C (C is not first, and B is already in the 10 slot) - **Slot 12**: D (D is not at 12, so it must be in the 11 slot) However, this placement violates the constraint that D is not at 12. Therefore, this schedule is not valid. Let's try placing A in the 10 slot: - **Slot 10**: A - **Slot 11**: B (B is immediately after A) Now, we need to place C and D: - **Slot 9**: C (C is not first) - **Slot 12**: D (D is not at 12) This schedule satisfies all the constraints: - A is before D. - C is not first. - B is immediately after A. - D is not at 12. Therefore, the valid schedule is: ``` 9: C 10: A 11: B 12: D ``` Justification: This schedule satisfies all the given constraints.

Model A gives the unique valid schedule and a concise justification that matches all constraints. Model B contradicts itself, ends with an invalid schedule placing D at 12 and C first, and does not follow the requested output format. (Second judge pass, order swapped — scores are the average of both: Model A gives the unique valid schedule and a concise justification that matches all constraints. Model B contradicts itself and presents an invalid schedule with D at 12 and C first, so it fails both correctness and instruction adherence.)

Slugify product titles in Go

Write Go code only. Implement `func SlugifyTitle(s string) string` for an e-commerce ingest service. Rules: lowercase; trim outer space; convert any run of spaces or underscores to a single `-`; remove all characters except ASCII letters, digits, and `-`; collapse repeated `-`; strip leading/trailing `-`. Examples: `" ACME__Bolt 3/8\" - Zinc " -> "acme-bolt-38-zinc"`, `"Kids' Rain_Jacket (Blue)" -> "kids-rain-jacket-blue"`, `"---" -> ""`.

grok-4.6: ```go package ingest import "strings" func SlugifyTitle(s string) string { s = strings.ToLower(strings.TrimSpace(s)) var b strings.Builder b.Grow(len(s)) pending := false started := false for i := 0; i < len(s); i++ { c := s[i] if (c >= 'a' && c <= 'z') || (c >= '0' && c <= '9') { if pending && started { b.WriteByte('-') } b.WriteByte(c) pending = false started = true continue } if c == ' ' || c == '_' || c == '-' { pending = true } } return b.String() } ```

Codestral-2501: ```go package main import ( "regexp" "strings" "unicode" ) func SlugifyTitle(s string) string { // Convert to lowercase s = strings.ToLower(s) // Trim outer spaces s = strings.TrimSpace(s) // Replace runs of spaces or underscores with a single '-' re := regexp.MustCompile(`[_\s]+`) s = re.ReplaceAllString(s, "-") // Remove all characters except ASCII letters, digits, and '-' var result strings.Builder for _, char := range s { if unicode.IsLetter(char) || unicode.IsDigit(char) || char == '-' { result.WriteRune(char) } } // Collapse repeated '-' re = regexp.MustCompile(`-+`) s = re.ReplaceAllString(result.String(), "-") // Strip leading/trailing '-' s = strings.Trim(s, "-") return s } func main() { // Test cases tests := []struct { input string expected string }{ {" ACME__Bolt 3/8\" - Zinc ", "acme-bolt-38-zinc"}, {"Kids' Rain_Jacket (Blue)", "kids-rain-jacket-blue"}, {"---", ""}, } for _, test := range tests { result := SlugifyTitle(test.input) if result != test.expected { println("Test failed:", test.input, "->", result, "expected:", test.expected) } else { println("Test passed:", test.input, "->", result) } } } ```

Model A is closer to the requested function-only Go solution and correctly handles the provided examples by treating spaces, underscores, and hyphens as separators while removing other punctuation. Model B violates the prompt by including a main function and comments/tests, and it is less correct because it allows non-ASCII letters despite the requirement to keep only ASCII letters, digits, and hyphens. (Second judge pass, order swapped — scores are the average of both: Model A better matches the required slug rules with a simple ASCII-only implementation that trims, lowercases, normalizes separators, removes disallowed characters, and avoids leading/trailing hyphens. Model B violates the ASCII-only requirement by using unicode letter/digit checks, includes extra code beyond the requested function, and produces the wrong result for inputs like "3/8\"" because it drops the slash without inserting a separator as required by the example.)

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.

grok-4.6: Convert the tank volume to liters: $0.9\,\mathrm{m}^3=900\,\mathrm{L}$. The pump rate is $3.5\,\mathrm{L}$ per $8\,\mathrm{s}$, so the fill time is \[ t=900\times\frac{8}{3.5}=\frac{14400}{7}\approx2057.142857\,\mathrm{s}. \] Convert to minutes: \[ 2057.142857=34\times60+17.142857, \] which rounds to $34$ minutes and $17$ seconds. 34:17

Codestral-2501: To solve this problem, we need to determine how long it will take to fill a 0.9 cubic meter tank with a pump that moves 3.5 liters every 8 seconds. ### Key Steps: 1. **Convert the tank volume to liters:** - 1 cubic meter = 1000 liters - Therefore, 0.9 cubic meters = 0.9 * 1000 liters = 900 liters 2. **Calculate the total time to fill the tank:** - The pump moves 3.5 liters every 8 seconds. - To find out how many 8-second intervals are needed to move 900 liters, we divide the total volume by the volume moved per interval: \[ \text{Total intervals} = \frac{900 \text{ liters}}{3.5 \text{ liters/interval}} = 257.14 \text{ intervals} \] 3. **Convert intervals to seconds:** - Each interval is 8 seconds. - Total time in seconds = 257.14 intervals * 8 seconds/interval = 2057.12 seconds 4. **Convert seconds to minutes and seconds:** - 1 minute = 60 seconds - Minutes = 2057.12 seconds / 60 seconds/minute = 34.2853 minutes - Seconds = (34.2853 minutes - 34 minutes) * 60 seconds/minute = 0.2853 * 60 seconds ≈ 17.12 seconds 5. **Round to the nearest second:** - 34 minutes and 17 seconds ### Final Answer: 34:17

Model A is slightly better because it is fully correct, concise, and follows the requested format closely by showing the key steps and then giving the final answer cleanly on its own line. Model B also gets the correct result, but it is more verbose than needed and introduces minor rounding imprecision in the intermediate interval calculation. (Second judge pass, order swapped — scores are the average of both: Model A is better because it is fully correct, concise, and follows the requested format by showing the key steps and then giving the final answer cleanly on its own line. Model B is also correct, but it is more verbose than needed and includes a slightly clunkier conversion sequence.)

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

grok-4.6: Hi team, I hope you're all having a good day. I'm writing to share a quick but important update with the entire engineering team. Deploy is frozen until the memory leak in the image service is fixed. Priya is on it. As a result, please do not merge to main. The ETA for this is tomorrow noon. Thank you all in advance for your understanding and cooperation on this. Your support in pausing merges and holding deploys helps us keep things stable. We truly value everyone's contributions.

Codestral-2501: Hey team, Just a heads-up: the deploy is currently on hold until we resolve the memory leak in the image service. Priya is working on it and we should have an update by tomorrow noon. Please avoid merging to main in the meantime. Thanks for your understanding!

Model B is warmer and more natural for Slack while preserving the key facts with minimal embellishment. Model A exceeds the 60–90 word limit and adds extra language that edges toward new implications, while Model B stays concise and professional despite slightly softening the exact ETA wording. (Second judge pass, order swapped — scores are the average of both: Model B is warmer and professional while preserving the core facts with only a slight softening of the ETA into an update expectation. Model A keeps the facts more literally but violates the 60–90 word limit and adds extra sentiment and implications beyond the note, so Model B is the better overall fit.)