Head to head: grok-4.3 vs Phi-4

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.

How they were tested

We ran 4 fresh text tasks, generated on the fly for this matchup so neither model could prepare in advance, and had gpt-5.4 score each one. grok-4.3 scored 37.0 to Phi-4's 26.0.

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

Winner: grok-4.3 — 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.

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

Winner: grok-4.3 — 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.

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

Winner: grok-4.3 — 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.

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

Winner: grok-4.3 — 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.

See every prompt and the full side-by-side outputs in the interactive Head-to-Head.