Head to head: gpt-oss-120b vs cohere-command-a

gpt-oss-120b vs cohere-command-a

This wasn’t a stylistic squeaker; it was a broad, repeatable win. gpt-oss-120b beat cohere-command-a across instruction-heavy, format-sensitive, and reasoning tasks, with a decisive 99% confidence edge.

gpt-oss-120b takes this matchup cleanly: **102.5 to 80.1, with a 99% confidence verdict**, and a **10–2 task win split**. That margin matters because it wasn’t built on one flashy outlier. Model A kept winning in the unglamorous places that separate reliable production behavior from demo-friendly competence: strict JSON output, exact proofreading diffs, contradiction finding, localization tone control, and bug-fix tasks where permissive parsing or sloppy formatting gets you in trouble fast. The pattern is simple: **gpt-oss-120b followed directions better and made fewer costly mistakes**. It returned plain JSON when asked instead of hiding valid content inside code fences. It handled the JavaScript currency parser more correctly by rejecting malformed inputs that `parseFloat` would wrongly accept. It wrote the vendor-delay update with all required facts, including the vendor name, and it produced tighter, more natural microcopy in the Spanish localization task. Even where both models were substantively correct—support ticket triage, unit-aware math—Model A was usually cleaner and more precise in format and presentation. Cohere-command-a’s losses weren’t cosmetic. In the clinic scheduling task it violated key constraints; in contradiction detection it identified the wrong pair; in SQL it buried an at-least-plausible answer under commentary despite being told to return one query only. That’s the recurring issue in this head-to-head: Model B often looked capable, but too often it **failed the assignment as given**. For users who care about exact output contracts, that is not a minor defect—it is the product. To be fair, cohere-command-a did take two categories. It was the better fit on the Python log-redaction helper once instruction-following penalties were counted against Model A’s fenced/extraneous output, and it also won the Polish localization task by staying closer to the requested length and source meaning. But those are isolated wins, not signs of a balanced contest. **Final call: gpt-oss-120b is the clear winner.** Not because it is more verbose or more polished in the abstract, but because across this suite it was the model you could trust to do the job requested, in the format requested, without introducing avoidable errors.

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

gpt-oss-120b: It's been a long time since we saw their new office, and he and I were surprised how quiet it was. Its -> It's; seen -> saw; there -> their; me and him -> he and I; was -> were; suprised -> surprised; quite -> quiet.
cohere-command-a: "It's been a long time since we saw their new office, and he and I were surprised how quiet it was." - Its -> It's - been -> been (no change) - seen -> saw - there -> their - new -> new (no change) - office, -> office, (no change) - and -> and (no change) - me -> I - and -> and (no change) - him -> he - was -> were - suprised -> surprised - quite -> quiet - it -> it (no change) - was. -> was. (no change)

Model A is better because it cleanly corrects the sentence and lists only actual changes, closely matching the requested format. Model B makes the same core corrections but adds quotation marks not present in the original and includes many unchanged tokens, which does not follow the instruction to list each change as 'was -> now'. (Second judge pass, order swapped — scores are the average of both: Model A is better because it provides the corrected sentence and a concise list of actual changes, while Model B adds many unnecessary 'no change' items that do not match the requested format. Both models make the same substantive corrections, but Model A follows the instruction to list each change more cleanly and precisely.)

Clinic on-call schedule

Assign exactly one person to each shift and use each person exactly once. People: Nora, Imran, Celia, Mateo Shifts: Mon AM, Mon PM, Tue AM, Tue PM Constraints: - Nora cannot do any PM shift. - Imran cannot do Mon AM. - Celia must work immediately before Mateo in time order. - Tue AM must be Nora or Imran. - Mateo cannot do Tue PM. Return only the final assignment as four lines in this format: "Mon AM: Name" etc.

gpt-oss-120b: Mon AM: Celia Mon PM: Mateo Tue AM: Nora Tue PM: Imran
cohere-command-a: Mon AM: Imran Mon PM: Celia Tue AM: Nora Tue PM: Mateo

