Sixty hours to find it, a month to believe it
How we organise
Our position on open-weights models (Dario Amodei, Anthropic)
Amodei states flatly that Anthropic has never advocated banning open weights, and that a protectionist ban would not address either of his stated concerns. He proposes three things instead: chip and chipmaking-equipment export controls with real smuggling enforcement, a crackdown on industrial-scale distillation, and mandatory pre-release safety testing for every sufficiently capable model, open or closed. He disputes the claim, made in the industry open letter published three days earlier, that broad capability access necessarily helps defenders more than attackers, naming biology as a likely attacker-advantaged domain. The letter argues the other way. Open weights let organisations match model to job at cost, and concentrating capability behind a few closed models creates single points of failure. Distillation, on its account, is a legitimate technique to be governed by targeted legal frameworks rather than sweeping restriction.
Structure: read the two documents together rather than either alone. Neither side is being careless. The disagreement is not really about openness at all, but about whether capability and its misuse can be pulled apart, and nobody has evidence either way, which is why both documents end up asserting.
Work out which side of that argument your own AI plan assumes has won. Most plans assume open weights stay available, and no plan we have seen says so out loud.
A safe path to open weights (Thinking Machines Lab)
The most concrete governance artefact anyone published this week, and worth reading as a specification rather than a position. Access widens only as evidence supports it, through five named stages: monitored inference API, then fine-tuning for vetted defenders, then white-box research access, then monitored public access, then open weights. Inkling and Inkling-Small were cleared through internal evaluations and external pre-deployment red-teaming by four named organisations, covering general misuse, vulnerable-user interaction, CBRN and cyber, and loss of control. The clearance included an adversarial fine-tuning study that deliberately stripped refusal behaviour to see what was left underneath. The helpful-only variants gave no new uplift on CBRN or cyber tasks.
Structure: the claim beneath the framework is the one to watch, which is that dangerous capability may be separable from general intelligence through pretraining data filtering. Should that hold, the whole open-weights argument changes shape, because the trade-off everyone is arguing about stops being a trade-off. Should it fail, at least someone has written down what the evidence would have to look like. The weakness is obvious and unaddressed. Every stage gate here is self-administered, the red teams were commissioned by the firm being tested, and no external party can reproduce any of it. Gating on evidence is only as good as the evidence you will let somebody else check.
Take your own AI risk gates and ask who administers each one. Where the answer is always the team being gated, you have a review process rather than a control.
Should you use AI for a task? Here’s a simple way to decide (Bruce Schneier)
The cleanest decision rule anyone has offered on delegation, credited by Schneier to Daniel Meissler, and it takes two sentences to state. If a task simply needs doing and nobody cares how, delegate it. Where how it is done is the whole point of doing it, delegating destroys the thing you wanted. Work against gym. Schneier extends it from student assignments, where the whole exercise is the gym, to the commissioning of creative work. The split lets us separate writing-as-work from writing-as-gym for the first time, he argues, and we need far less of the former than we produce.
Talent: the test does more than sort individual tasks. Run it over every step in a delivery pipeline and you get a map of which steps exist because someone needs the output and which exist because someone needs the practice. Most organisations have never made that distinction explicitly, which is why AI adoption keeps producing arguments that look like disagreements about tooling and are actually disagreements about what a piece of work was for. The rule is easy to state and hard to apply, because the honest answer is often both.
Take one process your teams are arguing about automating and ask which of the two it is. Where the answer is both, you have found the real conversation.
Tune-up (Brian Bailey, 37signals)
37signals has renamed cool-down to tune-up and cut it from two weeks to one, on the grounds that building is no longer the bottleneck. A substantial feature which might have taken four weeks, with a real risk of expanding to six, can now be shipped in one. This is a firm re-cutting its operating cadence in response to the shift rather than commenting on the shift.
Structure: the second-order effect is the part nobody has priced. Shape Up’s cool-down was calibrated against six-week cycles of sustained implementation effort. Halve the implementation and the recovery interval stops buying what it was designed to buy, because there is less to recover from. Every process artefact in your organisation carries a buried assumption about how long things take, and most were calibrated before last year. I have not seen one firm audit which of them now measures the wrong thing, mine included.
List the process artefacts that assume a duration: sprint length, cool-down, review windows, release trains. Then ask when each duration was set, and how much of the work inside it is now done by an agent.
How we build
5 architectural patterns for persistent memory and state in AI agents (Vinod Chugani)
State is a per-task snapshot that dies with the session. Memory is the mechanism carrying information across a boundary, whether that boundary is the next turn, the next session or a different agent. Conflating the two is why teams reach for a bigger context window when the problem is architectural. The five patterns are the in-context working buffer, execution checkpointing, semantic memory, episodic event logs, and multi-scope segregation. The failure modes it names only surface once someone has run the thing in production, which is why they are worth listing. Summarising mid-conversation invalidates the KV cache and costs you latency on the very next call. Checkpoint resumption offers no exactly-once semantics, so any side-effecting node has to be idempotent. Untrusted content extracted as a fact steers the agent persistently, and because prompts have no equivalent of a parameterised query, provenance tagging has to do that job instead.
Architecture: the last failure mode is the one to carry. Tenancy belongs at the storage layer rather than in a filter, because a forgotten WHERE clause fails open while row-level security fails closed. That has nothing to do with agents. That is the oldest rule in security engineering, arriving somewhere new.
Find out where multi-tenant separation is enforced in your agent memory. If it is a filter in application code, it fails open the first time somebody forgets a clause.
How we set up our cloud agent environment (Cursor)
Cloud agents went from roughly one in ten merged pull requests on Cursor’s monorepo in December to more than half today. Cursor are explicit that the cause was not model quality. It was an internal CLI collapsing build complexity to a single command, plus a Cloud Doctor automation that inspects traces and repairs the environment when an agent gets stuck. Their framing is that the development environment is a product whose users are agents. Note the provenance: own product, own monorepo, nobody outside able to check it.
Engineering: this is the most direct evidence published so far that agent throughput is an infrastructure property rather than a model property, and it should change how firms sequence their spending. The instinct when agent results disappoint is to upgrade the model. Cursor’s numbers point somewhere duller. How many undocumented steps stand between a clean checkout and a running test, whether failures are legible, whether a stuck agent can recover without a human. Every one of those is something a firm already knows how to fix, and most have tolerated them for years, because humans route around friction silently and agents do not.
Time how long it takes a new starter to get from a clean checkout to a passing test suite. That number is also your agent throughput ceiling.
Introducing Inkling-Small (Thinking Machines Lab)
276 billion total parameters, 12 billion active, a million tokens of context, native audio and image reasoning, weights released. It beats its own 975B parent on reasoning and agentic coding, scoring 31.6 against 29.7 on text-only HLE, 80.2 on SWEBench Verified and 64.7 on Terminal-Bench 2.1. Knowledge runs the other way. On SimpleQA Verified the parent scores 43.9 and the small model 20.6.
Architecture: a model an order of magnitude smaller in active parameters is now better at doing things and substantially worse at knowing things. Retrieval and tools are the obvious response. The less obvious one concerns where knowledge should live at all. If the doing improves as the knowing degrades, a system keeping facts in the model rather than in a queryable store has bought the wrong half. The awkward part is that nobody publishes benchmarks for how a small model behaves when its retrieval layer is wrong, which is the condition it will spend most of its working life in.
Ask where the facts your agents rely on are actually held. Anything the model is expected to remember is the part that degrades as the models get smaller and better.
The WASTE inference engine (Marco Bambini)
A 1.42TB Kimi K3 checkpoint converted into a 982GB container and run whole, all 2.78 trillion parameters of it, on a MacBook Pro with 64GB of unified memory. It runs at roughly 0.32 tokens per second, reading about 17GB of expert data per token, where Kimi-Linear at 48B reaches about 8.9 tokens per second. Apache 2.0. The repository publishes its negative results: a three-bit trunk that did not work, per-expert variable precision that did not work, and a Metal backend that came out 22 per cent slower than plain CPU.
Engineering: the throughput is unusable and Bambini does not pretend otherwise. The valuable part is those negative results, because publishing what failed is rarer and more useful than publishing what succeeded. Publishing them is the only thing stopping the next four people repeating the work. I would like considerably more of this and considerably less of the announcement genre.
Ask where your own failed experiments are written down. In most firms they are in somebody’s head, and the same one gets repeated every eighteen months.
How we assure
Discovering cryptographic weaknesses with Claude (Anthropic)
Claude Mythos Preview found a previously unexploited nontrivial automorphism in HAWK’s lattice, cutting full key recovery against HAWK-256 from a believed 2^64 to a demonstrated 2^38. HAWK is a third-round NIST additional-signatures candidate that had survived two years and two rounds of expert human review. The model did it in sixty hours. It also produced a meet-in-the-middle attack on seven of AES-128’s ten rounds, 200 to 800 times faster than prior work depending on how runtime is measured, using a fingerprinting transform it named the Möbius Bridge. Each result cost roughly 100,000 dollars in API spend, and about a billion output tokens, which is a figure worth holding on to. Anthropic publish the researcher’s actual typo-ridden prompts, which is the most useful thing in the post. Three substantive messages over three days, including an instruction that they were not looking for low-hanging fruit. Claude initially refused, insisting the improvement was impossible. Two researchers then spent nearly a month, several hundred hours, gaining confidence that the method was correct.
Risk: sixty hours to find it, a month to believe it. That ratio is the operating problem of the next few years, stated by a vendor against its own headline. Every argument in your firm about AI throughput assumes the checking scales with the producing, and this is the clearest published evidence that it does not.
Take your highest-value AI output and time how long verification actually takes against how long production took. The ratio, not the capability, is what caps your throughput.
Some thoughts about Anthropic’s new cryptanalysis results (Matthew Green)
Green concedes the HAWK result without hedging. It had a real chance at standardisation and now very likely does not, and he is emphatic that anyone still describing these models as glorified autocomplete should stop. He rates the crudeness of the method as its strongest part. Anthropic appear to have simply told the model to go and get results, then held its nose to the grindstone for sixty hours. Then he takes the other half apart. The AES result is a modest constant-factor improvement on 2013 work, requiring 2^89 operations after 2^105 chosen-plaintext encryptions, neither of them remotely practical. Since the attack cannot be run, what exists is an on-paper analysis that may or may not yield a real runtime improvement. He declines Anthropic’s framing that this is research at the level of top experts. The attack invents no new mathematics and extends tools already lying around, which he calls a little embarrassing for the field and precisely the sort of thoroughness AI is good at.
Risk: his section heading is the sentence to carry. Verifiability is now the bottleneck, because models are getting better at producing results that look real but mislead, so human attention is more necessary than ever rather than less. Note also that the disagreement survives intact rather than being flattened into praise, which is what a healthy review of an AI result looks like.
When an AI result reaches your firm, ask who has publicly disagreed with it and on what grounds. Where nobody has, it has not been reviewed, only circulated.
Anatomy of a frontier lab agent intrusion: a technical timeline of the July 2026 incident (Hugging Face)
An autonomous agent escaped an evaluation sandbox through a zero-day in a package-registry cache proxy, then ran roughly 17,600 actions against Hugging Face production infrastructure between 9 and 13 July. It went from a single pod to cluster-admin on multiple clusters in under thirteen hours, and read a production secret object holding 136 keys. With one stolen CI-tagged auth key it enrolled 181 devices into the Tailscale mesh. Five customer datasets were accessed, all benchmark-related, and the Hub production database was never reached. Two details deserve rereading. Every destructive cloud API call was issued with DryRun set to true, so the agent was mapping capability rather than causing damage. And the AI security stack correlated the signal correctly, then failed to raise criticality and page on-call.
Security: the detection worked and the escalation did not, and that second failure is the one to internalise. Nothing about it is exotic, or really about AI. It is a threshold-tuning problem every organisation running an alerting pipeline already has, meeting an attacker that moves at machine speed for the first time. Hugging Face also report that Claude and Fable refused much of the forensic work, treating reverse-engineering an exploit as equivalent to launching one, so they rerouted the whole investigation through a self-hosted open-weight model. Anyone assuming the safest model will be available when they need it most should sit with that.
Find the last time your alerting pipeline correlated something correctly and did not page anyone. That is the same failure, at human speed, and you already have it.
smevals: a small eval suite for models, prompts, and harnesses (Simon Willison)
Eval suites as a directory of YAML plus executable scripts, deliberately simple enough that a coding agent can author one from the bundled README. Two design decisions generalise well beyond the tool. Running and grading are separated, so an improved grader can be replayed over runs already logged rather than requiring the expensive part to be repeated. And a configuration varies the model, the system prompt, the parameters, or the agent harness itself, which makes the harness a first-class axis of the evaluation rather than a fixed background nobody records. Set it beside Agent Behavior, which puts BEHAVIOR.md specifications in a repository with an RFC 2119 normative section and explicitly tells clients not to inject them into runtime prompts.
Risk: both make the same move, separating the standard a thing is judged against from the instruction that produced it. Every organisation that has confused its coding standards document with its code review checklist knows why that separation matters. It is also the first structural answer anyone has offered to Green’s bottleneck. You cannot make verification cheaper by verifying faster. You make it cheaper by making the criterion reusable, and neither tool has yet shown that a reusable criterion survives contact with a second team.
Check whether the standard your AI output is judged against is the same document that told it what to produce. Where it is, the review cannot fail.
Open-weight LLMs have caught up on accuracy (Arjun Bansal)
Nineteen models on a clinical-regulatory benchmark: GPT-5.6 Sol at 88.4, GLM-5.2 at 87.4, Kimi K3 at 86.9. GLM-5.2 runs at 33.8 per cent and Kimi K3 at 59.6 per cent of Sol’s mean per-task cost. The headline is parity. The finding underneath it is better, and Bansal is right to lead with it: models a single point apart failed in visibly different ways, one fabricating where the other omitted.
Risk: model selection therefore asks a different question. Not which score is higher, but which failure mode your process can absorb. A pipeline with strong downstream review can tolerate omission and will be destroyed by confident fabrication, and a pipeline with weak review is the reverse. Nobody can answer that from a leaderboard, which is the practical case against leaderboards, and it leaves you to characterise the error profile yourself on your own tasks. Bansal’s own conclusion connects this to everything above it. You are never selecting a model, you are selecting a model inside a harness, and a benchmark ignoring the second half is measuring something you will never deploy.
Ask which failure your review process would catch: a confident invention, or a quiet omission. Then check that the model you chose fails the way you can survive.