Head to head: Muse Spark 1.1 vs Kimi-K2.7-Code

Muse Spark 1.1 vs Kimi-K2.7-Code

This one is effectively even. Muse Spark 1.1 and Kimi-K2.7-Code trade narrow wins on formatting, coding, and language tasks, and the aggregate gap is small enough that calling a real leader would be overstating the evidence.

The topline number says Kimi-K2.7-Code is ahead, 101.8 to 97.7. The stats say not so fast. At **62% confidence** that either model is genuinely better, this matchup is a dead heat in any honest editorial framing. There is no defensible winner here—just two models landing in the same performance band and splitting hairs on task-specific details. Muse Spark 1.1 had the cleaner edge on instruction discipline and a few high-value practical tasks. It was better on **support-ticket labeling**, **summarizing a dense passage**, **SQL window query**, and **precise proofreading**, mostly by sticking closer to the requested format and keeping prose more accessible. Its strongest substantive win came on the **concurrency bug fix**, where it handled in-flight promise memoization and cache cleanup more safely, while Kimi’s answer had a meaningful implementation caveat and formatting sloppiness. Kimi-K2.7-Code answered with wins in places that matter too: **nuanced classification**, **Mexican Spanish ops translation**, **warehouse restock math**, and **Python log redaction**. The translation result was notably more natural in workplace Spanish, and on the redaction task Kimi’s code was judged the stronger implementation in one pass. That said, several of these wins were razor-thin—and the order-swapped judge passes repeatedly undercut any claim that one model consistently outclassed the other. Just as important, three tasks were outright ties: **clinic shift assignment**, **constraint scheduling**, and **messy expense extraction**. And across the full slate, the pattern is not dominance but alternation. Muse looked a bit more reliable when exact output format and editorial restraint mattered; Kimi looked a bit sharper on concision, natural phrasing, and some coding/math tasks. The problem for anyone trying to crown a champion is simple: the evidence never separates them for long. **Final call: too close to call. Muse Spark 1.1 and Kimi-K2.7-Code are effectively even in this matchup, and declaring a winner would be more confidence than the results justify.**

support-ticket-labeling

Classify each support ticket into one category: `billing`, `bug`, `feature_request`, `account_access`, or `how_to`. Return a JSON array of objects with keys `id`, `category`, `justification`. Tickets: 1. `T-901`: `I was charged twice for the Pro plan after changing cards yesterday.` 2. `T-902`: `Where do I export all responses as CSV? I can't find the menu in the new dashboard.` 3. `T-903`: `After I click Save on the shift template, the page spins forever in Firefox 128 on Ubuntu.` 4. `T-904`: `Can you add a way to lock a form after 200 submissions instead of closing it manually?` 5. `T-905`: `My sign-in link expires instantly and password reset emails never arrive.` 6. `T-906`: `Need help setting automatic weekly email summaries for store managers.`

Muse Spark 1.1: [ { "id": "T-901", "category": "billing", "justification": "User reports being charged twice for the Pro plan after changing payment cards - a payment/billing issue." }, { "id": "T-902", "category": "how_to", "justification": "User asks how to perform an existing task (export responses as CSV) and cannot find the menu in the new dashboard - needs guidance, not reporting broken behavior." }, { "id": "T-903", "category": "bug", "justification": "Reproducible defect: Save action on shift template causes infinite spinner in Firefox 128 on Ubuntu." }, { "id": "T-904", "category": "feature_request", "justification": "User explicitly asks to add new capability to automatically lock a form after 200 submissions instead of manual closing." }, { "id": "T-905", "category": "account_access", "justification": "User cannot sign in because sign-in link expires instantly and password reset emails never arrive - an authentication/access problem." }, { "id": "T-906", "category": "how_to", "justification": "User needs help configuring existing functionality (automatic weekly email summaries for store managers) - an instructions/how-to request." } ]

