Head to head: grok-4.3 vs Phi-4

grok-4.3 vs Phi-4

This matchup wasn’t especially close: grok-4.3 beat Phi-4 by being the more disciplined model where it counts—following instructions exactly, preserving edge-case correctness, and producing cleaner task-shaped outputs. Phi-4 had moments of competence, but it repeatedly gave away points on avoidable mistakes.

grok-4.3 wins this head-to-head, 37.0 to 26.0, because it was consistently tighter on both correctness and compliance. The pattern across the set is straightforward: when the prompt demanded precision, grok-4.3 delivered it; when there was room to slip on assumptions or formatting, Phi-4 usually did. The clearest technical gap showed up in **python-window-merger**. grok-4.3 handled the actual spec: merge overlapping and directly adjacent intervals for the same service, keep services separate, return sorted output, and deal with empty input cleanly. Phi-4 missed on multiple fronts at once—it treated one-minute gaps as adjacent with `start <= current_end + 1`, mutated the input via `events.sort()`, and even included example-print code after being told to provide just the implementation. That’s not a small miss; that’s a model inventing its own rules. On the writing-and-structure tasks, grok-4.3 was also the sharper editor. In **billing-credit-email**, both responses were usable, but grok-4.3 was more accountable: it plainly said no action is needed and gave a concrete fallback if the refund wasn’t visible by April 14. Phi-4 sounded polished, but it introduced an unsupported explanation—"technical oversight"—that wasn’t in the source material. In **incident-notes-summary**, grok-4.3 again kept the details straight: peak error rate, timing, retries, no data loss, and the correct JSON field mapping with the owner separated cleanly. Phi-4 was broadly accurate, but less exact, and it muddied `follow_up_owner` by stuffing action detail into a field that should have contained just the owner. The smallest task exposed the same larger issue. In **messy-orders-to-json**, grok-4.3 did the boring but essential thing: valid JSON only, correctly normalized and sorted. Phi-4’s underlying content was fine, but it still wrapped the output in Markdown code fences, directly violating the instruction. That’s the story of this matchup in miniature—Phi-4 often looked close until you checked whether it actually obeyed the prompt. **Final call: grok-4.3 is the better text model here, and not by style points. It won on rigor, restraint, and instruction-following—the traits that separate a genuinely reliable model from one that merely sounds competent.**

python-window-merger

Write Python 3 code only. Implement a function `merge_windows(events: list[tuple[str,int,int]]) -> list[tuple[str,int,int]]` for a monitoring service. Each tuple is `(service, start_minute, end_minute)` and represents an outage window with `start_minute < end_minute`. Merge overlapping or directly adjacent windows for the same service only. Keep different services separate. Return the merged windows sorted first by service name, then by start time. Example input: `[('api',10,20),('api',20,25),('db',5,8),('api',18,22),('db',9,11),('web',1,2)]` should return `[('api',10,25),('db',5,8),('db',9,11),('web',1,2)]` because adjacency counts only when end==next start, so db windows here do not merge. Handle empty input.

grok-4.3: ```python from collections import defaultdict def merge_windows(events): if not events: return [] service_windows = defaultdict(list) for service, start, end in events: service_windows[service].append((start, end)) result = [] for service in sorted(service_windows.keys()): intervals = sorted(service_windows[service]) merged = [] for curr_start, curr_end in intervals: if not merged: merged.append([curr_start, curr_end]) else: last = merged[-1] if curr_start <= last[1]: last[1] = max(last[1], curr_end) else: merged.append([curr_start, curr_end]) for start, end in merged: result.append((service, start, end)) return result ```

Phi-4: ```python from typing import List, Tuple def merge_windows(events: List[Tuple[str, int, int]]) -> List[Tuple[str, int, int]]: if not events: return [] # Sort events by service name, then by start minute events.sort() merged_windows = [] current_service = None current_start = None current_end = None for service, start, end in events: if service != current_service: # If service changes, append the previous merged window and reset if current_service is not None: merged_windows.append((current_service, current_start, current_end)) current_service = service current_start = start current_end = end else: # If it's the same service, check if we need to merge if start <= current_end + 1: current_end = max(current_end, end) else: # Append the previous window and start a new one merged_windows.append((current_service, current_start, current_end)) current_start = start current_end = end # Append the last processed window merged_windows.append((current_service, current_start, current_end)) return merged_windows # Example usage: example_input = [('api', 10, 20), ('api', 20, 25), ('db', 5, 8), ('api', 18, 22), ('db', 9, 11), ('web', 1, 2)] print(merge_windows(example_input)) ```

