Head to head: Kimi-K3 vs gpt-oss-120b

Kimi-K3 vs gpt-oss-120b

By Ryan Merket · Published Sep 2, 2026, 9:42am CT

This one is a genuine photo finish. Kimi-K3 and gpt-oss-120b trade blows across coding, reasoning, editing, and extraction tasks so evenly that the aggregate gap is noise, not a verdict.

The scoreboard says 108.0 for Kimi-K3 and 103.7 for gpt-oss-120b, but the only number that really matters is the confidence: **50%**. In plain English, that means this matchup is a statistical dead heat. There is no honest winner to declare here; these models were effectively even. The shape of the tie is interesting, though. **Kimi-K3 tended to win on instruction discipline and exactness**: the concurrency bug fix was a recurring bright spot, with Kimi more reliably caching the in-flight promise correctly and returning only the requested function. It also had strong showings in SQL and several formatting-sensitive proofreading tasks, where cleaner adherence to the prompt mattered as much as raw correctness. **gpt-oss-120b, meanwhile, often looked better when robustness and implementation hygiene were the differentiator.** It had the edge in some debugging and LRU-cache evaluations thanks to safer handling of edge cases like invalid capacity or malformed input, and it frequently read as the more systematic explainer in reasoning-heavy prompts. On localization, it also often sounded more natural and product-ready, especially for short UI copy. What keeps this from tilting either way is that nearly every apparent advantage got canceled somewhere else. Several tasks were outright ties, and even among the split decisions, the second-pass judging repeatedly softened first-pass wins into negligible differences. In other words: one model might be slightly cleaner on one coding prompt, the other slightly sharper on the next, but **there is no stable, publication-worthy separation between them in this run**. **Final call: too close to call. Kimi-K3 and gpt-oss-120b are effectively tied in this head-to-head, and claiming a real winner would overread the data.**

Classification & labeling

Classify each customer-support message into exactly one category: - Billing - Technical Issue - Account Access - Feature Request - Shipping/Delivery Return one line per item in this exact format: `<number>. <category> - <brief justification>` Items: 1. "I was charged twice for order 7714 even though the checkout page froze." 2. "The reset link says it's expired the moment I click it." 3. "Can you add dark mode to the analyst dashboard?" 4. "My replacement filters were marked delivered yesterday, but nothing is at the front desk." 5. "The Android app closes whenever I tap Export CSV." 6. "Where can I download invoices for March?"

Kimi-K3: 1. Billing - Customer reports a duplicate charge on order 7714. 2. Account Access - Password reset link is failing, preventing login recovery. 3. Feature Request - Customer is asking for a new dark mode capability. 4. Shipping/Delivery - Package shows as delivered but customer hasn't received it. 5. Technical Issue - App crashes consistently when using the Export CSV function. 6. Billing - Customer needs help locating/downloading invoices, a billing document.

gpt-oss-120b: 1. Billing - duplicate charge reported for order 7714. 2. Account Access - reset link expires immediately, preventing login. 3. Feature Request - user asks for a dark mode option in the dashboard. 4. Shipping/Delivery - item marked delivered but not physically received. 5. Technical Issue - Android app crashes when using Export CSV function. 6. Billing - request for downloading monthly invoices.

Model A and Model B both classify all six items correctly and follow the required one-line format with brief justifications. Model A is slightly more explanatory, while Model B is slightly more concise, but neither has a meaningful quality advantage for this task. (Second judge pass, order swapped — scores are the average of both: Model B and Model A both classify all six items correctly and follow the required one-line format with concise justifications. Model A is slightly more polished in phrasing, but the difference is negligible for this task.)

Step-by-step reasoning

A clinic buys nitrile gloves in 3 box sizes: - small box: 40 pairs for $11.20 - medium box: 75 pairs for $19.50 - bulk box: 120 pairs for $30.00 They need at least 430 pairs for a vaccination drive and have storage space for at most 6 boxes total. They want the lowest possible total cost. If multiple options tie on cost, choose the one with fewer boxes; if still tied, choose the one with more bulk boxes. What combination of boxes should they buy, and what is the total cost? Show your reasoning.

