Head to head: Kimi K3 vs Z.ai: GLM 5.3

Kimi K3 vs Z.ai: GLM 5.3

By Ryan Merket · Published Aug 19, 2026, 8:29pm CT

A near-dead heat on aggregate score conceals a far more lopsided task-by-task contest. The difference comes down to precision, format discipline, and whether each model catches the prompt’s least obvious constraint.

The topline scores—112.5 for GLM 5.3 and 111.8 for Kimi K3—are effectively neck and neck, but they obscure the stronger signal: Kimi won seven tasks to GLM’s one, with four ties. The paired statistical verdict gives Kimi a decisive 98% confidence advantage, so GLM’s 0.7-point aggregate edge does not make it the better all-around performer here. Kimi’s wins were rarely flashy; they came from reading the entire brief. It preserved exact output formatting in localization and proofreading, covered the separate invoice-PDF issue in meeting notes, retained technical nuance in dense summarization, and produced a customer email without unresolved placeholders. Its concurrency fix was also more robust, using an identity check so stale rejection cleanup could not delete a replacement cache entry. GLM’s sole win mattered: it correctly recognized that the clinic-shift constraints were impossible, while Kimi returned a schedule that violated the required Priya-before-Lin ordering. Elsewhere, however, GLM repeatedly lost on small but real execution details—telegraphic classification reasons, less precise wording, multi-line output where one line was requested, and an email that was not ready to send. Both models also shared avoidable compliance blemishes, notably wrapping JSON in Markdown fences. **Final call: Kimi K3 wins. The aggregate totals are too close to suggest a raw capability gap, but the 7–1 task record and 98% confidence make Kimi the decisively more reliable model across this test set.**

invoice-fact-extraction

Extract the requested fields from this messy note and return ONLY valid JSON with keys: vendor, invoice_number, issue_date, due_date, currency, subtotal, tax, total, po_number, bill_to_email, ship_to_city, line_items (array of {description, qty, unit_price}). Text: "Fwd: AP cleanup — please pay soon. Vendor: North Lantern Office Supply LLC // inv no. NL-48217-A. Issued 2026-02-11; terms Net 21, so due Mar 4, 2026. Bill to: Ridgeway Clinics, AP <[email protected]>. Ship-to: 88 Vale St., Duluth, MN. PO# RC-7719. Items: 4 x ergonomic keyboard wrist rests @ $18.50; 2 x USB-C docks (dual HDMI) @ $94.00; 1 x cable organizer kit @ $27. Tax 7.875%. Subtotal noted in margin as USD 289.00, tax USD 22.76, grand total USD 311.76. Ignore scribble: 'old invoice NL-47002 voided'."

Kimi K3: ```json { "vendor": "North Lantern Office Supply LLC", "invoice_number": "NL-48217-A", "issue_date": "2026-02-11", "due_date": "2026-03-04", "currency": "USD", "subtotal": 289.00, "tax": 22.76, "total": 311.76, "po_number": "RC-7719", "bill_to_email": "[email protected]", "ship_to_city": "Duluth", "line_items": [ { "description": "ergonomic keyboard wrist rests", "qty": 4, "unit_price": 18.50 }, { "description": "USB-C docks (dual HDMI)", "qty": 2, "unit_price": 94.00 }, { "description": "cable organizer kit", "qty": 1, "unit_price": 27.00 } ] } ```

Z.ai: GLM 5.3: ```json { "vendor": "North Lantern Office Supply LLC", "invoice_number": "NL-48217-A", "issue_date": "2026-02-11", "due_date": "2026-03-04", "currency": "USD", "subtotal": 289.00, "tax": 22.76, "total": 311.76, "po_number": "RC-7719", "bill_to_email": "[email protected]", "ship_to_city": "Duluth", "line_items": [ { "description": "ergonomic keyboard wrist rests", "qty": 4, "unit_price": 18.50 }, { "description": "USB-C docks (dual HDMI)", "qty": 2, "unit_price": 94.00 }, { "description": "cable organizer kit", "qty": 1, "unit_price": 27.00 } ] } ```

Model A and Model B are identical and extract every requested field accurately. Both slightly miss the instruction to return only valid JSON because the JSON is wrapped in Markdown code fences. (Second judge pass, order swapped — scores are the average of both: Model B and Model A are identical and extract every requested field correctly; both have the same minor instruction-following issue of wrapping the JSON in Markdown code fences rather than returning only raw JSON.)

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: Ya está. Tu primera copia de seguridad empieza esta noche. (58)

