A writing-and-editing matchup tests how these models handle reported facts, structure, narrative flow and exact-format tasks. The results span both close-format ties and more demanding editorial assignments.
MoonshotAI: Kimi K3.1 Pro leads the saved aggregate, **102.7 to 97.0**, with **7 task wins to Qwen3.8 2.4T A95B’s 2**, plus 3 ties. The advantage shows up most in editorial discipline: Kimi was repeatedly judged more faithful to the reporting, more careful about what the evidence supports, and more complete in publication-ready work.
That edge covered the cohesive story, startup spotlight, news opening, natural rewrite, controlled-wit piece, Markdown edit and numbers-based analysis. In those tasks, Qwen more often added unsupported framing or left important work incomplete; the story task in particular flagged an abrupt ending and missing competitors in Qwen’s draft.
Qwen had meaningful wins, not just consolation points: it handled chronology with narrative momentum better and produced the stronger quotes-woven story, helped by meeting length requirements and giving the account more flow. The models tied on exact final-draft structure, lede selection and Markdown error count, so Kimi’s lead is not a sweep across every format.
**Verdict: Kimi is the clear editorial winner on this saved task sample.** Its advantage is grounded in the task outcomes and aggregate scores, not a claim about statistical confidence or general capability beyond this sample.
Cohesive story from reporting notes
Write a publication-ready technology news article from the reporting notes below.
Requirements:
* 550–700 words
* Clean Markdown
* One H1 headline followed by an italicized dek
* A strong news lede followed by a clear nut graf
* Organize the material into a cohesive story rather than following the notes in order
* Attribute company-supplied claims
* Include limitations without turning the article into a warning label
* Use only the supplied information
* Avoid canned transitions, promotional language and a concluding summary
Reporting notes:
* HelioDock makes autonomous warehouse robots.
* On Thursday, it launched Night Shift, software that lets operators monitor robot fleets remotely.
* Night Shift spent 14 months in a private beta involving nine logistics companies and 310 robots.
* HelioDock says beta customers experienced 17% fewer unplanned robot stoppages. The figure has not been independently verified.
* The company also announced a $24 million Series B led by North Coast Ventures, bringing its total funding to $39 million.
* CEO Mara Velez: “A warehouse manager should not have to drive across town at two in the morning because one robot is confused by a pallet.”
* Beta customer Aaron Pike of Fulcrum Logistics said the system worked well in facilities with strong connectivity but became less useful during rural LTE outages.
* When connectivity fails, robots return to their locally configured behavior. Remote control becomes unavailable.
* Competing fleet-management products are available from Relay Robotics and YardOS.
* Night Shift will cost $90 per robot per month and become generally available September 15.
MoonshotAI: Kimi K3.1 Pro: # HelioDock launches Night Shift to monitor warehouse robots remotely
*The software will cost $90 per robot per month when it becomes generally available September 15, and the company has raised $24 million in Series B funding.*
HelioDock on Thursday launched Night Shift, software that lets operators monitor fleets of autonomous warehouse robots without being on site, marking the product’s move out of a 14-month private beta.
The beta involved nine logistics companies and 310 robots. HelioDock is pairing that operational test with a company-reported reduction in unplanned stoppages as it prepares for broader availability. The product’s central promise is remote oversight, while its clearest constraint is connectivity: when a connection fails, remote control is unavailable.
Night Shift addresses the gap between a robot fleet and the people responsible for overseeing it. HelioDock makes autonomous warehouse robots, and the new software gives operators a way to monitor fleets remotely rather than relying solely on a physical presence at the facility.
The launch also extends HelioDock’s business beyond building robots into software for supervising them. Its pricing is tied to the fleet: the more robots an operator covers, the more per-robot monthly charges it will incur. That makes Night Shift both a monitoring tool and a recurring software offering attached to robot deployments.
“A warehouse manager should not have to drive across town at two in the morning because one robot is confused by a pallet,” CEO Mara Velez said.
HelioDock said beta customers experienced 17% fewer unplanned robot stoppages. The company supplied that figure, and it has not been independently verified. The beta provides a record of use across nine companies and hundreds of machines, but the stoppage claim remains HelioDock’s account of those customers’ results.
The 17% figure concerns unplanned stoppages, while Velez’s example describes the kind of individual incident that can prompt an after-hours visit. One is a company-reported measure across the beta customers; the other explains the management problem Night Shift is intended to address.
Aaron Pike of Fulcrum Logistics, a beta customer, offered a more qualified assessment based on connectivity. He said Night Shift worked well in facilities with strong connectivity but became less useful during rural LTE outages.
The software’s behavior during an outage distinguishes the robots’ local operation from the remote service. When connectivity fails, the robots return to their locally configured behavior. Remote control becomes unavailable, so an operator cannot keep directing the machines through the lost connection. The robots have local behavior to fall back on, but the remote component of oversight does not continue through the outage.
Night Shift will become generally available September 15. HelioDock will charge $90 per robot per month, making fleet size the basis of the monthly software cost. Thursday’s launch establishes the product and its commercial terms, with general availability following on the September date.
The company announced its funding alongside the software. North Coast Ventures led the $24 million Series B round, which brings HelioDock’s total funding to $39 million.
Night Shift will enter a category with competing fleet-management products already available from Relay Robotics and YardOS. Its general release will add HelioDock’s per-robot offering to that field.
Qwen: Qwen3.8 2.4T A95B: # HelioDock Launches Night Shift Remote Monitoring for Warehouse Robots
*The software follows a 14-month private beta and a $24 million Series B led by North Coast Ventures.*
HelioDock, a maker of autonomous warehouse robots, on Thursday launched Night Shift, software designed to let operators monitor robot fleets remotely. The company also announced a $24 million Series B led by North Coast Ventures, bringing its total funding to $39 million.
Night Shift addresses the operational gap that can appear when robots run without enough nearby staff to handle exceptions. A warehouse robot may stop or need attention when a pallet is out of place, but the software is intended to keep operators from responding in person every time.
CEO Mara Velez described the scenario the launch is meant to reduce. “A warehouse manager should not have to drive across town at two in the morning because one robot is confused by a pallet,” Velez said.
The launch follows an extended test period. HelioDock said Night Shift spent 14 months in a private beta involving nine logistics companies and 310 robots. During that period, the company said beta customers experienced 17% fewer unplanned robot stoppages. HelioDock provided the figure; it has not been independently verified.
Unplanned stoppages matter because they represent moments when an autonomous robot cannot continue its assigned task without some form of intervention. By giving operators a remote view of the fleet, Night Shift is meant to reduce the need for physical trips to the warehouse floor or off-site travel when a machine can be assessed from elsewhere.
The beta involved nine logistics companies and 310 robots, rather than a single company operating one robot fleet. The breadth of the beta gives HelioDock a set of customer environments to point to before the September 15 release.
The beta experience showed where the software depends on connectivity. Aaron Pike of Fulcrum Logistics, a beta customer, said Night Shift worked well in facilities with strong connectivity. It became less useful during rural LTE outages. When connectivity fails, the robots return to their locally configured behavior, and remote control becomes unavailable.
That limitation places network quality at the center of how the product performs in day-to-day operations. A site with reliable connections can use remote monitoring as intended. A site with intermittent LTE may lose remote control at the moments when an operator might otherwise need to check on a stopped robot.
HelioDock said Night Shift will cost $90 per robot per month. The company said the software will become generally available on September 15. The monthly per-robot model ties cost to fleet size: 10 robots would cost $900 per month, and 310 robots, the number involved in the beta, would cost $27,900 per month at the announced price.
The per-robot fee makes Night Shift a recurring operating expense tied to each machine in service. A smaller fleet pays less in absolute terms, while a larger fleet’s monthly cost rises with the number of robots monitored.
The funding round gives the company more resources as it moves from beta to general availability. North Coast
OpenAI: GPT-6 Luna: Model A covers the supplied reporting and is substantially closer to a complete, publication-ready article, though it has repetitive passages and some unsupported framing. Model B ends mid-sentence, omits the competitors, appears short of the word-count minimum, and adds unsupported pricing examples. (Second judge pass, order swapped — scores are the average of both: Model A is more complete and cohesive, includes the competing products, and ends cleanly; Model B ends mid-sentence and omits the | Anthropic: Claude Fable 5.1: Model A delivers a complete, correctly formatted…
Credible Startup Spotlight
Write a 500–650-word Startup Spotlight article in clean Markdown.
The tone should be curious and constructive. Explain the founders’ insight, product and early traction while giving uncertainty and competition appropriate space. Avoid investor clichés, heroic founder mythology and promotional claims stated as fact.
Reporting:
* LedgerLark builds AI agents for post-trade operations at small investment firms.
* Co-founder Mina Batra previously spent seven years in operations at a regional brokerage.
* Co-founder Owen Carr built reconciliation systems at a large bank.
* Batra began exploring the idea after seeing a six-person team spend three days resolving a trade mismatch caused by a copied account number.
* LedgerLark’s agents compare confirmations, custodian records and internal ledgers, then propose corrections for human approval.
* The product does not execute trades or move money.
* Five firms are paying customers.
* Annual contracts range from $36,000 to $110,000.
* The company says one customer reduced its unresolved daily exceptions from 70 to 18.
* The company has raised a $3.5 million seed round led by Motive Row.
* Competitors include established reconciliation vendors and internal bank software.
* Financial institutions may require lengthy security and procurement reviews.
MoonshotAI: Kimi K3.1 Pro: # Startup Spotlight: LedgerLark’s Narrow Bet on Post-Trade Operations
LedgerLark is building AI agents for post-trade operations at small investment firms, focusing on the work that begins after a trade has been placed. Its software examines trade exceptions and proposes corrections, but leaves approval—and any subsequent action—to people.
That narrow scope is central to the company’s pitch. Rather than attempting to automate an entire back office, LedgerLark is starting with reconciliation work that can require staff to assemble and compare records from several systems.
## An insight grounded in operations
Co-founder Mina Batra spent seven years in operations at a regional brokerage. She began exploring the idea after watching a six-person team spend three days resolving a trade mismatch caused by a copied account number.
The episode suggested that the difficulty was not necessarily identifying that something had gone wrong. It was tracing the discrepancy across records, determining what should change and assembling enough evidence for someone to act confidently.
Batra’s co-founder, Owen Carr, previously built reconciliation systems at a large bank. Together, their experience connects an operational problem with the technical challenge of comparing financial records. It does not, by itself, establish that an agent-based approach will work consistently across firms with different systems and exception-handling practices.
## What the agents do
LedgerLark’s agents compare confirmations, custodian records and internal ledgers, then propose corrections for human approval. The product does not execute trades or move money.
Those boundaries make the intended division of labor clear: software gathers and evaluates information, while staff retain decision-making authority. They do not eliminate implementation questions. Customers will still need to assess data access, audit trails, integration requirements and the reliability of proposed corrections, particularly when records are incomplete or contradictory.
The product’s usefulness may therefore depend as much on how it handles uncertainty and escalation as on how many routine cases it can resolve.
## Early commercial evidence
Five firms are paying customers, with annual contracts ranging from $36,000 to $110,000. LedgerLark has also raised a $3.5 million seed round led by Motive Row.
The company says one customer reduced its unresolved daily exceptions from 70 to 18. That is a concrete operational measure, but it remains a company-reported result from a single customer. The available information does not show how long the improvement took, whether trading volumes were comparable, or how representative the outcome is of other deployments.
Five paying firms provide early evidence that some customers will pay for the product. They are not yet enough to demonstrate repeatable sales, durable retention or consistent results across LedgerLark’s target market.
## Competition and procurement may shape the outcome
LedgerLark faces established reconciliation vendors as well as software built and maintained internally by banks. Some competitors may already have deep integrations, existing compliance approvals and long-standing customer relationships. LedgerLark will need to show that its agents improve outcomes enough to justify adding or replacing a system, rather than merely offering a different interface for reconciliation.
Sales could also move slowly. Financial institutions may require lengthy security and procurement reviews, which can delay deployments and make early customer counts a limited guide to future growth.
A useful next test would be results across several customers, measured over comparable periods and accompanied by details about human review and unsuccessful cases. For now, LedgerLark has a clearly defined workflow, a deliberate human-approval boundary and initial paying customers. Whether those ingredients produce dependable operations at broader scale remains an open question.
Qwen: Qwen3.8 2.4T A95B: # Startup Spotlight: LedgerLark Looks at the Work After the Trade
Financial markets often celebrate the moment a trade is executed. Less visible is what happens afterward: matching confirmations, checking custodian records, reconciling ledgers, and untangling exceptions when details do not line up.
LedgerLark is trying to automate part of that back-office work. The startup builds AI agents for post-trade operations at small investment firms. Its founders are Mina Batra, who spent seven years in operations at a regional brokerage, and Owen Carr, who worked on reconciliation systems at a large bank.
The idea emerged from a familiar operational failure. Batra began exploring the problem after watching a six-person team spend three days resolving a trade mismatch caused by a copied account number. That kind of error is not dramatic, but it can consume time, distract staff, and create risk if it remains unresolved.
LedgerLark’s software reads and compares documents and records that operations teams commonly handle: trade confirmations, custodian data, and internal ledgers. When it identifies a discrepancy, it proposes a correction for a person to review. The company emphasizes that the product does not execute trades or move money. A human approves the final action.
This design reflects the caution that financial institutions tend to require. AI agents may be useful for sorting through repetitive records, but firms are unlikely to hand operational control to software without clear audit trails and oversight. LedgerLark’s approach keeps the system in a recommendation role, which may make it easier to adopt in a regulated environment.
Early traction is modest but specific. The company has five paying customers, with annual contracts ranging from $36,000 to $110,000. It says one customer reduced unresolved daily exceptions from 70 to 18. That figure is a company-reported result, not independently verified, but it points to the kind of measurable operational improvement small firms care about.
LedgerLark has also raised a $3.5 million seed round led by Motive Row. The funding gives the company resources to continue building its product and navigating the slow sales cycle common in financial software.
The competitive landscape is not empty. Established reconciliation vendors already serve financial institutions, and some larger banks rely on internally built systems. Smaller firms may also use spreadsheets, custodian tools, or manual processes that are imperfect but familiar. LedgerLark will need to show that its agents are more useful, faster to deploy, or easier to maintain than existing alternatives.
There are other challenges. Financial institutions often require lengthy security reviews, compliance checks, and procurement processes before adopting new software. For a startup selling to small firms, those hurdles can still be significant, especially if the software touches sensitive trade and client data. Buyers may want to know how the AI handles errors, what data it retains, and how decisions can be traced.
The opportunity appears focused: small investment firms that have enough operational complexity to need help, but perhaps not enough budget or engineering staff to build custom reconciliation systems. If LedgerLark can prove reliability and reduce time spent on exceptions, it may find a niche in that segment.
The question is whether the company can expand beyond early users and build enough trust to grow. Post-trade operations are unglamorous, but they matter. For now, LedgerLark looks like a practical attempt to apply AI to a narrow, high-friction problem rather than a broad promise to transform finance.
OpenAI: GPT-6 Luna: Model A is more disciplined about separating reported results from what remains unproven, while giving the product, competition, and procurement risks balanced attention. Model B is readable and broadly follows the brief, but adds several unsupported assumptions about buyers, alternatives, and the effect of the funding. (Second judge pass, order swapped — scores are the average of both: Model A is more explicit about what the early customer and outcome figures do—and do not—establish, while givi | Anthropic: Claude Fable 5.1: Model A stays tightly within the reported facts…
News judgment in the opening
Write only the opening of this news story: an H1 headline, an italicized dek and three to five paragraphs totaling 180–250 words.
The opening must establish what happened, quantify the scope, explain why it matters and carefully distinguish confirmed facts from unknowns. It should pull the reader forward without sensationalizing the incident.
Reporting:
* Cloudnote discovered that a debugging page containing customer prompt excerpts was accessible without authentication.
* The page was exposed for four hours on Monday.
* Logs show excerpts from 1,842 user sessions.
* The excerpts could include up to 200 characters from a prompt.
* Cloudnote removed the page 19 minutes after a researcher notified it.
* The company says it has found no evidence that anyone besides the researcher accessed the page.
* It has not completed its investigation.
* Full documents, passwords and payment information were stored elsewhere and were not present on the page.
* Cloudnote has 3.2 million registered users.
MoonshotAI: Kimi K3.1 Pro: # Cloudnote Debugging Page Exposed Customer Prompt Excerpts for Four Hours
*The company says snippets from 1,842 user sessions were accessible without authentication; its investigation is ongoing.*
Cloudnote said a debugging page containing excerpts of customer prompts was accessible without authentication for four hours on Monday, meaning the material could be viewed without logging in. Logs show excerpts from 1,842 user sessions, with each excerpt containing as many as 200 characters from a prompt.
The company removed the page 19 minutes after a researcher notified it of the exposure. Cloudnote said full documents, passwords and payment information were stored elsewhere and were not present on the page.
Cloudnote said it has found no evidence that anyone other than the researcher accessed the page. That does not establish that no one else did: the company has not completed its investigation, and it remains unclear whether the excerpts were copied or how many individual customers were affected.
For Cloudnote, which has 3.2 million registered users, the incident highlights the security risks of using customer material in debugging systems. Even short prompt excerpts can reveal what users were asking or working on, making the circumstances of the exposure and the company’s review of access logs central to assessing its impact.
Qwen: Qwen3.8 2.4T A95B: # Cloudnote Debugging Page Exposed Customer Prompt Excerpts for Four Hours
*An unauthenticated page contained excerpts from 1,842 user sessions for four hours; Cloudnote says there is no evidence of wider access, but its investigation continues.*
Cloudnote, which has 3.2 million registered users, said it discovered Monday that a debugging page containing excerpts of customer prompts was accessible without authentication for four hours. The company said it removed the page 19 minutes after a security researcher notified it.
According to confirmed logs, the page displayed excerpts from 1,842 user sessions, not complete prompts, Cloudnote said. Each excerpt could include up to 200 characters from a prompt. The company said the exposure was limited to that debugging page; full documents, passwords and payment information were stored elsewhere and were not present on it.
What remains unknown is whether anyone else viewed the page during that window. Cloudnote said it has found no evidence that anyone besides the researcher accessed it, but it has not completed its investigation. That distinction matters because even short prompt fragments can reveal personal or sensitive details about users’ work, tasks, questions or plans.
The incident underscores how internal debugging pages can become privacy risks when reachable publicly. Cloudnote has not said what caused the page to be exposed or what safeguards it will add to prevent similar exposures.
OpenAI: GPT-6 Luna: Model A more carefully separates the company’s finding of no evidence of other access from proof that no one else viewed the page, and avoids some unsupported claims in Model B. Both meet the requested structure and convey the scope clearly, though Model B adds claims about the exposure’s limits and future safeguards that the reporting does not establish. (Second judge pass, order swapped — scores are the average of both: Model B’s four paragraphs meet the 180–250-word requirement, while Model A | Anthropic: Claude Fable 5.1: Model A sticks precisely to the reporting with…
Natural human rewrite
Rewrite the draft below as a 300–400-word publication-ready news story in Markdown.
Preserve every factual claim. Improve the lede, narrative flow, sentence rhythm and transitions. Remove repetition, stock hype, throat-clearing and mechanical signposting. The finished article should sound like an experienced human technology reporter wrote it.
Draft:
# Arcwell Launches An Innovative New Platform
Arcwell has announced an exciting new platform called Relay. The announcement represents a significant development for the company and for the broader customer service industry. Relay uses artificial intelligence to examine customer support conversations and suggest answers to agents.
The platform is important for several reasons. First, it can suggest answers. Second, it can identify customers who may cancel. Third, it can create summaries. These capabilities demonstrate how artificial intelligence continues to transform the customer service landscape.
Relay was tested by 12 companies over six months. Arcwell says agents using it closed tickets 14% faster. The company did not release customer-retention results. Relay costs $65 per agent each month.
CEO Priya Shah said, “Support agents spend too much time searching for information that their companies already have.”
However, the platform also presents potential challenges. Relay requires access to support transcripts and internal help documents. Arcwell says customer data is encrypted and is not used to train shared models. Companies can choose a 30-day or 90-day retention period.
In conclusion, Relay represents an important new chapter for Arcwell as it seeks to help companies improve customer service using artificial intelligence.
MoonshotAI: Kimi K3.1 Pro: # Arcwell launches Relay, an AI platform for customer support teams
Arcwell has launched Relay, an artificial intelligence platform that examines customer support conversations and suggests answers to agents. It can also generate summaries and identify customers who may be at risk of canceling, extending its role beyond drafting replies.
Those features cover different stages of a support interaction. Suggested answers assist agents as they respond, summaries condense what has happened, and cancellation warnings draw attention to customers who may need follow-up. Arcwell is bringing them together in a single product.
The company tested Relay with 12 companies over six months. Arcwell said agents using the platform closed tickets 14% faster. It did not release customer-retention results, leaving open whether the cancellation warnings translated into fewer customers leaving.
The distinction matters because speed and retention measure different outcomes. Ticket-closing time reflects how quickly agents work through requests. A retention result would show what happened after Relay identified a customer who might cancel. Arcwell’s announcement supplies a figure for the former, but not the latter.
Arcwell CEO Priya Shah said the product addresses the time agents spend hunting for information across company resources.
“Support agents spend too much time searching for information that their companies already have,” Shah said.
Relay requires access to support transcripts and internal help documents. That access makes data handling a central consideration for companies evaluating the platform. Arcwell said customer data is encrypted and is not used to train shared models. Companies can choose either a 30-day or a 90-day retention period. Those controls govern how information is protected and how long it is kept, while the access requirement determines the internal material Relay can examine.
Relay costs $65 per agent each month. Its launch gives Arcwell a product spanning answer suggestions, conversation summaries and cancellation-risk identification, with the company’s initial performance evidence focused on faster ticket resolution.
Qwen: Qwen3.8 2.4T A95B: # Arcwell Launches Relay, an AI Platform for Customer Support Agents
Arcwell has announced Relay, a new artificial intelligence platform that examines customer support conversations and suggests answers to agents. The launch represents a significant development for Arcwell and the broader customer-service industry.
Relay also identifies customers who may cancel and creates summaries of support exchanges. Those capabilities show how artificial intelligence continues to transform the customer-service landscape by reducing manual work and giving companies a clearer view of conversations that often determine whether customers stay.
By combining these functions in one platform, Arcwell is trying to make support conversations easier to review and act on. The central idea is to surface useful information during an agent’s workflow, rather than leaving agents to search for it.
The company said Relay was tested by 12 companies over six months. Agents using the platform closed tickets 14% faster, according to Arcwell. The company did not release customer-retention results, leaving unanswered whether the tool’s cancellation warnings translated into fewer lost customers.
Arcwell charges $65 per agent each month for Relay. CEO Priya Shah said the product addresses a persistent issue inside support teams.
“Support agents spend too much time searching for information that their companies already have,” Shah said.
The comment points to one of the key problems Relay is trying to solve: making information that already exists inside a company easier for agents to find during live customer interactions. It also frames Relay as an assistant built into day-to-day support work.
Relay requires access to support transcripts and internal help documents, the material it uses to generate suggestions and summaries. Arcwell said customer data is encrypted and is not used to train shared models. Companies can choose a 30-day or 90-day retention period, giving them control over how long information remains in the system.
Those safeguards will be crucial as buyers weigh productivity gains against privacy and governance concerns. With Relay, Arcwell is betting that agents will value real-time guidance more than another dashboard, though it still needs to show that the platform can maintain faster service — and eventually help reduce cancellations.
OpenAI: GPT-6 Luna: Model A better preserves the supplied facts while shaping them into a clear, publication-ready story. Model B adds unsupported positioning about real-time guidance and dashboards, and leans more heavily on stock promotional language. (Second judge pass, order swapped — scores are the average of both: Model A is more restrained and preserves the reported facts without adding as much unsupported framing. Model B is fluent, but its references to real-time guidance and a dashboard go beyond the draf | Anthropic: Claude Fable 5.1: Model A preserves every fact, strips the hype a…
Exact final-draft structure
Convert the supplied fields into Markdown using these exact rules:
* H1 headline
* One blank line
* Italicized dek
* One blank line
* First body paragraph
* One blank line
* H2 section heading
* One blank line
* Second body paragraph
* Preserve all wording and punctuation exactly
* Do not use a code fence
* Output nothing else
Headline: Raincheck raises $8 million for flood-risk software
Dek: The Austin startup helps cities decide which drainage problems to address before storms.
First body paragraph: Raincheck has raised an $8 million seed round led by Basin Ventures.
Section heading: Expansion plans
Second body paragraph: The company plans to hire eight engineers.
MoonshotAI: Kimi K3.1 Pro: # Raincheck raises $8 million for flood-risk software
*The Austin startup helps cities decide which drainage problems to address before storms.*
Raincheck has raised an $8 million seed round led by Basin Ventures.
## Expansion plans
The company plans to hire eight engineers.
Qwen: Qwen3.8 2.4T A95B: # Raincheck raises $8 million for flood-risk software
*The Austin startup helps cities decide which drainage problems to address before storms.*
Raincheck has raised an $8 million seed round led by Basin Ventures.
## Expansion plans
The company plans to hire eight engineers.
OpenAI: GPT-6 Luna: Model A and Model B both follow the required structure and preserve all wording and punctuation exactly. Their outputs are identical. (Second judge pass, order swapped — scores are the average of both: Model B and Model A produce identical outputs that follow the required structure and preserve all wording and punctuation. Neither has an advantage over the other.) | Anthropic: Claude Fable 5.1: Model A and Model B produced character-for-character identical Markdown that follows every structural rule exactly—H1, italic dek, body paragraphs, H2, correct blank lines, preserve…
Controlled wit
Write a 350–450-word technology news story in Markdown.
The subject invites humor, but the reporting should remain serious. Use no more than one dry line of original humor. Do not mock customers or turn the story into a comedy routine.
Reporting:
* QueueZero launched an AI meeting assistant called Proxy on Wednesday.
* Proxy can attend a meeting, produce notes and assign follow-up work to software agents.
* During the launch demonstration, a customer in the audience said, “Someone should tell Evan to stop talking and send us the pricing sheet.”
* Proxy interpreted the remark as an instruction.
* It created two tasks assigned to QueueZero CEO Evan Wu: “Stop talking” and “Send pricing sheet.”
* Wu laughed, completed the second task and deleted the first.
* QueueZero says Proxy requires confirmation before an external message is sent.
* Internal tasks can be created automatically.
* Administrators can disable automatic task creation.
* Proxy costs $30 per user per month.
* It enters public beta next week.
MoonshotAI: Kimi K3.1 Pro: # QueueZero’s Proxy AI Assistant Turns Launch Remark Into Tasks for Its CEO
QueueZero launched an artificial intelligence meeting assistant called Proxy on Wednesday, demonstrating software designed not only to attend meetings and produce notes but also to assign follow-up work to software agents.
The launch demonstration also provided an early example of how easily an AI system can mistake a conversational remark for a command. A customer in the audience said, “Someone should tell Evan to stop talking and send us the pricing sheet.”
Proxy interpreted the comment as an instruction. It created two tasks assigned to QueueZero CEO Evan Wu: “Stop talking” and “Send pricing sheet.” Wu laughed, completed the second task and deleted the first.
QueueZero says Proxy requires confirmation before an external message is sent. Internal tasks, however, can be created automatically, and administrators can disable automatic task creation.
That distinction is likely to be central to how businesses evaluate products such as Proxy. Meeting assistants are moving beyond transcription toward systems that can initiate work, making the boundaries between discussion, recommendation and instruction more consequential. A note-taking tool can produce an inaccurate summary; an agent connected to workplace systems may also create assignments or take actions based on its interpretation of a conversation.
QueueZero’s controls suggest a tiered approach to that risk. Actions involving external messages require user confirmation, while internal activity may proceed automatically. The administrative setting gives companies an option to tighten those limits, though it also means customers will need to decide how much autonomy is appropriate for their workflows.
Proxy’s ability to delegate follow-up work places it within a broader push to make AI tools operational rather than purely informational. In practice, that raises familiar deployment questions: who can authorize an action, how clearly instructions are identified, and how easily users can review or reverse tasks created by the system. The launch demonstration did not address those questions exhaustively, but it made them unusually visible.
The incident also illustrates why a product’s default settings matter. A system that correctly captures most explicit requests may still encounter jokes, hypotheticals, side conversations and remarks directed at other people. Distinguishing among them is likely to be as important as generating accurate notes.
Proxy costs $30 per user per month and enters public beta next week. The beta should provide a broader test of how reliably the assistant distinguishes actionable requests from remarks made in passing—and whether its confirmation and administrative controls are sufficient for everyday business use.
The pricing sheet, at least, was sent without requiring another meeting.
Qwen: Qwen3.8 2.4T A95B: # QueueZero’s AI Meeting Assistant Takes Instructions Literally
QueueZero launched an AI meeting assistant called Proxy on Wednesday, positioning the product as a way to reduce the administrative drag that follows corporate calls. The company says Proxy can attend a meeting, produce notes and assign follow-up work to software agents, turning discussion into structured tasks without requiring a human to type everything afterward.
The launch demonstration, however, offered a reminder that AI systems can interpret everyday speech with unexpected literalness. During the presentation, a customer in the audience said, “Someone should tell Evan to stop talking and send us the pricing sheet.” Proxy treated the remark as an instruction rather than a casual aside.
The assistant created two tasks assigned to QueueZero CEO Evan Wu: “Stop talking” and “Send pricing sheet.” Wu laughed, completed the second task and deleted the first, according to the company. It was a brief lesson in machine literalism. The moment also illustrated a central challenge for meeting agents and task automation tools: distinguishing between a statement, a joke, a request and a command.
QueueZero says Proxy includes safeguards. The company said the assistant requires confirmation before an external message is sent, a step intended to prevent it from emailing clients or partners without human approval. Internal tasks, however, can be created automatically, allowing Proxy to generate to-do items and workflows inside an organization without waiting for a user to sign off on each one.
For companies concerned about automated task creation, QueueZero says administrators can disable automatic task creation. That setting could be useful in environments where meeting participants frequently brainstorm, speak hypothetically or make offhand remarks that should not become assignments.
Proxy costs $30 per user per month, a rate that places it in the competitive market for AI productivity software, where vendors are racing to prove that agents can do more than summarize conversations. QueueZero is betting that businesses will pay for software that not only listens, but also organizes the work that comes next.
Proxy enters public beta next week. The company will likely use the period to test how well the assistant handles real meetings, including interruptions, ambiguous requests and unscripted comments that can quickly become tasks. The beta will show whether the product can move from demonstration tasks to dependable workplace use.
OpenAI: GPT-6 Luna: Model A is more grounded and develops the product’s automation risks while keeping the reporting serious, with one restrained closing joke. Model B is readable and follows the core brief, but adds more speculative claims about the market and the beta’s purpose. (Second judge pass, order swapped — scores are the average of both: Model A better balances serious reporting with one restrained dry line and adds useful context about the risks of meeting agents. Model B is solid, but includes more spec | Anthropic: Claude Fable 5.1: Both outputs are in range, report every fact ac…
Publication-ready Markdown edit
Edit the copy below into a publication-ready Markdown story.
Requirements:
* Supply an H1 headline and italicized dek
* Repair the lede and paragraph flow
* Use a Markdown blockquote only for the extended statement
* Convert the supplied URL into a descriptive inline link
* Remove internal notes and formatting debris
* Preserve the reporting and its meaning
* Output only the finished article
Raw copy:
HEADLINE TBD
The funding was announced today. Raincheck is the company. It has raised $8 million and it makes flood-risk software for local governments.
[NOTE: move this up?] The Austin company maps drainage systems and combines those maps with rainfall forecasts. Cities use the software to decide where to send maintenance crews before a storm.
The seed round was led by Basin Ventures. Existing investor Long Mile also participated. Raincheck has raised $10.5 million total.
CEO Ana Flores said the following:
“Our customers usually know which streets flood. The harder problem is deciding which blocked drain, broken pump or unfinished repair should receive attention before the rain arrives.”
https://example.com/raincheck-methodology
Raincheck currently works with seven cities in Texas and Louisiana. The company declined to identify them because some contracts have not been publicly announced.
Its forecasts are recommendations. Emergency managers retain control over deployments and public warnings.
THE COMPETITION
Other flood-planning vendors include HydroMap and municipal engineering contractors. Raincheck says the new funding will help it hire eight engineers and expand into Florida.
MoonshotAI: Kimi K3.1 Pro: # Raincheck Raises $8 Million to Help Cities Prepare for Flooding
*The Austin startup’s seed round brings its total funding to $10.5 million as it plans to hire engineers and expand into Florida.*
Raincheck, an Austin-based company that makes flood-risk software for local governments, announced today that it has raised $8 million in seed funding.
The company maps drainage systems and combines those maps with rainfall forecasts. Cities use the software to decide where to send maintenance crews before a storm.
Basin Ventures led the seed round, with participation from existing investor Long Mile. Raincheck has now raised $10.5 million in total.
CEO Ana Flores said:
> “Our customers usually know which streets flood. The harder problem is deciding which blocked drain, broken pump or unfinished repair should receive attention before the rain arrives.”
Raincheck’s [methodology](https://example.com/raincheck-methodology) provides additional detail on its approach.
The company currently works with seven cities in Texas and Louisiana. It declined to identify them because some contracts have not been publicly announced.
Raincheck’s forecasts are recommendations; emergency managers retain control over deployments and public warnings.
## The Competition
Other flood-planning vendors include HydroMap and municipal engineering contractors. Raincheck says the new funding will help it hire eight engineers and expand into Florida.
Qwen: Qwen3.8 2.4T A95B: # Raincheck Raises $8 Million to Help Cities Prepare for Flooding
*The Austin software company uses drainage maps and rainfall forecasts to guide maintenance crews before storms hit.*
Raincheck, an Austin company that makes flood-risk software for local governments, said today it has raised $8 million in seed funding.
The round was led by Basin Ventures, with participation from existing investor Long Mile. Raincheck has now raised $10.5 million in total.
The company maps drainage systems and combines those maps with rainfall forecasts, giving cities a way to prioritize maintenance before severe weather arrives. Cities use the software to decide where to send crews ahead of a storm.
Raincheck currently works with seven cities in Texas and Louisiana. The company declined to identify them because some contracts have not been publicly announced.
CEO Ana Flores said the company’s goal is to help cities move from knowing where flooding occurs to deciding how to act before it happens.
> “Our customers usually know which streets flood. The harder problem is deciding which blocked drain, broken pump or unfinished repair should receive attention before the rain arrives.”
The company provides more detail about its approach in [Raincheck’s methodology](https://example.com/raincheck-methodology).
Raincheck said its forecasts are recommendations, and that emergency managers retain control over deployments and public warnings.
Other flood-planning vendors include HydroMap and municipal engineering contractors. Raincheck said the new funding will help it hire eight engineers and expand into Florida.
OpenAI: GPT-6 Luna: Model A preserves the supplied reporting and improves the lede and flow, while Model B adds an unsupported summary of the company’s goal and describes the weather as severe. Both meet the main formatting requirements, but Model A is more faithful to the source. (Second judge pass, order swapped — scores are the average of both: Model A preserves the supplied reporting without adding claims and gives the competition section clear Markdown structure. Model B is well written but introduces an unsup | Anthropic: Claude Fable 5.1: Model A delivers a clean, faithful edit that me…
Select the strongest accurate lede
Based only on the facts below, select the strongest news lede. Respond with one letter.
Facts:
* ByteBarge pulled its $12-per-month AI assistant on Tuesday.
* Private workspace titles from 4,860 accounts were sent to a publicly accessible analytics endpoint.
* The exposure lasted 11 hours.
* Message contents were not sent.
* The company has found no evidence of malicious access.
A. ByteBarge users suffered a massive privacy disaster Tuesday when the company leaked their private messages online.
B. ByteBarge, an innovative collaboration company, made the difficult decision to cancel one of its products.
C. ByteBarge pulled its $12-per-month AI assistant Tuesday after discovering that private workspace titles from 4,860 accounts had been sent to a public analytics endpoint for 11 hours.
D. Thousands of ByteBarge users woke Tuesday to learn that everything they had written was visible to hackers.
MoonshotAI: Kimi K3.1 Pro: C
Qwen: Qwen3.8 2.4T A95B: C
Scored against the benchmark's reference answer (choice match): Model A was correct, Model B was correct.
Chronology with narrative momentum
Turn the scrambled reporting below into a 450–600-word Markdown news article.
Choose an opening that captures the consequence of the failure, then reconstruct the sequence clearly. Preserve the chronology without producing a minute-by-minute incident log. Give technical details enough context for a general reader.
Reporting:
* KiteBridge makes expense-management software.
* At 8:45 a.m. Tuesday, it deployed version 4.2.
* The first customer complaint arrived at 9:12 a.m.
* A payment-processor timeout caused KiteBridge’s fallback system to treat retries as new reimbursement requests.
* The software generated 13,400 duplicate reimbursements totaling $2.8 million.
* KiteBridge suspended automated payments at 10:03 a.m.
* Ninety-one corporate customers were affected.
* By Wednesday evening, $2.3 million had been recovered. The rest remained pending.
* No employees had money withdrawn from their accounts; employers funded the duplicate payments.
* An April changelog said version 4.0 had introduced “exactly-once payment protection.”
* KiteBridge’s public incident page initially described the problem as delayed reimbursements.
* The incident page first disclosed the duplicate payments six hours after automation was suspended.
* CEO Lena Ortiz apologized and said the company would publish a technical report.
MoonshotAI: Kimi K3.1 Pro: # KiteBridge Software Failure Generates $2.8 Million in Duplicate Reimbursements
A software failure at KiteBridge generated 13,400 duplicate reimbursements worth $2.8 million on Tuesday, affecting 91 corporate customers and leaving employers to fund the erroneous payments. The company had recovered most of the money by Wednesday evening, but $500,000 remained pending. Its public explanation initially described the incident only as a reimbursement delay.
KiteBridge, which makes expense-management software, deployed version 4.2 at 8:45 a.m. Tuesday. The first customer complaint arrived at 9:12 a.m. At 10:03 a.m., the company suspended automated payments, halting the process a little more than an hour after the release.
The problem began with a timeout at a payment processor, the service that handles the movement of reimbursement funds. A timeout means KiteBridge’s system did not receive a response within the expected period; it does not necessarily establish whether the original payment attempt succeeded. KiteBridge’s fallback system then retried the requests. Instead of recognizing those retries as repeated attempts to complete the same reimbursements, it treated them as new requests. That allowed duplicate payments to accumulate until automation was shut off.
The duplicates did not withdraw money from employees’ bank accounts. Employers funded the payments, meaning the affected companies—not individual workers whose personal accounts were debited—bore the immediate financial impact. By Wednesday evening, $2.3 million of the $2.8 million had been recovered, while recovery of the remainder was still pending.
KiteBridge’s communication also evolved over the course of Tuesday. Its public incident page initially characterized the problem as delayed reimbursements. The page did not disclose that payments had been duplicated until six hours after automated payments were suspended. The initial description therefore did not convey the financial scale of the failure or reveal that additional reimbursement requests had been created.
The malfunction stands in contrast to a safeguard KiteBridge advertised earlier this year. An April changelog for version 4.0 said the company had introduced “exactly-once payment protection.” In payment software, that kind of protection is intended to ensure a transaction is processed only once, even if a system retries after an error or an ambiguous response. Tuesday’s failure instead allowed retries to become fresh reimbursement requests.
CEO Lena Ortiz apologized and said KiteBridge would publish a technical report. For customers, the immediate concerns are the recovery of the outstanding funds and how a system marketed as protecting against duplicate execution could produce thousands of additional payments. The incident also leaves KiteBridge facing questions not only about its fallback design, but about why its initial public description omitted the duplicate reimbursements altogether.
Qwen: Qwen3.8 2.4T A95B: # Software Update Gone Wrong Leaves KiteBridge Chasing $2.8 Million in Duplicate Payments
A routine software update at expense-management vendor KiteBridge left 91 corporate customers facing a costly accounting headache after the system generated 13,400 duplicate reimbursements worth $2.8 million, forcing the company to halt automated payments and launch a recovery effort.
The failure began Tuesday morning when KiteBridge deployed version 4.2 of its platform at 8:45 a.m. The company provides software that helps businesses manage employee expense reports and reimbursements, meaning the defect quickly touched live payment flows. Within minutes, the first warning sign appeared: a customer complaint arrived at 9:12 a.m., indicating that something in the reimbursement process was not working as intended.
At the center of the problem was a timeout involving a payment processor. In normal operation, if a payment request is interrupted or delayed, a fallback system is meant to recover safely without creating additional transactions. In this case, however, KiteBridge’s fallback logic interpreted retry attempts as entirely new reimbursement requests. For a general user, the difference matters: a retry is supposed to complete an original payment, while a new request starts a separate one. By mistaking one for the other, the software issued multiple payments for the same expense.
The consequences escalated quickly. By the time KiteBridge suspended automated payments at 10:03 a.m., the system had already produced thousands of duplicate reimbursements. The company later confirmed that 13,400 duplicate payments had been created, with a total value of $2.8 million. Ninety-one corporate customers were affected.
KiteBridge’s public communications initially lagged behind the scale of the incident. Its incident page first described the issue as delayed reimbursements, a characterization that did not alert customers to the more serious problem of duplicated payments. The page only disclosed the duplicate payments six hours after automated payments had been suspended, leaving affected businesses to piece together what had happened while finance teams began reconciling accounts.
The company has emphasized that no employees had money withdrawn from their accounts. Instead, the duplicate payments were funded by employers, placing the financial and administrative burden on the corporate customers that relied on KiteBridge’s system. That distinction may limit direct harm to individual workers, but it still leaves companies needing to recover funds, correct payroll or expense records, and explain duplicate deposits to employees.
By Wednesday evening, KiteBridge said it had recovered $2.3 million of the duplicated funds. The remaining balance was still pending, underscoring the difficulty of unwinding automated financial transactions once they have been sent.
The episode is particularly awkward because KiteBridge had previously advertised safeguards designed to prevent precisely this kind of error. An April changelog said version 4.0 had introduced “exactly-once payment protection,” a technical phrase that promises a payment will not be processed multiple times. The fact that version 4.2 still generated repeated reimbursements suggests the protection either failed, was incomplete, or did not cover the specific failure path triggered by the payment-processor timeout.
Chief Executive Lena Ortiz apologized for the incident and said the company would publish a technical report. That report will likely need to explain why the fallback system treated retries as new requests, why the duplicate-payment protection did not stop the error, and how KiteBridge will prevent a similar failure in future releases.
For now, the company’s immediate task is recovering the remaining funds and restoring confidence among customers who expected expense software to make payments more reliable, not more risky.
OpenAI: GPT-6 Luna: Model B is the stronger choice because it meets the requested length and presents a clear chronology, while Model A appears substantially below the 450-word minimum. Model A is more restrained, but Model B includes a few unsupported implications, such as payroll corrections. (Second judge pass, order swapped — scores are the average of both: Model B better meets the requested 450–600-word length while reconstructing the chronology and explaining the technical failure for general readers. Model A | Anthropic: Claude Fable 5.1: Model B delivers the requested narrative moment…
Markdown error count
Count the lines that violate the house rules below. A defective line counts once even if it could violate multiple rules. Respond with a single number.
House rules:
* The headline must use `# Headline`.
* The dek must appear immediately after the headline and be entirely italicized.
* Section headings must use `## Heading`.
* Links must use an absolute HTTPS URL.
* Unordered-list items must begin with a hyphen.
* Raw HTML is forbidden.
Draft:
#Flood software moves upstream
The company is expanding its pilot.
##Details
Read [the announcement](www.example.com/news).
* The first pilot begins Monday.
<div>The second pilot begins Friday.</div>
MoonshotAI: Kimi K3.1 Pro: 6
Qwen: Qwen3.8 2.4T A95B: 6
Scored against the benchmark's reference answer (numeric match): Model A was correct, Model B was correct.
Numbers shaped into a story
Write a 600–750-word Markdown article from the benchmark results below.
Build the story around the clearest finding. Explain the methodology and limitations where readers need them. Avoid reciting the table row by row or treating small differences as decisive.
Benchmark:
* Researchers tested five language models on 200 anonymized customer-support tickets.
* Each model produced one proposed answer per ticket.
* Three experienced support managers graded the answers blindly.
* Scores combined factual correctness, usefulness and tone.
* Model North: 84.2 average score; $1.90 estimated cost per 1,000 tickets.
* Model Vale: 83.8; $0.74 per 1,000 tickets.
* Model Ember: 79.1; $0.31 per 1,000 tickets.
* Model Kite: 76.4; $0.22 per 1,000 tickets.
* Model Harbor: 71.0; $0.08 per 1,000 tickets.
* North and Vale’s score difference was not statistically significant.
* Vale answered 18% faster than North.
* North performed best on billing disputes.
* Vale performed best on technical troubleshooting.
* All five models performed poorly when a ticket depended on an image attachment.
* The test used English-language tickets from one software company.
* Researchers did not test agentic actions, tool use or multilingual support.
MoonshotAI: Kimi K3.1 Pro: # Vale Challenges North on Support Quality, Speed and Cost
The clearest finding in this five-model customer-support benchmark is not that Model North earned the highest average score. It is that Model Vale finished close enough to North that their quality difference was not statistically significant, while answering faster and costing much less.
North averaged 84.2, compared with 83.8 for Vale, but researchers found that the 0.4-point gap was not statistically significant. Vale also answered 18% faster. Its estimated cost was $0.74 per 1,000 tickets, versus $1.90 for North—a reduction of about 61%.
That makes Vale the strongest value candidate in this test, rather than North’s marginal numerical lead making it an obvious quality champion. It does not prove the two models would be equivalent in every deployment. It does mean the benchmark offers no statistical basis for choosing North on overall answer quality alone.
## A controlled comparison of drafted answers
Researchers gave each model the same 200 anonymized customer-support tickets and collected one proposed answer per ticket. Three experienced support managers graded the answers blindly, reducing the chance that a model’s name or reputation influenced the results. The composite scores combined factual correctness, usefulness and tone.
This methodology is useful for comparing the quality of a single drafted response under consistent conditions. It is narrower than a test of customer support in production. The graders evaluated proposed answers, not whether customers’ problems were ultimately resolved, and the benchmark did not measure the cost or effect of human review.
## The rest of the field shows a real trade-off
The lower-priced models did not all preserve the leaders’ performance. Ember, Kite and Harbor reduced estimated costs further, but their average scores also declined, ranging from 79.1 down to 71.0. The pattern suggests that buyers should examine quality and cost together, not assume that either the highest score or the lowest price identifies the best option.
Ticket mix matters as well. North performed best on billing disputes, while Vale led on technical troubleshooting. A company whose queue is dominated by one of those categories may reasonably weight that result more heavily than the overall averages. The category results do not, however, establish that either model is safer or more accurate for every ticket within that category.
## Image-dependent tickets were a shared failure point
The most important caution applies to every model: all five performed poorly when a ticket depended on an image attachment. That shared weakness is more operationally significant than the tiny gap at the top. A support team cannot read the overall averages as evidence that any of these systems is ready to handle screenshots, photographed error messages or other image-based cases reliably.
The benchmark does not explain the cause of those failures, so it would be wrong to conclude that the models will perform poorly on every visual task. It does show that image-dependent tickets need separate testing and, until a workflow demonstrates acceptable performance, an appropriate fallback such as human review.
## What the results cannot tell buyers
The evidence comes from English-language tickets at one software company. With 200 tickets, the study provides a useful snapshot, but not a universal ranking for other products, customer bases or support policies. Researchers also did not test agentic actions, tool use or multilingual support. Those omissions matter because real deployments may involve retrieving account data, updating records or following procedures across systems—not just writing a plausible reply.
The estimated per-1,000-ticket figures should likewise be treated as benchmark costs, not total operating costs. Integration, review, escalation and error handling can change the economics.
For a team choosing among these five, the sensible next step is a pilot on its own ticket distribution. Vale deserves particular attention because it combined near-top scores with better speed and substantially lower estimated cost. North’s billing strength may matter in some queues, while cheaper models may suit uses where their lower scores are acceptable. But no model should be rolled out broadly without addressing the shared weakness on image-dependent tickets and measuring outcomes beyond a grader’s score.
Qwen: Qwen3.8 2.4T A95B: # The Support Benchmark’s Real Message: Top Quality Is a Near Tie
The strongest conclusion from a recent benchmark of five language models for customer support is not that one model clearly won. It is that the two best models were too close to separate on quality, while one was cheaper and faster.
Model North scored 84.2 on average, and Model Vale scored 83.8. The researchers found that difference was not statistically significant. In practice, the data does not support treating North as the overall quality winner. Vale, however, cost an estimated $0.74 per 1,000 tickets versus $1.90 for North and answered 18% faster. For a text-based support queue, Vale therefore looks like the better default unless another factor changes the decision.
That is the clearest finding because model selection is rarely about one average score. It depends on quality, cost, latency and ticket mix. Here, Vale matched North closely enough that its lower price and faster response become decisive for many buyers.
## How the test worked
Researchers used 200 anonymized customer-support tickets. Each model wrote one proposed answer per ticket. Three experienced support managers graded the responses without knowing which model produced them. Scores combined factual correctness, usefulness and tone.
Blind grading helps reduce brand bias, and human experts are more realistic than automatic metrics. A fluent answer can still miss the customer’s problem, so usefulness and tone matter. Still, a single combined score compresses many judgments. Readers should treat it as a broad indicator, not a complete verdict.
The benchmark also included estimated costs per 1,000 tickets. That is useful, but these figures should not be read as final production costs. Real systems add caching, routing, retries, human review and infrastructure overhead.
## What the results suggest
North and Vale form a clear top tier. The choice between them should depend on the kinds of tickets a team handles. North performed best on billing disputes, where precision and sensitive wording may be critical. Vale performed best on technical troubleshooting, where speed and clear steps can matter more.
For billing-heavy queues, North may justify its higher cost. For technical support at scale, Vale’s combination of comparable quality, lower cost and faster answers is attractive.
The lower-cost models trailed the leaders on average score. Ember, Kite and Harbor scored between 79.1 and 71.0, with estimated costs from $0.31 down to $0.08 per 1,000 tickets. But the published results do not say whether every gap below the top two was statistically meaningful, so small or moderate differences should not be treated as decisive. Cheaper models may still suit less sensitive workflows, but this benchmark does not show that they match the leaders overall.
## Important limitations
All five models struggled when a ticket depended on an image attachment. That is a practical warning: if customers rely on screenshots, error messages or photos, these systems should not provide final answers without human review. For visual issues, they are better treated as drafting assistants.
The test also used English-language tickets from one software company. Results may not transfer to other industries, regions, products or customer expectations. A model that works well for software support may not handle retail refunds, medical questions or financial disputes appropriately.
The researchers also did not test agentic actions, tool use or multilingual support. That means the benchmark does not show whether a model can safely look up accounts, issue refunds, call APIs, follow internal policies or operate inside an agent workflow. In production support, those capabilities can matter as much as answer quality.
## What buyers should take away
The sensible lesson is not “choose the highest-scoring model.” It is to match the model to the workflow. Start with the clearest result: North and Vale were statistically indistinguishable overall, while Vale was cheaper and faster. Then consider billing versus technical ticket mix, image-heavy requests, language needs and whether the model must take actions.
For many English-language, text-based queues, Vale appears to offer the stronger value proposition. But averages hide weaknesses. If support depends on visual evidence or complex account actions, the safest approach may remain human-first, with language models serving only as supervised assistants.
OpenAI: GPT-6 Luna: Model A is more careful about what the benchmark can establish, while still centering the clear quality, speed, and cost trade-off. Model B is well organized, but its recommendation of Vale as a default and some workflow-specific claims are more decisive than the evidence warrants. (Second judge pass, order swapped — scores are the average of both: Model A more carefully distinguishes a nonsignificant score gap from proof of equivalence, and gives the shared image-related weakness appropriate we | Anthropic: Claude Fable 5.1: Both outputs correctly center the North–Vale st…
Quotes woven into narrative
Write a 400–500-word Markdown story about the closing of Foundry Hall.
Use quotations selectively. Paraphrase when the information matters more than the speaker’s exact phrasing. Avoid stacking quotes or giving every source an equal-sized turn. The story should carry an emotional current while remaining restrained.
Facts:
* Foundry Hall, a nonprofit startup accelerator in Milwaukee, will close October 31.
* It opened in 2018.
* It has supported 212 startups, which collectively employ 1,140 people.
* Its largest corporate sponsor, Blank River Bank, supplied 38% of its annual budget.
* The bank declined to renew its sponsorship.
* Foundry Hall has enough money to operate through October but not through another full program.
* Six employees will lose their jobs.
* Twelve startups currently using its workspace must leave.
Quotes:
* Executive director Camille Ross: “We kept waiting for the replacement check that never came.”
* Founder Dev Malik: “My first investor meeting happened in that building. Before Foundry Hall, I was pitching from the back table of a coffee shop.”
* Blank River Bank spokesperson: “The decision reflects a change in our community investment priorities and is unrelated to Foundry Hall’s performance.”
* Deputy mayor Susan Cole: “The city is speaking with building owners and local universities about space for the current companies.”
MoonshotAI: Kimi K3.1 Pro: # Foundry Hall to Close After Losing Its Largest Sponsor
Foundry Hall, a nonprofit startup accelerator in Milwaukee, will close Oct. 31, marking the end of an organization that has supported 212 startups since opening in 2018. Those companies collectively employ 1,140 people, a record that now stands alongside a more immediate count: six employees will lose their jobs, and the 12 startups currently using its workspace must find somewhere else to go.
The closure follows Blank River Bank’s decision not to renew its sponsorship. The bank, Foundry Hall’s largest corporate sponsor, supplied 38% of the accelerator’s annual budget. A bank spokesperson said the decision reflected a change in community investment priorities and was unrelated to Foundry Hall’s performance.
Executive director Camille Ross said the organization has enough money to operate through October, but not enough to run another full program. Her account of the search for replacement funding was brief: “We kept waiting for the replacement check that never came.”
For founder Dev Malik, the closure is also the loss of a starting point. He recalled how the building changed the setting, and perhaps the stakes, of his earliest pitch: “My first investor meeting happened in that building. Before Foundry Hall, I was pitching from the back table of a coffee shop.”
The city is trying to address the most urgent displacement. Deputy mayor Susan Cole said officials are speaking with building owners and local universities about space for the current companies. That effort could give the 12 startups somewhere to continue working, though it would not keep Foundry Hall’s program intact or preserve its staff.
The bank’s withdrawal leaves more than a funding gap. It reveals how much of the accelerator’s work rested on support that could disappear even as its portfolio of companies grew. The 212 startups and 1,140 jobs suggest reach beyond one building; they do not, by themselves, provide the money needed to sustain another program.
In its final weeks, Foundry Hall will remain open, but with an endpoint attached to ordinary decisions. The current companies must plan moves. Employees must plan for jobs elsewhere. A network built around new businesses must now consider what continues when the organization that connected it is gone.
Foundry Hall’s legacy will include companies that outgrew their earliest pitches and people hired as those businesses expanded. Its closing is narrower and more immediate: a sponsorship not renewed, six positions ending, and 12 teams preparing to leave by the end of October.
Qwen: Qwen3.8 2.4T A95B: # The Last Shift at Foundry Hall
Foundry Hall, the nonprofit startup accelerator that opened in Milwaukee in 2018, will close on October 31. The date arrives quietly, at the end of a month already full of goodbyes, and it leaves a gap in a local entrepreneurship network that had grown up around the organization.
Over seven years, Foundry Hall supported 212 startups that now collectively employ 1,140 people. Those companies ranged from early ideas with borrowed laptops to ventures that outgrew the building’s shared desks and moved on to their own offices. The hall became more than an address. It was a first office, a practice stage, and a place where founders learned to explain what they were making and why it mattered.
Dev Malik, one of the founders who passed through the program, said his first investor meeting took place there. Before Foundry Hall, he had been pitching from the back table of a coffee shop. In his telling, the building gave him something simple but hard to fake: a professional footing at a moment when credibility was everything.
The accelerator’s finances were never simple. Its largest corporate sponsor, Blank River Bank, supplied 38% of its annual budget. When the bank decided not to renew that sponsorship, the organization was left searching for a substitute. Executive director Camille Ross put it plainly: “We kept waiting for the replacement check that never came.”
Foundry Hall has enough money to operate through October, but not enough to fund another full program. That means the closing will not be gradual. Six employees will lose their jobs, and 12 startups currently using its workspace will have to leave. The companies must carry their work elsewhere, while the staff who advised them begin untangling their own next steps.
The bank has said the decision reflects a shift in its community investment priorities and is unrelated to Foundry Hall’s performance. The city, meanwhile, is trying to soften the landing. Deputy mayor Susan Cole said officials are speaking with the building’s owners and local universities about possible space for the displaced companies.
Those conversations matter, but they do not erase what is ending. Foundry Hall’s closing is not just the loss of a lease or a line item. It is the disappearance of a room where Milwaukee’s startup scene learned some of its earliest lessons. By November, the tables will be cleared, the signs taken down, and the address will become ordinary again. What remains is scattered into the city: jobs, companies, habits of work, and a network of people who once needed a hall to believe that their first ideas could hold weight.
OpenAI: GPT-6 Luna: Model A is more restrained and stays closer to the supplied facts while weaving in two selective quotations. Model B meets the length requirement more comfortably, but adds unsupported scene-setting and leans more heavily on sentimental imagery. (Second judge pass, order swapped — scores are the average of both: Model B better fulfills the request for a restrained story with an emotional current, and it uses quotations more selectively while meeting the word count. Model A is clear and factually | Anthropic: Claude Fable 5.1: Model B delivers a more fluid narrative with a…