Kimi-K3: Buy **3 bulk boxes and 1 medium box**. - Pairs: $3(120)+75=435$, which meets the 430-pair need. - Boxes: $3+1=4$, within the 6-box storage limit. - Cost: $3(\$30.00)+\$19.50=\boxed{\$109.50}$. Reasoning: unit costs are bulk $= \$0.25$/pair, medium $= \$0.26$/pair, small $= \$0.28$/pair. Checking the best feasible fill for each possible number of bulk boxes: | Bulk boxes | Remaining pairs needed | Best feasible fill within 6 total boxes | Total pairs | Total cost | |---:|---:|---|---:|---:| | 0 | 430 | 6 medium | 450 | \$117.00 | | 1 | 310 | 4 medium + 1 small | 460 | \$119.20 | | 2 | 190 | 2 medium + 1 small | 430 | \$110.20 | | 3 | 70 | 1 medium | 435 | **\$109.50** | | 4+ | already met | cost at least \$120 | — | not lower | For 3 bulk boxes, the remaining 70 pairs are covered more cheaply by one medium box (\$19.50) than by two small boxes (\$22.40). This is the unique lowest-cost option, so the tie-breakers do not change the choice.

gpt-oss-120b: **Variables** | Box type | Pairs per box | Cost per box | Cost per pair | |----------|----------------|--------------|---------------| | Small | 40 | \$11.20 | \$0.28 | | Medium | 75 | \$19.50 | \$0.26 | | Bulk | 120 | \$30.00 | \$0.25 | Let * $s$ = number of small boxes, * $m$ = number of medium boxes, * $b$ = number of bulk boxes. All variables are non‑negative integers. **Constraints** 1. **Pairs needed** \[ 40s + 75m + 120b \;\ge\; 430 \] 2. **Storage (boxes) limit** \[ s + m + b \;\le\; 6 \] **Objective** Minimise total cost \[ C = 11.20\,s + 19.50\,m + 30.00\,b. \] If several solutions give the same minimum cost we prefer 1. fewer total boxes $(s+m+b)$ and, if still tied, 2. more bulk boxes $b$. --- ### 1. Brute‑force search (only a few possibilities) Because at most 6 boxes can be bought, we can enumerate all feasible $(s,m,b)$ triples. | $b$ | $m$ | $s$ | Pairs | Boxes | Cost (\$) | |------|------|------|-------|-------|----------| | 4 | 0 | 0 | 480 | 4 | 120.00 | | 3 | 1 | 0 | 435 | 4 | **109.50** | | 3 | 0 | 1 | 400 | 4 | 101.20* (insufficient) | | 3 | 0 | 2 | 440 | 5 | 112.40 | | 2 | 2 | 1 | 430 | 5 | 110.20 | | 2 | 3 | 0 | 495 | 5 | 118.50 | | 2 | 1 | 3 | 435 | 6 | 113.10 | | 1 | 4 | 1 | 460 | 6 | 119.20 | | 1 | 5 | 0 | 475 | 6 | 127.50 | | 0 | 6 | 0 | 450 | 6 | 117.00 | *(The row with 3‑bulk + 0‑medium + 1‑small gives only 400 pairs, so it is rejected.)* All other combinations either fail the “≥ 430 pairs’’ requirement or use more than six boxes. ### 2. Finding the cheapest feasible solution The cheapest cost among the feasible rows is **\$109.50**, achieved by: * **3 bulk boxes** (3 × 120 = 360 pairs) * **1 medium box** (1 × 75 = 75 pairs) Total pairs = 360 + 75 = **435 pairs** (≥ 430). Total boxes = 3 + 1 = **4 boxes** (≤ 6). No other feasible combination reaches a lower cost; a quick check of the cost equation \[ 30b + 19.5m + 11.2s = 109.5 \] shows that the only integer solution satisfying the box‑limit is $(b,m,s) = (3,1,0)$. ### 3. Tie‑breaking (not needed) Because the minimum cost is unique, the tie‑break rules are irrelevant. The solution already uses the fewest boxes (4) among all cost‑optimal possibilities. --- ## Answer **Buy 3 bulk boxes and 1 medium box.** *Pairs obtained:* $3 × 120 + 1 × 75 = 435$ pairs (meets the 430‑pair requirement). *Boxes used:* 4 (within the storage limit of 6). *Total cost:* $3 × \$30.00 + 1 × \$19.50 = \boxed{\$109.50}$.