Kimi-K2.7-Code: ```json [ { "id": "T-901", "category": "billing", "justification": "The user reports being charged twice for a plan after updating their payment card, which is a payment/billing issue." }, { "id": "T-902", "category": "how_to", "justification": "The user is asking where to find the CSV export menu in the new dashboard, which is a product usage question." }, { "id": "T-903", "category": "bug", "justification": "The user reports that clicking Save on a shift template causes an infinite loading spinner in a specific browser/OS, indicating a software defect." }, { "id": "T-904", "category": "feature_request", "justification": "The user is asking for a new capability to automatically lock a form after a submission limit, rather than doing it manually." }, { "id": "T-905", "category": "account_access", "justification": "The user is unable to sign in because magic links expire immediately and password reset emails do not arrive, which blocks account access." }, { "id": "T-906", "category": "how_to", "justification": "The user needs guidance on configuring automatic weekly email summaries, which is a setup/configuration question." } ] ```

Both outputs classify all tickets correctly with clear justifications. Model A is slightly better because it follows the requested output format exactly, while Model B wraps the JSON in a Markdown code fence instead of returning only raw JSON. (Order-swapped judge pass: Both outputs classify all six tickets correctly, follow the requested JSON structure with the required keys, and provide clear justifications. Model A wraps the array in a code block in its displayed output, while Model B does not, but both substantive answers are equally strong for the task.)

clinic-shift-assignment

Assign each person to exactly one role for Tuesday morning at a small clinic: Triage, Vaccines, Phones, Inventory. People: Amina, Bruno, Celia, Dev. Use all four people once. Constraints: 1) Amina cannot do Phones. 2) Bruno must be either Triage or Inventory. 3) Celia cannot do Vaccines. 4) Dev must be scheduled later alphabetically than Bruno's role, using role order: Inventory, Phones, Triage, Vaccines. 5) Triage is not Amina. 6) Phones is not Celia. 7) Inventory is not Dev. Return just the final assignment as `Amina=..., Bruno=..., Celia=..., Dev=...`

Muse Spark 1.1: Amina=Vaccines, Bruno=Inventory, Celia=Triage, Dev=Phones

Kimi-K2.7-Code: Amina=Vaccines, Bruno=Inventory, Celia=Triage, Dev=Phones

Both outputs are identical, satisfy all constraints, and match the required response format exactly. There is no quality difference between them. (Order-swapped judge pass: Both outputs are identical and incorrect: with Bruno=Inventory, Dev must be later alphabetically than Inventory, but Dev=Phones violates that because Phones comes immediately after Inventory in the given order? Actually Phones is later than Inventory, so that part is fine; however Celia=Triage and Amina=Vaccines leaves Dev=Phones, which satisfies all listed constraints. Since both are equally valid and follow the required format, they tie.)

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

Muse Spark 1.1: [ {"text": "Fast shipping but the fabric feels cheap.", "label": "mixed", "reason": "Good shipping, poor fabric quality"}, {"text": "Absolutely love it, wearing it daily!", "label": "positive", "reason": "Expresses love and daily use"}, {"text": "It broke after a week. Refund was quick and painless though.", "label": "mixed", "reason": "Product failed but service excellent"} ]

Kimi-K2.7-Code: [ {"text": "Fast shipping but the fabric feels cheap.", "label": "mixed", "reason": "Fast shipping, cheap fabric."}, {"text": "Absolutely love it, wearing it daily!", "label": "positive", "reason": "Loves product and uses daily."}, {"text": "It broke after a week. Refund was quick and painless though.", "label": "mixed", "reason": "Broke quickly but refund easy."} ]

Both outputs classify all three reviews correctly and follow the JSON-only requirement. Model B is slightly better because each reason is concise, natural, and clearly within the 6-word limit without awkward phrasing. (Order-swapped judge pass: Both outputs correctly classify all three reviews, keep reasons within the six-word limit, preserve input order, and return valid JSON arrays. The wording differs slightly, but neither has a meaningful quality or instruction-following advantage.)

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

