In short : NVIDIA's Q2 FY27 revenue reached $96b with a $108b Q3 guide, but hyperscale revenue grew only 13% sequentially against 25% for everyone else. To fund the buyers filling that gap, NVIDIA extended payment terms — DSO rose from 45 to 60 days & receivables hit $63b — & built a $581b stack of supply commitments, power guarantees, leases & $101b of equity in the AI startups & neoclouds buying its chips.

NVIDIA booked $96b of revenue last quarter, up 106% from a year ago & 18% from the quarter before. The company guided Q3 to $108b ±2%.

That guide crosses $100b of revenue in a single quarter. No semiconductor company has ever reached that threshold, & no company of any kind has reached it while growing triple digits.

Q2 alone runs at $385b a year. At $108b, NVIDIA annualizes to $432b of revenue, making it the sixth largest company in the world, leapfrogging Apple, McKesson & Alphabet.

The only companies still ahead of it are Amazon, Walmart, State Grid, UnitedHealth & Saudi Aramco, all of which compound between -3% & 14% a year. NVIDIA is growing 106%.

On gross profit, the math is even more extreme. Because NVIDIA operates at 75.0% gross margins, that $108b quarterly run-rate generates $324b of annual gross profit, ranking it second in the world.

But the revenue contribution is shifting.

Colette Kress gave the split :

“Hyperscale revenue more than doubled from a year ago and increased 13% sequentially… ACIE revenue increased 138% from a year ago and 25% sequentially driven by end-demand from AI natives, enterprises, and sovereign customers.”

For the first time, neoclouds contributed the majority of net-new Data Center revenue. This shift suggests NVIDIA’s business is healthier & more diversified than before, but it raises the question of whether hyperscaler custom silicon, Google TPUs, Amazon Trainium & Meta MTIA, will eventually slow Big Tech’s demand.

Jensen Huang described the replacement demand :

“This time last year, one lab alone was driving the buildout; today, we have a golden age of new AI labs and startups, multiple frontier labs scaling in parallel, a thriving open-model ecosystem and physical AI coming online.”

It also changes the credit risk. Non-hyperscalers have significantly weaker balance sheets & smaller cash flows than Big Tech, meaning NVIDIA will likely provide more supplier financing to sustain their growth. We are already seeing that show up in the receivables.

Days sales outstanding jumped from 45 to 60 in one quarter. For eight quarters before this, DSO sat in a band between 43 & 46 days. Revenue grew 18% sequentially. Receivables grew 64%.

Kress attributed it to “extended payment terms on large, multi-quarter agreements with certain investment-grade customers.”

Watch DSO next quarter. If 60 days was a one-time reset, it holds or falls. If it climbs, it signals that NVIDIA is extending more credit to sustain demand from buyers who cannot self-fund their growth.

Full article content is not available for inline reading.

Read the original article →

Intelligent transcription with Gemini 3.5 Transcribe

Our latest speech-to-text model designed for precise and intelligent real-time transcription.

Today, we’re introducing Gemini 3.5 Transcribe, our most precise speech-to-text model yet, designed for intelligent voice interactions. Unlike conventional speech recognition models that struggle with background noise, complex jargon, and disfluency cleanup, Gemini 3.5 Transcribe converts raw audio directly into accurate, polished, formatted text.

Across our products like the Gemini app and on Android, we’ve seen consumers already benefiting from this transcription model with new voice capabilities like Rambler on Android and in the Gemini app on macOS. Now, developers can build similar capabilities with Gemini 3.5 Transcribe in the Gemini API in Google AI Studio and Gemini Enterprise Agent Platform.

We've built 3.5 Transcribe to plug seamlessly into your developer workflows, whether you’re building voice agents, real-time captioning tools, or post-call analytics pipelines. The model is available across two separate APIs:

• Real-time streaming: Delivers continuous, bidirectional streaming with sub-second latency for interactive voice apps via the Live API using gemini-3.5-transcribe-live.
• Pre-recorded audio processing: Transcribes recorded audio, meetings, call logs, and more with speaker attribution and word-level timestamps via the Interactions API using gemini-3.5-transcribe.

Get more precise and intelligent transcription

Gemini 3.5 Transcribe is designed to capture your natural speaking style to better understand your intent and recognize custom vocabulary, so you can execute tasks with your voice.