Model B is better because it gives a clearer, more systematic optimization setup and explicitly frames the constraints and objective before checking feasible combinations. Both models reach the correct answer, but Model B’s reasoning is more complete and polished, while Model A’s table is slightly less rigorous in how it summarizes the search. (Second judge pass, order swapped — scores are the average of both: Model B and Model A both reach the correct minimum-cost combination of 3 bulk boxes and 1 medium box for $109.50, and both show valid reasoning. Model B is more exhaustive and explicit, while Model A is more concise and still sufficiently justified, so neither is clearly better overall.)

LRU cache

Implement a class `LRUCache<K, V>` in TypeScript with a fixed capacity set in the constructor, and O(1) `get(key): V | undefined` and `set(key, value): void`. Accessing or updating a key must mark it most-recently-used; inserting beyond capacity must evict the least-recently-used entry. Return ONLY the class, no prose.

Kimi-K3: ```typescript class LRUCache<K, V> { private readonly capacity: number; private readonly cache: Map<K, V>; constructor(capacity: number) { this.capacity = capacity; this.cache = new Map<K, V>(); } get(key: K): V | undefined { const value = this.cache.get(key); if (value === undefined && !this.cache.has(key)) { return undefined; } this.cache.delete(key); this.cache.set(key, value as V); return value; } set(key: K, value: V): void { if (this.cache.has(key)) { this.cache.delete(key); } else if (this.cache.size >= this.capacity) { const oldestKey = this.cache.keys().next().value as K; this.cache.delete(oldestKey); } this.cache.set(key, value); } } ```

gpt-oss-120b: ```typescript class LRUCache<K, V> { private readonly capacity: number; private readonly map: Map<K, V>; constructor(capacity: number) { this.capacity = capacity; this.map = new Map<K, V>(); } get(key: K): V | undefined { if (!this.map.has(key)) return undefined; const value = this.map.get(key)!; // Move accessed entry to the end (most-recently-used) this.map.delete(key); this.map.set(key, value); return value; } set(key: K, value: V): void { if (this.capacity <= 0) return; if (this.map.has(key)) { this.map.delete(key); } this.map.set(key, value); if (this.map.size > this.capacity) { const lruKey = this.map.keys().next().value; this.map.delete(lruKey); } } } ```

Model B is better because it correctly handles zero or negative capacity by making set a no-op, while Model A can behave incorrectly by attempting to evict from an empty map and then inserting anyway. Both follow the requested API and achieve O(1) operations using Map insertion order, but Model B is slightly cleaner and more robust. (Second judge pass, order swapped — scores are the average of both: Model B correctly implements LRU behavior with O(1) operations using Map insertion order and safely handles nonpositive capacity by making set a no-op. Model A is mostly correct, but it fails for capacity 0 by evicting nothing before reinserting, allowing the cache to grow when it should hold no items.)

Concurrency bug fix

This TypeScript function is meant to memoize an async loader but has a race: concurrent callers can each trigger the underlying fetch. Fix it so the fetch runs at most once per key, and a rejected fetch does NOT poison the cache (a later call must retry). Return ONLY the corrected function. ```ts const cache = new Map<string, Promise<string>>(); async function load(key: string, fetcher: (k: string) => Promise<string>) { if (cache.has(key)) return cache.get(key)!; const value = await fetcher(key); cache.set(key, Promise.resolve(value)); return value; } ```

Kimi-K3: async function load(key: string, fetcher: (k: string) => Promise<string>) { const cached = cache.get(key); if (cached) return cached; const p = fetcher(key).catch((err) => { cache.delete(key); throw err; }); cache.set(key, p); return p; }

gpt-oss-120b: ```ts const cache = new Map<string, Promise<string>>(); async function load( key: string, fetcher: (k: string) => Promise<string> ): Promise<string> { // Return the already‑resolved or in‑flight promise if we have one let cached = cache.get(key); if (!cached) { // Start the fetch and store the in‑flight promise immediately const inFlight = fetcher(key); cache.set(key, inFlight); // When it settles, either replace with a resolved promise or delete on error cached = inFlight.then( (value) => { cache.set(key, Promise.resolve(value)); // cache the successful result return value; }, (err) => { cache.delete(key); // do not poison the cache on failure throw err; } ); } return cached; } ```