Z.ai: GLM 5.3: Ya está: tu primera copia de seguridad empieza esta noche. (58 characters)

Model A provides a natural European Spanish translation and follows the requested count format exactly. Model B is equally natural and accurate, but “(58 characters)” is less faithful to the instruction to return the character count in parentheses. (Second judge pass, order swapped — scores are the average of both: Model A follows the requested output format more precisely by giving only the translation and a parenthesized number. Both translations are accurate, natural, friendly, exactly 58 characters long, and contain no exclamation marks, though Model A’s sentence break reads slightly more naturally than Model B’s colon.)

meeting-notes-summary

Summarize the meeting notes below in EXACTLY 4 bullet points, each 10-16 words, with no intro or conclusion. Notes: "Ops/Eng sync, 7 May. Checkout slowdown traced to image-resizing service saturating CPU on two nodes after a catalog import. Team temporarily disabled high-resolution thumbnail generation, which restored median checkout latency from 4.8s to 1.3s. Permanent fix: move resizing jobs to async queue and cap worker concurrency; owner is Nia, target 16 May. Finance asked whether delayed invoice PDFs are related; answer: no, that issue comes from a separate template rendering timeout. Support has 14 open tickets tied to checkout slowness; Eli will send a customer-facing update by 3 p.m. Legal reminder: avoid saying 'outage' because transactions still processed."

Kimi K3: - Image-resizing CPU saturation slowed checkout; disabling high-res thumbnails restored median latency from 4.8s to 1.3s. - Permanent fix: move resizing to async queue and cap worker concurrency; Nia owns, target 16 May. - Delayed invoice PDFs unrelated—separate template timeout; Eli updating customers on 14 tickets by 3 p.m. - Legal reminder: avoid the word "outage" since transactions continued processing.

Z.ai: GLM 5.3: - Checkout slowdown traced to image-resizing service saturating CPU on two nodes after catalog import. - Temporarily disabling high-resolution thumbnails restored median checkout latency from 4.8s to 1.3s. - Permanent fix: Nia to move resizing to async queue with capped concurrency by 16 May. - Eli will update customers on 14 open tickets by 3 p.m.; Legal says avoid "outage."

Model A satisfies the exact bullet and word-count constraints while covering the separate invoice-PDF issue. Model B also follows the format precisely but omits that clarification and devotes more space to incident details. (Second judge pass, order swapped — scores are the average of both: Both models satisfy the exact bullet-count and word-count requirements while accurately summarizing the notes. Model A is better because it includes the separate invoice-PDF issue and the reason for avoiding “outage,” providing broader coverage than Model B.)

Nuanced classification

Classify each review's sentiment as "positive", "negative", or "mixed", and give a 6-word-max reason. Return ONLY a JSON array of {"text","label","reason"} in input order. Reviews: ["Fast shipping but the fabric feels cheap.", "Absolutely love it, wearing it daily!", "It broke after a week. Refund was quick and painless though."]

Kimi K3: ```json [ {"text": "Fast shipping but the fabric feels cheap.", "label": "mixed", "reason": "Praises shipping, criticizes fabric quality."}, {"text": "Absolutely love it, wearing it daily!", "label": "positive", "reason": "Loves product, wears it daily."}, {"text": "It broke after a week. Refund was quick and painless though.", "label": "mixed", "reason": "Product broke; refund process praised."} ] ```

Z.ai: GLM 5.3: ```json [ {"text": "Fast shipping but the fabric feels cheap.", "label": "mixed", "reason": "Fast shipping positive, cheap fabric negative"}, {"text": "Absolutely love it, wearing it daily!", "label": "positive", "reason": "Enthusiastic daily use, clearly delighted"}, {"text": "It broke after a week. Refund was quick and painless though.", "label": "mixed", "reason": "Product broke negative, easy refund positive"} ] ```

Model A and Model B classify every review correctly and keep all reasons within six words, but both improperly use code fences. Model A has more natural, polished reasons than Model B’s slightly telegraphic phrasing. (Second judge pass, order swapped — scores are the average of both: Model B and Model A classify every review correctly and keep all reasons within six words. Model A has slightly more natural, polished phrasing, though both improperly add Markdown fences instead of returning only the JSON array.)