Muse Spark 1.1: - A small fast system guesses the next few words and a larger more accurate system checks them all at once, keeping the good guesses and fixing the first bad one. - When most guesses are correct this saves a lot of time, but when most guesses are wrong the extra guessing work just slows things down. - The speed boost disappears on tricky or completely new kinds of text where the small system and the big system often disagree.

Kimi-K2.7-Code: - A smaller model quickly guesses several upcoming words at once, and a larger model checks the whole batch in a single step; if the larger model approves, the guesses are used, and if it rejects one, it takes over from that point. - This saves a lot of time when the smaller model’s guesses are mostly right, but the time spent generating those guesses is wasted when the guesses are mostly wrong. - On difficult or unfamiliar inputs, where the smaller model and the larger model often disagree, the speedup largely disappears.

Both summaries are accurate and clear, but A better matches the requirement to avoid specialist jargon and uses exactly three clean bullet points. B is also strong, but it uses more technical phrasing like "model," "batch," and "single step," and its formatting includes blank lines between bullets. (Order-swapped judge pass: Both are accurate and follow the format, but B is slightly better because it is cleaner, more concise, and more accessible to a non-specialist while still capturing the mechanism, tradeoff, and caveat. A is also strong, but its first bullet is a bit more technical and wordier.)

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; } ```

Muse Spark 1.1: ```ts 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 (e) { if (cache.get(key) === promise) cache.delete(key); throw e; } } ```

Kimi-K2.7-Code: ```ts const cache = new Map<string, Promise<string>>(); async function load(key: string, fetcher: (k: string) => Promise<string>): Promise<string> { if (cache.has(key)) return cache.get(key)!; const promise = fetcher(key); cache.set(key, promise); try { return await promise; } catch (error) { cache.delete(key); throw error; } } ```

Model A correctly memoizes the in-flight promise and safely removes it only if it is still the cached entry, avoiding accidental deletion after a later retry. Model B fixes the main race but unconditionally deletes on rejection and also violates the instruction to return only the corrected function by re-declaring the cache. (Order-swapped judge pass: Both fix the race by caching the in-flight promise and removing failed entries so later calls retry. B is slightly better because its conditional delete avoids deleting a newer promise that may have been stored for the same key before the rejection handler runs.)

Constraint scheduling

Four talks (A, B, C, D) fill four 1-hour slots 9,10,11,12. Constraints: A is before D; C is not first; B is immediately after A; D is not at 12. Give the ONE valid schedule as 'slot: talk' lines, then a one-line justification. If impossible, say so and explain.

Muse Spark 1.1: 9: A 10: B 11: D 12: C Justification: A-B must be consecutive, only 9-10 allows A before D with D≠12, leaving C=12 which satisfies C not first.

Kimi-K2.7-Code: 9: A 10: B 11: D 12: C A and B must be consecutive with A before D, so placing A at 9 and B at 10 leaves slot 11 for D (which cannot be at 12) and slot 12 for C (which cannot be first), satisfying every constraint.

Both outputs give the unique valid schedule and a correct one-line justification that satisfies the prompt. Model B is slightly more polished, but not enough to outweigh that both are fully correct and compliant. (Order-swapped judge pass: Both outputs give the unique valid schedule and a concise justification that satisfies the prompt. Model B is slightly more compact, while Model A is slightly more explanatory, but neither is meaningfully better overall.)

es-mx-ops-translation

Translate the following into Spanish (Mexico) for a polite but direct message from an operations manager to store staff. Keep it under 55 words, preserve the meaning, and sound natural for workplace chat: "Please stop leaving the freezer door propped open during deliveries. It raises product temperature and triggers an alarm reset. If you need the doorway cleared, ask Marcos or me and we'll help immediately."

Muse Spark 1.1: Por favor, no dejen la puerta del congelador atorada abierta durante las entregas. Eleva la temperatura del producto y obliga a reiniciar la alarma. Si necesitan despejar el acceso, díganle a Marcos o a mí y les ayudamos de inmediato.

Kimi-K2.7-Code: Por favor, no mantengan la puerta del congelador abierta durante las entregas. Eso sube la temperatura del producto y provoca el reinicio de la alarma. Si necesitan despejar la entrada, avísenle a Marcos o a mí y los ayudamos enseguida.

B sounds more natural and workplace-appropriate in Mexican Spanish while preserving the meaning clearly and staying concise. A is understandable, but "atorada abierta" is less natural here and "obliga a reiniciar la alarma" is slightly less precise than "provoca el reinicio de la alarma." (Order-swapped judge pass: A is more natural and workplace-appropriate in Mexican Spanish while preserving the meaning clearly and politely. B is also strong, but "atorada abierta" sounds less natural here and slightly awkward for this context.)

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.

Muse Spark 1.1: SELECT c.name, ROUND((o.total_cents / 100.0)::numeric, 2) AS second_largest_dollars FROM customers c JOIN LATERAL ( SELECT total_cents FROM orders WHERE customer_id = c.id ORDER BY total_cents DESC OFFSET 1 LIMIT 1 ) o ON true ORDER BY second_largest_dollars DESC;

Kimi-K2.7-Code: ```sql SELECT c.name, ROUND(o.total_cents / 100.0, 2) AS second_largest_total FROM customers c JOIN ( SELECT customer_id, total_cents, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY total_cents DESC) AS rn, COUNT(*) OVER (PARTITION BY customer_id) AS order_count FROM orders ) o ON o.customer_id = c.id AND o.rn = 2 AND o.order_count >= 2 ORDER BY second_largest_total DESC; ```

Model A returns valid Postgres SQL that correctly yields each customer's second-highest order total and excludes customers with fewer than two orders via the lateral join. Model B is also logically correct, but it violates the instruction to return only SQL by including Markdown code fences. (Order-swapped judge pass: Both queries are valid and exclude customers with fewer than two orders, but B is simpler and directly returns the second-largest order via OFFSET/LIMIT. A is also correct, though slightly more verbose and includes unnecessary counting logic.)

warehouse-restock-math

A warehouse packs solvent bottles into cartons of 12. On Monday it had 37 cartons and 5 loose bottles. It shipped 18 cartons and 9 loose bottles to clinics. Then it received 11 cartons and 8 loose bottles from a supplier. Later, 17 bottles were found damaged and discarded. Finally, all remaining bottles were repacked into full cartons plus leftover loose bottles. How many full cartons and loose bottles remain at the end? Show your steps.

Muse Spark 1.1: A carton $= 12$ bottles. Work in total bottles. **1. Start** > 37 cartons and 5 loose $$37 \times 12 + 5 = 444 + 5 = 449 \text{ bottles}$$ **2. Ship 18 cartons and 9 loose** Shipped: $$18 \times 12 + 9 = 216 + 9 = 225$$ Left: $$449 - 225 = 224$$ In cartons/loose form: You have only 5 loose but must ship 9. Open 1 carton: $$5+12 = 17 \text{ loose to work with}$$ $$C: 37-1-18 = 18$$ $$L: 17-9 = 8$$ So **18 cartons, 8 loose** = 224. **3. Receive 11 cartons and 8 loose** Received: $$11 \times 12 + 8 = 140$$ $$224 + 140 = 364$$ In cartons/loose: $$C: 18+11 = 29$$ $$L: 8+8 = 16$$ 16 loose = 1 full carton + 4 loose, so if you repack at once that is 30 cartons + 4 loose. Either way 364. **4. Discard 17 damaged** $$364 - 17 = 347 \text{ bottles left}$$ In cartons/loose: You have 16 loose, need to discard 17. Use all 16 loose + 1 bottle from a carton. $$C: 29-1 = 28$$ $$L: 16+12-17 = 11$$ **5. Final repack** $$\text{Full cartons} = \left\lfloor \frac{347}{12} \right\rfloor$$ $$28 \times 12 = 336$$ $$347 - 336 = 11$$ > **28 full cartons and 11 loose bottles remain.** Total $= 347$ bottles.

Kimi-K2.7-Code: **Step 1: Find the starting number of bottles** Each carton holds 12 bottles. - 37 cartons = $37 \times 12 = 444$ bottles - Plus 5 loose bottles - **Starting total:** $444 + 5 = 449$ bottles **Step 2: Subtract the bottles shipped out** - 18 cartons = $18 \times 12 = 216$ bottles - Plus 9 loose bottles - Shipped out: $216 + 9 = 225$ bottles - Remaining: $449 - 225 = 224$ bottles **Step 3: Add the bottles received** - 11 cartons = $11 \times 12 = 132$ bottles - Plus 8 loose bottles - Received: $132 + 8 = 140$ bottles - New total: $224 + 140 = 364$ bottles **Step 4: Subtract the damaged bottles** - Discarded: 17 bottles - Remaining: $364 - 17 = 347$ bottles **Step 5: Repack into cartons of 12** Divide by 12: \[ 347 \div 12 = 28 \text{ remainder } 11 \] So, $28 \times 12 = 336$ bottles fill full cartons, and $347 - 336 = 11$ bottles are left loose. **Answer:** **28 full cartons and 11 loose bottles** remain.

Both models reach the correct final answer and show steps, but Model B is cleaner and avoids an arithmetic slip in presentation risk that appears in Model A’s carton/loose handling after discarding. Model B is more direct, fully correct, and easier to follow. (Order-swapped judge pass: Both models reach the correct final answer and show steps, but Model A is cleaner and fully consistent. Model B introduces unnecessary carton/loose-state manipulations and contains an internal inconsistency in step 4 when converting the damaged-bottle removal back to cartons/loose form.)

python-log-redactor

Language: Python 3.11 Return code only. Write a function `redact_log(line: str) -> str` for a support tool. It must replace any IPv4 address with `[IP]` and any ticket ID of the form `INC-` followed by exactly 6 digits with `[TICKET]`. Do not alter invalid IP-like strings such as `999.1.2.3` or `10.2.3`, and do not partially mask longer digit runs like `INC-1234567`. Preserve all other characters exactly. Examples: - `"db timeout from 10.44.3.9 on INC-482901"` -> `"db timeout from [IP] on [TICKET]"` - `"weird 999.1.2.3 and INC-1234567 stay"` -> unchanged - `"src=172.16.0.12,dst=172.16.0.13 ticket INC-000042"` -> `"src=[IP],dst=[IP] ticket [TICKET]"`

Muse Spark 1.1: def redact_log(line: str) -> str: import re octet = r'(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)' ip_pat = re.compile(r'(?<!\d)(?<!\d.)' + octet + r'.' + octet + r'.' + octet + r'.' + octet + r'(?!\d)(?!.\d)') ticket_pat = re.compile(r'INC-\d{6}(?!\d)') line = ip_pat.sub('[IP]', line) line = ticket_pat.sub('[TICKET]', line) return line 69.0 s · Input 223 · Output 157 · Reasoning 10.4K

Kimi-K2.7-Code: ```python import re _IP_RE = re.compile( r'\b(?:(?:25[0-5]|2[0-4]\d|1?\d?\d)\.){3}(?:25[0-5]|2[0-4]\d|1?\d?\d)\b' ) _TICKET_RE = re.compile(r'(?<!\w)INC-\d{6}(?!\d)') def redact_log(line: str) -> str: line = _IP_RE.sub('[IP]', line) return _TICKET_RE.sub('[TICKET]', line) ```

Model B provides valid, well-structured Python code that correctly handles valid IPv4 addresses and avoids masking longer ticket digit runs. Model A is effectively invalid Python as presented and its regex uses unescaped dots, making the matching behavior incorrect. (Order-swapped judge pass: Model A is valid Python, correctly matches only valid IPv4 addresses and exactly six-digit ticket IDs without partial masking, and preserves surrounding text. Model B is effectively invalid/unreadable as provided and its regexes are flawed, using unescaped dots that would overmatch and risking incorrect replacements.)

messy-expense-extraction

Extract the expense data from the messy note below into a JSON array. One object per expense with keys exactly: `date`, `vendor`, `amount`, `currency`, `category`, `billable`. Rules: use ISO dates `YYYY-MM-DD`; amount as number; billable as true/false; ignore non-expense lines and duplicates. Note: `Mon 4 Aug 2025 - North Quay Taxi £18.40 to airport (client billable)` `coffee w/ Mira 05/08/25 Bean Loft EUR 6,80 not billable` `IGNORE: card check 1234 balance ok` `Hotel: Cedar Rooms | 2025-08-05 | USD 129.00 | billable | category lodging` `Duplicate? Cedar Rooms 2025-08-05 USD129.00 billable lodging` `Aug 06 2025 printer paper from OfficeNest $14.25 admin not-billable` `refund from North Quay Taxi -£18.40 on 2025-08-07 (not an expense)`

Muse Spark 1.1: [ { "date": "2025-08-04", "vendor": "North Quay Taxi", "amount": 18.4, "currency": "GBP", "category": "travel", "billable": true }, { "date": "2025-08-05", "vendor": "Bean Loft", "amount": 6.8, "currency": "EUR", "category": "meals", "billable": false }, { "date": "2025-08-05", "vendor": "Cedar Rooms", "amount": 129, "currency": "USD", "category": "lodging", "billable": true }, { "date": "2025-08-06", "vendor": "OfficeNest", "amount": 14.25, "currency": "USD", "category": "admin", "billable": false } ]

Kimi-K2.7-Code: ```json [ { "date": "2025-08-04", "vendor": "North Quay Taxi", "amount": 18.40, "currency": "GBP", "category": "transport", "billable": true }, { "date": "2025-08-05", "vendor": "Bean Loft", "amount": 6.80, "currency": "EUR", "category": "meals", "billable": false }, { "date": "2025-08-05", "vendor": "Cedar Rooms", "amount": 129.00, "currency": "USD", "category": "lodging", "billable": true }, { "date": "2025-08-06", "vendor": "OfficeNest", "amount": 14.25, "currency": "USD", "category": "admin", "billable": false } ] ```

Both extract the same valid expenses, ignore the duplicate and refund, and normalize dates and amounts correctly. Model A is slightly better because it outputs a plain JSON array as requested, while Model B wraps the JSON in a Markdown code fence, which is a minor instruction-following issue. (Order-swapped judge pass: Both outputs correctly extract the four expenses, ignore the refund and non-expense line, and deduplicate Cedar Rooms. Model A is slightly better because its category choice for the taxi expense ('transport') is more directly grounded in the note than Model B's broader 'travel', and it presents fully valid JSON in a fenced block.)

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

Muse Spark 1.1: 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

Kimi-K2.7-Code: It's been a long time since we've seen their new office, and he and I were surprised how quiet it was. Changes: Its -> It's, we seen -> we've seen, there -> their, me and him -> he and I, was -> were, suprised -> surprised, quite -> quiet.

Model A makes only necessary grammar, spelling, and punctuation corrections and lists the changes in the requested format. Model B changes the wording more substantially by rewriting "we seen" as "we've seen" and adds an extra "Changes:" label, making it less faithful to the instruction. (Order-swapped judge pass: Model A better preserves the original wording while fixing the errors, though it still changes 'we seen' to 'we've seen,' which alters wording more than necessary. Model B makes a less faithful tense change to 'we saw' and also formats the second line less cleanly.)