Executive Summary
Today's three sources point the same way: the hard part of AI is moving from buying capability to allocating it. Kimi K3.1 shows open weights reaching the frontier on well-specified tasks. It still costs a lot to serve and stays weak on open-ended, long-horizon work. Jones's pricing argument splits work along the same line. Closed-loop work can be metered by outcome, while open-ended work needs organizational fluency that no contract supplies. For Fred's clients, model choice is becoming a routing decision across a portfolio. The value lever sits in how frontline staff assign work, not in which model or price tier they buy.
What Changed
- Open weights cleared a planning bar. Berman reports Kimi K3.1 solved a fully scrambled Rubik's Cube with a real algorithm, precomputed and then executed. He says open models had previously failed this test. It is one qualitative demo with no pass rate.
- Benchmarks and real use disagree. Lambert and Brand put K3.1 Pro in the top tier on Artificial Analysis, but about 20 points behind on Terminal-Bench Science. They read its post-training as skewed toward short, goal-directed tasks.
- Serving economics favor smaller models. At roughly 3T parameters, one replica needs a full B300-class node. 700B-class Flash models on H200s come close on routine coding.
- Outcome pricing is becoming real, within limits. Sierra/Cedar's Cora and Fin bill per resolution. Equity-linked structures (OpenAI/Thrive, the Anthropic/Blackstone/H&F/Goldman venture) cover the less fluent middle market.
- AI gateway infrastructure got burned. LiteLLM was compromised again, through an API key exposed in GitHub for five months.
Cross-Expert Synthesis
Berman and Lambert look like they disagree, but they are measuring different things. The cube is closed and fully specified: compute the plan, then execute it. That is the short, goal-directed profile Lambert says K3.1 was tuned for. Berman's pass is consistent with Lambert's warning, not a counterexample to it. Neither source shows that K3.1 handles exploratory, persistent, ambiguous work, which is where agents fail in production.
Jones draws the same line on the commercial side. Outcome pricing works where the task closes cleanly (a bill paid, a ticket resolved) and fails on open-ended redesign. Model capability and pricing models split on one axis: closed-loop versus open-ended work. Closed-loop work is commoditizing on both fronts. Cheap open models handle it, and vendors will take outcome risk on it. Open-ended work still needs frontier closed models, expensive serving, and human judgment about when to dig deeper or escalate. That judgment is the fluency Jones says most buyers lack.
Lambert's cyber point fits the same pattern. Kimi down-weighted offensive data, but he argues the threat is driven by the ecosystem: more AI-written code, a growing backlog, and leaked secrets. The LiteLLM breach was a hygiene failure, not a capability failure. In every case the binding constraint is operational discipline, not model access.
Enterprise Implications
Open weights now give real negotiating leverage for closed-loop workloads, but self-hosting a 3T-class model is rarely justified. Sovereignty buyers should look first at Flash-class models that fit existing H200 capacity, and keep frontier closed APIs for open-ended reasoning. A single-vendor, single-model architecture leaves margin on the table at both ends.
The commercial structure should follow the work type and the client's maturity, not the vendor's preference. Fluent buyers keep per-token pricing because it lets them reassign spend and experiment. Less fluent buyers will be offered FDE or joint-venture structures that create dependency without teaching them much. Jones's claim that most firms are under-invested also challenges the spend caps most CFOs currently impose.
The LLM gateway (LiteLLM or similar) concentrates every provider key in one place and is now a proven attack target. It needs the same controls as a payment system.
What To Do About It
- Sort client workloads into closed-loop and open-ended before choosing any model or contract. Route closed-loop work to cheap open or outcome-priced options, and keep open-ended work on frontier APIs with human escalation paths.
- Benchmark Flash-class open models before K3.1 Pro. Test on the client's own multi-step tasks for accuracy, cost per completed task, and latency. Evaluate K3.1 only for hard, ambiguous work, and only after the weights ship (due November 4) and the license is reviewed.
- Harden the gateway. Scope keys per provider, rotate them on a schedule, scan repos for secrets, and alert on anomalous use. Enroll security teams in identity-verified defensive programs from closed labs instead of using abliterated hosted models.
- Replace spend caps with one funded proof. Fund a revenue project that was previously unresourced and attribute the results to AI, as Jones suggests. This tests his under-investment claim on the client's own numbers.
- Customer question: "If your vendor offered to bill per outcome tomorrow, which of your workflows could you even define an outcome for?" A thin answer measures the fluency gap and shows where advisory work is needed.
Risks and Blind Spots
Each source has a weak spot. Berman's evidence is one demo of a task likely well covered in training data. Lambert's benchmark gap comes from a single eval family, and he notes that launch buzz is now professionalized, sometimes astroturfed. That cuts both ways, including against the enthusiasm in today's sources. Jones's ROI evidence (Shopify flat headcount with 34% revenue growth, Block 25% gross profit growth) comes only from already fluent firms, so it says little about typical clients. The naming is also ambiguous: Berman says "K3.1" and Lambert says "K3.1 Pro." The sources do not confirm whether these are the same model or the same serving footprint, so verify before quoting either figure to a client.
Political risk is not priced in. One breach attributed to a Chinese open model could change procurement rules overnight. Any sovereignty strategy built on Kimi needs a fallback to a domestic or Western open model. Finally, none of the sources gives total cost of ownership for self-hosting. Until a client runs that number on its own workload, "open weights is cheaper" remains unproven.