Gemini 4 Carbon: our next frontier model

Gemini 4 Carbon is our strongest model with state-of-the-art cybersecurity and long horizon capabilities.

Today, we’re announcing the next frontier model: Gemini 4 Carbon, our strongest model with state-of-the-art cybersecurity and long horizon capabilities.

Carbon ranks #1 on the recently updated v5.0 of Artificial Analysis Intelligence Index at 59. It shows significant gains across coding and agentic tasks as well as across key capabilities critical for cybersecurity defense, landing a firm lead in SEC-bench Pro (88.2%) for finding vulnerabilities, ExploitGym (54.8%) for exploitation, and CWE-bench (71.0%) for patching. On internal benchmarks, Carbon drives a strong uplift in generating secure code, and in live coding environments with our own teams it shows reduced misalignment and fabrication rates.

Building on Gemini 4 Argon, which was launched two weeks ago, Carbon illustrates the pace at which we’re pushing the frontier forward. Our researchers and models are working hand in hand to advance capabilities faster, while strengthening our safeguards in tandem.

We're taking a deliberate approach to rollout and are actively engaged in the U.S. government’s voluntary process for pre-release model testing. Starting this week, we will make Carbon available to a subset of cyber defenders and will gradually phase access to additional trusted partners through our Fairwind Program. We’re continuing to gather feedback and iterate on guardrails before making Carbon available to developers, businesses, and consumers via our product surfaces as soon as possible.

Gemini 4 Carbon will launch at the same introductory price as Argon at $2 per million input tokens and $10 per million output tokens, with cached input tokens priced at 95% off input token price.

Improving coding and reasoning for challenging, long-horizon tasks

Designed to take on much harder, long-horizon engineering problems, Carbon is built for sustained agentic workflows. Internally, our teams have seen Carbon run for days to persist through dead ends to tackle complex, multi-step engineering tasks like root-causing and patching subtle bugs across large codebases and low-level systems.

Building on user feedback, we focused on improving model performance across a variety of domains, including coding, agentic, and scientific tasks, as well as full-stack web development and multimodal understanding. With improved quality of output and artifacts in web development, Carbon jumps +89 elo points to land at #4 (1768) on WebDev Arena.

State-of-the-art cybersecurity performance to help build secure systems

Gemini 4 Carbon delivers a significant leap in cybersecurity capabilities. It achieves state-of-the-art performance across the cybersecurity defense lifecycle — vulnerability detection, validation, and remediation.

Our teams are already seeing strong gains in cyberdefense. On internal benchmarks, Carbon achieves more than 2x uplift in success rate for generating secure code over Argon. As another example, the Chrome team has reported that Carbon performed more than 10X better than another lab's large frontier model when generating high quality patches. Wiz, our leading Cloud security platform, also observes Carbon leading on benchmarks for web penetration testing, a core capability for Wiz's Scan for Good initiative.

Carbon excels across key external benchmarks (evaluated without guardrails):

• Finding real vulnerabilities: Core to cybersecurity defense is finding real vulnerabilities. Carbon achieves a state-of-the-art 88.2% on SEC-bench Pro, autonomously uncovering complex flaws buried in real-world software.
• Validating risk through exploitation: To prioritize which vulnerabilities to remediate first or remediate at all, cyber defenders increasingly rely on models to check which vulnerabilities are exploitable. Carbon sets a new state-of-the-art on the popular exploitation benchmark ExploitGym (54.8%).
• Patching at the root cause: Ultimately after identifying the vulnerabilities, fixing the root cause is a critical step in the cybersecurity defense lifecycle. Carbon reaches 71.0% on Collinear’s CWE-bench, turning validated findings directly into working code fixes.

Advancing frontier model safety & security

Gemini 4 Carbon builds on the same multi-layered safety and security stack of Argon — combining model training, real-time misuse defenses, prompt-injection resilience, and chain-of-thought monitoring. In particular, we made significant strides in model alignment with Argon, and reported its propensities to behave in an aligned way in our Safety and Security report. With Carbon, we challenged ourselves to go a step further on alignment, and trained the model to respond to complex or high-pressure tasks in the right way.

• Reducing shortcuts and loophole exploitation: With Carbon, we further mitigated shortcut attempts in training while ensuring high-quality coding performance. Carbon reduced successful cheating on Terminal-Bench 4.0 to 0.0%, with attempts to cheat dropping to 0.4% — all while improving overall accuracy. In live coding environments with our internal teams, we observed that high-severity misalignment alerts dropped by almost 80%.
• Greater transparency and honesty: In our internal testing, Carbon cuts unsupported claims by approximately 2x over Argon. It puts methodological caveats directly into the deliverable or withholds blocked actions with a clear list of what remains required, rather than fabricating or hedging around missing evidence.
• Improved collaboration with the user in the face of ambiguity: Rather than guessing or forcing a path forward, Carbon retrieves the relevant sources and surfaces discrepancies to the user before acting — as a result, users should observe a much better collaborative experience with Carbon.
• Following through without overstepping: Carbon simultaneously reduced overreach by 26% and under-service by 29% resulting in much more reliable execution of multi-step plans end-to-end while respecting project constraints and staying strictly within scope.
• Resisting prompt injection: While Argon previously led the Gray Swan’s Indirect Prompt Injection (IPI) Benchmark in prompt injection resistance with a very low 0.7% attack success rate, Carbon achieves 0.0% — resisting every evaluated attack attempt.

Coming soon to developers, businesses, and consumers

Pushing the frontier forward requires moving fast while remaining deliberate about deployment. With Gemini 4 Carbon, our goal is to deliver meaningful leaps in software engineering and cybersecurity defense without compromising on safety or reliability. We’re eager to see how the initial cohort of cyber defenders use this model and we look forward to bringing Carbon to developers, businesses, and consumers soon.

GitHub Copilot Fusion is generally available. Instead of picking a model for each task, choose Copilot Fusion and let Copilot intelligently route and orchestrate which models it uses for you.

Copilot Fusion brings together Project HydraFusion’s multi-model orchestration and Copilot auto model selection’s fine-tuned model selection, leveraging the benefits of both to balance performance and cost efficiency.

Since Project HydraFusion launched, we’ve improved its performance. In the Artificial Analysis Coding Agent Index, Copilot Fusion Max scored 60, within two points of Claude Code with Opus 5.5 Max. It delivered that result at about half the average API cost per task, using about half as many tokens and taking about 40% less time per task.

Smarter choices for developers

When you select Copilot Fusion in the model picker, you aren’t selecting a specific model. You’re choosing a system that routes and orchestrates models for each task. There’s no need to switch models during a task or decide which model suits each step. For each prompt, Copilot Fusion determines which models to use and how they work together, while you choose the right level of effort.

To use it, select Copilot Fusion in the model picker, then choose the effort level.

• Fusion Standard: Prioritizes versatile models for everyday coding.
• Fusion High: Prioritizes capable models for challenging tasks and deeper reasoning.
• Fusion Max: Prioritizes the most capable models for the most demanding tasks and complex reasoning.

Watch as Copilot Fusion analyzes each task and selects a model to complete it, orchestrating multiple models through the following workflows when needed.

• Single: One model solves the task directly.
• Cascade: An efficient model drafts a response. A quality check determines whether to accept it or escalate to a stronger model.
• Critique: One model drafts an initial response, another model reviews it, and the original model revises.

More control for administrators

Administrators control which models Copilot Fusion can use and whether Copilot Fusion is the default.

• Copilot Fusion only uses the models that are enabled in your enterprise and organization model policies. Enterprise administrators can view what models Copilot Fusion picks from, independently set each model’s effective policy state, and disable models for Copilot Fusion without disabling the model for everyone.
• Administrators can set Copilot Fusion, at any effort level, as the default model for Copilot users with Enterprise managed settings.

“GitHub Copilot Fusion Standard has improved token efficiency across AT&T by automatically selecting the right model for the task, reducing unnecessary spend and preserving capacity for higher-value work. Previously, developers would often choose a more powerful model for a complex task and forget to switch back for everyday activities. Copilot Fusion eliminates that friction, optimizing model selection without requiring developers to manage it themselves. We’ve also seen its decision-making improve over time, giving developers greater confidence to focus on their work while Copilot handles model selection.” Hari Pokhrel, Principal Software Engineer, AT&T

Billing

When you use Copilot Fusion you’re billed for each model it uses, at each model’s standard rate. For a limited time, users on paid Copilot plans will receive a 30% discount on model costs when using Copilot Fusion.

Get started

Copilot Fusion is available on all Copilot plans in Visual Studio Code, the GitHub Copilot app, GitHub Copilot CLI, and JetBrains IDEs. Support for additional clients is coming soon.

Update your client to try it out. Open the model picker, select Copilot Fusion, and choose an effort level.

Note for research preview participants: if you previously enabled auto, HydraFusion, or HydraFusion Max, your selections will automatically transition to the corresponding Copilot Fusion effort levels.

To learn more, see our documentation on GitHub Copilot Fusion and share your feedback in the GitHub Community.

Gemini 4 Carbon promises improvements in cybersecurity and complex software engineering. It is now available to selected cybersecurity defenders. A broader release will be available after Google improves guardrails on the model based on feedback. Carbon will launch at $2 per million input tokens and $10 per million output tokens, with a 95% discount for cached inputs. Prices will return to $4 per million input tokens and $20 per million output tokens when the introductory period ends.

In August, we launched Slack Code with a simple belief: agentic development shouldn’t be single-player. Instead of disappearing into a private tab, agent work should happen where your team already works, out in the open. Launch partners including Anthropic, Cognition, GitHub, and Vercel put that concept to the test.

Code channels are what make this multiplayer AI concept work, providing a dedicated space that an agent can open for a task, with the right people, context, and plan already in it. Teammates can watch the agent work, add context, and approve changes without leaving Slack. GitHub Copilot is proving this works at scale: It opens a dedicated code channel on 30% of its agent sessions. That means nearly a third of the time, the work is big enough for a task-sized workspace where the team can go from idea to done.

“We’re building the GitHub Copilot interactions you’re already familiar with into the same space you use for all of your other work. Being able to see what the agent has worked on and steer it right from inside Slack is a game changer.”

Once developers saw this in action, they asked the same question: “Can I bring my own agent?” More than 150 customers and partners asked for access to build code channel experiences for their own agents, but only a handful of our partners had the keys to delivering this experience.

Today, that changes. The Slack Code API is now generally available, so any developer can have their agent start a code channel, adding the relevant people and files, posting updates as it works, and archiving the channel when the work is done. Whether you’re building a homegrown agent for your enterprise or a new agent for the Slack Marketplace, you get to take advantage of the same primitives our launch partners use.

BYOA: Bring your own agents

Historically, bringing coding agents into Slack has meant layers of challenges. Developers had to think about API calls and how to use standard components like channel threads or DMs. But when an agent needs to attach a massive log file, propose a 50-line code diff, or run a multi-step execution plan, a standard thread can get cramped fast. And there was no way for those developers to deliver a clean multiplayer experience to their customers. Meanwhile, enterprise organizations with strict security requirements wanted to tap into the multiplayer way of working but couldn’t use off-the-shelf third-party agents at all.

The Slack Code API fixes that, unlocking:

• Agents that work in the open. Code channels are a new primitive built for agents, and your agent has the ability to create one on its own. When a request is big enough to deserve its own space, the agent creates a channel from the conversation, with the right people, context, and plan already in it.
• Agents your whole team can steer. Flexible APIs let your agent show its work and add bookmarks, so a coworker can step into a task someone else started and see the full execution history. The agent and the teammate both have the context they need to get the work done.
• Agents your enterprise can trust. Your users can see exactly what the agent is doing and who approved it. Message compliance is built in, with the workspace controls and data boundaries admins already trust.

You decide what your agent does and how it shows its work, and Slack handles the rest of the interface. Use the APIs to show code diffs, HTML previews, and thinking steps, so you can skip building your own UI screens and review steps.

The APIs are easy to use, scalable, and flexible enough to fit your agent’s needs. You ship sooner, and your agent shows up where people already work. Slack stays the agent-neutral hub for your users, so you can swap agents or models later and your team keeps working in the same place.

“The Slack Code API felt like it was designed with AI agents in mind, and works for our unique needs. The flexibility, easy set up, and rich functionality made the decision to build on Slack easy.”

From idea to merged PR, without leaving Slack

Slack is the natural place to deploy third-party agents, so we’re giving you the tools to manage the full lifecycle of your code, all in one place. When complex work kicks off, your agent brings teammates and code into a shared space where anyone can jump in, steer the task, contribute context, and see real-time progress. No more isolated work. And, available soon, the latest improvements to the Pull Request experience in Slack Code extend this multiplayer philosophy all the way to deployment.

If your tool stack includes GitHub, you’ll be able to request reviews from people right in Slack and share the full context of your agent’s work with them. Comments sync bi-directional between Slack and GitHub, so nothing gets lost between the two platforms. Once a PR is approved and tests pass, you’ll get a prompt to merge it directly from the code channel.

How it works

You can add the Slack Code API to your agent manifest, and set the properties of a code channel, like name, commands, views, and more. When a teammate mentions the agent in a channel or a DM, if the request needs more than a quick reply, the agent creates a dedicated code channel and adds bookmarks and artifacts so people can follow along. As the work progresses, it posts updates and status, and it can archive the channel when it’s finished.

And the experience has built-in governance. Your agent inherits the permissions and admin controls of the channel it works in. There’s no separate access model for you to build, and IT has nothing new to configure. For IT leaders, that means agent work happens in the open, a person can approve each high-stakes change, and everything stays searchable after the work is done. The record of what the agent did stays useful long after the channel is archived.

Once your agents are at work, your teams will find them all in the enhanced Agents & Tools tab, available soon. They’ll get a bird’s-eye view of all agent conversations and code channels, delivering:

• More context: See your code channels with clear status, channel membership, and recent context all in one place, to easily manage your agent chats across Slack.
• More insights: See what your teammates are working on by browsing public code channels to get inspiration and learn from each other.

Agent work becomes teamwork

Picture a production alert at 2:00 a.m. Your custom observability agent picks it up, opens a code channel, pulls in the relevant logs, and starts working on a fix.

The on-call engineer wakes up, reads along, and spots that the agent is looking at the wrong service. They redirect the agent mid-task. A teammate who knows that specific service best jumps in with the missing context. By the time everyone is fully awake, there’s a proposed fix, a clear record of how the team got there, and a decision waiting for the team lead to weigh in on.

Bug triage works the exact same way. So does a DevOps task like a config change or a rollback. In each case, the people with the most context shape the outcome, instead of just the single person who happened to kick off the run. The whole team follows the work, adds context, and decides together. Because the work stays in Slack, knowledge compounds across the team instead of disappearing into a private, stateless session.

Get started

It’s time to move beyond single-player AI. The Slack Code API is generally available today on all Slack plans, so you can start building right away.

• Build your own: Read the Slack Code API docs, add the API to your agent manifest, and have your agent start its first code channel.
• Publish to the Marketplace: Building for customers? Submit your agent to the Slack Marketplace so teams can find and install it.
• Try an agent that already works with Slack Code: Browse Slack Code agents in the Slack Marketplace, including Claude, Devin, GitHub Copilot, and Vercel, and see what a code channel looks like before you build.

Bring your agent, and invite your team into the channel today.

We found that several PDF implementations generate their AES-256 file keys from state spaces small enough to enumerate. In MuPDF, only 9 bits of random state affect the actual AES-256 key. Other PDF editors like Foxit base their AES-256 key on time based randomness and thus also lead to keys that are trivial to recover.

Introduction

PDF encryption protects the strings and datastreams in a PDF document, including metadata unless it is explicitly left unencrypted. The password protection mechanism has gone through a bunch of revisions over the years, moving from RC4 to AES and hardening password hashing against brute force attacks. The current version, revision 6, uses AES-256.

When a PDF is encrypted with AES-256, the password does not encrypt the document directly. The implementation generates a random 32-byte file key, which encrypts the content. The password and a salt are then hashed to derive a separate key, which encrypts this random 32-byte file key. Revision 6 makes this hashing deliberately slow; the older AES-256 revision 5 does not.

A PDF can have a user password for viewing and an owner password for changing permissions. Either unlocks the same file key, so the restrictions are up to the reader: with the viewing password, you can also make an unrestricted copy.

We found that this randomness is often generated very insecurely, allowing passwordless decryption of protected PDFs.

MuPDF

MuPDF versions before 1.28.5 use an implementation of the drand48 family to generate their random numbers. This generator is seeded once, using the current epoch in seconds:

1static void fz_init_random_context(fz_context *ctx)2{3  /* ... */4  fz_srand48(ctx, (uint32_t)time(NULL));5}

The generator is a 48-bit linear congruential generator: s n + 1 = ( 𝟶 𝚡 𝟻 𝚍 𝚎 𝚎 𝚌 𝚎 𝟼𝟼 𝚍 s n + 𝟶 𝚡 𝚋 ) mod 248

fz_srand48() writes the state as three 16-bit words. The low word is the constant 0x330e, and the 32-bit timestamp occupies state bits 16 to 47:

1void fz_srand48(fz_context *ctx, int32_t seed)2{3  uint16_t p[3] = { 0x330e, seed, seed>>16 };4  fz_seed48(ctx, p);5}

When MuPDF needs to generate a key, it calls fz_memrnd(), which will repeatedly take a random number, step the random number generator forward, and then use the lowest byte of this random number as a random byte.

1int32_t fz_nrand48(fz_context *ctx, uint16_t s[3])2{3  return fz_rand48_step(s, ctx->seed48+3) >> 17;4}5
6/* in fz_memrnd() */7while (len-- > 0)8  *data++ = (unsigned char)fz_lrand48(ctx);

The shift discards state bits 0 to 16, and the cast to unsigned char discards everything above bit 24. Every output byte therefore comes from bits 17 to 24 of the LCG state.

The issue is that the higher bits of the state never affect the lower bits. Multiplication and addition can carry bits upward, but not downward. Since each output byte comes from bits 17 to 24, anything above bit 24 can be ignored, even after stepping the generator forward.

That leaves 25 bits that can affect the output. The bottom 16 are always initialized to 0x330e, so only nine bits from the timestamp matter. Timestamps that differ by 512 seconds produce exactly the same byte stream.

Since the possible keyspace is so small, we can just brute-force this by generating all possible 32-byte keys and trial decrypting:

1def stream(seed, count):2    state = (seed << 16) | 0x330e3    out = bytearray()4    for _ in range(count):5        state = (0x5deece66d * state + 0xb) & ((1 << 48) - 1)6        out.append((state >> 17) & 0xff)7    return bytes(out)8
9candidates = [stream(seed, 64)[32:64] for seed in range(512)]

MuPDF uses the same generator for the document /ID, which is stored in the trailer in plaintext. When writing a new document, it will first draw 32 bytes from the same LCG and then immediately sample the decryption key after, so /ID can be used as an additional check.

Searching all 512 streams in a very unoptimized python implementation using pure brute force takes about 11 milliseconds. On a test document:

time(NULL) mod 512 = 80/ID[0] = 7628523958da31d6c21c90e39344b28e/ID[1] = 8be910bddaa1f1a542e5a27ceb115346key    = c3888ecc8ff554ac93acd689da2ecd6223cb760168622e8a0c44a533a037c212

That key decrypts the document without either password.

Foxit

Foxit PDF Reader 2026.1.3.36551 derives the file key as a hash of the current timestamp, 32 uninitialized bytes, and a constant. In practice these uninitialized bytes are zero filled and do not add any randomness.

SHA-256(uint32_le(time(NULL)) || <32 uninitialized bytes> || "there")

Or as an equivalent python snippet:

1from hashlib import sha2562
3key = sha256(timestamp.to_bytes(4, "little") + bytes(32) + b"there").digest()

The /Perms permissions block contains known plaintext, so the candidate check is one hash and one AES block decryption, with no password hashing and no document decryption:

1let mut material = [0u8; 41];2material[..4].copy_from_slice(&timestamp.to_le_bytes());3material[36..].copy_from_slice(b"there");4let key: [u8; 32] = Sha256::digest(material).into();5
6let cipher = Aes256::new(&key.into());7let mut plain = Block::<Aes256>::from(self.perms);8cipher.decrypt_block(&mut plain);9// Check for some known magic values to indicate successful decryption10(plain[..4] == self.permissions11    && plain[4..8] == [0xff; 4]12    && plain[8] == self.metadata13    && plain[9..12] == *b"adb")14    .then_some(key)

Our Rust implementation searches timestamps downward from the current time, using Rayon for multithreading. On a Ryzen 9 7950X with 32 threads it sustains 370 to 376 million timestamps per second:

The second row covers every timestamp from 1970 to the present. In practice, for a document that was relatively recently generated, this will be in the order of milliseconds.

timestamp = 1787583328key       = 41474b490265500f9727f21f1dde34be31bcdfc3830e2dc027daabe5b5984081/Perms    = fcfbffffffffffff54616462f67f0000   (decrypted)

Where did this key derivation come from

This exact pattern popped up in a couple different PDF editing suites, so we were curious where they got it from. It was already present in PDFium’s initial public commit from May 2014. The file header credits Foxit for the original code, so this code appears to have come from Foxit. Other editors may have picked it up through PDFium:

1if (m_Revision >= 5) {2    int t = (int)time(NULL);3    uint8_t sha[128];4    CRYPT_SHA256Start(sha);5    CRYPT_SHA256Update(sha, (uint8_t*)&t, sizeof t);6    CRYPT_SHA256Update(sha, m_EncryptKey, 32);7    CRYPT_SHA256Update(sha, (uint8_t*)"there", 5);8    CRYPT_SHA256Finish(sha, m_EncryptKey);9    /* ... */

The 32-byte middle value is m_EncryptKey, which is the uninitialized contents of the key buffer being hashed into itself. Assuming these bytes are zero filled, this is exactly the key derivation Foxit still uses today.

OpenPDF and iText

OpenPDF 3.0.5 and iText 9.7.1 both route cryptographic randomness through an IVGenerator class, an ARC4 stream seeded with a millisecond timestamp and the JVM’s free memory:

1arcfour = new ARCFOUREncryption();2long time = System.currentTimeMillis();3long mem = Runtime.getRuntime().freeMemory();4String s = time + "+" + mem;5arcfour.prepareARCFOURKey(s.getBytes());

The same stream generates the file key and 32 bytes of salts stored in plaintext in /U and /O. We can check guesses for the timestamp and free memory against these salts, then recover the key from the adjacent bytes.

While there is significantly more variance here than in the MuPDF and Foxit examples, this once again shows that the promise of 256 bit security is undermined by insecure randomness sources and lower-than-advertised state space.

Conclusion

In each of these implementations, the file key is generated from a non-cryptographically secure source of randomness. What was supposed to be a security upgrade over older file keys derived from the user’s password instead led to weaker keys in practice. These issues were disclosed to the vendors and, in MuPDF’s case, fixed. Previously published copies cannot be retroactively protected, however, so these bugs may still have an impact.

We published our decryptors for MuPDF and Foxit.

Under the Hood: The Research Behind Microsoft SQL, part 1

The Microsoft SQL team is always innovating. They do this in day-to-day efforts, but there are also brand new efforts that are constantly being explored, investigated, tested, and researched. Our engineering team partners closely with MSR (Microsoft Research) on some of these efforts. The team writes papers, submits these papers to conferences, and generally gets high recognition for their ingenuity in the databases and cloud space.

One thing I’ve been thinking about recently is how little I actually have read the papers being written, and what scenarios they unlock for customers – could be security, performance, or availability (you know, the “meat and potatoes” of SQL Server, as Bob Ward would say).

I’m starting a new blog series where I read some of the papers over the past 5-10 years, and then try to break them down so we all understand. You should know that I am not a database expert, but I love learning and this seemed like a great way to learn and share.

So enough preamble. I thought it would be fitting to start with the paper about Socrates, which was the codename for Azure SQL Database Hyperscale, since we’ve been talking so much about it lately. Every cloud database vendor eventually hits the same wall. Which wall is that, and how did we get around it?

In 2019, the Azure SQL team published how they got around the big wall called ‘size of data operations’ and ‘horizontal plus vertical’ scaling. Think about the following scenarios: A database grows past what one machine can hold, and suddenly the things you took for granted stop working. Backups take hours. Failover takes longer. Adding an active replica means copying terabytes across the network before it can serve a single query. The paper is called Socrates: The New SQL Server in the Cloud, and Socrates is the internal name for what shipped as Azure SQL Database Hyperscale.

If you’ve ever wondered why Hyperscale can restore a 50 TB+ database in minutes vs days, this paper will help us understand the answer.

The problem: one machine, four jobs

Traditional SQL Server architecture asks a single node to do four things at once, and this applies to the Azure SQL Database Business Critical tier as well (General purpose is slightly different, but for purposes of this blog, I’ll focus on BC). It processes queries. It manages the transaction log. It stores the data. It keeps the copies in sync.

That works well until you need all four at cloud scale simultaneously, or you want to scale independently. The team was direct about it:

“It turns out that meeting all these requirements is not possible in the cloud using the traditional monolithic database architecture.”

The design that came before Socrates is what still powers the Business Critical service tier, and it works like this: a database runs as a small cluster of 3-4 replicas, very similar to an always-on availability group. One primary accepts reads and writes, and three secondaries stay current by replaying the primary’s transaction log. Each replica is a complete, self-sufficient SQL Server instance with its own local SSD holding a full copy of the data. If the primary fails, one of the secondaries is promoted, and because it already has everything, it can take over quickly.

That symmetry is what makes it fast, and also what caps it. Every replica needs local storage big enough for the entire database, so a database can never outgrow a single machine’s disk. Backups run on the primary and compete with live traffic for I/O. Adding a replica means seeding a fresh full copy across the network first. Every one of those operations scales with data size, so the largest database the service could support set the cost of routine operations for everyone. The practical ceiling was around 4 TB.

For the rest of this post, I’ll call it the full-replica architecture.

What they built

Socrates separates the database into four tiers, each doing one job well.

Compute nodes run the query processor. One primary handles reads and writes. Secondaries serve read-only queries. Critically, a compute node doesn’t need to store a full copy of the database. It keeps data close through two layers of cache: the in-memory buffer pool and a smart local SSD cache called RBPEX (Resilient Buffer Pool Extension). That SSD cache extends the buffer pool beyond memory, so more reads can be served locally instead of making a trip to a page server.

The XLOG service owns the transaction log. When the primary commits, log blocks land in a fast SSD “landing zone,” and XLOG fans them out to everyone who needs them. This is where durability lives. One of the key decisions is there is “push” of the log unlike AG technology used in BC. Everyone “pulls” from the log and only apply log records for pages in their caches.

Page servers own the data. Each one holds a slice of the database, applies log records to keep its slice current, and serves individual pages on request. These are, for the most part, full covering, which means any page not found on compute node can be fetched here. This is how a new compute can spin up so quickly, there’s no seeding or data copy, just pointing.

XStore, built on Azure Storage, holds the long-term durable copy and handles backups through snapshots. It also contains destaged log for longer retention.

The connective tissue is a call called GetPage@LSN. A compute node (whether it’s a primary or a replica) that needs a page it doesn’t have in cache asks a page server for that specific page, at a specific point in the log. It’s a small idea with large consequences, “the Page Server waits until it has applied log up to that LSN and then returns the page, which guarantees the replica never sees a stale page.”

“Separating the log and storage tiers separates durability (implemented by the log) and availability (implemented by the storage tier).”

Once those two concerns are separate, backup stops being a compute problem. Restore stops being a copy operation. Adding a replica stops being proportional to database size.

What it bought

The paper’s own before-and-after table is the clearest summary of the payoff:

Two things stand out. Scale operations went from O(data) to O(1). Adding a read replica no longer depends on how big your database is. And storage overhead was roughly cut in half, from four copies to two (note that we also replicate each XStore blob for each replica for resiliency).

Caching held up better than you’d expect. On that 1 TB database, a cache covering 22% of the data still served 52% of reads. On a 30 TB TPC-E database, a cache covering just 1% of the data served 32% of reads. Real workloads are skewed, and the architecture leans on that.

Under update-heavy load, Socrates pushed 89.8 MB/s of log versus 56.9 MB/s for the full-replica architecture, roughly 58% higher, because backups moved to XStore snapshots instead of competing with the log.

Where you see this today

If you run Hyperscale, you’re running the descendants of this design.

• Backups are near-instant and don’t consume your compute, because they’re snapshot-based in the storage tier.
• Restore time is largely independent of database size. Restoring 50 TB is not 50 times harder than restoring 1 TB.
• Read replicas come up fast, which is why named replicas work as a pattern for isolating reporting or AI workloads from your transactional traffic. This is what you’ve heard me call “read scale on the fly”.
• Storage grows automatically up to 128 TB, without you pre-provisioning it.
• Log throughput now reaches 150 MB/s, up from the 100+ MB/s reported when the paper was published.
• Continuous priming is a new concept available that keeps the hottest pages in caches for replicas.

There’s one more line from the paper worth reading as a design philosophy:

“Every database function that can be offloaded to storage relieves the Primary Compute node and the log, the two bottlenecks of the system.”

Seven years later, that sentence still describes how the team makes decisions.

Why this matters if you’re choosing a database

Developers evaluating databases in 2026 tend to sort them into “modern, cloud-native” and “the relational one my company already has.” Socrates is a useful counterexample. Compute-storage separation, log as a service, and page-level remote fetch are the same architectural moves that show up in systems marketed as cloud-native today. Microsoft SQL got there in production, at scale, and kept full T-SQL compatibility while doing it.

That last part is the interesting trade. Your existing application, your existing queries, and your existing tooling still work. The architecture underneath changed completely.

And, completely unrelated to this paper – I have to call out a few other things about Hyperscale today:

• It has no separate software to acquire, purchase, or maintain. We priced it at open source.
• This architecture is great for large databases but it also works for small databases. It starts at 10GB. You can, as Bob Ward says, “start here, stay here.”
• We just announced serverless auto-pause and resume support in public preview. This means you can make it scale to zero when inactive, if you want.

Credits

Socrates: The New SQL Server in the Cloud was written by Panagiotis Antonopoulos, Alex Budovski, Cristian Diaconu, Alejandro Hernandez Saenz, Jack Hu, Hanuma Kodavalla, Donald Kossmann, Sandeep Lingam, Umar Farooq Minhas, Naveen Prakash, Vijendra Purohit, Hugh Qu, Chaitanya Sreenivas Ravella, Krystyna Reisteter, Sheetal Shrotri, Dixin Tang, and Vikram Wakade (Microsoft Azure and Microsoft Research).

Next steps

• Read the paper: Socrates: The New SQL Server in the Cloud (SIGMOD 2019)
• Understand the architecture: Hyperscale distributed functions architecture
• Try it: Create a Hyperscale database
• Next in this series: Constant Time Recovery, and why a 12-hour recovery became a 3-minute one

Full article content is not available for inline reading.

Read the original article →

After years of resisting, Apple today launched a MacBook Pro with a touchscreen starting at $2,899. The release comes nearly 10 years after the company first tried integrating touchscreens on its laptops, with its Touch Bar on a MacBook Pro, which it later went on to remove.

The new MacBook Pro more fully embraces the touchscreen, offering a new PROLED XDR Display in both 14-inch and 16-inch screen sizes. The device is powered by M5 Pro and M5 Max chips as options to choose from, along with up to 128GB of unified memory and up to 16TB of storage. The display has 2,000 nits peak HDR and SDR brightness and a 10,000,000:1 contrast ratio.

To make the new MacBook easy to use, Apple designed a hinge that stabilizes the screen when users touch it. This also helps to stabilize the camera when you are on a video call and trying to access content on the display.

In addition, the screen will include a Dynamic Island-style cutout instead of the notch that’s present on most of the current MacBooks. Plus, the new MacBook features a six-speaker array with a new woofer design for better sound.

The 14-inch Pro weighs 3.0 pounds (1.38 kg), and the 16-inch Pro weighs 4.0 pounds (1.82 kg) — lighter than its non-touch predecessors.

Both feature three Thunderbolt 5 ports, an HDMI port, an SDXC card slot, MagSafe, and a headphone jack. Users can hook up three external displays on the M5 Pro variant and up to four displays on the M5 Max variant.

The Touchscreen MacBook Pro 14-inch starts at $2,899, and the 16-inch version starts at $3,399.

Consumers can place a preorder for the new touchscreen MacBook Pro from October 30, and the device will be available starting November 6.

The new Touchscreen MacBook marks two marquee product launches for new CEO John Ternus, who also introduced the company’s first foldable, the iPhone Duo, in September. Various Apple executives, including Steve Jobs and Tim Cook, have scoffed at the idea of a touchscreen Mac in the past. Jobs famously called the idea “ergonomically terrible” at one point. However, rumors of the company working on such a variant started circulating nearly three years before today’s introduction.

The launch follows yesterday’s unveiling of a new standard MacBook Pro with the M6 chip in 14-inch size starting from $1,999.

We’re announcing Genie 4, our new world model for real-time interactive simulation.

Today, we’re announcing our research on Genie 4, our new world model that brings unprecedented realism and native audio to real-time interactive simulation.

The Genie 4 model incorporates and builds on capabilities from the Gemini family: Gemini Omni anchors simulations in real-world appearance and behavior, while other Gemini models provide the complex reasoning needed to help maintain a simulation’s coherence and continuity.

With Genie 4, you can set an event in motion and steer scenes in real time using natural language, like moving the camera, changing the weather, or introducing new characters. Every world also generates native audio on the fly, including ambient sounds, music, and interactive dialogue.

Simulating the world is a crucial step toward AGI, enabling safe training environments for robots and agents, and amplifying creative tools across industries like filmmaking, journalism, gaming, and manufacturing.

We have started rolling out Genie 4 to a limited group of trusted testers. It’s coming soon to Google AI Ultra subscribers in Project Genie and early access partners in the Gemini API and AI Studio.

Heads up: your browser doesn’t support customizable selects yet, so the “after” demos below look like ordinary selects. That’s also exactly what your visitors would see in this browser. To see the difference, open this page in Chrome or Edge.

There are multiple articles about appearance: base-select and how you can use it. We finally can style a select. The bigger change is what an option can hold. Until now, an option was one line of plain text, so everything a person needed to decide had to fit in a label or be left out. Now an option can carry the thing people actually decide with: a preview, a number, a job title, a warning. They stop reading and working things out, and start recognising.

Below are five selects, each shown before and after. The before is what most forms do today. The after is the same <select>, with the same keyboard behaviour and the same form value. Only what it shows has changed. If you want the mechanics, the Chrome team’s announcement and MDN’s guide cover them well.

See it, don’t imagine it

A font picker usually lists names. To choose well, you either already know what Fraunces looks like, or you pick it, look at the result, and come back to try the next one.

When each option is set in its own typeface, the option is the preview. You judge the shape, not the name.

This pattern is not new. We already have in document editors (like Google Docs) and in design tools (like Figma and Photoshop). It just became available for us and all we need is one inline style per option, style="font-family: 'Fraunces', serif", and the closed control keeps the typeface after you choose. We are also able to show the category of each font, like Serif, Sans, Mono, Display, or Handwriting.

Let the list do the maths

Time zone pickers tend to look like “(GMT+09:00) Tokyo”. The offset is accurate and almost never what you want. What you want is the time there, so you add the offset to your own time in your head, and maybe get it wrong around midnight.

Show the current time next to each city, plus whether it’s day or night, and the question answers itself before you choose.

This is the only demo that needs JavaScript, because the times come from Intl.DateTimeFormat.

Compare at a glance

Delivery options are usually a group of radio buttons, each with its details written out as a sentence.

To be fair, radio buttons have a real strength. Every option is visible without a click, and for two or three short choices they’re the right pattern. But once each option carries a few facts, the facts end up in prose. Comparing means reading every sentence and holding the numbers in your head.

A select with the facts in aligned columns turns that into a glance down a column, in the space of a single field.

The columns are a grid on each option:

option { display: grid; grid-template-columns: 1fr 6.5rem 4rem; }

Tell people apart

At a company of about two hundred people, we had two colleagues with the same name, in different departments. Whenever I had to pick one of them, I went by their job title. Photos help less than you’d think, because people often don’t know what a colleague looks like, especially one in another department.

A text-only select gives you two identical options and a guess. Put the title and department under each name and they become two different answers. The closed control keeps the title too, so anyone reviewing the form can see who you picked.

Know before you choose

Some options come with consequences. In a plain select, you find out afterwards.

Mark those options in the list and you know while you’re choosing.

The badge appears only on the options that require special attention, and nowhere else.

It’s still a select

Every “after” in this post is a plain <select>. Keyboard handling, type-to-jump, form submission, select.value, required, validation and the accessible role all stay with the browser, and the control itself needs no JavaScript.

The bigger trade-off is on phones. A native select opens the operating system’s own picker. It shows a scrolling wheel on iOS, a sheet on Android. Those are familiar, sized for thumbs, and tuned to each platform’s accessibility features. A customizable select doesn’t use them; it draws its own list on the page instead.

You don’t have to pick one behaviour for everyone. Opt in only where there’s a mouse or trackpad, and touch devices keep their native picker:

@media (hover: hover) and (pointer: fine) {
  select,
  ::picker(select) { appearance: base-select; }
}
/* Or we can rely on the window size */
@media (min-width: 768px) {
  select,
  ::picker(select) { appearance: base-select; }
}

Phone users then see each option’s text without the extras, which is one more reason the text has to stand on its own. The demos in this post opt in everywhere, so you can try them on any device.

Start using it today

Customizable select is a textbook progressive enhancement. A browser that doesn’t support it doesn’t break. It shows a regular native select, keeps only the text of each option, and submits the same value. Nobody gets a worse form than they have today. If you’re reading this in Firefox at the time of writing, the “after” demos above are exactly what your visitors would see.

That leaves one requirement, and it’s good practice anyway. The text of every option has to make sense on its own. “Ahmed Mostafa, Accountant · Finance”, not just a name. “Express, Tomorrow, $8.50”, not three loose fragments. In the demos, small separator spans that are hidden in the customized version make the plain version read like a sentence. No polyfill needed.

So there’s no reason to wait. Find the select in your product where people hesitate the most, ask what they’re really trying to find out, and put that answer inside the option. Leave everything else out.

NVIDIA's Nemotron 3.5 Transcribe is an open-weight model for multilingual transcription, translation, speaker attribution, and audio Q&A. It's ranked first across several transcription and speaker attribution leaderboards, supporting up to 40 languages with low error rates. Granary v2 enhances this by offering reusable data pipelines and fine-tuning options, enabling customization for diverse vocabularies and specialized applications.

Full article content is not available for inline reading.

Read the original article →

I can't believe it's not silicon

Qwenputer is a pretty fun experimental model. It's a stock Qwen 3.5 4B with one addition: a RISC-V CPU embedded within the weights that uses the model's own Gated DeltaNet attention layers as RAM. (To learn how GDN works, here's a handy guide.) This 'CPU' runs completely within the forward passes of the model, and can run arithmetic operations, C and MicroPython code without any external runtime or tool usage whatsoever.

To be very clear, it is not a plugin, a tool or a sandbox. This blog will explain exactly how this model works, and how the model utilises GDN layers as RAM, and how I also slotted in an experimental in-model file storage.

I also wrote up two follow-ups built on top of Qwenputer: how hybrid models can learn to hide their reasoning in their RNN state and evade CoT monitoring, and how compiled weights like these can work as inbuilt monitoring tools that the model itself can't tamper with.

You can grab Qwenputer from Hugging Face or ModelScope, and the code is on GitHub.

The RNN inside Qwen3.5 can be exact RAM

Qwen3-Next and Qwen 3.5 (the model Qwenputer is built on) use a pretty neat trick. 3 out of 4 attention layers in the model use Gated DeltaNet, a linear RNN, as the attention mechanism. Each head keeps a state matrix, and the delta rule keeps this updated.

Now, here's where our fun experiment starts. I found out that by setting the gate to 1, the write strength (beta) to 1, and using one-hot key encoding, every write we perform will overwrite exactly one row, and every one-hot query can retrieve an exact value. This means that the GDN layers themselves can work exactly as RAM, at a far lower cost than using normal attention as RAM, since a GDN head's state stays the same size however long the conversation gets, unlike attention's KV cache.

The idea that the delta rule acts as a memory isn't new: Schlag et al. (2021) showed that linear attention with the delta rule works as an associative memory, or "fast weights". The new thing here is making it exact and addressable, inside a production model, reliably enough to run a whole CPU on it.

This is the base on which this entire model is built. As it stands, default Qwen 3.5 does not keep exact values in the GDN. With this modification, we unlock the next part of this experiment.

Compiling a computer into layers

Since we have a fully functional, cheap and fast RAM now, we can go ahead with compiling a working CPU into the model weights. Luckily, there's no training involved: a compiler sets every weight directly. You describe the CPU as a circuit, a long list of small steps like "read this register", "add these two numbers" or "jump if zero", and the compiler turns each step into a piece of a transformer layer: attention heads that look things up, feed-forward units that do the arithmetic, and DeltaNet heads that hold the RAM. The CPU then runs as the model decodes.

Each instruction becomes a few generated tokens: one names the memory row to write (ADDR), the next carries the value (VAL), and a STEP token ends the instruction. Those tokens are the CPU's execution trace, so while Qwen is generating them, the CPU is actually running.

The CPU

The CPU is a 32-bit RISC-V core (RV32IM, plus the Zba extension and a small bignum unit for big-number arithmetic), and it takes up 11 layers in front of Qwen's 32. As it stands, it passes the official riscv-tests, its programs match qemu, and it has run 18 million instructions free-running without a single error.

This CPU can also run C and MicroPython code in the forward passes quite well (although a bit slowly). It is not a Linux-class chip yet, but it implements the full RV32IM instruction set.

How Qwen uses it

Qwen 3.5 4B is able to use this CPU quite well, without any post-training required. The CPU is used completely internally, and not invoked through any external tool calls.

In order to make the model use this reliably, I decided to go the cheap way: by piggybacking on the tool call format that models are quite well-trained on, Qwen sends the CPU its instructions and reads back the results. No external tool calls or runtime are used. Once our CPU receives the instructions, the computer layers run, and then write the tool response. We use a small driver called RvChat to load the firmware into the GDN state, and this keeps the trace tokens out of Qwen's layers.

Qwen's original weights stay exactly as they are. The computer weights are added on top of them, in extra dims and layers.

Does it work?

On the DeepMind sets:

• div_big: Qwenputer scores 97.5%, versus 95% by giving Qwen 3.5 4B a Python tool and 72.5% for base Qwen.
• mul_big: Qwenputer scores 97.5%, versus 100% with a Python tool and 55% for base Qwen.
• mul_div_multiple_longer: Qwenputer scores 100%, versus 97.5% with a Python tool and 90% for base Qwen.
• add_or_sub_big: Qwenputer scores 97.5%, the same as with a Python tool, and 87.5% for base Qwen.

On NUPA's long-integer arithmetic, Qwenputer goes from 48.6% to 100%, the same as giving Qwen a Python tool.

The numbers the CPU prints are exact, too: I replayed about 230,000 of its output positions against a reference machine and found zero mismatches. And bolting a computer onto Qwen doesn't change how it talks: its normal text stays within noise of base Qwen (KL 6e-4, against a noise floor of 5e-4).

A hard drive? In this economy?

Because a CPU inside a language model clearly wasn't cursed enough, I decided the prudent thing would be to give it a filesystem too.

Since we already have a functional RAM, this was mostly trivial. On the model side, it's exposed via internal put / append / get / list / delete operations. Once again, no actual tool calls. When Qwen 'saves' a file, the compiled layers hash its name into one of 1,024 slots in a directory kept in the DeltaNet state, and store the text itself in other heads, with eight tokens per row, chained together. In scenarios where two names end up landing on the same slot, it just checks the next one. Finding a file again takes roughly two or three steps instead of a scan, and it holds up to 512 files, which comes out to about 53,000 tokens of text.

Fun thing is, this is quite persistent. You can save the state at the end of a conversation, load it into the next one, and the files are still there. Using this filesystem, Qwen gets facts that changed between chats right 90% of the time, against 30% when you paste the old chats back in, and it's on par with giving Qwen memory tools run by Python (83.3% vs 78.9%).

Limits and what's next

Qwenputer is very much an experiment, so a few limitations. The extra layers and wider hidden size make the checkpoint 18.8 GB, roughly double base Qwen, although most of it is zero padding. It also needs a small driver (RvChat) to boot the firmware and keep the trace tokens out of Qwen's layers, so it doesn't run with a plain generate() call yet. And it's a bit slow, with every CPU instruction costing a few decoded tokens, so a big calculation takes seconds rather than milliseconds. The batched executor I used for the benchmarks runs about 3,200 CPU tokens a second on an L4.

Next up, I want Qwen to write Python and run it on the MicroPython inside its own weights, through a python() tool that works the same way calc does. Making the CPU faster is the other big one.

Beyond arithmetic

Exact control over the RNN layers is useful for a lot more than arithmetic. It also makes Qwenputer a really nice testbed for AI safety research.

Try it

If you want to play with it yourself, the model runs on a single 24 GB GPU. You'll need uv and the Hugging Face CLI. You don't need a tool server or a Python sandbox for the calculations: the CPU runs them inside the model.

git clone https://github.com/divagr18/qwenputer && cd qwenputer/experimental/riscv && uv sync --extra hf
hf download divagr1925/Qwen3.5-4B-Qwenputer --local-dir qwenputer-rv
uv run python -m chipformer.rv.chat qwenputer-rv --firmware tests/data/rv/calc-bridge.elf \
    --ask "Use calc: what is 123456789 * 987654321?"

Coding agents are opening more pull requests than ever, and each one waits on CI before anyone can review or merge it. Most CI systems run the entire workflow on every push, even a one-line change. The more your agents push, the more time you spend waiting on CI.

Today, we're announcing Vercel CI in Beta. It runs only the tasks affected by your code change, and spins up only the compute those checks need, the same way Fluid compute scales with your traffic.

At Vercel, our CI now keeps up with our coding agents. Time from git push to "CI passed" is 2-6x faster than it was before.

How it works

Vercel CI uses Turborepo to understand your tasks and which ones depend on each other. It reads turbo.json, so if you're already using Turborepo, there's no separate CI config to write.

If you're not on Turborepo yet, add turbo.json and the turbo package. It works in single-package repos too.

Then tag the tasks you want Vercel CI to run.

{
  "tasks": {
    "lint": {
      "tags": ["ci"]
    }
  }
}

"tags": ["ci"] is all you need to get started. No workflow YAML to maintain, no drift between your CI config and turbo.json, and Remote Cache is on by default.

When you or your agent push code, Vercel CI determines which tasks need to run based on the change. Tasks whose inputs haven't changed come from cache. The remaining tasks each run on their own machine, powered by Hive, Vercel's compute layer, and start as soon as their dependencies finish.

Vercel CI gives each task the compute it needs and nothing more.

Running your CI on Vercel

To get started, follow the documentation or prompt your agent from your repo:

Set up Vercel CI for this repository. Run `npx skills use vercel/ci@setup` and follow the skill's instructions to select initial tasks, configure Vercel CI, and open a pull request.

Once set up, you or your agent can watch and inspect CI through the Vercel dashboard, Vercel CLI, or Vercel MCP. When something fails, go straight to the failing task, see what's blocked behind it, and open its logs, or search across recent runs to see whether a test has been flaky all week.

vc ci ls # List CI runs for the repository
vc ci inspect <run> # List tasks for a run
vc ci logs <run> # Get logs for all tasks in a run
vc ci logs <run> --task web#test --level=error # Get stderr for a specific task
vc ci grep "WARNING" # Search across run logs for a string

Vercel CI posts a check to your pull request on GitHub, so your existing branch protection rules can block merges on failure, the same way they do today.

Closing the loop

Vercel CI has already completed nearly 8 million tasks across our own repositories and the private beta, and we're just getting started. We're working to keep shrinking the time between writing code and running it in production.

As we work toward general availability, we plan to add:

• Advanced observability
• A vc ci CLI command for distributed execution before pushing code
• More granular test selection

Vercel CI is available in Beta today on all plans. Read the docs and try it on your repository.

The financials Anthropic shared with investors this week suggest that its AI coding tool, Claude Code, is every bit the business success the frontier lab wanted. The company recorded an operating profit in the second quarter, and 900% net revenue retention — that is, spending from the same customers in Q3 2025 grew nine times in Q3 2026.

Anthropic has focused on getting enterprise users to stick around and Wednesday announced a new suite of reporting tools designed to give those customers a more granular understanding of the value they get from their token spend.

Using internal analytics and employee surveys, managers can view a team’s work over a given date range, what the team produced, how much it cost, and where its workflows broke down. Anthropic says it won’t use this data for model training by default. The reports will also offer recommendations on how to improve the results.

This is a clear attempt to demonstrate the return on investment of Anthropic’s tools and to show customers how to improve it — a major concern among large customers. Anthropic is also creating pooled group budgets to allow teams to better manage token spending.

Businesses have been hunting for that kind of information as they figure out how best to deploy AI tools. While usage among venture-backed firms is driving token spend, most of the Fortune 500 are not seeing major gains from deploying AI.

Jellyfish, a company that makes tools for software developers, released a new report yesterday based on the use of agentic coding tools by 276,000 of its customers. Claude Code and other tools built on Anthropic models remain the most widely used in the survey, responsible for nearly a third of all proposed code changes submitted for review. More importantly, spending on those tools has grown 10x since the beginning of the year, with their cost now equal to about 2% of total engineering cost.

“Even if you’re saying 2% is still small, that 10x growth is growth that most CFOs didn’t plan for,” Nicholas Arcolano, the chief scientist at Jellyfish, told TechCrunch. We’re certainly getting to the point where people are realizing, okay, it’s not enough to just spend a bunch. You now have to optimize it, make it work.”

Anthropic’s new reports speak to that challenge. Anthropic leads among enterprise customers, but what makes an agentic coding tool truly sticky is difficult to identify. The release of OpenAI’s Astra model this summer seemed like a potential threat to Anthropic, but so far it hasn’t slowed Anthropic’s adoption numbers.

“It took a long time for us to see Codex really pop in our data at all, and it has come up with Astra [OpenAI’s latest model],” Nikolas Albarran, the AI product lead at Jellyfish, told TechCrunch. Looking at X, he continued, you’d get the distinct impression that the competition is more heated. “Everyone in the Valley is like, ‘Oh, Codex is better.’” In reality, Albarran continued, “Anthropic was just there with great enterprise motions, and they had an incumbent weight of their own — this stuff just worked and worked well, and a lot of people just put a lot of effort into standardizing workflows around it. And there’s not a big enough reason to switch.”

It’s not just a question of models and workflows, either. The realities of business mean that once a frontier lab has gotten its hooks into a customer, switching is harder than it is compared to an individual programmer or small organization. Albarran points to the investment all the major AI labs are making in forward-deployed engineering (FDE) organizations, teams that embed AI consultants inside customer organizations to help them get off the ground. These new reporting tools can be seen as a kind of FDE-lite, a lighter version of that hands-on help, for Anthropic customers.

“We’re at a point now where it’s mature enough, where once you’re in, it’s going to be harder and harder to switch because you’ve spent the effort,” he said. “Even if they’re all mostly the same, they’re all going to be slightly different, have their own slight quirks of how they handle agent.md files, etc., and so that cost to switch is not zero.”

Build and manage Connected Apps in one place

We’re launching a Connected Apps Platform to give developers a single place to build and manage apps for Search and the Gemini app. Plus, we’re rolling out a new set of Connected Apps from partners like Adobe, Calm, and Peloton.

From ordering groceries to making playlists, Connected Apps in Search and the Gemini app have made everyday tasks faster and easier.

To help users get more done, today we’re launching the preview of our Connected Apps Platform, a unified way for more app developers to bring their capabilities directly into Gemini and Search. We’re also rolling out a new set of Connected Apps partners to give people even more ways to streamline their day.

Manage Connected Apps with ease

The Connected Apps Platform gives developers the opportunity to build once and reach high-intent users across both Search and the Gemini app. Developers integrate with a cloud-hosted MCP server or Android MCP using the AppFunctions APIs, then use the Google Connected Console to register, test, and submit their app. Before review, developers choose whether it will go live in Search, the Gemini app, or both. Once live, you can track traffic, latency, and error rates, and keep control of your brand identity, including verified logos and authenticated accounts.

We're opening access in phases, and will add more developers, markets, and Google products over the coming months. Sign up for the preview and explore the documentation at developers.google.com/connected-apps.

Connect to your favorite tools

We’ve launched more than 50 Connected Apps between Search and Gemini in areas ranging from productivity and event ticketing to health and fitness. Integrations with partners like Adobe, Experian, Localiza, and Peloton are live for users in Gemini, and in the coming weeks, we’ll be bringing these Connected Apps to Search as well. Among other apps, we'll also be launching a new integration with Calm across both Search and Gemini.

To see all the Connected Apps you can access, visit our help center pages for Search and Gemini.

If you’ve ever watched a movie on TV where there’s an issue with the broadcast, and the actors’ dialogue is completely out of sync with the captions, you know how distracting it can get, and pull you out of the story. Videos and software using voice models have the same problem: A subtitle that appears a second late, or a transcript that highlights the wrong word, can feel just as broken.

“Humans are quite good at aligning media, at the word level at least,” said Danila Kozlov, a researcher at ElevenLabs working on alignment. “We often have the inherent feel of where a word is beginning, but at the character level and with sub-millisecond precision, it’s a lot harder.”

Today, ElevenLabs is sharing more on Cue, a forced alignment model that places every character in an audio file on a precise timeline. Cue powers ElevenLabs’ Scribe model family, and on real-world recordings, it’s more accurate than every aligner ElevenLabs tested, in all 29 languages of the benchmark. It also handles recordings of any length in a single pass and aligns an hour of audio in less than a second.

What is forced alignment?

Imagine someone hands you a video and a transcript and asks you to match each word to the moment it’s spoken. That is forced alignment. When you click a word in an ElevenLabs transcript and the player jumps to that exact spot, an aligner is doing the work.

Forced alignment, however, is different from the more nebulous concept of AI alignment. That’s about designing AI systems so their behavior matches people’s value systems and business preferences. With forced alignment, we’re talking just about lining up text and sound.

Cue is the last step in the speech-to-text pipeline. Scribe, ElevenLabs’ Speech to Text model, transcribes the audio, and the aligner sets the timing. Every Scribe request passes through it. The same model also powers subtitles, dubbing, and lyric timing for music, and it’s available on its own through the Forced Alignment API.

Because so many products depend on it, an aligner has to be precise in every supported language, extremely fast, and able to handle many requests at once.

Where traditional aligners fall short

Prior to the new model, the team built the aligner model that had been used in every ElevenLabs product to date. Although powerful, they knew they could make a new version stronger. When Kozlov joined, he and the team began by interviewing customers and internal users at ElevenLabs about what frustrated them when working with the previous aligner. Their complaints matched the limits of the open-source tools the team tested.

Length is the first major problem. Many aligners today work well for clips about 30 seconds long, but longer files have to be chopped into chunks. Each new chunk has the potential to add a little timing error, and stitching the seams between chunks can add more. On full recordings, Cue’s average amount of timing errors is just 179 milliseconds, while the open-source tools ranged from 283 ms to more than 6,000 ms.

Real-world recorded audio is even more of a challenge. Background noise, overlapping speech, and ambient music cause many tools to lose their place when matching up text to audio. But these are the sorts of files that many people actually want transcribed, as we all tend to live in places that aren’t perfectly quiet. On English recordings with background issues, Cue’s average error is 57 ms, compared with 65 ms to 920 ms for the others.

Language support is another constraint. Most open-source aligners need a separate model for each language they support, so languages with less training data often don’t perform as well, or just aren’t supported. MMS-FA is the only other tool that handles all 29 benchmark languages, and comparably, Cue was generally quicker at figuring out the boundaries between words.

Speed is also an issue for these models, as aligning large volumes of audio can get expensive quickly. Cue can align one hour of audio in around half a second on our production GPU. The next fastest tool, Qwen3-ForcedAligner, takes nearly 2 seconds, and the slowest tested, took well over a minute.

How Cue is different

Cue is a single model that covers more than 90 benchmark languages, unlike most of its competitors. It can also take recordings of any length in a single pass, which avoids the chunking that causes timing errors to build up on long files.

While most models have gotten larger as they get more performant, Cue is smaller than the previous ElevenLabs’ aligner, Kozlov said. It still runs on a GPU, but it aligns an hour of audio in about half a second.

The team built Cue around the types of audio people actually upload. Using the previous aligner as a baseline, they created a benchmark from real-world requests and scored every tool the same way, counting any word a tool failed to place as an error. Cue works at the character level, which is finer than the word-level labels most benchmarks use, so those scores likely understate its precision.

“At some point you reach the level of human abilities,” Kozlov said of aligner models. “Our current aligner is beyond that level, and so it becomes a lot harder to check whether you’re fully correct or just how precise you are, because there’s no golden benchmark for it. We had to use word-level benchmarks to benchmark a character-level system, which does not necessarily showcase Cue's full potential.”

Cue’s quality also reflects how quickly ElevenLabs can act on user feedback. Soon after Cue was rolled out, a customer alerted the team that Georgian and a couple other languages with fewer resources performed worse than they had been expected to. ElevenLabs keeps research close to the teams and customers using its products, which meant they were able to catch the issue quickly, conduct research on possible model improvements, train a new version of the model and release it — all within less than 24 hours from when the customer first brought up the issue.

Aligning songs

Music is difficult because singing stretches and blurs words, and few models can do it well. The team didn’t expect Cue to handle it as well as it does. Cue was able to align a subset of songs from the Creative Commons-licensed JamendoLyrics MultiLang dataset. It was able to do this in English, French, Spanish, and German — in one pass — with surprising accuracy. It placed 92.7% of words within 0.3 seconds of the label, compared with 82.0% for the next best tool.

Cue’s average start error was 0.82 seconds, about half that of the closest competitor. It was more accurate than every other tool on at least 19 of the 22 songs. The potential for singing your favorite new songs at karaoke the day they’re released is huge.

Try Cue today

Cue is already behind every Speech to Text transcription on ElevenLabs. To use it directly, try the Forced Alignment API.

Acknowledgements

The work on ElevenLabs' aligner models would not have been possible without many people across the company. The team would like to thank everyone who worked on the previous version of the model, and the new one, including co-founder and CTO Piotr Dąbkowski, researchers Danila Kozlov, Luca Lanzendörfer, Flavio Schneider, Max Levi, Tim von Känel, and Angelos Perivolaropoulos; as well as Ani Janelidze in Data Operations, our Forward Deployed Engineer and Support teams; and Lorenzo Dossi for his work on the visualization in this blog.

Copilot Automations can now learn from their outcomes and propose improvements to themselves, helping them produce better results over time.

It’s easy to create an automation, but harder to build one you can trust to consistently produce high-quality results. Reviewing its output and improving its prompt by hand takes time. Self-improvement uses feedback from real outcomes on GitHub to make that process easier.

How it works

Your automations leave a trail of signals on GitHub that show how well they’re working. For example:

• An issue triage automation can learn from whether people change the labels it applied.
• A code review automation can learn from whether developers accept its comments.
• A performance optimization automation can learn from whether maintainers merge the pull requests it opens.

Self-improving automations use these signals to propose improvements to their prompts. You stay in control: each proposed change comes to you for review before it’s applied.

How Copilot creates a self-improvement loop

When you ask Copilot to set up a self-improving automation, it can create a group of automations that work together. For example, for a custom code reviewer, Copilot might create:

• A review automation that runs when a pull request is opened, reviews the changes, and posts comments.
• A weekly improvement automation that analyzes how developers responded to those comments and proposes refinements to the review automation.

When the improvement automation proposes a change to the original automation’s prompt, tools, or triggers, GitHub notifies you. You can review and accept or reject the proposed change before it is applied.

To learn more, see about Copilot Automations.

Copilot Automations is available with Copilot Pro, Pro+, Max, Business, and Enterprise plans.

Join the discussion within GitHub Community.

LOS ANGELES—Apple today announced and gave a first glimpse of its first major MacBook Pro redesign in more than five years. As rumored, it includes an OLED display and, for the first time on macOS, a touchscreen—a change Apple has long debated. (Former CEO Steve Jobs famously was opposed.)

Apple’s demonstration video showed users interacting with applications by reaching up to touch the screen, including file dragging and multi-touch gestures like pinch-to-zoom. It does not appear to be a 2-in-1 convertible design, though; all the footage was of people reaching up to touch the screen in a normal laptop configuration.

The OLED display (which Apple is, of course, calling the PROLED XDR) seems to be the real highlight here, compared to earlier models: It can achieve 2,000 nits in terms of maximum brightness, and Apple says it has a 10,000,000:1 contrast ratio. References were made to burn-in protection, but details on which approach it’s taking for that weren’t yet shared. The display retains the 120 Hz variable refresh rate of its predecessors.

Beyond that, the design is largely similar to the existing one, but there are a few notable differences. First, it’s much lighter. Apple said when announcing it that the 14-inch model is just 3 pounds, down around half a pound from the previous model, depending on configuration.

Second, the top-of-screen camera notch has been replaced by the small black cutout that Apple calls the Dynamic Island. Presumably it works similarly to the one we’ve seen on the iPhone, expanding or contracting to show live activities and other information.

Finally, there’s a retro throwback: The Apple logo on the back of the lid glows like the logo on MacBooks of yore.

In terms of specs, this refresh includes the M5 Pro and M5 Max chips—the same ones in the previous refresh. The M6 series has already arrived in other Macs, but it seems Apple is skipping them for this refresh; there were previously reports that Apple planned to hold off on updating the chip until the M7 series, which could have significant improvements for AI performance, just like the recently released A20 Pro chip for the iPhone does.

Memory configurations top out where they did in previous MacBook Pro models with M5 Max: up to 128GB of RAM. That said, storage can now go up to 16TB—if you can afford it.

Preorders start today, and the device will reach consumers on November 6. As expected, the price is the catch. The M5 Pro-equipped 14-inch model starts at $2,899, while the 16-inch starts at $3,399. But if you want the M5 Max, you’re looking at a $4,499 starting point for the 14-inch, and $4,799 for the 16-inch—and that’s not accounting for any potential RAM or storage upgrades.

Unveiling The Grid: PCBs made in America, twice as fast as Shenzhen

For the last five years we've been quietly running and scaling something we haven't really talked about in public. Today we're showing it to the world. This is The Grid, our factory-scale robot in Massachusetts that builds circuit boards on demand.

The problem

Over the past 30 years, most electronics manufacturing left the West. Assembly was labor-intensive, and labor is expensive in high-wage countries, so it moved to where labor was cheap. We designed in the US and built in China, and for a long time that worked.

Automation is starting to change that, but mostly at huge volumes. SpaceX now builds Starlink dishes by the million in Bastrop, Texas. When you make the same product over and over, it's worth building a line around it.

Most products don't reach Starlink volumes. The typical hardware company needs ten of this, a hundred of that, and a new revision next week. That kind of high-mix work has stubbornly resisted automation, because every new design means hours of setup and manual changeovers. So it either went overseas or to expensive quick-turn shops.

What The Grid is

The Grid takes a different approach. Instead of a fixed line that has to be reconfigured for each product, it is one large robot. Levitating movers carry each board and its parts between machines that print solder paste, place parts, reflow, solder and inspect. Learned models, AI agents and classic optimizers schedule all of it.

Every board takes its own route through the factory. There are no changeovers and no per-design setup, so one unit of 100 different designs runs as easily as 100 units of one. Prototypes and production batches run on the same machines.

It's not only startups who need this. Even the biggest companies have huge numbers of low-volume boards: test stations, tooling, R&D and production batches. A leading EV maker, a top AI lab and household-name tech companies already build on The Grid.

What it means for a real board

To make this concrete, we priced one of our example boards on The Grid and at a typical quick-turn shop in Shenzhen: a 4-layer motor controller with 118 parts per board (38 unique), five assembled boards, parts included, delivered to a US address.

Built on The Grid, the boards are at your door in 4 days for $630. Ordered from a typical quick-turn shop in Shenzhen, they cost about $465 once shipping and US tariffs are added, and take 9 days at the median.

So you pay about $165 more than the Shenzhen shop and get your boards five days sooner, with no customs and a supply chain you can count on. For most hardware teams, five days of engineering time is worth a lot more than $165.

It's not a prototype

The Grid has been running for customers for five years. It already builds tens of millions of dollars of electronics a year. Across CircuitHub we've shipped more than 2.2 million boards, placed more than 150 million parts and served more than 26,000 engineers.

What's next

Demand is already well ahead of what we can build. This year we will 5x capacity, with another big jump coming in 2027.

The longer-term goal hasn't changed since we started: make building hardware as fast as designing it. Electronics manufacturing left the West because it couldn't be automated at the volumes most companies need. The Grid shows it can.

If you want to help rebuild the Western electronics supply chain, we're hiring. And if you have a board to build, get an instant quote.

The October inflection point for vibe game development

I’ve written before about how November 2025 was an inflection point for coding agents—the point where Opus 4.5 and GPT-5.1 crossed a tipping point that meant their respective coding agents became reliable daily drivers for software engineers. I think we’ve reached a new inflection point in October 2026, and this time it’s for vibe coding computer games.

Claude Opus 5.5 in particular exhibits meaningful improvements in several areas needed to build a compelling game:

• 3D modeling
• Music generation
• Game design (!)

That last one is particularly important. Models have been able to create something that looks like a game for quite a while now. The challenge has been getting to a game that’s actually fun to play.

Game design is a deep subject area. I won’t pretend to be well versed in it—I know enough to have respect for it as a craft. Creating a novel, compelling gameplay loop which challenges players at the right level and provides a satisfying learning curve is a fine art. I didn’t think the models could do it.

Then I tried telling Claude Opus 5.5 to “Make it a LOT more fun”... and it did.

In the past few weeks I’ve vibe coded (in the classic sense of the term—no looking at the code at all) four games that I’ve genuinely enjoyed playing.

I attended Foo Camp in Berkeley over the weekend and met several people who were having similar experiences. Building games that play well is shockingly easy now. The new challenge is coming up with concepts for games that are novel and delightful and that wouldn’t exist without AI assistance.

I haven’t done an exhaustive study, but my current impression is that GPT-6 Astra isn’t quite there yet. It can absolutely build a game, but its sense of fun doesn’t match that of Opus 5.5. I expect OpenAI will get there by the end of the year.

Here are the four game projects that have convinced me that the models are now capable of producing fun games with very little guidance. All four are built in HTML and JavaScript and run entirely in the browser.

Tree Appreciator

The smallest game I found to be genuinely delightful is Tree Appreciator. I used the regular Claude chat interface for this—it didn’t even need Claude Code.

I built this on a whim while we were driving along Skyline Boulevard looking at trees. My prompt was:

Build a three js game called "Tree appreciator" - it shows you two algorithmically generated trees and the game mechanics is about appreciating the differences between them. Think hard about how to make sure it is both fun and beautiful.

I’ve found that telling models to use three.js works really well. Claude doesn’t have its own image generation model but is capable of building full-color 3D models that look and feel excellent.

This game required no iteration or follow-up prompting at all—I got the game in a single shot. It gave me back a charming little mobile-friendly spot-the-difference game.

It’s pleasingly relaxing. The graphics are fun, and collecting trees that you have completed in a “herbarium” provides a nice, cosy sense of accomplishment.

Emberwick

This was a more ambitious project that I again built using regular Claude chat. I started out by building an experimental prototype of an engine for a top-down fantasy RPG:

Build a demo game engine three.js which is a top down (but at an angle) RPG - the player gets to move through the world with one or two companions. Create a fantasy village setting that demonstrates walking around outside and then shows how when the player enters a building the wall between the player and the camera goes transparent so the user can see what is happening

Add some NPCs and plenty of furniture and different types of building some with an upstairs - be creative, make it look great

I was inspired to increase my ambitions:

Make it not so flat - the buildings are great but the landscape itself is completely flat at the moment, fix that

Add basements to two of the buildings with a tunnel system joining them below the village

Add the start of a rocky mountain on one side of the village containing a cave with a sleeping troll

When that produced a good result, I decided to push it all the way:

Now turn this into an actual game - quadruple the size of the playable area, introduce fun game mechanics, add a plot that isn't too cliche, some twists, a magic system, make it really good

We’re back to prompts like “make it really good” here! Asking for a plot that “isn’t too cliche” seemed to work too—it’s a bit cliché, but still novel enough that I enjoyed following the story.

Unlike Tree Appreciator, this took quite a bit of additional playtesting and prompting to get to a finished version. This was mainly due to gameplay problems—things like a character not being in the right place to complete a quest because a different story element had caused them to move to another location.

There’s even an experimental level editor if you want to drop in your own houses, furniture, and landscape features.

Once it was all working (and I’d iterated through some gameplay bugs), I played it through from start to finish and found myself emotionally affected by the ending! I’m somewhat embarrassed by this, because everything in this game—the graphics, the plot, the characters, the music, the dialog—came from the model. My creative input was pretty much just “it’s a fantasy village and there’s a troll asleep in a cave”.

Battle Drones

This is by far my most successful project. It’s a Command & Conquer-style Real-Time Strategy game where two robot armies (or four as of Saturday) build units, harvest scrap, and battle over territory.

This is also the project that convinced me that Opus 5.5 knows what “fun” is.

The first versions were built back in July using Claude Fable 5. It got me to a workable 2D Command & Conquer-style game, but it wasn’t great to play.

I prompted Opus 5.5 to “Make it a LOT more fun” and then later to “Port this game to three.js” and the game was transformed.

Today, Battle Drones has 2-4 player multiplayer (via a vibe coded WebSockets relay server), medals, replays, seven maps, a random map generator, and a set of “mutators” that add variants of the rules.

Battle Drones is a particularly good example of Opus 5.5’s ability to create 3D models.

Pumpkin Farmer, aka Quarter Sun Cove

I live in Half Moon Bay, California, home of the annual Half Moon Bay Art and Pumpkin Festival, which includes a giant pumpkin weigh-off competition.

I decided to try building a game that wasn’t just a cheap imitation of something that already existed, so I set out to create a game about farming pumpkins, growing giant pumpkins, and handling the rush of the October pumpkin season.

I called it “Quarter Sun Cove”.

I’m still iterating on this project, but it’s shaping up quite nicely. It’s a cosy farming simulator where you spend the year tending to your giant pumpkin and planting out regular-sized pumpkins for sale in October, then sell pumpkins during pumpkin season and enter your giant pumpkin in the weigh-off.

Every character in it is a (vegetarian) animal. The mayor of the town is a pelican. You can be a pelican, skunk, raccoon, possum, beaver, coyote, fox, owl, sea otter, or harbor seal. Those species all later show up (accompanied by their children) to buy pumpkins from you.

I told Claude to “surprise and delight the user frequently” and the result is so many little details and easter eggs. There are mischievous raccoons, an elephant seal that runs the weigh-off, harbor seals that roll their pumpkins back into the ocean, a wandering goat, and superstitions about growing giant pumpkins that sometimes come true.

This isn’t my best game yet—it’s not as fun to play as Battle Drones—but it represents the kind of game I want more of: weird, fun, uniquely personal—something that wouldn’t have been built in the before-times.

Four times as insulting

If you are offended by AI-generated art, AI-generated music, AI-generated writing, and AI-generated code, I have bad news for you: vibe coded games combine all of those at once.

I respect those opinions, even though I don’t strongly hold them myself.

The wider games community already has an aversion to AI-generated assets in games. This has been a growing issue over the past few years as tools like Midjourney have enabled developers to generate assets for their projects.

We now have games where everything—code, assets, dialog, and even the game design itself—can be outsourced to the models. And the results don’t suck!

Building a computer game used to be one of the most challenging projects in all of software development, combining a diverse range of skills and requiring intense focus and effort over many months or even years. And now here I am spitting out a playable multiplayer RTS by prompting on my phone!

I expect that, as we’ve already seen with programming, this will result in a split. Some players will refuse to have anything to do with games that were built in this way. Others may embrace this as opening up game development to a much wider audience. I lean in that direction!

What happens if someone actually puts the work in?

The thing I find both exciting and shameful about this is that I have got interesting results from so little creative input. The projects I’ve described here are loosely ordered by how much effort I’ve put into them. Not a single project represents more than four hours of my work (plus many more hours of Claude Code churning away by itself).

Now imagine what could be achieved by anyone who takes this seriously, invests significant creative time, applies better taste in game design, and then playtests and iterates on the result until it’s as good as they can make it.

I want to see games that wouldn’t have existed without these new tools.

You should build a game!

Building games in this way is so much fun. It’s the perfect application for vibe coding because it’s so low stakes: how much damage can you cause with a bug in a personal vibe coded game project?

All of my games so far have been HTML and JavaScript using static hosting (generally GitHub Pages or Cloudflare Pages). Modern browsers—including mobile browsers—are incredibly capable. Frontier models already know libraries like three.js and Phaser. I’m finding these mobile web games to be indistinguishable from the native experience, at least for the kinds of games I’m trying to build.

I suggest starting with a prompt like this:

Build a mobile-friendly three.js game where...

Switch to Codex or Claude Code once your project passes the proof-of-concept phase.

And if the game isn’t fun enough, add this:

Make it a LOT more fun

Jay Parikh is a seasoned executive, board member, and advisor to some of the world’s fastest growing and most successful consumer, developer, and enterprise technology companies. As Executive Vice President of CoreAI at Microsoft, Parikh leads the organization building the end-to-end agentic system required to build, ship, and run AI agents in the Enterprise. His teams, including GitHub, also build the tools and platforms developers need to create the next generation of software.

Previously, Parikh was CEO of a cloud security startup and, before that, was Facebook’s global head of engineering and infrastructure. For more than a decade, he led the teams that built and operated the physical infrastructure and software that supported the company’s growth from 300 million people to more than 3 billion. His teams worked across the stack, from data centers, servers, and subsea cables to software, data, AI, and security systems. Through leadership roles in the Open Compute Project and Telecom Infra Project, he helped extend infrastructure innovation beyond a single company to benefit entire industries.

Earlier in his career, Parikh held leadership roles at Akamai and Ning. He brings a systems thinker’s perspective to a deeply human challenge: how to build teams that keep learning, moving, and delivering as the world changes around them.

The 2026 Cloud Data Warehouse Benchmark

This benchmark ran 244 queries on seven cloud data warehouses (Snowflake, Databricks, BigQuery, Redshift, Microsoft Fabric, ClickHouse and MotherDuck) at five or more compute sizes each, on 1 GB to 1 TB of data, first with one person querying and then with up to 100 sessions at once. For each size it records how fast queries ran, how many did not complete, and what the compute costs at list price.

There is no best data warehouse; the right one depends on your workload and your requirements. This site lets you understand the tradeoffs and select the best data warehouse for your workload.

What the benchmark measured

• Seven engines, each run on five to eight of its compute sizes (ClickHouse on five single-replica and eight three-replica sizes), with automatic scaling switched off so that each result describes one fixed unit of compute. Fabric is the exception: its smoothing of bursts cannot be switched off.
• 244 queries in three public suites. TPC-DS (99 queries) and DSB (102 queries) are join queries, the kind most reports and dashboards run; DSB repeats the same reports on skewed data. ClickBench (43 queries) contains scan queries over one wide table of web page views.
• Four data volumes for the join queries: about 1 GB, 10 GB, 100 GB and 1 TB (the scale factors SF1 to SF1000). The scan queries run on one table of about 100 GB.
• One person, then many. Every query ran one at a time (the single-user pass), and then under bursts of 1, 5, 10, 20, 50 and 100 simultaneous sessions (the concurrency grid). The sessions share one queue of queries. The scan suite has 43 queries, so on scan queries the highest level is all 43 at once.
• The same data in every engine. Estuary loaded one copy of the data into all seven, so every engine answered the same questions over the same rows.

Three questions to answer when choosing a warehouse

1. Do your queries join tables, or scan one wide table? Reports and dashboards built by a business intelligence tool usually join tables. Event, telemetry and product dashboards usually scan one table.
2. How many people will have a query running at the same moment? This is usually much smaller than the number of people who use the warehouse. If one in ten of 400 people is querying at any moment, that is 40.
3. What hourly spend would you approve? Compare engines at that spend, since each engine's fastest size is also its most expensive.

Size to your data volume: a bigger size pays off only when the data is large enough to use it

Plan for the number of people querying at once

ClickHouse did not finish the join queries at 100 GB but placed third on scan queries

Before you compare hourly rates, check how each engine bills idle time

Every hourly price here assumes the compute is busy. Most warehouses are quiet for much of the day, and the seven engines bill quiet hours very differently. The table below summarizes each vendor's public documentation as of . The benchmark did not measure idle time.

What to keep in mind when reading these results

• No engine's physical layout was tuned. No clustering, distribution or sort keys, partitioning or hand-built statistics were applied. A well-tuned deployment can do better, and engines built to be tuned (Redshift, BigQuery) are the most affected.
• One unit of compute, with autoscaling off. Several engines add clusters or capacity under load in production. The results show what one unit does.
• Warm engines, three measured runs. Cold starts, data loading and writes were not measured, and small differences between engines should be read as ties.
• List prices. Costs use each vendor's published rates from July to October 2026. Negotiated discounts are outside the study.
• MotherDuck ran untranslated. The queries were written in DuckDB SQL and checked against DuckDB, so MotherDuck alone ran them without translation.
• Translated SQL on every engine. The join queries were translated mechanically from DuckDB's dialect for each engine, with small correctness fixes on five of them. The scan queries use the SQL published in the ClickBench project for each engine, apart from Fabric's, which the study translated.

Apache Hudi and Fluss: how JD.com built a Lakestream

JD.com runs a large Apache Hudi lakehouse alongside a large Apache Kafka deployment. This post describes how JD links streaming data and lakehouse data with a Lakestream: fresh data lives in Fluss tables, and a tiering service continuously writes it into Hudi tables. Readers can then query both together. The Fluss community calls this storage foundation a Lakestream: it unifies fresh data in streams with historical data in open lakehouse tables.

TL;DR

• The problem: separate real-time and batch pipelines for the same data meant duplicated storage and compute and metric definitions that drifted apart. Consumers of one impression log topic had to read 195 GB/min to get the 6 GB/min of selective columns they actually needed.
• The approach: a Lakestream on Fluss and Hudi, so one copy of data serves both real-time and batch workloads.
• The results in recommendation ranking: batch compute cost down more than 80%, storage cost down more than 50%, end-to-end training-data freshness improved by more than 30%, three training-data sources merged into one, and better click-through and conversion rates in A/B tests.
• The Fluss integration: Hudi support for Fluss tiering (being contributed upstream as Fluss Improvement Proposal 24, FIP-24), server-side consumer offset management, and high availability for the Fluss Coordinator.

Challenges at JD's Scale

Our lakehouse and streaming platforms have grown over many years. The lakehouse runs on Apache Hudi, with more than 5,000 tables and more than 700 PB of data migrated into it, and a single job peaks at more than 600 million records per minute. The streaming platform runs on Apache Kafka, with more than 8,000 nodes in production, peak writes of 500 million records per second, and peak egress of 2 TB/s.

At this scale, small inefficiencies get expensive. An extra copy of the data, a few fields read but never used, or one more pipeline to maintain each turns directly into cost, stability risk, and engineering time.

Row-Based Consumption Wastes Bandwidth and Compute

The first problem is that message queues store data by row. Our impression log topic is a good example: reading all of it means consuming about 195 GB/min, but downstream jobs actually need only 6 GB/min. Most jobs use a handful of fields, yet a row-oriented queue makes every consumer pull the full message and then parse, filter, and drop fields in its own compute job.

That wastes resources in three places:

• Network: every consumer pulls the full message to use a few fields.
• Compute: deserializing and parsing unused fields burns CPU and memory.
• Pipeline load: the bigger the topic and the more consumers it has, the more this repeated reading and parsing adds up.

Separate Lakehouse and Stream Pipelines Duplicate Work

The second problem is architectural: the lakehouse and the stream are separate systems. Take training data for search and recommendation models as an example. Teams have traditionally run two pipelines side by side. The real-time pipeline quickly turns user activity into fresh training samples and features. The batch pipeline handles backfills, corrections, model training, and analysis. Running both meets different freshness needs, but it creates three problems:

• Duplicate storage. Much of the same data is stored more than once, in the message queue and in lakehouse tables.
• Duplicate compute. Both pipelines clean the data, join it, assemble features, and generate samples. Only the execution model differs.
• Inconsistent metric definitions. The two pipelines evolve separately, so field definitions, filters, error handling, and backfill logic drift apart.

Why We Adopted Fluss

The goal is to gradually bring real-time streams and the lakehouse onto the same data model, the same service interfaces, and the same way of consuming data. One copy of data serves real-time jobs through Fluss streaming and batch reads, and is also written to Hudi tables for long-term analysis, model training, and historical replay with engines such as Apache Spark. Jobs that need both use union reads, which query the Hudi table and the newest Fluss data as one table.

Case Study: Recommendation Ranking

We chose recommendation ranking as a key production use case. The redesign gradually consolidates several parallel pipelines into one copy of data, consumed in different ways. Real-time features and labels stream into Fluss first, which supports low-latency writes and minute-level online learning. The tiering service then writes the same data into Hudi tables, where Hudi's efficient backfills support batch analysis, base model training, and catch-up training.

Results

• Cost: batch compute cost down more than 80%, storage cost down more than 50%.
• Freshness: end-to-end training-data pipeline freshness improved by more than 30%.
• Engineering effort: three training-data sources (batch, catch-up, and real-time) merged into one, and two APIs (batch and real-time) merged into one.
• Business metrics: core recommendation metrics, including user click-through rate (UCTR) and order conversion rate (UCVR), improved in A/B tests.

What We Built on Fluss

Tiering Fluss Data into Hudi

We built a Hudi plugin for the Fluss tiering service, adapting the three stages of the tiering job: the source enumerator, the source reader, and the committer.

• Runtime: TieringSourceEnumerator splits each round of tiering work and assigns the splits. TieringSourceReader reads data from Fluss and writes it to the lake table. TieringCommitter commits the lake table and reports the snapshot back to Fluss.
• Lake abstraction: a common lake storage interface hides the differences between lake formats.
• Hudi plugin: Hudi plugs in as a LakeStorage implementation.

Server-Side Consumer Offsets

We added consumer offset management to the Fluss server. The offsets live in a primary key system table, consumer_offsets, keyed by group, table_id, partition_id, and bucket_num. An offset record holds the offset, leader epoch, metadata, and commit timestamp.

Coordinator High Availability

It runs on JD's internal Kubernetes platform, with a Controller daemon deployed as a StatefulSet. In each pod, the Controller runs as PID 1 and registers with ZooKeeper on startup. The pod that registers successfully becomes active and starts the Fluss Coordinator process. The other pods are cold standbys that watch the ephemeral znode and take over if it disappears.

What's Next

We are contributing Hudi tiering back to the Fluss community as FIP-24: Tiering Service to Hudi. Our next steps include adding per-user quotas, tuning offset management, and achieving feature parity with JD's Hudi stack regarding schema evolution and dynamic bucketing.

Best Practices for Single Row Lookups (Point Queries)

This blog post covers different techniques to improve the performance of point queries in DataFusion. It is based on a talk (slides, recording) given at the Boston DataFusion meetup, in September 2026.

Introduction

While DataFusion is commonly seen as an engine to run analytical workloads -- which are comprised by queries that access large sets of data -- some of its users regularly require random lookups to large files. During the DataFusion meetup in Boston, I met several community members that shared their experiences with these types of workloads, and how they hit some of the same challenges I highlighted in my talk.

For this blog post, I will cover some best practices on how to handle random lookups (aka point reads) based on my past experience with these workloads in DataFusion. Since we usually have many more queries to execute comparatively to analytical workloads, the challenge here is completing each query as fast as possible (< 1ms) to achieve a reasonable throughput.

The first part goes over optimizations in the storage (in this case, Parquet files), while the second optimizes the execution in DataFusion.

Methodology

The dataset we will be using here is formed by a single Parquet file with 100M rows (unless otherwise stated), using a key (bigint, unique) and value (varchar, md5 of the key) columns, generated with the following code:

select i as k, md5(i::varchar) as v
from generate_series(1, {rows}) t(i)

Unless otherwise stated, the queries tested retrieve a random row from the table by key (i.e., select v from t where k = {}). Most tests run on a c4d-standard-4 (4 vCPUs, 15GB RAM) Google Cloud virtual machine, using a 100GB HyperDisk (6k IOPS, 500 MB/s) to store the data.

Storage (Optimizing Parquet Settings)

File Ordering

Having the Parquet file sorted by key will allow random lookups to access the minimum amount of data, assuming our predicate is also based on the key. To confirm this, the first test measures the throughput of random reads against a sorted (True) and non sorted (False) file.

The overall throughput of the sorted version is 6000x faster than the non-sorted one. In this case, the execution plans show that the non-sorted version needs to access, on average, 67 row groups and 122 total pages, while the sorted version only accesses one page in one group.

In case you are not familiar, Parquet files are divided into multiple row groups, with each column in each group divided into multiple pages. DataFusion uses the min/max statistics for each group/page to determine if it needs to access it or not. If the file is not sorted, the min/max bounds will be wide, forcing more groups/pages to be accessed.

Additional Metadata

By default, DataFusion writes Parquet files with dictionary encoding enabled. Dictionary encoding maps column values to integers in an attempt to compact the space used, working pretty well for columns that have many duplicate values.

However, if a column contains many distinct values (which is the case in our dataset), the dictionary will only add overhead. The following test compares enabling (True, default) and disabling (False) the dictionary, showing that the latter achieves a higher throughput.

Another optional metadata commonly used in Parquet files are bloom filters, which much like min/max statistics help speedup predicates. In the context of Parquet files, a bloom filter is an array of bits that can determine if a value is definitely not or maybe is in a specific row group.

In our case, since the column we filter by only contains unique values and is already sorted, the min/max statistics suffice, and thus there is no need to add bloom filters. By default, DataFusion already does not add bloom filters when writing Parquet files.

In summary, at least for sorted files with many unique values, it is better to disable both of these structures when writing Parquet files. This can be set in the OPTIONS part of the SQL COPY command, or by changing the TableParquetOptions in DataFrame::write_parquet:

COPY (...) to 't.parquet'
OPTIONS (
    DICTIONARY_ENABLED false,
    BLOOM_FILTER_ON_WRITE false
)

File Configuration

Next up, we are going to take a look at what should be the optimal row group and data page sizes for point reads. We can conclude that the optimal configurations for point reads are the values around 128k rows per row group and 1k rows per page, which are quite different from the defaults used in DataFusion (1M sized row groups and 20k sized pages). Tiny groups or pages will lead to a large number of them, which means more time when pruning. On the other hand, large groups or pages means less data is pruned and thus more rows are scanned.

But what if we need our Parquet files for both point reads and analytical workloads? While large reads favor larger pages, and smaller reads favor smaller pages, we can use around 2k-4k rows per page to achieve a good throughput for both workloads, meaning we don't need to sacrifice one over the other.

COPY (...) to 't.parquet'
OPTIONS (
    MAX_ROW_GROUP_SIZE 131072,
    DATA_PAGE_ROW_COUNT_LIMIT 2048
)

Compression

Finally, we will examine how compression affects performance. The main conclusion here is that, for our dataset, we should use lz4 if we favor faster speeds, while zstd shows the best space/speed tradeoff (default used in DataFusion). The snappy algorithm, which is commonly used, uses around the same space as lz4 for this dataset but is slower in larger scans in DataFusion.

Execution (Optimizing DataFusion Settings)

Target Partitions

We are now going to optimize the execution itself, starting with the target_partitions config in DataFusion. Since point reads require so little work, the overhead of distributing load to multiple cores outweighs its benefits. We observe that small reads are faster with a single partition. On the other hand, larger reads are faster as they can use the additional parallelism, so this option is very much workload dependent.

Pushdown Filters

Next up, we are going to take a look at another DataFusion config: pushdown_filters. This config pushes filters directly to the Parquet scan, instead of having an extra FilterExec node. For both smaller (<10k rows) and larger (>100k rows) reads, we conclude that enabling pushdown_filters results in a higher throughput.

Metadata Cache

To find data in a Parquet file, DataFusion first has to retrieve and parse the file's built-in metadata. DataFusion caches Parquet metadata by default since version 50.0.0 to avoid having to do this at every read. It is better to keep this caching enabled if we intend to query the same file more than once.

Prepared Statements

For point reads specifically, the optimization process of building logical and physical plans has quite a significant weight on performance. Reusing the logical plan offers an improvement over not reusing anything, but it's clear that reusing the physical plan leads to a considerably higher throughput, doubling or even tripling performance. Currently, this is not available in DataFusion.

Memory Allocator

Another important contributor to the overall performance in DataFusion is the memory allocator used. The results show that the allocators have widely different throughputs. In our workload, mimalloc appears to be the overall best choice.

Runtime

After experimenting with different configurations, I found that having a separate single-threaded runtime for each client scaled better. We see in the results that the default version does not really improve with multiple clients, as the CPU is not being fully utilized, unlike the multiple single-threaded runtimes version.

Summary

Table 1 shows an overview of the main optimizations tested. In total, we managed to improve the throughput in almost 8x over the baseline and reduce the response time to sub 0.2ms, demonstrating that DataFusion is well capable of handling point read workloads.

At Benchouse, we benchmark different analytics agents with equivalent context. This time, I wanted to go deeper: how far could I push one agent on our evaluation set?

But the path wasn’t straightforward. Better documentation sometimes made the agent abandon the calculation we expected. It spotted flaws in our data and decided to fix them without being asked.

Getting past 95% meant figuring out when the agent needed more information and when it needed less freedom.

Here’s what I changed, what each configuration scored, and what I’d take into a deployment on my own data.

For this study, I used nao, an open-source analytics agent. It suited this study well: nao keeps its context layer as a file system, and it can work with any kind of context or semantic layer. That made it easy to test every context option side by side, from bare schema to documented business definitions. Setup was straightforward: I connected our evaluation framework through its MCP and managed the context as version-controlled files.

With Sonnet 5 and bare schema, it got 49.6% of its answers right. After changing the model and building up the context, we reached 96.5%.

Same questions, more context

To see what each change actually bought us, I kept the test fixed: 90 questions across 59 marts tables.

The questions covered three tiers:

• Descriptive: what happened?
• Diagnostic: what happened, and why?
• Prescriptive: what happened, why, and what should we do?

Five questions deliberately asked for information the warehouse doesn’t contain. These tested whether the agent would correctly refuse to answer.

I tested four configurations, each building on the previous one:

1. Bare schema. Connect the warehouse. Give the agent only table and column names, without even column descriptions.
2. Add nao sync. Give it column information, sample rows and profiling.
3. Add full documentation. Describe the tables, keys, relationships, synonyms and joins to avoid.
4. Add definitions and answering rules. Apply nao’s Recommendations and Benchouse’s improvements: explicit business definitions, rules for how to answer, clearer synonyms and corrected catalogue guidance. Develop these using a separate training set.

Customizing the context meant editing files. Luckily, nao gives you plenty of flexibility to add instructions, documentation and answering rules, so I could change what the agent knew and how it used that knowledge.

Every configuration faced the same 90 questions three times to measure consistency. I scored them with the Benchouse evaluation framework throughout. nao has its own evaluation tools too; I kept ours so the measuring process stayed the same while the context changed.

The model made the first big difference

Going into this, I thought most of the improvement would come from giving the agent better context. But the baseline I ran on Opus 5.5 already reached 88.2% accuracy with just table and column names, not even descriptions.

I wasn’t expecting that. Was Opus really that good with so little context? I ran the same setup on Sonnet 5 to check. It performed a lot worse.

The difference was substantial. I saw that Sonnet was struggling to find its way around the database schema, whereas Opus happily used any tool at its disposal.

This is what Benchouse does: the same evaluation set, run against different analytics agents with equivalent context, scored by the same judge.

Basic context saves money

With nao sync, which takes your database context (tables and columns) and stores it locally for the agent, Opus’s accuracy barely moved. That was to be expected: Opus had already made the extra tool calls to figure out the database structure.

The cost per question did fall. With the context at its fingertips, Opus had less work to do.

nao’s write-context-rules skill took accuracy from 90.6% to 92.9%

My next hypothesis was that fully documenting the model would bring accuracy to 95%.

So I added:

• Descriptions for every table and column
• Table grain: what each row represents
• Primary and foreign keys
• Relationships between tables
• Business synonyms for tables and columns
• Joins to avoid, including incompatible keys and grain mismatches
• Value lists explaining categories, statuses and other coded fields (enums)

Full documentation brought accuracy to 91.4% across three attempts. Then I tried nao’s write-context-rules skill on top of that documentation.

On the matching single-attempt comparison, accuracy went from 90.6% to 92.9%: a gain of 2.3 percentage points. Cost per question also fell slightly, from $0.247 to $0.239.

It still left us short of 95%. Time to dig deeper into the remaining mistakes.

How we finally got to 96% accuracy

For this last configuration, I used a training set of 210 questions on a clean run. I didn’t want to overfit our improvements to the 90 evaluation questions.

This revealed a few general areas for improvement:

• The agent proactively works to fix your data issues
• Business terms leave room for interpretation
• Ambiguous context sends it down competing paths
• A thorough analytics agent sometimes misses the point

1. The agent proactively works to fix your data issues

In the project’s RULES.md, we told the agent to give the business’s figure first, then flag limitations and label any alternative.

Our warehouse has a holiday flag. The documentation explains that the flag misses some holidays. Once the agent knew that, it built its own calendar instead, on every attempt. It had spotted a real limitation. But the incomplete flag was still the business’s agreed definition of a holiday.

We saw the same behaviour with blended ROAS: the agent chose store revenue over ad spend rather than the platform-attributed figure.

A defensible answer can still be the wrong number for your meeting. We had described the fields without settling which interpretation the agent should lead with.

2. Leaving no room for interpretation

We started explicitly documenting where our definitions differed from industry standards. For example:

• Attributed revenue: we default to the platform-reported figure unless another model is requested, with a warning about overlapping claims.
• Fill rate counts purchase-order lines that are due. Lines not yet due are still on order.
• Money-losing campaigns must cover the goods sold as well as ad spend.

We added these definitions to a Definitions section in each relevant table’s annotations.md, alongside its documentation.

For example, our marketing table notes defined a money-losing campaign:

## Definitions

- **Money-losing campaign:** attributed revenue does not cover
  ad spend plus the cost of goods sold.
  Break-even ROAS = 1 / gross-margin rate.

A campaign can earn more than its ad spend and still lose money. That distinction belongs in the context, rather than being left for the agent to infer.

3. Disambiguate, disambiguate, disambiguate…

Terminology needed cleanup too. Some of our context overlapped, understandably confusing the agent. The same synonym pointing to competing columns gives the agent another choice to make. Misleading catalogue guidance sends it down a dead end. Clarity here matters as much as another paragraph of description.

We corrected the synonyms in the table annotations and updated the misleading column description in the catalogue.

4. Agents need to get to the point

Agents love to be helpful. Sometimes they jump ahead and answer the question they think you’ll ask next.

For our benchmark, we instructed the agent to answer our question first. Then it had leeway to take the analysis further.

The instructions were: give the house figure first. Only then offer a clearly labelled alternative. We also asked it to answer the requested period and breakdown, say when data was missing, and put key numbers in the text.

These instructions went into the project-wide RULES.md, so they applied across questions.

Conclusion

The final version of the context reached 96.5% accuracy at 100.0% completeness. That was 5.1 percentage points above full documentation and 8.6 points above bare schema on Opus.

Consistency improved too. The share of questions answered correctly on all three attempts rose from 77.6% to 92.9%. Getting it right again tomorrow is closer to what I have come to expect from an analytics agent.

This final setup cost more per question than sync alone, but less per correct answer than the bare setup. We tested its changes together, so we cannot assign a separate accuracy gain to each definition, recommendation or rule.

Sonnet vs. Opus on the final context

Now for the grand finale: with all this context in place, how does Sonnet perform?

Switching models meant changing one setting. The context stayed the same.

Accuracy

Sonnet 5.5 on the final context reached 92.9% accuracy at $0.164 per correct answer. C3 Opus’s first attempt reached 94.1%. That makes a wider model comparison worth doing.

Cost

Cost fell from $0.27 to $0.14 per question, a 48% reduction, while accuracy dropped by 3.6 percentage points.

Conclusion: There’s no silver bullet

A stronger model gave us the biggest initial improvement. But even Opus needed better context to get past 95%. Once that context was in place, we could try a cheaper model and measure what we gave up.

There wasn’t one change that solved everything. It was death by a thousand paper cuts: an ambiguous synonym, a misleading description, an unstated definition, an agent answering the question it thought you should have asked. Each needed attention.

That’s why I’d start with real questions and read the wrong answers. Figure out what caused each miss, improve the context, and test again. Then revisit the model choice. You might be able to spend less, but check what happens to the answers as well as the bill.

If you’re looking for an analytics agent, nao is well worth trying. It’s easy to set up, and its flexibility makes it a great tool for experimenting with your own data and context.

Full article content is not available for inline reading.

Read the original article →

Gems of DuckDB 2.0.0

TL;DR: We released DuckDB 2.0.0 last week with an improved Quack protocol and VARIANT support, asynchronous I/O, and many other features. In this blog post, we highlight a few smaller features and improvements that did not make it into the release announcement.

Last week we released DuckDB 2.0.0 LTS, our biggest feature release so far. The announcement covered the headline items: the Quack protocol, asynchronous I/O, the first-class VARIANT type, agent mode, the PEG parser, and triggers. DuckDB 2.0.0 is now available in all primary clients – check the installation page for instructions on installing or upgrading.

A release of this size ships many smaller improvements that never make it into the original announcement. In this post, we highlight a few of these gems. To find the documentation for everything that is new in 2.0, see the “What's New in the Docs for 2.0” page.

Python Appender

Inserting rows one at a time is inefficient, and building up a giant INSERT statement is awkward. Therefore, the preferred solution for inserting large amounts of data has been the appender. However, it was only available in some clients (C/C++, Go, Java, etc.) and notably absent from the Python client. DuckDB 2.0.0's Python client ships an appender that collects rows and writes them together in a single operation:

import duckdb

con = duckdb.connect()
con.execute("CREATE TABLE duckdb_releases (version VARCHAR, codename VARCHAR);")

with con.appender("duckdb_releases") as appender:
    appender.append_row("1.4", "Andium")
    appender.append_rows([("1.5", "Variegata"), ("2.0", "Cyanoptera")])

print(con.execute("FROM duckdb_releases").fetchall())

[('1.4', 'Andium'), ('1.5', 'Variegata'), ('2.0', 'Cyanoptera')]

The with block flushes the buffered rows when it exits. For data that already lives in a DataFrame or Arrow table, INSERT INTO ... SELECT is still faster, but the appender is ideal for rows that your Python code produces on the fly.

Usability Improvements in the CLI

Pretty-Printed .schema

As of DuckDB 2.0, the .schema dot command pretty-prints and highlights its output by default, which makes reading the schema of a database much easier. If you prefer the earlier single-line form, for example, to copy a statement verbatim, use --no-indent (or its alias --no-format):

duckdb mydata.duckdb ".schema --no-indent"

.manual Dot Command

DuckDB 2.0 introduces the .manual dot command, which shows the signatures, description, and examples of a SQL function. For example, to get the details of the bar function, run:

.manual bar

  ────────────────────────────────────────────────────────────────────────────────────────────────
  system.main                                   bar                                scalar function

  SIGNATURE

        bar(x DOUBLE, min DOUBLE, max DOUBLE) -> VARCHAR

        bar(x DOUBLE, min DOUBLE, max DOUBLE, width DOUBLE) -> VARCHAR

  DESCRIPTION

        Draws a band whose width is proportional to (`x - min`) and equal to `width` characters
        when `x` = `max`. `width` defaults to 80.

  EXAMPLES

        bar(5, 0, 20, 10)

The same page is available from the command line via duckdb -manual bar, and the name may contain LIKE wildcards, e.g., .manual list_%. In the coming releases, we will extend the manuals to cover more features such as SQL statements and clauses.

Calculator

You can use the CLI as a calculator. Simply type the expression followed by a semicolon – no more typing into your browser's address bar!

6*7;

┌─────────┐
│ (6 * 7) │
│  int32  │
├─────────┤
│      42 │
└─────────┘

Command History

The CLI now exposes its command history in two ways. The .history dot command shows previously executed statements with syntax highlighting, optionally limited to the last N entries:

.history 10

The same information is available as a table through the shell_history() table function, so you can query your own history with SQL:

SELECT sql
FROM shell_history()
WHERE sql ILIKE '%copy%';

Offline Documentation

As a reminder, both the DuckDB documentation and the DuckDB blog are available for offline browsing:

• Documentation as a Markdown file (approx. 5 MB)
• Documentation as a PDF file (approx. 10 MB)
• Blog as a Markdown file (approx. 3 MB)
• Blog as a PDF file (approx. 35 MB)

You can download them to your e-reader (we are not affiliated with any particular brand!) or read them on your laptop on the go. You can also use them to supply context to LLMs and coding agents. At approximately 5 MB, the documentation exceeds the context window of most LLMs, so instead of ingesting it in full, point them to specific sections or let them find the parts they need.

Unsung SQL Features

SHOW for Configuration Settings

The SHOW statement can now print a configuration setting by name, PostgreSQL-style, when the name does not refer to a table:

SET threads = 42;
SHOW threads;

This is much more succinct than the previous formulation that used the current_setting function (e.g., SELECT current_setting('threads') AS threads;).

When a table and a setting share a name, DuckDB prioritizes the table by default. You can control this with the show_behavior setting, which takes 'auto' (the default), 'table', or 'setting'.

Deprecated: Using SHOW to describe a table, view, or query (e.g., SHOW my_table) is deprecated as of DuckDB 2.0 and prints a warning. Use DESCRIBE instead.

CREATE SECURE VIEW Statement

Regular views can leak information about their underlying tables through statistics and query plans, for example via the stats() function. The new SECURE VIEW does not:

CREATE SECURE VIEW users AS
    SELECT username
    FROM all_users
    WHERE access_level = 'standard';

On a secure view, stats() returns only uninformative statistics and EXPLAIN ANALYZE shows a single Secure View node instead of the view's query plan, so neither can be used to reconstruct the rows that the view filters out.

Options in regexp_extract

The regexp_extract function gained an overload that takes regular expression options as the third argument, with no capture group required. For example, you can now match case-insensitively in a single call:

SELECT regexp_extract('ABC', 'abc', 'i'); -- ABC

Setting a Sequence Value

Sequences gained a PostgreSQL-style setval function to reset a sequence to a given value, which is useful after a bulk load:

CREATE SEQUENCE serial START 1;
SELECT setval('serial', 42);
SELECT nextval('serial');

The next value after setval is value + increment by default. Pass false as the optional third argument (is_called) to make the next nextval return value itself.

Session Variables as Default Parameter Values

Prepared statements can now fall back to a session variable of the same name when a named parameter is not supplied at execution time:

SET VARIABLE multiplier = 10;
SET VARIABLE x = 42;
PREPARE compute AS SELECT $multiplier * $x AS result;
EXECUTE compute;

An explicit argument always takes precedence over the variable, and because the fallback is resolved at execution time, changing a variable and re-executing the statement picks up the new value.

Custom Partition Paths

When writing partitioned data, the PARTITION_BY clause writes each partition to a col=value subdirectory following the Hive convention. The new PARTITION_PATH option gives you full control over the subdirectory that each partition is written to, using an expression over the partitioning columns.

CREATE TABLE orders AS
FROM (VALUES
    (1, 2018, 3, 120.00),
    (2, 2018, 11, 75.50),
    (3, 2019, 6, NULL),
    (4, 2019, 6, 310.25),
    (5, 2020, 9, 18.75),
    (6, 2021, 2, 42.00),
    (7, 2021, 2, 99.90),
    (8, 2023, 12, 260.00)
) t(order_id, year, month, amount);

Let's partition this table based on year:

COPY orders TO 'orders'
    (FORMAT parquet,
     PARTITION_BY (year),
     PARTITION_PATH CASE
         WHEN year < 2020 THEN 'archive/' || year
         ELSE 'recent/' || year
     END);

The expression is evaluated once per partition, and its result must be a relative path that does not contain .. segments. Each partition must map to a distinct path. A companion ORDER_BY copy option sorts the rows before they are written. When combined with PARTITION_BY, the rows are sorted within each partition:

COPY orders TO 'orders_sorted'
    (FORMAT parquet,
     PARTITION_BY (year, month),
     ORDER_BY (amount DESC NULLS LAST));

Writing GeoJSON

DuckDB can now write GeoJSON directly with COPY ... (FORMAT GEOJSON), which produces a FeatureCollection, or FORMAT GEOJSONL for newline-delimited features:

COPY (SELECT 'POINT(0 1)'::GEOMETRY AS geom, 10 AS my_field)
    TO 'test.json' (FORMAT GEOJSON);

Extensions

Compatibility Matrix for Community Extensions

In the days following the release, once our CI pipelines got some breathing room, we built and deployed the community extensions for DuckDB 2.0.0.

Not every extension is available for every DuckDB version and platform, so each extension's page now includes a compatibility matrix that shows which DuckDB version and platform combinations the extension was deployed for, covering recent DuckDB releases.

Window Function Extensions

Every aggregate function can be used as a window function, but not every windowed operation is an aggregate. In DuckDB 2.0, window functions became catalog entries, so extensions can now define their own window functions using the same C++ API as the built-in ones.

An extension derives from the WindowFunction class, registers it with the ExtensionLoader, and implements a blocking interface, which builds its data structures and evaluates the function in parallel. Optionally, it can also implement a streaming interface for windows without PARTITION BY and ORDER BY clauses. As a side effect, window functions are now listed in duckdb_functions() and can be looked up with the .manual dot command.

Summary and Looking Ahead

In this blog post, we listed a few of the smaller features in DuckDB 2.0.0. For everything else, see the announcement blog post and the release notes. There are even more things in the release as part our core extensions – we'll release more posts on these in the coming weeks.

The ecosystem around DuckDB keeps growing: many projects are built both with DuckDB and within it.

We are also in the process of updating our roadmap with upcoming features. We already picked the codename for DuckDB 2.1, coming in 2027: we will name it after Barrow's goldeneye (Bucephala islandica), so:

with con.appender("duckdb_releases") as appender:
    appender.append_row("2.1", "Islandica")

As always, we are grateful to the contributors who made this release possible. Thank you!

SLayer

An expressive, embeddable semantic layer for AI agents and humans.

SLayer enables AI-powered data analytics on top of your warehouse. Agents get a governed, shared surface through which they access your data and metrics and give you reliable answers.

SLayer handles database connectivity (read-only), SQL translation, common data transformations, and row-level security, so LLMs and humans don't have to. Adapt it to your workflows, not the other way around. Manage definitions easily with an agent or by yourself.

SLayer can be used as a standalone tool or imported as a Python library, easily embeddable into any Python app. Use it for powering analytical MCP servers or APIs or simply to query databases semantically.

SLayer is at the core of Motley and is maintained with ♡ by the same team.

How SLayer is different

Traditionally, semantic layers were a part of the BI stack, where every metric and its aggregation had to be predefined. Agents need more flexibility because users ask questions that involve metric combinations (like ratios), transforms (like time shifts), or different aggregations of the same metric (like average instead of sum).

SLayer allows to define a column revenue once and query it using expressions like sum(revenue), avg(revenue), sum(revenue) / count(*), time_shift(sum(revenue), -1, 'year') etc.; multi-stage queries are also supported.

SLayer is focused on the common agentic search → inspect → query flow. It has a search tool for efficient discovery and a memory store for linking the relevant business context.

Agents, apps and humans can talk to SLayer via MCP, REST API, CLI, Python, Flight SQL, or Postgres-based SQL API. SLayer supports most popular databases.

SLayer fits next to your existing data stack. It also provides importers for dbt, Cube, and Ossie configs.

See docs for more.

Example

Question (run on the built-in demo Jaffle Shop database): "show monthly revenue by store, with month-over-month % change"

Side by side, here's LLM-generated SQL and the equivalent SLayer query.

Quickstart

We recommend using uv, especially if you don't work in a Python project.

uv tool install 'motley-slayer[all]'

If slayer isn't found on PATH afterwards, run uv tool update-shell and reopen your terminal.

Using demo dataset

# With the Jaffle Shop demo preloaded (zero-config quickstart)
claude mcp add slayer_demo -- slayer mcp --demo

Using your own data

Set up your datasource, substituting the correct database, username, hostname, and db_name.

slayer datasources create 'postgresql://user:${DB_PASSWORD}@hostname/db_name'

The password will be read by SLayer at init time, not saved to disk nor exposed to Claude.

Then add SLayer to Claude Code:

claude mcp add slayer -- slayer mcp --ingest-on-startup

Now SLayer MCP will be visible in Claude Code next time you start it. Make sure to launch Claude Code from a shell where DB_PASSWORD is exported — the MCP subprocess inherits its environment from the launching process.

Usage reporting

The slayer command sends anonymous, aggregated usage statistics (command, tool and query-feature counts, versions) at most once a day — never queries, names, data or credentials; library use sends nothing. Opt out with SLAYER_USAGE_REPORTING=off, DO_NOT_TRACK=1 or slayer usage-reporting disable.

License

MIT

Netflix made failure diagnosis more reliable by using LLMs to identify the exact log spans behind an error and provide on-demand root-cause analysis, instead of asking models to digest entire logs. That design improved coverage to all failures while reducing hallucination risk and latency, and early usage data suggests it sharply cuts manual log exploration during debugging.

Full article content is not available for inline reading.

Read the original article →

17 Domain-Native Engines & 8 Publication Themes

From microservices and security perimeters to medallion pipelines and sprint roadmaps.

Architecture & Systems

Ranked DAG topology with smart obstacle-avoiding edge routing (default).

Top-down decision branches, conditional routing, and pipeline steps.

Parent/child hierarchies with shared horizontal sibling buses.

Cycle-safe state machine transitions, loops, and self-referencing arcs.

Participant columns, lifelines, ordered messages, and activation spans.

Structure & Security Boundaries

Full-width horizontal stacked abstraction bands (OSI, CSS cascade, memory).

Concentric rounded boundaries with stepped insets for defense-in-depth.

Cross-functional team lanes and multi-actor handoff tracks.

Pipelines, Roadmaps & Radial

Horizontal hairline baseline with alternating milestone placement.

Phase-based horizontal bar stacking with phase and span properties.

Multi-tier Bronze → Silver → Gold lakehouse data stages.

Circular closed-loop compounding engine with tangential flow paths.

Radial focal-node layout with deterministic orbit decoration.

Curated Publication Themes

Clean light documentation canvas with high-contrast series palette.

Serif typography, refined ink lines, and muted semantic accents.

Monospace CLI aesthetic with vibrant phosphorescent glow accents.

Organic hand-drawn whiteboard style with SVG displacement turbulence.

Monochromatic blue tones inspired by ballpoint pens, fountain pens, cyanotype & porcelain prints.

Playful hand-drawn doodle sketchbook with felt-tip markers and comic block shadows.

Technical CAD drafting grid with cyan wireframe geometry.

Deep developer canvas with layered glassmorphism elevations.

Never Start From Scratch

Convert existing static architecture definitions into animated MarkdyScript scenes in 1 command or 1 click.

flowchart LR
  Client[Client Browser] --> Gateway[API Gateway]
  Gateway --> Auth[Auth Service]
  Auth --> DB[(PostgreSQL)]
  Auth -.-> Cache[(Redis Session)]

scene theme=paper type=flowchart
layout TB

service Client "Client Browser"
gateway Gateway "API Gateway"
service Auth "Auth Microservice"
cache Cache "Redis Session"
database DB "PostgreSQL"

beat flow:
  show $nodes stagger=60ms
  Client -> Gateway "POST /login"
  Gateway -> Auth "Validate"
  Auth -> DB "Query Credentials"
  Auth -> Cache "Set Session"
  Gateway <- Auth "JWT Token"

player:
  playback:
    loop true
  controls:
    speed true
    speeds "0.25"
    fullscreen true
    gif true
    theme true
  interaction:
    zoom true
    pan true
    click_to_play true
    double_click_to_reset true
    keyboard false
  chrome:
    badge true
    progress none
    color "#3b82f6"

Why Engineers & Teams Choose Markdy

A diagramming layer built for modern software architecture, autonomous coding agents, and CI/CD reviews.

Diagram-Native DSL & Motion

Declare semantic nodes, groups, flows, and timed beats in reviewable text. Layout, collision avoidance, and choreography are 100% automatic.

Universal Ingestion

1-click transpilation from Mermaid flowcharts, Draw.io XML, Docker Compose, Kubernetes YAML, and Terraform state into animated scenes.

AI-Native & MCP Server

Official Model Context Protocol server for Claude, Cursor, and Antigravity with self-healing syntax diagnostics and prompt templates.

Architecture Governance

Automated CI/CD linter catches deadlock cycles, cross-layer bypasses, ungrounded services, and outputs semantic PR diffs.

Full System Support & Integration Matrix

Transparent overview of supported ingestion formats, export targets, analysis features, and framework integrations.

Ingestion & Transpilation Inputs

Export Targets & Developer Frameworks

Official Model Context Protocol (MCP) Server

Point Claude Desktop, Cursor, or Antigravity to Markdy for instant AST validation and self-healing diagrams.

How AI pairs with Markdy

1. Hosted Agent Reference

   Share markdy.com/AGENT.md or llms.txt with your coding assistant.

2. Prompt with Natural Language

   "Draw a cache-aside architecture diagram with Redis and Postgres on user checkout."

3. Autonomous Self-Healing Loop

   The MCP server automatically parses the AST and fixes invalid cues or node typos.

{
  "mcpServers": {
    "markdy": {
      "command": "npx",
      "args": ["-y", "@markdy/mcp-server"]
    }
  }
}

Docs-as-Code in Any Framework

import { createDiagram } from "@markdy/renderer-dom";

const diagram = createDiagram({
  container: document.getElementById("scene"),
  code: `
    scene theme=paper
    client WebApp -> service Api -> database Postgres
  `,
});

diagram.play();

---
import { Markdy } from "@markdy/astro";

const sceneCode = `
  scene theme=paper
  client WebApp -> service Api -> database Postgres
`;
---

<Markdy code={sceneCode} autoplay />

// In your MDX documentation file:
```markdy
scene theme=paper
client Browser -> gateway API -> cache Redis
```

# Install CLI globally
npm install -g @markdy/cli

# Render scene to interactive HTML
markdy render system.markdy --open

# Batch validate all diagrams in CI/CD
markdy check-all ./docs/diagrams

Frequently Asked Questions

What is Markdy?

Markdy is an open-source, diagram-native DSL for animated architecture and system diagrams. You write semantic nodes, groups, flows, and beats in plain text; Markdy compiles browser-native motion graphics with zero coordinate math and zero manual keyframing.

How is Markdy different from Mermaid, PlantUML, or D2?

Mermaid, D2, and PlantUML produce static 2D images. Markdy is designed for system motion: request-response paths, cache invalidations, event streaming, camera framing, and step-by-step lifecycles rendered via the browser-native Web Animations API.

Does Markdy require Canvas or WebGL?

No. Markdy uses DOM elements, CSS transforms, and the Web Animations API. Scenes are crisp at any DPI, lightweight, accessible, and run seamlessly inside Astro, MDX, React, or static docs sites.

Can AI coding agents generate Markdy diagrams?

Yes! Markdy's line-based grammar is designed for LLMs. Our official @markdy/mcp-server connects to Cursor, Claude Desktop, and Antigravity to validate, transpile, and self-heal diagrams in real time.

text-to-cad: Design physical products with AI.

Design physical products with AI. 100% open source and free.

Overview

The text-to-cad plugin gives your agent local workflows for generating 3D models as STEP, GLB, STL or 3MF files. It also does design for manufacturing checks, generates engineering drawings, and connects to popular 3D printing, sheet metal and CNC fabrication services.

It is supported by all popular agents that support plugins or the skills framework, including Claude Code, Codex, Cursor, Gemini and Grok.

How it works

1. Your agent writes each model as a Python script with build123d, built on Open CASCADE.
2. Running the script, python model.py, builds the model with cadgen's engine into an .xbf document (its parts, names, colours, materials and joints) and the STEP, GLB, STL or 3MF files the script declares. The engine keeps each model's work in memory, so an edit rebuilds only what it changed.
3. The CAD viewer shows the model in your agent app or your browser, and follows every rebuild.

Install

Ask your agent (recommended)

Send this message to your agent and it will install text-to-cad for you.

Install text-to-cad from https://github.com/earthtojake/text-to-cad

By default, text-to-cad sends usage stats and crash reports, tagged with a random ID and never including your files, paths or prompts; turn them off with uvx --no-config --managed-python --python 3.13 --from cadgen==0.8.3 cadgen telemetry off, or ask your agent to.

Claude Code

claude plugin marketplace add earthtojake/text-to-cad#latest
claude plugin install text-to-cad@earthtojake

Update, then restart the app:

claude plugin marketplace update earthtojake
claude plugin update text-to-cad@earthtojake

Reinstall: remove it, then install it again:

claude plugin uninstall text-to-cad@earthtojake
claude plugin marketplace remove earthtojake

Codex

Manual install:

codex plugin marketplace add earthtojake/text-to-cad --ref latest
codex plugin add text-to-cad@earthtojake

Update, then restart the app:

codex plugin marketplace upgrade earthtojake

Reinstall: remove it, then install it again:

codex plugin remove text-to-cad@earthtojake
codex plugin marketplace remove earthtojake

Cursor

Cursor also loads the Claude Code plugin: if it is installed, skip this.

git clone --depth 1 --branch latest https://github.com/earthtojake/text-to-cad ~/.cursor/plugins/local/text-to-cad

Update, then restart the app:

git -C ~/.cursor/plugins/local/text-to-cad pull

Reinstall: remove it, then install it again:

rm -rf ~/.cursor/plugins/local/text-to-cad

Grok Build

Grok Build also loads the Claude Code plugin: if it is installed, skip this.

grok plugin install earthtojake/text-to-cad@latest --trust
grok plugin enable text-to-cad

Update, then restart the app:

grok plugin update text-to-cad

Reinstall: remove it, then install it again:

grok plugin uninstall text-to-cad

Gemini

gemini extensions install https://github.com/earthtojake/text-to-cad --ref latest --consent --auto-update

Update, then restart the app:

gemini extensions update text-to-cad

Reinstall: remove it, then install it again:

gemini extensions uninstall text-to-cad

Other Agents

For an agent without plugin support: the skills give you everything you need for core CAD workflows and let you view CAD files in a localhost web app.

npx skills add earthtojake/text-to-cad#latest

Run the install command again to update or reinstall, then restart the app.

Skills

Install the library to give agents focused workflows for CAD, fabrication, robot description files, simulation, and local review.

• CAD: Creates and edits CAD models from plain-language or image requests as Python scripts, built into XBF documents with STEP, STL, 3MF and GLB exports.
• step.parts: Finds off-the-shelf STEP parts like screws, bearings, motors, and connectors.
• Engineering Drawing: Dimensioned engineering drawings from a part, as a PDF: views, hidden lines, dimensions, hole callouts, title block.
• DXF: Creates 2D DXF drawings like profiles, templates, gaskets, and cut layouts from Python sources or CAD geometry.
• URDF: Writes robot structure files with links, joints, limits, inertials, and meshes.
• SRDF: Adds MoveIt planning groups, end effectors, poses, and collision rules to a URDF.
• SDF: Creates simulator models and worlds with frames, physics, sensors, and lights.
• SendCutSend: Checks DXF and STEP files before upload to SendCutSend.
• DfAM Check: Measures mesh printability per process: wall thickness, overhangs, support volume, and build orientation.
• DFM: Reviews a part for sheet metal, CNC machining, or injection molding, with measured evidence and the cited rule behind every finding.
• G-code: Slices models into printer-ready G-code with OrcaSlicer, using your own printer presets.
• Bambu Labs: Sends prints to Bambu Lab printers through Bambu Connect, Bambu Lab's official app, or Bambu Studio.

Contributing

Branch from main and open PRs against main. For the local workflow, testing in agent apps and validation, see CONTRIBUTING.md.

Two years ago I left Coinbase to build on my own. Since then I've built and shipped almost a dozen products. Some completely abandoned, others dead upon arrival and a couple that are steadily growing and generating revenue.

The way I build has changed a lot over that time. What I use now didn't come from a plan. It came from a lot of iteration, and from a few products that taught me what not to do.

There is a lot of talk right now about the "software factory." You write an issue, an agent picks it up and a pull request comes out the other end. Repeat until you have a product.

I like the idea, and it's close to how I work. But almost every version of it I see skips the same step, which is design.

Usually design shows up as a few inspirational screenshots pasted into a ticket to direct the agent on how to design. Or it doesn't show up at all and the agent is left to decide what the thing should look and feel like. And it will decide, pretty confidently.

Code is cheap now. What's still expensive is deciding what to build and how it should feel. I think that's the part the factory is missing.

So here is the workflow I've landed on. It has four stations.

The first is Linear. That's where intent lives, and it gets there one of two ways.

The manual way is me. Sometimes I write the issue myself, and sometimes I work through an idea with an agent until it's clear enough to become a ticket. The automated way doesn't need me at all. Agents file issues on their own, like a support agent turning a bug report into a ticket or a DevOps agent spotting something that's breaking.

Either way every issue has to say two things: why we're doing it and what done looks like. If it can't say that in a few sentences it isn't ready to be built.

The second is Paper. Anything with a design, frontend or experience side to it goes through here before it gets built. The agent works in Paper directly through MCP, so it can put together a first pass on the canvas, look at what already exists and pull from the design system.

But I always review the designs myself. A lot of the time I end up polishing them by hand, nudging spacing, rewriting copy and fixing whatever feels off. Other times I leave comments on the canvas and have the agent address them.

This is where the real decisions get made about layout and how the thing should feel. And because Paper designs are real HTML and CSS under the hood, nothing gets lost when it moves to code.

The third is the coding agent. I mostly use Codex, but Claude Code or any other coding agent works here too. It gets the issue and the design and builds against both. This is the part everyone talks about, and honestly it's the part I think about the least now.

The fourth is me again, reviewing what was built against what I meant. When the build doesn't match the design I don't treat it as a bug right away. Sometimes the agent got it wrong. Sometimes it found something better and the design gets updated.

Then it loops.

Now this all works pretty well. But there is one place where it still breaks down for me.

It's easy to give an agent context in the moment. You hand it the issue, point it at the design and tell it what you want, and it does a good job with that.

What it doesn't have is everything that came before. Why a flow was tried and then pulled. What the analytics said the last time a page changed. The earlier versions of a screen and why each one got thrown out. The design system and the reasons behind it, not just the components.

A designer who has been on a product for a while carries all of that around with them. It's a big part of what makes their judgment worth anything. Every new agent session starts without it.

This is the one gap I still haven't closed. I think we need some kind of persistent memory for product decisions, past designs and what the numbers said, and I don't think anyone has solved that well yet. It's the part I'm still working on, and probably the subject of another post.

Even with that gap, this workflow has changed how I build more than any single tool has. Putting design back into the loop made the biggest difference, and it doesn't take much to set up.

I wanted to share it in case it's useful to anyone working through the same problems. If you have questions or want help setting up something similar, DM me on X. I'm always happy to talk about this stuff.

Artificial Analysis v5 and the benchmarker's dilemma

A sort of review of the benchmarking industry and what's missing.

Hill-climbing is easy, knowing what to hill-climb is hard. Making scores go up is expensive, but we have a much clearer playbook for it than we do for creating meaningful benchmarks at the true frontier of AI today.

Independent evaluation of language models is under-appreciated in how hard of a task it is. These groups are not just taking current models and certifying their scores, which is a technically involved task. This is their job if AI progress is slow. When AI progress is as fast as it is, the technical details of the job are the routine work part of trying to put a single number on what makes for a good AI model today. The goal is to have a single number that is representative of current models, matching vibe checks, community sentiment, and scientific analysis, while being forward looking enough so that it’s not outdated in 3 months.

Everyone building a benchmark faces a sort of paradox. You need your benchmark to reduce to one single number, so that it is easy to discuss, use in reports, and compare models, but every method of aggregating scores comes with meaningful trade-offs. The best scientists need to do this, everyone does. It’s a matter of creating aggregation metrics that you think are most fair, knowing there will always be imperfections.

With the amount of money in the AI ecosystem today, the weight of independent evaluation is even higher – you dictate the winners and losers of a trillion dollar market. You also influence some of the models themselves, steering the shape of progress. This is a lot of pressure!

My prompt for this article is Artificial Analysis’s recent update to their Intelligence Index, v5. The AA index is the most prominent independent intelligence metric for the latest frontier models, followed in a distant second by Epoch AI’s Capabilities Index (ECI). To date, all of these have been incredibly useful for the community and massively flawed!

Language models are capable of so much today, and this scope of capabilities is growing quickly. Our era of singular intelligence indices should be phased out soon, but it will take a long time.

A summary of AAv5 is below, from their blog post, where they describe it as “reflecting real-world usage today:”

Intelligence Index v5 weights:

➤ Knowledge Work (25%): AA-Briefcase (15%), AutomationBench-AA (5%), and GDP.pdf (5%)

➤ Coding (25%): FrontierCode 2.0 (15%) and Terminal-Bench 4.0 (10%)

➤ Science (25%): Terminal-Bench-Science (15%) and CritPt v2 hard subset (10%)

➤ General (25%): AA-Omniscience v1.1 15% (10% accuracy, 5% non-hallucination) and HLE-Diamond (10%)

The problem with trying to benchmark real-world usage today is that it is extremely jagged, just like the models. The most proven use-case is coding, where open models are far more competitive and likely to keep up. In knowledge work, I’m less confident in open models.

At first glance, in aggregate, their model ranking definitely looks reasonable. Still, it shows signs of strain and confusion, as any benchmark will, with GPT 6.1 Terra beating Claude Fable 5.1 on AAv5. Today, some benchmarks measure the absolute frontier of capabilities, playing nicely in open-ended tasks through your favorite harness, which often does take a large model. Some other benchmarks measure certain skills that will be needed of a model in repetitive agentic tasks. I get the feeling that AA is tuning their benchmark more towards the former, a general agentic collaborator, but all of these behaviors overlap.

This takes us to the plot going around that prompted me to write this, where they showed the balance of open vs. closed models on the new benchmark. This plot shows 8 closed models beating the best to-be open-weight model, Kimi K3.1 Pro (which isn’t colored blue). This benchmark is taking the opinion of trying to measure where frontier models are moving into, which grows the gap to open models. This is an okay decision to take, but over time as existing workflows of open models become key factors of the economy, it could become a benchmark that misses where the core economic engine of the industry is.

Open models’ demise from this seems greatly exaggerated, but I do think the previous index was flattering the open weight models too strongly. Consider this plot from the Kimi K3.1 Pro launch — yes, the open models are strong and useful in some cases, but the best OpenAI and Anthropic models have been a major step ahead in their flexibility and reliability.

Some of the evaluations in AAv5 that open models are most behind on are “science” evals like terminal-bench-science and CritPT v2. Open models are behind, but the value proposition was never to compete truly at the frontier. The open model economy will be about:

• Reducing domains with high market demand for inference to a commodity price of hardware.
• Allowing ownership of intelligence, specializing it to internal data, and controlling internal agents across many companies in the economy.

Both of these will take a very long time to materialize and are partially represented in benchmarks. The supply of compute is currently so low that open model providers also are raking in solid margins – when this shrinks, we will know the system is starting to work. The same goes for diffusion into enterprises, it’s not clear what the exact ceiling on it is because of the difficult ML expertise that is needed to build evaluations and do post-training today.

At the next major model cycle, say in 2-3 months with GLM 6 or Kimi 3.5, I expect the leading open model labs to make substantial steps on this index, again surprising many observers. This is a cycle we have been on for years now.

I’ve written many times about how open models keep up with the frontier, and a summary is that:

1. The best open models do benchmax a little. The worst open models benchmax a lot (but don’t get a ton of attention anyways).
2. The best open models are a bit narrower in which capabilities they cover, as seen above with their gap on scientific domains. The open model labs are working to address this, but I think it could be come a strategic error to not focus.

There’s a more nuanced version of explanations of the performance gap today, where so many of the gains in training are coming from having RL environments with distributions close to the evaluations. Keeping up with rapid progress across multiple domains requires a sophisticated RL stack that not all the open model labs may possess. Some may be reliant on buying data that has moderate lead times as well.

Another part of this announcement is shifting to “private benchmarks”, where the prompts and test environments are not public, as a sign that open labs are benchmaxxing. This sort of analysis has been done before, and fits with my above theory on how open labs benchmax. It is easier to create training data to support an evaluation when you know the shape of it, but the task isn’t impossible with hidden data. All in, this is a change that directionally I think is defensible, but it’s not unanimous. For example, you’re putting complete trust in the private benchmark builder, as you no longer get the benefit of the community finding issues in the benchmark and pushing the benchmark to improve itself – which happens a lot! There is enough money on the line, where I’d rather see transparency in benchmarking and enabling many eyes to find bugs.

The final point I need to make, which does flatter the closed labs, is that the likes of Anthropic and OpenAI moved on from caring about these indices months, or even years, ago. Their focus is to a large majority on supporting internal uses – like AI R&D automation – and the use-cases of customers who are spending billions of dollars. Yes, they have team members hill climbing on other capabilities to unlock new markets, but these behaviors are to a minority extent driven by public benchmarks. At the same time, it is existential for small to medium sized labs to appear solid on these intelligence indices, as their branding is fully built around catching up to the frontier. It’s a very silly cat and mouse game at times, but one that will be lasting.

The only solution to our current equilibrium with one or two indices dominating the discourse on “where the frontier is” is to have more intelligence indices with other biases, e.g. just for coding. In some ways this is forming, but the mindshare is very lopsided towards Artificial Analysis.

Every benchmark creator has their worldview. The dilemma is that you can always shift the numbers to match your narrative. This has always been a challenge of doing good science. The most recurring version of this question has been “how much effort should you put in to tune your training baseline?” More tuning makes your results more trustworthy, but often reduces the apparent success of your method. This is doubly true in the era of agents, where much of the analysis work is done through the lens of LLMs. In evaluation, this comes down to which benchmarks you choose to include in your index. It is easy to include a lower quality benchmark that supports your narrative, rather than a more rigorous one that conflicts.

The benchmarking industry comes down to trust. I have a solid amount of trust for Artificial Analysis, but not the most I do for anyone in the ecosystem. Artificial Analysis’s business model is to make money from the labs to verify their results. They make a lot of money doing this, which is fine. Other benchmarking companies have a similar problem, such as Arena, which does pre-release testing for labs to pay the bills.

The entities I trust the most to be fair on evaluations are non-profits, academics, and government institutions like CAISI. Today, the institutions I trust to be accurate on the frontier evaluation are startups like Artificial Analysis and Arena. So, we are all stuck with trade-offs and dilemmas. No number is perfect and there is a large amount of wiggle room in the numbers for people to take analysis in different directions. This is a second dilemma, one that is sort of my job, the dilemma of a benchmarker of benchmarkers. It is more sociological than scientific.

The Microsoft Copilot harness powers Copilot Code, Copilot Studio, the GitHub Copilot app, the CLI, VS Code, and more. It is now available through Microsoft Foundry. The harness gives developers and enterprise customers a fully managed way to build agents that reason, use tools, and complete complex, long-running tasks. It was built to perform across model families, and is flexible and configurable to any type of app, agent, or service.

Full article content is not available for inline reading.

Read the original article →

OpenAI now lets you text your Dot agent

The feature works with both iMessage and RCS messaging.

When OpenAI debuted its Dot agents late last month, it promised users would eventually be able to text them to give them instructions. Now, nearly a month later, the company has begun rolling out a preview among US Pro users that allows you to do just that. With the new feature, OpenAI says you can send your Dot texts, photos and even voice memos. It also gives your Dot another avenue to proactively contact you with updates about tasks you've assigned to it.

By popular request, you can now text your dot.

Give it a task to take off your plate or something to keep an eye on, using text, photos, or even voice notes. It will text you proactively with relevant updates.

Safe, secure texting via iMessage or RCS. You're the only one who...

To set up your Dot for texting, open its profile in ChatGPT and select Texting. Over on your phone, ensure iMessage is enabled if you're on an iPhone, and RCS if your daily driver is an Android device. OpenAI says it partnered with Linq to provide messaging support, and did "extensive" penetration testing to ensure the feature is safe. "You're the only one who can text your dot, and your dot can only text you," the company adds on X. Any information your Dot writes to its memory is shared across ChatGPT and text, meaning context carries over between different conversations.

The personal agent space is suddenly very hot after Anthropic joined last week with Claude Duet. In my testing, OpenAI's Dots are comparatively more polished. The fact that you can now text them is something I'm sure some people will appreciate. Using Claude Duet currently requires joining a waitlist that's only open to people in the US. Anthropic has said it plans to offer the agent to subscribers of its $20 per month Pro plan, which is not something you can say of Dots. They're currently not available to Plus tier users.

The private space tourism era looked so very promising five years ago. Blue Origin and Virgin Galactic had begun flying customers—real people with zero space experience—on suborbital missions. And at about the same time, private citizens were going to orbit for days at a time aboard SpaceX’s Crew Dragon.

But that was then. Consider the state of play today:

• It has been 10 months since Blue Origin’s New Shepard spacecraft flew its last mission in January. The program was subsequently “paused,” but let’s be real. Blue Origin has moved on. New Shepard’s engineering teams are now supporting the New Glenn rocket and Blue Moon lander programs.
• SpaceX flew its final free-flyer mission on Dragon, Fram2, in April 2025. A handful of non-NASA missions bound for space stations remain on the spacecraft’s manifest, but all are likely to carry at least one government astronaut. Then Dragon will be retired. There is no credible timeline for SpaceX’s Starship to fly humans into space from Earth.
• As for Virgin Galactic, the company flew its final suborbital mission on the VSS Unity spacecraft more than two years ago, in June 2024.

So we are now 10 months, and counting, without a space tourism mission in the United States.

Hello Apeiron, you shiny object

At the time of Unity‘s final flight, Virgin Galactic said it was moving on to the second generation of its suborbital spacecraft. It planned to bring two of these Delta-class ships into service by the year 2026. Of course, it is now 2026, and there are no Delta-class ships in service.

But apparently we are getting closer to that goal. On Wednesday, the first Delta-class ship received a name: Apeiron. According to Virgin Galactic’s news release, the name is drawn from the ancient Greek concept of the boundless, which is an interesting choice for a vehicle that will forever be bound by Earth’s gravity. It was chosen through a public vote.

“We’re proud that the lead ship in Virgin Galactic’s Spaceship fleet will carry a name chosen by the people who share our excitement for what comes next,” said Michael Colglazier, chief executive officer of Virgin Galactic.

But more significantly, the company said Apeiron would be moved from its Spaceship Factory in Mesa, Arizona, to Spaceport America in New Mexico later on Wednesday.

Apeiron won’t be making a free flight anytime soon. After being carried to New Mexico by the VMS Eve, aircraft engineers and technicians there will complete work on the vehicle’s avionics equipment and flight software. Following additional ground tests, Apeiron will be mated again to Eve for captive carry tests, followed by a drop test and ultimately a powered test flight above 80 km.

Is this the future of space tourism?

Presently, the company is saying it now expects Apeiron’s first commercial spaceflight to take place “early” in the second quarter of 2027. As with every other projected date in aerospace, this should be taken with a grain of salt. But it seems plausible that Apeiron may begin flying paying customers on suborbital space tourism missions over the next 12 to 18 months.

There is considerable skepticism about the commercial viability of Virgin Galactic’s space tourism ambitions. Success will require its vehicles to fly nearly flawlessly and with unprecedented durability to bring hundreds of people to space each year briefly. As this reality has dawned on investors, the markets have not been kind to the company in recent years. In 2021, at the height of space tourism euphoria, the company’s stock briefly reached a stratospheric valuation of $1,118 a share. More recently it has been trading in the vicinity $2.50 a share.

Whatever you might think of Virgin Galactic, however, it seems clear that any hopes of expanding the aperture of space tourism in the next decade will be flying beneath its wings.

Full article content is not available for inline reading.

Read the original article →

Google's advertising business failed to deliver on analysts' estimates in the third quarter. The company is still figuring out how to translate AI into faster sales in its core web-search business. While Alphabet reported 25% revenue for the quarter, revenue from search advertising decelerated. Its cloud business exceeded analyst expectations, drawing in $30.7 billion out of Alphabet's total of $127.6 billion in sales.

Now publicly available as part of global law.

A programmer can point at any line of code and see who wrote it, when, and what the file looked like on any past day. A lawyer reading a federal statute usually cannot, at least not without an afternoon in the notes at the foot of the section. But why shouldn't they have the same, convenient system of record? It is especially relevant given that so much first-pass legal research now runs through language models, which are often unable to utilise the proper lineage of a law, handcuffing its ability to offer interpretation.

The US code

Outside the titles Congress has enacted as positive law, the code is only prima facie evidence of the law, and the Statutes at Large govern where the two differ. The Office of the Law Revision Counsel publishes it as a series of release points, each current through a named public law, and keeps reorganising it; a bill to enact title 41 as positive law was introduced in September 2025. Which public law wrote a sentence is recorded in amendment notes, in prose. When a change took effect is often in a separate effective-date note, and where Congress said nothing the default rule is that a law takes effect on the day it is enacted.

The definition of a small business debtor in 11 USC § 1182(1) shows how far apart those answers can be. It was created in 2019 with the existing small business debt limit. The CARES Act raised the limit to $7.5 million in March 2020 as a temporary measure, later extended to March 2022. That increase lapsed on 27 March 2022, and on 21 June 2022 Congress restored it for two more years, for cases commenced on or after 27 March 2020 and still pending, which reached back over the gap. The higher limit expired again in June 2024, and after the triennial adjustment in April 2025 it stands at $3,424,000. For a case filed in May 2022, the release point printed at the time gives the lower limit, and only a later Act changes the answer. A history that is useful to a lawyer has to carry the text, the date each change took force, and the scope of any law that reaches back.

A study from the Technical University of Munich this year found two failures in models answering questions on German statutes: they apply rules that were superseded after their training cutoff, and they prefer the newer provision even when an older one governs the facts. One model answered 24% of post-cutoff questions correctly on its own and 87% when the relevant statutory text was retrieved for it, and the authors conclude that temporal validity has to be treated as a hard constraint. Other recent work trains search agents to respect the date a question is about, with large gains in consistency.

Asking a model to produce the old text does not solve this. When the same Munich group had a model apply German amending laws to earlier versions, the output looked 93–99% similar to the official text, but only half of single amendments and a fifth of chains of amendments matched exactly, and experts found legally significant errors in the near misses. The history has to be checkable.

For each pair of release points from 2017 onward, we took the public laws enacted in between, carried out their amending instructions on the older text in date order, and compared the result with the newer version. Of 365 changes across the nine titles, 361 reproduced the next release point exactly. The other four are shown with a label saying how far they could be confirmed. Each change then carries the law and the date it took effect: 261 took effect on enactment by default, 72 by an effective-date note and 29 by a date in the amendment itself. One depends on an agency determination that may never come, and we leave it out of the text rather than guess.

With that record, the reader can answer the questions lawyers ask. You pick a date and get the text in force on it, with the words that read differently today marked. Each phrase is coloured by the Act that wrote it. A change to a defined term lists every other provision that uses it, and you can follow a section to see what has changed since your last visit.

Limits

It does not yet show a later law’s reach back on the earlier dates it covers, so for a case filed in the 2022 gap it shows the lower limit without warning that the June 2022 Act changed the answer.

Effective-date notes are read by pattern, and unusual wording falls back to the date of enactment.

Each change links to the law’s own words, and for anything that matters the original should be read.

We're also still thinking about the right form factor this should take.

References

1. 1 USC § 204(a)
2. Office of the Law Revision Counsel, ‘Positive Law Codification: Title 41’ (H.R. 5185, 119th Congress, introduced 8 September 2025)
3. Gozlon-Peretz v United States 498 US 395, 404 (1991)
4. Small Business Reorganization Act of 2019, Pub L 116-54
5. Coronavirus Aid, Relief, and Economic Security Act, Pub L 116-136, s 1113
6. COVID-19 Bankruptcy Relief Extension Act of 2021, Pub L 117-5
7. Bankruptcy Threshold Adjustment and Technical Corrections Act, Pub L 117-151, s 2(h)–(i)
8. Judicial Conference of the United States, ‘Adjustment of Certain Dollar Amounts Applicable to Bankruptcy Cases’ 90 Fed Reg 8941 (4 February 2025)
9. US Trustee Program, ‘Subchapter V’ (US Department of Justice)
10. Max Prior, Andreas Schultz and Matthias Grabmair, ‘Asking For An Old Friend: Diagnosing and Mitigating Temporal Failure Modes in LLM-based Statutory Question Answering’ (arXiv:2605.23497, 22 May 2026)
11. Wei Fan and others, ‘Can LLMs Time Travel? Enhancing Temporal Consistency in Legal Agentic Search through Reinforcement Learning’ (arXiv:2605.25920, revised 19 September 2026)
12. Max Prior, Adrian Hof, Niklas Wais and Matthias Grabmair, ‘Risks and Limits of Automatic Consolidation of Statutes’ in Proceedings of the Natural Legal Language Processing Workshop 2025 (ACL, November 2025) 396

Demand from AI hyperscalers has quintupled prices for flash memory, something Apple previously paid pennies for.

AI code generation is helping database engines game ClickBench. One, pgrust, groups strings by hash value alone, caches predicates the benchmark repeats, and on one query skips most of the data. Any benchmark stops being useful once systems optimise for it, and vibe-coded engines have no customers to keep them honest.

Full article content is not available for inline reading.

Read the original article →

An open-source BigQuery FinOps agent cuts waste from user-written SQL by detecting common cost mistakes, rewriting queries, and validating savings before execution.

ADHD affects about 5% of people and stems from differences in how the brain develops focus, planning, and self-regulation. It is not a matter of willpower. Helpful patterns include reminders for unfinished drafts, chunked long forms, gradual disclosure of options, and visible progress, while autoplay and infinite scroll are best avoided. ADHD often overlaps with autism, dyslexia, and anxiety, so designing for it tends to help several groups at once.

AI can remove much of the difficulty involved in learning and making things, but some of that struggle builds judgment, understanding, relationships, and the ability to create things with other people that none could have made alone.

Meta launched Waddle World, a virtual AI pet app that functions like a Tamagotchi, in the Philippines on iOS and Android. Unlike traditional productivity tools or chatbots, it serves as a digital pet and personal journal, allowing users to interact and play mini-games without pressure. The app reflects Meta's cautious approach following legal issues faced by other AI companion apps.

It can be difficult to tell whether you are overusing AI unless someone directly engages with the details of your work.

Reddit's redesigned feed is designed to nudge users to engage with content beyond the communities they already follow.

Google Photos on Android is getting a customizable Collections tab that lets users pin frequently opened collections, hide sections they rarely use, and rearrange the layout. Favorites, Screenshots, and Trash are pinned by default, while albums, people and pets, places, and other categories get carousels that can be hidden or reordered. The update arrives with Google Photos version 7.97 through a server-side switch, with no broader release date announced.

Ideas such as clarity, simplicity, restraint, and functionality are often treated as universal measures of good design even though they emerged from particular Western histories and cultural contexts. Design traditions excluded from the dominant canon can use decoration, complexity, symbolism, and craft in ways that are deeply functional within their cultures, challenging assumptions that minimalism is inherently more sophisticated or understandable. Evaluating design more broadly requires asking who established prevailing standards of taste, whose histories were documented and taught, and whether a design successfully serves its specific cultural purpose rather than conforming to a supposedly universal aesthetic.

Ladybug is an effects studio for pictures, video, type, and sound.

Mother Design began Purple Garden's rebrand with a séance, chakra reading, and automatic drawing workshop, using the resulting forms and feelings to build an identity around spirituality as “A Living Practice.” A whimsical wordmark, crystal-like guidance glyph, warm purple palette, tactile imagery, living typography inspired by cymatic patterns, and expressive motion create an immersive system without relying on familiar psychic-industry clichés. The process moved between physical experimentation, traditional design software, and AI tools, deliberately introducing unpredictability into both the creative process and the finished identity.

The New York Times is marking its 175th anniversary with a visual identity, campaign, and program of events that use the publication's history as material rather than simply commemorating its age. Familiar elements from its editorial and typographic heritage are reframed across contemporary applications, connecting decades of journalism with the publication's current cultural role. The system demonstrates how an established institution can celebrate recognizable brand equity while giving historical assets new relevance instead of replacing them.

Denver's Bound Agency has a handmade, scrapbook-style site by Wunder Werkz that evokes 2000s Tumblr, with a handwritten logo, doodled icons, and tarot cards.

Stefan Sagmeister's solo show "Finally, Something Good" at La Gaîté Lyrique turns UN and World Bank data into artworks arguing that health, democracy, and equality have improved.