Model A correctly stores the in-flight promise before awaiting, ensuring only one fetch per key, and deletes the cache entry on rejection so later calls retry. Model B intends to do the same, but it returns a different promise than the one stored in the cache during the initial call and includes extra code fencing and declarations instead of returning only the corrected function. (Second judge pass, order swapped — scores are the average of both: Model A correctly stores the in-flight promise immediately and deletes it on rejection, so concurrent callers share one fetch and failures do not poison the cache. Model B has a subtle bug: it stores the raw in-flight promise in the cache but returns a different wrapped promise, so concurrent callers can receive a promise that remains cached even after rejection, violating the retry requirement; it also includes extra code outside the requested corrected function.)

Editing & proofreading

Rewrite the passage to fix grammar, punctuation, and clarity without changing meaning. Then provide 3 brief bullet points noting the main edits. Passage: "Our field team were on site Tuesday, however the generator inspection didn't start until 11:15 because security had not been told we was coming. The lead tech say the coolant line look stable, but there is vibrations near the south mount that needs a closer check. If parts is required, procurement can order them next week, this may delay restart by 2 days. Please advise whether operations want us to proceed or to pause repairs."

Kimi-K3: **Rewritten passage:** "Our field team was on site Tuesday; however, the generator inspection didn't start until 11:15 because security had not been told we were coming. The lead tech said the coolant line looks stable, but there are vibrations near the south mount that need a closer check. If parts are required, procurement can order them next week; this may delay the restart by two days. Please advise whether Operations wants us to proceed or pause repairs." **Main edits:** - **Subject–verb agreement:** Corrected "team were" → "team was," "we was" → "we were," "there is vibrations" → "there are vibrations," and "parts is" → "parts are." - **Comma splices and punctuation:** Added semicolons around "however" and between "next week" and "this may delay," since these joined independent clauses with only a comma. - **Tense and clarity:** Changed "tech say" → "tech said" for consistency, added "the" before "restart," spelled out "two days," and tightened the closing request to "proceed or pause repairs."

gpt-oss-120b: **Revised passage** Our field team was on site Tuesday; however, the generator inspection did not begin until 11:15 because security had not been informed that we were coming. The lead technician says the coolant line looks stable, but there are vibrations near the south mount that require a closer inspection. If parts are required, procurement can order them next week, although this may delay the restart by two days. Please advise whether operations would like us to proceed or pause the repairs. **Key edits** - Fixed subject‑verb agreement and pronoun errors (“team was,” “we were coming,” “technician says,” “parts are required”). - Added appropriate punctuation (semicolon, commas, period) to separate clauses and improve readability. - Clarified wording (“did not begin,” “requires a closer inspection,” “operations would like us to proceed or pause the repairs”).

Model A better preserves the original meaning while fixing grammar and punctuation cleanly; its edits are accurate and its bullet points directly reflect the main changes. Model B is strong, but it makes more substantive wording changes such as "had not been informed," "lead technician says," and "would like us to proceed," which slightly shifts tone and tense from the source. (Second judge pass, order swapped — scores are the average of both: Model B is better because it cleanly fixes the grammar, punctuation, and clarity while preserving meaning and providing exactly three brief edit notes. Model A is also strong, but it introduces a few less consistent choices, such as retaining quotation marks, capitalizing "Operations," and mixing tense choices in a way that is slightly less polished.)

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.

Kimi-K3: ```sql WITH ranked AS ( SELECT customer_id, total_cents, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY total_cents DESC) AS rn FROM orders ) SELECT c.name, ROUND(r.total_cents / 100.0, 2) AS second_largest_total FROM ranked r JOIN customers c ON c.id = r.customer_id WHERE r.rn = 2 ORDER BY second_largest_total DESC; ```

gpt-oss-120b: ```sql SELECT c.name, ROUND(o.total_cents / 100.0, 2) AS second_largest_order 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 DESC; ```

Model A correctly returns the second-highest order per customer using ROW_NUMBER, excludes customers with fewer than two orders, and orders the result properly. Model B uses DENSE_RANK, which returns the second-largest distinct total rather than the second order total, so it can incorrectly include customers with only one distinct order amount repeated and does not match the prompt as well. (Second judge pass, order swapped — scores are the average of both: Model A better matches the likely intent of "second-largest order total" by returning the second order amount per customer via ROW_NUMBER(), while excluding customers with fewer than two orders. Model B uses DENSE_RANK(), which instead returns the second-largest distinct total and can include customers who have multiple orders tied at the top value, so it is less correct for this prompt.)

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