A correctly merges overlapping and directly adjacent intervals for the same service, keeps services separate, handles empty input, and returns results sorted by service then start. B incorrectly treats gaps of 1 minute as adjacent via `start <= current_end + 1`, mutates the input list with `events.sort()`, and includes example-print code despite the instruction to provide just the implementation.

billing-credit-email

Draft a customer email to Maya Ortiz, operations manager at Northline Pilates. We accidentally billed her team twice for the April 2026 Pro plan renewal: invoice INV-84217 for $312.00 was paid on Apr 2, and duplicate invoice INV-84217-D was charged on Apr 3. Finance has already issued a full refund to the original Visa ending 1184; banks usually post it in 5–7 business days. Apologize clearly, confirm there is no action needed from her, and offer direct help if the refund is not visible by Apr 14. Tone: professional, calm, and accountable. Length: 120–160 words.

grok-4.3: Subject: Apology for Duplicate Billing on April 2026 Pro Plan Renewal Dear Ms. Ortiz, I am writing to apologize for an error that resulted in a duplicate charge for Northline Pilates’ April 2026 Pro plan renewal. Invoice INV-84217 for $312.00 was paid on April 2, and a duplicate invoice, INV-84217-D, was charged the following day. We have already issued a full refund to the original Visa card ending in 1184. Banks typically post refunds within 5–7 business days. No action is required on your part at this time. If the credit does not appear on your statement by April 14, please reply to this email or contact me directly and I will resolve it immediately. Thank you for your patience. We value your partnership and are committed to preventing this from recurring. Best regards, [Your Name] Customer Success [Your Company]

Phi-4: Subject: Correction of Billing Error and Refund Information for Northline Pilates Dear Maya, I hope this message finds you well. I am writing to sincerely apologize for a billing error regarding the renewal of your team’s Pro plan for April 2026. Due to a technical oversight, your account was inadvertently billed twice. The original invoice, INV-84217, amounting to $312.00, was paid on April 2. A duplicate invoice, INV-84217-D, was subsequently charged on April 3. Please be assured that our Finance Department has promptly issued a full refund to the original Visa card ending in 1184. Typically, banks process refunds within 5–7 business days, and you should observe the refund noted in your account soon. There is no action required on your part, but please do not hesitate to contact me directly if the refund has not been reflected by April 14. Our team is here to assist you with any further information or support needed. Thank you for your understanding, and once again, we are truly sorry for any inconvenience this may have caused. Warm regards, [Your Name] [Your Position] [Your Contact Information] [Company Name]

Both are strong and meet the core requirements, but A is slightly better because it is more direct and accountable, explicitly says no action is needed, and clearly offers direct help if the refund is not visible by April 14. B is polished but adds an unsupported detail ('technical oversight') and is a bit more generic.

incident-notes-summary

Read the meeting notes below, then output two sections: (1) a 3-bullet summary for executives, and (2) a JSON object with keys `incident_id`, `start_time`, `customer_impact`, `root_cause`, `mitigation`, `follow_up_owner`. Source notes: - Incident: IM-4172 - 08:13 UTC: alerts fired for elevated 502s on upload API. - Priya said error rate peaked at 18% between 08:19 and 08:27; mostly affected EU tenants uploading CSVs larger than 20 MB. - Mateo traced it to a config rollout in `edge-gateway` that lowered upstream read timeout from 90s to 9s. - Rollout began 08:07, fully propagated by 08:12. - At 08:29, team reverted the timeout and drained two unhealthy pods. - Metrics back to baseline by 08:34. - No data loss observed; failed uploads can be retried safely. - Follow-up: Lena to add a policy check blocking timeout reductions over 50% without approval. - Customer comms draft should mention intermittent upload failures, not total outage.

