Dagens feed handler mindre om endnu en chatbot og mere om hele maskinrummet: Meta er tilbage i åbne weights, Claude leverer ny matematik, OpenAI åbner en kontrolleret cybermotor, og flere datapunkter siger det samme — model, harness, værktøjer og adgangskontrol er ét samlet produkt. Arkitekturen er blevet hovedpersonen.
Meta er tilbage i open-weights-sporet med Muse Glimmer: en tæt 30B multimodal agentmodel under Apache 2.0, komprimeret til under 20 GB og bygget til lokal tool use, kode og lange workflows. Det er ikke en frontierdræber, men det er en seriøs amerikansk lokalmodel uden den gamle Llama-licensgymnastik — og Spark 1.2-weights er lovet snart.
Today we're also opening the weights for Muse Glimmer, a great 30B parameter dense model that can run locally. Soon we'll also release the weights for Muse Spark 1.2, our latest foundation model. Meta is a strong supporter of open source and I'm proud of these releases. Congrats to @alexandr_wang and the MSL team for all your great work on these models.
Claude fik besked på at angribe Riemann-hypotesen, fejlede 650 gange og endte med noget bedre end en flot demo: en ny bevist undergrænse på 67,2 procent mod 41,6 procent før. Løbet brugte 31 millioner outputtokens og cirka 60 subagenter; Anthropic-matematikere og eksterne eksperter har gennemgået resultatet, og der ligger en Lean-formalisering. “Tro på dig selv” er åbenbart blevet forskningsmetode, men denne gang med bevis.
We asked an unreleased research version of Claude to take a stab at the Riemann hypothesis. It didn’t solve it, but it did make strides on a related problem: it increased the lower bound for the fraction of zeros of the Riemann zeta function that satisfy the hypothesis from 41.6% to 67.2%. https://t.co/aZDvqqhHRi
OpenAI lancerer GPT-5.6-Cyber til godkendt sårbarhedsforskning. Modellen svarer på 95 procent af deres avancerede cyberopgaver mod 1,5 procent for almindelig Sol og har allerede fundet ukendte fejl i Chromes V8. Det er både et forsvarsværktøj og et ret tydeligt skilt med “angrebsbarrieren flytter sig nu”.
We’re expanding our cybersecurity initiative Daybreak and introducing GPT-5.6-Cyber, a new model for advanced, authorized cybersecurity work. As the threat landscape evolves, we’re putting frontier intelligence in the hands of trusted defenders before attackers can deploy offensive AI at scale.
Dagens vigtigste coding-agent-datapunkt: på 250 SWE-bench Pro-opgaver flyttede valg af harness GLM-5.2 fra 23 til 52 procent og Gemma 4 fra 15 til 36. Rangeringen kunne ikke overføres mellem modeller; en 26B-model i det rigtige stillads slog flere 744B-setups til en brøkdel af prisen. “Hvilken model er bedst?” er stadig det forkerte spørgsmål.
Codex is overoptimised for large models: it ranks 2nd out of 10 for GLM 5.2 but drops to 9th place for Gemma-4! Almost all the effort in this field goes into tuning the weights. We wanted to know how much of the final number is decided by the harness wrapped around them instead, so we ran 10 coding agent harnesses against two models on SWE-bench Pro. A lot, it turns out. Swapping the harness moves pass@1 from 23% to 52% on GLM-5.2, and from 15% to 36% on Gemma 4 26B-A4B: a wider gap than most model releases buy you. And the ranking does not transfer. The rank correlation between the two models' harness leaderboards is -0.05, which is to say: none. Codex is not alone in this. Every harness shipped by a model vendor drops on the small model — Codex 2nd to 9th, Claude Code 3rd to 7th, Qwen Code 4th to 6th — while the model-agnostic ones climb: crush 7th to 1st, opencode 8th to 2nd, pi 9th to 4th. The clearest case is crush, 7th on GLM-5.2 and 1st on Gemma 4. Run the identical scaffold on both and the small model wins by 4 points at a twelfth of the price, $0.30 per task against $3.61. Gemma 4's best harness beats GLM-5.2's four worst. A 26B model in the right scaffold is not far off a 744B model in the wrong one. Cost per solved task: $0.84 for Gemma 4 + crush at 36%. The cheapest GLM-5.2 setup that scores as well is openclaw at 38%, for $7.05. Output tokens per task span 16k to 621k across harnesses: a 39x spread in what you pay for, buying a 2x spread in what you get. 97% of input tokens are re-sent conversation prefix, so prompt caching is super important. The setup: every harness run against both models on the same 250 SWE-bench Pro tasks, one rollout each, priced at list API rates for the tokens each one actually spent. In the plot, a dark ring means the pairing sits on the Pareto frontier across both models and a faded dot means you could score higher for less elsewhere; 2 of the 10 harnesses (goose and hermes) are left out of the figure for legibility
Spotify open-sourcer Xirp efter intern brug blandt over 1.300 udviklere: ét miljø til Claude Code, Gemini CLI og Codex, koblet til viden om services, ejerskab og arkitekturbeslutninger. Multi-provider er ikke længere hobbyterminalisme; det er ved at blive almindelig platform engineering.
We just launched Xirp, a vendor-neutral agentic development environment. One place to manage agent sessions across @ClaudeDevs, @GeminiApp CLI, and @OpenAI Codex. 1,300+ @Spotify engineers already use it. Now it's available for you to try. Learn more at https://t.co/Hwo8Qqx4OI. https://t.co/YTuJ3LA3M9
Linears produktionsopskrift er mere værd end hundrede agent-manifester: kortlæg det virkelige workflow, giv agenten værktøjer til selv at hente kontekst, start med ét hyppigt job, brug den stærkeste model indtil det virker, og gør hver reel fejl til en eval eller et manglende værktøj. Kedeligt på den helt rigtige måde.
My 5 biggest takeaways from @thenanyu and @delashum from @Linear on how to build a great production agent end to end: 1. The first step is to map the actual workflow. Identify where work starts, which systems hold context, what actions complete the job, what “done” means, and where a person needs to review. For example, if work starts in Slack, make Slack the on-ramp instead of forcing users to use a separate chatbot. 2. Give agents tools to find context instead of stuffing context into the prompt. From Jacob: “Give it as little instruction as possible. Give it the tools to load context. Don’t give it context.” Start small, then let the agent pull only the instructions and data it needs for the current task. 3. Start with one frequent job, then expand based on real usage. Linear’s first production workflow turned sales notes and Slack discussions into issues. The team launched it quietly, watched how people used it, and built the next workflows based on real user behavior instead of a grand spec that covered all possible use cases. 4. Start with the strongest model until the workflow works. Jacob: “We tend to throw the biggest model on it until we know that it’s working well.” Once you have clear success criteria and evals, test smaller models on narrow jobs. Cost optimization should come after a quality baseline. 5. Turn every real failure into either an eval or a product task. Linear created two feedback loops from real usage. If the agent had the right tools but behaved badly, the team added that exact case to its evals. If the agent lacked the required tool, it reported the gap so the system could add it to an existing issue for the team to investigate. 📌 Watch the full episode for the complete walkthrough: https://t.co/wmw8vvjvv0
Og et lille Pi-gem med meget lokal relevans: Onur har bygget lange monitorjobs som deterministiske workflowgrafer omkring agenten. Kontrolflowet husker at vågne igen, selv når modellen eller kvoten går i grøften. Cron-jobbet læser med alvorlig mine og føler sig pludselig set.
I've felt the lack of a certain feature of codex desktop app since I went back to the CLI: scheduled tasks Codex desktop app can keep track of a task until it is properly finished. It's basically cron. And for some reason, codex CLI still doesn't have it. Codex app acts as a shared runtime, and for some reason, certain features don't work without it, even though they could... there is no reason for openai to not use a background process So I got bored of waiting, and decided to build my own in @pidotdev But I realized, I could do much more than a simple cron job, with my recently upgraded osolmaz/pi-workflows extension A cron job is a loop after all. Being a loop, I can represent it as a workflow graph So I created a built in `monitor` workflow to mimic cron behavior. The agent is forced into a loop where it re-checks a very long-running job every 1 hour, and it is instructed to autonomously correct it and fix any bugs if any are encountered The same functionality can be achieved by iamwrm/pi-unified-exec as well, which implements codex-like auto-forking exec behavior. But there is a chance the model messes up exec, or does not re-arm the next sleep() properly once one of them exits My monitor workflow on the other hand is deterministic. I can make the agent loop infinitely, and there is nothing the agent can do to evade the task. I just ask the agent to monitor something, and it starts it automatically This lets me just fire off week-long jobs, and forget about it! It even survives codex usage depletion, by auto-recovering once my quota resets Oh also, @ratatui_rs is a delight! I created piw, a viewer for my ongoing pi workflows. I just type piw, and can see the current state, or play back the finished ones
Cloudflare open-sourcer sit interne agent-workspace efter brug hos tusindvis af medarbejdere. Den stærke idé er ikke chatvinduet, men Gatekeepers: agenten starter uden adgang, credentials skjules bag snævre capabilities, og politik følger de data, agenten faktisk har set, så et genereret dashboard ikke bliver en kreativ genvej rundt om adgangskontrollen.
AI-notetageren tl;dv efterlod 181.874 meeting-records fra 84.312 brugere læsbare for enhver indlogget konto, inklusive IDs til aktive møder. Forskeren meldte fejlen i januar; seks måneder senere var den stadig åben. SOC 2-badges er åbenbart ikke en Firestore-regel, og backendens pasta-navne gør kun katastrofen mere al dente.