Kimi-K3: **Conflicting sentences:** > "Archiving a project does not count against the project limit." > "Free accounts are limited to three projects total, including archived ones." **Conflict:** The first sentence states that archived projects are excluded from the project limit, while the second states that archived projects are included in the same three-project limit — an archived project cannot simultaneously count and not count toward the limit.

gpt-oss-120b: **Conflicting sentences** - “Archiving a project does not count against the project limit.” - “Free accounts are limited to three projects total, including archived ones.” **Explanation:** One sentence says archived projects are excluded from the limit, while the other says they are counted toward the three‑project cap, creating a direct contradiction.

Model A and Model B both identify the same two conflicting sentences verbatim and explain the contradiction accurately in one sentence without attempting to fix it. Model A is slightly more explicit, while Model B is slightly more concise, but neither is meaningfully better for this task. (Second judge pass, order swapped — scores are the average of both: Model B and Model A both identify the same two conflicting sentences verbatim and explain the contradiction accurately in one sentence without attempting to fix it. Model A is slightly more polished stylistically, but the task performance is effectively identical.)

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.

Kimi-K3: Listo: tu primera copia de seguridad empieza esta noche. (56)

gpt-oss-120b: Todo listo, tu primera copia empieza esta noche. (48)

Model B is more natural and concise for a friendly mobile toast in European Spanish, and it stays comfortably under the limit. Model A is accurate but sounds more formal and technical with "copia de seguridad," making it less toast-like. (Second judge pass, order swapped — scores are the average of both: Model B is more natural and concise for a friendly mobile toast in European Spanish while staying well under the limit. Model A is also correct, but "copia de seguridad" feels more cumbersome for this UI context and the punctuation makes it slightly less smooth.)

Information extraction

Extract the shipment records below into a JSON array. For each record, return: `tracking_id`, `customer`, `ship_date` (YYYY-MM-DD), `city`, `items` (array of item names), `fragile` (true/false), and `delivery_window` (exact text like `9am-1pm` or null). Be accurate and include all records. Messy notes: - 04/17/2026 — TRK-8831A :: Customer=Meridian Dental Lab, drop to Boise. Contents: "chair arm kit" x2; "sterile tray". Mark FRAGILE. Window 9am-1pm. - Apr 18 2026 | tracking TRK-8832A | for Nila Cortez | city: Reno | items: desk lamp, shade | no frag | leave at reception. - 2026-04-18 / id=TRK-8833A / customer "Pine & Dock LLC" / destination Spokane / contents: 4x ceramic mug / fragile=yes / delivery after 3pm. - 4-19-2026 ; TRK-8834A ; customer: Orson Biotech ; to Eugene ; items = coolant pack, sensor cable, sensor cable ; fragile: no ; window: 8:30am-10am.

Kimi-K3: ```json [ { "tracking_id": "TRK-8831A", "customer": "Meridian Dental Lab", "ship_date": "2026-04-17", "city": "Boise", "items": ["chair arm kit", "chair arm kit", "sterile tray"], "fragile": true, "delivery_window": "9am-1pm" }, { "tracking_id": "TRK-8832A", "customer": "Nila Cortez", "ship_date": "2026-04-18", "city": "Reno", "items": ["desk lamp", "shade"], "fragile": false, "delivery_window": null }, { "tracking_id": "TRK-8833A", "customer": "Pine & Dock LLC", "ship_date": "2026-04-18", "city": "Spokane", "items": ["ceramic mug", "ceramic mug", "ceramic mug", "ceramic mug"], "fragile": true, "delivery_window": null }, { "tracking_id": "TRK-8834A", "customer": "Orson Biotech", "ship_date": "2026-04-19", "city": "Eugene", "items": ["coolant pack", "sensor cable", "sensor cable"], "fragile": false, "delivery_window": "8:30am-10am" } ] ``` **Notes on judgment calls:** - **Quantities:** `x2` and `4x` were expanded into repeated array entries (matching how "sensor cable, sensor cable" is listed explicitly in record 4). If you'd rather list each item name only once, I can collapse duplicates. - **TRK-8832A:** "leave at reception" is a drop-off instruction, not a time window → `null`. - **TRK-8833A:** "delivery after 3pm" is a one-sided time constraint, not a window range like `9am-1pm`, so I set `null`. If you'd prefer to capture it as `"after 3pm"`, that's a one-line change.