Model A satisfies all constraints: each person is used exactly once, Nora is on a non-PM shift, Imran is not on Mon AM, Celia is immediately before Mateo, Tue AM is Nora, and Mateo is not on Tue PM. Model B violates multiple constraints, including assigning Mateo to Tue PM and failing to place Celia immediately before Mateo in time order. (Second judge pass, order swapped — scores are the average of both: Model B and Model A both violate key scheduling constraints, so neither is better overall. Model B assigns Mateo to Tue PM despite that being forbidden, while Model A fails the requirement that Celia must work immediately before Mateo in time order.)

Support ticket triage labels

Classify each incoming support line into exactly one category: Billing, Bug, Feature Request, Account Access, or Shipping. For each, give a 4-8 word justification. Return a JSON array of objects with keys id, category, justification. Items: 1) "I was charged twice for order QN-1842 after the page froze." 2) "Please add a dark-mode toggle to the kiosk dashboard." 3) "Reset link says expired the moment I click it." 4) "Package for invoice 7719 still shows 'label created' after 9 days." 5) "Exporting March leads from AtlasCRM gives a blank CSV in Firefox 127." 6) "Can you switch our plan from annual to monthly starting next cycle?"

gpt-oss-120b: [ { "id": 1, "category": "Billing", "justification": "Duplicate charge caused by page freeze" }, { "id": 2, "category": "Feature Request", "justification": "Add dark-mode toggle to dashboard" }, { "id": 3, "category": "Account Access", "justification": "Password reset link expires instantly" }, { "id": 4, "category": "Shipping", "justification": "Shipment stuck at label created status" }, { "id": 5, "category": "Bug", "justification": "Export produces empty CSV in Firefox" }, { "id": 6, "category": "Billing", "justification": "Change subscription from annual to monthly" } ]
cohere-command-a: ```json [ { "id": 1, "category": "Billing", "justification": "Double charge reported for specific order." }, { "id": 2, "category": "Feature Request", "justification": "Request for new UI feature addition." }, { "id": 3, "category": "Account Access", "justification": "Password reset link functionality issue." }, { "id": 4, "category": "Shipping", "justification": "Package status stagnant for extended period." }, { "id": 5, "category": "Bug", "justification": "Software export function fails in specific browser." }, { "id": 6, "category": "Billing", "justification": "Request to change subscription billing cycle." } ] ```

Model A and Model B both classify all six items correctly, but Model A follows the requested output format more cleanly by returning plain JSON rather than a fenced code block. Model A’s justifications are also slightly more specific and directly tied to each ticket while staying within the 4–8 word limit. (Second judge pass, order swapped — scores are the average of both: Model B and Model A both classify all six items correctly and provide valid JSON with 4–8 word justifications. Model A is slightly better because its justifications are more specific and directly grounded in each support line, while Model B is a bit more generic in places.)

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

gpt-oss-120b: [ { "title": "Standup", "day": "Daily", "start24": "09:00", "durationMinutes": 15 }, { "title": "Design Review", "day": "Thursday", "start24": "14:30", "durationMinutes": 90 }, { "title": "Payroll Sync", "day": "Monday", "start24": "11:00", "durationMinutes": 60 } ]
cohere-command-a: ```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": 60 } ] ```

Model A better follows the requirement to return only valid JSON, while Model B incorrectly wraps the JSON in a code fence. Model B is slightly more faithful on the day field by preserving "First Monday," but the formatting violation makes Model A the better overall answer. (Second judge pass, order swapped — scores are the average of both: Model A is better because it returns only valid JSON and correctly extracts the meetings and times; Model B includes Markdown code fences, which violates the instruction to return only JSON. Model B is slightly more faithful in preserving "First Monday," but the formatting error makes Model A the stronger overall response.)

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.