grok-4.3: (1) Executive summary - Incident IM-4172 caused intermittent 502 errors on the upload API, peaking at 18 % for EU tenants uploading large CSVs between 08:19–08:27 UTC; service was restored with no data loss. - Root cause was an edge-gateway config rollout that reduced the upstream read timeout from 90 s to 9 s; the change was rolled back and unhealthy pods drained by 08:34 UTC. - Lena will add an automated policy check to block future timeout reductions >50 % without approval; customer messaging will describe the event as intermittent upload failures rather than a full outage. (2) { "incident_id": "IM-4172", "start_time": "08:07 UTC", "customer_impact": "Elevated 502 errors, peaking at 18% between 08:19-08:27 UTC, primarily affecting EU tenants uploading CSVs larger than 20 MB; no data loss, uploads can be retried", "root_cause": "Config rollout in edge-gateway lowered upstream read timeout from 90s to 9s, began 08:07 and fully propagated by 08:12", "mitigation": "Reverted timeout change and drained two unhealthy pods at 08:29; metrics returned to baseline by 08:34", "follow_up_owner": "Lena" }

Phi-4: ### 3-Bullet Summary for Executives - **Incident Overview**: There was an incident with elevated 502 errors on the upload API affecting primarily EU tenants uploading CSVs larger than 20 MB. - **Root Cause & Resolution**: The issue was traced to a configuration change in `edge-gateway` reducing the read timeout, which was immediately reverted, and unhealthy pods were drained. - **Impact & Follow-Up**: The incident had minimal impact with no data loss, and a policy check will be introduced to prevent similar future occurrences. ### JSON Object ```json { "incident_id": "IM-4172", "start_time": "08:13 UTC", "customer_impact": "Mainly affected EU tenants uploading CSVs larger than 20 MB, with no data loss; retries are safe.", "root_cause": "Configuration rollout in `edge-gateway` lowered upstream read timeout from 90s to 9s.", "mitigation": "Reverted the timeout change and drained two unhealthy pods; metrics returned to baseline by 08:34.", "follow_up_owner": "Lena to implement a policy check for preventing unapproved timeout reductions over 50%." } ```

A is more complete and precise: it includes the peak error rate, timing, retry/no-data-loss context, and a cleaner JSON field mapping with the correct owner. B is accurate overall but omits key impact details, uses a less precise summary, and puts extra action detail into `follow_up_owner` instead of just the owner.

messy-orders-to-json

Transform the messy order lines below into valid JSON only. Output an array of objects sorted by `order_id` ascending. Schema for each object: `{ "order_id": string, "customer": string, "items": [{"sku": string, "qty": integer}], "priority": boolean }`. Normalize customer names to title case, trim spaces, combine duplicate SKUs within the same order by summing qty, and treat priority values `Y`, `yes`, `true`, `1` as true; everything else as false. Data: ORD-105 | customer= selam h. | items: AX9 x2, QL2 x1, AX9 x3 | priority=Y ORD-102 | customer=BRUNO VEGA| items: MN1 x 4 | priority=no ORD-104 | customer=ina ko| items: TT7 x1, ZZ2 x2 | priority=1 ORD-103 | customer= d. mendoza | items: QL2 x2, ql2 x5, BK1 x1 | priority=false

grok-4.3: [ {"order_id": "ORD-102", "customer": "Bruno Vega", "items": [{"sku": "MN1", "qty": 4}], "priority": false}, {"order_id": "ORD-103", "customer": "D. Mendoza", "items": [{"sku": "QL2", "qty": 7}, {"sku": "BK1", "qty": 1}], "priority": false}, {"order_id": "ORD-104", "customer": "Ina Ko", "items": [{"sku": "TT7", "qty": 1}, {"sku": "ZZ2", "qty": 2}], "priority": true}, {"order_id": "ORD-105", "customer": "Selam H.", "items": [{"sku": "AX9", "qty": 5}, {"sku": "QL2", "qty": 1}], "priority": true} ]

Phi-4: ```json [ { "order_id": "ORD-102", "customer": "Bruno Vega", "items": [ { "sku": "MN1", "qty": 4 } ], "priority": false }, { "order_id": "ORD-103", "customer": "D. Mendoza", "items": [ { "sku": "QL2", "qty": 7 }, { "sku": "BK1", "qty": 1 } ], "priority": false }, { "order_id": "ORD-104", "customer": "Ina Ko", "items": [ { "sku": "TT7", "qty": 1 }, { "sku": "ZZ2", "qty": 2 } ], "priority": true }, { "order_id": "ORD-105", "customer": "Selam H.", "items": [ { "sku": "AX9", "qty": 5 }, { "sku": "QL2", "qty": 1 } ], "priority": true } ] ```

A fully satisfies the prompt with valid JSON only, correctly sorted and normalized. B's content is otherwise correct, but it violates the instruction to output valid JSON only by wrapping the array in Markdown code fences.