OpenAI Pulls Models From Cursor, GLM-5.3 Goes Open, htmx 4.0

Good morning. It's Saturday, August 29, and we're covering OpenAI winding down its contract with Cursor after the SpaceX acquisition, Z.ai shipping the open weights it promised for GLM-5.3, the first major htmx release in years, and the new pattern where a rumor of a bug is enough for agents to weaponize it.

OpenAI's Cursor decision post drew 528 points and 291 comments, GLM-5.3's open-weights drop pulled 700 with 232 comments, and htmx 4.0's announcement held 661 with 165. The security story is the one worth reading slowly: a Cambridge professor watched probes land on his project minutes after a patch was shared. Here is the signal, sourced.

In today's brief:

• OpenAI told SpaceX it will wind down the contract feeding models to Cursor, with a proposed shutoff of November 12 - the maximum notice its contract allows, after Musk admitted under oath that xAI distilled OpenAI data
• GLM-5.3's open weights arrived two weeks after launch: the same 753B base as GLM-5.2 with everything gained in post-training, plus a stated 50% jump on Z.ai's coding bench
• htmx 4.0 moves the library from XMLHttpRequest to fetch(), makes attribute inheritance explicit, and ships morphing swaps and a new scripting extension out of the box
• Open-source maintainers now field exploit probes minutes after sharing patch discussions - rclone went from 20 security disclosures in ten years to over 40 in one month

THE BIG ONE

OpenAI Winds Down Its Cursor Contract After the SpaceX Acquisition

OpenAI announced that it notified SpaceX of its intent to wind down the contract providing OpenAI models to Cursor, with a proposed shutoff date of November 12, 2026 - the maximum notice the contract allows, and a deliberate gift of runway to every developer currently using GPT-5.6 Sol or Luna inside Cursor. The reasoning is blunt: "we cannot be confident that SpaceX will use our technology within our terms of service, based on our experience with Elon Musk's companies violating contracts." That experience is documented in the post: after Musk acquired Twitter - now part of SpaceX - the company broke the terms of its contract with OpenAI, and earlier this year Musk admitted under oath that xAI, now also part of SpaceX, violated OpenAI's terms of service when it distilled OpenAI data to train its models. OpenAI's custom agreement with Cursor carried a limited cancellation window after a change of control, and with the upcoming Astra model, the company says it needs its partners to stay inside the terms.

The context makes this the second shoe, not the first. SpaceX's $60 billion acquisition of Cursor - announced in April, officially closed August 16 - put the most popular AI IDE in the world inside xAI, and the HN thread (528 points, 291 comments) notes Anthropic already banned xAI for very similar terms-of-service violations earlier this year. Cursor has been a multi-model terminal by design: Composer, Sol, Claude, and Grok in one editor, with a review workflow many developers now say they can't give up. After November 12, the OpenAI models disappear; the comments zero in on what that does to a product whose biggest structural advantage was never any single model but the ability to switch between all of them - "It's always been clear," one of the top comments puts it, "that Cursor's business model of reselling others' APIs had its days numbered."

The timing matters for the wider market. OpenAI is making a statement about Astra's distribution: it will not let frontier models flow through buyers it cannot audit. The practical read for developers: whatever OpenAI models you rely on inside Cursor stay live until November 12, and no new OpenAI models will reach it after that; for the multi-model workflow, the CLI agents and BYOK editors are about to get a wave of refugees. Our SpaceX-Cursor acquisition guide has the full ownership map, and the Claude Code vs Cursor comparison covers the harnesses readers are likely to move to.

Why it matters: when both major frontier labs treat a distributor as untrusted, "which models can I use in which tool" becomes a legal question as much as a technical one - so model access is now a contract property of every IDE you adopt, not a feature of it.

MODELS

GLM-5.3's Open Weights Land, Two Weeks After the API Launch

