Head to head: grok-4.3 vs cohere-command-a

The aggregate score says it plainly: grok-4.3 wins 36.6 to 30.1, and the task breakdown backs that up. This was not a vibes contest. It was a test of whether a model can follow constraints, preserve structure, and avoid introducing subtle errors when the prompt leaves little room for improvisation.

The clearest separation showed up in the technical tasks. On python-log-redactor, grok-4.3 was simply tighter: it redacted only query parameters preceded by ? or &, preserved the original key casing through captured groups, and avoided the sloppiness in Cohere-command-a’s approach, which could redact mytoken=... anywhere in a line and used a weaker IPv4 regex that also matched invalid addresses. That is the difference between a tool you can trust in production and one that creates fresh cleanup work.

Grok-4.3 also handled structured-output compliance better. In meeting-notes-summary, it delivered the requested two-sentence summary and a JSON object with the specified keys, while still capturing both key decisions. Cohere-command-a dropped the Android rollout decision from decisions and rewired action_items into objects instead of the requested simple list. In messy-orders-to-json, both models understood the data, but only grok-4.3 respected the instruction to return valid JSON only; Cohere-command-a wrapped its answer in Markdown fences and failed on a basic formatting requirement.

Cohere-command-a’s one win, vendor-delay-update, is real but limited. Its response was better organized for the internal audience, with clearer separation of scope, ETA-page status, and next steps for Sales and Support. Grok-4.3 was accurate, but less polished in the customer-facing message and less direct in team guidance. That matters for internal comms. It just does not outweigh repeated misses on precision and schema fidelity elsewhere.

Final call: grok-4.3 is the stronger text model here because it is more exact, more compliant, and less likely to break the brief in high-consequence tasks. Cohere-command-a writes a neater status update, but grok-4.3 wins the head-to-head on substance.

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 36.6 to cohere-command-a's 30.1.

1. python-log-redactor

Language: Python 3.11 Return code only. Write a function redact_log(line: str) -> str for an API gateway that removes sensitive data from a single log line. Requirements: - Replace any IPv4 address with [IP]. - Replace any email address with [EMAIL]. - Replace any value of query params named token, api_key, or sessionid with [REDACTED], preserving the key and separators. Example: token=abc123 -> token=[REDACTED]. - Matching for param names is case-insensitive. - Do not alter other text. - Use only the standard library. Also include a few assert tests at the bottom covering mixed cases like: 2026-04-18T09:14:03Z GET /v1/export?token=q9Z!&page=2 from 198.51.100.24 user=maya@larkspur.tools POST /login?SessionId=xy-77&redirect=/dash by aaron+ops@northjet.io via 203.0.113.9 no secrets here

Winner: grok-4.3 — A better preserves the required query-param separators by matching only params preceded by ? or & and keeps the original key casing via captured groups. B is less precise: it can redact non-query text like 'mytoken=...' anywhere in the line, does not preserve the exact matched key casing in the replacement, and uses a looser IPv4 regex that matches invalid addresses.

2. vendor-delay-update

Draft a status update email to our internal sales and support teams. Context: Our warehouse vendor, BlueHarbor Fulfillment, had a scanner outage this morning from 07:20 to 10:05 local time. Orders were received but not picked during that window. We estimate 143 orders will ship one business day late. No data loss, no payment issues, and expedited orders placed after 10:05 are flowing normally. Customer-facing ETA pages have not yet been updated. We expect the backlog cleared by tomorrow 14:00. Support needs a short approved message to use with affected customers. Sales needs to know this only affects US East inventory, not custom-engraved items. Write one email: - audience: internal sales + support - tone: calm, accountable, practical - length: 170-220 words - include a 3-bullet "What to tell customers" section - include a clear subject line

Winner: cohere-command-a — B is slightly better organized for the internal audience, explicitly separates scope, ETA-page status, and next steps for Sales and Support, while staying within the requested tone and length. A is solid and accurate, but its customer message is a bit less polished and it gives less direct guidance to the two teams.

3. meeting-notes-summary

Read the meeting notes below, then provide: 1) a 2-sentence summary 2) a JSON object with keys: launch_date, owner, blocked_by, decisions, action_items Meeting notes: - Team: Nimbus Note mobile sync - Priya said Android crash rate improved after 5.4.2, but offline edits still duplicate attachments in rare cases. - Marco wants to keep the staged rollout at 25% until support confirms fewer than 15 duplicate-attachment tickets/day for 3 straight days. - Decision: iOS release can go out Tuesday 12 Aug if legal approves the revised backup-copy text. - Legal review owner is Dana; she said feedback by Monday 15:00. - Blocker: the French translation for the backup-copy screen still uses the old retention wording. - Action: Jules to patch the French string today. - Action: Priya to post a support-ticket trend snapshot in #mobile-quality every morning through Tuesday. - Action: Marco to prepare rollback steps before the release meeting. - Reminder: enterprise customers on legacy sync are not affected.

Winner: grok-4.3 — A better follows the requested format with a clear 2-sentence summary and a JSON object matching the specified keys while capturing both key decisions. B is mostly correct but omits the Android rollout decision from decisions and changes the action_items structure from a simple list to objects, which is less faithful to the prompt.

4. messy-orders-to-json

Convert the messy order notes below into valid JSON only. Output schema: { "orders": [ { "order_id": string, "customer": string, "ship_country": string, "items": [{"sku": string, "qty": integer}], "priority": "low" | "normal" | "high", "gift": boolean } ] } Rules: - Preserve input order. - Normalize country names to full English names. - Trim spaces. - Quantities are integers. - If priority missing, use "normal". - Interpret gift markers yes/y/true as true; no/n/false as false. - Do not invent missing items. Messy notes: 1. order=QF-1908 | customer: Nila Voss | country=DE | items: AX-4 x2, BOLT-9 x 1 | gift=y | priority=high 2. customer=Orin Hale; id QF-1909; ship to: United States ; lines= MUG-RED*4 ; gift=no 3. QF-1910 / Mei Tan / UK / SKUs [PEN-2 qty 3 ; NOTE-88 qty 12] / priority low / gift true 4. id:QF-1911, customer: "R. Ibarra", country: jp, items: CABLE-USB-C x1, ADAPT-2 x2, , gift: n

Winner: grok-4.3 — Both outputs parse the orders correctly and match the schema content, but A follows the instruction to output valid JSON only. B wraps the JSON in Markdown code fences, so it is not JSON-only and is less compliant.

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