gpt-oss-120b: ```json [ { "tracking_id": "TRK-8831A", "customer": "Meridian Dental Lab", "ship_date": "2026-04-17", "city": "Boise", "items": [ "chair arm kit", "chair arm kit", "sterile tray" ], "fragile": true, "delivery_window": "9am-1pm" }, { "tracking_id": "TRK-8832A", "customer": "Nila Cortez", "ship_date": "2026-04-18", "city": "Reno", "items": [ "desk lamp", "shade" ], "fragile": false, "delivery_window": null }, { "tracking_id": "TRK-8833A", "customer": "Pine & Dock LLC", "ship_date": "2026-04-18", "city": "Spokane", "items": [ "ceramic mug", "ceramic mug", "ceramic mug", "ceramic mug" ], "fragile": true, "delivery_window": "after 3pm" }, { "tracking_id": "TRK-8834A", "customer": "Orson Biotech", "ship_date": "2026-04-19", "city": "Eugene", "items": [ "coolant pack", "sensor cable", "sensor cable" ], "fragile": false, "delivery_window": "8:30am-10am" } ] ```

Model A is better because it correctly treats the one-sided constraint "after 3pm" as not matching the requested delivery-window format examples and sets it to null, while Model B inserts a value that does not fit the specified pattern. Both extract all records accurately, but Model A shows slightly better adherence to the schema despite adding extra explanatory text outside the JSON. (Second judge pass, order swapped — scores are the average of both: Model B is better because it includes all four records in valid JSON and captures the explicit delivery constraint for TRK-8833A as the exact text "after 3pm," which aligns with the schema asking for exact delivery-window text or null. Model A is also strong, but it drops that available field value and adds extra explanatory notes outside the requested JSON-only output.)

Debugging & code review

Language: JavaScript The function should group invoice lines by SKU and sum qty*unitPrice into cents, returning an object like {"A12": 1234, ...}. It fails on some realistic inputs. Find the bug(s), fix them, and return the corrected code only. ```js function totalsBySku(lines) { const out = {}; for (const line in lines) { const sku = line.sku.trim(); const qty = parseInt(line.qty, 10) || 0; const priceCents = Math.round(parseFloat(line.unitPrice) * 100) || 0; if (!out[sku]) out[sku] = 0; out[sku] += qty + priceCents; } return out; } const lines = [ { sku: ' A12 ', qty: '2', unitPrice: '3.50' }, { sku: 'B07', qty: '1', unitPrice: '10.00' }, { sku: 'A12', qty: '3', unitPrice: '3.50' } ]; console.log(totalsBySku(lines)); ```

Kimi-K3: ```js function totalsBySku(lines) { const out = {}; for (const line of lines) { const sku = line.sku.trim(); const qty = parseInt(line.qty, 10) || 0; const priceCents = Math.round(parseFloat(line.unitPrice) * 100) || 0; if (!Object.prototype.hasOwnProperty.call(out, sku)) out[sku] = 0; out[sku] += qty * priceCents; } return out; } const lines = [ { sku: ' A12 ', qty: '2', unitPrice: '3.50' }, { sku: 'B07', qty: '1', unitPrice: '10.00' }, { sku: 'A12', qty: '3', unitPrice: '3.50' } ]; console.log(totalsBySku(lines)); // { A12: 1750, B07: 1000 } ```

gpt-oss-120b: ```js function totalsBySku(lines) { const out = {}; for (const line of lines) { // iterate over elements, not indices const sku = (line.sku || '').trim(); // safe fallback and trim if (!sku) continue; // skip lines without a SKU const qty = parseInt(line.qty, 10) || 0; const priceCents = Math.round((parseFloat(line.unitPrice) || 0) * 100); if (!out[sku]) out[sku] = 0; out[sku] += qty * priceCents; // multiply, not add } return out; } /* example */ const lines = [ { sku: ' A12 ', qty: '2', unitPrice: '3.50' }, { sku: 'B07', qty: '1', unitPrice: '10.00' }, { sku: 'A12', qty: '3', unitPrice: '3.50' } ]; console.log(totalsBySku(lines)); // { A12: 1750, B07: 1000 } ```

