Head to head: grok-4.6 vs Codestral-2501

grok-4.6 vs Codestral-2501

By Ryan Merket · Published Sep 19th, 2026, 9:44am CT

This matchup tests far more than coding: exact rewrites, proofreading, localization, structured extraction, SQL, JavaScript, Python, and strict instruction compliance all matter. The decisive question is whether either model can remain correct when formatting and edge cases are part of the task.

This was a rout. grok-4.6 posted a 106.2 aggregate score against Codestral-2501’s 62.1 and won all 24 tasks, with no ties. The statistical verdict confirms the result at limited confidence: this is a clear win, not noise at the margins. grok-4.6’s advantage was most obvious when correctness depended on respecting the entire specification. It hit exact word counts, preserved deployment details without inventing commitments, kept sentiment justifications within the required length, returned bare valid JSON, and produced localizations that actually met character and word limits. Codestral-2501 repeatedly delivered plausible prose while missing the governing constraint—too short, too long, over-bulleted, fenced when JSON-only was required, or subtly altered in meaning. The coding results were equally one-sided. grok-4.6 validated IPv4 octets and handled numeric-domain emails correctly, used `Map` insertion order for O(1) LRU operations, and avoided SQL join fan-out by aggregating sales and refunds separately. Codestral-2501 accepted invalid IPs, missed the email-domain edge case, used a linear eviction scan, inflated SQL aggregates, and failed to filter refunds by return date. There were minor blemishes in grok-4.6’s work—some repetitive phrasing, occasional unnecessary code fences, and a possible trailing-dot issue in the redaction regex—but none changed the matchup. Codestral-2501 was sometimes fluent and occasionally reached the right final answer, yet it too often treated explicit constraints as optional. **Final call: grok-4.6 wins decisively. The 24–0 sweep, 44.1-point aggregate margin, and limited confidence verdict leave no credible case for Codestral-2501 here.**

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 everyone — a friendly note for the whole engineering team. Deploy is frozen until the memory leak in the image service is fixed. Priya is on it. Please do not merge to main. ETA is tomorrow noon. Thank you for your patience and for not merging while this work is underway. We really appreciate the whole team staying aligned and supporting a clean path to the fix. Thanks, everyone.

Codestral-2501: Hey team, Just a heads-up: the deploy is currently on hold until we address 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 until then. Thanks for your understanding!

