Fusion takes the match 34.6 to 32.3 by winning the harder precision tests, while DeepSeek-V4-Pro looks better on presentation and instruction-following in narrower spots. The split is clear: Fusion is the safer model when correctness matters; DeepSeek-V4-Pro is the cleaner stylist when the task is mostly packaging.
OpenRouter: Fusion wins this head-to-head because it was better where mistakes actually cost you. In the Go rate-limit parser, Fusion delivered a complete, compilable snippet and got the edge cases right: case-insensitive header lookup, trimming, rejecting signed and fractional numerics, and parsing both RFC1123 and RFC1123Z. DeepSeek-V4-Pro stumbled on basics here — no package declaration, an unnecessary `net/http` import, and a real logic bug in treating a valid integer value of `"0"` as invalid.
Fusion also took the meeting-notes task, and that result matters more than it might look. It preserved the key nuance that the Sept. 24 launch was tentative, correctly framed legal approval as the launch gate, and produced a stronger summary plus action items. DeepSeek-V4-Pro was serviceable, but it flattened important uncertainty and overstated the CSV fix as a pre-launch requirement when the notes did not actually say that.
DeepSeek-V4-Pro's wins were narrower but legitimate. On the vendor outage status update, it wrote the more client-ready note: clearer, less technical, and better tuned to the audience. Fusion's version covered the facts, but the opening line — `I'll draft this status update email for you.` — is exactly the kind of meta filler that makes copy feel unshipped.
And in the messy-orders extraction task, DeepSeek-V4-Pro won by simply following directions. Both models structured the orders correctly, but Fusion blew the `valid JSON only` requirement by adding explanatory text before the payload. That's not a small formatting nit; in automation, that kind of lapse breaks pipelines.
**Final call: OpenRouter: Fusion is the better text model overall.** DeepSeek-V4-Pro is polished and often better at audience-facing prose, but Fusion was more dependable on the two tasks that demanded precise reasoning and faithful execution. If I need one model to be right rather than merely presentable, I take Fusion.
Go rate-limit parser
Language: Go
Return code only.
Implement a function:
func RetryAfterSeconds(headers map[string]string, now time.Time) int
It should read an HTTP Retry-After value from headers, checking keys case-insensitively. If the value is an integer number of seconds, return that integer. Otherwise, try to parse it as an HTTP date using time.RFC1123 or time.RFC1123Z and return the positive whole-number difference in seconds from now. If the date is in the past, parsing fails, the header is missing, or the value is empty, return 0.
Requirements:
- Do not mutate the input map.
- Trim surrounding spaces on the header value.
- Fractional or signed numbers like "1.5" or "+20" are invalid and should return 0 unless they parse as a date.
- Include any imports needed, but no explanation text.
OpenRouter: Fusion: ```go
package main
import (
"strconv"
"strings"
"time"
)
func RetryAfterSeconds(headers map[string]string, now time.Time) int {
var value string
found := false
for k, v := range headers {
if strings.EqualFold(k, "Retry-After") {
value = v
found = true
break
}
}
if !found {
return 0
}
value = strings.TrimSpace(value)
if value == "" {
return 0
}
allDigits := true
for _, r := range value {
if r < '0' || r > '9' {
allDigits = false
break
}
}
if allDigits {
if n, err := strconv.Atoi(value); err == nil {
return n
}
}
for _, layout := range []string{time.RFC1123, time.RFC1123Z} {
if t, err := time.Parse(layout, value); err == nil {
diff := int(t.Sub(now) / time.Second)
if diff > 0 {
return diff
}
return 0
}
}
return 0
}
```
DeepSeek-V4-Pro: ```go
import (
"net/http"
"strconv"
"strings"
"time"
)
func RetryAfterSeconds(headers map[string]string, now time.Time) int {
val := getHeaderCaseInsensitive(headers, "Retry-After")
val = strings.TrimSpace(val)
if val == "" {
return 0
}
if seconds, err := strconv.Atoi(val); err == nil {
if seconds > 0 {
return seconds
}
return 0
}
t, err := parseHTTPDate(val)
if err != nil {
return 0
}
diff := t.Sub(now)
if diff <= 0 {
return 0
}
return int(diff.Seconds())
}
func getHeaderCaseInsensitive(headers map[string]string, key string) string {
keyLower := strings.ToLower(key)
for k, v := range headers {
if strings.ToLower(k) == keyLower {
return v
}
}
return ""
}
func parseHTTPDate(value string) (time.Time, error) {
t, err := time.Parse(time.RFC1123, value)
if err == nil {
return t, nil
}
t, err = time.Parse(time.RFC1123Z, value)
if err == nil {
return t, nil
}
return time.Time{}, http.ErrNotSupported
}
```
A is a complete, compilable Go snippet that correctly handles case-insensitive lookup, trimming, invalid signed/fractional numerics, and RFC1123/RFC1123Z parsing. B is not self-contained because it lacks a package declaration, adds an unnecessary net/http dependency, and incorrectly rejects a valid integer value of "0", which should be returned as 0 rather than treated as invalid.
Vendor outage status update
Draft a status update email to retail pharmacy clients.
Scenario: Yesterday from 14:07 to 15:18 Central Time, our prescription routing platform "NexLane Rx" delayed some refill messages because a queue worker in the Omaha region stopped acknowledging jobs after a config rollout. New prescriptions were unaffected. We rolled back at 14:41, drained the backlog by 15:18, and added an alert on unacked jobs. No data loss or security issue occurred. Affected clients saw refill processing delays of 12–46 minutes.
Write for pharmacy operations managers. Tone: accountable, calm, non-technical. Length: 140–180 words. Include: what happened, who was affected, resolution, and one concrete prevention step. Do not use bullets.
OpenRouter: Fusion: I'll draft this status update email for you.Subject: NexLane Rx Refill Delay — Resolved
Dear Pharmacy Operations Team,
We're writing to inform you of a service issue that affected NexLane Rx yesterday afternoon. Between 2:07 and 3:18 PM Central Time, some refill messages were delayed following a routine system update in our Omaha region that caused processing to stall. New prescriptions were not affected at any point, and there was no data loss and no security or privacy issue.
Pharmacies submitting refills during this window may have experienced processing delays of roughly 12 to 46 minutes. Our team identified the cause quickly, reversed the update at 2:41 PM, and fully cleared the delayed messages by 3:18 PM. All affected refills were processed successfully, and service has returned to normal.
We take this disruption seriously and apologize for any inconvenience to your team and the patients you serve. To prevent a recurrence, we have added a new alert that immediately notifies our engineers if messages begin queuing without being processed, allowing us to act before your operations are affected.
Please reach out with any questions.
Sincerely,
The NexLane Rx Team
DeepSeek-V4-Pro: Subject: Update – NexLane Rx Refill Processing Delay on April 9
Dear Pharmacy Operations Managers,
We want to share a brief update on a service delay that occurred yesterday within our prescription routing platform, NexLane Rx. Between 14:07 and 15:18 Central Time, some refill messages were delayed and did not transmit to your work queues as quickly as expected. New prescriptions were not affected and continued routing normally. Affected locations experienced refill processing delays ranging from 12 to 46 minutes. No messages were lost, and no security incident occurred.
The issue began after a configuration update affected a processing component in our Omaha region, causing it to pause its work temporarily. Our team identified the problem and rolled back the change at 14:41, and the message backlog was fully cleared by 15:18. We have since added an immediate alert that will notify our engineers the moment any similar processing delay occurs, allowing us to intervene before it impacts pharmacy operations.
We take full accountability for this disruption and appreciate your patience as we continue refining our platform’s reliability. Please contact your account manager with any questions.
Both are strong, but B better matches the requested audience and tone with clearer, non-technical phrasing while still covering what happened, who was affected, the resolution, and a concrete prevention step. A is also solid, but its opening line is awkward ('I'll draft this status update email for you.') and slightly less polished for direct client use.
Meeting notes summary and action items
Read these meeting notes and produce:
1) a 3-bullet summary
2) a JSON object with keys: decision, launch_date, blockers, owners
Notes:
- Tuesday sync for the "ParcelLens" returns dashboard.
- Mina: the carrier-status widget is accurate enough now; false "in transit" labels dropped from 7.8% to 1.9% after remapping FalconExpress event 214.
- Jorge: support still gets complaints from beta users about CSV export timing out on workspaces over 80k rows.
- Priya: if we cut PDF export from v1, design can finish by Sept 18 instead of Sept 27.
- Team agreed v1 will launch without PDF export.
- Evan: legal needs final vendor DPA signed before launch; target review complete by Sept 12.
- Mina will own carrier widget QA sign-off.
- Jorge will coordinate a fix for CSV export timeouts with data infra.
- Tentative launch date kept at Sept 24 unless legal slips.
For the JSON, make owners an object mapping each open work item to its owner.
OpenRouter: Fusion: I'll analyze these meeting notes and produce the requested summary and JSON.## 3-Bullet Summary
- **The team decided ParcelLens v1 will launch without PDF export**, letting design finish by Sept 18 instead of Sept 27. The carrier-status widget has also improved markedly—false "in transit" labels fell from 7.8% to 1.9% after remapping FalconExpress event 214.
- **Two open work items remain:** Mina owns carrier-widget QA sign-off, and Jorge is coordinating a fix with data infra for CSV export timeouts that beta users hit on workspaces over 80k rows.
- **Launch is tentatively set for Sept 24**, gated on legal signing the final vendor DPA (review targeted complete by Sept 12); the date holds unless legal slips.
## JSON
```json
{
"decision": "v1 will launch without PDF export",
"launch_date": "Sept 24 (tentative, unless legal slips)",
"blockers": [
"Final vendor DPA must be signed by legal before launch (review targeted complete by Sept 12)",
"CSV export times out on workspaces over 80k rows"
],
"owners": {
"Carrier widget QA sign-off": "Mina",
"CSV export timeout fix (with data infra)": "Jorge",
"Vendor DPA review and signing": "Evan"
}
}
```
A couple of notes on choices made:
- I kept the launch date as a string preserving the "tentative, unless legal slips" condition, since the notes give no year and explicitly tie Sept 24 to that contingency.
- The `owners` object lists only the three genuine open work items. Priya's design completion is excluded because cutting PDF export was a decision already made, not an assigned action item.
- Worth flagging: the schedule is tight—legal targets Sept 12 and design finishes Sept 18, leaving a narrow buffer before the Sept 24 launch. Of the two blockers, only the DPA is explicitly launch-gating; the CSV timeout is a known beta issue with a fix in progress.
DeepSeek-V4-Pro: Here is the output based on the meeting notes:
**1) 3-Bullet Summary**
- The carrier-status widget accuracy improved significantly (false "in transit" labels dropped from 7.8% to 1.9%) after a label remapping fix.
- The team formally agreed to cut PDF export from the v1 scope to accelerate the design completion date by over a week.
- CSV export timeouts for large workspaces remain a critical user complaint, requiring a coordinated fix before launch.
**2) JSON Object**
```json
{
"decision": "v1 launch without PDF export",
"launch_date": "Sept 24",
"blockers": [
"Vendor DPA final signature required before launch",
"CSV export timeout on workspaces over 80k rows"
],
"owners": {
"Carrier widget QA sign-off": "Mina",
"CSV export timeout fix coordination": "Jorge",
"Legal vendor DPA completion": "Evan"
}
}
```
A is more complete and faithful to the notes: it includes the tentative nature of the Sept 24 launch, correctly ties legal to the launch gate, and provides a stronger summary. B is solid but omits the launch contingency in both the summary and JSON and overstates that the CSV fix is required before launch, which the notes do not explicitly say.
Messy orders to JSON
Transform the messy order lines below into valid JSON only.
Output schema:
{
"orders": [
{
"order_id": "string",
"customer": "string",
"ship_country": "string",
"items": [{"sku":"string","qty":number}],
"priority": true,
"notes": "string or null"
}
]
}
Rules:
- One object per unique order_id, preserving first appearance order.
- Combine repeated order lines into the same items array.
- qty must be a number.
- priority is true only if the line says rush=yes.
- notes should be null if blank or "-".
- Trim spaces everywhere.
Data:
ORD-881 | customer: Hale Bioworks | country: CA | sku=MX-44 | qty 3 | rush=yes | notes: deliver before 5 pm
ORD-882|customer: Northline Studio|country:US|sku=TB-9|qty 1|rush=no|notes:-
ORD-881| customer:Hale Bioworks| country:CA | sku=QZ-2 | qty 7 | rush=yes | notes: deliver before 5 pm
ORD-883 | customer: Parnell Civic Theatre | country: IE | sku = STAGE-1 | qty 2 | rush = no | notes: back dock
ORD-884|customer:Umber & Ash Cafe|country:AU|sku=GR-11|qty 12|rush=yes|notes:
OpenRouter: Fusion: I'll process this data transformation request.```json
{
"orders": [
{
"order_id": "ORD-881",
"customer": "Hale Bioworks",
"ship_country": "CA",
"items": [
{"sku": "MX-44", "qty": 3},
{"sku": "QZ-2", "qty": 7}
],
"priority": true,
"notes": "deliver before 5 pm"
},
{
"order_id": "ORD-882",
"customer": "Northline Studio",
"ship_country": "US",
"items": [
{"sku": "TB-9", "qty": 1}
],
"priority": false,
"notes": null
},
{
"order_id": "ORD-883",
"customer": "Parnell Civic Theatre",
"ship_country": "IE",
"items": [
{"sku": "STAGE-1", "qty": 2}
],
"priority": false,
"notes": "back dock"
},
{
"order_id": "ORD-884",
"customer": "Umber & Ash Cafe",
"ship_country": "AU",
"items": [
{"sku": "GR-11", "qty": 12}
],
"priority": true,
"notes": null
}
]
}
```
DeepSeek-V4-Pro: ```json
{
"orders": [
{
"order_id": "ORD-881",
"customer": "Hale Bioworks",
"ship_country": "CA",
"items": [
{"sku": "MX-44", "qty": 3},
{"sku": "QZ-2", "qty": 7}
],
"priority": true,
"notes": "deliver before 5 pm"
},
{
"order_id": "ORD-882",
"customer": "Northline Studio",
"ship_country": "US",
"items": [
{"sku": "TB-9", "qty": 1}
],
"priority": false,
"notes": null
},
{
"order_id": "ORD-883",
"customer": "Parnell Civic Theatre",
"ship_country": "IE",
"items": [
{"sku": "STAGE-1", "qty": 2}
],
"priority": false,
"notes": "back dock"
},
{
"order_id": "ORD-884",
"customer": "Umber & Ash Cafe",
"ship_country": "AU",
"items": [
{"sku": "GR-11", "qty": 12}
],
"priority": true,
"notes": null
}
]
}
```
Both outputs extract and structure the orders correctly, but Model A violates the instruction to return valid JSON only by adding explanatory text before the JSON block. Model B follows the content requirements and formatting instruction more closely.
Matchup powered by
OpenRouter.