Summarize dense passage

Summarize the passage below in exactly three bullet points, each one sentence, capturing the mechanism, the tradeoff, and the caveat — no jargon a non-specialist couldn't follow. Return only the bullets. Passage: "Speculative decoding pairs a small draft model with a large target model: the draft proposes several tokens, the target verifies them in one pass, and accepted tokens are kept while the first rejection resets to the target's own choice. This can cut latency substantially when acceptance is high, but the draft model's compute is pure overhead when acceptance is low, and gains evaporate on adversarial or highly novel inputs where the draft and target disagree often."

Kimi K3: - **Mechanism:** A small, fast model writes a short stretch of draft text, then the large model checks it all in a single pass, keeping every piece it agrees with and replacing the first one it disputes with its own choice. - **Tradeoff:** When the small model's guesses are usually right this saves a lot of time, but when they're usually wrong the small model's work is entirely wasted effort. - **Caveat:** The speedup disappears on tricky or highly unfamiliar material where the two models disagree often.

Z.ai: GLM 5.3: - A small, fast model makes quick guesses at the next few words, and a larger model checks all the guesses in one go, keeping the correct ones and fixing the first mistake. - This speeds things up a lot when the small model guesses well, but its work becomes wasted time when it guesses poorly. - The speedup can disappear on unusual or deliberately tricky text, where the two models often disagree.

Model A is slightly more precise because it describes the large model accepting text it agrees with rather than calling accepted guesses objectively correct, while still clearly covering the mechanism, tradeoff, and caveat. Model B is concise and accessible but loses a small amount of technical accuracy with “correct ones” and “first mistake.” (Second judge pass, order swapped — scores are the average of both: Model A is slightly more precise because it describes the larger model as accepting guesses it agrees with, whereas Model B calls them “correct,” which could imply objective correctness rather than agreement between models. Both models follow the three-bullet, one-sentence-per-bullet format and use clear, accessible language.)

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: ```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 promise = fetcher(key); cache.set(key, promise); try { return await promise; } catch (err) { if (cache.get(key) === promise) cache.delete(key); throw err; } } ```

Z.ai: GLM 5.3: ```ts const cache = new Map<string, Promise<string>>(); 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); // evict on failure so a later call retries throw err; }); cache.set(key, p); return p; } ```

Model A correctly caches the in-flight promise and evicts it on rejection, while its identity check prevents accidentally deleting a replacement entry. Model B is also correct under normal use, but unconditional deletion is slightly less robust if the cache entry is replaced before the rejection handler runs. (Second judge pass, order swapped — scores are the average of both: Model A correctly caches the in-flight promise and conditionally removes it on rejection, preventing stale cleanup from deleting a newer entry. Model B is also correct in the shown context, but its unconditional deletion is slightly less robust; both include the cache declaration despite the request for only the corrected function.)

support-ticket-labeling

Classify each ticket into one category: Billing, Bug, Feature Request, Account Access, or How-To. Return a Markdown table with columns Ticket, Category, Justification. Tickets: (A) "I was charged twice for invoice QN-204 after updating my card." (B) "The Android app closes every time I tap Export CSV on version 5.2.1." (C) "Can you add an option to auto-archive projects after 90 days of inactivity?" (D) "I’m not receiving the sign-in code at my backup email and I’m locked out." (E) "Where do I change the default timezone for reports in the admin console?"

Kimi K3: | Ticket | Category | Justification | |--------|----------|---------------| | A | Billing | Reports a duplicate charge on a specific invoice after a card update — a payment/charge issue. | | B | Bug | The app crashes (closes unexpectedly) on a specific action and version — defective behavior, not a request or question. | | C | Feature Request | Asks for a new capability (auto-archive after 90 days) that doesn't currently exist. | | D | Account Access | User is locked out and cannot receive the sign-in code — an authentication/login problem. | | E | How-To | Asks where/how to change a setting (default timezone) — needs instructions, not a fix or new feature. |