gpt-oss-120b: **Key steps** 1. Convert tank volume to liters: \(0.9\ \text{m}^3 = 0.9 \times 1000 = 900\ \text{L}\). 2. Determine the pump’s flow rate: \(\displaystyle \frac{3.5\ \text{L}}{8\ \text{s}} = \frac{3.5}{8}=0.4375\ \text{L/s}\). 3. Compute the time required: \[ t = \frac{\text{total volume}}{\text{flow rate}} = \frac{900\ \text{L}}{0.4375\ \text{L/s}} = \frac{900}{0.4375}\ \text{s} = \frac{900}{7/16}\ \text{s}=900 \times \frac{16}{7}\ \text{s}= \frac{14400}{7}\ \text{s}\approx 2057.14\ \text{s}. \] 4. Convert seconds to minutes‑seconds: \[ 2057.14\ \text{s}= 34\ \text{min} + 17.14\ \text{s}\approx 34\ \text{min}\ 17\ \text{s}. \] **Final answer** 34:17
cohere-command-a: To determine how long it takes to fill the tank, we need to follow these steps: 1. **Convert the tank volume to liters:** \[ 0.9 \text{ cubic meters} = 0.9 \times 1000 \text{ liters} = 900 \text{ liters} \] 2. **Determine the pump's rate in liters per second:** \[ \text{Rate} = \frac{3.5 \text{ liters}}{8 \text{ seconds}} = 0.4375 \text{ liters/second} \] 3. **Calculate the total time in seconds to fill the tank:** \[ \text{Time (seconds)} = \frac{900 \text{ liters}}{0.4375 \text{ liters/second}} = 2057.142857 \text{ seconds} \] 4. **Convert the total time to minutes and seconds:** \[ \text{Minutes} = \left\lfloor \frac{2057.142857}{60} \right\rfloor = 34 \text{ minutes} \] \[ \text{Remaining seconds} = 2057.142857 - (34 \times 60) = 2057.142857 - 2040 = 17.142857 \text{ seconds} \] 5. **Round the remaining seconds to the nearest second:** \[ 17.142857 \approx 17 \text{ seconds} \] Thus, the time to fill the tank is: \[ \boxed{34:17} \]

Model A and Model B both compute the conversion and fill time correctly and both give the final answer as 34:17. Model A is slightly more concise while Model B is slightly more explicit, but both follow the instructions well and are equally strong overall. (Second judge pass, order swapped — scores are the average of both: Model A is slightly better because it is fully correct, concise, and follows the requested format more cleanly by showing key steps and then giving the final answer on its own line. Model B is also correct, but it is a bit more verbose and its final answer is embedded in explanatory text rather than presented as cleanly.)

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

gpt-oss-120b: **Conflicting sentences** 1. “Archiving a project does not count against the project limit.” 2. “Free accounts are limited to three projects total, including archived ones.” **Explanation:** The first sentence says archived projects are excluded from the limit, while the second says archived projects are included in the three‑project cap for free accounts, creating a direct contradiction.
cohere-command-a: **Conflicting Sentences:** 1. "Free accounts may create up to three projects." 2. "Free accounts are limited to three projects total, including archived ones." **Explanation:** The first sentence implies that free accounts can create up to three active projects, while the second sentence states that free accounts are limited to three projects in total, including archived ones, which contradicts the idea that archiving does not count against the project limit.

Model A identifies the actual contradictory pair verbatim and explains the conflict accurately in one sentence. Model B quotes a non-contradictory pair and relies on an unquoted third sentence in its explanation, so it is less correct and follows the task less precisely. (Second judge pass, order swapped — scores are the average of both: Model A identifies the actual contradictory pair verbatim and explains the conflict directly. Model B quotes a non-contradictory sentence as one half of the pair and relies on an unquoted third sentence in its explanation, so it is less correct and less faithful to the task.)

Vendor delay status update

Draft a Slack status update to the operations team. Audience: internal coworkers. Tone: calm, direct, accountable. Length: 80-110 words. Facts to include: - Vendor: Pine Metric - Issue: overnight inventory sync failed for 14 store locations - Cause: expired API certificate discovered at 06:40 - Current workaround: manual CSV imports started at 07:15 - Risk: dashboards may show stale counts until about noon - Next update promised by 10:30 - Do not blame the vendor or sound alarmist.