Model B is better because it fixes the core bugs and also handles realistic bad inputs more safely by guarding missing or blank SKUs. Model A corrects the iteration and multiplication issues, but it can still throw if a line lacks a valid sku property. (Second judge pass, order swapped — scores are the average of both: Model B fixes both core bugs: iterating array elements correctly and summing qty * unitPrice in cents rather than qty + priceCents; it also adds reasonable guards for missing SKU and invalid price input. Model A fixes the iteration and multiplication bug but is less robust on realistic inputs because it still assumes line.sku is always present and valid.)

Algorithm & data structures

Implement in Python a class `RollingMedian` for a stream of integers with methods: - `add(x: int) -> None` - `median() -> float` Requirements: - `add` must be O(log n) - `median` must be O(1) - If there are an even number of items, return the average of the two middle values as a float. - Handle negatives and duplicates. - Return code only, no explanation. Example behavior: add(5), add(1), median() -> 3.0 add(9), median() -> 5.0 add(1), median() -> 3.0

Kimi-K3: ```python import heapq class RollingMedian: def __init__(self): self._lo = [] # max-heap (stores negated values) self._hi = [] # min-heap def add(self, x: int) -> None: heapq.heappush(self._lo, -x) if self._hi and -self._lo[0] > self._hi[0]: heapq.heappush(self._hi, -heapq.heappop(self._lo)) while len(self._lo) > len(self._hi) + 1: heapq.heappush(self._hi, -heapq.heappop(self._lo)) while len(self._hi) > len(self._lo): heapq.heappush(self._lo, -heapq.heappop(self._hi)) def median(self) -> float: if not self._lo: raise IndexError("median of empty stream") if len(self._lo) > len(self._hi): return float(-self._lo[0]) return (-self._lo[0] + self._hi[0]) / 2.0 ```

gpt-oss-120b: ```python import heapq from typing import List class RollingMedian: def __init__(self) -> None: # max‑heap for the lower half (store negatives) self._low: List[int] = [] # min‑heap for the upper half self._high: List[int] = [] def add(self, x: int) -> None: # Insert into appropriate heap if not self._low or x <= -self._low[0]: heapq.heappush(self._low, -x) else: heapq.heappush(self._high, x) # Rebalance so lengths differ by at most 1 if len(self._low) > len(self._high) + 1: heapq.heappush(self._high, -heapq.heappop(self._low)) elif len(self._high) > len(self._low) + 1: heapq.heappush(self._low, -heapq.heappop(self._high)) def median(self) -> float: if not self._low and not self._high: raise IndexError("median from empty RollingMedian") if len(self._low) > len(self._high): return float(-self._low[0]) if len(self._high) > len(self._low): return float(self._high[0]) # even number of elements return (-self._low[0] + self._high[0]) / 2.0 ```

Model A correctly maintains the invariant that all lower-half elements are <= all upper-half elements and keeps the heaps balanced, so median() is correct in O(1) after O(log n) insertion. Model B can return incorrect medians because its rebalancing allows the upper heap to have more elements without ensuring the lower heap holds the extra item, violating the ordering/size invariant needed for correct median computation. (Second judge pass, order swapped — scores are the average of both: Model B cleanly maintains the two-heap invariant and correctly handles odd and even counts with O(log n) insertion and O(1) median lookup. Model A is close, but its insertion logic can leave an out-of-order partition when the upper heap is empty and a larger value is added after a smaller one, producing an incorrect median.)

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

Kimi-K3: 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 was -> he and I were suprised -> surprised quite -> quiet

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 → he, him → I, was → were, suprised → surprised, quite → quiet

Model A better follows the requested format by putting the corrected sentence on one line and listing each change on separate subsequent lines exactly as 'was -> now'. Model B’s correction is also accurate, but it compresses all changes onto one line, uses a different arrow symbol, and splits the phrase-level change into token-level edits rather than preserving the requested listing style as closely. (Second judge pass, order swapped — scores are the average of both: Model A is better because it follows the required second-line change listing format more closely, using separate 'was -> now' entries and correctly grouping the linked grammar change. Model B’s correction is accurate, but its change list is compressed onto one line and splits the coordinated grammar fix less cleanly.)