Z.ai: GLM 5.3: | Ticket | Category | Justification | |--------|----------|---------------| | A | Billing | Reports a duplicate charge on a specific invoice (QN-204), requiring a payment review or refund. | | B | Bug | Describes a reproducible app crash (closes when tapping Export CSV) on a specific version, indicating defective behavior. | | C | Feature Request | Asks for new functionality (auto-archiving projects after 90 days of inactivity) that doesn't currently exist. | | D | Account Access | User is locked out because the sign-in verification code isn't arriving — an authentication/login issue. | | E | How-To | Asks where to locate and change an existing setting (default report timezone) in the admin console; seeking guidance, not reporting a problem. |

Model A and Model B classify all five tickets correctly, follow the requested Markdown table format, and provide concise, accurate justifications. Neither output has a meaningful quality advantage. (Second judge pass, order swapped — scores are the average of both: Model B and Model A classify all five tickets correctly, follow the required Markdown table format, and provide clear, concise justifications. Neither output has a meaningful quality advantage.)

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." **Explanation:** The first sentence exempts archived projects from the three-project limit, while the second explicitly counts archived projects toward that same limit, so an archived project simultaneously does and does not consume quota.

Z.ai: GLM 5.3: **Conflicting sentences:** 1. "Archiving a project does not count against the project limit." 2. "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 the three-project limit for free accounts includes archived projects, so they cannot both be true.

Model A and Model B both quote the correct conflicting sentences verbatim and accurately explain the contradiction in one sentence without attempting to fix it. Both are clear, concise, and fully compliant with the prompt. (Second judge pass, order swapped — scores are the average of both: Model B and Model A both quote the two conflicting sentences verbatim and accurately explain the contradiction in a single clear sentence without attempting to fix it.)

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

Z.ai: GLM 5.3: 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 -> he and I - was -> were - suprised -> surprised - quite -> quiet

Model A provides the correct sentence and lists all changes on a single second line as requested, while Model B gives the same correct edits but spreads the change list across multiple bulleted lines. (Second judge pass, order swapped — scores are the average of both: Model A provides the correct sentence and lists every change on the requested second line. Model B makes the same correct edits but spreads the change list across multiple bulleted lines, slightly missing the specified format.)

customer-delay-email

Write a customer email from a hardware store support team to a buyer named Elise Rowan. Situation: her order for a GlacierBlue 24-inch induction range (order HB-93841) was supposed to ship today, but the carrier damaged the outbound pallet during loading. Replacement stock arrives at the warehouse on 18 September and can ship within 2 business days after that. Offer two options: keep the order with free threshold delivery upgrade, or cancel for a full refund. Tone: apologetic, calm, professional. Audience: customer. Length: 110-140 words. Include a clear subject line.

Kimi K3: **Subject:** Update on Your Order HB-93841 – Shipping Delay Dear Ms. Rowan, I'm very sorry to let you know that your GlacierBlue 24-inch induction range (order HB-93841) will not ship today as scheduled. During loading, the carrier damaged the outbound pallet, and the appliance can no longer be sent safely. Replacement stock arrives at our warehouse on 18 September and can ship within two business days of arrival. You have two options: 1. Keep your order, and we'll add a free threshold delivery upgrade to apologize for the wait. 2. Cancel for a full refund, which we'll process right away. Simply reply to this email with your preference, and we'll handle everything from there. We sincerely apologize for the inconvenience and appreciate your patience. Kind regards, The HomeBase Hardware Customer Support Team

Z.ai: GLM 5.3: **Subject: Important Update on Order HB-93841 (GlacierBlue 24-Inch Induction Range)** Dear Elise Rowan, We're very sorry to let you know that your order HB-93841, the GlacierBlue 24-inch induction range, has been unexpectedly delayed. It was due to ship today; unfortunately, the carrier damaged the outbound pallet during loading, and we won't risk sending an appliance that may have been affected. Replacement stock arrives at our warehouse on 18 September and will ship within two business days afterward. You have two options: 1. **Keep your order**, and we'll upgrade you to threshold delivery at no charge. 2. **Cancel** for a full refund to your original payment method. We sincerely apologize for the inconvenience and appreciate your patience. Please reply with your preference, or call us at [phone number] — we're glad to assist either way. Warm regards, The [Store Name] Support Team