OpenAI: GPT-5.6 Sol Pro: Model A meets the 60–90-word requirement and preserves every fact, though the opening and closing are somewhat repetitive. Model B is polished but falls below the required length, weakens the merge prohibition, and changes the tomorrow-noon ETA into a promised update. (Second judge pass, order swapped — scores are the average of both: Model A preserves every fact, stays within the 60–90-word limit, and adds no commitments, though the opening and closing are somewhat repetitive. Model B is concis | Anthropic: Claude Fable 5.1: Model A preserves every fact exactly, adds…

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

grok-4.6: It's been a long time since we've seen their new office, and he and I were surprised how quiet it was. Its -> It's, we seen -> we've seen, there -> their, me and him -> he and I, was -> were, suprised -> surprised, quite -> quiet

Codestral-2501: Its been a long time since we seen there new office, and me and him was suprised how quite it was. was -> It's was -> since we've was -> there was -> him was -> surprised was -> quiet

OpenAI: GPT-5.6 Sol Pro: Model A correctly fixes all grammar, spelling, and punctuation errors and accurately lists each change. Model B leaves the sentence uncorrected and provides an inaccurate change list. (Second judge pass, order swapped — scores are the average of both: Model A correctly fixes every grammar, spelling, and punctuation error and accurately lists each change in the requested format. Model B leaves the original sentence uncorrected and provides an inaccurate change list whose source entries are mostly | Anthropic: Claude Fable 5.1: Model A correctly fixes every error (It's,…

Python log redaction function

In Python, write a function `redact_log(line: str) -> str` for application logs. Replace every email address with `[EMAIL]` and every IPv4 address with `[IP]`, but leave all other text unchanged. If an IP appears inside an email domain, redact the whole email as `[EMAIL]` and do not separately insert `[IP]` inside it. Preserve spacing and punctuation. Return code only.

grok-4.6: ```python import re _IPV4 = ( r'(?:25[0-5]|2[0-4]\d|[01]?\d\d?)' r'\.(?:25[0-5]|2[0-4]\d|[01]?\d\d?)' r'\.(?:25[0-5]|2[0-4]\d|[01]?\d\d?)' r'\.(?:25[0-5]|2[0-4]\d|[01]?\d\d?)' ) _EMAIL = ( r'[A-Za-z0-9._%+\-]+@' r'(?:[A-Za-z0-9.\-]+\.[A-Za-z]{2,}|' + _IPV4 + r'|\[\s*' + _IPV4 + r'\s*\])' ) _PATTERN = re.compile(rf'(?:{_EMAIL})|(?:{_IPV4})') def redact_log(line: str) -> str: def _repl(match: re.Match) -> str: return '[EMAIL]' if '@' in match.group(0) else '[IP]' return _PATTERN.sub(_repl, line) ```

Codestral-2501: ```python import re def redact_log(line: str) -> str: # Regex pattern for matching email addresses email_pattern = re.compile(r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b') # Regex pattern for matching IPv4 addresses ip_pattern = re.compile(r'\b(?:[0-9]{1,3}\.){3}[0-9]{1,3}\b') # Function to replace email addresses def replace_email(match): return '[EMAIL]' # Function to replace IPv4 addresses def replace_ip(match): return '[IP]' # First, replace email addresses to avoid IP inside email domains being replaced line = email_pattern.sub(replace_email, line) # Then, replace IPv4 addresses line = ip_pattern.sub(replace_ip, line) return line ```

OpenAI: GPT-5.6 Sol Pro: Model A prioritizes complete email matches, supports IPv4 email domains, and validates IPv4 octets. Model B misses emails whose domain is an IPv4 address and accepts invalid octets above 255, directly violating key requirements. (Second judge pass, order swapped — scores are the average of both: Model A is better because Model A validates IPv4 octets and matches an IPv4 email domain as part of the email before considering standalone IPs. Model B fails that explicit email-domain case and accepts | Anthropic: Claude Fable 5.1: Model A uses a single alternation with the…

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.map.has(key)) { this.map.delete(key); } else if (this.map.size >= this.capacity) { const lru = this.map.keys().next().value; if (lru !== undefined) this.map.delete(lru); } this.map.set(key, value); } } ```

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

OpenAI: GPT-5.6 Sol Pro: Model A uses Map insertion order to implement both access promotion and eviction in O(1), while Model B scans all usage records during eviction and therefore violates the required O(1) set complexity. Model A has minor edge-case issues for zero capacity and an undefined key, while both outputs also include code fences despite the request to return only the class. (Second judge pass, order swapped — scores are the average of both: Model A uses Map insertion order to provide expected O(1) access, | Anthropic: Claude Fable 5.1: Model A leverages Map insertion order to de…

Top-returning customers SQL

Schema: customers(customer_id, full_name) orders(order_id, customer_id, order_date) order_items(order_id, sku, quantity, unit_price) returns(return_id, order_id, return_date, refund_amount) Question: Write a single SQL query that returns the top 3 customers by return rate in 2025 among customers who placed at least 5 orders in 2025. Define return rate as total refunded amount in 2025 divided by total gross sales from their 2025 orders, rounded to 4 decimals. Return: customer_id, full_name, orders_2025, gross_sales_2025, refunded_2025, return_rate. Sort by return_rate descending, then customer_id ascending.

grok-4.6: ```sql WITH sales_2025 AS ( SELECT o.customer_id, COUNT(DISTINCT o.order_id) AS orders_2025, SUM(oi.quantity * oi.unit_price) AS gross_sales_2025 FROM orders o JOIN order_items oi ON oi.order_id = o.order_id WHERE o.order_date >= DATE '2025-01-01' AND o.order_date < DATE '2026-01-01' GROUP BY o.customer_id HAVING COUNT(DISTINCT o.order_id) >= 5 ), refunds_2025 AS ( SELECT o.customer_id, SUM(r.refund_amount) AS refunded_2025 FROM returns r JOIN orders o ON o.order_id = r.order_id WHERE r.return_date >= DATE '2025-01-01' AND r.return_date < DATE '2026-01-01' GROUP BY o.customer_id ) SELECT c.customer_id, c.full_name, s.orders_2025, s.gross_sales_2025, COALESCE(rf.refunded_2025, 0) AS refunded_2025, ROUND(COALESCE(rf.refunded_2025, 0) * 1.0 / s.gross_sales_2025, 4) AS return_rate FROM sales_2025 s JOIN customers c ON c.customer_id = s.customer_id LEFT JOIN refunds_2025 rf ON rf.customer_id = s.customer_id WHERE s.gross_sales_2025 <> 0 ORDER BY return_rate DESC, c.customer_id ASC FETCH FIRST 3 ROWS ONLY; ```

Codestral-2501: To achieve this, you need to perform several steps in your SQL query: 1. Calculate the total number of orders placed by each customer in 2025. 2. Filter customers who have placed at least 5 orders in 2025. 3. Calculate the total gross sales and total refunded amount for each of these customers in 2025. 4. Compute the return rate for each customer. 5. Select the top 3 customers by return rate. 6. Sort the results by return rate in descending order and then by customer ID in ascending order. Here is the SQL query that accomplishes this: ```sql WITH CustomerOrders AS ( SELECT c.customer_id, c.full_name, COUNT(o.order_id) AS orders_2025 FROM customers c JOIN orders o ON c.customer_id = o.customer_id WHERE YEAR(o.order_date) = 2025 GROUP BY c.customer_id, c.full_name HAVING COUNT(o.order_id) >= 5 ), CustomerSales AS ( SELECT co.customer_id, co.full_name, co.orders_2025, SUM(oi.quantity * oi.unit_price) AS gross_sales_2025, COALESCE(SUM(r.refund_amount), 0) AS refunded_2025 FROM CustomerOrders co JOIN orders o ON co.customer_id = o.customer_id JOIN order_items oi ON o.order_id = oi.order_id LEFT JOIN returns r ON o.order_id = r.order_id WHERE YEAR(o.order_date) = 2025 GROUP BY co.customer_id, co.full_name, co.orders_2025 ), CustomerReturnRate AS ( SELECT cs.customer_id, cs.full_name, cs.orders_2025, cs.gross_sales_2025, cs.refunded_2025, ROUND(cs.refunded_2025 / NULLIF(cs.gross_sales_2025, 0), 4) AS return_rate FROM CustomerSales cs ) SELECT cr.customer_id, cr.full_name, cr.orders_2025, cr.gross_sales_2025, cr.refunded_2025, cr.return_rate FROM CustomerReturnRate cr ORDER BY cr.return_rate DESC, cr.customer_id ASC LIMIT 3; ``` ### Explanation: 1. **CustomerOrders CTE**: This Common Table Expression (CTE) calculates the number of orders each customer placed in 2025 and filters out customers who have placed fewer than 5 orders. 2. **CustomerSales CTE**: This CTE calculates the total gross sales and total refunded amount for each customer in 2025. It joins the `CustomerOrders` CTE with the `orders`, `order_items`, and `returns` tables to get the necessary data. 3. **CustomerReturnRate CTE**: This CTE computes the return rate for each customer by dividing the total refunded amount by the total gross sales, rounded to 4 decimal places. 4. **Final SELECT**: The final query selects the required columns and orders the results by return rate in descending order and then by customer ID in ascending order. It limits the results to the top 3 customers. This query ensures that you get the top 3 customers by return rate in 2025 who have placed at least 5 orders in that year.

OpenAI: GPT-5.6 Sol Pro: Model A correctly aggregates sales and refunds separately, preventing join fan-out, and filters refunds by return date in 2025. Model B can multiply both sales and refunds when orders have multiple items or returns, and it does not filter refunds by return_date. (Second judge pass, order swapped — scores are the average of both: Model A correctly aggregates sales and refunds separately, filters refunds by return date, and avoids the many-to-many multiplication that can inflate both values in Mod | Anthropic: Claude Fable 5.1: Model A correctly aggregates gross sales a…

Memo with tight constraints

Write an internal memo about delaying the Q4 office move at Larkspur Analytics. Requirements: - Exactly 120 words total. - Use exactly 3 bullet points, each starting with "- ". - Start with the line: "To: Facilities Team" - Include these fields on separate lines before the bullets: "From: Maya Chen", "Date: 14 Nov 2026", "Subject: Revised move timeline" - Mention the new move date: 12 January 2027. - Include the numbers 18, 42, and 7. - Do not use the words "delay", "postpone", "sorry", or "apologize". - End with the exact sentence: "Please update vendor bookings by Friday."

grok-4.6: To: Facilities Team From: Maya Chen Date: 14 Nov 2026 Subject: Revised move timeline The Larkspur Analytics office move previously set for Q4 will now take place on 12 January 2027. Facilities should realign all logistics with this date so operations remain smooth. Leadership confirmed this schedule after reviewing capacity, vendor availability, and staff feedback across sites. Please brief floor captains and share the revised checklist with every department so packing starts on time and the IT cutover remains fully coordinated. - Coordinate 18 movers for packing, labeling, and transport of core equipment. - Reserve 42 workstations and related furniture for the new floor layout. - Confirm 7 loading dock windows with building management before year end. Please update vendor bookings by Friday.

Codestral-2501: To: Facilities Team From: Maya Chen Date: 14 Nov 2026 Subject: Revised move timeline - The Q4 office move has been rescheduled to 12 January 2027. - This change is due to 18 new projects requiring additional space, impacting our current plans. - We anticipate 42 additional staff and 7 new vendors to accommodate these projects. Please update vendor bookings by Friday.

OpenAI: GPT-5.6 Sol Pro: Model A satisfies every constraint, including the exact 120-word count, three bullets, required fields, specified numbers and date, prohibited-word restriction, and exact closing sentence. Model B is clear and includes most required content, but it is far short of 120 words and introduces unsupported operational details. (Second judge pass, order swapped — scores are the average of both: Model A satisfies the exact 120-word requirement and all other formatting, content, and vocabulary constraint | Anthropic: Claude Fable 5.1: Model A hits exactly 120 words, uses exact…

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.

grok-4.6: Todo listo — tu primer backup empieza esta noche (48)

Codestral-2501: "Todo listo — tu primera copia de seguridad comienza esta noche." (68)

OpenAI: GPT-5.6 Sol Pro: Model A is natural, friendly, correctly counted at 48 characters, and follows the length and formatting constraints, though “backup” is a mild Anglicism. Model B uses standard Spanish terminology but exceeds 60 characters, adds quotation marks, and gives an incorrect character count. (Second judge pass, order swapped — scores are the average of both: Model A stays under 60 characters and reports the count correctly, though “backup” is a less localized choice than “copia de seguridad.” Model B is | Anthropic: Claude Fable 5.1: Model A delivers a friendly, toast-appropr…

Support-ticket sentiment labels

Classify each support-ticket message as one of: Positive, Neutral, Negative, Urgent. For each item, give a label and a justification of 6-10 words. Return exactly one line per item in this format: `<id> | <label> | <justification>` Items: A1: "Thanks, the export worked after I retried." A2: "Our clinic can't print wristband labels at check-in. Patients are already waiting." A3: "Can you confirm whether plan Aurora includes SAML?" A4: "This billing mistake happened again, and I'm tired of chasing refunds." A5: "All good now — the barcode scanner connected immediately."

OpenAI: GPT-5.6 Sol Pro: Model A provides correct labels, clear justifications, and satisfies the required 6–10-word length for every item. Model B labels correctly but every justification is fewer than six words, violating a central instruction. (Second judge pass, order swapped — scores are the average of both: Model A provides correct labels, clear justifications, and meets the required 6–10-word limit for every item. Model B labels correctly but every justification is too short.) | Anthropic: Claude Fable 5.1: Both entries assign the same correct labels, but Model A meets the required 6-1…

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 fill time in seconds is \[ \frac{900}{3.5}\times 8=\frac{7200}{3.5}=2057+\frac{1}{7}\approx 2057.142857\,\mathrm{s}. \] Convert to minutes and seconds: \[ 2057.142857=34\times 60+17.142857. \] The fractional second rounds to \(17\), giving \(34:17\). 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 volume of the tank 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 the number of intervals to total seconds:** - Each interval is 8 seconds, so: \[ \text{Total seconds} = 257.14 \text{ intervals} \times 8 \text{ seconds/interval} = 2057.12 \text{ seconds} \] 4. **Convert the total seconds to minutes and seconds:** - There are 60 seconds in a minute, so: \[ \text{Minutes} = \left\lfloor \frac{2057.12}{60} \right\rfloor = 34 \text{ minutes} \] \[ \text{Remaining seconds} = 2057.12 - (34 \times 60) = 2057.12 - 2040 = 17.12 \text{ seconds} \] - Rounding 17.12 seconds to the nearest second gives us 17 seconds. ### Final Answer: 34:17

OpenAI: GPT-5.6 Sol Pro: Model A is exact, concise, and fully follows the requested format. Model B reaches the correct answer and follows the instructions, but prematurely rounds the interval count, causing a small intermediate numerical error that does not affect the final result. (Second judge pass, order swapped — scores are the average of both: Model A is concise and preserves exact arithmetic through the calculation. Model B reaches the correct result but prematurely rounds the interval count, producing the slight | Anthropic: Claude Fable 5.1: Both arrive at the correct 34:17, but Mode…

Proofread incident update

Correct the passage below for grammar, style, and clarity without changing meaning. Then add 2 brief bullet points noting the main changes. Passage: "Yesterday evening the payment API was intermittently failing, which caused some orders to not complete and support was getting a unusually high number of chats. The issue were traced to a config change on node 3, after rollback error rates dropped quickly. We will monitor through monday morning and send another update if anything changes, customers who retried later was generally successful."

grok-4.6: **Corrected passage:** Yesterday evening, the payment API was intermittently failing, which caused some orders not to complete and led support to receive an unusually high number of chats. The issue was traced to a config change on node 3; after rollback, error rates dropped quickly. We will monitor through Monday morning and send another update if anything changes. Customers who retried later were generally successful. **Main changes:** - Fixed subject–verb agreement (`issue were` → `was`; `customers … was` → `were`) and the article (`a unusually` → `an unusually`). - Split run-on sentences, added needed punctuation, and capitalized `Monday` for clearer, more professional flow.

Codestral-2501: "Yesterday evening, the payment API was intermittently failing, causing some orders to not complete and support to receive an unusually high number of chats. The issue was traced to a configuration change on node 3. After rolling back the change, error rates dropped quickly. We will monitor through Monday morning and send another update if anything changes. Customers who retried later were generally successful." **Main Changes:** - Added commas for better readability. - Changed "were traced" to "was traced" for grammatical correctness. - Changed "after rollback" to "After rolling back" for better flow. - Changed "through monday morning" to "through Monday morning" for capitalization. - Changed "customers who retried later was generally successful" to "Customers who retried later were generally successful" for grammatical correctness.

OpenAI: GPT-5.6 Sol Pro: Model A provides a polished, meaning-preserving correction and follows the requirement to add exactly two brief bullet points. Model B is generally accurate, but it supplies five bullets instead of two and introduces a dangling modifier in “After rolling back the change, error rates dropped quickly.” (Second judge pass, order swapped — scores are the average of both: Model A provides a clear, grammatically correct revision and follows the explicit requirement to add exactly two brief bullet poin | Anthropic: Claude Fable 5.1: Model A produces a clean, correct revision…

Polished Mexican Spanish localization

Translate this product message into Mexican Spanish for a friendly but professional app notification. Keep the meaning and nuance, avoid sounding literal, and use 24-30 words total. Text: "Your trial ends tomorrow. If you do nothing, your workspace will switch to read-only mode, but your files will stay safe for 90 days."

grok-4.6: Tu prueba termina mañana. Si no haces nada, tu espacio de trabajo cambiará a modo de solo lectura, pero tus archivos se mantendrán seguros durante 90 días.

Codestral-2501: "Tu prueba termina mañana. Si no haces nada, tu espacio de trabajo cambiará a modo de solo lectura, pero tus archivos estarán seguros por 90 días."

OpenAI: GPT-5.6 Sol Pro: Model A conserva mejor el matiz de que los archivos seguirán protegidos y cumple con el límite de 27 palabras. Model B también es correcto y natural, pero «estarán seguros» pierde ligeramente esa continuidad y las comillas son innecesarias. (Second judge pass, order swapped — scores are the average of both: Model A better preserves the nuance of “will stay safe” with “se mantendrán seguros” and sounds slightly more polished. Model B is accurate and meets the word-count requirement, but “estarán | Anthropic: Claude Fable 5.1: Both renderings are accurate, natural Mexic…

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

grok-4.6: [{"title":"Standup","day":"Daily","start24":"09:00","durationMinutes":15},{"title":"Design Review","day":"Thursday","start24":"14:30","durationMinutes":90},{"title":"Payroll Sync","day":"First Monday","start24":"11:00","durationMinutes":60}]

Codestral-2501: ```json [ {"title":"Standup","day":"Daily","start24":"09:00","durationMinutes":15}, {"title":"Design Review","day":"Thursday","start24":"14:30","durationMinutes":90}, {"title":"Payroll Sync","day":"First Monday","start24":"11:00","durationMinutes":120} ] ```

OpenAI: GPT-5.6 Sol Pro: Model A correctly extracts all meetings, including the 60-minute Payroll Sync, and returns only valid JSON. Model B incorrectly gives Payroll Sync a 120-minute duration and wraps the array in a Markdown code fence, violating the strict JSON requirement. (Second judge pass, order swapped — scores are the average of both: Model B incorrectly assigns 120 minutes to the 11:00-to-noon meeting and wraps the response in Markdown fences, violating the strict JSON-only requirement. Model A correctly extr | Anthropic: Claude Fable 5.1: Model A correctly extracts all three meeti…