• Smart transcription: Seamlessly handles self-corrections (like "let’s meet Tuesday—no, Wednesday"), removes filler words (“ums” and ‘“ahs"), auto-formats your text.
• Function calling: The model can delegate complex tasks (such as image generation and file analysis) to other Gemini models via function calls. Currently available in the Gemini macOS app.
• More precise transcription: As measured by Artificial Analysis, achieves an average Word Error Rate (WER) of 4.0% for streaming and 2.6% for non-streaming use-cases. It shows strong performance across noisy, real-world environments, accurately capturing alphanumeric entities like postal codes and order IDs.
• Custom vocabulary: Recognizes specialized jargon and unique spellings by seamlessly adapting transcriptions to your provided custom vocabulary.
• Global language support: Automatically detects and transcribes over 85 languages, seamlessly handling regional accents and diverse dialects.
• Multi-speaker identification: Accurately attributes speech in pre-recorded audio with timestamps for up to three speakers (support for 3+ speakers is experimental).

Gemini 3.5 Transcribe’s performance represents a major advancement from our previous transcription model, Chirp 3, offering new capabilities, improved word error rates, and significantly better latency. As measured by Artificial Analysis, time to final transcription, for example, improves by 70%. On the FLEURS benchmark across a set of top languages and locales, the model delivers precise multilingual performance, improving over Chirp 3, and achieving a 5.50% WER in streaming mode and 5.04% WER in non-streaming use-cases.

Experience smart transcription and advanced dictation

In addition to the Gemini API in the Google AI Studio and Gemini Enterprise Agent Platform, 3.5 Transcribe goes further than standard speech-to-text to make working across Google feel more natural and intuitive. By bringing context-aware understanding directly into everyday surfaces like Gboard, Antigravity, the Gemini app, and Chrome, it captures nuances, intent, and inline edits with ease.

• On Gboard on Android, through the new Rambler feature, 3.5 Transcribe transforms spoken thoughts into well-formatted text, filtering out filler words. You can also use your voice to make edits, correct misspellings, and change the writing style.
• On Google Antigravity, 3.5 Transcribe pairs screen context and chat history, with your permission, to ensure pinpoint transcription accuracy across file names, agent thoughts, and active documents.
• In Google AI Studio, you can access 3.5 Transcribe in Build mode to vibe code apps with your voice on the fly.
• In the Gemini app on macOS, 3.5 Transcribe not only transcribes your free natural speech into clean formatted text, but also enables voice commands that can pair seamlessly with screen context to power complex workflows. By calling on other Gemini models in the background to handle the heavy lifting, the model makes it effortless to summarize local files, repurpose text across apps, or generate images right at your cursor—using just your voice.
• Coming soon to Chrome, you’ll be able to talk to type in any web field — making it effortless to dictate replies, draft posts, or prompt Gemini in Chrome more naturally and easily with your voice.

Read the early reviews

By leveraging the Gemini Live API, developer platforms such as Agora, Fishjam, LangChain, LiveKit, Pipecat, Vercel, and Vision Agents enable developers to build and deploy high-performance voice-driven interfaces with ease. These platforms manage complex real-time media streaming infrastructure behind the scenes, allowing developers to focus entirely on crafting the user experience.

Companies like vivo, Intellitek Health, and Lingopal have also shared positive feedback on 3.5 Transcribe, highlighting its impressive latency, accuracy, and expansive language support.

Start using 3.5 Transcribe today

• For developers: In public preview in the Gemini API via Google AI Studio and Google Antigravity.
• For enterprises: In public preview via Gemini Enterprise Agent Platform and coming soon to Gemini Enterprise for Customer Experience.
• For everyone: In Gemini app on macOS in English, Rambler on Android in select countries and languages, and coming soon to Chrome.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

PagedAttention

Here's a thing I think about a lot: very occasionally, an idea from one subfield of computer science walks across the room, taps another subfield on the shoulder, and changes everything. PagedAttention is one of those moments. The idea is just virtual memory, the thing operating systems have been doing since the 1960s, transplanted onto the KV cache of a language model. That's it. That single observation is why a modern inference engine can serve two to four times more users per GPU than the naive approach.

This post is about that crossover. I want to build the intuition for why the KV cache wastes so much memory by default, why virtual memory is exactly the right analogy, and how PagedAttention implements the idea in a way that attention kernels can still work with.

A quick refresher: the KV cache is the per-request store of attention keys and values. It lets the model avoid recomputing them at every decoding step. It grows linearly with sequence length and at long contexts it eats more GPU memory than the model weights themselves. So it's the scarce resource. Every serving-system innovation in this arc is, in one way or another, about managing this one resource better.

Fragmented memory, wasted GPU

When you serve an LLM, you don't know in advance how long each request will be. User A might generate 25 tokens. User B might keep going for 2,000. Your service promises to support, say, 2,048 tokens per request, and you have no idea which user will use all of it. So a naive serving system does the obvious thing: reserve max_context slots of KV cache for each active request. If the model is 70B and the context is 32k tokens, that's gigabytes of GPU memory per request, reserved up front, most of it unused.

Two things go wrong here, and they compound.

The first is internal fragmentation. A request that only generates 47 tokens still holds onto 2,048 slots of cache. 2,001 slots sit empty the entire time. Multiply by 30 concurrent requests and you've reserved 60k token slots for what, in aggregate, is maybe 1–2k filled. That's unused memory you can't hand to another request, because it's already spoken for.

The second is external fragmentation. Requests show up and leave at different times. When request A finishes, its contiguous 2,048-slot chunk becomes available. But if you have a new request that also wants 2,048 slots, and the only free regions are a 1,500-slot hole from A and an 800-slot hole from someone else, you can't use them together. The free memory is the right size in total but the wrong shape. Either you defragment (copy stuff around, which is expensive and disruptive) or you sit on unusable memory.

Kwon et al.'s original vLLM paper puts real numbers on the waste. On production workloads they measured KV-cache utilization around 20–40%, which means 60–80% of the most expensive memory on the most expensive GPU in the cluster was sitting there doing nothing. That's the problem PagedAttention set out to fix.

This is just virtual memory

The moment the vLLM paper clicked for me was when I realized the problem it's solving is exactly the same problem operating systems solved decades ago.

In the early days of multiprogramming, every process asked for a contiguous chunk of RAM. The OS had to decide where to put it. Processes of different sizes came and went. Over time the free memory turned into a jigsaw of unusable fragments. Programs couldn't fit even when there was plenty of free RAM in total. The solution, pioneered on the Atlas at Manchester and refined by the 1970s, was virtual memory.

Here's how virtual memory works, boiled down: each process sees a contiguous virtual address space, but the operating system chops it into fixed-size pages (typically 4 KB) and stores them wherever it likes in physical memory. A per-process page table maps virtual page numbers to physical frame numbers. When the process reads virtual address 0x1000, the CPU (with help from the MMU) looks up the translation in the page table and fetches the data from whatever scattered physical frame is actually holding it. The process never knows the pages aren't contiguous. The OS gets to pack physical memory however it likes.

Now read that paragraph again and replace "process" with "request", "page" with "KV block", "physical frame" with "physical block in the GPU KV-cache pool", and "page table" with "block table". That's PagedAttention. The whole thing is a one-to-one correspondence.

OS virtual memory        →   PagedAttention
------------------------------   -----------------------------
process                  →   request (one prompt + generation)
page (4 KB)              →   KV block (e.g. 16 tokens)
page table               →   block table (logical → physical block idx)
physical frame           →   physical KV block in the shared pool
page fault / alloc       →   allocate a new block on demand
copy-on-write            →   copy-on-write for shared prefixes

I think this is the most useful mental model for the entire post. If you remember "it's virtual memory for the KV cache", you can reconstruct most of the mechanics on a napkin.

PagedAttention in one picture

Here's the machinery. The KV cache is no longer one big contiguous array per request. Instead:

• GPU memory holds a shared pool of fixed-size physical blocks. A typical block is 16 tokens. Each block can hold the K and V vectors for 16 consecutive positions of one request. Blocks are allocated from the pool as requests need them and freed back to the pool when they're done.
• Each request has a logical sequence of blocks: L0, L1, L2, ... arranged in order. The first 16 tokens go in L0, the next 16 in L1, and so on.
• Each request has a small block table that maps logical block index → physical block index. table[0] = 7 means "logical block 0 of this request lives at physical block 7 in the pool".

When attention runs, the kernel doesn't assume keys and values are contiguous. It walks the block table: "logical block 0 is physical block 7, logical block 1 is physical block 3, ..." and gathers the K and V vectors from wherever they actually live. There's a little indirection cost per block, but because blocks are substantial (16 tokens × hidden dimension), the fixed cost of the lookup is amortized across many arithmetic operations. The overhead ends up in the single-digit percent range.

The payoff is that you only ever allocate what you use, rounded up to block size. A request of 47 tokens takes three blocks (48 slots). Waste per request is bounded by BLOCK_SIZE - 1 tokens, so total waste across the system is small and constant instead of growing with max_context. Kwon et al. measured the resulting cache utilization at ~96% on production-like workloads, up from 20–40%.

Copy-on-write: when two requests share a prefix

Here is where the analogy pays off twice. Operating systems have a lovely trick called copy-on-write (COW): when a process forks, instead of duplicating its entire memory, the kernel shares the parent's pages with the child and marks them read-only. The child only gets its own copy of a page the instant it writes to one. Memory stays shared as long as nobody actually modifies it, which is most of the time.

This trick transfers directly. In LLM serving, many requests share a prefix. A chat app might prepend the same 800-token system prompt to every user message. Parallel sampling (the same prompt, multiple sampled continuations) shares every token up to the first sample token. Beam search is the same, at a finer grain: beams share everything except their most recent divergent token. If every one of those shared prefixes gets its own copy of the KV cache, you're paying for the same work many times over.

With PagedAttention, the scheduler can point multiple block tables at the same physical block. Each physical block maintains a reference count. As long as the count is greater than 1, nobody is allowed to write into the block in place. The moment one request needs to write (say, because it's about to generate a new token in a block still shared with another request), the engine clones that one block, decrements the refcount on the original, and updates the writing request's table to point at the clone. Everybody else keeps pointing at the original.

Why the attention kernel works at all

One thing that bothered me when I first read the paper was: attention is a dense matrix operation. How can it possibly work on non-contiguous memory without falling apart?

The answer is that attention, at the kernel level, is already a loop that walks over keys and values one chunk at a time. FlashAttention, for example, tiles the K and V matrices into blocks that fit in SRAM and processes them iteratively. PagedAttention aligns its block size with the tile size the kernel uses anyway. Inside each block, memory is contiguous. Across blocks, you just look up the next physical block address from the block table and continue. The kernel does a little more pointer arithmetic. It doesn't rewrite attention from scratch.

Misconceptions

"PagedAttention changes the model output." No. It doesn't touch the math at all. Attention produces the exact same logits regardless of whether the K and V tensors are laid out contiguously or scattered through a pool. The only change is in how the kernel fetches memory.

"Smaller blocks are always better because they reduce waste." It's more of a tradeoff. Smaller blocks reduce internal fragmentation (less padding in the last block per request) but inflate the block-table size and add per-block overhead inside the attention kernel. They also spread memory accesses more randomly, which can hurt cache performance. Kwon et al. found 16 tokens to be a strong default.

"Copy-on-write is mostly a beam-search optimization." The paper emphasizes beam search, but in production the dominant source of shared prefixes is system prompts. One prompt, many users, many concurrent requests all starting with the same 500–2000 tokens. COW there means the cached prefix lives exactly once in GPU memory across all of them.

🛠️ AutoSaddler: Automatic Harness Optimization with Durable Updates from Agent Execution Traces

AutoSaddler automatically improves LLM-agent harnesses by diagnosing execution traces, applying structured updates to prompts, tools, and middleware, and selecting changes that generalize.

Preliminary results report the following test Pass@1 scores across benchmarks and agent harnesses:

✨ Highlights

• Full-harness optimization: searches over prompts, tool definitions and implementations, middleware hooks, and agent-loop logic.
• In-depth diagnosis: deeply debugs execution traces and the harness codebase to identify root causes rather than relying on shallow reflection.
• Structured intervention: targets prompts, tools, and middleware through an explicit patch taxonomy and phased Capability-to-Steering schedule instead of unconstrained editing.
• Generalization-aware selection: validates updates beyond the motivating trajectories and uses reflection with an evolution DAG (EvoDAG) to retain broadly useful lessons.
• Durable execution: records append-only events, immutable provenance, resumable state, and content-addressed candidates.

🛠️ Installation

AutoSaddler requires Python 3.12-3.14, uv, and Git.

git clone https://github.com/microsoft/AutoSaddler.git
cd AutoSaddler
uv sync --extra dev

🚀 Quick Start

Run the deterministic, credential-free V2 template to exercise the optimization engine, event store, candidate evolution, and output projections:

uv run python -m autosaddler.v2.cli \
  --config configs/v2/local_template.yaml \
  --run-id local-template

🧭 Versions

• V2 (current): the durable, plugin-based implementation.
• V1 (legacy): the research-quality implementation used for the experiments in the arXiv paper.

🧩 How It Works

AutoSaddler formulates harness optimization as offline mini-batch learning. It uses three session types across the optimization lifecycle:

1. Diagnosis-Patch: inspects failed traces and the harness codebase, then proposes structured Capability patches (code or infrastructure) and Steering patches (textual behavior changes).
2. Reflection: compares pre- and post-patch traces, classifies fixed, regressed, still-failing, and still-passing cases, and records reusable lessons.
3. Evolution: consults the full EvoDAG to synthesize candidates from successful components and lessons across lineages.

🎯 Supported Harnesses and Benchmarks

⚙️ Configuration

Every V2 config starts with schema_version: autosaddler/v2. A scenario plugin is the adapter between AutoSaddler's generic optimization engine and a specific harness/benchmark pair.

🔬 Reproducing the Included GAIA2 Smoke Run

The smoke config exercises the real optimization pipeline on seven GAIA2 scenarios.

1. Prepare the repositories

Use a sibling layout with AutoSaddler/, Meta-ARE/, meta_are_data/, and a working_dir/.

2. Provision the benchmark inputs

uv run --extra meta-are-setup python scripts/meta_are/provision_gaia2_scenarios.py ...
uv run --extra meta-are-setup python scripts/meta_are/provision_demo_filesystem.py ...

3. Configure providers and run

export OPENAI_API_KEY="..."
export ANTHROPIC_API_KEY="..."
cd ../working_dir
uv run --project ../AutoSaddler \
  python -m autosaddler.v2.cli \
  --config ../AutoSaddler/configs/v2/meta_are_smoke.yaml \
  --run-id "$RUN_ID"

📝 Citation

@misc{park2026autosaddlerautomaticharnessoptimization,
  title={AutoSaddler: Automatic Harness Optimization with Durable Updates from Agent Execution Traces},
  author={Sungho Park and Wonjoong Kim and Rongyuan Tan and Jue Zhang and Wook-Shin Han and Pengfei Gao and Chanyoung Park and Yongqiang Yao and Rao Fu and Elsie Nallipogu and Qingwei Lin and Saravan Rajmohan and Dongmei Zhang},
  year={2026},
  eprint={2608.23041},
  archivePrefix={arXiv},
  primaryClass={cs.AI},
  url={https://arxiv.org/abs/2608.23041},
}

WeMM-Embedding: WeChat Multi-Modal Embedding

WeMM-Embedding is a family of universal multimodal embedding models developed by the WeChat Vision team. It provides unified representations for text, images, videos, visual documents, and interleaved multimodal inputs, achieving state-of-the-art performance across multiple benchmarks covering diverse tasks and domains.

Model Zoo

All models support text, images, videos, visual documents, and interleaved multimodal inputs. Embeddings are obtained from the last-layer hidden state at the dedicated <embedding> token position, followed by L2 normalization. Audio input is not currently supported.

Installation

pip install -r requirements.txt

Transformers

We recommend using transformers==5.2.0 for inference and reproducibility, as newer versions may differ in preprocessing behavior.

python examples/transformers_inference.py \
  --model /path/to/WeMM-Embedding-2B \
  --image /path/to/image.jpg \
  --video /path/to/video.mp4 \
  --dimension 2048

The example produces independent text, image, and video embeddings. Omit --dimension for the full embedding dimension.

Sentence Transformers

python examples/sentence_transformers_inference.py \
  --model /path/to/WeMM-Embedding-2B \
  --image /path/to/image.jpg \
  --video /path/to/video.mp4 \
  --dimension 2048

SentenceTransformer loads the model directly, so a Hugging Face model id such as tencent/WeMM-Embedding-2B also works in place of a local path. Text, image, and video inputs go through SentenceTransformer.encode(), and MRL is selected with --dimension.

Serving

Tested versions: vLLM 0.27.0 and SGLang 0.5.9.

vLLM:

MODEL_PATH=/path/to/WeMM-Embedding-2B
vllm serve "$MODEL_PATH" \
  --runner pooling \
  --chat-template "$MODEL_PATH/embedding_chat_template.jinja"

SGLang:

MODEL_PATH=/path/to/WeMM-Embedding-2B
python scripts/patch_sglang_video.py
python -m sglang.launch_server \
  --model-path "$MODEL_PATH" \
  --is-embedding \
  --enable-precise-embedding-interpolation

Equivalent one-command wrappers are available in scripts/serve_vllm.sh and scripts/serve_sglang.sh.

Matryoshka Embeddings

For a supported dimension d, truncate the full embedding and normalize it again:

embedding = torch.nn.functional.normalize(embedding[..., :d], dim=-1)

On MMEB-v2, the 2B model at 256 dimensions retains 98.7% of its full-dimensional image and video performance.

Evaluation

MMEB-v2

Results on 78 datasets. Image and video tasks use Hit@1, while visual-document tasks use NDCG@5. Higher is better.

MMEB-v3

Results on 190 tasks. V3-All includes the 78 MMEB-v2 tasks, 53 text tasks, 47 agent tasks, 11 audio tasks, and MCMR.

Text results use NDCG@5; agent, MCMR, and audio results use Hit@1.

cd mmeb_v3_eval
DATA_ROOT=/path/to/MMEB-V3 bash scripts/download_data.sh
MODEL_PATH=/path/to/WeMM-Embedding-2B DATA_BASEDIR=/path/to/MMEB-V3 \
OUTPUT_DIR=exps/wemm_embedding bash scripts/run_eval.sh

Citation

@article{wemm-embedding,
      title={WeMM-Embedding: WeChat Multi-Modal Embedding Technical Report}, 
      author={Junjie Zhou and Ke Mei and Lei Li and Tianyi Wang and Fengyun Rao and Jing Lyu},
      year={2026},
      eprint={2608.24053},
      archivePrefix={arXiv},
      primaryClass={cs.CV},
      url={https://arxiv.org/abs/2608.24053}, 
}

License

Unless otherwise noted, Tencent-authored code in this repository is released under the Apache License 2.0.

OpenAI's ChatGPT desktop app's built-in browser and ChatGPT Sites now support WebMCP. ChatGPT and Codex can now use compatible websites' tools instead of guessing its way through the interface. Website teams should design, test, and understand the complete agent experience because users can now be agents, or a person and agent browsing together.

Alibaba’s Qwen team has released Qwen3.8-Flash-Next, an open-weight preview of the architecture it intends to use for Qwen4, carrying 125B parameters but activating only 6B for each token. Its licence may not qualify for the EU AI Act’s open-source exemption.

Alibaba’s Qwen team has published the architecture it plans to build Qwen4 on. Qwen3.8-Flash-Next carries 125B parameters and fires only 6B of them for each token it produces.

The claim is about cost rather than capability. The team says its concern is what architectural choices do to inference bills as agentic jobs with very long contexts become the normal workload.

The comparison it draws is with its own last model. Qwen3.7-Plus holds 397B parameters and activates 17B, so this one runs on roughly a third of the active compute.

Three of the four changes are conventional enough. A new sparse attention scheme works on micro-blocks instead of picking individual tokens, a gated residual mechanism controls what passes between layers, and the training recipe drops batch-size warmup entirely.

The fourth is the odd one. Rather than adding experts, the model bolts on 51B parameters as a separate embedding indexed by two and three-character fragments, which the team says costs less computation and is easier to offload onto memory-constrained accelerators.

That last phrase is worth reading twice. Designing for accelerators short of memory is what you do when you cannot buy the best chips, which is the position export controls have put Chinese labs in.

The numbers attached to all this are Alibaba’s own. TNW noted this month that the company called Qwen3.8 the world’s second-best model and showed no proof, and these scores again come from the team’s own harnesses.

Some of the choices are unusually candid. The model card says its Humanity’s Last Exam score was graded by GPT-4o rather than the benchmark’s own grader, which is disclosure rather than neutrality.

The licence is where Europe has a question. The weights sit on Hugging Face under a qwen-community licence, and TNW reported on 7 August that Alibaba wants to charge its largest commercial users.

The AI Act treats that distinction as load-bearing. Article 53(2) lifts two documentation duties for models under a free and open-source licence, and Recital 103 says components provided against a price or otherwise monetised should not get the exemption.

European firms are not waiting for the answer. Thomson Reuters built its model on Qwen, and anyone who does inherits whatever the licence eventually becomes.

Claude gets its own browser in Cowork

Claude opens its own browser to navigate sites, read pages, and fill forms, inside the desktop app.

Claude now has a browser built into Claude Cowork on the desktop app. When a task needs to use a website, a browser opens in the side panel and Claude navigates webpages, reads them, clicks, and types. You can now hand off the web part of the task and stay where you are: Claude can fill in a form, pull numbers from a dashboard, or work through a portal that has no connector. No extension, no setup, and nothing shared from your own browser unless you choose to.

Until now, giving Claude the ability to use the web in Cowork meant giving it access to your browser through the Claude in Chrome extension. When the work is on a page you already have open, that's still the right choice. But a lot of web tasks don't need your browser, just a browser, and now Claude has one.

It's rolling out this week to Pro, Max, and Team plans in the Claude desktop app. Enterprise admins can turn it on for their organization starting today.

Which browser, when

It's Claude's browser, not yours. The built-in browser is separate from your own. Claude never sees your tabs, bookmarks, or passwords. To stay signed in to your sites, you can bring your logins over site by site, from Chrome, Edge, or Firefox on macOS and from Firefox on Windows and Linux. Banking, email, and single sign-on sites are left out unless you choose to include them.

That's also the difference between the two ways Claude can use the web. The built-in browser is for handing web tasks to Claude while you keep working: gathering research for a report, or collecting this month’s invoices from a vendor portal. Claude in Chrome is for the page you already have open, with the accounts you're already signed in to, such as updating your CRM, working through your inbox, or editing the doc in front of you.

If you already use Claude in Chrome, it keeps working and stays your default; otherwise Claude uses the built-in browser. Switch anytime in Settings → Cowork → Preferred browser.

Staying in control

The built-in browser carries the same prompt injection risks as any AI agent that acts in a browser, where instructions hidden in a page try to redirect Claude. It runs the same safeguards as Claude in Chrome, including the checks that review Claude's actions against what you asked for. We describe them on the Claude in Chrome blog post. Those measures meaningfully reduce the risk but can't eliminate it, so we recommend starting on sites you trust. Read our safety guide for more.

Getting started

The built-in browser is rolling out over the coming week to Pro, Max, and Team plans in the Claude desktop app on macOS, Windows, and Linux (in beta). Once it reaches you, it's on by default: give Claude a task that involves a website and the browser opens on its own. On Enterprise plans, it's available now and admins can manage it in Organization settings → Cowork → Built-in browser.

The built-in browser lives in the desktop app. From the web or your phone, Claude can still drive it as long as your desktop app is open and online. On the web without the desktop app, Claude in Chrome remains the way to give Claude a browser.

Surprise: Z.ai is the AI lab behind the mysterious Ox Alpha model

Over the weekend, the nerds were buzzing with speculation over which AI lab was behind Ox Alpha, the mysterious new open-weight AI model launched onto OpenRouter anonymously and already topping benchmarks and leaderboards against the best models.

As many had expected, Ox Alpha was spawned by GLM-maker Z.ai, according to Bloomberg. Z.ai confirmed that Ox Alpha is the newest iteration of its GLM series, which Hugging Face famously used recently to defend itself against an attack from OpenAI agents.

The company said it will release the weights for Ox Alpha on Wednesday, after which developers can build on top of it. The company describes Ox Alpha as “a reasoning model designed for coding, sustained agentic work, and production workloads. It is suited for long-horizon software engineering, complex reasoning, and workflows that combine text with visual context.”

The release of Ox Alpha adds to the burgeoning threat of cheap, capable models from China that could take real market share away from expensive frontier model companies like OpenAI and Anthropic.

Earlier this month, Z.ai released GLM-5.3, which rivals Anthropic’s Fable 5 on certain benchmarks.

TechCrunch has reached out to Z.ai for comment.

How to Make LLMs 3X Faster

A 70-billion-parameter model requires reading roughly 140 GBs of weights out of the GPU memory. On a modern data center GPU, this transfer can take tens of milliseconds. The actual calculation applied to these weights takes a fraction of that time. This means that the processor’s math units are unused for most of the time taken by the token generation step.

Speculative decoding is a technique that converts this unused capacity into output. A second, much smaller model produces several candidate tokens in advance. The large model evaluates all of them in a single forward pass instead of one pass per token, resulting in 2-3 times faster generation. To make things better, the text produced remains statistically identical to the output of the large model running alone.

In this article, we will look at how speculative decoding works. Here’s what we will cover:

• Why token generation runs one step at a time
• What a GPU spends its time on during generation
• How several candidate tokens are evaluated in a single pass
• The accept and reject loop, and what happens when a candidate is wrong
• Why output quality is preserved exactly
• Acceptance rate, and why it varies by workload
• The four places a draft can come from
• When speculative decoding stops helping

Autoregressive Decoding

Text generation works one token at a time.

The model reads everything produced so far, computes a probability distribution over its vocabulary, selects the next token, appends that token to the input, and repeats the cycle. Each cycle is called a forward pass, and every forward pass runs the input through all layers of the model.

For example, token 50 depends on token 49 being present in the input, and token 49 depends on token 48, and so on. Computing them simultaneously would break the dependency chain that makes the output coherent.

The implication is that a 500-token response requires 500 sequential forward passes, each one completing before the next begins. Since the duration of a single pass depends on the size of the model, the total generation time equals the number of output tokens multiplied by the time per forward pass.

This explains why the response speed stays roughly steady whether the answer is a short factual reply or a long block of code, because the per-token cost stays the same either way. It also explains why a larger model produces text more slowly on identical hardware.

Modern inference systems use a KV cache, which stores the attention state for tokens already processed so that each new pass only computes attention for the newest position. This cuts the work done inside each pass to a large extent, though the requirement for one pass per token still remains.

Memory Bandwidth

Since the number of passes is fixed by how much text we want, it leaves the second half of the equation. What does a single forward pass actually spend its time doing?

To put it simply, a forward pass spends most of its duration moving data rather than performing arithmetic calculations.

Model weights live in the GPU memory, usually called VRAM. To compute anything with those weights, the GPU has to transfer them into the compute units where the multiplication happens. For a 70-billion-parameter model stored at 16-bit precision, this transfer amounts to roughly 140 GBs for every single token.

The arithmetic performed on those 140 GBs is quite small by comparison. One token means one narrow vector flowing through each weight matrix. The GPU loads an enormous matrix out of memory, multiplies it against that vector, discards it, and loads the next one.

The consequence is that during prompt processing, compute utilization is around 90 to 95 percent. However, during token generation, it falls to somewhere between 20 and 40 percent. The math units are unused for most of every step while the memory bus runs near capacity.

The difference is driven by how much work each weight read supports:

• Prompt processing reads the weights once and applies them to thousands of input tokens simultaneously.
• Token generation reads the same weights and applies them to exactly one token.

This is capacity that has already been paid for, but underutilized.

But why does this matter practically?

A GPU with higher memory bandwidth improves generation speed more than one with more raw compute.

However, spare capacity only helps if there is useful work to put into it. The question is whether a single forward pass can produce more than one token’s worth of output.

Parallel Verification

A single forward pass can evaluate many positions at once.

Transformers process an entire sequence in parallel. When we feed in a sequence of tokens, the model computes a next-token prediction at every position in that sequence during the same pass. For example, a five-token input produces five predictions.

These predictions stay valid because of causal masking. Inside the attention mechanism, position 5 can access positions 1 through 5 while positions 6 and beyond are masked out, and position 3 can access only positions 1 through 3. Each position is therefore conditioned on exactly the tokens preceding it, identical to the conditioning it would have received had we generated the sequence one step at a time.

This is the property that makes prompt processing fast. A 2,000-token prompt runs through the model in one pass rather than 2,000, because all 2,000 positions are computed together.

When applied to verification, the consequence is direct. For example, if we append four candidate tokens to the context and run one forward pass, we receive the model’s own prediction at each of those four positions.

One thing to understand here is that verification and generation are basically the same operation. The target model performs identical work at each position. The cost savings comes from performing that work across several positions in a single pass instead of across one position in each of several passes.

Draft and Verify

The complete loop combines a fast source of candidate tokens with the batched evaluation described above.

This setup uses two models:

• The large model we want output from is called the target model
• Running alongside it is a much smaller draft model with 10 to 20 times fewer parameters. It is usually drawn from the same family and uses the same tokenizer.

Each round has three steps:

• The draft model produces K candidate tokens through its own serial loop. Those passes are sequential as well, though each one costs a small fraction of a target model pass.
• The candidates are appended to the context. The target model evaluates the extended sequence in one forward pass.
• Working left to right, each candidate is compared against the target model’s prediction at that position. The matching candidates are kept, and as soon as the first mismatch appears, the remaining candidates are discarded.

The mismatch point plays an important role in this. The verification pass already computed the target model’s prediction at that position, so that token gets used directly. We keep the matching prefix and receive one correct token at no additional cost.

This property places a bound on the downside.

In the worst case, all four candidates might fail to match, but we would still have the one token the target model produced at the first position, which is exactly what plain decoding would have delivered from one forward pass. The wasted effort amounts to just the draft model’s compute and some extra effort in the verification pass. Both are drawn from otherwise available capacity. In a typical case where two of four candidates match, we get to keep two plus the free token, giving three tokens from one target model pass.

Draft length K is a tunable value, which is commonly set between 3 and 5. Larger values raise the ceiling on savings, since a fully accepted draft of eight saves more than a fully accepted draft of three. However, larger values also reduce the odds that later candidates survive, because the draft model conditions on its own unverified output as it moves forward. Past a certain point, the additional candidates get discarded often enough that the extra work outweighs the benefit.

Lossless Guarantee

Speculative decoding produces text with the same statistical properties as the target model running alone. This is enforced by means of the acceptance rule.

Under greedy decoding, where we always take the highest-probability token, the rule is quite direct. A candidate is kept when it matches the target model’s top choice at that position, and dropped when it fails to match.

However, sampling takes more care, since tokens get picked with some randomness. Both models produce a full set of probabilities across the vocabulary at each position. The rule compares the two sets:

• When the target model gave the candidate at least as much probability as the draft model did, the candidate is kept.
• When the target model gave it less, the candidate is kept part of the time. This is in proportion to how far apart the two numbers were.
• When a candidate is dropped, the replacement gets picked from an adjusted set of probabilities, with the draft model’s own scores subtracted out first.

This last step is critical. If we add up both paths, the candidates kept and the candidates replaced, the odds of any particular token appearing depend exactly on the target model’s own odds for it. This is regardless of what the draft model suggested.

There are two qualifications to this:

• Matching odds still allow different wording, since sampling stays random either way. Running the same prompt twice can give varied text in both setups.
• Computers store these numbers with limited precision, so rounding can flip the winner when two tokens sit almost exactly tied.

Acceptance Rate

The size of the speed increase in this approach is governed by the acceptance rate, which is largely a property of the workload.

Acceptance rate is the fraction of candidate tokens the target model keeps, and acceptance length is the average number confirmed per verification pass, including the free token at the end.

Different workload types produce different results:

• Structured and repetitive output produces high acceptance. For example, code generation, summarization, extraction, and retrieval-augmented answers reuse large amounts of text from the input, which makes the next token easy to predict from a small model.
• Open-ended output produces low acceptance. Creative writing and open conversation generate text with genuine variety, where a small model diverges from a large one far more often.

Sampling temperature contributes as well. Higher temperature flattens the probability distribution, which increases mismatches between the two models and pushes acceptance down. If the acceptance falls below roughly 50%, the additional work outweighs the savings.

For reference, DeepSeek reported acceptance rates between 80 and 90 percent for the second predicted token in production serving of DeepSeek-V3, which translated to roughly 1.8x generation throughput.

The practical implication is that two teams can deploy the same configuration on the same hardware and get different results, because their users are asking different questions. Ultimately, acceptance depends on the quality of the candidates, which brings us to where candidates come from.

Candidate or Draft Sources

The key question while choosing candidate or draft sources is where to obtain fast predictions cheaply. There are four answers in common use:

• A separate small model: The original approach pairs the target with a smaller sibling, so a 1B model drafting for a 13B target, or a 3B to 8B model drafting for a 70B target. Same family and identical tokenizer are requirements in this approach. The cost is a second checkpoint to deploy and version, plus VRAM that comes out of the KV cache budget, which reduces how many concurrent requests the server can hold.
• Extra prediction heads on the target model: Lightweight output heads predict tokens two or three positions ahead using the target model’s internal representations. DeepSeek-V3 trained these during pretraining to improve model quality, then reused them at inference as the draft source. The cost is training, which puts this option out of reach unless we control the model.
• A cheaper version of the same model: The draft runs the same weights under a reduced compute budget through quantization, layer skipping, or a compressed KV cache. For example, QuantSpec uses 4-bit weights and a 4-bit KV cache for drafting while verification runs at higher precision, reporting speedups above 1.78x with acceptance above 90 percent. The cost is implementation complexity, since draft and target share hardware and cache structures.
• A search over existing text: This approach scans the prompt and previous output for a recent matching sequence, then proposes whatever followed it last time. Memory cost is zero, and a single model is involved. It contributes only when output repeats input, where it reaches 2x to 4x on tasks like document editing and summarization.

Selecting an option depends on the deployment. Also, tokenizer compatibility constrains pairing more tightly than model quality does. A stronger small model with a different vocabulary is unusable as a draft source without additional machinery. All four options depend on spare compute being available. This condition holds under some serving loads better than others.

Concurrency Limits

The increase in speed also depends on the operating regime rather than on the technique alone. The gains shrink as server load rises.

Speculative decoding spends compute capacity that would otherwise go unassigned. When a server handles a single request, this capacity is genuinely available. As concurrent requests accumulate, the same weight read operation serves many requests at once, and the compute units approach saturation. Verification work has to compete with real requests.

One systematic evaluation reported up to 1.96x on a 70B model at batch size 1, declining to 1.21x at batch size 128. Under higher concurrency, the technique can fall below baseline throughput, at which point enabling it costs more than the benefits.

Serving systems try to handle this in different ways. For example, vLLM exposes a flag that disables speculation above a configurable batch size. It supports dynamic adjustment where draft length shrinks as concurrency rises and reaches zero under heavy load. The control signals routine operational tuning rather than an edge case.

Another boundary is that the time to first token stays roughly the same, since speculative decoding applies to generation rather than prompt processing. Therefore, workloads with long prompts and short outputs have relatively little to gain.

DeepSeek documented the tradeoff, describing multi-token prediction as slightly reducing throughput while significantly improving end-to-end generation latency.

Conclusion

Speculative decoding rearranges when the processing happens rather than reducing how much the target model performs. Here are some key points we have understood:

• Token generation is slow because every token requires reading the full set of model weights out of memory, while the arithmetic applied to those weights is comparatively small.
• A transformer computes a prediction at every position in one pass, which makes evaluating several candidate tokens cost about the same as evaluating one.
• A rejected draft truncates rather than wastes, since the verification pass supplies a correct token at the mismatch position regardless.
• Output quality is preserved by the acceptance rule itself, so it holds without tuning.
• The size of the gain depends on how predictable the output is and how much spare compute the server has available.
• The variants differ in where predictions come from and what that source costs.

Full article content is not available for inline reading.

Read the original article →

Earlier this year, Meta created a “plan” to reduce some of its teams by as much as 60 percent to make the company “AI native,” Reuters reported today, citing two people familiar with Meta’s internal affairs.

Reuters’ report highlights the challenges organizations face when analyzing the best uses for AI and determining when the technology is a better fit for certain tasks than employees.

Meta confirmed to Reuters that the plan, reportedly codenamed Project OT (short for organization transformation), explored scenarios in which Meta reduced some team headcounts by 60 percent and that the plan called for two rounds of layoffs. Meta wouldn’t confirm which teams Project OT affected.

Meta told the publication:

As part of our company restructuring earlier this year, we asked some teams to conduct a scenario planning exercise looking at the potential impact of redeployments, open role closures and cuts. This ultimately resulted in moving thousands of employees to do priority work on several newly-established teams, as has been publicly reported. Ultimately, we didn’t move forward with every scenario from the exercise – and it was never assumed we would.

Reuters reported that Meta CEO Mark Zuckerberg “set Project OT in motion and directed executives to proceed with the changes to management structures” earlier this year. It said that the first round of layoffs from Project OT occurred in May and that Meta canceled the second.

Reuters said it reviewed “scores of internal documents, posts, and recordings” and spoke with “more than 20 people with knowledge of Meta’s inner workings” about the since-scrapped plans.

Per the publication, Meta executives created Project OT in January. Project OT reportedly explored using AI to perform “much of the daily work performed by thousands of human employees.” Small teams of people would oversee the AI, the report said, citing “one internal planning document reviewed by Reuters and three people familiar with the project.”

In these scenarios, Meta would give some employees new roles and lay off others. One HR executive reportedly said that Meta would have reduced its headcount by about 25 percent or more under these scenarios. Meta told Reuters that it canceled Project OT before determining how many layoffs the plan called for.

Meta was going to use some of the money that it saved from layoffs to pay for high-performing employees, especially those with AI engineering skills, Reuters reported, citing “two people familiar with the matter.”

“AI native”

One of the Project OT documents that Reuters reviewed described “AI native” as a company where “AI-ready tools and agents interact, workflows are automated, [and] new builds are AI-first.” Being “AI native” also means, per the document, selling AI agents to third parties, which Meta started doing in June.

This year, Meta reportedly launched a pilot program that restructured engineering teams, research teams, and at least eight other teams into smaller groups.

This followed the reported October publishing of an internal post called “AI-Native Playbook,” in which a Meta product management team member outlined how the pilot would remove middle management and use “agent-assisted analysis” to help prioritize daily tasks.

Reuters noted that HR employees and “AI systems” would help Meta’s leaders decide about promotions; however, Meta told the publication: “Performance rating and promotion decisions were and are made by people, not AI.”

Second thoughts

Immediately after issuing the May layoffs, Zuckerberg reportedly canceled the November wave. Reuters said it “was unable to determine what exactly prompted Zuckerberg to shift course.”

Reuters said March and April reports of impending layoffs and Meta tracking employees’ keyboard and mouse input in order to train AI agents (Meta has since paused the program) hurt employee morale.

Another potential factor in Meta’s decision to scale back Project OT was uncertainty about whether increased AI use would boost productivity. Citing internal posts, Reuters noted: “For instance, code changes made to the internal software platforms and infrastructure employees use on the job were up 220 percent year-over-year, according to a post by [Meta CTO Andrew] Bosworth in early June. But changes that led to new or upgraded features reaching Meta users were only up 36 percent.”

Internal posts also reportedly pointed to AI agents making “large-scale, disruptive actions that humans are unlikely to execute” and leading to a 40 percent increase in major technical and security incidents compared to the prior year. Employee time spent resolving those problems increased by as much as 70 percent. Meta declined to comment on these internal posts.

In July, however, Zuckerberg reportedly acknowledged during a company meeting that the “trajectory of the agentic development over at least the last four months hasn’t really accelerated in the way that we expected.”

Many organizations, including those much bigger and much smaller than Meta, are exploring ways that AI could help with company goals, such as by saving employees time, driving revenue, or reducing costs, including, in some cases, human resources. Meta’s story also shows how far some firms are willing to go to implement AI in an advantageous way, even at the cost of jobs.

Meta’s case suggests that even some of the most eager organizations may struggle to replace various human workloads with AI while also highlighting the risks of overzealous AI projects.

Claudeforce puts the world's largest customer relationship management platform directly inside Claude. It ships with 37 pre-built sales skills and lets sellers query, update, and act on live CRM data without ever opening Salesforce itself. Claudeforce is now available to select pilot customers. An open beta is planned for September.

Lovable CTO: The Future of SaaS Is Apps That Agents Can Use

Lovable is branching out from AI-powered web app creation and into MCP-powered ‘capabilities’. We talk to CTO Fabian Hedin.

Lovable is well known as an AI-powered platform to build applications. But ironically, it is now moving towards a future where fewer and fewer people will be using conventional apps. That is, of course, because of the growing impact of agents.

In a recent blog post, Lovable outlined a vision for “a digital brain for your team connecting your daily tools.”

Or as Lovable CTO Fabian Hedin put it in an interview with Latent Space, “you can get to a place where you’re using one entry point to all the work that you’re doing.”

To be clear, Lovable still wants to be the tool you use to build apps — but increasingly, it will also enable you to build what Hedin calls “capabilities.” Lovable defines a capability as a useful part of an application that an agent can call directly; bypassing the need for a human user to open the app.

Lovable can turn a published application into agent-accessible capabilities by exposing selected functions from the app as tools through a hosted MCP server. The result is essentially one application with two interfaces: a traditional human UI and a new agent interface that can be used from ChatGPT, Claude and other MCP-compatible AI clients.

This is how fast an AI business evolves

This shift towards capabilities is the latest evolution from Lovable, in an already fast-moving 3 years in business.

Lovable emerged from GPT Engineer, an open source coding tool that launched in 2023, initially focusing on prototyping. In November 2024, it became a commercial product and the following month, it was rebranded as Lovable.

By that point, they’d begun to notice some of its users building production apps on Lovable — including products that had become real businesses.

“We started seeing people on the platform building not only a prototype, and not only an MVP [Minimum Viable Product], but the actual thing — an actual product that serves real customers,” Hedin said.

Next, Lovable noticed its users creating internal software, in some cases to support a public-facing app and in other cases as an internal app built for an enterprise company.

“People started creating not only software to enable a business, in terms of a customer-facing product, but also the operations behind the company,” Hedin said.

He means tools like a CRM, an admin panel, or a customer-support console.

From app builder to agent platform

So in less than three years, Lovable has become an all-round software creation and hosting company, which means it’s swimming in the same waters as the likes of Vercel and Cloudflare. That said, Lovable is more focused on AI-generated software than infrastructure. But we are seeing crossover in these markets — for example, Vercel’s v0 allows you to generate an app from natural language, just like Lovable.

Also just like the black triangle and orange cloud companies, Lovable has expanded into agentic workflows.

This rapid product evolution has been accompanied by strong user and revenue growth. According to a tweet from Deedy Das, a partner at lead investor Menlo Ventures, the company has surpassed a $500 million annualized revenue run rate, with more than 60 million projects created and over 900 million monthly visits to Lovable-built apps. Lovable also says employees at nearly two-thirds of the Fortune 500 have used the platform.

Unsurprisingly, Menlo Ventures is doubling down on its investment. It led Lovable’s $400 million Series C this month, alongside the Scaleup Europe Fund managed by EQT, valuing the company at $13.3 billion.

Hedin attributes the pace of change to a combination of Lovable’s innovation and the rapidly improving state of LLMs.

“Every few months, we introduce new capabilities at the application layer, while the large language models also continue improving. Those two things compound.”

Lovable’s model of a company brain

The concept of a digital brain for an organization, for Lovable, essentially means a single interface where you can access many different tools and workflows.

“It should have as much context as possible about you, your company and the world around you,” said Hedin. “Then it needs the capabilities to perform both general tasks and actions that are specific to your organization.”

Ultimately, he added, the goal is that “everything that you’re building can be reused in an agentic way.”

In a sense, then, applications are becoming a collection of capabilities that users will increasingly access through an organizational agent — instead of, or in addition to, the actual application.

“Our job as a platform is to ensure that all these separate capabilities are connected through one agent — not that you have to build a different agent for every task,” said Hedin.

As an example, Hedin mentioned an internal application they use at Lovable.

“We built this internal tool to help us grant credits to users [via] our support team, and help manage our platform in different ways. Those capabilities are now available [internally] through the Lovable agent.”

Lovable also wants this company brain to work asynchronously. Its agent can schedule itself to resume a task later — for example to check a deployment or to monitor a recurring process — then return the result to the same conversation.

The competition

Lovable isn’t the only company pursuing a “company brain” vision. Vercel CEO Guillermo Rauch recently introduced its internal agent, called @𝚟. “Every day-to-day job at Vercel now involves @𝚟,” Rauch tweeted. “It’s growing exponentially both in daily interactions and token use.”

Hedin acknowledged that Vercel and other AI companies are building towards a similar vision, but he thinks Lovable’s “wedge” is “being the best place to build the capabilities that agents need.” In other words, Lovable’s focus is on helping their users build the capabilities that a company brain will need.

“Orchestrating these capabilities is the easy part,” Hedin said. “Making sure they are well connected, built correctly and reliable is the hard part.”

He also hinted at why they’re using the word ‘brain’ to describe this shift, rather than just ‘agent’.

“I’m careful about using the word ‘agent.’ It suggests something like an employee performing a task, which is an easy way to think about it. But underneath, it is really about connecting the right context and capabilities.”

Security and connecting to external capabilities

Perhaps the biggest challenge with the agents and capabilities paradigm is security. For instance, if one of your employees creates an app with Lovable that connects to the company Slack, you want to ensure that user doesn’t inadvertently expose their personal messages, or any other confidential information, to the company brain.

Connectors are Lovable’s method of connecting to external tools and services. Hedin said the platform must account for a “kind of permissioning graph” to maintain security and privacy.

As described in a technical article on Lovable’s blog, one connector type, which Lovable calls an “app user connector,” preserves each user’s identity and source-system permissions. Credentials are stored server-side in encrypted form and handled by Lovable’s connector gateway, rather than being exposed to the generated application; the app instead presents a short-lived key bound to the relevant user.

“We separate the connection to external systems from the application code being written,” is how Hedin put it. “The application interfaces with the Lovable platform, but the application itself never gets access to those credentials.”

The future of SaaS

So Lovable is moving to a future where a company brain uses capabilities derived from the apps its users build. That begs the question: what will happen to SaaS apps?

Hedin reiterated that people will increasingly interact with software through an AI layer — the company brain concept.

“People are not going to have as many tabs open in different tools as they have historically. That experience is going to consolidate, but the vertical capabilities those tools provide will remain valuable.”

He recognizes that some traditional SaaS products may “fight” this trend, by sticking with their traditional apps and not adapting, but he says Lovable wants to become a platform for building capabilities.

“We want to build this open platform that anyone can connect to, anyone can use,” he said.

Hedin ended with some advice for SaaS companies, whether existing ones or apps that might emerge on the Lovable platform.

“I think SaaS businesses are going to have to focus more on providing the shovel for AI to use their capabilities.”

Meta has agreed to make major changes to its products.

In July, several Confluent colleagues and I published The LogDrive: Composable Durability for Cloud-Based Shared Logs. The paper evolves the concepts of Virtual Consensus in Delos by decomposing the Loglet abstraction into AtomicLog and LogDrive, moving composition below sequencing to a new durability abstraction. This post describes these new abstractions in the context of Virtual Consensus, focusing on how they support RAID-like composability for shared logs.

The ideas of the paper came out of a research project led by Mahesh Balakrishnan, Gardner Vickers, and Lucas Bradstreet. The project itself was to build a Kafka-on-S3 service to run in Confluent Cloud and the project ultimately became K2 or Kora 2, the next evolution of the Kora engine (which powers Confluent Cloud’s Kafka service). The first product built on K2 was Freight Clusters (Kafka on S3). The research that led to the LogDrive paper originated in Conflux, the scalable metadata service in K2 which acts as sequencer and metadata database for the fleet of leaderless brokers, akin to WarpStream’s agents.

Conflux is a multi-master state-machine replication service built over a shared log based on Virtual Consensus which uses cloud services such as S3 and DynamoDB as the backing storage service.

But this post isn’t about K2, nor even Conflux, its about extending the shared log protocol Virtual Consensus for better composability, specifically, being able to use RAID-like semantics to build logs with striping and quorums over diverse backing storage without having to rewrite the stack.

A brief recap of Virtual Consensus

I recommend reading my previous posts on Virtual Consensus to better understand this post:

• An Introduction to Virtual Consensus in Delos

• Steady on! Separating Failure-Free Ordering from Fault-Tolerant Consensus

But in any case, I will do a quick recap to set the scene for describing the new abstractions introduced by the LogDrive paper.

Traditional replicated-log protocols tend to combine sequencing, durable storage, failure handling, and membership changes. Virtual Consensus separates these responsibilities between a VirtualLog and a sequence of Loglets.

The VirtualLog exposes one logical address space over a chain of independent Loglets. One Loglet is active, while its predecessors are sealed. The active Loglet provides the steady-state data path: it accepts appends and establishes a durable order within a fixed configuration—failure-free ordering. Basically the happy steady state where everything is running fine.

The VirtualLog provides the control plane. When the active Loglet experiences a failure and must be replaced, the VirtualLog seals it, records its final tail, and extends the chain with a new Loglet.

Virtual Consensus separates the protocol into failure-free ordering (Loglet) and fault-tolerant consensus (VirtualLog). A Loglet does not need to implement recovery from partial failure, such as leader elections or membership changes. In that sense, it can be much simpler to implement than Raft. It only needs to order entries with a fixed configuration and provide fault-tolerant seal and checkTail operations so that the VirtualLog can terminate the segment safely.

The Problem With Append and Loglet Composition

There is a limitation to the Loglet abstraction when it comes to Loglet composition. By composition I mean building Loglets that are composed of other Loglets. For example, building a generic QuorumLoglet over a set of child Loglets, or a StripingLoglet that stripes writes across a set of child Loglets.

The fundamental write operation of the Loglet is append(value) -> address.

An append both assigns a position and stores the value.

Striping works despite this coupling of sequencing with storage. A StripedLoglet routes each append to one child Loglet append and translates the returned child address into its own address space. This works provided that each child allocates contiguous addresses (for address translation between child and parent address space).

But while append can work for striping, it does not compose cleanly for a QuorumLoglet. A parent can forward an append to several child Loglets, but each child independently assigns the address. Partial failures and retries may place corresponding values at different addresses across the child Loglets, creating divergence.

An external sequencer could assign positions first, but the Loglet API has no operation for storing a value at a caller-selected address (it only has append). The parent would have to ignore the children’s ordering and somehow add its own sequencing and reordering machinery. Doesn’t sound like much fun.

In Delos, quorum replication was therefore implemented inside the NativeLoglet. The NativeLoglet consists of a sequencer and a set of Log Servers. The sequencer assigns an address to each append and then writes the value at that address to a quorum of Log Servers. Crucially, the Log Servers expose write(address, value), not append(value).

Loglet composition via append is the problem. This now brings us to the new abstractions: AtomicLog and LogDrive.

Making Loglets More Composable

The AtomicLog together with the LogDrive is an implementation of the Loglet API. From the VirtualLog’s perspective, AtomicLog is simply another Loglet: it supports append, readNext, checkTail, prefixTrim and seal, and it can be replaced through the normal Virtual Consensus reconfiguration mechanism.

The further decomposition of the Loglet is as follows:

• The AtomicLog is responsible for sequencing and general log semantics but delegates durability. Sequencing/addressing is achieved via a soft-state sequencer (which we can consider is part of the AtomicLog).

• The LogDrive (sitting below the AtomicLog) is concerned with durability rather than sequencing. It exposes a flat numbered address space of durable single-value registers together with weakTail, an operation that lets AtomicLog reconstruct the tail from backing storage after the sequencer has disappeared. 

Composition into stripes and quorums exists at the LogDrive level, below sequencing. That is, composition is via the LogDrive API, not the AtomicLog (Loglet) API.

The LogDrive API does not include append, as composition requires writes to use caller-defined addresses:

interface LogDrive {
  void write(long address, ByteBuf payload);
  ByteBuf read(long address);
  TailDesc weakTail(int K);
  struct TailDesc {
    long nonContiguousTail;
    Set<Long> holes;
  }
}

Appends

An AtomicLog append consists of a three step process:

1. Acquire the next free slot from the sequencer (the slot is the address)

2. Write the append value to the acquired address via the LogDrive

3. Complete the slot

The sequencer is essentially a map of: address -> {FREE, ACQUIRED, COMPLETED}, though the sequencer uses the term slot instead of address. 

Multiple addresses can be written concurrently using a windowed write discipline: the sequencer permits up to (K) appends to be in flight ahead of the contiguous log tail T. The contiguous tail is the first unwritten address and the non-contiguous tail is the lowest unwritten address after which all addresses are unwritten (or alternatively the last written address + 1).

On a completeSlot(slot) call, the sequencer blocks until all prior slots are also completed. In the figure above, we see that the window of four addresses which is being written to concurrently has holes in addresses 3 and 5. The LogDrive writes for 4 and 6 can finish out of order but their sequencer completeSlot calls cannot complete until all preceding slots have completed. Only once address 3 has been written to and completeSlot(3) is called, can address 4 complete and the contiguous tail advance to slot 5. So while writes to the LogDrive can complete out-of-order, the appends at the AtomicLog are strictly completed in address order.

checkTail

When a Loglet is unsealed, checkTail simply asks the sequencer what the tail is. This is the fast-path as the sequencer keeps all its state in memory. Should the sequencer become unavailable, then the AtomicLog can only discover the tail by inspecting log storage (slow-path). The LogDrive offers the weakTail command for this purpose.

While the AtomicLog checkTail returns a scalar contiguous tail (T) address, the LogDrive weakTail returns:

• N: the non-contiguous tail (first unwritten address after which all addresses are unwritten, or alternatively, the highest written address + 1)

• H: The holeset, the unwritten addresses within the write window.

As seen in Fig 9, the write window can create a Swiss cheese of holes at the tail of the log. The weakTail result implicitly describes the state of the write window. The write discipline maintains N − T ≤ K. Therefore, every hole lies in the address range [max(0, N − K), N), while all addresses below that range are guaranteed to be written.

The window provides concurrency while bounding the number of holes that incomplete or slow writes can create. Limiting the window size allows the tail to be recovered or checked efficiently by examining at most the last K addresses rather than scanning an unbounded address space. 

LogDrive composition

There are three main types of LogDrive:

• Primitive LogDrive: A thin interface over remote storage, such as a cloud database, KV store or object storage. For example, one might implement a DynamoDBLogDrive, or an S3LogDrive, which are thin shims.

• StripedLogDrive: A log drive with a set of child log drives where each child is a stripe. Maps addresses to stripes and performs address translation between its own address space and that of its children.

• QuorumLogDrive: Also has a set of child log drives. Each read, write, weakTail is a quorum operation over its child logdrives.

Striped and Quorum LogDrives call the LogDrive API of their children—the LogDrive API is the compositional interface. So we can compose LogDrives arbitrarily: quorums over stripes over primitives, or stripes over quorums over primitives and even over heterogenous primitives. The base of the tree must ultimately consist of primitive implementations.

read/write composition

A call to write(a, v) in the root LogDrive will flow down as calls to write(a,v) in child LogDrives, according to the type LogDrive.

A QuorumLogDrive forwards write(a, v) to its child LogDrives and waits for a write quorum (Qw). Flexible quorums apply here, where the read-quorum (Qr) is computed as N-Qw+1. So if N=3, Qw=2, then the Qr=2. If N=5, Qw=4, then Qr=2. Because the parent supplies a, every child receives the same value for the same address. Partial success can leave an address unwritten on some children, but it cannot cause their logical address assignments to diverge as independent child append calls can.

weakTail composition

The Loglet API checkTail command returns T, the contiguous tail (plus a boolean whether the Loglet is sealed). However, this is not enough for quorum composition. A single scalar value per child tail does not provide enough information for a QuorumLogDrive to compute its tail value.

The write window of each child LogDrive may individually resemble Swiss cheese of holes but when unioned together form a contiguous slice of quorum-written addresses.

Motivations Behind the Log Drive

Cheap adaptation to new storage services

A Primitive LogDrive is intended to be a thin adapter over some backing storage service such as DynamoDB, S3, or a KV store. Because it only needs to implement the small LogDrive API, a new primitive can be relatively simple, on the order of a few hundred lines of code rather than a new shared-log implementation.

Reusable composition

Striping and quorum replication live in generic StripedLogDrive and QuorumLogDrive implementations. These operate over the LogDrive API and therefore do not care whether their children are backed by DynamoDB, S3, S3 Express One Zone, or something else.

Evolving durability configurations over time

Virtual Consensus adds another useful property: different Loglets in the same VirtualLog can use different LogDrive configurations.

A log might initially use an AtomicLog backed by a singleton DynamoDBLogDrive. A later reconfiguration could extend the VirtualLog with a new AtomicLog backed by a QuorumLogDrive over several S3 Express One Zone LogDrives, perhaps spread across availability zones or regions. The old configuration remains responsible for its existing segment while new appends move to the new one, and the old segment can eventually age out as the log prefix is trimmed.

Final thoughts on Abstractions

You might be thinking that you’ve seen all these patterns before and there’s nothing groundbreaking here, and in some ways you’d be right. But what the paper contributes are the formalized abstractions.

The contribution of LogDrive is instead the abstraction: reducing durability to a numbered collection of single-value registers plus weakTail, while moving sequencing above it into AtomicLog. The interesting part is that the weaker abstraction is the more composable one. By reducing durability to its essential behavior, LogDrive provides a better building block for constructing shared logs.

Benchmarking RocksDB’s Three Amplification Factors

If you've read anything about RocksDB, LevelDB, Cassandra, or any other LSM-tree database, you've met the three amplification factors:

• Space amplification — bytes on disk ÷ bytes of live data
• Read amplification — I/O operations per logical read
• Write amplification — bytes written to disk ÷ bytes your application handed over

They're always presented the same way: three tidy definitions, a sentence about how tuning is a tradeoff between them, and a link to the official tuning guide. Which says, memorably:

"Unfortunately, configuring RocksDB optimally is not trivial. Even we as RocksDB developers don't fully understand the effect of each configuration change. If you want to fully optimize RocksDB for your workload, we recommend experiments and benchmarking, while keeping an eye on the three amplification factors."

That's the RocksDB team telling you to go measure. Almost nobody does.

So I did. Everything below is measured on one machine, with code you can run. The numbers are less interesting than what it took to get them honest — I'll get to the three benchmarks that fooled me first.

Setup: Apple M4 Pro (14 cores, 48 GB), macOS 26.6, RocksDB via the rocksdict Python bindings 0.3.29. 113-byte records (13-byte key, 100-byte value). Compression disabled throughout — I want to measure amplification, not LZ4's opinion of it. All numbers come from RocksDB's own statistics counters (rocksdb.flush.write.bytes, rocksdb.compact.write.bytes, rocksdb.bloom.filter.useful) and from du-style walks of the database directory.

This is a laptop, not a server. Absolute latencies are warm-page-cache numbers and would look very different on a loaded machine with cold storage. The shapes of the curves are the point, not the absolute values.

1. Deleting half the keys made the database bigger

The theory: a delete in an LSM-tree isn't a delete. It's a write — a tombstone record marking the key as gone. The original value stays on disk until compaction merges it away, and the tombstone itself can generally only be dropped at the bottommost level, because dropping it earlier would let an older value on a lower level resurrect.

So deleting data should temporarily increase disk usage. Here's what it actually looks like:

I wrote 1,000,000 keys — 107.8 MB of logical data, 111.5 MB on disk, a very tidy 1.04× space amplification. Then I deleted every other key.

Live data drops in a straight line: 107.8 MB → 53.9 MB. Disk usage goes the other way, climbing to a peak of 127.6 MB while only 80.8 MB of it was live — a space amplification of 1.58×. I had deleted 250,000 keys and gained 16 MB.

The sawtooth is compaction fighting back. Each cliff is a compaction pass reclaiming space; each climb between them is tombstones accumulating faster than compaction retires them. After forcing a full compaction at the end: 56.0 MB on disk for 53.9 MB of data. Back to 1.04×.

The practical version: if you run a delete-heavy workload and watch a disk-usage graph, the spike is not a bug and disk usage is a lagging indicator of what you actually store. If you're near a disk threshold, a bulk delete is the last thing that will save you in the next five minutes.

2. Every L0 file costs a lookup another microsecond

Level 0 is the odd level out. Files there are direct memtable dumps, so their key ranges overlap, so a lookup can't know which one holds the key — it has to check all of them, newest first. Levels 1 and below are partitioned into non-overlapping ranges, so one file per level suffices.

That means read cost should grow linearly in the number of L0 files. I turned off auto-compaction and built L0 by hand, one SST at a time, measuring get() latency for keys that live only in the oldest file — the worst case, since every newer file has to be ruled out first.

With bloom filters off, it's about as clean a straight line as you'll get from a real system: 1.29 µs at one L0 file, 23.29 µs at 24 — roughly 0.96 µs of added latency per file, an 18× degradation.

With bloom filters on (10 bits/key), the same workload goes 1.38 µs → 2.54 µs. The filter absorbs essentially the whole thing. The rocksdb.bloom.filter.useful counter climbs to 139,637 rejections over the last generation's probes, which is the filter turning "read the index, decompress a block, scan it, find nothing" into a few hundred nanoseconds of bit-checking, 23 times per lookup.

The practical version: the default level0_file_num_compaction_trigger of 4 is not arbitrary — it's a cap on exactly this. And bloom filters aren't a nice-to-have for negative lookups; they're what keeps L0 from being a linear scan.

3. The same 2 million writes cost 4.4× more in random order

Write amplification is the one you pay for the other two. Compaction reclaims space and keeps reads fast by rewriting data it has already written, sometimes many times over as records migrate down the levels.

I wrote 2,000,000 keys (216 MB of application data) and tracked what RocksDB actually put on disk.

With random keys: flush wrote 223.7 MB, compaction wrote 758.3 MB. Total 982 MB of disk writes for 216 MB of data — 4.56× write amplification, still climbing when the run ended. Forcing a full compaction afterward pushed it to 5.61×.

With sequential keys: 222.8 MB from flush, and compaction wrote exactly zero bytes. Write amplification 1.03×.

That zero is the interesting number. Ascending keys produce SSTs whose key ranges don't overlap anything, so RocksDB places each flushed file directly at a deep level and never needs to merge it. No merging, no amplification.

This is a real and useful optimization — it's why bulk-loading sorted data into RocksDB is so fast. It's also a trap, because it means every benchmark that inserts sequential keys reports write amplification that a production workload will never see. If you've seen a "RocksDB writes 1.0× " claim, check the key order.

4. One knob, and it isn't the important one

Now the tradeoff. level0_file_num_compaction_trigger controls how many L0 files accumulate before compaction fires. Low means eager compaction: more write amplification, less of everything else. High means lazy. That's the theory, anyway.

I swept it from 1 to 64 against an identical workload (800k random writes, 200k overwrites, 100k deletes) and measured all four consequences. Then I ran the whole sweep a second time with background I/O throttled to 16 MB/s, to simulate a server where compaction is disk-bound rather than free.

When compaction keeps up (blue), the theory holds — for exactly one metric. Write amplification falls 6.29× → 2.83× as the trigger goes from 1 to 8, then flattens (it bottoms out at 2.76× and stays there). Space amplification moves the opposite way, 1.58× → 1.75×. Read latency and throughput barely budge.

Why does it flatten? Because L0 never exceeded 5 files regardless of the setting. On 14 cores with a fast SSD, compaction drains L0 continuously, so a trigger of 8 and a trigger of 64 describe a threshold that is never reached. The knob stops existing.

When compaction is disk-bound (orange), everything changes at once, and the trigger becomes noise:

Throughput drops by 2.8×. Space amplification nearly doubles. And the run accumulates eight to ten seconds of write stalls — RocksDB deliberately throttling the application because L0 is backed up.

Note the counterintuitive bit: write amplification drops to 1.7–2.1× in the disk-bound runs. That isn't an improvement. The compaction work simply hadn't happened yet when I measured. It's debt, not savings.

The practical version: I went looking for a clean three-way tradeoff dial and found something more useful. The L0 trigger is a real knob with a real, monotonic effect on write amplification — within the regime where compaction can keep up. Whether compaction can keep up is decided by your I/O budget, not by this setting, and it dominates all three amplification factors put together. Tune your compaction throughput before you tune your compaction thresholds.

Three benchmarks that lied to me

This is the part I'd most want to read in someone else's post, so: three of my first four experiments produced clean, plausible, completely meaningless results. All three failure modes are things RocksDB does right, which is exactly why they're easy to miss.

1. Disjoint key ranges made read amplification vanish. My first read-amp benchmark had each generation write a distinct ascending key range: generation 0 wrote keys 0–49,999, generation 1 wrote 50,000–99,999, and so on. Latency came out perfectly flat — 1.5 µs whether there was 1 L0 file or 24 — and rocksdb.bloom.filter.useful dropped to zero after the third generation.

Every SST stores its minimum and maximum key. RocksDB checks that range before consulting a bloom filter or reading an index. My generations were disjoint, so 23 of 24 files were excluded on range alone, for free. I had accidentally built the best case and measured it.

The fix: every generation now writes two sentinel keys at the extremes of the keyspace, forcing all L0 files to span the full range so none can be skipped. That's also what a realistic random-write workload looks like.

2. Sequential inserts made write amplification vanish. Covered above, but it bears repeating as a benchmarking lesson: my first write-amp run reported 1.03× with compaction doing literally zero bytes of work. I nearly published that as "write amplification is overstated." It was 4.56× the moment I randomized key order.

3. Waiting for quiescence erased the entire tradeoff. My first version of the sweep called "wait for compaction to finish" before measuring, because that seemed like the clean, reproducible thing to do. Every single trigger setting converged to identical space amplification (1.40–1.46×) and identical read latency. Of course they did — I was measuring seven configurations after removing the only difference between them. L0 was zero everywhere.

Compaction settings only manifest under load. Measuring a database at rest tells you about the compactor, not the configuration.

The common thread: RocksDB is full of optimizations that make naive benchmarks look great. Range-based file skipping, direct-to-deep-level placement, background compaction that catches up the instant you stop writing. If your benchmark result is suspiciously clean, you have probably measured a fast path rather than your workload.

What I'd actually take away

• Measure under load, at steady state, with your key distribution. Key order alone moved write amplification by 4.4×. No amount of config tuning is worth as much as benchmarking the access pattern you actually have.
• Deletes are writes, and disk usage lags reality. Plan capacity for the peak during a bulk delete, not the trough after it.
• Bloom filters are load-bearing. 18× read degradation without, 1.8× with, on identical data.
• Compaction throughput dominates compaction thresholds. Starving background I/O cost 3× throughput, doubled space amplification, and produced ten seconds of write stalls — while the knob I was actually studying moved nothing.
• Write amplification going down is not always good news. Sometimes it means compaction is behind and you're looking at deferred work.

And the meta-lesson, which is really just the tuning guide's advice with receipts attached: the RocksDB developers weren't being modest when they said they can't predict the effect of a config change. I couldn't reliably predict the effect of four config changes on a laptop, in a controlled experiment, with the statistics counters right in front of me. Benchmark your own workload.

Run it yourself

All four experiments, the chart code, and the raw JSON results are here:

bench/exp1_space_amp.py     # write 1M, delete 500k, watch disk climb
bench/exp2_read_amp.py      # L0 files 1 -> 24, bloom on/off
bench/exp3_write_amp.py     # random vs sequential key order
bench/exp4_tradeoff.py      # trigger sweep x compaction I/O budget
bench/plot.py               # charts

Each script is self-contained, seeded, and takes under a minute. Run them, disagree with me, and tell me what your hardware says — the interesting result here isn't any single number, it's how easily a benchmark can produce a confident wrong one.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

Khaos: Kafka Load Testing & Chaos Engineering

Khaos is an open-source Kafka traffic generator, load-testing tool, and chaos engineering CLI for reproducing realistic Kafka workloads and failure scenarios (consumer lag, hot partitions, rebalances, and broker failures) on demand, instead of waiting for production to find them.

Documentation · Quick Start · Scenario Reference

What it does

• Generate realistic Kafka test data: structured, faker-backed records in JSON, Avro, or Protobuf.
• Simulate producer and consumer traffic: configurable throughput, key distributions, and consumer group topology.
• Load test Kafka clusters and the applications that consume from them, including Kafka Streams and Flink jobs.
• Reproduce failure conditions on purpose: consumer lag, hot partitions, rebalances, and broker failures, scheduled on a timeline.

Scenarios are plain YAML. No code, no client library, no instrumentation in the system under test.

Quick start

go install github.com/aleksandarskrbic/khaos/cmd/khaos@latest

khaos list                          # see the bundled scenarios
khaos run traffic/high-throughput   # auto-starts a local 3-broker Kafka cluster

khaos run manages its own local Kafka cluster via Docker Compose. To target a cluster you already have, including managed clusters needing SASL/SSL, use khaos simulate instead. See the Quick Start guide and Installation for release binaries and Docker.

A few scenarios

khaos run traffic/hot-partition       # skewed key distribution overloads one partition
khaos run traffic/consumer-lag        # producer rate outpaces slow consumers
khaos run chaos/broker-chaos          # brokers stop and restart while traffic keeps flowing
khaos run chaos/rebalance-storm       # a consumer group rebalances repeatedly

khaos validate checks a scenario file's structure without running it: the same command Khaos's own CI runs against every bundled scenario. See the Scenarios and Guides sections of the docs for what each one actually configures and why.

Documentation

Full documentation, including the CLI reference, the scenario YAML schema, and guides for load testing, data generation, and each failure scenario, lives at getkhaos.dev/docs:

• Kafka Load Testing
• Kafka Data Generation
• Consumer Lag Testing
• CLI Reference
• Scenario File Reference

Architecture

Khaos is a single Go binary. The scenario engine is independent of any user interface: it exposes one read method, Snapshot(), and the terminal UI, the headless log loop, and the final summary table all poll it. Nothing in the engine knows about terminals, so a headless run in CI behaves identically to an interactive one, and a stalled UI can't stall a run.

Kafka access is franz-go, a pure-Go client, which is what makes CGO_ENABLED=0, cross-compilation, go install, and a distroless/static image all work without a C toolchain. See the Concepts page for the full picture.

Rewritten in Go

Khaos was rewritten from Python to Go: a single static binary, no runtime dependencies, and a pure Go Kafka client that cross-compiles cleanly. See the release notes for details.

Contributing

Issues and pull requests are welcome. If Khaos is useful to you, a star helps others find it.

License

Apache 2.0.

Well, truth be told these are not all that new (couple of months), but I finally have gotten around to research it.

So, let's see what's what. For starters I need some test data. Luckily, I have explain.depesz.com DB…

Extracted all plans to side table, with this structure:

=$ \d all_plans
            Table "public.all_plans"
 Column | Type | Collation | Nullable | Default 
--------+------+-----------+----------+---------
 id     | text |           | not null | 
 plan   | text |           |          | 
Indexes:
    "all_plans_pkey" PRIMARY KEY, btree (id)

In total, there are 1.6 million rows there, with average length of 22kB, max length (of plan) ~ 9.5MB, and total length of all plans around 33GB.

First test case is word “sususu". I picked this string as it is uncommon (only 93 plans with it).

Original Pg, with no magic:

=$ explain (analyze on, buffers on, costs off) select count(*) from all_plans  where plan ~ 'sususu';
                                              QUERY PLAN
───────────────────────────────────────────────────────────────────────────────────────────────────────
 Finalize Aggregate (actual time=41431.824..41442.352 rows=1.00 loops=1)
   Buffers: shared hit=2007647 read=941087
   ->  Gather (actual time=41367.015..41442.322 rows=3.00 loops=1)
         Workers Planned: 2
         Workers Launched: 2
         Buffers: shared hit=2007647 read=941087
         ->  Partial Aggregate (actual time=41391.421..41391.422 rows=1.00 loops=3)
               Buffers: shared hit=2007647 read=941087
               ->  Parallel Seq Scan on all_plans (actual time=1591.041..41391.268 rows=31.00 loops=3)
                     Filter: (plan ~ 'sususu'::text)
                     Rows Removed by Filter: 541276
                     Buffers: shared hit=2007647 read=941087
 Planning Time: 0.305 ms
 Execution Time: 41442.639 ms
(14 rows)

OK. So we see that it took ~ 40 seconds, it was 3-way parallel seq scan.

Great. Luckily we know that we can optimize it using pg_trgm:

=$ create extension pg_trgm;
CREATE EXTENSION
 
=$ create index trgm_idx on all_plans using gin (plan gin_trgm_ops);
CREATE INDEX
Time: 1007956.846 ms (16:47.957)
 
=$ select pg_size_pretty( pg_relation_size('trgm_idx'::regclass));
 pg_size_pretty 
----------------
 1667 MB
(1 row)

That took a while….

But now:

=$ explain (analyze on, buffers on, costs off) select count(*) from all_plans  where plan ~ '(su){3}';
                                        QUERY PLAN                                         
-------------------------------------------------------------------------------------------
 Aggregate (actual time=1615.599..1615.600 rows=1.00 loops=1)
   Buffers: shared hit=6038 read=29131
   ->  Bitmap Heap Scan on all_plans (actual time=38.302..1615.518 rows=93.00 loops=1)
         Recheck Cond: (plan ~ '(su){3}'::text)
         Rows Removed by Index Recheck: 2879
         Heap Blocks: exact=2884
         Buffers: shared hit=6038 read=29131
         ->  Bitmap Index Scan on trgm_idx (actual time=1.829..1.830 rows=2972.00 loops=1)
               Index Cond: (plan ~ '(su){3}'::text)
               Index Searches: 1
               Buffers: shared hit=9 read=21
 Planning:
   Buffers: shared read=1
 Planning Time: 0.365 ms
 Execution Time: 1615.620 ms
(15 rows)

Nice. 1.6 second, used index.

Now. For the new stuff.

First, is pg_tre, with initial (well, at least for me) announcement here.

Installation is somewhat trivial:

=$ git clone --recurse-submodules https://codeberg.org/gregburd/pg_tre.git
=$ cd pg_tre
=$ make
=$ sudo make install

and then, in DB:

=$ CREATE EXTENSION pg_tre;
CREATE EXTENSION
 
=$ CREATE INDEX plan_tre ON all_plans_tre USING tre (plan);
NOTICE:  pg_tre: collected 1701834577 trigram entries from 1623920 heap tuples
NOTICE:  pg_tre: built 755269 posting trees
NOTICE:  pg_tre: built range tier with 1407 ranges across 47 pages
NOTICE:  pg_tre: build complete, indexed 1623920 heap tuples into 755269 trigrams
CREATE INDEX
Time: 26127621.037 ms (07:15:27.621)

OH. MY. $DEITY. 7 hours. And how about size?

=$ select pg_size_pretty( pg_relation_size('plan_tre'::regclass));
 pg_size_pretty
────────────────
 21 GB
(1 row)

You might have noticed that I changed table name – it's identical to all_plans, but I made a copy so I can test all approaches at the same time.

So. Let's see if the new index is fast…

=$ explain (analyze on, buffers on, costs off) SELECT * FROM all_plans_tre WHERE plan %~~ tre_pattern('su{3}', 0);
                                     QUERY PLAN
────────────────────────────────────────────────────────────────────────────────────
 Bitmap Heap Scan on all_plans_tre (actual time=2.182..2292.506 rows=85.00 loops=1)
   Recheck Cond: (plan %~~ 'su{3}'::tre_pattern)
   Rows Removed by Index Recheck: 357
   Heap Blocks: exact=431
   Buffers: shared hit=5967
   ->  Bitmap Index Scan on plan_tre (actual time=0.132..0.132 rows=442.00 loops=1)
         Index Cond: (plan %~~ 'su{3}'::tre_pattern)
         Index Searches: 0
         Buffers: shared hit=7
 Planning:
   Buffers: shared hit=14
 Planning Time: 0.135 ms
 Execution Time: 2292.584 ms
(13 rows)

Well, it's faster than seq scan, but it's not as fast as trigram. BUT, docs say this:

Where pg_tre is not the answer
Exact substring / LIKE: pg_trgm is battle-tested and ships with every PG install. Use it.

My search was clearly very simplistic. So let's try something more “fun":

=$ explain (analyze, buffers, costs off) select * from all_plans  where plan ~ '(?<=e.)aa[bc]c[b-d]';
                                     QUERY PLAN
─────────────────────────────────────────────────────────────────────────────────────
 Bitmap Heap Scan on all_plans (actual time=124.424..39356.809 rows=40.00 loops=1)
   Recheck Cond: (plan ~ '(?<=e.)aa[bc]c[b-d]'::text)
   Rows Removed by Index Recheck: 5137
   Heap Blocks: exact=5005
   Buffers: shared hit=19212 read=103648
   ->  Bitmap Index Scan on trgm_idx (actual time=7.965..7.966 rows=5177.00 loops=1)
         Index Cond: (plan ~ '(?<=e.)aa[bc]c[b-d]'::text)
         Index Searches: 1
         Buffers: shared hit=177
 Planning:
   Buffers: shared hit=1
 Planning Time: 1.789 ms
 Execution Time: 39356.895 ms
(13 rows)

But I can't use this regexp for tre:

=$ explain (analyze, buffers, costs off) select * from all_plans_tre  where plan %~~ tre_pattern('(?<=e.)aa[bc]c[b-d]');
ERROR:  pg_tre: invalid regex pattern:

Interestingly, it seems to have an error in message, as it ends with :, but there is nothing afterwards.

So, what good is it for?

Well, apparently it has support for fuzzy matching built-in.

For example:

=$ select word from word_stats where word  %~~ tre_pattern('postgresql', 1);
                word
────────────────────────────────────
 autopostgresqlbackup
 metadatapostgresqlserver
 rpostgresql
 inpostgresql
 postgresl
 postgresml
 postgresql
 Postgresql
 PostgresqlDatabaseServices
 postgresqlmatches
 postgrestls
 postgresxl
 usrpostgresplanif
 InternalPostgresqlDatabaseServices
 libpostgresql
 VRTSpostgresql
(16 rows)

The number at the end is related to Levenshtein distance. So it can do pretty cool things. I think that using this on list of words, and then extracting using normal trigram could be great:

=$ EXPLAIN ( analyze, buffers, costs off)
WITH re AS (
    SELECT
        string_agg(
            word,
            '|'
        ) AS ex
    FROM
        word_stats
    WHERE
        word %~~ tre_pattern(
            'postgresql',
            1
        )
)
SELECT
    *
FROM
    all_plans
WHERE
    plan ~ (
        SELECT
            re.ex
        FROM
            re
    );
                                                 QUERY PLAN
────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Bitmap Heap Scan on all_plans (actual time=684.096..9993.531 rows=846.00 loops=1)
   Recheck Cond: (plan ~ (InitPlan 1).col1)
   Rows Removed by Index Recheck: 12951
   Heap Blocks: exact=12946
   Buffers: shared hit=28794 read=94765
   InitPlan 1
     ->  Finalize Aggregate (actual time=638.129..638.264 rows=1.00 loops=1)
           Buffers: shared read=14464
           ->  Gather (actual time=629.474..638.250 rows=3.00 loops=1)
                 Workers Planned: 2
                 Workers Launched: 2
                 Buffers: shared read=14464
                 ->  Partial Aggregate (actual time=619.772..619.773 rows=1.00 loops=3)
                       Buffers: shared read=14464
                       ->  Parallel Seq Scan on word_stats (actual time=309.658..619.756 rows=5.33 loops=3)
                             Filter: (word %~~ 'postgresql@1'::tre_pattern)
                             Rows Removed by Filter: 800091
                             Buffers: shared read=14464
   ->  Bitmap Index Scan on trgm_idx (actual time=680.737..680.737 rows=13797.00 loops=1)
         Index Cond: (plan ~ (InitPlan 1).col1)
         Index Searches: 1
         Buffers: shared hit=693 read=15219
 Planning:
   Buffers: shared hit=1
 Planning Time: 2.671 ms
 Execution Time: 9994.121 ms
(26 rows)

In here I searched through list of words to find the ones that kinda look like postgresql, and then built (not in safe way, but it's just test) regexp that matches any of them, and then used trigram index for search. Not bad.

Anyway. I think that while it might have some uses, currently there are some rough edges that will require more work. But it definitely looks interesting…

So, let's look at pg_re2.

Installation is pretty simple:

=$ sudo apt-get install libre2-dev
=$ sudo pgxnclient install re2

And then you can:

=$ create extension re2;
CREATE EXTENSION

Sweet. Now, we can try it:

=$ explain (analyze on, buffers on, costs off) SELECT * FROM all_plans_re2 WHERE plan @~ '(su){3}';
                                          QUERY PLAN
───────────────────────────────────────────────────────────────────────────────────────────────
 Gather (actual time=247.527..23113.592 rows=93.00 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   Buffers: shared hit=2007641 read=941087
   ->  Parallel Seq Scan on all_plans_re2 (actual time=1067.656..23075.232 rows=31.00 loops=3)
         Filter: (plan @~ '(su){3}'::text)
         Rows Removed by Filter: 541276
         Buffers: shared hit=2007641 read=941087
 Planning Time: 0.290 ms
 Execution Time: 23113.893 ms
(10 rows)

What?! 23 seconds? Scan, without index, using normal ~ operator, built-in Pg, took a bit over 40 seconds?! I tested it couple of times, and confirmed the result.

So, let's add custom re2 index:

=$ CREATE INDEX re2idx ON all_plans_re2 USING gin (plan gin_re2_ops);
CREATE INDEX
Time: 898682.472 ms (14:58.682)
 
=$ select pg_size_pretty( pg_relation_size('re2idx'::regclass));
 pg_size_pretty
────────────────
 2927 MB
(1 row)

So, making the index took less time than trigram index, and it's almost 2x the size of trigram index. So, how does it behave?

=$ explain (analyze on, buffers on, costs off) SELECT * FROM all_plans_re2 WHERE plan @~ '(su){3}';
                                     QUERY PLAN
─────────────────────────────────────────────────────────────────────────────────────
 Bitmap Heap Scan on all_plans_re2 (actual time=21.121..958.796 rows=93.00 loops=1)
   Recheck Cond: (plan @~ '(su){3}'::text)
   Rows Removed by Index Recheck: 2879
   Heap Blocks: exact=2884
   Buffers: shared hit=6033 read=29142
   ->  Bitmap Index Scan on re2idx (actual time=19.322..19.323 rows=2972.00 loops=1)
         Index Cond: (plan @~ '(su){3}'::text)
         Index Searches: 1
         Buffers: shared hit=10 read=21
 Planning:
   Buffers: shared read=1
 Planning Time: 0.368 ms
 Execution Time: 958.857 ms
(13 rows)

Pretty cool. It's significantly faster than trigram. What about more complex regexp?

=$ explain (analyze on, buffers on, costs off) SELECT * FROM all_plans_re2 WHERE plan @~ '(^|^.|[^e].)aa[bc]c[b-d]';
                                      QUERY PLAN
──────────────────────────────────────────────────────────────────────────────────────
 Bitmap Heap Scan on all_plans_re2 (actual time=24.061..2267.620 rows=376.00 loops=1)
   Recheck Cond: (plan @~ '(^|^.|[^e].)aa[bc]c[b-d]'::text)
   Rows Removed by Index Recheck: 4801
   Heap Blocks: exact=5005
   Buffers: shared hit=11775 read=111084
   ->  Bitmap Index Scan on re2idx (actual time=11.902..11.903 rows=5177.00 loops=1)
         Index Cond: (plan @~ '(^|^.|[^e].)aa[bc]c[b-d]'::text)
         Index Searches: 1
         Buffers: shared hit=72 read=104
 Planning:
   Buffers: shared read=1
 Planning Time: 0.449 ms
 Execution Time: 2267.799 ms
(13 rows)

This regexp should be functionally the same as plan ~ ‘(?<=e.)aa[bc]c[b-d]', and it does return the same number of rows. In ~ 50% of the time!

Why can't I use (?<=…? It's limitation of re2 library. To make it fast certain things have been removed.

All things said – there is some interesting work related to regular expressions in PostgreSQL. Some of it already provides great results. Some of it looks more like promise for bright future. But still, it does look interesting…

Full article content is not available for inline reading.

Read the original article →

The ledger of design

In software and product development, the ledger of work is not a new concept. Software developers have used Source Code Management (SCM) tools for decades to track and memorialize decisions of work. There are also tools such as Jira that are a System of Record (SOR) that capture work. Despite various systems existing, Design hasn’t made progress on recording their work.

The artifacts for design have changed with AI. As a result, the ledger and proof of work has evolved. It’s no longer only documented artifacts such as mockups, diagrams, and decks to prototypes and living systems of code. One of the classic team challenges is visibility of work. Historically, it’s been difficult to find progress and proof of work because the immense effort it took. AI significantly solved this problem with search and retrieval, but there is a new problem as as result of AI. Now there is the abundance and slop problem. When teams can produce more work at higher volume, the process behind the work becomes easier to hide and harder to validate. Finished-looking outputs are cheaper now, which means credibility has to come from more than the finish.

Ledgers for various roles

This norm looks different across roles: individual contributors, managers, and even agents.

Contributors

AI can generate options, drafts, variations, and first passes, so the existence of an artifact no longer says as much as it used to. The stronger signal is how the contributor gathered context, shaped the problem, evaluated the options, and selected the final direction.

The quality of the artifact matters more, not less. When output is cheap, taste becomes more visible. A strong contributor can show the thinking that led to the work: the context they pulled in, the constraints that mattered, the prompts they used, the tools they created, and the directions they rejected along the way. The final deck, document, design, or code is only part of the proof. The rest is the judgment that explains why this version deserved to exist.

A contributor might create a prompt pattern, build a reusable skill, improve a workflow, or package a method so others can use it. That contribution is easy to miss if we only inspect the finished output. The best people will scale the systems along with their work.

Managers

The pressure is increasing for managers to have a ledger of their work. Much of the visible surface area of management is being compressed: meeting summaries, status updates, follow-up notes, planning documents, and context sharing. Those tasks still matter, but they no longer explain the value of the role. A good-looking plan can still be poorly reasoned.

The ledger has to move from activity to rationale. If everyone can ask an AI system for five plausible strategies, the manager’s contribution is not that they found an option. It is that they chose a direction and can explain why that direction is right for this team, this moment, this constraint. The decision trail becomes the proof. What was considered? What was rejected? What tradeoff was made? What risk was accepted? What would change the decision later? As iteration speeds up, teams produce more material than any one person can hold.

The manager’s job is to make the work legible: where the team is going, why it matters, what has changed, and what still needs human judgment. Management becomes less about being the source of every answer and more about creating the context that makes the right answer easier to recognize.

Agents

Ledgers are also important for agents, arguably more because agentic work requires human approval. A human has to be confident knowing what has been done. If agents operate across the toolchain of email, calendars, documents, browsers, and internal systems, users need to see what the agent was asked to do, what it accessed, what it read, what it changed. This is the most important trust layer for agentic work.

Instinct showed what happens when that layer is missing. During launch week, users found the agent had indexed and retained their email with no way to delete it. Access could be revoked; what had already been ingested stayed invisible. I’m confident the team will commit to improve the legibility of their agents work, but this is a lesson on how important visibility of work is that could errode trust.

GrokBot has a feature where a user can see the persistent cloud machine with a real browser, filesystem, and terminal, so the work happens somewhere you can point to. But every bot shares that machine, along with one credential pool and one set of browser sessions. xAI’s own documentation tells you not to treat separate bots as a security boundary. The product called its shared computer “a real blast radius.” Retention is undocumented, the audit view is promised but not shipped, and deleting a bot may not clear its files or sessions. You can see where the work happened. You cannot scope it, review it, or take it back.

That is the shape of agent credibility: visible execution, scoped access, reviewable history, reversible actions. The four are not interchangeable, and a product can nail one while failing the rest. If agents are going to be collaborators, they need what human work needs: a trail of context, action, and accountability.

Build the ledger

A useful ledger has to be easy to capture, or it becomes bureaucracy. The trace should come from tools people already use: documents, commits, prompts, agent runs, decisions, artifacts. If capture takes effort, it turns into after-the-fact performance.

It also has to be useful to review. A ledger that records everything clarifies nothing. Keep what someone would need to understand how the artifact came to be: what changed, why, who approved it, what evidence held. Where did this come from? What generated it? What did a human change? The wrong version of this is surveillance. The right version shows where judgment was applied and who stands behind the result.

Build the ledger around your work: the context, the decisions, the toolchain, the approvals, the artifact. Then hand someone the finished piece and ask them how it got made. If they can answer, you have one.

The first version of ChatGPT memory was a simple notepad the model could read from, write to, and edit across conversations. The hard part was not the interface, but training the decision boundaries for what is worth saving and when to recall it. Most current memory implementations still over-apply what they know, which makes productive forgetting the missing capability.

Z.ai revealed that the anonymously tested ox-alpha was GLM-5.3-Flash, a 320B-parameter MoE model with 18B active parameters that approached Claude Opus 4.8 on coding and agentic benchmarks.

Key Points

• Salesforce and Anthropic on Wednesday expanded their strategic partnership and unveiled "Claudeforce," a new way for salespeople to work within Anthropic's product.
• The announcement marks the first time that Salesforce has ever added its "force" suffix at the end of another company's product.
• "We're delivering a dynamic interface that thinks, reasons, and acts," Salesforce CEO Marc Benioff said in a statement.

Salesforce and Anthropic on Wednesday expanded their strategic partnership and unveiled "Claudeforce," a new way for salespeople to access critical data directly from inside Anthropic's Claude chatbot.

Claudeforce is launching as a plugin with 37 pre-built sales skills that will allow Claude users to compose emails, update records and take other relevant actions, according to a release. The companies said they plan to introduce more integrations across Claude, Salesforce and its messaging platform Slack in the future.

"It's really a first in the industry," Salesforce CEO Marc Benioff told CNBC's Jim Cramer on Wednesday. He was joined by Anthropic CEO Dario Amodei in a joint interview at the top of Salesforce Tower in San Francisco. "It's completely exciting. I think that this is the way all enterprise systems are going to run in the future."

Wednesday's announcement marks the first time that Salesforce has ever added its "force" suffix to the end of another company's product name.

Salesforce and its software peers have been under pressure as investors question whether AI tools from companies like Anthropic and OpenAI will replace them. Salesforce shares are down about 22% this year after dropping 20% in 2025. The Nasdaq, meanwhile, is up about 35% since the end of 2024.

Shares of Salesforce rose 12% in extended trading on Wednesday, after the company announced the partnership and reported fiscal second quarter results that beat Wall Street's expectations.

Anthropic primarily sells its Claude models and products to other businesses and has experienced a period of explosive growth this year. The company recently told investors that its annualized revenue run rate hit $65 billion at the end of July, a sevenfold increase from a year ago.

Amodei told CNBC on Wednesday that Anthropic put a "huge amount of effort" into managing permissions for Claudeforce. He said the two companies are building "Enterprise Frontier Safeguards" to ensure that Salesforce's customer data remains private, and that Anthropic's models "don't run out of control."

Amodei added that Claudeforce has already been useful for many of Anthropic's own employees.

"Within Anthropic, for a long time we've been accelerating the research teams within Claude, but this is the first time that we've really been able to incredibly accelerate our go-to-market efforts within Claude," he said.

Claudeforce is available to a select group of pilot customers, and it will launch in a preview capacity next month, the companies said. Additional pre-built skills will be available later this year.

Chinese AI lab Z.ai has come forward to claim the viral anonymous Ox Alpha model.

On Wednesday, Z.ai unveiled GLM-5.3-Flash, the first natively multimodal model of the GLM-5 series. The company said the model was released anonymously as Ox Alpha on OpenCode and OpenRouter where it completely overtook leaderboards and went viral for offering a capacity for 100 trillion tokens per day.

Notably, the company said in its announcement that all of the traffic from its model's skyrocketing popularity was "served on Chinese AI chips."

The model features 320 billion total parameters with 18 million active, and outperforms its previous generation, GLM-5.2, across a number of benchmarks at a tenth of the price, the company said in its announcement.

The lab also claims that GLM-5.3-Flash approaches Claude Opus 4.8 in coding and agentic benchmarks. It also performs on par with DeepSeek-V4, GPT-5.6 Terra, and Gemini 3.7 Flash on benchmarks for software engineering, multi-step agentic tasks, tool use and professional work.

The company said the model is architected for "extreme efficiency," and "specifically designed for ultra-low-cost inference."

• GLM-5.3-Flash was essentially designed to do more with less, the company said, using a hybrid attention architecture to reduce the cost of serving long-context queries without sacrificing accuracy.
• Additionally, the model is built to improve "scaling efficiency" by implementing what are called "Manifold-Constrained Hyper-Connections," or a technique that improves the way that information moves through the layers of a neural network.
• The model weights are currently available on Hugging Face. The model is also powering ZCode, Z.ai's coding tool.

"GLM-5.3-Flash shows that frontier intelligence does not have to come at frontier cost," the company said in its announcement. "We are now scaling this recipe to larger models — GLM-5.3-Flash pushes the cost-performance frontier, and the lessons from building it are already shaping our next frontier model."

Z.ai's Ox Alpha win comes at a particularly poignant moment for open models: Open source model platform Hugging Face is reportedly fielding acquisition offers that value the company at $13 billion, and Nvidia last week announced a $6 billion investment in bolstering the open source AI ecosystem in the US.

But Chinese firms may be going after one enterprise pain point in particular: token costs. Models from Chinese labs that perform on-par with those from proprietary providers may be enticing to developers that are now facing budget constraints after previously being encouraged to spend freely on AI, Karthik Sj, chief AI officer at LogicMonitor, told The Deep View.

"Ox Alpha demonstrates how low- and zero-cost model access may sound appealing at first, but free access always carries hidden costs," said Sj. "While Z.ai revealing that it’s behind the model solves some auditability concerns, vetted and well-tested models are the safer bet.”

Our Deeper View

Though it's obvious that Z.ai is targeting cost and resource efficiency with its release of GLM-5.3-Flash, this model's popularity also points to another trend: not every daily use model needs to be state-of-the-art. GLM-5.3-Flash still sits on-par or just behind the frontier models from labs like Anthropic, Google and OpenAI, however, a model doesn't need to be ultrapowerful to be incredibly useful. Though OpenAI is trying to entice people to use its frontier models with lower prices, it can only serve that kind of inference at those costs for so long. For a large majority of enterprise tasks, generally, mid-range performance is good enough, especially when it comes to solving for ROI.

Meta's Muse Image model can generate images grounded by search. It can reason before it renders. The model is priced for production volumes at $0.01 per image. Real-world examples of Muse Image workflows are available in the link.

• Anthropic has reached a roughly $45 billion cloud deal with Nscale, CNBC confirmed.
• Anthropic will rent around 460 megawatts of compute capacity at an Nscale data center development in West Virgina, according to sources.
• The company has inked several infrastructure deals this year as it works to increase its computing capacity.

Anthropic has inked a roughly $45 billion cloud deal with Nscale, a UK-based artificial intelligence infrastructure company, CNBC confirmed on Wednesday.

As part of the agreement, Anthropic will rent around 460 megawatts of compute capacity at an Nscale data center development in West Virgina, according to two people with knowledge of the matter who asked not to be named because the details are confidential. Anthropic will leverage Nvidia's advanced Vera Rubin chips through the facility, which is expected to come online at the end of 2027, the people said.

Bloomberg was first to report on the deal.

Anthropic said earlier this year that growing demand for its Claude AI models and products has caused "inevitable strain" on its infrastructure, which impacted "reliability and performance" for its users, especially during peak hours. It's announced a flurry of deals with infrastructure partners in the months following to try and increase its computing capacity, including major agreements with Advanced Micro Devices, Elon Musk's SpaceX, Google and Broadcom.

Anthropic confidentially filed its IPO prospectus with the Securities and Exchange Commission in June, and has been engaging in preliminary meetings with prospective investors.

The company is under pressure to justify its $965 billion valuation to investors, especially as it faces increasingly stiff competition from rivals like OpenAI and Google. Its infrastructure strategy will be central to its roadmap and its story to Wall Street.

Google is reportedly in advanced talks to license technology and hire staff from AI startup Mechanize in a deal valued at more than $1.5 billion, according to Business Insider.

The agreement would give Google access to Mechanize's technology and bring some of its employees into the company.

If completed, the deal would expand Google's investment in AI coding as competition with Anthropic, OpenAI, and Meta moves from chatbots to agents that can handle real software development tasks.

Google and Mechanize declined to comment, and no completed agreement has been publicly announced.

Google's Reported Mechanize Deal and AI Coding Push

Business Insider reported that Google was discussing a deal worth over $1.5 billion to license Mechanize's technology and hire some of its employees. Negotiations were ongoing at the time of publication, and the report noted that details could still change.

This approach is similar to Google's July 2025 agreement to pay about $2.4 billion to license technology from AI coding startup Windsurf. That deal also brought CEO Varun Mohan, co-founder Douglas Chen, and several researchers into Google DeepMind, where Reuters said they would focus on agentic coding projects related to Gemini.

A deal with Mechanize would be another significant investment in external technology and talent as Google tries to strengthen its position in a rapidly changing market. The company has also continued internal development.

At Google I/O earlier this year, it introduced Gemini 3.5 Flash and new agentic coding tools to compete with Anthropic and OpenAI, followed by the release of Gemini 3.7 Flash, which focuses on coding and AI-agent workloads.

Another billion-dollar agreement would add to Google's existing efforts, which already include Gemini, developer tools, cloud services, and the Windsurf team now working in DeepMind. A Mechanize deal would further expand these resources.

Mechanize's AI Agent Technology and the Big Tech Coding Race

Mechanize stands out because its goals go beyond building another coding assistant. Founded in 2025 by Tamay Besiroglu, Matthew Barnett, and Ege Erdil, the company develops virtual environments, benchmarks, and training data to help AI agents handle more complex tasks. In its initial announcement, the founders said they aim to enable full automation of the economy, starting with software engineering.

Mechanize says that current coding agents do well on narrow tasks but still have trouble with the ongoing, complex work found in real software projects. The company points to issues like reliability, handling long contexts, and broader agentic tasks.

In April, Mechanize announced it had raised $9.1 million at a $500 million post-money valuation. A deal worth over $1.5 billion would be a notable price for a company just over a year old.

The broader trend is that major tech companies are putting more value on AI coding. Anthropic has made Claude Code a key product, with features that go beyond autocomplete to include navigating repositories, editing files, running tests, and coordinating agents. OpenAI is developing Codex along similar lines, and Meta recently joined the competition with Muse Code, its own AI coding agent.

This technology is also changing how engineers at AI companies describe their work. Some engineers at Anthropic and OpenAI say AI now generates most or all of the code they write.

As a result, software development is becoming a test case for whether AI agents can handle valuable work on their own and whether companies are willing to pay for that output.

What Google's Reported Mechanize Deal Could Mean for Developers

For developers, AI coding tools are shifting from being optional assistants to playing a more central role in software development. As Google, Anthropic, OpenAI, and Meta invest in agents that can navigate codebases, make changes, run tests, and handle longer tasks, engineering teams will need to decide how these systems fit into their workflows and where human review remains important.

For tech leaders, this shift brings up questions about standardizing tools, security, code quality, vendor dependence, and how much autonomy to give software agents. Companies may soon need to decide not just whether to use AI coding agents, but how much of their development process they are willing to hand over.

These talks are based on Business Insider's reporting, not an official announcement, and both Google and Mechanize declined to comment. No agreement has been finalized or announced, and Business Insider noted that details could still change.

The final deal value, which employees might move to Google, and how Mechanize's technology would fit with Gemini and DeepMind's coding work have not been confirmed.

Nvidia is close to finalizing a deal to acquire Hugging Face at a value of roughly $13 billion. Hugging Face makes AI software and hosts it for other companies. Nvidia was already a backer of Hugging Face, which was valued at $4.5 billion in a funding round three years ago.

Full article content is not available for inline reading.

Read the original article →

A day in a life of the AI-assisted technical content writer

I find it hilarious that when I search for “working writer” on Pexel, they serve me numerous images of serious-looking people with typewriters. Honey, we’ve moved on from that, but I’ll use it because of the romanticism of it all. In truth, I work with two monitors, a mouse and a mechanical keyboard hooked up to a laptop that constantly reminds me of yet another Jira and chat notification. A steady drip of coffee throughout the day is essential for brain power.

First, a caveat: There’s no such thing as a typical work day for me. Some days I go all-in with content creation. Some days are meeting-heavy days. Other days I plan and manage the content pipeline.

The day I’m highlighting is a “content creation” and “content management” day. Here’s how it can go:

9am: I am in the office with a cup of coffee.

From 9 to 5pm I may be doing the following:

• Bob, one of my agents, has a daily brief ready for me in a chat room. The report helps me get caught up as it tells me what’s been happening in chat rooms and emails while I was asleep. I take note of requests and personal DMs. I may have to rejig the quarterly editorial plan if I get an urgent content request.
• After reading the brief, I send an agent to create a fact pack for a project I’ll be writing about. We have a rich, well-maintained knowledge base it can use.
• While my agent is running around, I’m working with my chosen AI coding agent (it could be Antigravity, Claude Code) to discuss the editorial calendar app I’m building with it.
• Once I get the fact pack project, I’ll evaluate the report to see if the project is “ready” to be turned into content.
• If the project is ready, I’ll evaluate every single claim of the report to ensure its accuracy.
• 12pm. I break for lunch
• Then I’ll write the outline for the case story with my brain and fingers because it’s important to encode that information in my head..
• If I feel like it I will ask another agent to expand the outline to the case study format I’ve told it to use.
• Then I will revise that prototype like crazy.
• Once the draft is ready I’ll use another agent who serves as a beta-reader (from the perspective of our target audience), a “third eye” to critique the draft to surface any missing perspectives/points
• I revise again
• Then once I’m satisfied, I launch a copyeditor agent. If I’m fairly confident I just go straight to a proofreading agent.
• The copy is now ready for review. I update the necessary job tickets.
• The day ends with me going for a walk towards the nearby town centre for dinner.

Okay, I wouldn’t call this a typical day. It’s a fairly intense content-creation day. But it’s VERY possible thanks to the AI assistance.

Usually I prefer to do this entire workflow in two days: One day for creation, another day for evaluation and revision. Different days for different brain modes. It’s kinder on the brain.

In a typical company, a team may execute this workflow. Now, I have a whole content team (and even an engineer bot) to help me. What used to take an entire week or more can be condensed into 1-3 days.

I am still the boss and I still write heavily.

You are probably wondering: why not hire people to fill those roles AI is doing?

Yes, ideally it’ll be great to have a team.

But what makes you think every company has the luxury to hire an entire team for content purposes?

In my career, I’ve had roles where I’m the solo tech writer/writer. All-in-one, jack-of-all-trades content roles are common in Malaysia because local companies tend to be very lean.

If you have a human team to support you, all the better!

All stripes of writers, whether they are tech writers, content marketers or managers, whether they have a team or not, can benefit from the assistance of AI, especially if they know how to use them well.

However, this will be a game-changer for that solo, all-in-one content manager and marketer; it’ll enable them to work with support, even if it’s just a bot.

Enterprise content management and creation is very complex, so I cannot say that AI will turn everything into nirvana overnight for content professionals.

Used improperly, it will still be more work than help. And if expectations are unrealistic, content professional will still be burned out by the demands.

But a company that understands the role LLMs play in assisting content creation will really stand to benefit from it.

PS: I always try to offer a more realistic view of the profession, not a rainbows and kittens idea of how it’s like to be a writer in enterprises. You can read more below:

Excited and exhausted: My honest take about life as a techwriter in the AI age

Any rigorous thinking about the long-term future leads to extreme outcomes. It cannot, by construction, produce normal or mundane futures.

“Rigorous thinking” means you have a model: a formalism for representing the state of the world, and a transition function to advance the state. You put the world into the formalism, and turn the crank to get successive states of the world. Models can be qualitative or quantitative. Most thinking about the future is qualitative and informal: people think in terms of trends over vague qualities like “intelligence”. For example, your model might be:

1. Currently, humans are smarter than computers.
2. Computers are getting smarter faster than humans are getting smarter.

From this, you can derive:

1. At some point in the future, computers will match human intelligence, and thereafter exceed it.
2. In the limit, and given reasonable assumptions about at the physics of information processing, computers will vastly exceed human intelligence.

But you can’t say when (1) or (2) will happen. So, a qualitative model can tell you the world will pass through a sequence of discrete states, but not when.

Quantitative models usually have better time resolution: you turn the crank until you reach some desired time t, and examine the state of the world. You can talk about both the journey and the destination. For obvious reasons, models that make detailed, fine-grained predictions only work for the near future.

But, in an existential sense, the only thing that matters is the ultimate future, “ultimate” not as in “long-term” but in the sense of a normal form: a state for which no more rewrite rules apply. So you keep turning the crank until the model stabilizes. And there are only two stable states: heaven and hell. It’s either the spike, von Neumann probes, uploaded minds living at a million subjective years per second, galaxies dimmed to infrared with Matrioshka brains, the Omega Point; or we crash and go to zero.

Graph Engineering in the Era of LLM Agents: From Individual Intelligence to System Intelligence

LLMs have evolved from language generators to autonomous agents capable of complex, long-horizon tasks. This evolution has produced paradigms including Prompt Engineering to elicit model capabilities, Context Engineering to manage information access, Harness Engineering to organize external tools and resources, and Loop Engineering to support continual reflection and self-improvement. Yet as tasks grow more complex, individual intelligence faces a fundamental limit: many tasks require heterogeneous expertise, interdependent subtasks, parallel execution, independent verification, and persistent state, exceeding any single agent's organizational capacity. Augmenting one agent's capabilities or context cannot resolve this architectural mismatch; intelligence must instead be distributed across specialized agents and organized at the system level.

We call this System Intelligence: an agent system's ability to organize and coordinate multiple intelligent components into a coherent, adaptive whole pursuing a shared objective. Achieving it requires more than adding agents; it demands explicit structures to organize work, coordinate heterogeneous agents, and maintain evolving execution states. We introduce Graph Engineering, an emerging paradigm for next-generation agent systems. Unlike prior paradigms that mainly optimize individual interactions or agent-level behavior, Graph Engineering constructs explicit, dynamic, evolving graph structures representing tasks, agents, and system states. These abstractions provide a unified foundation for organizing complex objectives, orchestrating heterogeneous agents, modeling system dynamics, and enabling scalable agent evolution. We systematically review the principles, methodologies, and applications of Graph Engineering for LLM agents. Related papers, open-source data, and projects are collected at this https URL.

AI creates more pipelines and dependencies without matching growth in data teams, making engineers the operational bottleneck. Companies should prevent burnout with scalable infrastructure, governance, and automated operations matched to their actual needs and capacity.

DuckLabs to Join AWS, Projects to Remain Open Source

Today, we’re announcing that DuckLabs will join Amazon Web Services (AWS), which is expected to be effective in early September.

Our team will remain together in Amsterdam, continuing our work on DuckDB, DuckLake, Quack, and the broader community. Joining AWS gives us the resources and reach to bring this technology to many more developers and organizations, and to pursue ideas at a scale that would have been difficult for us to reach alone.

Most importantly, the foundations of the project will remain firmly in place. DuckDB and the other open-source components of the “Duck Stack” will remain free and open source under the MIT license, with the nonprofit DuckDB Foundation continuing its stewardship of the projects.

This is a significant moment for all of us at DuckLabs. It marks the end of one chapter that we are immensely proud of, and the beginning of another that we believe can take DuckDB much further.

Our Journey to This Point

We founded DuckLabs a little over five years ago to give the team behind DuckDB a stable, long-term home.

At the time, DuckDB was beginning to gain real momentum. The first commercial contracts to prioritize features were materializing, and venture capital firms were calling. We chose a different path: a bootstrapped company, fully owned by its founders and development team.

That decision shaped DuckLabs in ways we value deeply. It gave us the freedom to build patiently, to put the technology first, and to grow without losing sight of why we started. From a small group gathered around an ambitious open-source project, we grew into a team of more than 30 people in Amsterdam, all while continuing to invest in DuckDB and the community taking shape around it.

During those years, DuckDB traveled much further than we imagined when the project began. Today, we see more than one million downloads every day. Developers around the world use it to explore data, power products, teach new ideas, conduct research, and build systems we could never have anticipated ourselves.

Watching that happen has been one of the great privileges of our professional lives. But the limits of our existing model also became increasingly clear. As founders, we worried that DuckDB’s growth would eventually outpace our ability to support it. That our small company could become a bottleneck for the project, the team, and the people building businesses on top of it.

We also worried that scaling DuckLabs into a much larger sales, support, and operations organization would pull our attention away from the technical work and open-source community that made DuckDB successful in the first place.

Our partnerships work best with highly technical organizations – often companies with substantial database expertise of their own. Reaching a much broader group of users requires us to solve more complete and specialized problems, serve the needs of different industries, invest substantially more in infrastructure, and reach people who may never think to seek out an analytical database directly.

We believe the DuckDB revolution can grow by another couple of orders of magnitude. To give it that opportunity, we realized we needed a different setup.

Why AWS

DuckLabs and AWS have already been working closely together for more than a year. During that time, we came to understand how our teams collaborate, what each brings to the table, and what might become possible by combining DuckLabs’ technical expertise with AWS’s infrastructure, scale, and customer reach.

That experience gave us confidence in taking this next step.

Together, we plan to use DuckDB, DuckLake, and Quack to help power a new generation of data services. Our ambition is to reach people who may eventually depend on the Duck Stack every day, whether they interact with it directly or encounter it quietly inside the products and services they use.

For the DuckLabs team, joining AWS creates the space to concentrate on the technical work we care about most while operating at a scale we could not easily achieve on our own. It allows us to think further ahead, be bolder, tackle harder problems, and bring the ideas behind DuckDB to many more people.

AWS has committed to supporting the continued development of DuckDB and its wider community for the long term. That commitment matters deeply to us.

“DuckDB is an incredible open source project with an amazing community; it is broadly used and very much loved by S3 customers today. After about two years of working closely with Mark, Hannes and the whole team at DuckLabs I’m excited at the opportunity to help the project have an even broader impact. Also, and maybe a little selfishly, I’ve found the DuckLabs team to be one of the most technically deep, humble, and high-velocity teams that I’ve ever had a chance to work with and I’m delighted that we get to do a lot more of that.”

– Andy Warfield (Distinguished Engineer and Vice President, AWS)

What Will Remain the Same

We know that an announcement like this brings important – and understandable – questions for users, contributors, customers, and partners.

DuckDB, DuckLake, Quack, and the other open-source components of the Duck Stack will remain free and open source under the MIT license. The nonprofit DuckDB Foundation will continue to steward these projects, and the DuckLabs team will continue to contribute to the project and remain together in Amsterdam.

The open-source projects will continue to serve a broad community of users, contributors, platforms, and vendors. The openness that allowed DuckDB to flourish will remain central to its future.

We care deeply about the trust this community has placed in us. Protecting that trust has been one of the most important considerations throughout this process.

“As the CWI representative on the DuckDB Foundation, I would like to congratulate Hannes, Mark and all DuckLabs employees with this new chapter. When DuckLabs spun out of CWI, we created this foundation, which holds all IP of open-source DuckDB, and will continue to do so. I am delighted that AWS is committed to keep advancing open-source DuckDB, and I anticipate it to even accelerate its innovation. Via the DuckDB Foundation we will also make sure that the voices of its supporters and all members of the open-source DuckDB community at large, will continue to be heard. I am very proud of DuckDB and its creators; this development underlines it is state-of-the-art technology, which realizes many ideas from the database architecture research group in open source, for everybody’s benefit.”

– Peter Boncz (Database Architectures group lead at CWI Amsterdam, DuckDB Foundation board member)

“Over the course of five years, DuckDB’s open nature, its sheer hackability, and the remarkably friendly community of developers has turned the system into one of the premier platforms for database research as well as teaching. For both, it is essential that we can inspect and tinker with DuckDB’s kernel. I am thus excited to learn that DuckDB will remain open source under the umbrella of AWS. An even wider range of opportunities is in reach now. We are glad to be able to be a part of this new era for DuckLabs and DuckDB.”

– Torsten Grust (Professor of Computer Science and Database Systems research group lead at Universität Tübingen, Germany)

What We Plan to Expand

Joining AWS will give us greater capacity to invest in both the technology and the community around it. Going forward, the DuckDB Foundation will include a technical advisory board, so that leading community members can provide their input on the project’s technical direction. We also plan to open the extension stack so that extensions signed by other developers and organizations can run in DuckDB.

There is a great deal of work ahead, and many details still to shape. We will share more as these plans develop.

“Amazon putting its weight behind DuckDB is going to add a ton of momentum and strengthen the ecosystem. This is great news for those of us who believe in DuckDB as the platform on which the future of analytics is being built.”

– Jordan Tigani (CEO, MotherDuck)

“Amazon is the ideal home for DuckLabs. DuckDB is the center of the vendor-neutral open data stack, and Amazon has the commitment to openness, and the track record of working with the entire cloud ecosystem, to enable the DuckDB project to continue to thrive in this role.”

– George Fraser (CEO and co-founder, Fivetran)

The Next Chapter

DuckDB’s success has always belonged to a much larger community than the people working inside DuckLabs.

It belongs to everyone who has used it, contributed code, reported a bug, written an extension, answered a question, published a benchmark, taught a class, built a product, challenged our assumptions, or recommended DuckDB to someone else. Every one of those acts helped the project become what it is today.

We do not take that support – or the trust behind it – for granted.

Joining AWS gives the DuckLabs team an extraordinary opportunity to bring the Duck Stack to a much larger audience while continuing to invest in the open-source technology at its heart. We enter this next chapter with the same curiosity, care, and technical ambition that brought us here, alongside a team that has been through the entire journey together.

To everyone who helped us reach this point: thank you. We are proud of what we have built together, excited by what now lies ahead, and looking forward to building the next chapter with you.

The worldwide enterprise application market grew 11.5% in 2024. It grew 12.1% in 2025. Halfway through 2026, verified earnings across 60 public application software vendors (20 large-cap, 20 mid-cap, and 20 small-cap) put blended growth at roughly 13%, confirmed against the most recently reported quarters. On a market approaching $700 billion, that is real money amounting to tens of billions of dollars in incremental annual spend. It is also, by any honest reading, not the inflection point the AI narrative promised.

That gap is the whole story. If agentic AI were about to remake enterprise software the way cloud remade it a decade and a half ago, the aggregate growth rate should be bending upward. It isn’t bending. It’s creeping. However, therein resides the lie. An average of a market pulling apart in opposite directions is not a measurement. It’s a number that happens to be both true and useless at the same time.

The reason is not that AI has failed to show up. It is that the aggregate number is the wrong place to look for it. AI capability moves into specific application categories at different speeds, and until it does, it has no reason to move the blended average at all. The businesses waiting for the aggregate number to justify the investment will be years behind the ones who read the dispersion first.

Where the disruption is actually showing up

The real signal was never the aggregate. It is the dispersion beneath it, and 2026 earnings confirm the pattern is holding, not reversing. Atlassian grew 28% in its most recent fiscal quarter. ServiceNow grew 24%. BILL Holdings, an accounts payable and receivable automation platform, grew core revenue 16%. These are workflow-heavy, automation-friendly businesses. This is exactly where agentic AI should add value fastest, and the real numbers agree with the theory.

Customer Service Applications and Human Capital Management tell the opposite story. Sprinklr, a customer experience platform, grew just 6.8% in its most recent quarter, with guidance pointing toward roughly 1% next quarter. LivePerson, sitting in the same customer operations orbit, saw revenue decline 12% year over year. Workday’s total revenue growth held at 13.5% in early 2026, in line with IDC’s full-year 2025 HCM category rate of 13.0%. Not the reacceleration bulls were hoping for.

That is the part worth pausing on. Customer service and HR are arguably the two categories most exposed to AI disruption. Support agents replacing chat queues. AI-driven recruiting replacing manual sourcing and screening. Growth in both is stagnant, not accelerating. The explanation is not that AI failed to show up. Rather, the combination of usage-based, outcome-based, and other agentic pricing models may be cannibalizing legacy per-seat license revenue faster than new AI spend is replacing it. Both could be true, but our research suggests the scale tips toward it being a pricing issue rather than a value issue.

The strongest market cluster is actually not even specifically AI-labeled. It is collaboration software. Atlassian’s 28% and Monday.com’s 22% sit inside this space, and IDC’s 2025 data already showed Enterprise Portals accelerating to nearly 17%.

This is the part akin to the early cloud transition, playing out in real time. The categories with the most surface area for embedded AI agents and assistants moved first, years before analysts had a clean line item to point to. Slack and Teams did not wait for a “collaboration AI” category to exist before AI showed up inside them. Neither will the rest of the market.

What this means now

None of this shows up if the aggregate number is the only thing anyone checks. The categories and the pricing decisions made within them are where the real signal lives, and that holds for tech leaders and software vendors alike.

For tech leaders, the practical version of “don’t trust the aggregate” is to stop asking vendors how their AI roadmap looks and start asking how it will be priced. Before you standardize on any AI feature, ask a specific question: Is this bundled into your current subscription, or will it eventually be metered or split into its own tier? Get the answer in writing. A feature that ships free today can become a paid add-on once your team depends on it, and the time to negotiate a price lock or grandfather clause is before that dependency forms, not after. If a vendor will not commit to how an AI feature will be priced going forward, that ambiguity itself is worth noting and potentially pushing back on in the contract.

The performance of the app category your vendor sits in is a second number worth checking. It tells you something about the pressure that the vendor is under. A vendor in a category where growth has stalled, like customer service software or HCM, is likely facing margin pressure across its customer base, which shapes how it negotiates. First, they may be more willing to discount to retain you. Second, there is a real chance they will get more aggressive about raising prices over time to compensate. Knowing which situation you are in changes how you approach renewal, regardless of how the vendor’s AI roadmap is marketed.

For suppliers, the lesson is direct, and it is the same lesson in reverse. The categories where growth has stalled are not short on AI investment. They are short on pricing models designed to capture the value AI creates rather than giving it away. If your AI features are seeing real adoption and your revenue has not moved, that is not a messaging problem to fix with better marketing. It is a sign your pricing model is absorbing the value your product now creates rather than charging for it. Fix the pricing before you fix the pitch. The vendors in accelerating categories, collaboration and finance automation among them, are not simply better at building AI. They have found ways to attach a price to it.

Both sides are better off treating a vendor’s pricing structure as a more honest signal than its AI messaging, for the same reason the aggregate market number is a less honest signal than the category data underneath it. A vendor confident that its AI is delivering real value usually shows that confidence in how it charges for it. A vendor still bundling AI in for free, indefinitely, may be telling you something about how differentiated that AI actually is, whether or not that is the story in the pitch deck.

The aggregate number will keep lying for as long as it’s the only number anyone checks. Category-level dispersion and the pricing signals underneath it is where the truth actually lives.

Apple has begun rolling out ads in Apple Maps across the US and Canada, showing sponsored locations before and after searches. While Apple says the ads are privacy-focused and don't use personal tracking, critics argue they still risk undermining Apple's privacy reputation and make its premium products feel less premium by introducing advertising into built-in apps.

The AIInterface Museum

A visual history of how humans learned to talk to, look through, create with, and delegate work to artificial intelligence.

• Siri (2011): The original Siri interface in iOS 5
• Google Now (2012): Predictive cards
• Amazon Echo (2014): Alexa
• Google Photos (2015): Semantic search
• Discover Weekly (2015): A playlist made for you
• Tesla Autopilot (2015): Supervising the machine
• Google Assistant (2016): Conversational search
• Prisma (2016): Neural styles
• Google Lens (2017): Point and understand
• Google Duplex (2018): Calling on your behalf
• Smart Compose (2018): Ghost text
• TikTok For You (2018): The interest graph
• Waymo One (2018): Riding with no driver
• GPT-3 Playground (2020): Prompt as programming
• DALL·E (2021): Text becomes image
• GitHub Copilot (2021): Technical preview
• DALL·E 2 (2022): Generative editing
• Midjourney (2022): Discord bot
• Stable Diffusion (2022): The interface becomes forkable
• Character.AI (2022): A directory of personalities
• ChatGPT (2022): Research preview
• Perplexity (2022): Answer engine
• The New Bing (2023): Search plus chat
• Adobe Firefly (2023): Generative Fill
• Cursor Cmd+K (2023): Edit by intent
• ChatGPT Vision (2023): See, hear, speak
• v0 (2023): Generative UI
• Rabbit R1 (2024): AI pocket device
• Devin (2024): Technical preview
• GPT-4o Voice (2024): Real-time multimodality
• Claude Artifacts (2024): Chat beside the work
• Gemini Live (2024): Continuous voice
• NotebookLM (2024): Audio Overviews
• ChatGPT Canvas (2024): Writing and coding workspace
• Claude Computer Use (2024): Screen, cursor, keyboard
• Sora (2024): Storyboard interface
• Operator (2025): Browser agent
• Deep Research (2025): Long-running synthesis
• Claude Code (2025): Terminal agent
• Manus (2025): Cloud computer agent
• 4o Image Generation (2025): Images inside chat
• Codex (2025): Parallel coding tasks
• Flow (2025): Generative filmmaking
• ChatGPT Agent (2025): Thinking and acting
• Suno Studio (2025): Generative music canvas
• Claude Cowork (2026): Desktop knowledge agent
• Figure Helix 02 (2026): Whole-body autonomy
• Codex App (2026): Multi-agent command center
• Poke (2026): Agent in your texts

Full article content is not available for inline reading.

Read the original article →

A fintech company significantly reduced costly loan-processing errors by redesigning an internal verification screen, highlighting how small usability improvements in back-office tools can have outsized business impact. Internal systems like admin portals, dashboards, compliance tools, and operational software are often more consequential than customer-facing apps, yet receive far less design attention. Some of the most valuable design work lies in understanding complex workflows, supporting decision-making under pressure, and improving the systems that keep businesses running.

We learned this week that Amazon is destroying rare books to train AI, but some fear that AI is also destroying the future of literature. There's been a boom in poor-quality AI-generated children's books, and parents and artists are getting increasingly concerned.

On social media, people complain of nonsensical children's literature in shops and libraries, while parents have received AI storybooks featuring their own children as unwanted gifts. In most cases, the books are shoddily made with little thought or respect given to the product or its audience.

I've just found some of the other artwork in the book online, and there is absolutely no stylistic consistency in the illustrations. Tommy's hair colour is described as "sandy brown" on one page but he is then depicted very dark brown hair on another.

Most people have probably come across websites with unreadable AI-written text or AI-generated books offered for sale online, but some people have been shocked to discover bad AI-generated books appearing in print in physical retail outlets.

An illustration student recently shared an image on X of a book she said "ripped her heart out" when she found it in a shop. The text and illustrations appear to have been generated by AI, while truly awful text placement leaves the book's title barely legible on the cover 'design'. And yet a real shop had the book on its shelves.

The post quickly went viral, receiving over 60,000 likes and hundreds of comments, almost all from people who were equally disheartened or had comes across similar AI catastrophes.

"It shows complete disrespect to children's books as a medium. Picture books are not just Notes app poems with random images attached. The artwork in children’s books is integral to how educational and engaging the book is to children," one person wrote.

"This looks horrible," an early childhood educator wrote. "Besides the AI, this book would be horrible for the text alone".

In my country they're selling this crap too, worse is that these are from a BIG, "reputable" publishing house

Along with plans for AI-generated children's programming such as Amazon's KPop Demon Hunters mockbuster, these kinds of books suggest that children are seen as an easy market for AI slop, less likely to care or complain about the quality.

But I think even young kids might have an issue with books where the imagery makes no sense, characters change their appearance from one page to the nex,t or where puzzles or drawing tasks are impossible to complete.

Local cafe have printed out a completely nonsensical AI children’s activity sheet including a puzzle maze with no exit

Google released a tool for creating AI storybooks last year, and several companies are now marketing AI tools that allow users to upload photos and details about real people to generate a story that can then be ordered in print.

Wired this week reported on cases of family tension flaring due to well-meaning grandparents giving AI-generated books as presents to their grandchildren. It seems the boomer grandparents like the novelty. Parents are often less enthused to learn that their children's names, experiences and photos have been fed into AI tools with murky data transparency policies.

“I have reiterated countless times that I do not support AI-generated art, and drew a hard line that she is absolutely not to feed any of our photos into AI or use our identifying information in any way,” one person wrote on Reddit. “However, she is creating these storylines based on experiences with my kid and modeling her characters to have similar attributes as my kid."

The children apparently aren't impressed either. One dad told Wired his children were “bored” by the books.

Daozhi Xu, a researcher at Macquarie University who published a study into the explosion of such books notes that “children do not love a storybook simply because their name or image appears in the story; they love the book because the story itself is interesting.” AI-generated books often “lack humor, memorable characters, and dramatic tension,” Xu adds.

i heard my daughter say “i can’t do this connect the dots!” and i thought huh that’s weird they’re usually no problem for her… then i looked and it’s this AI mess

discovered the insane world of AI generated kindle unlimited children's books about ... palantir ceo alex karp

Generative AI can help us do some things faster and easier. it's natural that some people will take advantage of that to churn out rubbish in the hope that someone might buy it. It's a shame that children are seen as an easy target despite the rich history of beautiful and inspiring children's literature and art.

Hopefully more awareness will mean that parents take the time to check what they're choosing for their kids, while book shops and libraries could also step up quality control.

If children grow up surrounded by poorly written, low‑quality AI‑generated books, it could damage their long‑term relationship with art and literature more than many people appreciate. Children learn about symbolism, nuance, creativity and logic from well‑crafted prose and art. Exposure to clumsy phrasing, incoherent storytelling and generic imagery could stunt linguistic growth and the development of interpretive skills, which could have implications far beyond the book and illustration industries.

Barret Zoph was a co-founder at Thinking Machines Lab before defecting to OpenAI this year due to a dispute with Chief Executive Mira Murati. Zoph is now leaving OpenAI to join Google as vice-president of research. Google is currently restructuring its AI development efforts to catch up with rivals in developing AI that can create code. Zoph had worked as a research scientist at Google from 2016 through to 2022.

Grok Bot now comes with SuperGrok and Cursor plans, offering expanded access without affecting existing usage limits.

Bill Gates, once optimistic about AI, now warns it could become a major source of injustice and cause widespread unemployment.

Researchers have discovered a drug that disables a stubborn mutation that made pancreatic cancer a death sentence. Rasonque helped subjects in a late-stage study live more than 13 months, nearly twice as long as those on chemotherapy alone. It has side effects, including a harsh rash across the body and gastrointestinal issues, and costs more than $477,000 a year. The drug could generate more than $20 billion in annual sales.

Medium uses favicons in a particularly useful and delightful fashion.

Analyst Gym uses daily two-minute workplace drills to sharpen analytical judgment rather than coding skills.

Calendly has unveiled a new logo, wordmark, and color system alongside an AI email assistant and an AI meeting notetaker. The rebrand replaces the previous neon palette with soft prismatic gradients and a rippling "gloop" motif, signaling that the product is more than a scheduling link as AI reshapes productivity software.

Apple's rumored foldable “iPhone Ultra” is reportedly impressing early testers with its pocket-friendly design, durable hinge, and larger iPad-like internal display, potentially making it Apple's most exciting hardware launch in years. However, leaks suggest it may omit key premium features such as a telephoto camera and Face ID, raising questions about its value at a rumored $2,000 price point. For creatives, the choice may come down to whether a larger foldable screen is more important than having Apple's best camera system.

Generate images from text, compare leading AI models, and edit with AI chat and references. Move from prompt to finished visual without starting over.

From design tokens to fully interactive components — eUI provides the foundation for consistent, accessible, and beautiful web applications.

Apple's redesigned Safari icon in iOS 27 has sparked criticism from design enthusiasts, who argue its compass graphic inaccurately resembles two overlapping needles and reflects a decline in Apple's attention to detail.

Google has refreshed the Clock and Pixel Magnifier app icons as part of the visual design language introduced with the Pixel 11. The new Clock icon features thicker, watch-inspired hands, a blue gradient face, and a white background that aligns it with Google's broader app ecosystem, while Pixel Magnifier receives a similar treatment with a thicker gradient magnifying glass and updated Quick Settings icon. These changes are purely cosmetic, with no notable updates to the apps' functionality or user interfaces.

French illustrator Olivier Menanteau paints human figures merging with plant life in his ongoing series "Polychröm Symbiosis."