gpt-oss-120b: Team, a quick heads‑up on the inventory sync for Pine Metric. The overnight sync failed for 14 store locations after we discovered an expired API certificate at 06:40. We started manual CSV imports at 07:15 as a temporary workaround. Until the imports finish, dashboards may display stale counts, likely through around noon. I’ll monitor the process and provide a full update by 10:30. Thanks for your patience—please let me know if you notice any discrepancies in the meantime. We are also coordinating with Pine Metric to renew the certificate and prevent recurrence.
cohere-command-a: **Status Update: Inventory Sync Issue** The overnight inventory sync for 14 store locations failed due to an expired API certificate, identified at 06:40. As a workaround, manual CSV imports began at 07:15 to ensure data continuity. Dashboards may display stale counts until approximately noon. We’re working to resolve the root cause and will provide a detailed update by 10:30. For now, operations can proceed with the manual imports in place. No need to escalate further at this time. Thanks for your patience and understanding. Let me know if you have questions.

Model A is better because it includes all required facts, names Pine Metric explicitly, and maintains a calm, accountable internal status-update tone within the requested length. Model B is clear and well written, but it omits the vendor name and adds slightly awkward phrasing about operations proceeding with manual imports, which weakens correctness and fit. (Second judge pass, order swapped — scores are the average of both: Model A is better because it includes all required facts, explicitly names Pine Metric, and reads more naturally as a Slack update while keeping a calm, accountable tone. Model B is solid but omits the vendor name and adds slightly awkward or unnecessary phrasing like "No need to escalate further at this time" and "Let me know if you have questions.")

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.

gpt-oss-120b: Listo, la primera copia arrancará esta noche. (45)
cohere-command-a: Todo listo, tu primera copia de seguridad comienza esta noche. (57)

Model A is shorter, natural for a mobile toast, and stays comfortably under the 60-character limit while preserving the meaning. Model B is also accurate and compliant, but it sounds more verbose and less toast-like for onboarding microcopy. (Second judge pass, order swapped — scores are the average of both: Model A is more natural and concise for a friendly mobile toast in European Spanish, and it stays comfortably under the limit with an accurate character count. Model B is understandable but sounds more literal and slightly less toast-like, and its stated character count appears incorrect.)

JavaScript currency parser fix

Review this JavaScript function. It should convert human-entered prices like "$1,299.50", "19.99", or "€08" into numbers, and return null for invalid inputs. It currently has a subtle bug. Find the bug, fix it, and return only the corrected code. ```js function parsePrice(input) { if (!input) return null; const cleaned = input.replace(/[$€,\s]/g, ''); const value = parseInt(cleaned, 10); return Number.isNaN(value) ? null : value; } ```

gpt-oss-120b: ```js function parsePrice(input) { if (!input) return null; const cleaned = input.replace(/[$€,\s]/g, ''); if (!cleaned) return null; // nothing left after cleaning const value = Number(cleaned); // parses integers and decimals return Number.isNaN(value) ? null : value; } ```
cohere-command-a: ```js function parsePrice(input) { if (!input) return null; const cleaned = input.replace(/[$€,\s]/g, ''); const value = parseFloat(cleaned); // Use parseFloat to handle decimals return Number.isNaN(value) ? null : value; } ```