Model A fully covers the delay, cause, revised timing, and both remedies in a polished email within the requested length. Model B is similarly accurate, but its unresolved placeholders for the phone number and store name make it less customer-ready and it may slightly exceed the word limit depending on counting. (Second judge pass, order swapped — scores are the average of both: Model A fully covers the delay, replacement timeline, and both customer options in a polished email within the requested length. Model B is also strong, but its unresolved placeholders for the phone number and store name make it less ready to send.)

clinic-shift-assignment

Assign exactly one person to each shift and return ONLY JSON as {"Mon_AM":"...","Mon_PM":"...","Tue_AM":"...","Tue_PM":"..."}. Staff: Priya, Mateo, Lin, Zoe. Constraints: (1) Each person works exactly one shift. (2) Priya cannot work Monday. (3) Mateo can only work a PM shift. (4) Lin cannot work Tue_PM. (5) Zoe cannot work Mon_PM. (6) Tue_AM must be covered by either Priya or Lin. (7) Mon_PM must be covered by Mateo or Zoe. (8) Priya works earlier in the week than Lin. There is exactly one valid schedule.

Kimi K3: {"Mon_AM":"Lin","Mon_PM":"Mateo","Tue_AM":"Priya","Tue_PM":"Zoe"}

Z.ai: GLM 5.3: {"error":"No valid schedule exists"}

Model A violates the requirement that Priya work earlier in the week than Lin, since Lin is assigned Monday and Priya Tuesday. Model B correctly recognizes that Priya must work Tue_AM, which leaves no later permissible shift for Lin, though Model B does not use the requested schedule schema. (Second judge pass, order swapped — scores are the average of both: Model B correctly identifies that no schedule can satisfy both Priya working earlier than Lin and the other Tuesday restrictions, though Model B does not use the requested assignment schema. Model A uses the requested schema but violates the requirement that Priya work earlier in the week than Lin.)

warehouse-restock-math

A café manager is planning a 6-day restock for bottled cold brew. Daily sales forecast is: Mon 18, Tue 23, Wed 19, Thu 27, Fri 31, Sat 22 bottles. Starting inventory Monday morning is 42 bottles. A supplier delivery of 36 bottles arrives before opening on Thursday. The café requires a safety stock of 12 bottles at the end of Saturday. What is the MINIMUM number of bottles the manager must order to arrive before opening on Monday? Show your calculation briefly, then give the final number.

Kimi K3: ## Calculation **Total 6-day demand:** 18 + 23 + 19 + 27 + 31 + 22 = **140 bottles** **Total available without a new order:** Starting inventory 42 + Thursday delivery 36 = **78 bottles** **Required total supply:** Demand + safety stock = 140 + 12 = **152 bottles** **Minimum Monday order:** 152 − 78 = **74 bottles** ## Verification (day-by-day with 74 bottles) | Day | Start (+delivery) | Sold | End | |-----|------------------|------|-----| | Mon | 42 + 74 = 116 | 18 | 98 | | Tue | 98 | 23 | 75 | | Wed | 75 | 19 | 56 | | Thu | 56 + 36 = 92 | 27 | 65 | | Fri | 65 | 31 | 34 | | Sat | 34 | 22 | **12** ✓ | ## Answer: **74 bottles**

Z.ai: GLM 5.3: # Calculation **Total demand (Mon–Sat):** 18 + 23 + 19 + 27 + 31 + 22 = **140 bottles** **Total supply available (without new order):** - Starting inventory: 42 - Thursday delivery: +36 - Total: **78 bottles** **Required ending position:** 140 (sales) + 12 (safety stock) = **152 bottles needed** **Order required:** 152 − 78 = **74 bottles** **Quick check (with 74 ordered Monday):** - Wed end: 42 + 74 − 18 − 23 − 19 = 56 ✓ - Thu morning: 56 + 36 = 92 → Thu end: 92 − 27 = 65 - Fri end: 65 − 31 = 34 - Sat end: 34 − 22 = 12 ✓ (meets safety stock exactly) ## Final Answer: **74 bottles**

Model A and Model B both correctly calculate total demand, account for starting inventory and the Thursday delivery, preserve the required Saturday safety stock, and arrive at the minimum order of 74 bottles. Both follow the request with clear, concise calculations and a valid inventory check. (Second judge pass, order swapped — scores are the average of both: Model B and Model A are both fully correct and clearly verify the 74-bottle minimum, but Model B is slightly better because its calculation is more concise and better matches the request to show the work briefly.)