Z.ai released the GLM-5.3 weights (700 points, 232 comments) - on schedule with the "about two weeks" promise from the API launch on August 14. The model card leads with a notable claim: GLM-5.3 shares the exact same base model as GLM-5.2, so every gain comes from post-training alone. It is a 753B-parameter mixture-of-experts model with 22 community quantizations already available, and Z.ai says it is now the most capable open-weights model for coding: a 50% improvement over GLM-5.2 on its in-house Z.ai Code Bench, and open-source state of the art on Terminal Bench 3.0 (28.3 vs GLM-5.2's 4.6) and Agents' Last Exam (28.5 vs 27.6 for Kimi K3). On other benches the picture stays close to Kimi K3: DeepSWE 66.9 vs 67.5, SWE-Marathon 42.5 vs 48.1 - the open-weights frontier is now a genuine two-horse race.

The most discussed table is the security one. GLM-5.3 scores state of the art on CyberGym (84.5), and its gains are largest further up the exploitation chain: ExploitGym 105/130 vs GLM-5.2's 29/39, ExploitBench 54.4 vs 24.4 - more than double on both. It follows a pattern Anthropic documented in its own evaluations: scaling post-training exposes cyber capability earlier than expected, and "emergent" is now the wrong word because vendors are measuring it deliberately. For builders, the practical details: a reasoning_effort parameter with low/high/max levels (default max if unset), a clear_thinking flag that defaults to false in the chat template, fp8 weights for hostable memory footprints, and first-class vLLM, SGLang, and KTransformers support. One licensing caveat: it ships under Z.ai's custom GLM-5.3 license, not Apache-2.0, so check the terms before you embed it in a product. Our free and cheap GLM-5.3 access guide was written two weeks ago around the promised weights - the third-party-host picture it described is now live - and the open-weights coding showdown will fold in independent numbers as they arrive.

Why it matters: open weights at this coding level with this pricing pressure keep resetting the floor under every proprietary model's price - and the CyberGym results mean self-hosted frontier-adjacent agents are now a security surface every team must plan for, not just a cost decision.

FRAMEWORKS

htmx 4.0: Eight Months, fetch(), and Explicit Everywhere

htmx 4.0.0 is out (661 points, 165 comments), the culmination of eight months of work that started when project founder Carson Gross, building the fixi project, decided he wanted to understand the fetch() API well enough to move htmx off its 1999-era XMLHttpRequest foundation. Internally the library is new; the release announcement is proud that user-visible behavior barely changed - 4.0 is "almost identical to htmx 2" from the outside, which is the point of a careful 2.x-to-4.x migration.

Three deliberate breaks bracket the release. Attribute inheritance - the CSS-like behavior where attributes on parents silently apply to children - is now explicit by default: you opt in with hx-confirm:inherited, and a CLI (npx htmx.org@4.0.0 upgrade-check) scans your templates for every place that needs the suffix, including the gotcha where an hx-headers CSRF token stops reaching child elements. Event names are standardized to htmx:phase:action[:sub-action] (htmx:before:request, htmx:after:swap), with error events collapsed into htmx:error and the old htmx:xhr:* events gone with the XHR. And history no longer caches page snapshots in localStorage - that was a decade of support headaches from third-party DOM mutations surviving restoration - so back-navigation re-fetches the page and swaps it into body, with a new hx-history-cache extension for teams that want local caching back.

The two headline features are both reasons to upgrade for new work. Morphing swaps (the idiomorph algorithm, now first-party) make DOM diffs faithful instead of destructive blanket swaps. And the new <hx-partial> tag extends the out-of-band pattern into full server-driven fragments: one response, multiple targeted swaps. The extension ecosystem is where the fetch() move really pays off: hx-preload, hx-download, hx-alpine-compat, three streaming extensions (hx-sse over text/event-stream, hx-ws over WebSockets, hx-multipart over multipart/mixed), and hx-live, the team's own Alpine-inspired scripting solution with DOM-based HATEOAS-friendly reactivity - all available bundled together as htmax.js. Notably for the LLM era, the release ships official agent skill files for guidance, debugging, extension authoring, and the 2.x-to-4.x migration. htmx 2.x remains on the latest npm tag and is supported indefinitely; 4.0 stays on next until early 2027, so nobody is forced to move - but the upgrade checker makes the move a Friday-afternoon job.

Why it matters: htmx spent a decade proving the hypermedia approach needs no JavaScript framework to feel modern, and 4.0's streaming, morphing, and explicit semantics upgrade it for the agent-driven era - where stable, debuggable, server-rendered HTML is exactly what deterministic tools are best at.

SECURITY

A Rumor Is Now Enough: Agents Weaponize Patches Within Minutes

Anil Madhavapeddy, professor of computer science at Cambridge and a core OCaml compiler maintainer, reports (321 points, 113 comments) that security issues in OCaml projects now draw attempted exploits within minutes of patches being shared for discussion - before any release, before any CVE. Within about ten minutes of one fix being posted, his website was fielding probes for percent-encoded traversal sequences, which means automated watchers are monitoring public repositories and turning the mere hint of a bug into working exploits. He has demonstrated the workflow with his own agents, which found the flaw from the rumor alone - he notes he switched to DeepSeek V4 Pro when Claude Fable refused the task.

The numbers from rclone maintainer Nick Craig-Wood, quoted in the thread, put the scale on it: in the first ten years of the rclone project, about 20 security disclosures came through GitHub. In the last month alone, more than 40 - with about 75% carrying "a nugget of something which needs looking at." The downstream effects compound: GitHub's CVE assignment for advisories went from 2-3 days before the AI era to 3-4 weeks now, so maintainers ship point releases with CVE-PENDING in the changelog, which is exactly the kind of open disclosure that feeds the next wave of agents. Madhavapeddy's conclusion is pointed: existing open-source embargo practices - discuss privately, release in weeks - were designed for human analysis timescales, and they are now incompatible with a world where disclosure speed is measured in minutes. Simon Willison gave the post a full pass and flags the same conclusion: the secure-development conversation has to move from "how do we embargo" to "how do we make patches harder to weaponize," because the weaponizer no longer sleeps.

Why it matters: when an agent can go from commit-diff to exploit in under an hour, every developer's security clock shortens - full-disclosure coordination, patch triage, and disclosure timelines must all be renegotiated for machine-speed attackers. Our agent security models comparison and the security triage bottleneck breakdown cover the defense posture that holds up.

RESEARCH

Lemmalog: A Datalog Engine as an Agent's Memory

Security researcher Jordy Zomer accidentally built a Datalog engine while trying to fix LLM memory (157 points, 35 comments). Working on long vulnerability-research sessions, he kept hitting the same failure: hours into an investigation, the model would suggest approaches already ruled out or reason from observations that had been disproven in a debugger. His realization is the insight: the two problems hiding under "memory" are different - retrieval ("what is relevant from the past") and maintained state ("given everything learned, what is currently true") - and the second one is a database problem, solved for decades in program analysis.

So he built Lemmalog: the LLM handles the fuzzy front-end (turning "LLDB shows the freed object is later reused as the write destination" into structured facts), while a deterministic Datalog engine maintains the consequences, with retractions, provenance, and validity intervals. When a fact is disproven, affected conclusions are invalidated automatically - including the multi-support case where a conclusion survives because an independent derivation remains. The incidental byproduct is the ability to ask an agent "why do you believe this" and get a dependency tree back, so unsupported conclusions can no longer silently join the investigation. Benchmarks are honest and mixed: LongMemEval F1 of 0.463 (vs PropMem 0.550, SimpleMem 0.480, OpenClaw 0.244, and 0.222 for feeding the full 100k-token context) - and on knowledge-update questions, the exact case it was built for, it tops the field at 0.579. On LoCoMo's 1,986 questions it lands at 0.533 F1, third among dedicated memory systems, while passing the answer model about 2,700 tokens per question instead of roughly 104,000 - a 38x context reduction. The write-up's failure forensics are worth the read alone: the model was accidentally taught to refuse synthesis questions that required counting, and a plural stemmer that ignored words under five letters silently killed every count query.

Why it matters: the agent-memory arms race has assumed bigger context windows win; Lemmalog demonstrates the alternative - a small deterministic state layer around the model that keeps conclusions consistent - and the provenance model maps directly onto the auditability requirements of regulated agent deployments. Our context-ledger argument and memory benchmark reality check frame where this fits in the current memory stack.

TOOLS WORTH A LOOK

1. TurboKV (OSS, Apache-2.0, 102 points) - an async embedded key-value store for Rust with LSM compaction, WAL durability presets (fast/durable/paranoid), atomic batches, and ~3 million keys/sec in fast mode on an M4.
2. StemDeck (free, open source, 101 points) - a fully local AI stem separator that splits songs into vocals, drums, bass, and other tracks on your own machine.
3. vphone-cli (OSS, 270 points) - boot a virtual iPhone through Apple's Virtualization.framework, headless, for CI testing and automation of iOS apps without physical devices.

WHAT ELSE IS HAPPENING

• "GUIs should be fully keyboard-driven" (809 points, 409 comments): the essay arguing mouse-first interfaces waste the fastest input device we own, with concrete interaction patterns - the top story on HN this morning.
• "It works better in the app" (657 points, 446 comments): Terence Eden on the pattern where websites that work fine in the browser push users into worse, tracker-heavy native apps instead.
• The Twelve-Factor App gets a 2025 refresh (268 points, 150 comments): the canonical SaaS manifesto is back in active form, updated for the modern deployment stack.
• Run Qwen3.8 27B locally (110 points): real throughput and memory numbers from a Mac Studio, with the caveats quantized builds still carry.
• Monzo Stand-In (82 points): the UK bank's standby service that keeps payments and balance checks working during full cloud outages - an honest post about engineering for the worst day.
• Autonomous Mathematical Discovery in a Multi-Agent World (paper, 106 points): an open-world multi-agent environment where LLM agents pursue conjectures over long horizons, with surprising success on problems that resist single-shot prompting.

---

Every link above goes to a primary source or our sourced coverage. Tomorrow's brief lands when the news does - subscribe to get it by email.