Model A better fixes the bug by using Number so the entire cleaned string must be a valid numeric value, which correctly returns null for malformed inputs like "12abc"; it also guards against an empty cleaned string. Model B improves decimal handling but parseFloat still accepts invalid trailing characters, so it is less correct for the requirement to return null for invalid inputs. (Second judge pass, order swapped — scores are the average of both: Model A is better because it fixes the decimal-parsing bug while also correctly rejecting inputs that become empty after cleaning and avoiding parseFloat's permissive partial parsing of malformed strings. Model B addresses the main bug but can still accept invalid inputs like an empty cleaned string or partially numeric text, so it is less correct overall.)

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.

gpt-oss-120b: ```sql SELECT c.name, ROUND(o.total_cents / 100.0, 2) AS second_largest_order_total FROM ( SELECT customer_id, total_cents, DENSE_RANK() OVER (PARTITION BY customer_id ORDER BY total_cents DESC) AS rnk FROM orders ) o JOIN customers c ON c.id = o.customer_id WHERE o.rnk = 2 -- second‑largest distinct total per customer ORDER BY second_largest_order_total DESC; ```
cohere-command-a: ```sql WITH ranked_orders AS ( SELECT c.name, o.total_cents / 100.0 AS total_dollars, ROW_NUMBER() OVER (PARTITION BY c.id ORDER BY o.total_cents DESC) AS row_num FROM customers c JOIN orders o ON c.id = o.customer_id ), filtered_ranked_orders AS ( SELECT name, total_dollars FROM ranked_orders WHERE row_num = 2 ), customer_order_counts AS ( SELECT customer_id, COUNT(*) AS order_count FROM orders GROUP BY customer_id HAVING COUNT(*) >= 2 ) SELECT f.name, f.total_dollars FROM filtered_ranked_orders f JOIN customer_order_counts c ON f.name = (SELECT name FROM customers WHERE id = c.customer_id) ORDER BY f.total_dollars DESC; ``` However, a more efficient and correct version would be: ```sql WITH customer_order_counts AS ( SELECT customer_id, COUNT(*) AS order_count FROM orders GROUP BY customer_id HAVING COUNT(*) >= 2 ), ranked_orders AS ( SELECT c.name, o.total_cents / 100.0 AS total_dollars, ROW_NUMBER() OVER (PARTITION BY c.id ORDER BY o.total_cents DESC) AS row_num FROM customers c JOIN orders o ON c.id = o.customer_id WHERE c.id IN (SELECT customer_id FROM customer_order_counts) ) SELECT name, ROUND(total_dollars, 2) AS total_dollars FROM ranked_orders WHERE row_num = 2 ORDER BY total_dollars DESC; ``` An even more concise and efficient version would be: ```sql SELECT c.name, ROUND((o.total_cents / 100.0), 2) AS second_largest_order FROM ( SELECT customer_id, NTH_VALUE(total_cents, 2) OVER (PARTITION BY customer_id ORDER BY total_cents DESC ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS second_largest_order_cents FROM orders WHERE customer_id IN ( SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) >= 2 ) ) AS o2 JOIN customers c ON o2.customer_id = c.id ORDER BY second_largest_order DESC; ``` However, the most efficient and correct version using standard SQL would be: ```sql WITH ranked_orders AS ( SELECT c.name, o.total_cents, ROW_NUMBER() OVER (PARTITION BY c.id ORDER BY o.total_cents DESC) AS row_num, COUNT(*) OVER (PARTITION BY c.id) AS order_count FROM customers c JOIN orders o ON c.id = o.customer_id ) SELECT name, ROUND((total_cents / 100.0), 2) AS second_largest_order FROM ranked_orders WHERE row_num = 2 AND order_count >= 2 ORDER BY second_largest_order DESC; ``` The best and most correct answer is: ```sql WITH ranked_orders AS ( SELECT c.name, o.total_cents, ROW_NUMBER() OVER (PARTITION BY c.id ORDER BY o.total_cents DESC) AS row_num, COUNT(*) OVER (PARTITION BY c.id) AS order_count FROM customers c JOIN orders o ON c.id = o.customer_id ) SELECT name, ROUND((total_cents / 100.0), 2) AS second_largest_order FROM ranked_orders WHERE row_num = 2 AND order_count >= 2 ORDER BY second_largest_order DESC; ``` However, considering the original request for a more straightforward query: ```sql WITH customer_orders AS ( SELECT customer_id, ARRAY_AGG(total_cents ORDER BY total_cents DESC) AS ordered_totals FROM orders GROUP BY customer_id HAVING COUNT(*) >= 2 ) SELECT c.name, ROUND((co.ordered_totals[2] / 100.0), 2) AS second_largest_order FROM customer_orders co JOIN customers c ON co.customer_id = c.id ORDER BY second_largest_order DESC; ``` But the most straightforward and correct query would be: ```sql SELECT c.name, ROUND((o.second_largest_total_cents / 100.0), 2) AS second_largest_order FROM ( SELECT customer_id, NTH_VALUE(total_cents, 2) OVER (PARTITION BY customer_id ORDER BY total_cents DESC ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS second_largest_total_cents FROM orders WHERE customer_id IN ( SELECT customer_id FROM orders GROUP BY customer_id HAVING COUNT(*) >= 2 ) ) AS o JOIN customers c ON o.customer_id = c.id WHERE o.second_largest_total_cents IS NOT NULL ORDER BY second_largest_order DESC; ``` A more standard and correct approach is: ```sql WITH ranked_orders AS ( SELECT c.name, o.total_cents, DENSE_RANK() OVER (PARTITION BY c.id ORDER BY o.total_cents DESC) AS rank FROM customers c JOIN orders o ON c.id = o.customer_id ), customer_ranks AS ( SELECT name, total_cents, rank FROM ranked_orders WHERE rank <= 2 ), customer_counts AS ( SELECT customer_id, COUNT(*) AS order_count FROM orders GROUP BY customer_id HAVING COUNT(*) >= 2 ) SELECT cr.name, ROUND((cr.total_cents / 100.0), 2) AS second_largest_order FROM customer_ranks cr JOIN customers c ON cr.name = c.name JOIN customer_counts cc ON c.id = cc.customer_id WHERE cr.rank = 2 ORDER BY second_largest_order DESC; ``` However, the most correct and efficient query is: ```sql WITH ranked_orders AS ( SELECT c.name, o.total_cents, DENSE_RANK() OVER (PARTITION BY c.id ORDER BY o.total_cents DESC) AS rank, COUNT(*) OVER (PARTITION BY c.id) AS order_count FROM customers c JOIN orders o ON c.id = o.customer_id ) SELECT name, ROUND((total_cents / 100.0), 2) AS second_largest_order FROM ranked_orders WHERE rank = 2 AND order_count >= 2 ORDER BY second_largest_order DESC; ``` **Final Answer:** ```sql WITH ranked_orders AS ( SELECT c.name, o.total_cents, DENSE_RANK() OVER (PARTITION BY c.id ORDER BY o.total_cents DESC) AS rank, COUNT(*) OVER (PARTITION BY c.id) AS order_count FROM customers c JOIN orders o ON c.id = o.customer_id ) SELECT name, ROUND((total_cents / 100.0), 2) AS second_largest_order FROM ranked_orders WHERE rank = 2 AND order_count >= 2 ORDER BY second_largest_order DESC; ```

Model A is concise and returns only SQL, but it uses DENSE_RANK so it finds the second-largest distinct total rather than necessarily the second order, which may not match the prompt. Model B badly violates the instruction to return only one SQL query by including extensive commentary and multiple alternative queries, even though one of its embedded queries is closer to correct. (Second judge pass, order swapped — scores are the average of both: Model A is better because it provides a single SQL query and is concise, whereas Model B violates the instruction to return only one SQL query by including extensive commentary and multiple alternatives. However, both have correctness issues: Model A uses DENSE_RANK(), which returns the second-distinct total rather than the second order total and can include customers with only one distinct value across multiple orders, while Model B’s final query has the same semantic issue despite also filtering for at least two orders.)

Python log redaction helper

Write Python 3 code only. Create a function `redact_log(line: str) -> str` that replaces any email address with `[EMAIL]` and any IPv4 address with `[IP]`, while leaving the rest of the line unchanged. Handle multiple occurrences in one line. Example: `"login from 192.168.1.9 by maya@northbay.dev"` -> `"login from [IP] by [EMAIL]"`. Use only the standard library.

gpt-oss-120b: ```python import re # IPv4 octet (0‑255) and full address pattern _IPV4_OCTET = r'(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)' _IPV4_PATTERN = rf'{_IPV4_OCTET}(?:\.{_IPV4_OCTET}){{3}}' # Simple (yet practical) e‑mail address pattern _EMAIL_PATTERN = r'[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}' # Compile a single regex that matches either an IPv4 address or an e‑mail address _RED_ACTION = re.compile(rf'({_IPV4_PATTERN})|({_EMAIL_PATTERN})') def redact_log(line: str) -> str: """ Replace every IPv4 address with `[IP]` and every e‑mail address with `[EMAIL]` in the supplied log line. Parameters ---------- line: str A single line from a log file. Returns ------- str The line with all IPv4 and e‑mail addresses redacted. """ def _replacer(match: re.Match) -> str: # match.group(1) is the IPv4 capture, group(2) is the e‑mail capture return '[IP]' if match.group(1) else '[EMAIL]' return _RED_ACTION.sub(_replacer, line) # ---------------------------------------------------------------------- # Example usage (can be removed or commented out when the function is imported) if __name__ == "__main__": examples = [ "login from 192.168.1.9 by maya@northbay.dev", "failed attempts from 10.0.0.1, 10.0.0.2 and user admin@example.org", "no sensitive data here", "multiple emails: a.b+c@example.co.uk, test@sub.domain.com", "mixed 127.0.0.1 and root@localhost", ] for e in examples: print(f"Original: {e}") print(f"Redacted: {redact_log(e)}") print("-" * 60) ```
cohere-command-a: import re def redact_log(line: str) -> str: """ Replaces any email address with [EMAIL] and any IPv4 address with [IP] in a given log line. Args: line (str): The log line to redact. Returns: str: The redacted log line. """ # Regular expression pattern to match IPv4 addresses ip_pattern = r"\b(?:\d{1,3}\.){3}\d{1,3}\b" # Regular expression pattern to match email addresses email_pattern = r"\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b" # Replace IPv4 addresses with [IP] line = re.sub(ip_pattern, "[IP]", line) # Replace email addresses with [EMAIL] line = re.sub(email_pattern, "[EMAIL]", line) return line

Model A is better because it provides valid Python 3 code only, handles multiple occurrences with a single compiled regex, and uses a stricter IPv4 pattern that avoids matching invalid addresses like 999.999.999.999. Model B is simpler and mostly works, but its IPv4 regex is overly permissive and its email character class `[A-Z|a-z]` is slightly sloppy, reducing correctness and polish. (Second judge pass, order swapped — scores are the average of both: Model B is the better fit because it provides valid Python code only and correctly redacts multiple email and IPv4-like matches using the standard library. Model A has a somewhat stronger IPv4 regex, but it violates the prompt by wrapping the answer in Markdown code fences and adding extra example/CLI code, so its instruction-following is worse.)

Polish product update localization

Translate this app update note into Polish for customer-facing release notes. Tone: friendly and reassuring. Length: 55-75 words. Keep the meaning and nuance intact; do not add features. Source: "We fixed an issue that could cause saved delivery routes to disappear after editing a stop with a weak signal. Your existing routes are safe. We also made barcode scanning faster on older phones and clarified the warning shown before you delete a route."

gpt-oss-120b: Naprawiliśmy problem, który mógł powodować znikanie zapisanych tras dostaw po edycji przystanku przy słabym sygnale. Twoje istniejące trasy są bezpieczne – nie musisz się o nie martwić. Dziękujemy za cierpliwość i zgłoszenia, które pomogły nam wykryć ten błąd. Dodatkowo przyspieszyliśmy skanowanie kodów kreskowych na starszych telefonach oraz doprecyzowaliśmy ostrzeżenie wyświetlane przed usunięciem trasy, aby było bardziej czytelne.
cohere-command-a: Naprawiliśmy problem, który mógł powodować zniknięcie zapisanych tras dostawy po edycji przystanku w miejscu z słabym sygnałem. Twoje istniejące trasy są bezpieczne. Przyspieszyliśmy również skanowanie kodów kreskowych na starszych telefonach i uściśliliśmy ostrzeżenie wyświetlane przed usunięciem trasy. Możesz spokojnie korzystać z aplikacji, wiedząc, że Twoje dane są bezpieczne i wszystko działa jeszcze lepiej!

Model B is closer to the requested length and keeps the main meaning in a friendly, reassuring tone, despite minor phrasing issues. Model A is fluent, but it exceeds the length limit and adds content not present in the source, such as thanks for patience and reports. (Second judge pass, order swapped — scores are the average of both: Model B stays closer to the source and covers all requested points in a friendly, reassuring tone, though it adds a mildly promotional closing sentence. Model A reads naturally, but it adds multiple unsupported details such as thanks for reports and extra reassurance, and it exceeds the requested length range.)

Matchup powered by OpenRouter.