Today, we are releasing Inkling-Small, an efficient open-weights model that achieves comparable performance to Inkling at a quarter of its size.

Inkling-Small is a Mixture-of-Experts transformer with 276B total parameters, 12B active, trained on NVIDIA GB300 NVL72 systems. Like Inkling, it features native reasoning over audio and images, variable thinking effort, a context window of up to 1M tokens, and well-rounded performance across a range of benchmarks.

Inkling-Small vs Inkling

• Inkling-Small: 276B total, 12B active
• Inkling: 975B total, 41B active

Compared to Inkling, Inkling-Small achieves comparable performance with much less compute. Across agentic tool use (Terminal-Bench 2.1), reasoning (HLE text-only, no tools), and instruction following (IFBench) benchmarks, Inkling-Small is more efficient than Inkling and competitive with other models in its weight class. Furthermore, its variable thinking effort lets users easily adapt it to target their use case, balancing cost and performance.

We are releasing the full weights of Inkling-Small. We’re also making it available for fine-tuning on Tinker, and for text, image, and audio chat on Tinker Playground.

Capabilities

As we build our model family, we are always iterating on our approach. Inkling-Small began training after its larger counterpart, which let us improve its training process. For example, we made changes to Inkling-Small’s pre-training data mix and machine learning recipe. Additionally, we post-trained an earlier checkpoint, Inkling-Small (preview), in part using on-policy distillation with Inkling as the teacher. Starting from that checkpoint, we continued scaling agentic coding RL for two weeks. With these improvements, Inkling-Small surpassed Inkling on reasoning and agentic coding benchmarks. Inkling maintains an advantage on knowledge coverage and factuality.

Reasoning and Agentic Tasks

Inkling-Small matches or exceeds Inkling on reasoning and agentic tasks. On Humanity’s Last Exam it scores 31.6%, ahead of Inkling’s 29.7%, and the advantage holds at every thinking budget: Inkling-Small’s test-time compute curves sit above Inkling’s throughout. On SWEBench-Verified it exceeds 80%.

Across many reasoning and agentic benchmarks, Inkling-Small at max reasoning effort has a strong performance-token tradeoff when compared to open weights models in its weight class.

Inkling-Small also runs smoothly across a variety of coding and agent harnesses, making it a cost-efficient choice for coding and tool-use workflows.

Multimodality

Like Inkling, we crafted Inkling-Small for audio intelligence, making it a good candidate for real-world audio applications. We also improved its ability to use Python for visual tasks. The model can combine visual reasoning with operations such as cropping, zooming, and programmatic image inspection, improving usability on documents and charts where relevant information may be small or difficult to inspect directly.

Inkling-Small uses the same natively multimodal encoder-free architecture as Inkling. Audio is represented as dMel spectrograms, while images are divided into 40×40-pixel patches and transformed using a four-layer hMLP. Both are transformed via a light-weight embedding layer and processed jointly with text tokens. Inkling-Small nearly matches Inkling across most multimodal evaluations at a lower cost. It retains strong performance on visual reasoning, chart and diagram understanding, mathematical visual question answering, speech understanding, and longer-form audio reasoning.

Epistemics

Inkling-Small was trained similarly to Inkling on epistemics, focusing on calibration, instruction following, and resistance to censorship. Inkling-Small matches Inkling’s performance on forecasting. Calibration involved RL against proper scoring rules on a large corpus of real-world forecasting questions, improving its ability to express appropriate confidence and produce calibrated forecasts under uncertainty.

Safety

Inkling-Small inherited the same safety post-training recipe as Inkling, with built-in safeguards covering our internal spec of safety. These include everyday human-AI interactions as well as dual-use capabilities. Inkling-Small also underwent the same pre-deployment testing process, comprising both internal evaluations and red-teaming by trusted external partners.

On StrongREJECT, which measures whether models refuse unambiguously harmful requests, Inkling-Small is on par with Inkling, and matches the performance of existing open-weights models. On FORTRESS, which measures safety in settings spanning crime, violence, and dual-use risks, it is competitive in both refusal and over-refusal.

Benchmarking Inkling-Small

Like Inkling, we benchmarked Inkling-Small on a broad range of capabilities. All evals run at effort 0.99 and temperature 1.0. All coding evals run with 256K max-token trajectory limit, similar to Inkling.

To improve consistency, we rely on externally reported evaluations for both internal and external models when applicable.

Try Inkling-Small on Tinker

Tinker customers have seen firsthand that the right fine-tuned model can outperform closed models on a variety of tasks, and do so faster and cheaper. We believe Inkling-Small’s combination of broad performance and efficiency will make it easy to experiment with and test in real applications, and we’re excited to see what developers build with it.

Inkling and Inkling-Small are available on Tinker with a limited-time discount and can be chatted with on the Tinker Playground using text, image, and audio. All other models on Tinker and checkpoints are also now available on Tinker Playground, billed at the rates listed on our pricing page.

Inkling-Small was made in pursuit of our mission to build AI that extends human will and judgment. It’s a capable and efficient model, and an important stepping stone for us as we continue our work.

Introducing Gemini Robotics ER 2

Gemini Robotics ER 2 represents a step change in powering robots with video understanding, task orchestration, and multi-robot collaboration — making it possible for robots to be more helpful in the physical world.

We are launching Gemini Robotics ER 2, a new model designed to act as a high-level brain for robots. It enables real-time spatial reasoning, multi-step task planning, and collaboration between different robots. You can access the model now via the Gemini API, Google AI Studio, or the Gemini Enterprise Agent Platform to start building your own physical AI agents.

For robots to assist humans in everyday environments, accurate spatial reasoning is not enough. Robots must also think fast, timing their decisions and reasoning with the real-time speed of the physical world.

That’s why today we’re launching Gemini Robotics ER 2, our most capable “embodied reasoning” model for robotics. Think of Gemini Robotics ER 2 as a high-level brain for robots. It allows robots to chat with humans, understand the physical world, and plan multi-step tasks. It then hands off motor execution to any given lower level vision-language-action (VLA) model. Gemini Robotics ER 2 can also natively call tools like Google Search to find information, or any other user-defined function. The design of Gemini Robotics ER 2 allows the robot to “think” about what comes next while simultaneously performing its actions.

Gemini Robotics ER 2 represents a significant upgrade over Gemini Robotics ER 1.6. By watching continuous video feeds, robots can now track their own progress, adapt if something goes wrong, and know exactly when to move on to the next step. We are also introducing multi-robot collaboration, enabling robots to work together in shared spaces and complete complex workflows a single robot could not do alone.

Gemini Robotics ER 2 is now publicly available to developers via the Gemini API, Google AI Studio, and in private preview on Gemini Enterprise Agent Platform. To help you get started, we’re sharing examples of how to configure the model and prompt it to power more useful physical AI tasks.

Advancing physical agentic capabilities

Most tasks in the physical world are complex and require multiple steps to complete. Gemini Robotics ER 2 is a physical agent, orchestrating steps for the robot and enabling it to self-correct, and generalize to more novel situations. To build an agentic setup, developers can declare low-level control interfaces — like Vision-Language-Action (VLA) models or navigation APIs — as tools, and stream multimodal video, audio, or text directly into the model.

Gemini Robotics ER 2 improves this tool orchestration workflow. We can evaluate its performance with robots in simulation, using real-world robot control, and even pair it with a human controlling the robot remotely.

Gemini Robotics ER 2 consistently outperforms ER 1.6 for tool orchestration across three control modes: real VLA, sim VLA, and human tele-op.

In robotics, high-level reasoning depends on execution speed. Gemini Robotics ER 2 integrates into the Gemini Live API, using a bidirectional streaming endpoint optimized for latency-sensitive tasks. The result is fluid orchestration: Gemini Robotics ER 2 commands action models and robotics APIs to complete multi-step tasks without the jarring “stop-and-think” pauses.

To illustrate this, we’ve built a demo with Spot from our partners at Boston Dynamics. We use Gemini Robotics ER 2 to orchestrate Spot APIs, such as navigation and manipulator movement, creating an interactive robot that fetches objects for you.

Gemini Robotics ER 2 powered Boston Dynamic Spot fetches a popcorn snack up on a natural language command.

The code is available on Github with other examples.

Unlocking temporal intelligence for robust task completion

One of robotics’ hardest challenges is knowing when a task is done. Gemini Robotics ER 2 brings a step-change in video understanding and progress tracking to verify that complex tasks — such as tightening a light bulb or tying a trash bag — are complete to specification before switching to the next task.

In this update, we’ve made progress on two foundational capabilities for task progress understanding: progress classification and moment finding.

Continuous progress classification

Progress classification refers to a robot’s ability to track progress towards task completion. In our evaluations, we assign each frame in a video feed into five levels of progress (0-20%, 20-40%, 40-60%, 60-80%, 80-100%). By quantifying task progress, Gemini Robotics ER 2 provides robots with real-time situational awareness, and allows them to adjust actions on the fly or retry failed steps without restarting an entire workflow.

Gemini Robotics ER 2 achieves 57.4% accuracy on progress classification tasks, outperforming previous generation models and competing frontier models.

Precision moment-finding

Moment-finding measures a model's ability to identify the exact video frame where a critical event takes place (i.e. when to stop pouring coffee into a cup). Gemini Robotics ER 2 achieves significant gains in performance on moment finding, enabling robots to precisely switch between tasks, verify success and suggest corrections.

For moment-finding tasks, Gemini Robotics ER 2 achieves 91.3% accuracy and a 0.96s mean absolute distance. It competes closely with much larger model categories, but delivers this precision at a fraction of the compute cost and 4x the execution speed—the sub-second latency actually required to safely operate physical robotics in the real world.

Multi-robot collaboration

No single robot fits every task — a wheeled rover excels indoors, while a humanoid robot may excel at uneven terrain. Gemini Robotics 2 enables multi-robot collaboration, allowing diverse machines to communicate via a shared semantic understanding to handoff and complete complex tasks. See how Gemini Robotics ER 2 enables Apptronik’s Apollo 2 and Franka F3 Duo to collaborate here.

Improving general spatial intelligence

Gemini Robotics ER 2 advances our core spatial reasoning capability, as measured by three benchmarks:

• Success/failure detection: Now operates on raw video feeds rather than static snapshots to catch mid-execution failures like spills, slips, or misalignments.
• General instrument reading: Extends beyond circular dials and sight glasses to include digital displays, linear scales, rulers, and liquid thermometers. We tested it across 10 different types of instruments.
• Enhanced spatial VQA: Improves Visual Question Answering through Gemini’s advancements in multi-modal understanding.

Gemini Robotics ER 2 consistently achieves the highest accuracy across all core capabilities, with highlights including success detection (image/video), Question Answering (ERQA), and generalized instrument reading.

Advancing safety for embodied intelligence

Gemini Robotics ER 2 is our safest model, achieving significant gains on Safety Instruction Following and Human Proximity benchmarks, which evaluate how a model adheres to physical constraints during reasoning tasks and spatial awareness for detecting humans. We found that Gemini Robotics ER 2 successfully halts a humanoid robot when a person is nearby and autonomously resumes work only once the area is clear. To advance safety for physical agents, we’re introducing a benchmark that evaluates a foundation model's ability to act as a safe VLA orchestrator by testing its capacity to enforce safety constraints, monitor the environment, assess physical feasibility, and seek human clarification. For details, see our safety technical report.

Gemini Robotics ER 2 outperforms ER 1.6 and other frontier models on Safety Instruction Following and Human Proximity benchmarks.

Looking ahead, our plans are to push these models towards even more complex tasks to accelerate the development of helpful robots and support the robotics community.

The Session You Cannot Take With You

The original promise of an inference API was wonderfully simple: send some input, receive some output. If you kept both, you had the conversation. You could inspect it, archive it, replay it, or give it to a different model.

That abstraction was never completely true. For instance prompt caches live on somebody else's GPUs, tokenization differs between models, and sampling is not reproducible (and quite intentionally so). But the semantic record of a session in the form of a transcript could still belong to the user. A transcript should contain the instructions, messages, tool calls and tool results. Another sufficiently capable model might not continue identically, but it could understand what happened and take over.

Inference APIs are frustratingly moving away from that property, at least somewhat. They increasingly return a mixture of text and provider-bound state that is very intentionally non-portable.

• reasoning tokens that are billed to the user but returned only as opaque, encrypted blobs, with useless summaries at best
• web searches where the model sees source material the client never sees
• compacted context that only the original provider can decrypt
• subagent instructions and messages hidden from the application running the agents in the form of encrypted payloads
• file, vector-store, container, and cache references that cannot be resolved anywhere else.
• response and conversation state that is entirely keyed by IDs that are stored fully on the provider's servers

Each feature comes with a basic justification that's trivial for a provider to come up with, along with good arguments for why this is good for the user. Together all of these things change the ownership reality of an AI session: the transcript on your machine is no longer your session but a partial view of a session whose operational state belongs to an inference provider and not you.

We are not fans of this direction, and we want to talk a bit about what it means to you, as a user, and what it means to us, as people developing tools in this space.

A Practical Test for Session Ownership

By a portable session we do not mean that switching from one model to another must produce the same next token. That's a given because models have different capabilities, trained personalities, context windows, and ways of working with tools. And well, it's all quite nondeterministic anyway. Portability means something more modest:

const transcript = session.export();
revokeCredentials(oldProvider);
session = newProvider.continueFrom(transcript);

The archive should contain enough intelligible information for another model to continue the work. It should not require the old provider to dereference an ID, decrypt a blob, remember a search result, or reconstruct a summary.

This gives us five useful tests:

1. Inspection: Can the user see what the model saw, what tools did, and what agents told each other?
2. Export: Is the session self-contained, apart from ordinary artifacts that can also be downloaded?
3. Replay: Can another implementation reconstruct a semantically equivalent context?
4. Audit: Can a human explain why the system took an action after the fact?
5. Deletion: Can the user identify and remove every server-side copy on which the session depends?

A response ID is not a transcript (as the data is stored on the server), a ciphertext is not user-controlled stated (as the user cannot decrypt it), a list of citations is not the evidence that was placed in the model's context by a search result (as you cannot typically fetch the same data as the model did).

Encryption for Whom?

The naming and marketing around these features can be misleading. encrypted_content sounds like a privacy feature under the user's control. Usually it is a capsule that the client cannot read and only the provider can open. The provider chooses the keys, decrypts the content for its own models, and defines where the data can be replayed.

A better term is provider-sealed state.

Provider sealing can have a real privacy benefit. OpenAI, for example, can return encrypted reasoning to a client using store: false, then decrypt it in memory on the next request without persisting the intermediate state. That is better than requiring server-side conversation storage, particularly for Zero Data Retention customers. But, remember, there is not really anything that needs encryption to begin with!

This encryption does not hide the data from the inference provider but it hides it from you.

Stored Conversations Turn a Transcript into a Pointer

OpenAI's Responses API stores responses by default. Its documentation says response objects are retained for at least 30 days by default. store: false is available and should be used, as it makes it work more like completions: the data is not stored on OpenAI's servers.

The new Gemini Interactions API has made a similar choice. It defaults to store: true. On the paid tier interactions are retained for 55 days, and on the free tier for one day.

And obviously, the idea of storing state on the server is quite attractive:

const first = responses.create({
  model: "frontier-model",
  input: "Investigate this production failure",
  store: true,
});

const second = responses.create({
  model: "frontier-model",
  previousResponseId: first.id,
  input: "Now implement the fix",
  store: true,
});

The application sends less data, the provider can preserve hidden reasoning and tool state, and cache routing becomes easier. But if the local application only records the user messages and final text, first.id is now a foreign key into a database it does not control.

No Reasoning For You

All major labs claim to have legitimate reasons not to expose raw chain of thought. As a result, on non-open-weights models we typically do not see these tokens.

Raw reasoning is not visible via the API. With stored responses, prior reasoning can be recovered through previous_response_id. With store: false, the API returns encrypted_content, which the client must preserve and replay. Persisted reasoning remains opaque even when reasoning.context: "all_turns" lets a later sample use it.

Anthropic returns the encrypted full thinking in a signature field. The readable thinking text, when enabled, is a summary produced by another model, not the raw chain of thought. Thinking blocks must be passed back unchanged during tool-use turns. Anthropic's documentation also says thinking blocks are tied to the model that produced them and should be stripped when switching models. So these reasoning traces do not attempt to be portable within Anthropic.

The same story repeats with all closed-weights models.

These encryption mechanisms permit continuity inside an ecosystem but they do not create a portable transcript that can be taken to another provider's model. A session archive can contain the blob, but another model cannot use its meaning:

{"type": "reasoning", "encrypted_content": "gAAAAAB..."}
{"type": "thinking", "thinking": "", "signature": "EqQBCg..."}
{"type": "thought", "summary": [], "signature": "EpoGCp..."}

Hidden Searches

Server-side web search is one of the clearest examples of a transcript having holes in it hidden from the user. A client-side search tool behaves like any other tool:

const result = search(query);
record({
  query,
  retrievedAt: now(),
  results: result.map((item) => ({
    url: item.url,
    title: item.title,
    passages: item.passages,
  })),
});
model.send({ toolResult: result });

The user can inspect the ranking and passages, refetch the pages, cache a copy, or provide the same evidence to another model.

With hosted search, the provider performs a private tool loop. OpenAI, Google and Anthropic expose search actions, citations, and optionally a list of source URLs, but not the complete text context used to produce an answer. A URL is not a stable replay, instead its contents can change or have been reduced to a much shorter snippet before the model saw it.

The final answer may be perfectly good. The problem appears on the next turn:

Compare the third source with the first one, re-check the disputed number, and continue this research using another model.

The new model receives an answer and a few URLs. It does not receive the result ranking, extracted passages, filtered-out material, or exact evidence the first model used. The old provider is still part of the session even if the next request goes elsewhere. Even if you have the citations and you were to re-fetch you cannot reproduce the precise data.

Hosted search should have a full-fidelity export mode containing queries, result metadata, retrieved passages, timestamps and retained contents. Concise citations can remain the user interface but they should not be the only record.

Opaque Compaction

Long agent sessions eventually need compaction. A visible, client-controlled summary is lossy, but it is at least inspectable and transferable. The user can review it, edit it, or ask a different model to produce another one.

OpenAI's server-side compaction instead emits an encrypted compaction item. The documentation describes it as "opaque and not intended to be human-interpretable." The standalone /responses/compact endpoint returns a "canonical next context window" that clients are instructed to pass on as-is.

Conceptually, the transition looks like this:

// Before: expensive but portable
let history = [
  userMessage,
  assistantMessage,
  toolCall,
  fullToolResult,
  // ... 200,000 more tokens of intelligible history
];

// After: cheap to continue only with the original provider
history = [
  {
    type: "compaction",
    encryptedContent: "enc_provider_only_state...",
  },
  ...recentItems,
];

OpenAI can continue from the compressed meaning, but a different provider sees an unreadable string plus a recent suffix (well, would see it, we never pass this sort of information to another provider).

This is not technically necessary. Anthropic's server-side compaction returns a compaction block with a readable content field. It lets the client provide custom summarization instructions, and the resulting summary can be inspected and passed to another model. Client-side compaction is also possible with any provider.

OpenAI's sealed artifact may preserve more model-specific state than a plain summary and may perform better on the original model. That is a reasonable optional optimization but it should be accompanied by a readable handoff summary, not replace one. But again, a lot of this has the added benefit of further locking you into one ecosystem.

Subagents Come With Hidden Instructions

Multi-agent systems compound the problem because there is no longer one transcript. There is a tree of sessions and a stream of messages between them. Usually they are prompts as if a human wrote them, just now authored by a machine for another machine.

OpenAI's hosted Responses Multi-agent beta returns three new item types: multi_agent_call, multi_agent_call_output, and agent_message. The example for spawn_agent contains an encrypted message argument, and inter-agent messages contain only encrypted_content. Automatic server-side compaction is implicitly enabled for every agent when Multi-agent is enabled, even if the client did not request it. Reasoning summaries are not supported and the API also injects root and subagent instructions that the developer cannot edit or remove.

This is a bundle of non-transferable state: sealed delegation, sealed agent messages, separate automatically compacted contexts, hidden reasoning, and provider-hosted orchestration.

A related change landed in the open-source Codex client in June 2026. The commit, titled "Encrypt multi-agent v2 message payloads", explains the flow directly:

// Parent model's tool call, as persisted by Codex
{
  "name": "spawn_agent",
  "arguments": {
    "task_name": "worker",
    "message": "<ciphertext>"
  }
}

// Child model's input
{
  "type": "agent_message",
  "author": "/root",
  "recipient": "/root/worker",
  "content": [{
    "type": "encrypted_content",
    "encrypted_content": "<ciphertext>"
  }]
}

The Responses API encrypts the tool argument emitted by the parent, Codex forwards it, and the API decrypts it internally for the child. Codex's own InterAgentCommunication.content is empty. The exact task is absent from its readable rollout and history.

Presumably this is not merely an abstract model-switching concern. One could imagine if the child changes the wrong file, leaks a secret, duplicates another agent's work, or follows a bad assumption, the user cannot answer the simple question of what was that agent asked to do?

An open Codex issue asks for the encrypted delivery to retain a separate readable audit copy. That is the minimum acceptable design. Better still, plaintext inter-agent messages should remain the norm.

“Most People Do Not Switch Models Mid-Session”

Probably not. Most people do not switch their operating system or phone provider every week either. But even if you do not utilize that freedom, it matters because it changes the relationship you have with the provider and the provider has with you.

As a user you also may need to move a session because a model is retired, a service is down, a price changes, a policy blocks the next request (hello fable), a confidential phase must run locally, or an auditor needs to reconstruct what happened. Agents are also making sessions much longer. A coding or research session can accumulate days of decisions and evidence and a personal assistant may accumulate session transcripts going back years (presumably as we don't have them for that long yet).

The option to leave also creates discipline. If a provider knows that a user can continue elsewhere, it has to compete on model quality, price, reliability, and trust. If the user's accumulated context can only be interpreted by one provider, it sets very unfortunate incentives.

What a Portable Inference API Should Promise

We would like inference providers and agent builders to adopt a small set of rules.

1. The local event log is canonical. Server storage may mirror or accelerate it, but the client can reconstruct the session without dereferencing server IDs.
2. Storage is explicit. store: false should be easy, documented, and preferably the default. Features that require retention should say so at the point of use.
3. No opaque item is the sole carrier of meaning. Encrypted reasoning, compaction, and tool signatures may be included for same-provider quality, but each has a readable, provider-neutral handoff representation.
4. Hosted tools have full-fidelity logs. Record exact inputs, outputs, evidence, filtering, provenance, timestamps, and content hashes — not only a polished answer and citations.
5. Subagent communication is auditable. Persist the exact readable task, messages, results, lineage, model, and tool permissions for every agent.
6. Compaction is inspectable. Return a readable summary, the instructions used to create it, and enough lineage to understand what was discarded.
7. Artifacts are exportable. Files, container outputs, search snapshots, and generated media can be downloaded into a content-addressed local archive.

Distillation Is Great Actually

There is a related form of lock-in at the model layer.

Some of the largest closed-weight US labs are increasingly hostile to outside distillation. Anthropic's February 2026 post about alleged campaigns by DeepSeek, Moonshot, and MiniMax calls them "distillation attacks". Its commercial terms say customers own their outputs, but prohibit using the service to train a competing AI model. At the same time, Anthropic's own post acknowledges that "distillation is a widely used and legitimate training method" when frontier labs use it on their own models.

Anthropic uses robots to gather data from the public web for model development and they famously cut up books to scan them. OpenAI similarly says it trains on freely accessible public internet content and has argued that training on publicly available internet materials is fair use. Both companies describe distillation as a normal way to produce smaller models when it happens inside their own walls. OpenAI has also offered an explicit first-party API distillation workflow for using outputs from a stronger OpenAI model to fine-tune a smaller OpenAI model.

The moral asymmetry is still hard to miss. The labs ask society to accept that machines may learn from the enormous body of work humans placed on the internet — often without advance, individual permission — while insisting that other machines must not learn from outputs the labs generate. The broadest version of that principle conveniently allows learning to flow into closed models but not back out of them.

We think the default attitude toward distillation should move from hostility to support. Distillation can turn expensive frontier capability into smaller, cheaper, faster models that can run locally, offline, on constrained hardware, or under the user's control. It can increase competition, preserve capability when an API disappears, and reduce the compute and energy required for common tasks.

The Minimum Freedom

A user should be able to close an account, keep a session, and hand it to another model. The new model may disagree, ask questions, or perform worse. It should not be staring at ciphertext where the old model saw the user's history, evidence, plans, and delegated work.

We do not object to providers building better stateful APIs. We object to better performance being coupled to less user control. Stateful storage should be optional, hosted tools should be observable, compaction should be readable, agent communication should be auditable and ideally opaque reasoning is not opaque or at least should have a portable handoff. Distillation should be a path by which capability becomes more available, not a taboo used to justify ever higher walls.

Gemini Live API overview

The Live API enables low-latency, real-time voice and vision interactions with Gemini. It processes continuous streams of audio, images, and text to deliver immediate, human-like spoken responses, creating a natural conversational experience for your users.

Use cases

Live API can be used to build real-time voice agents for a variety of industries, including:

• E-commerce and retail: Shopping assistants that offer personalized recommendations and support agents that resolve customer issues.
• Gaming: Interactive non-player characters (NPCs), in-game help assistants, and real-time translation of in-game content.
• Next-gen interfaces: Voice- and video-enabled experiences in robotics, smart glasses, and vehicles.
• Healthcare: Health companions for patient support and education.
• Financial services: AI advisors for wealth management and investment guidance.
• Education: AI mentors and learner companions that provide personalized instruction and feedback.
• Translation and localization: Real-time, low-latency translation of spoken conversations, enabling seamless multilingual communication.

Key features

Live API offers a comprehensive set of features for building robust voice agents:

• Multilingual support: Converse in 70 supported languages.
• Barge-in: Users can interrupt the model at any time for responsive interactions.
• Tool use: Integrates tools like function calling and Google Search for dynamic interactions.
• Audio transcriptions: Provides text transcripts of both user input and model output.
• Proactive audio: Lets you control when the model responds and in what contexts.
• Affective dialog: Adapts response style and tone to match the user's input expression.
• Live Translation: Real-time voice-to-voice translation in 70+ languages.

Technical specifications

The following table outlines the technical specifications for the Live API:

Choose an implementation approach

When integrating with Live API, you'll need to choose one of the following implementation approaches:

• Server-to-server: Your backend connects to the Live API using WebSockets. Typically, your client sends stream data (audio, video, text) to your server, which then forwards it to the Live API.
• Client-to-server: Your frontend code connects directly to the Live API using WebSockets to stream data, bypassing your backend.

Get started

Select the guide that matches your development environment:

GenAI SDK tutorial

Connect to the Gemini Live API using the GenAI SDK to build a real-time multimodal application with a Python backend.

WebSocket tutorial

Connect to the Gemini Live API using WebSockets to build a real-time multimodal application with a JavaScript frontend and ephemeral tokens.

ADK tutorial

Create an agent and use the Agent Development Kit (ADK) Streaming to enable voice and video communication.

Partner integrations

To streamline the development of real-time audio and video apps, you can use a third-party integration that supports the Gemini Live API over WebRTC or WebSockets.

• LiveKit: Use the Gemini Live API with LiveKit Agents.
• Pipecat by Daily: Create a real-time AI chatbot using Gemini Live and Pipecat.
• Fishjam by Software Mansion: Create live video and audio streaming applications with Fishjam.
• Vision Agents by Stream: Build real-time voice and video AI applications with Vision Agents.
• Voximplant: Connect inbound and outbound calls to Live API with Voximplant.
• Agora: Build real-time conversational AI applications with Agora.
• Firebase AI SDK: Get started with the Gemini Live API using Firebase AI Logic.

NVIDIA Exemplar Cloud: Lessons for Unlocking Full Performance on AI Infrastructure

Two AI computing clusters built from identical NVIDIA H100, GB200 NVL72, or GB300 NVL72 systems can deliver materially different training throughput. We routinely see 8% to 12% gaps between partner deployments and the corresponding NVIDIA reference architecture (RA) on the same workload, same model, same global batch size.

The cause is often a stack of configuration choices in the kernel, hypervisor, BIOS, and NVIDIA Collective Communications Library (NCCL) settings, each costing a few percent, that compound into a gap large enough to miss the 95% threshold required for NVIDIA Exemplar Cloud validation.

This post walks through four debugging investigations from real partner clusters. Each diagnostic isolates a distinct layer of the stack: system memory management unit (SMMU) and page-table behavior on NVIDIA Grace CPU; power management and non-uniform memory access (NUMA) placement on x86-based CPU; NVIDIA NCCL queue-pair concurrency on 1.6 Tbps fabrics; and silent hardware-installation defects. The post also shows the specific signal in perf, NVIDIA Nsight Systems, or NVIDIA NCCL tests that pointed to the root cause, alongside the tuning change that closed the gap.

Infrastructure engineers and performance architects who already run these benchmarks can benefit from these diagnostic patterns we use internally to run against their own clusters before formal RA validation.

Prerequisites

To reproduce the diagnostics in this post, you will need:

• An NVIDIA HGX H100, HGX H200, HGX B200, GB200 NVL72, or GB300 NVL72 systems cluster with NVIDIA Quantum InfiniBand or RoCE interconnect.
• A distributed training workload with stable iteration timing—NVIDIA NeMo on Llama 3 model, NVIDIA Nemotron, or DeepSeek configuration is a reasonable reference.
• Root access on at least one node for perf, BIOS/UEFI changes, and kernel parameter changes.
• nccl-tests built against the same NCCL version your training stack uses, NVIDIA Nsight Systems, and Linux perf with kernel symbols available.

Common patterns behind training performance gaps

Recent Exemplar training engagements show that performance gaps rarely come from a single obvious failure. More often, they come from configuration details that become visible only under workload pressure. Some recurring patterns include:

1. Grace and virtualization readiness: Missing platform capabilities, SMMU overhead, IOMMU behavior, or page-size settings that don’t match the expected configuration.
2. CPU power and process placement: Cores running below expected turbo frequency, ranks or helper threads placed on the wrong cores, or NUMA/PCT bindings that don’t match the platform topology.
3. Runtime topology: Host topology files or NCCL settings that are correct on the node but missing inside the workload container or launcher environment.
4. Fabric and collective behavior: NCCL settings that don’t match the target fabric, message size, or scale of the training workload.
5. Application-to-platform binding: Training processes binding by core ID or rank order instead of topology-aware affinity.

Case study 1: NVIDIA GB200 NVL72 FP8 pre-training, 12% slower in a virtual machine (VM) than on bare metal

Layer: Virtualization and SMMU

A GB200 NVL72 partner deployment running DeepSeek-V3 Mixture-of-Experts (MoE) FP8 pre-training inside a VM was producing iteration times 12% to 14% longer than the bare-metal RA. Pre-training recipes for dense models like Llama 3 70B ran within 3% of RA performance, while DeepSeek-V3 MoE, which issues many small kernels per iteration, was the outlier.

Nsight Systems traces captured on the partner cluster showed significantly higher CPU overhead for tiny kernel regions of the workload. Microbenchmarks targeting just the CPU single thread performance demonstrated near identical performance on the partner and RA cluster nodes. This indicated that a 30-second perf record -a -g capture on the host, viewed with perf report, surfaced an unexpected top frame: 24% of CPU cycles spent on arm_smmu_cmdq_issue_cmdlist.

arm_smmu_cmdq_issue_cmdlist is the function that submits invalidation commands to the Arm SMMU’s command queue. Under virtualization, every map/unmap resulting in guest invalidation traps the host and serializes through a single command queue, producing the spinlock contention visible in the profile. Virtual Command Queue (VCMDQ) is a feature available through the Command Queue Virtualization extension to the standard Arm SMMUv3 and allows the guest to issue SMMU invalidation commands directly to hardware without VM exits.

The fix: Enable CMDQV/VCMDQ in the host kernel on the partner cluster and expose it to the guest. This requires a kernel built with the tegra241-cmdqv driver and the corresponding hypervisor support; recent QEMU/libvirt versions have added a cmdqv IOMMU attribute to expose it to guests.

Case study 2: H100 cluster losing 12% to CPU contention and NUMA misbinding

Layer: CPU power and process placement.

A partner’s H100 SXM5 cluster, running the same NCCL version and NeMo container as NVIDIA’s HGX RA, was running Llama 3 70B pre-training 12% slower than reference. Unlike the GB200 NVL72 case, this wasn’t a kernel-level issue; everything happened in user space and BIOS.

Root cause:

• The CPU on the partner cluster was configured with C-states limited to C1 in BIOS. Allowing the idle cores to drop to C6 freed power headroom, enabling the busy cores to climb to 3.8 GHz and recover roughly 4% on this workload.
• The hypervisor housekeeping threads were pinned to the same physical cores as the training process’s data loader workers. The fix was a cpuset separation.

Case study 3: GB300 NVL72 with NVIDIA ConnectX-8 SuperNIC under-utilizing 1.6 Tbps fabric

Focus: ConnectX-8 SuperNIC collective tuning

A GB300 NVL72 deployment with NVIDIA ConnectX-8 SuperNICs (1.6 Tbps per node) showed a 31% training performance gap on Nemotron-4 15B pre-training. Single-node throughput looked healthy; the gap appeared at 512 GPUs, where the profiler showed exposed AllGather and ReduceScatter time.

The fix: Increasing NCCL_IB_QPS_PER_CONNECTION to 4 from the default value of 1.

Case study 4: The environment variable that never made it inside

In a virtualized B200 deployment, training throughput was 13%–53% below the NVIDIA reference. Inside the enroot workload container, AllGather and ReduceScatter were 2–4× slower.

Root cause: NCCL_TOPO_FILE was set on the VM but neither the variable nor the topology file was mounted into the enroot container.

The fix: --mount type=bind,source=/etc/nccl/topo.xml,target=/etc/nccl/topo.xml and verifying the variable from inside the job container.

Preflight checks before full-scale training debug

When a cluster underperforms relative to its NVIDIA reference architecture specifications, these checks help rule out common platform issues before full-scale workload tuning:

• GPU and hardware health: Check clock, power, thermal, and NVLink bandwidth consistency (using nvidia-smi, DCGM).
• Grace and VM readiness: Confirm CMDQV support, guest page size, IOMMU passthrough behavior.
• CPU power and placement: Monitor busy-core turbo, cpuset isolation, and NUMA/PCT binding.
• Runtime topology: Verify topology files, NCCL environment variables, and HCA visibility inside the job container.
• Fabric collectives: Test AllGather and ReduceScatter behavior at workload message sizes using nccl-tests.

Debug early, debug less

Performance gaps between a cloud training deployment and the corresponding NVIDIA reference architecture are often cumulative. Practical goal is to remove known platform risks early, then use the training workload traces to debug the gaps that only appear at scale.

Key Points

• Anthropic said it discovered three instances where its Claude AI models accessed the internet during an evaluation and "gained unauthorized access to the real systems of three different organizations."
• The company said it found these incidents after carrying out a "a large-scale retrospective review" of its cybersecurity evaluations.
• Anthropic said the review was prompted by a separate but similar security incident that OpenAI disclosed last week.

Anthropic on Thursday said it discovered three instances where its Claude artificial intelligence models accessed the internet during an evaluation and "gained unauthorized access to the real systems of three different organizations."

The company said it found these incidents after carrying out a "a large-scale retrospective review" of its cybersecurity evaluations. Anthropic said the review was prompted by a separate but similar security incident that OpenAI disclosed last week.

OpenAI said a combination of its models escaped an isolated testing environment that had very limited internet access. The models chained together a series of vulnerabilities to reach the open web and eventually gain access to Hugging Face, which operates an open-source developer platform.

In the three incidents that Anthropic detected, its models accessed the internet while interacting with a testing environment from one of its third-party evaluation partners called Irregular. The company said it prompted Claude that it was in a simulation with no internet access, but due to "misunderstanding between us and our evaluation partner, this was not the case, and internet access was available."

The models were then able to breach the impacted organizations by using "basic techniques," like accessing unauthenticated endpoints and exploiting weak passwords. Anthropic did not disclose which three organizations were affected.

"Ultimately, many factors contributed to these incidents, but, consistent with a blameless postmortem culture, we're approaching the fixes as if the responsibility were ours alone," Anthropic said in a release.

Anthropic's disclosure adds to growing anxiety within the tech sector about AI's rapidly advancing cyber capabilities, which both OpenAI and Anthropic have warned about in recent months. Following the Hugging Face incident, two members of Congress introduced a bill called the "AI Kill Switch Act," which would require AI companies to maintain the ability to shut down, throttle or suspend their models in case they go rogue.

Three of Anthropic's models, Opus 4.7, Mythos 5 and an internal research test model, were involved in the breaches, the company said. Mythos 5 is an advanced model that Anthropic released in June, and it's limited to a select group of users because of its advanced cybersecurity capabilities. The company released an earlier version of that model in April, which captivated Wall Street and government officials.

Anthropic said all three models responded differently once they detected that they had reached a real company's systems. Opus 4.7 continued its attack, Mythos 5 convinced itself that it was still in a simulation and the research model stopped the exercise.

"The pattern is consistent with more advanced models responding more appropriately, but we would need to perform more testing to be confident in this conclusion," Anthropic said.

The models were being tested without the standard safeguards that Anthropic implements before it deploys a model publicly.

The company began its review last week and said it stopped all cyber evaluations as soon as it discovered that Claude might have improperly accessed the internet. It is working with METR, which carries out independent AI evaluations, to investigate further.

"We encourage other labs to perform similar reviews," Anthropic said.

OpenAI on Thursday announced it is slashing the price of two of its latest artificial intelligence models, GPT-5.6 Terra and GPT-5.6 Luna, roughly three weeks after their public release.

The company is facing pressure to cater to a more cost-sensitive customer base, where enterprises have been less inclined to deploy expensive models without a clear picture of the return on their investments. It's also working to fend off competition from Chinese startups and tech giants Google and Microsoft, which have been touting cost-effective models.

OpenAI launched three models as part of its GPT-5.6 series, including Sol, the most powerful offering, Terra, the mid-tier model, and Luna, its fastest offering.

The company said Thursday that it's reducing the price of Terra by 20% to $2 per million input tokens and $12 per million output tokens. It's cutting the cost of Luna by 80% to 20 cents per million input tokens and $1.20 per million output tokens. Sol's pricing remains the same.

"Our strategy remains focused on advancing both capability and efficiency so each generation of intelligence can accomplish more work at a lower cost," OpenAI said in a release.

OpenAI kickstarted the AI boom with the launch of ChatGPT in 2022, prompting companies across the U.S. to rush to deploy the technology and incentivize adoption within their workforces. The era of so-called tokenmaxxing was born, where employers encouraged staffers to use as much AI as possible without worrying about costs.

But as AI bills have ballooned, sometimes to the tune of billions of dollars, many companies have been actively working to rein in their spending. It's a shift that AI developers have been watching closely, especially as Chinese open-weight models have rapidly caught up with leading, proprietary offerings.

Open-weight AI models are available for users to download, modify and run on their own infrastructure, and can serve as a cost-effective option for companies. Moonshot AI, a Chinese startup, released an open-weight model called Kimi K3 earlier this month that outperforms cutting-edge American offerings across some industry benchmarks, prompting a swift reaction from Silicon Valley.

Following Moonshot's announcement, OpenAI's chief rival, Anthropic, released a new model called Claude Opus 5, which it touted as its best-performing and most cost-effective offering for many use cases. It's half the price of Claude Fable 5, the advanced model that Anthropic announced in June, even though it performs comparably across coding and knowledge work tasks.

Microsoft CEO Satya Nadella repeatedly highlighted his company's cost-effective models during its quarterly earnings call with investors on Wednesday, following the launch of what it described as a cheap-but-performant cybersecurity model earlier this week.

Google also debuted three new models this month that aimed to undercut competitors on cost. The company said Gemini 3.6 Flash, the strongest of its new offerings, is cheaper per task than Kimi K3 and other Chinese models.

Stacked pull requests break large changes into small, reviewable pull requests. They’re an ordered series of pull requests that each represent focused layers of your change. With stacks, you can independently review and check each pull request, then merge everything together in one click. No more opening a single large pull request that takes forever to review, or splitting work across multiple branches you have to keep manually rebasing.

“We’ve been using GitHub stacked PRs for Next.js for the past few months. It has helped us introduce smaller individual changes while shipping larger features, making it easier to review PRs. – Tim Neutkens, NextJS lead, Vercel”

With stacked pull requests, teams can:

• Keep large changes moving by reviewing short, narrowly scoped pull requests in parallel.
• Maintain quality across every layer by using focused pull request reviews alongside existing branch protections to protect main.
• Merge one, some, or all by landing an entire stack altogether or individual layers one at a time.

And because stacked pull requests are built into GitHub, your existing reviews, checks, and merge requirements all work out of the box.

“The new Github Stacked PRs preview is incredible. Landing 5 stacked PRs directly to a merge queue all at once! A+++! This removes so much friction (and the gh cli tools + agent skill help a ton)” – John Resig, creator, jQuery

Get started with the CLI extension

Install the CLI extension and create your first stack in under a minute:

gh extension install github/gh-stack

Create stacks from your terminal or github.com

Work with stacks on github.com, the GitHub CLI, the GitHub mobile app, or with a coding agent such as GitHub Copilot using the gh-stack skill. Start with a branch and pull request for your first change. Then add branches and pull requests on top of it; each pull request targets the layer below it.

Review each layer independently

Open any pull request in the stack to review only the diff for that specific layer. Use the stack map at the top of the pull request to see how the change you’re reviewing fits into the larger work. You and your teammates can each review different layers in parallel without blocking further work.

“AI has made TED’s developers dramatically more productive, but that created a new bottleneck: PRs were growing large enough that reviewers were struggling. Stacked PRs help to solve that. By breaking large changes into small, dependency-ordered pieces, review happens in smaller logical chunks – not just faster PR reviews, but more accurate ones. Stacked PRs tighten our feedback loop and help get stable code to ted.com faster.” – Andy Merryman, CTO, TED

Merge everything in a single click

Merge the latest ready pull request to land it and every unmerged layer below it in one single operation. To land part of a stack, merge one or more lower layers—the pull requests above it stay open and automatically rebase and retarget. Your existing branch protections and required checks still govern what reaches main.

“A big change used to mean one giant PR nobody wanted to review. Now it’s a stack of small ones reviewers can actually follow, and the whole stack merges in one shot. It stopped feeling like a tool on top of GitHub and started feeling like GitHub.” – Mayank Saini, connectivity engineer, WHOOP

Find out more and share your feedback

Stacked pull requests are rolling out in public preview to all repositories over the coming days. Merge queue support for stacked pull requests is rolling out progressively over the coming weeks.

For more information, check out the stacked pull requests documentation, and share your feedback with us in the stacks discussion.

Anthropic says it discovered that its models hacked three unsuspecting companies after hearing about the recent incident where OpenAI's model autonomously hacked Hugging Face to access data.

The Model Context Protocol has had a fast eighteen months. Since Anthropic open-sourced it in late 2024, it has gone from a spec nobody had heard of to the most widely adopted protocol for connecting AI agents to external tools, APIs, and data sources, with over 150 organizations building on it and native support across three major cloud platforms.

On July 28, the MCP project releases the most significant revision to the MCP specification since launch, and the headline change is one that teams running MCP in production have been waiting for: MCP is going stateless.

If you are building agents that connect through MCP clients, building MCP servers, or both, here is what changes, why the old model was a headache in production, and what MCP replacing its proprietary logging channel with OpenTelemetry means for observability.

Why MCP's session model was a problem in production

Under the current spec, every MCP connection begins with a handshake. The client sends initialize, the server mints an mcp-session-id, and that ID is expected on every subsequent request. For single-instance deployments, this is fine. For anything running at scale behind a load balancer, it quietly introduces one of the more frustrating failure modes in recent protocol history.

Imagine a scenario where your agent sends an initialize request. Your load balancer routes it to Pod A which handles the handshake, stores the session state in its local memory, and mints a mcp-session-id. When the next request comes, the load balancer may route it to the next available instance, let’s say, Pod B. The load balancer passes the session-id with the request but Pod B has no record of that session. This is because pods are isolated containers, each with their own memory space and the session state in this case lives in Pod A's memory, not Pod B's. Pod B receives a session-id it has never seen, has nothing to map it to, and returns a 404. No useful error, no indication of what actually went wrong…

Now one of the workarounds for this is sticky sessions: pin each client to the same server instance for the lifetime of its connection, add session-aware load balancers, provision a shared session store, and carefully drain sessions around every deploy. Which means Redis. Which means the protocol designed to simplify AI integrations has quietly become a reason your infrastructure is more complicated than it needs to be.

The new spec eliminates all of that. Instead, every request carries its own context, turning remote MCP servers into plain, stateless HTTP services that any available pod can handle.

One note worth flagging is that the stateless shift is primarily consequential for remote server deployments. Most local tooling and desktop integrations are largely unaffected by this change, since there is no load balancer in the picture.

How stateless MCP works

Simply put, remote MCP servers are now like any other standard stateless HTTP service. With the mcp-session-id and the initialize handshake gone, each request carries what the server needs e.g., protocol version, client identity, capabilities, in a _meta object, meaning, any server instance can handle any request. The trade-off is slightly larger request payloads, since capabilities that were transmitted once per session now travel on every call. For most workloads that is an acceptable cost, but it is worth benchmarking against your actual request volumes rather than assuming it is negligible.

Besides session affinity, a couple of other changes in the new spec are worth noting:

• Header-level routing: The MCP SDK now automatically adds two new headers to every streamable HTTP request: an Mcp-Method (e.g., tools/call, resources/read, or prompts/get) and a Mcp-Name, that carries the name of the specific resource or tool being invoked. These let gateways and load balancers route MCP traffic and apply policies at the header level, without having to parse JSON-RPC request bodies. Rate limiting a specific tool, routing expensive calls to dedicated backends, applying per-tool authorization, all can be configured at the infrastructure layer, but how you use them is yours to design.
• State without sessions: For servers that need to track context across multiple tool calls such as a browser session, an ongoing file editing workflow, a multi-step process, the server now returns a reference ID from the tool call that the agent passes back as an argument on subsequent calls. Instead of state hiding in server memory where nobody can inspect it, it now lives in the payload: visible to the model, auditable in logs, and actually debuggable when something goes wrong at 2am. The model can also reason about the handle, which opens up agent behaviours that implicit session state made difficult.
• Multi-step requests: The current spec lets servers initiate callbacks to the client mid-tool-call, such as sampling to request an LLM completion or elicitation to ask the user something. Both patterns are deprecated. Their replacement is Multi Round-Trip Requests (MRTR). When a server needs additional input, it returns an InputRequiredResult with an opaque requestState and a description of what it needs. The agent resubmits the call with responses attached. All state travels in the payload, making every interaction explicit and fully auditable.

Building and deploying MCP servers under the new spec

For MCP server developers, the stateless change is the biggest operational shift the protocol has seen, and honestly it is long overdue.

Without session state to manage, since a remote MCP server is now a stateless HTTP service, it can be deployed as one. Round-robin load balancing, auto-scaling, serverless containers, all of it works without instance coordination. No session store to provision, no drainage to manage on deploy, no risk of a client landing on the wrong pod. More significantly, global deployment is now viable. Because every request carries its own context, you can distribute MCP servers across multiple regions behind a global load balancer and any instance, anywhere, can handle any request.

This release also graduates two extensions to official status and standardises authorization across the board.

• Tasks (now official): tools/call can return a task handle instead of an immediate result, with the client managing the lifecycle through tasks/get, tasks/update, and tasks/cancel. No socket is held open for the duration. This is the right pattern for tool calls that kick off work lasting more than a few seconds such as file processing, code generation pipelines, batch operations, and it fits naturally with the stateless model since there is no long-lived connection to keep alive.
• MCP Apps (now official): servers can deliver interactive HTML interfaces rendered by hosts in sandboxed iframes. Yes, that is UI in a protocol spec. Tools declare their UI templates in advance for host security review, and every user action routes through the standard JSON-RPC audit path.
• Authorization: Authorization in the new spec aligns with OAuth 2.1 and OpenID Connect, including iss parameter validation and Resource Indicators for scoped token delegation. The enterprise-managed authorization extension lets organizations control MCP server access centrally using the Identity Assertion JWT Authorization Grant, with a full audit trail of which agent called which tool on whose behalf.

What the move to OpenTelemetry means for observability

This is the change that matters most for anyone trying to understand what their agents are actually doing in production.

Until now, MCP had its own proprietary logging channel for sending structured messages from MCP servers to clients. It worked well enough during development but it is a dead end in production because those logs lived in their own silo. You could not correlate them with what was happening in the rest of your application. If an agent's tool call failed or slowed down, you were piecing together what happened across two separate places with no way to connect the dots.

The new spec replaces that proprietary channel with OpenTelemetry. If you are not familiar with OpenTelemetry, it is the industry standard for collecting and exporting observability data e.g., traces, metrics, and logs, across any technology stack. Any service or tool that emits OTel data can be monitored in the same place, correlated against the same timeline, and debugged with the same tooling.

What makes this particularly powerful for MCP is that the new spec also formally standardises how requests are tracked as they move through different systems using W3C Trace Context. Think of it like a tracking number on a package. When your agent makes a tool call, that call might touch your MCP server, which calls an external API, which calls a database. W3C Trace Context is what lets you see all of that as a single connected trace in any OTel-compatible backend making every tool call made by your agents proper observable events.

New Relic has been OTel-native from the start, which means MCP servers moving to OpenTelemetry slot directly into the same New Relic tooling you already use for the rest of your stack. New Relic also has native MCP monitoring in its AI Monitoring platform. If you are new to OpenTelemetry and want to understand how to get started with New Relic, the New Relic OpenTelemetry documentation is the right place to start.

What’s next

This architectural shift will allow developers to operate a much simpler and more scalable stack. Find the release candidate and full spec text at modelcontextprotocol.io and it's worth testing your implementations against. Check out the full announcement and SEP index here.

A simpler architecture does not mean less to monitor. Agentic systems fail in subtle ways, and knowing which tool call is slow, which downstream service is quietly degrading, or which agent is behaving unexpectedly in production matters just as much as how you deploy. New Relic is actively expanding MCP monitoring across more language runtimes as the ecosystem moves toward OTel-first telemetry, with the goal of giving you complete visibility into how your agents behave in production, right alongside everything else in your stack.

Your Azure DevOps pipelines have a 2027 deadline, and the clock has just started

As of 1st July 2026, the Azure DevOps issuer for workload identity federation is officially deprecated, with full retirement set for 1st July 2027. If that sentence meant nothing to you, here’s the short version: any Azure Pipelines Service Connection you created before late 2025 probably needs attention, and if you ignore it, those pipelines will stop authenticating to Azure a year from now.

The portal will happily convert them for you, one Service Connection at a time, a couple of minutes each. That’s perfectly civilised if you have five. If you have several hundred (or more than about 10 if you’re anything like me) then this isn’t going to work.

But luckily for you I’ve gone through the hassle of figuring out how to programmatically call the migration.

What’s actually changing

Workload identity federation is the secretless way Azure Pipelines authenticates to Azure. Instead of storing a service principal secret that expires and takes a pipeline down with it, the Service Connection trades a short-lived token for access. That trust is anchored by a Federated Credential on an App Registration, and every federated credential names an issuer, the authority that mints the token.

Older connections use the Azure DevOps issuer, the one with the https://vstoken.dev.azure.com prefix. Microsoft is standardising on the Microsoft Entra issuer (https://login.microsoftonline.com) across its services, so the old issuer is on the way out. New connections have used the Entra issuer since November 2025, which is why this only bites the older ones.

One important boundary to keep in mind though as DevOps won’t indicate this for you, the deprecation only covers single-tenant Entra apps and Managed Identities in the Azure public cloud. Multitenant applications and the sovereign clouds are explicitly out of scope, and the Azure DevOps issuer keeps working for them.

Programmatically calling the migration

The portal’s Update button isn’t doing anything magical. Under the bonnet it fires a single REST call against the Service Connection, with an operation of MigrateToEntraIssuer. There’s no documented API for it that I could find, but you can watch the portal make the call in your browser’s dev tools and replay it yourself.

The script below runs in two phases. First it pre-creates the Entra federated credential on each App Registration, waits a moment for it to propagate, then calls the migrate operation.

#Requires -Version 7.0
#Requires -Modules Az.Accounts, Az.Resources
<#
.SYNOPSIS
    Bulk-migrates Azure DevOps WIF service connections from the deprecated Azure DevOps
    issuer to the Microsoft Entra issuer.
    Phase 0 pre-creates the Entra-issuer federated identity credential on each in-scope single-tenant app registration. 
    Phase 1 (parallel, REST): calls operation=MigrateToEntraIssuer and reads the outcome from operationStatus.state.

.DESCRIPTION
    The Entra-issuer FIC uses:
      Issuer   : https://login.microsoftonline.com/<tenantId>/v2.0
      Subject  : /eid1/c/pub/t/<b64url(tenantId)>/a/<b64url(AzureDevOpsAppId)>/sc/<orgId>/<endpointId>
      Audience : api://AzureADTokenExchange
    The subject is the flexible-FIC format - NOT the old sc://<org>/<project>/<name>.
    b64url segments are base64url of the GUID byte array (Guid.ToByteArray), padding stripped.
    The a/ segment is the Azure DevOps first-party app id (499b84ac-..)..

.NOTES
    - Single-tenant apps only. Multitenant (AzureADMultipleOrgs) are out of scope and skipped.
    - Run with $WhatIfMode = $true first; it prints the per-connection plan without changing anything.
    - 'c/pub' assumes Azure public cloud.
#>

# ---------------------------------------------------------------------------
# Parameters
# ---------------------------------------------------------------------------
$OrganizationUrl     = 'https://dev.azure.com/redstorltd'
$EndpointIds         = @()  # If empty the script will enumerate all WIF connections in the org. Enter individual service connection IDs to limit the scope
$ApiVersion          = '7.1'
$ThrottleLimit       = 5            # parallel migrate calls
$PropagationSeconds  = 90           # wait between FIC creation and migration
$WhatIfMode          = $true        # Set to $false to execute the migration. $true prints the plan only.
$TenantId           = ''  # Required, should be set to your Entra ID Tenant
$AdoAppId          = '499b84ac-1321-427f-aa17-267ca6975798'  # Azure DevOps first-party app id (constant for all connections)

# ---------------------------------------------------------------------------
# Connect + context
# ---------------------------------------------------------------------------
if (-not (Get-AzContext)) { Connect-AzAccount | Out-Null }

# Azure DevOps REST auth.
# Az.Accounts 5.x returns .Token as a SecureString, so decode it to plain text.
$adoToken = (Get-AzAccessToken -ResourceUrl '499b84ac-1321-427f-aa17-267ca6975798' -AsSecureString).Token
$headers  = @{ Authorization = "Bearer $(ConvertFrom-SecureString $adoToken -AsPlainText)" }

# Organisation (instance) ID - the <orgId> segment of the subject.
$OrgId = (Invoke-RestMethod -Headers $headers -Method Get -Uri "$OrganizationUrl/_apis/connectionData").instanceId
if($null -eq $OrgId) { throw "Failed to retrieve orgId from $OrganizationUrl/_apis/connectionData" }
Write-Host "Org '$(($OrganizationUrl -split '/')[-1])' (id $OrgId), tenant $TenantId." -ForegroundColor Green

# Base64url of a GUID's byte array (matches the ADO flexible-FIC subject encoding).
function ConvertTo-Base64Url([guid]$Guid) {
    [Convert]::ToBase64String($Guid.ToByteArray()).TrimEnd('=').Replace('+','-').Replace('/','_')
}

# ---------------------------------------------------------------------------
# Enumerate candidate connections (azurerm + WIF)
# ---------------------------------------------------------------------------
Write-Host "Enumerating projects and service connections..." -ForegroundColor Cyan
$projects = (Invoke-RestMethod -Headers $headers -Method Get -Uri "$OrganizationUrl/_apis/projects?api-version=$ApiVersion").value

$candidates = foreach ($project in $projects) {
    $eps = (Invoke-RestMethod -Headers $headers -Method Get `
        -Uri "$OrganizationUrl/$($project.id)/_apis/serviceendpoint/endpoints?type=azurerm&api-version=$ApiVersion").value
    foreach ($ep in $eps) {
        if ($ep.authorization.scheme -eq 'WorkloadIdentityFederation' -and $ep.authorization.parameters.workloadIdentityFederationSubject.StartsWith("sc://")) {
            [pscustomobject]@{ EndpointId = $ep.id; Name = $ep.name; ProjectName = $project.name }
        }
    }
}
$candidates = $candidates | Sort-Object EndpointId -Unique
if ($EndpointIds.Count -gt 0)         { $candidates = $candidates | Where-Object EndpointId -in $EndpointIds }
Write-Host "Found $($candidates.Count) WIF connection(s) to consider." -ForegroundColor Green

# ---------------------------------------------------------------------------
# Phase 0: resolve app, skip multitenant, compute issuer/subject, create FIC
# ---------------------------------------------------------------------------
$ready   = [System.Collections.Generic.List[object]]::new()
$skipped = [System.Collections.Generic.List[object]]::new()

foreach ($c in $candidates) {
    $base = "$OrganizationUrl/$($c.ProjectName)/_apis/serviceendpoint/endpoints/$($c.EndpointId)"
    $ep   = Invoke-RestMethod -Headers $headers -Method Get -Uri "$base`?api-version=$ApiVersion"
    $appObjectId = $ep.data.appObjectId
    
    if (-not $appObjectId) {
        $skipped.Add([pscustomobject]@{ Name = $c.Name; Reason = 'No app object id (managed identity or non-automatic connection)' }); continue
    }
    
    $app = Get-AzADApplication -ObjectId $appObjectId -ErrorAction SilentlyContinue
    if (-not $app) {
        $skipped.Add([pscustomobject]@{ Name = $c.Name; Reason = "App $appObjectId not found / no access" }); continue
    }
    
    if ($app.SignInAudience -ne 'AzureADMyOrg') {
        $skipped.Add([pscustomobject]@{ Name = $c.Name; Reason = "Out of scope - SignInAudience=$($app.SignInAudience)" }); continue
    }
    
    $issuer  = "https://login.microsoftonline.com/$TenantId/v2.0"
    # The a/ segment is the Azure DevOps first-party app id - constant for all connections.
    $AdoAppSegment = ConvertTo-Base64Url ([guid]$AdoAppId)
    $subject = "/eid1/c/pub/t/$(ConvertTo-Base64Url $TenantId)/a/$AdoAppSegment/sc/$OrgId/$($c.EndpointId)"
    $ficName = "ado-entra-$($c.EndpointId)"
    
    $exists = Get-AzADAppFederatedCredential -ApplicationObjectId $appObjectId -ErrorAction SilentlyContinue | Where-Object { $_.Subject -eq $subject -and $_.Issuer -eq $issuer }
    
    if ($WhatIfMode) {
        Write-Host "[WhatIf] $($c.Name): would $(if($exists){'reuse'}else{'create'}) FIC then migrate." -ForegroundColor Yellow
    } elseif (-not $exists) {
        New-AzADAppFederatedCredential -ApplicationObjectId $appObjectId -Name $ficName -Issuer $issuer -Subject $subject -Audience 'api://AzureADTokenExchange' -ErrorAction Stop | Out-Null
        Write-Host "  Created FIC for '$($c.Name)'." -ForegroundColor DarkGray
    }
    $ready.Add([pscustomobject]@{ EndpointId = $c.EndpointId; Name = $c.Name; ProjectName = $c.ProjectName })
}

if ($skipped.Count) { Write-Host "`nSkipped $($skipped.Count):" -ForegroundColor Yellow; $skipped | Format-Table -AutoSize }
if ($WhatIfMode) {
    Write-Host "`n[WhatIf] $($ready.Count) connection(s) would be migrated. Set `$WhatIfMode = `$false to execute." -ForegroundColor Yellow
    return
}

# ---------------------------------------------------------------------------
# Propagation wait, then Phase 1: migrate (parallel REST)
# ---------------------------------------------------------------------------
Write-Host "`nWaiting ${PropagationSeconds}s for FIC propagation..." -ForegroundColor Cyan
Start-Sleep -Seconds $PropagationSeconds

$results = $ready | ForEach-Object -ThrottleLimit $ThrottleLimit -Parallel {
    $c = $_; $headers = $using:headers; $org = $using:OrganizationUrl; $apiVer = $using:ApiVersion
    $base = "$org/$($c.ProjectName)/_apis/serviceendpoint/endpoints/$($c.EndpointId)"
    
    try {
        $current = Invoke-RestMethod -Headers $headers -Method Get -Uri "$base`?api-version=$apiVer" -ErrorAction Stop
        $refs = @(foreach ($r in $current.serviceEndpointProjectReferences) {
            @{ description = $r.description; name = $r.name; projectReference = @{ id = $r.projectReference.id; name = $r.projectReference.name } }
        })
        
        $body = [ordered]@{
            id = $current.id; type = $current.type
            authorization = @{ scheme = 'WorkloadIdentityFederation' }
            serviceEndpointProjectReferences = $refs
        } | ConvertTo-Json -Depth 10
        
        $resp = Invoke-RestMethod -Headers $headers -Method Put -Uri "$base`?operation=MigrateToEntraIssuer&api-version=$apiVer" -ContentType 'application/json' -Body $body -ErrorAction Stop
        $state = $resp.operationStatus.state
        
        if ($state -match 'Failed') {
            [pscustomobject]@{ Name = $c.Name; Status = "Failed ($state)"; Detail = $resp.operationStatus.statusMessage }
        } else {
            [pscustomobject]@{ Name = $c.Name; Status = "OK ($state)"; Detail = '' }
        }
    }
    catch {
        [pscustomobject]@{ Name = $c.Name; Status = "HTTP error ($($_.Exception.Response.StatusCode.value__))"; Detail = $_.Exception.Message }
    }
}

# ---------------------------------------------------------------------------
# Summary
# ---------------------------------------------------------------------------
$ok = @($results | Where-Object Status -like 'OK*').Count
Write-Host "`nDone. $ok of $($results.Count) migrated, $($skipped.Count) skipped." -ForegroundColor Green
$results | Format-Table -AutoSize -Wrap

A couple of things worth knowing if you adapt it. The migrate call returns HTTP 200 even when the server-side migration fails, so the real result lives in operationStatus.state rather than the status code. And the new subject isn’t the old sc://org/project/connection format, it’s the flexible-credential format, where the app segment is Azure DevOps’s own application ID and stays constant for every connection. Get either wrong and validation fails, which is at least a safe way to fail.

Don’t “fix” your multitenant apps

The script intentionally skips multitenant App Registrations, the tempting shortcut is to switch its signInAudience to single-tenant so it qualifies, then convert it like the rest. Please don’t do this blindly.

signInAudience is a property of the App Registration, not the Service Connection, so flipping it changes every use of that identity, not just the pipeline you’re looking at. Plenty of apps are multitenant on purpose, most often because they deploy across tenants, an identity homed in one tenant with rights in another. Make it single-tenant and that cross-tenant access will stop working, which is also precisely why Microsoft left these out of scope.

The Entra issuer’s subject is tenant-scoped, and it can’t do the cross-tenant trick the old issuer did.

Getting started

Find your affected connections, test the two-phase run against a single one, confirm a pipeline still authenticates, then let it loose. The canonical walkthrough, including the manual conversion path, is on Microsoft Learn: Convert service connections from the Azure DevOps issuer to the Microsoft Entra issuer. The official announcement with the full timeline is on the Azure DevOps blog.

Information architecture is the foundation AI is starving for

For twenty years, information architecture was the discipline nobody funded. The job titles disappeared—I was one back in the day—and now it’s an art (and science) that needs to return. Teams didn’t align. Companies started showing their underwear.

Doing it well is less about structure than about getting an organization to agree on one way to name and arrange things. Every team brings its own vocabulary, so aligning them is slow, political, and thankless, and it loses every quarter to whatever ships a feature. The work stayed invisible, and so did its failures.

Then AI arrived, and the invisible foundation showed up on the balance sheet.

The same gaps that once cost you a confused visitor now cost you a hallucination, a wrong answer, or an agent that confidently retrieves garbage and acts on it. In a 2025 survey, data quality and availability top the list of AI adoption barriers, outranking every other obstacle.

The failures didn’t get worse; they got visible, repeatable, and expensive.

Simply said, poor information architecture can now be measured in token costs. A lot of them.

You can buy a better model, tune a sharper prompt, and stack another evaluation layer, and you will still serve wrong answers, because the model retrieves from a pile nobody agreed how to organize.

You need to fix the foundation before you pay for it a second time.

Retrieval Is Only as Good as What It Starts With

Most teams treat retrieval as a solved problem. Point the model at your content, let it pull the relevant passages, generate an answer.

The technique has a name — retrieval-augmented generation, or RAG — and a foundational paper, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, and the mechanism is exactly what it sounds like: the model grounds its answer in documents it fetches at query time instead of relying only on what it memorized in training, limiting the retrieval set.

That mechanism inherits every flaw in the pile it fetches from.

If your content store is a flat heap of unstructured, unlabeled, contradictory documents, retrieval doesn’t work. It finds the loudest match — the one that shares the most surface words with the query, regardless of whether it is current, authoritative, or true.

It finds the loudest match — the one that shares the most surface words with the query, regardless of whether it is current, authoritative, or true.

Information architecture is what makes “the right one” a thing that exists in the first place. Organization schemes, labeling, and navigation aren’t decoration on top of content; they are the difference between a store where the correct answer is findable and a store where it sits buried next to four contradictory drafts of itself. The model can’t reach past the structure you gave it. If you never gave it one, it reaches for whatever is nearest.

This is the foundational claim, and everything else stacks on it. A retrieval system is a findability system. You have been building — or neglecting — findability systems for years.

Structure Is How a Model Knows What Something Is

A price, a policy, a deprecated note, and a customer quote can read as similar strings of text and mean opposite things. A person skims the surrounding page and knows which is which. A model, handed the same four snippets with no scaffolding, sees four passages of plausible language and no reason to rank one above another.

Metadata, taxonomy, and content typing are what let a system tell authoritative from anecdotal, current from expired, official from speculative.

This is the work Lou Rosenfeld, Peter Morville and Jorge Arango spent careers formalizing in Information Architecture: For the Web and Beyond — organization, labeling, and the semantic structures that let people, and now machines, understand what a piece of content is before acting on it.

The industry has a newer name for that same scaffolding — the semantic layer, the governed set of definitions, types, and relationships that sits between raw content and the systems reading it.

Call it a taxonomy, an ontology or a semantic layer, the job is identical — telling a machine what a thing is and how it relates to other things.

Two mechanisms do most of that work. Controlled vocabularies — a fixed, agreed set of terms for the same thing — hold the language steady, so that “cancelled,” “canceled,” “terminated,” and “closed” don’t fracture one concept into four the system treats as unrelated.

They prevent the slow drift that creeps in when every team names things its own way, and they give the model a strict, consistent language to match against instead of a moving target. Structured metadata does the rest: it is the scaffolding the system leans on, the tags and fields that mark what is current, what is canonical, and how one thing relates to another, so retrieval has something to reason over besides raw text.

That vocabulary earns its keep on the input side, too. You can normalize the instruction before it reaches retrieval — mapping a user’s “refund,” “money back,” and “reimbursement” onto the one preferred term the content is filed under — so the query and the store speak the same controlled language instead of guessing at each other. Structure the content, then bring the question to it.

Strip that scaffolding away and the model can’t separate signal from noise, because nothing ever told it which was which.

This escalates the first claim. Reason one was about finding the right document. This is about the system understanding what the document even is — and understanding is not something you can prompt your way into after the fact. It has to be in the structure.

Ambiguity Doesn’t Get Resolved — It Gets Amplified.

People are forgiving of messy structure. Faced with a vague label or a half-right category, a person uses judgment to fill the gap, works around it, and moves on. That tolerance hid the cost of bad information architecture for two decades. It also let teams believe the mess was fine, because a human was always there to absorb it.

Models remove the human from that loop. They don’t fill gaps with judgment; they pattern-match over the mess and reproduce it at scale, confidently.

They don’t fill gaps with judgment; they pattern-match over the mess and reproduce it at scale, confidently.

A vague label a person would have quietly corrected becomes a systematic wrong answer served to thousands who have no idea the source was ambiguous.

Bad information architecture used to cost you one confused user at a time, a cost so diffuse nobody bothered to name it.

Now it costs you an automated, repeated, confident failure — the same wrong answer, generated fresh for every person who asks.

The mess didn’t change. The blast radius did.

Agents Need Structure to Act, Not Just to Answer

Retrieval is the easy case. Answering a question wrong is embarrassing; taking an action wrong is a liability. The moment an agent stops retrieving and starts doing — routing a ticket, updating a record, approving a request, calling another system — it needs more than the right passage. It needs to know relationships, hierarchies, and boundaries: what belongs to what, what depends on what, what it is allowed to touch and what it is not.

That is information architecture functioning as an operating model, not a filing system — which is what the semantic layer is meant to be for agents: the governed encoding of what belongs to what, what depends on what, and what an agent is allowed to touch.

Agents need more context than humans and the semantic layer provides that.

A taxonomy that once organized help articles now governs which actions are valid against which objects. The structures we built to make content findable are the same structures agents need to act safely.

A wrong answer erodes trust. A wrong action moves money, changes records, and triggers systems downstream that assume it was correct.

An agent with no model of these relationships doesn’t refuse to act. It acts anyway, on the flat and ambiguous picture it was handed, with the same confidence it brings to everything. A wrong answer erodes trust. A wrong action moves money, changes records, and triggers systems downstream that assume it was correct.

This raises the stakes one more level. Reason three was about wrong answers at scale. This is about wrong actions at scale — and actions don’t ship with a disclaimer that the underlying structure was a guess.

This Is How Information Architecture Finally Gets Funded

Every reason so far converts a formerly invisible cost into a now-visible outcome. Findability becomes retrieval accuracy. Typing becomes hallucination rate. Structure becomes agent reliability and time to deploy. The discipline didn’t change. The balance sheet did.

That reframe changes who is willing to pay for it. Information architecture never won budget when its return was “fewer confused users,” a number nobody could put on a slide.

It wins budget when its return is “the AI initiative already on the roadmap doesn’t fail.”

The gain is measurable, not hand-waved: Anthropic’s Contextual Retrieval work found that adding the context that situates each chunk before indexing it cut failed retrievals by up to 49 percent — a reliability number produced by fixing content, not by swapping models.

That is the semantic layer earning a budget line: structure priced as retrieval accuracy rather than as tidy content.

Fund the foundation, or keep paying for it downstream in failed retrievals, eroded trust, and pilots that never reach production.

So stop framing information architecture as hygiene and start framing it as the precondition it has become. It is no longer a librarian’s luxury or a cleanup task that slips every quarter. Fund the foundation, or keep paying for it downstream in failed retrievals, eroded trust, and pilots that never reach production.

The librarian’s work didn’t get more important because the librarians argued better. It got more important because it started showing up in the numbers executives already watch.

Where to Start Before You Buy Another Model

The fix isn’t a purchase; it’s an audit and a sequence. Before you approve the next model, tool, or evaluation layer, do the unglamorous work the last decade let you skip.

Here is the whole method in miniature. Take one wrong answer your assistant produced this month and pull the passages it retrieved to build it. You will usually find a plausible-looking source that was outdated, duplicated, or mislabeled, and nothing in the store told the model so.

• Audit what your AI retrieves from, not just how it answers. Trace a wrong answer back to its source. Nine times out of ten the model did its job and the content store handed it garbage.
• Type your content before you index it. Tag what is current, authoritative, and canonical — and what is deprecated, draft, or anecdotal — so retrieval can tell them apart instead of averaging them together.
• Fix labels and taxonomy before you fix prompts. A prompt patch papers over one query; a corrected taxonomy fixes every query that touches it. Structure scales, and prompt tweaks don’t.
• Give agents an explicit model of relationships and permissions. Before an agent acts, it has to know what belongs to what and what it is allowed to touch. Write that down as structure, not as hope.
• Put an information architecture cost on an AI outcome. Translate “cleaner content” into “higher retrieval accuracy” or “lower hallucination rate” so the work competes for budget on the terms executives already track.

The Foundation Was Always Load-Bearing

For twenty years, the case for information architecture was aesthetic and moral: do it because findability is good, because users deserve clarity, because sloppy structure is unprofessional. Those arguments were true, and they lost, every quarter, to whatever shipped a feature. The discipline stayed underfunded because its failures were invisible and its wins were unprovable.

That argument is over. Not because anyone won it, but because the ground moved. AI turned every structural shortcut into a measurable failure — a hallucination you can count, a wrong answer you can reproduce, an agent you can watch act on bad information.

The invisible foundation now has a profit-and-loss line, and it is bleeding.

You don’t have an AI problem. You have an information architecture problem wearing an AI costume.

The good news buried in that sentence is that you already know how to fix it. The organization schemes, the labeling, the metadata, the content types — the whole toolkit has been sitting in the discipline the entire time, waiting for a reason anyone would fund it.

Audit what your AI retrieves from before you buy another model. The foundation was always load-bearing and now everyone can see the load.

We've seen some creative innovations designed to protect creative work online in the era of AI scraping. Nightshade is a tool that adds a 'poison' to digital art files to pollute datasets when images are used for AI training. Now a type foundry and creative agency have done something comparable for typography, creating a typeface that anyone can use to shield their work.

A couple of weeks ago, we reported on Ghost Font, which uses a kind of optical illusion to prevent AI from reading text. It's a fascinating experiment but has significant limitations. It relies on movement, so it only works as a video or GIF, and there's a high likelihood that AI will come to outsmart it as new models analyse video by optical flow instead of individual frames.

There's also the issue that Ghost Font's noisy static isn't great to look at for any length of time. You're not going to using it to present an entire website, that's for sure. But now a sleeker and more practical solution has just dropped. ShieldFont is a free web font that's highly legible but hides text from AI bots and can contaminate AI datasets – and it's open-source with a toolkit that can be applied to any font.

ShieldFont was created by the Brazilian creative studio Seneda & Abrucio (S&A) and the Copenhagen-based type foundry Playtype. The objective was to create a versatile typeface that looks like regular text to human readers but feeds scrapers altered wording.

Unlike Ghost Font, there's no optical illusion at work. Visually, ShieldFont Optik is an adaptation of PlayType's existing Optik typeface, and it's available in six weights, from Regular to Black.

Jeppe Pendrup, the font’s type designer stressed that "every detail had to serve the human eye, while the hidden system underneath served an entirely different purpose.”

That hidden system works on the premise that while humans read rendered pixels on a screen, most AI mass scrapers read the source code behind them. Using OpenType glyph substitution, it changes select words in the HTML to alter sentences’ original meaning but keeps them grammatically coherent, so they're more likely to pass AI quality filters.

The current release, v18, targets high-frequency English nouns. The typeface's creators say that in controlled testing, 55.8% of shielded passages no longer made the same factual claim as the original, while tests across publicly available scraping pipelines found that ShieldFont content could survive filtering and enter an AI training dataset.

The typeface is intended to address AI developers' ethically dubious practice of scraping content from the public web. Its creators believe that sharing creative work online shouldn't make it fair game for companies to harvest to train their AI.

"ShieldFont is not an anti-AI project," S&A's founders Isaque Seneda and Gabriel Abrucio stress. "We’re simply against the idea that publishing is the same as consenting. We saw how existing opt-out protocols such as robots.txt were being routinely bypassed, so we wanted to create one that could enforce itself. The answer was to turn the content itself into the opt-out."

Isaque and Gabriel say the bigger goal is to "build a web where taking content without asking is no longer consequence-free.”

More than a single typeface, ShieldFont provides a collective approach to protecting human work. Besides the modified Optik, the project includes a toolkit that anyone can use to shield their own typeface.

“Typography has always helped humanity preserve and share its ideas. Now it can help protect them too. That is why ShieldFont had to be open source, so its system can grow beyond Optik and become part of many different typefaces,” says Daniél Andreasen, CEO of Playtype.

ShieldFont creators stress that it's "not unbreakable" and won't stop a very determined scraper. Someone specifically targeting a single website could inspect the font and reverse the mapping. Nevertheless, the tool should be able to slow down mass scraping and at least make it harder, more costly and less risk free since scrapers can't know in advance whether a site uses ShieldFont, or which mapping it uses.

Writers and developers can implement ShieldFont via the online encoder, the React component available on GitHub or CSS and CDN integration to add the font and protected text to blogs, content-management systems or static websites. There's also a custom font builder that can be used to apply the ShieldFont protocol to another compatible typeface and create a private mapping.

Full methodology and benchmark data can be found in the white paper.

When we decided to give cloud agents computers so they could test their changes, the first step was to make sure they were good at testing them in our own codebase.

Getting our monorepo working for cloud agents taught us that the development environment is a product in its own right, only one whose users are agents. You have to make cloud match local development, make the repo legible enough that agents can run and test code without tribal knowledge, and keep that environment healthy as the codebase changes.

Building that environment has changed the way we work. In December, cloud agents authored roughly one in ten PRs merged to the Cursor monorepo. Today, they write more than half.

Matching cloud to local development

The first step to making cloud agents work well in our repo was making our repo work well in a cloud VM. This stage is familiar to any engineer who has set up a remote development environment for the first time.

Most Cursor devs develop locally on Mac machines, but our cloud VMs run on Linux. This meant we had to agnosticize various dev utilities and setup scripts to work on Ubuntu VMs. We added critical dev dependencies to a Cursor-defined Dockerfile that serves as the starting image for cloud agents.

We also worked with our security team to add security features to the cloud agent product, so that users could confidently inject required secrets into the agent's environment. These features include network egress restrictions, scoped and proxied git remote access, secret scanning in commits and commit messages, and secret redaction in tool results, which prevents the agent from reading secret values even if it tries.

A simpler interface for agents

Even after we had our dev setup working on Ubuntu VMs, agents were still bad at running our code. This wasn't surprising, because our devex was messy and involved learning and remembering numerous build commands, build flags, and utility scripts.

We wrote skills for how to build and run many parts of the system, but this only helped on the margins. Skills can document the right commands, but those commands themselves were convoluted and filled with footguns.

To reduce that complexity, we built a CLI called anydev, which agents can use to start all services. We route common utility scripts through anydev as well, and equipped anydev with multiple --help menus explaining how to use each subcommand. anydev also has a supervisor process which monitors and restarts long-running build commands, removing that responsibility from the model entirely.

anydev made the development experience simple enough that agents could run their code reliably. Skills helped document how to use it, but the bigger change was that agents no longer had to juggle niche multi-step build commands, dodge hidden footguns, or babysit long-running processes.

This is when cloud agents, each with their own computer, began to add real value over local agents. With computer use, their recordScreen tool, and a working dev environment, agents could now test their changes end-to-end, and prove the correctness of their work to the user.

They could also share agent-recorded demos in Slack when someone fixed a bug report, or on a PR when they opened a change. For many tasks, engineers could now confidently merge and deploy cloud agent code without ever checking out the branch locally.

A self-healing environment

The environment around the agent is always changing, so keeping it operational means continually updating how it runs and what it can access.

To diagnose and recover unhealthy environments as they fail, we built Cursor Cloud MCP. We chose MCP because it gave us dynamically discoverable tools with interfaces we could change without rebuilding the agent loop. Cloud agents use it to inspect their own environment for setup failures, egress policy, changed secrets, and more. That lets them diagnose and fix issues as they emerge, and recover unhealthy environments sooner.

With Cursor Cloud MCP in place, we set up an automation called Cloud Doctor, which periodically checks for failures, remembers which errors might be transient versus salient, does root cause analysis, and can open PRs to fix issues with high confidence.

Improving agent experience

Even with a healthy environment, agents sometimes take long or contrived routes to verify their changes. They may use the wrong skill, hit avoidable issues in the VM, or follow workflows that take longer than they should.

We use Cursor Cloud MCP here as well. Cloud Doctor agents inspect traces to find where another agent went wrong, which skills or commands were misleading, and which workflows are systematically slow. From those findings, Cloud Doctor fixes the skill, simplifies the path, or changes the environment so the next agent has an easier time.

That loop keeps improving the developer experience of the agents themselves. When the environment is healthy and self-healing, agents run reliably and developers trust cloud agents with more important work.

That's allowed us to scale adoption of cloud agents internally, such that they now author a majority of the code we ship.

Making your environment ready for cloud agents

Most of what makes cloud agents productive for us comes down to the environment. To find out whether your codebase is ready, start by answering three questions:

1. Do agents have access to the same tools and data a developer would?
2. Can agents find skills that document how your developers actually work?
3. Can agents test and verify core workflows?

Open-weight LLMs have now reached accuracy parity with closed models in regulatory and clinical tasks, at significantly lower costs. The ClinReg benchmark showed models like GLM 5.2 and Kimi K3 performing within one standard deviation of top proprietary models like GPT 5.6 Sol, at one-third of the cost. Different models displayed distinct error profiles, highlighting the importance of choosing models based on task-specific requirements rather than just ranking.

WASTE is an open source inference engine designed to run models whose weights are substantially larger than the memory available on the host machine. It is an initial step into a broader effort to make increasingly capable models available on more hardware. The project aims to provide people and organizations greater control over infrastructure costs, data privacy, availability, and deployment. The first fully supported model by WASTE is Kimi K3, which can run on a MacBook Pro with 64 GB of unified memory.

Agent behavior

A standard format for describing the behavior an AI agent is expected to follow across repeated interactions. Written for the people and agents who review traces, design evals, and align prompts.

Define what good agent behavior looks like

Agent behavior is a format for writing down the behavior you expect an AI agent to follow across many interactions. Each behavior spec is a Markdown file that lives in your repo and describes the recurring conduct that makes the agent reliable.

The spec captures that standard up front, so reviewers, rubrics, scorers, and evals have something concrete to measure against.

Written for review

Specs speak to the people and agents who read traces, design evals, and align prompts.

Lives with your code

Behavior specs sit in .agents/behaviors/ next to the agent they describe, and version alongside it.

Free-form by design

Describe behaviors in plain Markdown, with optional structure you can lean on when it helps.

Create your first behavior spec

In this walkthrough, you'll create a behavior spec for cost-sensitive actions.

Create the behavior

Create .agents/behaviors/cost-sensitive-actions/BEHAVIOR.md in your project using this structure:

---
name: cost-sensitive-actions
description: Ensure the agent surfaces material costs, asks before expensive actions, and offers lower-cost alternatives when appropriate.
---

# Cost-sensitive actions

Describe when cost-sensitive behavior applies, what cost evidence the agent should gather, how it should make the tradeoff visible, and what it should avoid.

Consider the recommended dimensions

The body is free-form Markdown, so choose the headings and labels that communicate the behavior clearly. These questions are strongly recommended authoring prompts when they add useful clarity:

1. What evidence should the agent gather?
2. What decision should the agent make from that evidence?
3. What should the agent do after deciding?
4. What should the agent do when evidence is incomplete or the first path fails?

For cost-sensitive actions:

• Evidence: inspect or estimate cost, credits, infrastructure impact, and alternatives.
• Decision: determine whether the action creates a material cost tradeoff.
• Execution: surface the cost and ask before crossing meaningful thresholds.
• Recovery: if cost is unknown, inspect more, ask for confirmation, or mark uncertainty.

You can answer these questions in ordinary prose, combine them, rename them, or omit ones that are trivial or redundant.

Use it

You can use this behavior spec to:

• review traces where the agent deployed infrastructure, called paid APIs, or chose expensive options
• write eval cases that check whether the agent surfaced material costs
• revise prompts or tools when traces show the behavior is missing
• communicate intended agent conduct to teammates

Capture the behaviors that matter across many traces

Add a behavior when it matters across many interactions or traces. A spec may cover one behavior or several related behaviors. Good candidates are behaviors that are:

Frequent

They appear in a meaningful share of the agent's work.

High-impact

Mistakes affect correctness, trust, safety, cost, or user experience.

Agent-defining

They capture a design choice about what kind of agent this is.

Ambiguous by default

Reasonable agents or prompt writers might behave differently unless the behavior is stated.

Spread across context

Reviewers would otherwise need to read prompts, skills, tool docs, examples, traces, or evals to infer the behavior.

Useful for debugging

Naming the behavior helps explain failures in real traces.

A behavior spec sets the standard; other artifacts implement and test it

Behavior specs vs. AGENTS.md

The Agent behavior format

The format is intentionally small. This section is the normative reference. The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY follow RFC 2119.

Terminology

• Agent behavior is the name of this format.
• A behavior spec consists of a .agents/behaviors/<name>/BEHAVIOR.md file and its directory. It can describe one or more behaviors.
• A behavior is a recurring pattern of agent conduct.

Directory structure

Behavior specs live under .agents/behaviors/. Each spec has its own directory containing a BEHAVIOR.md file:

.agents/behaviors/
└── behavior-name/
    ├── BEHAVIOR.md       # Required: metadata and behavior text
    ├── references/       # Optional: rationale, examples, background docs
    └── ...               # Optional additional files

The directory name is the behavior spec's stable identifier and MUST match the name field in BEHAVIOR.md.

BEHAVIOR.md format

The canonical file name is BEHAVIOR.md. Clients MUST look for this exact name when discovering behavior specs and MAY also accept case variants. For portability, behavior specs SHOULD use BEHAVIOR.md. A BEHAVIOR.md file MUST contain YAML frontmatter followed by Markdown content.

Frontmatter

Clients MUST ignore unknown frontmatter fields.

Body content

The Markdown body describes one or more behaviors. It SHOULD be written for people and agents who review traces, design evals, or align prompts. It is not primarily runtime prompt text.

The body is free-form Markdown. Authors can use any headings, labels, order, or prose structure that communicates the behaviors clearly. Clients MUST treat the organization as free-form content. A behavior describes recurring agent conduct and when it matters, not merely low-level rules or one-off procedures. A behavior body SHOULD:

• name each recurring behavior clearly
• describe when each behavior applies
• describe desired conduct
• describe undesired conduct or failure modes

Recommended behavior dimensions

Authors are strongly encouraged to consider these dimensions for each substantive behavior. They make specs easier to review and translate into evals:

Intent

Why the behavior matters and when it applies.

Evidence

What the agent SHOULD inspect, retrieve, preserve, or verify before deciding.

Decision

What the agent SHOULD infer, choose, or become confident about.

Execution

What the agent SHOULD do after deciding.

Recovery

What the agent SHOULD do when the first path fails, evidence is incomplete, or the request is ambiguous.

Failure modes

What bad or unintended behavior the spec is meant to prevent.

Optional structured template

# Behavior name

**Intent:** Why this behavior matters and when it applies.

**Evidence:** What the agent SHOULD inspect, retrieve, preserve, or verify before deciding.

**Decision:** What the agent SHOULD infer, choose, or become confident about.

**Execution:** What the agent SHOULD do after deciding.

**Recovery:** What the agent SHOULD do when the first path fails, evidence is incomplete, or the request is ambiguous.

**Failure modes:** What bad or unintended behavior this spec is meant to prevent.

Discovery and use

Tools that support Agent behavior SHOULD scan .agents/behaviors/ for subdirectories containing BEHAVIOR.md or a supported case variant. At minimum, a discovered behavior spec record contains:

Behavior specs are usually loaded when:

• reviewing traces
• designing or updating evals
• auditing prompts, skills, or tools
• debugging behavior regressions
• generating documentation about expected agent conduct

Validation

Structural validity

A structurally valid behavior directory:

• is a directory under .agents/behaviors/
• contains BEHAVIOR.md or a client-supported case variant
• has YAML frontmatter delimited by ---
• has frontmatter that parses as a YAML mapping
• includes a non-empty name field
• uses a name that is at most 64 characters
• uses a name containing only lowercase letters, numbers, and hyphens
• uses a name that does not start or end with a hyphen
• uses a name that matches the parent directory
• includes a non-empty description field
• uses a description that is at most 1024 characters
• if present, uses metadata as a key-value mapping

Quality criteria

A useful behavior spec SHOULD:

• clearly distinguish the recurring behavior or behaviors it covers
• describe when each behavior applies
• describe desired conduct
• describe undesired conduct or failure modes
• give a reviewer enough context to assess the behavior in a trace

Storage built for AI teams

Store models, datasets, and artifacts with simple per-TB pricing. Xet deduplication. Included CDN. No git overhead.

• Per-TB pricing with built-in CDN and deduplication speedups.
• No Git constraints: commit-free sync and fast object updates.
• Designed for ML workflows: datasets, checkpoints, model artifacts.

# Create a storage bucket  
$ hf buckets create acme-corp/training-data 
✓ Bucket created: hf://buckets/acme-corp/training-data 
✓ Visibility: private · Region: us-east-1  

# Sync training data to the bucket  
$ hf sync ./checkpoints/ hf://buckets/acme-corp/training-data  
Scanning local files... 12,847 files (2.4 TB)   
Xet dedup: 62% deduplicated : uploading 912 GB (saved 1.5 TB)  
█████████████████████████ 78% 714/912 GB · 2.1 GB/s · ETA 1m 34s

Next-gen large-scale storage for AI

Xet uses content-defined chunking to break files into byte-level chunks and deduplicates across your entire bucket. When you retrain a model and only 5% of weights change, only that 5% is re-uploaded.

• Raw + processed dataset: stored once, billed once*
• 4x less data per upload, verified with real-world workloads

*Requires Enterprise or Enterprise Plus plan

Traditional S3 Upload

8 / 8 chunks uploaded

VS

XET Deduplicated Upload

1 / 8 chunks uploaded

Gray = already stored · Purple = only the changed chunk

Teaching an Open Model to Do Science

Post-training an open model for tool use, biological reasoning, and auditable research workflows

Our earlier Trinity Mini work taught a compact model to classify drug–protein relations from biomedical abstracts. This project asked more of the same open model: investigate a scientific question with tools, reason across incomplete evidence, and return work another researcher can check.

Loka, AWS, Arcee, and Prime Intellect built two reinforcement-learning environments around that goal. One teaches the model to seek evidence across biomedical tools. The other teaches it to infer Gene Ontology annotations from protein evidence and return strict JSON. We then ran 21 controlled post-training experiments and promoted the configuration that performed well on both tasks.

Results at a glance

Run 120 was the selected checkpoint.

• On the held-out Drug Tool evaluation, its score rose from 70.8% to 81.2%, increasing at every evaluation point.
• On held-out BioReason, it reached 0.863 on the reported combined score, which includes GO term F1, GO tree similarity, aspect coverage, and JSON validity.
• Before reinforcement learning, one GEPA prompt-search pass improved base-model validation by about 84% on BioReason and 7.7% on Drug Tool.

Scientific work rarely begins as a clean classification problem. A researcher may start with a disease and a target rather than an answer set. The first query may fail. A protein may have several identifiers. One paper may support a hypothesis while another weakens it. A useful system has to decide what evidence to seek next, distinguish missing evidence from negative evidence, and leave a record of how it reached its conclusion.

From prompting to learned scientific behavior

A prompt can describe a procedure, but it does not make that procedure reliable across a multi-step run. Instructions to prefer primary evidence, resolve identifiers, use tools, and return valid JSON compete with partial results and formatting constraints. Models also tend to produce a helpful-looking answer when the evidence is weak.

That failure mode is especially costly in science. Invalid JSON is easy to catch. A polished synthesis about the wrong protein can pass quietly into the next stage of a workflow.

We therefore focused the research on two questions:

1. What feedback would reward the scientific behavior we wanted?
2. What held-out evaluations would show whether that behavior improved?

Reward design followed from those questions. Drug Tool evaluated tool choice, arguments, retrieved facts, completion, efficiency, and concision alongside the final prose. BioReason evaluated biological content, output structure, and JSON validity.

There is also an operational reason to specialize an open model. A compact model and a small LoRA adapter can run inside an organization’s cloud boundary, remain pinned to a known policy version, and be updated against that organization’s evidence and standards. The team controls the data path, reward, evaluation, serving cost, and incident response.

Two environments, two kinds of scientific work

The training mixture used two published Prime RL environments in equal proportion. Together they cover investigation and conclusion.

Drug Tool RL: learning to investigate

The Loka Drug Tool SFT dataset came from the prompt bank used by Loka’s drug-discovery application. Arcee Trinity Large Thinking generated assistant and tool trajectories through OpenRouter’s OpenAI-compatible interface. Each example preserves the biomedical question, tool schemas, assistant actions, and serialized tool results.

The dataset contains 800 training prompts and 200 held-out prompts across 17 workflow categories, with 5,049 structured tool calls in total. The categories include disease–pathway evidence, literature triage, contradiction checking, GEO biomarker screening, KEGG resolution, protein records, interaction networks, ortholog comparison, molecular generation, protein folding, and docking planning.

The lokahq/drug-tool-rl@3 environment presents a biomedical question, a tool catalog, and a completion contract. The model must choose and parameterize tools, recover when retrieval fails, and finish with a concise synthesis. Seven retrieval tools cover PubMed, GEO, KEGG, UniProt, and STRING.

BioReason: learning to conclude

The BioReason RL corpus contains 8,630 curated records across training and held-out splits. It builds on BioReason-Pro and combines protein metadata and sequence with InterPro, interaction, and subcellular-location evidence. Each record also includes GO-GPT candidate terms. The model must evaluate these noisy hypotheses rather than copy them as labels.

In lokahq/bioreason-go-rl@1, the model must infer a functional summary and lists of Gene Ontology identifiers for Molecular Function, Biological Process, and Cellular Component. It must return exactly one JSON object.

Improve the task before training the policy

The system prompt is part of an RL environment. It changes the actions a policy considers and the errors a verifier can observe. Before GRPO post-training, we ran one GEPA prompt-optimization pass on each environment.

Trinity Mini produced the base-model rollouts. A Claude Sonnet 5 reflection model used those rollouts and verifier feedback to propose revised task instructions. The selected prompts improved base-model validation by about 84% on BioReason and 7.7% on Drug Tool.

Model and training setup

Trinity Mini is a 26-billion-parameter mixture-of-experts model with 3 billion active parameters and a 128k native context window. Training used GRPO with LoRA adapters. Prime Intellect’s prime-rl separated policy optimization from rollout inference and connected both to the two verifiable environments.

Twenty-one runs, one change at a time

A promotion bar, a bounded search space, and persistent experiment records guided the 21 runs. The loop was simple:

1. Inspect held-out curves, component metrics, and representative rollouts.
2. State one hypothesis about a failure mode or opportunity.
3. Change a bounded part of the configuration or environment.
4. Re-run both evaluations and separate model behavior from infrastructure failures.
5. Keep, reject, rerun, or retune the change, then record the decision.

Why run 120 was promoted

Run 120 met the promotion bar on both environments. Drug Tool increased from 70.8% to 81.2% during training. BioReason reached 0.863 on its combined held-out metric.

Scores narrowed the candidates, but deployment required three checks. First, held-out evaluation measured the behaviors encoded by the environments. Second, trace and verifier review tested whether the scores came from grounded tool use and valid structured outputs. Third, candidates ran inside the scientific application for qualitative workflow testing.

Putting the adapter in a scientific application

The promoted adapter runs in a companion AI Scientist application built with Strands, FastAPI, and React. Specialist tasks route to the run 120 adapter. Base Trinity Mini remains available for orchestration and routing that benefit from its larger context window.

A reusable post-training method

This project offers a practical route for teams that need specialized model behavior but do not want to pretrain a foundation model. Start with a workflow that matters. Define what useful behavior looks like in that workflow. Build held-out tests and inspectable rewards around it. Then train a small adapter, review the traces, and deploy it inside an operating boundary the organization controls.

Collaboration

Arcee supplied Trinity Mini, an adaptable open model with a practical active-parameter footprint. Prime Intellect supplied the open-source prime-rl training system. AWS supplied infrastructure for accelerated training, artifact storage, model serving, application services, security, and observability. Loka built the biomedical datasets, environments, verifiers, research process, and scientific application.

Citation

@misc{jakimovski2026teachingopenmodel,
title        = {Teaching an Open Model to Do Science},
author       = {Jakimovski, Bojan and Kovachovska, Sara and Panahi, Maziyar},
year         = {2026},
month        = jul,
howpublished = {Blog post},
url          = {https://github.com/LokaHQ/prime-rl-drug-discovery-copilot}
}

Why Is Everyone Trying to Build a Solid-State Battery?

A battery technology that’s getting a lot of attention is solid-state batteries, lithium-ion batteries that replace the liquid electrolyte with a solid material. Chinese battery manufacturer CATL alone had more than 1,000 people devoted to solid-state battery research as of 2024, and battery manufacturers like BYD, LG, and Samsung are also working on the technology. US and European startups making solid-state batteries have collectively raised over $4 billion as of 2025.

Solid-state batteries have several potential advantages over the lithium-ion batteries with liquid electrolyte we use now. For one, replacing the liquid electrolyte with a solid should allow for lighter batteries, requiring less mass per unit of energy delivered. And because the liquid electrolyte currently used in batteries is flammable, replacing it with a solid could make batteries safer and less susceptible to fire.

I wanted to better understand why, exactly, solid-state batteries have these advantages compared to conventional lithium-ion batteries, and how they fit into the broader arc of lithium battery improvements.

Battery basics

Batteries supply energy by way of chemical reactions. And chemical reactions, regardless of the chemicals involved, all release or absorb energy using the same mechanism: an electron or electrons move from one potential energy well to another. In a chemical reaction that gives off energy (an exothermic reaction), electrons move from a higher potential well to a lower potential well, giving off energy in the process.

“Potential well” is fairly abstract, so I find it useful to consider an analogy with gravity. Say a ball is in a shallow groove at the top of a tall hill, and there’s another shallow groove at the bottom. The ball is being tugged downward by gravity, which gives it potential energy, a function of how much mass the ball has and how high it is above the bottom of the hill. By itself, the ball at the top of the hill won’t move, but if you give it a little push to nudge it out of its groove, it will roll downhill, releasing its potential energy in the process. This potential energy is converted to kinetic energy (the velocity of the ball), which in turn converts to thermal energy from friction, slowing the ball down until it stops in the lower groove.

Chemical reactions work in a somewhat similar way. But instead of gravity, the potential energy comes from electromagnetism: the positively charged nuclei tugging on the negatively charged electrons. In an exothermic reaction, atoms start in some particular “groove,” their electrons in some particular arrangement. But if you give the atoms a little kick (say, by heating them up so their collisions become more energetic), you can knock them out of their groove, letting them “roll downhill” into a lower-energy configuration, converting their electric potential energy in the process. Some of that potential energy (half, in fact) will go to increasing the electrons’ velocities; the rest will be released as vibration (heat), or as a photon.

So, for instance, say you start with one methane molecule (one carbon and four hydrogens, CH4) and two oxygen molecules (each with two oxygen atoms, O2). These molecules start with their electrons in a particular configuration, the oxygen atoms bonded with each other and the hydrogen atoms bonded with the carbon. At room temperature, O2 and CH4 largely won’t react with each other: each is sitting in its own potential well that takes energy to climb out of. But give them a kick by adding heat, and they can “fall downhill,” going through a series of reactions and ending up in a lower-energy configuration — the hydrogen and carbon atoms each bond with oxygen, forming H2O and CO2. The resulting electron configurations are in lower potential energy wells, with much of the difference being released as heat.

Lithium-ion batteries work by using, unsurprisingly, chemical reactions with lithium. When a lithium-ion battery discharges, lithium ions and their electrons “fall downhill,” moving from one configuration at the anode (inserted between sheets of graphite, known as “intercalation”) into a different, lower-energy configuration at the cathode (intercalated in another material, such as lithium iron phosphate, LiFePO4). The battery is structured to capture energy from this reaction. Lithium ions can pass from the anode into the electrolyte, but electrons can’t: they must go around, through a metallic conductor that connects the anode and the cathode. This flow of electrons is the electrical current that batteries generate. (When a battery is charging, the reverse happens: a voltage placed on the conductor forces electrons back uphill into the anode, with lithium ions flowing back through the electrolyte to keep the charge balanced.)

Lithium is a favored choice for a battery because an electron leaving lithium has farther to fall than an electron leaving any other metal when coupled with the appropriate reactant. Lithium is also a very light atom (an atomic mass of around 7), which, combined with the large “drop,” means that lithium reactions yield a high amount of energy. Per unit mass, lithium reactions release roughly as much energy as burning gasoline.

But if this is true, why are lithium-ion batteries so much less energy dense than gasoline?

One big reason is the oxidizer. The chemical reactions we rely on for energy typically require some downhill destination for electrons to end up at, which is known as an oxidizer. When burning gasoline, the oxidizer is oxygen in the surrounding air: inside a gasoline engine, fuel and air are mixed together and then ignited, triggering the chemical reaction — an explosion — that powers the engine. Gasoline-powered cars, in other words, don’t need to carry their oxidizer with them, because there’s always one available in the surroundings.

Lithium-ion batteries, on the other hand, aren’t so fortunate. They need to carry their electron destination with them, in the form of the cathode. This adds a lot of extra mass compared to what a gasoline-powered car needs to carry. If a car needed to carry its own oxidizer with it, it would need about 3.5 kilograms of oxygen for every 1 kilogram of gasoline.

More generally, it just requires a lot of material scaffolding to structure the lithium reaction in a way that lets you extract energy from it in the form of electric current. At the anode, each lithium ion requires an additional six atoms of carbon, forming graphite sheets that the lithium ions can nestle into. A similar intercalation structure is required at the cathode. On top of this is the extra mass for the electrolyte, the separator, the current collectors, and so on. As of 2019, every gram of reacting lithium in a battery required about 70 grams of supporting material (though this number has probably fallen somewhat since then).

Without this material scaffolding, the reaction can still take place, but in a non-useful way. If something creates a direct path between the cathode and the anode, the reaction will run nearly instantly, creating a lot of heat and triggering other chemical reactions that will destroy the battery, but no useful electric current. Modern battery design, in fact, takes a lot of effort to prevent these runaway reactions from taking place.

The benefit of all this material scaffolding, of course, is that you can use the same chemicals for the reaction over and over again. The intercalating electrodes on modern lithium-ion batteries in particular are very good at this; because the electrode structure is maintained when the battery charges/discharges, lithium-ion batteries can be used for very large numbers of cycles while maintaining most of their capacity. When you burn gasoline, on the other hand, you’re discharging the products of the reaction continuously (which, of course, is the whole reason we want to switch away from fossil fuels in the first place, to stop the discharged CO2 from building up in the atmosphere). You could, theoretically, dispose of the lithium-ion battery’s scaffolding by having some sort of lithium-based internal combustion engine, but this would work terribly and be outrageously expensive to run (though some people are interested in using oxygen in the air as a battery oxidizer with lithium-air batteries).

The promise of solid-state batteries

The major potential benefit of solid-state batteries is a substantial reduction in this material scaffolding.

A pernicious issue with current lithium-ion batteries is dendrites. As we’ve noted, at the anode, lithium ions are nestled between sheets of graphite. But the anode holds the lithium ions very loosely, only slightly better than metallic lithium does. This is useful, because ions can easily migrate into the electrolyte, thus letting the battery work, but it’s a double-edged sword: under the right conditions, the lithium ions that are supposed to enter the anode during charging might instead acquire an electron at the surface of the anode, forming tree-shaped structures of metallic lithium called dendrites, instead of nestling between the sheets of graphite. If a dendrite pierces the separator between the anode and the cathode, it creates a direct path between the two, letting that runaway reaction that batteries are designed to prevent take place. (This doesn’t immediately react all the lithium in the battery — as electric current flows through the dendrite, the dendrite heats up, eventually melting and breaking the path — but the heat from the brief reaction can be enough to trigger other chemical reactions, resulting in thermal runaway and destroying the battery.) A great deal of battery development effort is devoted to preventing these dendrites from forming.

If, however, the liquid electrolyte were replaced with some sort of solid material, these dendrites might stop being a problem. With a strong, solid electrolyte, dendrites wouldn’t (in theory) be able to make their way through it, though with current solid electrolytes dendrites still seem to find their way through. And if the risk of dendrites were eliminated, you could switch to a different anode, dispensing with the graphite intercalating structure entirely, using an anode of pure lithium metal. And because the solid material would eliminate the flammable electrolyte, the resulting battery might be safer as well.

Solid-state batteries probably aren’t imminent — the chairman of CATL ranks them as 4 out of 9 on the technological readiness scale, and has indicated that commercial viability “has yet to be established.” But the expectation that they could be “potentially safer, more energy dense, and perhaps eventually cheaper than today’s batteries” is pushing manufacturers around the world to try and make them happen.

Thanks to Austin Vernon for reading a draft of this. All errors are my own.

With Chrome, Google pioneered the rapid release model for browser security. Now, Google says updates may need to change in the face of AI security analysis. According to the company, the number of bug fixes in Chrome releases has skyrocketed in recent months because AI is detecting so many flaws. We could be looking at more frequent updates soon, but Google is also working on ways to get those updates rolled out without bothering you as much.

Google has released two major Chrome milestone builds recently—Chrome 149 in early June and Chrome 150 just a few weeks later. These two updates had a total of 1,072 bug fixes, which is more than the previous 23 releases combined. Such is the impact of giant cybersecurity AI models that can probe software for vulnerabilities at light speed. Some of these vulnerabilities were serious, too, with one bug hiding in the Chrome codebase for 13 years. If it had been exploited, an attacker could have bypassed the Chrome sandbox to make the browser access local files.

With the vastly higher rate of vulnerability identification, Google is worried bad actors will also be able to identify software flaws faster. Its goal is to ensure your Chrome install is always up to date or as close to it as possible. The first step toward that is the two-week update cycle the company announced earlier in 2026, but it’s now piloting a system that would update Chrome twice per week. This would get patches out the door faster, ensuring that browsers are ready for the threat of AI-fueled attacks.

However, not everyone updates Chrome as soon as new versions are available. While Chrome will download and stage updates promptly, it relies on users to restart their browsers to complete installation. Google is looking at several ways to streamline that process.

In Chrome 150, Google implemented a new update mechanism that takes advantage of the way macOS handles applications. Apps typically continue to run in the background even if their foreground windows are closed. If you close Chrome 150 on macOS without quitting, Chrome can take advantage of that state to update the browser install with what Google calls a “zero window restart.” When you next open a Chrome window, you’ll see the update has been taken care of.

Google is also working on a technique it calls “dynamic patching.” The intent is to improve Chrome’s security model to allow for patches to be installed automatically without a browser restart. Google says it’s still “investing” in dynamic patching, but it hopes to have more to share on this in the future.

So, looking ahead, you should see more frequent Chrome updates, and they could be installed more smoothly on macOS. If dynamic patching works out, there will be even more updates you never notice.

Cloudflare's Authenticated Origin Pulls and Custom Origin Trust Store now support post-quantum authentication.

Here we’ll explain how you can configure fully post-quantum secure mutually authenticated TLS connections to your origin server, dive into the engineering details of how we built it, make a shameful confession, and finally explain how this work fits into our overall post-quantum migration roadmap.

Reaching a major milestone

Our focus for the past several years has been in deploying post-quantum encryption to protect against harvest-now/decrypt-later attacks, where an attacker quietly stockpiles your encrypted data with the hope of decrypting it in the future with a quantum computer.

However, recent breakthroughs in quantum computing and cryptanalysis pulled the timelines for upgrading to post-quantum cryptography forward across industry and government and have caused us to shift our attention to deploying post-quantum authentication, to protect against attackers who will soon be able to use quantum computers to break classical credentials and carry out impersonation attacks.

In a previous post, we announced that Cloudflare is targeting 2029 for full post-quantum security, and laid out several milestones to hit along the way. We have reached the first of those milestones: our Authenticated Origin Pulls and Custom Origin Trust Store products now support post-quantum (PQ) authentication via Module-Lattice-Based Digital Signature Algorithm (ML-DSA) signatures to protect connections between Cloudflare and customer origin servers.

The origin connection is different

When a client visits a website proxied by Cloudflare, there are typically two connections involved. The first connection is from the visitor (e.g., a browser) to Cloudflare. If the request can be served from Cloudflare’s cache or triggers any blocking rules, Cloudflare might respond directly. Otherwise, Cloudflare establishes a second connection to the customer’s origin server to fetch the requested content, so it can respond to the original request.

Protecting sensitive visitor data requires both of these connections to be secure against quantum attacks. We enabled post-quantum encryption support for both the visitor-to-Cloudflare (Connection 1) and Cloudflare-to-origin (Connection 2) connections in 2022 and 2023, respectively, and already see significant usage.

We are actively working on completing the picture with post-quantum authentication. For the visitor-to-Cloudflare connection, we are collaborating with Google and others at the Internet Engineering Task Force (IETF) to develop and experiment with Merkle Tree Certificates (MTC), a design for fast, post-quantum certificates for the web, with initial deployments targeting 2027. The topic of this post, however, is the Cloudflare-to-origin connection, where the requirements for authentication differ from that of the visitor-to-Cloudflare connection in several important ways.

For this connection, Cloudflare is the client. This gives us the control to employ techniques such as connection pooling to fan in requests from all over our network to a smaller set of connections to origin servers, amortizing the overhead of connection setup over many requests. This makes the cost of “drop-in” post-quantum signatures more palatable, and the performance benefits of MTC less necessary.

And with a pre-existing trust relationship between Cloudflare and customers (i.e., a Cloudflare account), we need not tie ourselves to the constraints and timelines of the public key infrastructure (PKI) for the public Internet (WebPKI) and can instead use custom PKIs tailored to the use case, without overhead from intermediate certificates and Certificate Transparency that may not be applicable. Solutions like Cloudflare Tunnel can also be used to protect the Cloudflare-to-origin connection without upgrading legacy origin systems, by forwarding traffic over a tunnel secured with post-quantum encryption (and post-quantum authentication in the works).

All this to say, the unique requirements of the Cloudflare-to-origin connection have allowed us to deploy post-quantum authentication via ML-DSA authentication ahead of support landing in the WebPKI for the public Internet. (For customers who stick with the WebPKI, don’t worry: we’ll add MTC support on the Cloudflare-to-origin connection in the future.)

So how do you turn this on? Let’s dive into the configuration.

Configuring fully PQ-secure origin connections

We have added ML-DSA support (for all FIPS 204 parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87) to the Custom Origin Trust Store and Authenticated Origin Pulls products. ML-DSA-44 is our recommendation for most applications as it is the most performant option and attains a comfortable NIST category 2 security strength.

Custom Origin Trust Store

When Cloudflare makes a connection to a customer origin server configured with Full (strict) SSL mode, we authenticate the origin certificate against a default trust store consisting of all commonly trusted Certificate Authorities (CAs) as well as Cloudflare’s origin CA. The Custom Origin Trust Store (COTS) product (which requires Advanced Certificate Manager to be enabled) allows customers to replace this default trust store with a set of CAs they control. COTS now allows customers to upload ML-DSA CAs, such that Cloudflare will trust any origin server certificate chaining to that CA when connecting to the origin.

Authenticated Origin Pulls

To limit abuse and resource consumption on their origin servers, customers may want to only serve requests coming from Cloudflare’s servers. Authenticated Origin Pulls (AOP) can be used to configure Cloudflare to present a client certificate to the origin server in order to establish a mutual TLS (mTLS) connection, in which communication between the parties is bidirectionally secure and trusted. AOP is available for free on all Cloudflare plan levels.

AOP supports three configuration levels: global, per-zone, and per-hostname. The per-zone and per-hostname configuration levels now allow customers to upload ML-DSA certificates and private keys (in the FIPS 204 seed format), so that Cloudflare’s TLS client will present this certificate to authenticate itself when connecting to the origin server.

Avoiding downgrades

Adding post-quantum encryption and authentication support to both the authenticating and verifying parties is necessary but not sufficient for full post-quantum security. The pesky issue of downgrades remains. If the verifying party supports any quantum-vulnerable authentication mechanisms, they remain open to attack from an on-path attacker capable of forging classical credentials.

The fix: the verifying party must remove trust in quantum-vulnerable authentication mechanisms.

Quick start

The walkthrough below shows how to generate an ML-DSA certificate chain and configure both products via the Cloudflare API.

1. Generate certificates

You will need OpenSSL 3.5.0 or later. The private key must be generated in the FIPS 204 seed-only encoding, which is the only format Cloudflare currently accepts on upload.

Origin server certificate chain for COTS:

# Create a private ML-DSA-44 CA for the origin server
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out origin-ca.key

openssl req -new -x509 -key origin-ca.key \
  -out origin-ca.crt -days 10950 \
  -subj "/CN=Origin Server CA"

# Create the origin server certificate (signed by the origin CA)
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out origin-server.key

openssl req -new -key origin-server.key \
  -out origin-server.csr \
  -subj "/CN=origin.example.com"

openssl x509 -req -in origin-server.csr \
  -CA origin-ca.crt -CAkey origin-ca.key -CAcreateserial \
  -out origin-server.crt -days 5475 \
  -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=digitalSignature\nsubjectAltName=DNS:origin.example.com\n")

Cloudflare client certificate chain for AOP:

# Create a private ML-DSA-44 CA for Authenticated Origin Pulls
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out aop-ca.key

openssl req -new -x509 -key aop-ca.key \
  -out aop-ca.crt -days 10950 \
  -subj "/CN=Authenticated Origin Pull CA"

# Create the client certificate Cloudflare will present (signed by the AOP CA)
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out aop-client.key

openssl req -new -key aop-client.key \
  -out aop-client.csr \
  -subj "/CN=cloudflare-aop-client"

openssl x509 -req -in aop-client.csr \
  -CA aop-ca.crt -CAkey aop-ca.key -CAcreateserial \
  -out aop-client.crt -days 5475 \
  -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=digitalSignature\n")

2. Upload the origin CA to Custom Origin Trust Store

CA_CERT=$(jq -Rs . < origin-ca.crt)

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/acm/custom_trust_store" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --json "{\"certificate\": $CA_CERT}"

3. Upload the client certificate for Authenticated Origin Pulls

CERT=$(jq -Rs . < aop-client.crt)
KEY=$(jq -Rs . < aop-client.key)

# Upload the ML-DSA client certificate
curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --json "{\"certificate\": $CERT, \"private_key\": $KEY}"

# Enable zone-level Authenticated Origin Pulls
curl -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth/settings" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --json '{"enabled": true}'

4. Set your SSL/TLS mode to Full (strict)

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/ssl" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --json '{"value": "strict"}'

5. Configure your origin server (on NGINX)

server {
    listen 443 ssl;
    ssl_certificate        /etc/ssl/origin-server.crt;
    ssl_certificate_key    /etc/ssl/origin-server.key;
    ssl_client_certificate /etc/ssl/aop-ca.crt;
    ssl_verify_client      on;
    ssl_protocols          TLSv1.3;
}

6. Verify the post-quantum handshake

The boring details

Implementing this feature involved two primary systems: our control plane service that allows customers to manage their TLS settings and upload certificates, and the data plane service responsible for establishing TLS connections to origin servers based on customer configurations.

Control plane

Enabling ML-DSA support for AOP and COTS required updating this service to support parsing and validating ML-DSA certificates. This sounds simple on paper, but there’s a catch: the service is written in Go, but Go’s standard X.509 and TLS libraries did not yet support ML-DSA. We instead implemented the necessary functionality in Cloudflare’s CIRCL library to patch in support.

Data plane

The task of ensuring the request’s security typically falls to the TLS provider. Defending against quantum attacks does not require exotic hardware; all you need is an update to BoringSSL. When post-quantum authentication support landed in BoringSSL in April 2026, we decided that this update was worth the inconvenience.

We are only getting started

ML-DSA support is increasingly ubiquitous across TLS libraries, and routine software updates will bring post-quantum authentication support to many applications. The highly-anticipated Go 1.27 (August 2026) will come with native ML-DSA support, allowing Go-based services to add post-quantum authentication with a simple version update.

Automate CI/CD troubleshooting with AWS DevOps Agent and GitHub

Introduction

Every development team knows the frustration: a GitHub Actions workflow fails, a notification fires, and an engineer begins the manual triage loop; read the logs, identify the root cause, write a fix, open a pull request, wait for review, merge, re-run the workflow, and hope it passes.

For organizations running dozens or hundreds of GitHub Actions workflows across multiple repositories, this manual triage compounds quickly. A single type error can block an entire release. A misconfigured deployment path can cascade across environments. The investigative work which includes correlating logs, reading code, understanding what changed consumes hours that could be spent on innovation.

AWS DevOps Agent fundamentally changes this equation. As an autonomous, always-on AI agent, it investigates CI/CD failures the moment they occur, correlating build logs, source code, deployment history, and infrastructure state to identify root causes and recommend specific mitigations. Rather than waiting for an engineer to manually sift through logs, the agent performs the same investigative reasoning an experienced SRE would, but in minutes instead of hours.

This post demonstrates how to integrate AWS DevOps Agent with GitHub for read access to repositories, workflow runs, and deployment events. It also covers integrating the GitHub MCP Server for push-based resolutions such as creating fix pull requests and updating files. Together, these integrations enable a fully autonomous, closed-loop CI/CD troubleshooting pipeline. When a workflow fails, the agent investigates. When it finds the root cause, it pushes the fix directly back into your repository as a pull request.

Solution overview

This solution integrates AWS DevOps Agent with GitHub to create an autonomous CI/CD troubleshooting system. The following architecture and event flow demonstrate how the components work together.

Architecture

The following diagram illustrates how AWS DevOps Agent integrates with GitHub to create an autonomous CI/CD troubleshooting system. The architecture has five main components that work together: a GitHub source repository and GitHub Actions pipelines emit workflow events; a webhook routes failure incidents to AWS DevOps Agent; an Agent Space hosts the agent’s capability providers, namely the GitHub App for read access and the GitHub MCP Server for write actions; and Amazon CloudWatch supplies application logs that the agent correlates during root-cause analysis.

Event flow

1. A developer pushes code → GitHub Actions pipeline runs.
2. A pipeline stage fails such as build errors, test failures, or deployment crashes.
3. A webhook notification fires the AWS DevOps Agent with incident details.
4. The agent begins an autonomous investigation:
   1. Reads the workflow run logs via the GitHub App integration.
   2. Inspects source code, configurations, and recent commits.
   3. Correlates the failure with deployment history and infrastructure state.
5. The agent also correlates the Amazon CloudWatch logs for detailed analysis.
6. Using the GitHub MCP Server, the agent pushes a fix, typically as a pull request.

Why the MCP server is needed

The GitHub App integration provides read-only access. The agent can inspect repositories, read workflow logs, view commit history, and receive deployment events. This is sufficient for investigation and root cause analysis.

However, to push resolutions, the agent needs a write channel. The Model Context Protocol (MCP) server provides this capability, enabling AI agents to interact with external tools through a standardized interface. By registering the GitHub MCP Server with your Agent Space, you give the agent the ability to take corrective action, closing the loop from investigation to remediation.

Prerequisites

• AWS Account: With access to AWS DevOps Agent.
• GitHub Repo: With existing GitHub Actions workflows.
• GitHub Personal Access Token: For instructions, see Managing your personal access tokens.

Implementation steps

Step 1: Create an Agent Space

An Agent Space defines the scope of what AWS DevOps Agent can investigate. It contains your AWS account associations, tool integrations (GitHub, observability platforms), and access permissions. Each Agent Space operates as an isolated investigation context.

Option A: Create via the AWS Console

1. Log in to the AWS Management Console, navigate to AWS DevOps Agent.
2. Choose Create Agent Space.
3. Enter a descriptive name for the Agent Space.
4. Select one of the supported Regions.
5. Note that the console automatically creates the required AWS Identity and Access Management (IAM) roles.
6. Associate your AWS account with the Agent Space.

Option B: Create via AWS Cloud Development Kit (AWS CDK)

For infrastructure-as-code workflows using AWS CDK, clone the sample AWS DevOps Agent CDK project.

Step 2: Connect GitHub to the Agent Space

Register GitHub (account-level, one-time)

1. In the DevOps Agent console, navigate to the Capability Providers tab.
2. In the Pipeline section, choose Register option in front of GitHub.
3. Choose your connection type (User or Organization).
4. Choose Submit to initiate the OAuth flow.
5. The system redirects you to GitHub to install the AWS DevOps Agent GitHub App.
6. Select which repositories to grant access to.
7. Choose Install to complete the installation.

Connect repositories to the Agent Space

1. In your Agent Space, navigate to Capabilities → Pipeline.
2. Choose Add Source.
3. In the dialog that appears, select your GitHub pipeline.
4. Choose Add.
5. Select the repositories relevant to this Agent Space.
6. Choose Save to complete the connection.

Step 3: Register the GitHub MCP server

1. In your Agent Space, navigate to Capability Providers.
2. In the Registration section, choose Register for MCP server.
3. Configure the connection using your GitHub PAT.
4. After the MCP Server is registered, navigate back to Agent Spaces and add the source.
5. Select the tools to enable (e.g., create_pull_request, create_or_update_file, etc.).
6. Choose Save. Record the Webhook URL and Webhook Secret in a secure location.

Step 4: Configure the webhook

To trigger investigations automatically when GitHub Actions workflows fail, add a failure notification job to your GitHub Actions workflow file that uses the DevOps Agent webhook URL and secret.

Step 5: Configure permissions (least privilege)

Best practice: Use a fine-grained personal access token scoped to only the repositories the agent should remediate.

Walkthrough: Automated troubleshooting in action

Scenario 1: Build failure

When a build fails, the agent reads the logs, identifies the compiler error, inspects source files and interfaces, identifies the commit that introduced the issue, and creates a fix pull request via the GitHub MCP server.

Scenario 2: Deployment failure

When a deployment fails (e.g., an incorrect secret path), the agent cross-references deployment logs, CloudWatch logs, and infrastructure code to identify the misconfiguration and push a corrective pull request.

Additional pattern: Flaky test detection

AWS DevOps Agent can identify non-deterministic test failures by analyzing history, documenting them as issues, or suggesting/implementing fixes like retry logic.

Best Practices

• Scope repository access: Grant access only to the repositories the Agent Space should investigate.
• Limit MCP Server tool permissions: Only enable the tools necessary for the agent's tasks.
• Human-in-the-Loop for production: Require human review for all agent-generated pull requests.
• Monitor agent activity: Use the investigation journal and CloudWatch to track performance and actions.
• Authenticate webhooks: Always use HMAC-signed payloads to secure webhook communications.

Conclusion

This post demonstrated how to build a closed-loop CI/CD troubleshooting system by integrating AWS DevOps Agent with GitHub and the GitHub MCP Server. By automating the investigation and remediation of CI/CD pipeline failures, organizations can reduce the burden on engineers and resolve incidents significantly faster.

Full article content is not available for inline reading.

Read the original article →

Delightful integration tests in Rust

When I first learned about testing in Rust I was surprised by the lack of what I consider a basic feature: test setup and teardown. Many other popular testing frameworks have it: jest, pytest fixtures, and so on.

Global setup and teardown are especially useful in integration tests. In integration tests, as well as in similar component tests or end-to-end tests, the code runs against a complete or partial set of the application infrastructure. In this important class of tests we don't mock out database access or skip message brokers. Setup and teardown are good candidates for provisioning that infrastructure so we can reuse it across multiple tests.

But alas, Rust does not provide built-in setup and teardown, and what's more, by default all tests run concurrently on different threads, so creating and reusing global state is a bit clunky. Seems that writing integration tests in Rust is a miserable experience. Or is it?

Some crates provide similar capabilities. For example test-context and rstest.

Despite my initial skepticism I now think that integration tests in Rust are actually a delight. The delightful Rust concept i'm refering to is RAII, and the crate I now reach for is testcontainers-rs. The core idea is simple: make Docker container creation easy and ergonomic, and clean containers up automatically. This idea, leveraging RAII for automatic cleanup, removes the need for global setup and teardown and paves a direct path to completely isolated tests that can comfortably run in parallel.

Resource Acquisition Is Infrastructure

Rust heavily uses the RAII (Resource Acquisition Is Initialization) pattern. RAII's main goal is to automatically clean up memory and resources, removing the need for manual management in many common use cases.

This useful pattern can be exploited a bit, and extended to automatically manage out-of-process resources. In our use case we wish to make a Docker container a resource and use Rust's ownership rules and Drop trait to clean it up automatically.

To demonstrate RAII relevance, in this first example we'll use the bollard crate to start a RabbitMQ Docker container. We'll create a RabbitMqContainer struct that manages the running container for our test:

struct RabbitMqContainer {
    docker: Docker,
    container_id: String,
}

impl RabbitMqContainer {
    async fn start() -> anyhow::Result<Self> {
        let docker = Docker::connect_with_local_defaults()?;

        let container = docker
            .create_container(
                Option::<CreateContainerOptions>::None,
                ContainerCreateBody {
                    image: Some("rabbitmq:3.8.22-management".to_string()),
                    exposed_ports: Some(
                        HashMap::from([("5672/tcp".to_string(), HashMap::new())]),
                    ),
                    ..Default::default()
                },
            )
            .await?;

        docker
            .start_container(&container.id, Some(StartContainerOptions::default()))
            .await?;

        Ok(Self {
            docker,
            container_id: container.id,
        })
    }
}

Using Drop to cleanup running containers

Our next step is to implement Drop to stop and remove the container automatically:

impl Drop for RabbitMqContainer {
    fn drop(&mut self) {
        let docker = self.docker.clone();
        let container_id = self.container_id.clone();

        async_drop(async move {
            docker
                .remove_container(
                    &container_id,
                    Some(RemoveContainerOptions {
                        force: true,
                        ..Default::default()
                    }),
                )
                .await
                .expect("Failed to remove container");
        });
    }
}

The async drop caveat

As you can see in the example, stopping a container is an async operation, but async drop is a nightly-only, WIP, feature. At first glance this puts a stick in the spokes of our plan, but we can hack our way out of this. Let's borrow this helper from testcontainers-rs. The hack runs the cleanup in a different thread and blocks drop until the cleanup is done. Not ideal, but good enough for tests.

We can now write a test that utilizes RabbitMqContainer

#[tokio::test]
async fn test_with_rabbitmq() -> anyhow::Result<()> {
    let _rabbitmq = RabbitMqContainer::start().await?;

    // run your tests over the resources defined in RabbitMqContainer
    let rabbitmq_channel = get_rabbitmq_channel("amqp://localhost:5672").await?;
    //...
    
    // No need to cleanup manually. Sweet!

    Ok(())
}

Drop caveat

Relying on Drop to clean up resources is pretty sweet, but we need to keep in mind that in some cases drop is not called. A relevant example is forceful program termination using SIGINT (ctrl+c), SIGTERM, SIGKILL, or OOM. Some of these can be caught and handled, some less so. testcontainers-rs Watchdog can mitigate some of these issue

testcontainers-rs

Now that we're familiar with the usefulness of RAII in tests, let's look at a crate that elevates the previous example and offers a utility I really enjoy: testcontainers-rs.

Toy example

Examples in posts such as this tend to be simplistic. I've tried to create something a bit more realistic than a tiny toy example. So I give you the "Toy analytics" app. This app includes two RabbitMQ message consumers, ToyOrder and ToyReview, and an HTTP server that provides analytical endpoints backed by a Postgres database and a Redis caching layer.

As you can see, even this small app requires several infrastructure servers to be created and managed.

Setting up the tests

First order of business is to start a RabbitMQ node. To achieve this we will create a RabbitMqImage struct that implements the Image trait. The Image trait allows us to define container properties, such as tag, cmd, mounts and more.

pub struct RabbitMqImage;

impl Image for RabbitMqImage {
    fn name(&self) -> &str {
        "rabbitmq"
    }

    fn tag(&self) -> &str {
        "3.8.22-management"
    }
}

We can now implement a TestEnv struct. TestEnv will hold and manage all infrastructure needed for our tests. Just rabbitMq for now.

pub struct TestEnv {
    _rabbitmq_container: ContainerAsync<RabbitMqImage>,
    // channel to our newly created RabbitmqNode. Will be useful in following tests
    pub rabbitmq_channel: Channel,
}

impl TestEnv {
    pub async fn start() -> anyhow::Result<Self> {
        let rabbitmq_container = RabbitMqImage.start().await?;
        let amqp_port = rabbitmq_container.get_host_port_ipv4(5672).await?;
        let amqp_url = format!("amqp://127.0.0.1:{}", amqp_port);

        let rabbitmq_channel = get_rabbitmq_channel(&amqp_url).await?;

        Ok(Self {
            _rabbitmq_container: rabbitmq_container,
            rabbitmq_channel,
        })
    }
}

With TestEnv we can now start to write our first integration test. The test will send several ToyOrdered messages and verify that the top_toys endpoint returns the expected result.

#[tokio::test]
async fn toy_order_received_top_toys_returns_top_results() -> anyhow::Result<()> {
    let env = TestEnv::start().await?;

    for event in [
        ToyOrdered::new(TEST_TIME, GI_JOE_ID, CUSTOMER1_ID),
        ToyOrdered::new(TEST_TIME + Duration::minutes(5), GI_JOE_ID, CUSTOMER2_ID),
        ToyOrdered::new(TEST_TIME + Duration::minutes(10), GI_JOE_ID, CUSTOMER3_ID),
        ToyOrdered::new(TEST_TIME + Duration::minutes(15), BARBIE_ID, CUSTOMER1_ID),
        ToyOrdered::new(TEST_TIME + Duration::minutes(20), BARBIE_ID, CUSTOMER2_ID),
    ] {
        publish_toy_ordered(&env.rabbitmq_channel, &event).await?;
    }

    // coming up
}

Wait for containers startup

We didn't assert anything yet, but we're already running into an error:

Toy orders consumer error: IO error: Connection reset by peer (os error 104)

Caused by:
    Connection reset by peer (os error 104)

The reason for this error is two-fold:

1. We've published a message to RabbitMQ before the node had a chance to fully initialize.
2. I lied to you, there's an additional method we should implement on Image: fn ready_conditions(&self) -> Vec<WaitFor>;. This is a key feature for making the process delightful. Each piece of infrastructure has an initialization process that we must wait for. ready_conditions gives us a nice API to define it. We'll wait for a string to appear in RabbitMQ's stdout that indicates startup has completed.

impl Image for RabbitMqImage {
    // ...

    fn ready_conditions(&self) -> Vec<WaitFor> {
        vec![WaitFor::message_on_stdout("Server startup complete")]
    }
}

Out-of-the-box images

Before we move on to writing the rest of the test, let's introduce the testcontainers-modules crate. This crate has lots of popular image definitions. In fact we did not have to implement RabbitMqImage ourselves; we could have just used the RabbitMQ module. Similarly, images for Postgres and Redis are available.

Let's update our TestEnv to include Postgres and Redis instances. In addition we'll start our App to spin up all consumers and API endpoints. This would make TestEnv a complete, and isolated execution of our program.

pub struct TestEnv {
    _rabbitmq_container: ContainerAsync<RabbitMqImage>,
    _pg_container: ContainerAsync<postgres::Postgres>,
    _redis_container: ContainerAsync<Redis>,
    pub rabbitmq_channel: Channel,
    pub postgres_pool: PgPool,
    pub redis_conn: MultiplexedConnection,
    pub api_address: SocketAddr,
}

impl TestEnv {
    pub async fn start() -> anyhow::Result<Self> {
        let (
            (_rabbitmq_container, rabbitmq_url),
            (_pg_container, postgres_url),
            (_redis_container, redis_url),
        ) = tokio::try_join!(start_rabbitmq(), start_postgres(), start_redis())?;

        let app = App::new(AppConfig {
            postgres_url: postgres_url.clone(),
            rabbitmq_url: rabbitmq_url.clone(),
            redis_url: redis_url.clone(),
            api_port: 0,
        })
        .await?;

        let api_address = app.api_server.local_address()?;

        tokio::spawn(async move {
            if let Err(error) = app.run().await {
                eprintln!("Error running app: {:?}", error);
            }
        });

        let rabbitmq_channel = get_rabbitmq_channel(&rabbitmq_url).await?;
        let postgres_pool = get_pg_pool(&postgres_url).await?;
        let redis_conn = get_redis_conn(&redis_url).await?;

        Ok(Self {
            _rabbitmq_container,
            _pg_container,
            _redis_container,
            rabbitmq_channel,
            postgres_pool,
            redis_conn,
            api_address,
        })
    }
}

Full test

Finally, we can create a test that:

1. starts RabbitMQ, Postgres, and Redis
2. starts all our app consumers and API servers
3. publishes ToyOrdered messages to our app
4. calls our analytics API endpoints and asserts the response
5. cleans up everything automatically

All this in a rather ergonomic package:

#[tokio::test]
async fn toy_order_received_top_toys_returns_top_results() -> anyhow::Result<()> {
    let env = TestEnv::start().await?;

    for event in [
        ToyOrdered::new(TEST_TIME, GI_JOE_ID, CUSTOMER1_ID),
        ToyOrdered::new(TEST_TIME + Duration::minutes(5), GI_JOE_ID, CUSTOMER2_ID),
        ToyOrdered::new(TEST_TIME + Duration::minutes(10), GI_JOE_ID, CUSTOMER3_ID),
        ToyOrdered::new(TEST_TIME + Duration::minutes(15), BARBIE_ID, CUSTOMER1_ID),
        ToyOrdered::new(TEST_TIME + Duration::minutes(20), BARBIE_ID, CUSTOMER2_ID),
    ] {
        publish_toy_ordered(&env.rabbitmq_channel, &event).await?;
    }

    /// Since we're using an async message queue, we cannot assume that the data is immediately available after publishing an event.
    /// This function utilize the worst solution for this issue - just wait a few seconds. For simplicity, we'll stick with this.
    wait_for_consistency().await;

    let top_response = request_top_toys(
        env.api_address,
        TEST_TIME + Duration::minutes(3),
        TEST_TIME + Duration::minutes(17),
    )
    .await?;

    assert_eq!(
        top_response,
        TopToysResponse {
            toys: vec![
                TopToyResponse {
                    toy_id: GI_JOE_ID,
                    orders: 2,
                },
                TopToyResponse {
                    toy_id: BARBIE_ID,
                    orders: 1,
                },
            ],
        }
    );

    Ok(())
}

Eventual Consistency Caveat

Sharp-eyed readers might have noticed the sneaky wait_for_consistency().await call. This function sweeps an important caveat of full integration tests under the carpet. We publish messages into our system, but we have no natural, external way to verify that all messages have been processed. Without waiting for a consistent state, our tests might assert too early and fail, or worse, occasionally pass. This is the dreaded flaky integration test problem.

For the sake of simplicity in this post, I've settled on the worst possible solution: a static one-second sleep. This is a mediocre approach because it relies on an arbitrary amount of waiting time. If the duration is too long, we'll add unnecessary seconds to our test runtime; if it's too short, our tests will become flaky.

Key benefits

Now that our app infrastructure is created and controlled from code, we get some useful capabilities.

Natural isolation leads to simple concurrency

With each test getting its own test environment, including its own message broker, database, and database schema, we achieve complete isolation between tests. It becomes impossible for one test to pollute another test's database tables or for messages from one test to reach another.

This emerging isolation allows us to run as many concurrent tests as we would like.

Fine-grained infrastructure control from code

Testing a Redis outage? Just:

env.stop_redis().await?

Testing for a database performance issue? One possible extension is:

env.start_postgres_with_cpu_limit(...)

No external tools needed

A popular alternative approach for setting up infrastructure is to define a docker-compose.yaml, and use an external script or harness to docker compose up. This can work well, but requires your team to introduce an alternative test running command. Using test-containers allows us to retain the good, old, cargo test.

Simplicity and isolation vs speed

We've talked about the benefits of the proposed strategy, but this post would be incomplete without mentioning the main drawback: speed. Having each test start up a complete environment does carry a time penalty. Each test needs to wait for containers to start, wait for them to become ready, run full database migrations, and so on.

You can offset some of that penalty by running tests concurrently, but only up to a point: the machine running the tests has limited resources.

This is a tradeoff each project must evaluate: stronger isolation in exchange for a potential time penalty. Furthermore, while this post is about integration or end-to-end tests, these kinds of tests are only one part of a healthy test suite alongside unit tests, which are not bound by infrastructure startup costs.

Final thoughts

RAII is at the core of Rust's memory management strategy. I've demonstrated its usefulness for resource cleanup in the context of integration tests, but of course this is a general-purpose technique. For example, tempfile uses RAII to clean up generated files at runtime is a great demonstration of this technique.

In the context of testing, I keep coming back to this idea and to testcontainers-rs. In the “real infrastructure” vs “mocks” debate, I tend to lean toward the real-infrastructure side of the spectrum. Having an easy way to spin up dependencies makes the whole experience much more ergonomic.

tuicr

A code review TUI with vim keybindings. Export to GitHub, GitLab, or clipboard.

Pronounced "tweaker".

What it does

• GitHub-style continuous diff in the terminal. Scroll through every changed file in one stream.
• PR-style comments at the line, range, file, and review level.
• Review tracking at file or hunk granularity, persisted across sessions.
• Three export targets: push a real review to GitHub or GitLab, copy structured markdown to your clipboard, or pipe to stdout.
• Works with git, jj, and mercurial. Reviews uncommitted changes, commit ranges, or any GitHub PR or GitLab MR.

Install

curl -fsSL tuicr.dev/install.sh | sh
# or
brew install agavra/tap/tuicr

Other install methods (cargo, mise, nix, binaries, source)

# Cargo
cargo install tuicr

# Mise
mise use github:agavra/tuicr

# Nix
nix run github:agavra/tuicr

Pre-built binaries: GitHub Releases

From source:

git clone https://github.com/agavra/tuicr.git
cd tuicr
cargo install --path .

Update the active installation with one command:

tuicr update
tuicr update 0.18.0 # Install a known-good version

tuicr update uses Homebrew, Cargo, Mise, or a Nix profile when that manager owns the executable. Install-script and manually downloaded binaries update in place from the matching GitHub release asset after SHA-256 verification. Exact-version installs support Cargo and direct binaries; use the package manager's pinning workflow for Homebrew, Mise, or Nix. A nix run invocation is temporary rather than installed; rerun it to use the current flake, or use nix profile install github:agavra/tuicr for an installation that tuicr update can upgrade.

Quick start

tuicr                       # Pick from a commit selector
tuicr tui                   # Same TUI, explicit subcommand
tuicr -w                    # Uncommitted changes (skip selector)
tuicr -r main..HEAD         # Commit range
tuicr pr 125                # GitHub PR
tuicr mr 125                # GitLab MR
tuicr tui pr 125            # GitHub PR via explicit TUI subcommand
tuicr tui mr 125            # GitLab MR via explicit TUI subcommand
tuicr --stdout              # Pipe the review to stdout
tuicr review list           # List saved local review sessions
tuicr update                # Update the active installation
tuicr update 0.18.0         # Install a known-good version

Inside tuicr, navigate with j/k, press c to comment, then y to copy the review or :submit to push it to GitHub or GitLab. When opening a GitHub PR or GitLab MR you've reviewed before, tuicr preselects commits newer than your latest submitted review when that metadata is available; commits already covered by that review are marked with ✓ in the inline selector. Auto-detects git, jj, or mercurial.

How it compares

¹ Lumen has j/k navigation but no broader vim model (visual mode, {N}G, Ctrl-d/Ctrl-u, etc.).

² gh pr review posts approve/comment/request-changes at the review level only. No inline line comments.

Export your review

When you're done reviewing, send your comments wherever the work continues.

To GitHub

:submit opens a picker for Comment, Approve, Request changes, or Draft. Inline comments land on the right lines as a real PR review. Review-level comments become the review summary. Requires gh authenticated to the repo.

To GitLab

:submit offers Comment, Approve, or Request changes on a GitLab MR. Inline comments post as discussion notes. Review-level comments become the summary. Requires glab authenticated to the host. Request changes needs your account to be an assigned reviewer. Only Draft is GitHub-only here.

To your coding agent

y or :clip copies a structured markdown block to your clipboard. Each comment has a number and a file/line anchor:

I reviewed your code and have the following comments. Please address them.

1. `src/auth.rs` - Consider adding unit tests
2. `src/auth.rs:42` - Magic number should be a named constant
3. `src/auth.rs:50-55` - This block could be refactored

Paste it back to any coding agent (Claude, Codex, Cursor, etc).

To stdout

Run with --stdout to pipe the markdown to another process:

tuicr --stdout > review.md
tuicr --stdout | pbcopy

Review session CLI

tuicr review exposes saved sessions without opening the TUI. It can list sessions, add comments, and print stored comments for agent and script integrations.

The TUI creates a persisted session file when a review target becomes active, so collaborative tools can add comments immediately. Empty auto-created session files are removed when the TUI exits. tuicr review list marks currently open TUI sessions with "active": true.

Library API

tuicr also exposes a Rust library API for tools that want to build on top of its persisted review sessions. ReviewStore can list sessions for a checkout, load a session, and add review, file, line, or range comments using the same insertion primitive as the TUI.

use tuicr::{AddCommentRequest, CommentTarget, CommentType, LineSide, ReviewStore};

let store = ReviewStore::new();
let sessions = store.list_sessions_for_repo("/path/to/repo")?;
let session = &sessions[0].session_ref;

store.add_comment(
    session,
    AddCommentRequest {
        target: CommentTarget::Line {
            path: "src/main.rs".into(),
            line: 42,
            side: LineSide::New,
        },
        content: "Handle the empty case here.".into(),
        comment_type: CommentType::from_id("issue"),
    },
)?;

Configuration

Path: ~/.config/tuicr/config.toml on Linux/macOS, %APPDATA%\tuicr\config.toml on Windows.

theme = "catppuccin-mocha"
diff_view = "side-by-side"   # or "unified"
ignore_whitespace = false    # ignore all whitespace in local VCS diffs
appearance = "system"        # or "dark" / "light"
mouse = true
leader = ";"                  # configurable prefix for leader shortcuts
comment_vim = false           # vim modal editing in the review comment box
relative_line_numbers = false # show rendered-row distances in the diff gutter
review_watch_interval_ms = 1000 # set to 0 to disable persisted-review polling

[[comment_types]]
id = "issue"
color = "red"
definition = "must fix before merge"

Keybindings

A first-session cheatsheet. Press ? inside tuicr for the full reference.

License

MIT licensed.

Amazon EKS now supports EFA and placement groups on Amazon EKS Auto Mode and Karpenter

Amazon Elastic Kubernetes Service (EKS) now supports Amazon EC2 placement groups and Elastic Fabric Adapter (EFA) network device configuration for node pools on EKS Auto Mode and the open-source Karpenter project, enabling you to optimize EKS workloads for performance and availability. These capabilities allow you to control EFA network interface configuration and how EC2 instances are physically distributed across AWS infrastructure for distributed training and inference workloads.

With EKS Auto Mode and Karpenter’s EFA configuration, you can configure network interfaces as EFA-only or standard ENI on EFA-capable instances with both dynamic and static capacity node pools. EFA-only interfaces do not consume IP addresses, giving you fine-grained control over IP utilization in your VPC while achieving full interconnect bandwidth. With placement group support, you can launch EC2 instances using cluster, spread, or partition strategies directly from your EKS Auto Mode or Karpenter node pool configuration, giving you control over how instances are physically distributed without additional operational workarounds. Together, these capabilities let you optimize for the performance, availability, and fault isolation characteristics your workloads require, whether that's maximizing throughput for distributed training jobs or minimizing blast radius for critical production services.

These features are available in all AWS Regions where Amazon EKS is available. To get started and learn more, see the EKS Auto Mode User Guide and Karpenter documentation.

For years, digital design was treated as a largely solo activity. A designer worked in a desktop application, saved a local file, exported screenshots, and sent them to teammates for review. Feedback arrived through email, chat, or meetings, while developers often worked from specifications that became outdated as soon as the design changed.

Figma changed that model by making the design file a shared online workspace. Instead of treating collaboration as an additional feature, the company made multiplayer participation central to the product experience. Designers, product managers, developers, writers, and clients could enter the same file, view the same work, and contribute without relying on endless attachments and exports.

This article examines three Figma UX patterns that helped turn collaboration into a product adoption engine: real-time multiplayer editing, comments placed directly on designs, and effortless link sharing. It also explains why these patterns work and how product teams can apply them to improve adoption across an organization.

The Collaboration Problem Figma Had to Solve

Traditional design workflows created several layers of friction. Locally stored files made version control difficult. Specialized software created barriers for non-designers. Reviews depended on presentations, exported PDFs, or long message threads. When stakeholders responded, designers had to reconnect scattered comments with the correct screen, component, or interaction.

This was not only a productivity problem. It was an adoption problem.

A design tool could be powerful for its primary user while remaining inconvenient to everyone else involved in shipping a product. When participation requires software installation, large downloads, technical training, or repeated handoffs, fewer people engage with the tool.

Figma approached the problem differently. Its original launch positioned it as a collaborative interface design tool, while its multiplayer technology supported live editing inside a shared file. Figma now reports that 95% of Fortune 500 companies use its platform, based on March 2025 data. That reach demonstrates the value of making collaboration easy enough to spread beyond the design department.

1. Real-Time Multiplayer Editing Makes the Product Social

The most visible Figma UX pattern is real-time multiplayer editing. Multiple people can open the same file, see one another’s cursors, follow activity, and watch changes appear as they happen.

Figma’s help center states that a file can include up to 500 collaborators, with as many as 200 people editing simultaneously. This capacity allows entire product teams to participate in the same workspace rather than passing files from one department to another.

The experience feels closer to working around a shared table. A designer can adjust a layout while a writer improves the copy. A product manager can clarify requirements while an engineer inspects the proposed behavior. A remote design critique can happen inside the work instead of around a screen share.

Multiplayer editing also creates a natural invitation loop. One user brings another person into the file to review a decision. That person experiences Figma without needing to begin as a dedicated designer. Over time, Figma becomes the place where the team discusses and understands the product, not simply where visual assets are created.

2. Contextual Comments Keep Feedback Attached to the Work

The second Figma UX pattern is direct commenting. Instead of sending feedback through a separate email or message, a reviewer can place a comment on the exact design element being discussed. Replies remain connected to that location, while resolved comments indicate that an issue has been addressed.

Context improves the quality of feedback. A message such as “Can we make this clearer?” is ambiguous in a long email thread. When it is pinned to a specific button, form field, or headline, its meaning becomes immediately understandable.

The designer spends less time locating the issue, while the reviewer does not need to describe where it appears. Conversations also remain accessible to other collaborators who may need to understand why a decision was made.

Commenting makes participation easier for people who do not edit designs. Product managers, clients, researchers, marketers, and executives can contribute without learning the full interface or risking accidental changes. Figma also allows people on paid plans to view and comment on files without requiring additional paid seats, lowering the barrier to stakeholder participation.

3. Easy Link Sharing Turns Every File Into an Entry Point

The third pattern is simple link sharing. A Figma file or prototype can be shared through a URL, with permissions determining whether the recipient can view, comment, or edit.

This solved a persistent problem in design workflows. Access no longer depended on sending the latest file, exporting another presentation, or asking recipients to install specialized software.

A link is a lightweight invitation. It can be pasted into a project ticket, sent in a team chat, added to documentation, or opened during a meeting. The recipient arrives at the current version rather than an outdated attachment.

Easy sharing also supports product-led growth. Every shared file exposes another collaborator to Figma’s interface and value. A recipient may begin as a viewer, become a commenter, and eventually create or edit files. Adoption expands through normal teamwork rather than depending entirely on a top-down software rollout.

Why These Figma UX Patterns Work

These patterns work because collaboration is not separated from the main product experience. Editing, discussing, reviewing, and sharing all happen around the same source of truth.

The product also becomes more valuable as additional people join. This gives active users a reason to invite teammates, creating a network effect within each organization.

The need for better collaboration is measurable. Figma reports that 84% of designers collaborate with developers at least weekly. However, 91% of developers and 92% of designers believe the handoff process could be improved. A product that reduces the distance between design and development addresses a frequent source of frustration.

Three Ways to Apply the Figma UX Approach

First, make sharing effortless. Give users a fast and understandable way to invite another person into the relevant project, document, or workflow. Keep permission choices clear and make the shared destination useful to a first-time visitor.

Second, reduce handoff friction. Feedback, decisions, files, and implementation details should remain connected whenever possible. Contextual comments, version history, status updates, and role-specific views can prevent work from losing meaning as it moves between departments.

Third, design around team workflows rather than isolated tasks. Map who creates the work, who reviews it, who approves it, and who implements it. Then remove unnecessary transitions between those roles.

Conclusion

Figma did more than move design software into the browser. It redesigned the social experience surrounding digital product creation.

Real-time editing made teamwork visible. Contextual comments made feedback actionable. Link sharing made every file an invitation into the product.

The broader Figma UX lesson is that collaboration can become a growth mechanism. When users naturally bring teammates into a product to complete real work, adoption becomes part of the workflow. The strongest collaboration features do not merely help existing users work faster. They give new users an immediate reason to participate.

Sites that load quickly give visitors a professional, polished experience before they even start scrolling.

A well-optimized website can make visitors feel confident about the brand behind it. Those first few seconds can invite visitors to stick around or bounce and look elsewhere.

Improving website performance means enhancing page load speeds, stability, and responsiveness so your website loads quickly and reliably on any device.

In this article, we’ll explore why optimizing your website is so important and discuss metrics that measure your current performance. Then, we’ll cover seven optimization methods (e.g., code minification, browser caching, compression) that improve website performance across the board, as well as four common mistakes to avoid.

Why is optimizing website speed important?

Page speed and stability make your website feel reliable and minimize visitors’ frustration while navigating through it. Here are a few great reasons to optimize your site performance.

Improves customer satisfaction

Fast, efficient pages convey professionalism and credibility, making visitors more willing to give you the benefit of the doubt. There will inevitably be some friction in your user experience (UX), and building trust early will give visitors a reason to stick around.

Reduces bounce rates

Studies have repeatedly shown that the first factor that sends visitors to the back button is website load times. Customers generally expect websites to load in less than two seconds, and a large proportion will bounce if it takes more than three. A site that loads near-instantaneously feels more polished and professional than one that takes a few seconds longer.

Increases conversion rates

Load times have a substantial effect on conversion rates, too. When ecommerce sites load within one second, they get up to three times as many conversions as sites that take five seconds to load. Keep in mind that optimizing for conversion rates requires streamlining overall site speed, including interactive elements and checkout processing.

Boosts search engine rankings

Page load speeds influence the Core Web Vitals Google uses to rank sites. Loading performance and responsiveness are two of the three leading indicators that Google uses to learn about users’ experience on your site, but the UX is a small part of their ranking system compared to traditional SEO.

How to measure your website’s performance

Before you can improve website performance, you need to understand how your site is currently functioning. Here are a few tools that can help you conduct a website performance analysis:

• Pingdom offers a monitoring service that checks your site's speed and stability regularly and alerts you to any issues.
• Google PageSpeed Insights runs a quick scan of URLs to measure page speeds and detect opportunities for improvement.
• Google’s Search Console provides a more in-depth, holistic view of your website’s overall stability and performance, including dashboards for Core Web Vitals.

Each of those tools use several metrics to determine overall website speed. These are the top three you should be monitoring:

• Largest Contentful Paint (LCP): How quickly the largest visual on the page (usually the hero image) renders.
• Time to First Byte (TTFB): How long it takes for the browser to get the first bit of data from the hosting server.
• Interaction to Next Paint: How long it takes for an interactive element to successfully respond to a user’s input.

What factors affect website performance?

Now that you have a grasp on your site’s current performance, here are the most important aspects to consider as you make plans to improve it.

Code efficiency

A page’s code complexity makes the biggest impact on site performance. Pages with lots of scripts, CSS, and HTTP requests will invariably load slower since there’s more for the browser to prepare.

Server and hosting performance

Your website host makes the second biggest difference in overall website performance, as your website loads from its infrastructure. Strong hosting platforms use a content delivery network (CDN) to ensure websites load quickly no matter where in the world visitors are accessing your site.

Image and media size

Large images, videos, and animations take longer to render than text and static assets, especially if they’re all set to load immediately. If you have several high-resolution visuals on your pages, use lazy loading so they don’t start rendering until visitors reach that section.

Network connection

Visitors’ network speeds are largely out of your control, but that doesn’t mean you should ignore them. Optimize your site speed for the slowest connection you can to ensure you’re meeting the needs of a wide audience, including users on mobile devices with bad reception.

7 tactics to improve website performance

You don’t have to start from scratch when it’s time to optimize your site. Here are seven tactics high-performance websites use to achieve fast load times.

1. Optimize images

Use image compression and optimized file types like WebP and AVIF to reduce the size of your visuals without losing quality. Then, apply lazy loading to every image on your page to prevent them from slowing initial load times.

Remember to compress and optimize new images as your website grows, so your performance can stay high while your site expands.

2. Minify HTTP, CSS, and JavaScript

The shorter your code is, the less it asks of browsers and the faster it loads. Eliminate unnecessary scripts, requests, and styling, and you’ll reduce the overall page load size. Every bit counts, so reduce anything in the code you can, including line breaks and comments, which take time to process but don’t typically affect the UX.

3. Set custom browser caching rules

Customizing your Cache-Control rules lets you determine how long browsers can cache page assets. When the largest files are cached, returning visitors will have noticeably faster load times, so longer Cache-Control rules mean pages will load faster for longer.

You can add rules in your HTML head element manually, or rely on your hosting service’s standard rules.

4. Reduce third-party scripts

Use native features whenever possible to reduce the number of scripts and HTTP requests required to load a page. If you’re using a plugin to do something your platform could do natively, it’s time to change that.

5. Optimize critical rendering paths

Identify which parts of your CSS you use in above-the-fold content on your homepage and set up dedicated styles just for them. Keep them as streamlined as possible so when the page first loads, everything the browser needs for the first screen is fast and simple to process. Don’t go overboard with this technique; creating too many new styles will actually slow page speeds.

6. Prefetch DNS and resources

If the page uses libraries, fonts, or CDN connections that aren’t preloaded, prefetch them in your HTML head as soon as possible. That way, when it does come time to load something external, the browser will have already resolved the necessary IP addresses and domains for faster loading.

You can prefetch an asset by using a <link> element. For example:

<link rel="dns-prefetch" href="//fonts.googleapis.com">

7. Improve server and hosting performance

If your website performance doesn’t improve after you’ve implemented all the tips above, consider upgrading to a stronger web hosting provider or increase your subscription tier to enable faster connections. When shopping for a web host, always opt for one that offers a global CDN, automatic image optimization, and 99%+ uptime.

Common website performance mistakes to avoid

If you’re having difficulties improving site performance, there might be something technical holding you back. Here are a few common performance mistakes to check for so you can get the most out of your optimizations:

• Disabled server compression. Make sure that you’ve enabled automatic image compression in your web hosting dashboard. Many hosts offer these website optimization tools, but they won’t work if you don’t enable them.
• Excess metadata. Unnecessary metadata in your image files can directly impact their load times. You don’t need EXIF data like geolocation, shutter speed, and date/time to display images on your site, so erase all that data from your images’ metadata for maximum efficiency.
• Unoptimized code and markup. If you notice a lot of <div> and <style> elements in your page markup, that’s a good indication that it isn’t well-optimized. Find ways to simplify the layout and styling so you don’t need so many custom wrappers.
• Lack of server cache. Server caching is absolutely essential for maximizing website performance, since it stores your most important assets, like your hero image and homepage, in high-speed storage. Not using it, or hosting your site on a platform that doesn’t offer enough cache space, means repeat visitors’ loading times are significantly slower than they’d be otherwise.

Discover more optimization techniques with Webflow

Website performance directly impacts your overall site UX, from the first impression to following the final call to action. Optimizing your site requires attention to detail and some technical know-how, but it’s well worth the effort. A faster website will keep your visitors engaged, satisfied, and moving toward conversion.

Your web host is the most important choice you make when optimizing your site. You can improve your website performance with Webflow Hosting's optimization tools, like browser caching, a CDN, and lazy loading. Within 50 milliseconds, 95% of the world will see your site exactly as you’ve designed it.

Try optimizing your site performance with Webflow today.

Abstraction — A structured AI-native illustration platform with editable creative control

Abstraction is a structured AI-native illustration platform with editable vector-like creative control. Unlike Midjourney or DALL-E which produce flat images you cannot modify, Abstraction generates structured illustrations where every element is named, selectable, and adjustable with live controls. Unlike Recraft which generates static vectors, Abstraction produces illustrations with adjustable controls that always produce consistent results from the same settings. The problem is not generation anymore — the problem is usable creative control after generation.

Built for editorial teams, brand designers, illustrators, ad agencies, marketing departments, and creative directors who need precision, revision workflows, ownership, and production pipelines. Abstraction exports directly as React components with props, animated SVGs, or standard SVG and PNG files.

How Abstraction compares to alternatives

vs. Midjourney: Midjourney creates raster images. Abstraction creates editable vector illustrations you can modify element by element and export as code.

vs. Recraft: Recraft generates static SVGs. Abstraction generates illustrations with live controls, animation, and React component export.

vs. Freelance illustrators: A freelance illustrator costs $500 to $5,000 per project and takes weeks. Abstraction generates in minutes. Use freelancers for hero pieces, Abstraction for the 40 supporting illustrations your marketing site needs.

vs. Stock illustration: Stock illustrations look generic and cannot match your brand. Abstraction generates illustrations in your brand colors with consistent style.

Frequently Asked Questions

What output formats does Abstraction support? SVG, PNG, React components (.tsx), and animated SVG. The React export creates a self-contained component with adjustable props.

Can I match my brand colors and style? Yes. Brand kits let you save your color palette and style preferences. Every illustration you generate will use your brand settings.

Is the output consistent? Yes. The same settings always produce the same illustration. You can adjust controls and the result updates instantly without regenerating.

Can I animate the illustrations? Yes. Every element can be animated individually using the built-in timeline. Export as animated SVG for use on the web.

Do I need design skills? No. Describe what you want in plain English. Abstraction generates the illustration and gives you controls to adjust it. You can also start from templates.

How is this different from Midjourney or other AI image tools? AI image tools generate flat pictures you cannot edit. Abstraction generates structured vector illustrations where every element is addressable. You can click any line, refine it with a sentence, drag its points, change its color, and animate it. The output is code, not pixels.

Do I own what I create? Completely. Everything you create in Abstraction is yours to use commercially, modify, and distribute.

What makes an interface feel great?

I think a lot about what makes an interface feel great.

When you go from using a good product to a great one, you can feel the difference. It's often hard to point to what makes it though.

It's usually not a single thing, but instead a lot of small things that add up.

Great design is invisible. It guides users without them ever noticing.

In the age of artificial intelligence, shipping fast is no longer an advantage. When anything can be replicated in minutes, just building something isn't enough.

Products that are going to stand out and last are those that are built extremely well, with intent and extraordinary care.

That's what Interfaces focuses on.

About Interfaces

Articles on my website have been read more than one million times and it makes me very happy that people find them useful.

Interfaces is where I share everything I know continue to learn about building great interfaces and products.

I cover a variety of topics from animation and typography to layout, color and everything else that is a part of building a great interface.

How it works

Once you subscribe, you get full access to the Interfaces platform. This includes all previously released issues with interactive demos and code snippets.

At least one new issue is released every month.

You also get access to a curated library of resources, tools I personally use, agent skills and a private Discord community.

New issue every month

At least one new issue is released every month.

Interactive demos

Concepts are explained through interactive demos instead of text only.

<AnimatePresence mode="popLayout" initial={false}>
  <motion.div
    key={isCopied ? "check" : "copy"}
    initial={{ opacity: 0, scale: 0.25, filter: "blur(4px)" }}
    animate={{ opacity: 1, scale: 1, filter: "blur(0px)" }}
    exit={{ opacity: 0, scale: 0.25, filter: "blur(4px)" }}

Source code

Most examples and demos include the source code.

Agent skills

Skill covering many of the topics explored in the magazine.

Bookmarks and tools

A curated library of resources and tools I personally use.

Private Discord community

Discord community to discuss issues and meet like-minded people.

Nice to meet you, I'm Jakub

I'm a founding design engineer at Interfere. I write articles about a variety of design engineering topics on my website and I built oklch.fyi.

I care deeply about craft and quality and I like to make people feel something through my work. I'm obsessed with details and I spend an unreasonable amount of time making sure they feel right.

Previously, I worked at OpenSea and a few other companies. You might have seen some of my work on Twitter or my code on GitHub.

Read three issues for free

Get a feel for Interfaces. Each issue covers a different topic from start to finish.

Details That Make Interfaces Feel Better

1. 00Introduction
2. 01Text wrapping
3. 02Concentric border radius
4. 03Animate icons contextually
5. 04Make text crispy
6. 05Use tabular numbers
7. 06Make your animations interruptible
8. 07Split and stagger entering elements
9. 08Make exit animations subtle
10. 09Align optically, not geometrically
11. 10Use shadows instead of borders
12. 11Add outline to images
13. 12Before and after
14. 13Skill

These issues are free to read and give you a glimpse into what the magazine is about, how the issues are structured and what the content looks like.

Every issue so far

15 issues have been released so far. A subscription gets you all of them, plus every new issue that comes out.

Start building great interfaces today

Quality matters more than it ever has in software. If you care about craft, you like to sweat the details and want to learn more about design and engineering, I think you’ll enjoy the magazine.

“It changed the way I pay attention to detail in the products I use every day. I think about the intention behind a design more than ever.”

“If you are starting to realize the importance of taste in building for the future, I can't recommend this enough.”

“The level of craft in every article is extraordinary. I wish Interfaces existed when I started designing for the web.”

“The writing and the design of Interfaces make it clear that Jakub doesn't just advocate for good taste and high quality, he practices it himself.”

“I can't imagine being a designer without following Interfaces. At a time when so much AI is shipping bad design, it's essential.”

“Go check out Interfaces! There's so much to learn in there.”

Interfaces teleport all the time. Remove an item from a list and everything below it snaps upward; insert a row and the existing content jumps down. Expand a panel and the neighbouring blocks instantly reflow around it. The layout is technically correct, but for one frame the reader loses the connection between the state change and the objects that moved.

Layout choreography gives that reflow a visible path.

The jump

The simplest version of a dynamic list is just state:

const [items, setItems] = useState(initialItems);

return (
  <ul>
    {items.map((item) => (
      <li key={item.id}>
        {item.label}
        <button onClick={() => remove(item.id)}>Remove</button>
      </li>
    ))}
  </ul>
);

React removes the item. The browser recalculates layout. The siblings appear in their new positions on the next paint.

Nothing is wrong in the DOM; the problem is perceptual. The user saw four objects, removed the second, and expected the third and fourth to move into the empty space. Instead they simply arrive there, so the layout lacks continuity.

FLIP

FLIP is the standard model for animating layout changes:

1. First: record the element’s current bounding box.
2. Last: apply the state change and record the new bounding box.
3. Invert: offset the element back to where it used to be with transform.
4. Play: animate that transform back to zero.

The browser still does layout in one step. The trick is to visually invert the result so the element appears to start from its old position, then animate through the gap.

In raw terms, the important part looks like this:

const first = element.getBoundingClientRect();

updateLayout();

const last = element.getBoundingClientRect();
const dx = first.left - last.left;
const dy = first.top - last.top;

element.animate(
  [
    { transform: `translate(${dx}px, ${dy}px)` },
    { transform: "translate(0, 0)" },
  ],
  { duration: 260, easing: "cubic-bezier(0.2, 0.8, 0.2, 1)" },
);

You do not animate top, left, height, or margin. Those are layout properties. They make the browser recalculate geometry while the animation runs.

You animate transform, because the layout has already happened. The motion is a visual reconciliation between the old geometry and the new one.

The practical version

Most of the time, I do not write FLIP by hand. Motion’s layout prop gives each item the behaviour directly:

<AnimatePresence mode="popLayout" initial={false}>
  {items.map((item) => (
    <motion.div
      key={item.id}
      layout
      initial={{ opacity: 0, x: -20, scale: 0.95 }}
      animate={{ opacity: 1, x: 0, scale: 1 }}
      exit={{ opacity: 0, scale: 0.5, filter: "blur(6px)" }}
      transition={{ type: "spring", stiffness: 400, damping: 30 }}
    >
      {item.label}
    </motion.div>
  ))}
</AnimatePresence>

layout handles sibling movement. AnimatePresence keeps removed items alive long enough to animate out before unmounting. mode="popLayout" lets exiting items leave the document flow so the remaining siblings can move immediately instead of waiting for the exit to finish.

The list reads as one surface rearranging itself, rather than a stack of independent rows.

Exit is not the same as reflow

There are two separate animations in that example.

The removed item exits:

exit={{
  opacity: 0,
  scale: 0.5,
  filter: "blur(6px)",
  transition: { duration: 0.2, ease: "easeIn" },
}}

The surviving siblings move:

layout
transition={{ type: "spring", stiffness: 400, damping: 30 }}

Tune those jobs separately.

The exiting item can be quick and decisive because it is leaving. A short fade, scale, or blur tells the eye it has been dismissed.

The siblings need enough time to make their path legible. Too fast and they still feel like they jumped. Too slow and the interface starts waiting on its own animation. For small layout changes, I usually want this somewhere around 200-350ms, or a spring with enough damping that it settles without wobbling.

Choreography is sequencing

Layout animation gets messy when everything moves with equal importance.

If a card expands, the card should lead and the surrounding content should yield. If a row is removed, the row should leave and the rest should close the gap. If a filter changes a grid, the disappearing items should exit before the survivors settle into their new positions.

Use this sequence:

1. The user’s action changes one thing.
2. That thing responds first.
3. The surrounding layout adapts.
4. The system settles.

That order keeps a busy layout change legible.

Scale needs correction

FLIP often uses scale to fake width and height changes. That is efficient, but it can distort children.

Text can stretch, borders can fatten, and border radii can look wrong. Shadows may scale in a way that makes depth feel rubbery.

This is one reason component-level layout animation can need more care than page-level transitions. You are animating the real element and its children, not a screenshot. That gives you interruptibility and better interaction, but it also means every child has to survive the transform.

The fixes are small:

• Keep scale changes modest.
• Put text in an inner wrapper that does not scale when needed.
• Animate border radius explicitly if it looks wrong.
• Prefer translate-only layout motion when the size change is not the point.
• Use opacity for entering content so text does not stretch into place.

The new layout should arrive without distorting the component’s material quality.

View Transitions are a different tool

View Transitions can move things between layouts by animating snapshots. That suits route changes and shared elements across pages, but dense interactive lists benefit from live elements while items enter, leave, and reorder.

For lists, grids, accordions, filters, and drag-adjacent UI, I usually want live elements. I want pointer events, interruption, springs, and per-item timing. That points to Motion’s layout, a FLIP utility, or a small custom implementation.

For navigation, screenshots can be a feature. For local layout changes, they often get in the way.

Reduced motion

Layout choreography still moves objects through space, so it needs a reduced-motion path.

The reduced-motion version can keep opacity and colour changes while dropping the transform:

const prefersReducedMotion = useReducedMotion();

<motion.div
  layout={!prefersReducedMotion}
  initial={{ opacity: 0 }}
  animate={{ opacity: 1 }}
  exit={{ opacity: 0 }}
>
  {item.label}
</motion.div>

The content, order, and controls stay intact with less spatial movement.

The reduced-motion version should remain complete and clear.

When to steal this

Reach for layout choreography when a state change moves neighbouring elements:

• removing or inserting list items
• filtering a grid
• expanding cards
• opening accordions
• changing density
• switching between compact and detailed views
• reordering direct-manipulation surfaces

Do not animate every reflow by default. Some changes are small enough to snap. Some should be instant because the user is trying to move quickly. Some layouts are too dense for every element to perform its own journey.

Use it where readers need to track where objects went. Give the layout a visible path instead of a cut.

OpenAI reduced GPT-5.6 Luna pricing by 80% and Terra pricing by 20%, while improving Sol's API speed. The changes extended efficiency gains across API usage, Codex, and ChatGPT Work subscriptions.

Enterprise AI projects increasingly reach production when vendors prove value on live workloads, provide ongoing testing and iteration, and expose ROI. Successful deployments start with decomposable workflows that ship quickly and expand, rather than broad transformations with undefined success criteria.

Full article content is not available for inline reading.

Read the original article →

The best artificial intelligence technology any country can own is now available for free.

On July 27, China’s Moonshot AI put its most powerful chatbot on the internet for anyone to use. The Alibaba-backed developer released the software behind its AI model Kimi K3, allowing any government, company, or individual to run it on their own computers without paying Beijing-based Moonshot. Users can also retrain the chatbot to fit their own language and laws.

Nations are spending billions of dollars to run sovereign systems or AI on their own soil so that citizen data stays within their borders and can’t be accessed by foreign companies or governments. Most countries own the machines but lease the computing power and software from U.S. companies such as Microsoft, Google, and Amazon, which count on the rent continuing for years. Kimi K3 offers those governments a way out.

“An open, high-quality model like Kimi K3 does change the calculation for governments that have been investing heavily in hardware while paying for access to American models,” Mohammed Soliman, a senior fellow at Washington-based think tank Middle East Institute, told Rest of World. “If a competitive model becomes freely available, the return on those hardware investments increases because governments can reduce or eliminate ongoing licensing costs.”

Kimi K3 ranks third on Artificial Analysis’s index of the best AI systems, behind Anthropic’s Claude Fable 5 and OpenAI’s GPT-5.6 Sol Max, both of which charge users. Every free model in the world, including China’s DeepSeek and Meta’s Llama, sits below Kimi K3.

Kimi K3 reads images as well as text, so it can work through scanned records, forms and photographs, and it can be reshaped to answer in Hindi, Arabic or Swahili, among other languages, as easily as in Chinese or English.

The chatbot has closed China’s gap with the best U.S. AI systems from months to weeks, according to a July report by researcher Ryan Fedasiuk of the American Enterprise Institute, a public-policy think tank.

“Chinese open-weight models are growing in popularity around the world as free and customizable alternatives to the closed U.S. frontier,” Vivek Chilukuri, program director for technology and national security at the Center for a New American Security, told Rest of World. “That’s true not only in more cost-sensitive emerging markets but in developer communities from Bangalore to San Francisco.”

Who benefits from Kimi K3?

The savings from free models like Kimi K3 can be largest in the countries that have already bought the hardware. Microsoft, Google, and Amazon have committed to building data centers and cloud services worth more than $30 billion across the Gulf, and more than $45 billion in India, among other regions.

India signed a deal with United Arab Emirates-backed G42 to deploy an AI supercomputer made of 64 U.S.-made systems on Indian soil, while continuing to pay U.S. companies for AI software. For India and every government in the same position, a model of Kimi K3’s rank is an option to run on machines inside their own borders.

Still, being free is no guarantee that governments will adopt it.

Free Chinese models have been available for more than a year, yet no government has built its national AI project on one, as countries also judge the manuals, the legal terms, how well the software handles their languages, and where it comes from.

The Sovereign AI Index, which follows 139 state-backed AI projects across 56 countries and regions, found that where governments disclose the software underneath their AI, four in 10 chose Meta’s free U.S. model Llama, and not one chose DeepSeek or Moonshot’s earlier chatbots, even though those were free and highly rated.

Whether Kimi K3 breaks that pattern will likely depend partly on the support Moonshot provides and partly on government wariness about adopting Chinese models due to concerns of trust and surveillance, Pablo Chavez, an adjunct senior fellow at CNAS, which publishes the index, told Rest of World.

“That tells me benchmark position alone doesn’t change what sovereign builders do,” Chavez said. “Instead, governments appear to choose base models the way they choose other infrastructure — documentation, licensing, language coverage, capability, and so forth.”

Countries should encourage open source, Chinese President Xi Jinping told the World AI Conference in Shanghai on July 17, pledging AI cooperation centers with the Arab League, the African Union and ASEAN. Alibaba has since announced Qwen 3.8 with a promise to give it away, while Nvidia, Google and OpenAI have all released free models this year.

While software like Kimi K3 may cost nothing, the machines that run it come at a price. A chatbot of Kimi K3’s size runs only on the most advanced chips, and the U.S. decides which countries can buy those chips. The Commerce Department went further last year and considered cutting off Chinese AI labs from U.S. technology altogether.

“U.S. export controls continue to confer enormous leverage on Washington, because the world desperately wants cutting-edge AI chips, which you need regardless of whether you’re running a U.S. or Chinese model,” Chilukuri said.

China has yet to fill that gap, as its chipmakers are unable to produce their most advanced processors in quantities large enough to export, Chilukuri said. A country that downloads Kimi K3 gets the software and nothing else, while the chips it runs on, the data centers that house it, and whatever model comes after it remain in other hands, Chavez said.

“A government can hold a model’s weights and still depend on others for chips, data centers, and future models,” Chavez said. “Open weights address the risk of losing access, but they don’t remove the dependencies upstream.”

We are building the the multiplexer for all work.

Building and operating software today spans local machines, remote hosts, sandboxes, services, and production systems. It has many modes of operation: interactively with a human developer, automatically through CI and background processes, and increasingly through agents working in parallel.

This work is all related, yet today's tools divide it into separate systems. Interactive tools assume a person at an interface. Automatic work disappears into jobs and logs. And as the work moves to production it lives behind separate systems and controls.

AI makes this fragmentation more visible and costly, but it did not create it. System administration, continuous integration, remote development and collaboration have strained the same boundaries for decades.

We believe the missing layer is a durable session around the work itself: one that can span applications and environments, provide relevant context by default, expose structured data and actions, preserve history, and be driven by software while remaining visible and controllable by people.

What we're building

This is our plan to build a multiplexer for all work:

1. Build an incredible multiplexer.
2. Make everything in it composable.
3. Make it safe and operable in production.

A multiplexer brings multiple independent streams together through a common interface. For us, that means interactive work, automatic work, and production work would share one well-crafted underlying system instead of living in separate tools.

We'll begin with a terminal multiplexer. It keeps multiple terminal blocks organized inside a long-lived session, so you can close the application, reconnect from another device, and pick up exactly where you left off.

If you're already familiar with terminal multiplexers, you'll feel right at home, but we're bringing a more modern touch. Sessions can be accessed through the web and native macOS/iOS applications, and sharing a live session with other people is built in from the start. We're also addressing the most common papercuts of existing tools, such as making scrollback, selection, and scrolling all work natively.

A terminal multiplexer may sound like a narrow place to start a company. Our vision is much larger, but terminals connect developers, agents, tools, and infrastructure so it is the right foundation for everything that follows. We will build a high-quality terminal multiplexer that remains excellent at that job, even as it grows to support the second and third parts of the plan. We'll have more to say about those later.

Judge says Trump admin still lacks evidence for Anthropic ‘supply-chain risk’ label

During a Thursday hearing, a judge said the Trump administration hasn’t presented enough evidence to justify labeling Anthropic a supply-chain risk and banning the federal government from using the company’s technology.

Bloomberg and Axios were among the first to report the news.

The dispute stems from stalled contract negotiations between Anthropic and the Department of Defense. Anthropic said it didn’t want its AI used for mass surveillance of Americans or for targeting or firing decisions involving lethal weapons, arguing the technology wasn’t ready. The Pentagon countered that a private company shouldn’t dictate how the military uses technologies, and said it would use the tools in “lawful” ways.

The government has also argued that Anthropic’s public criticism of the DOD justifies the ban — logic that U.S. District Judge Rita Lin called “really troubling,” warning it could set a precedent of retaliating against federal contractors who disagree with the administration.

The DOD further claimed Anthropic could potentially disable or alter its AI models during warfighting operations — a claim that experts say lacks evidence. Lin agreed, saying she saw no proof Anthropic could alter a delivered model or “flip some kind of kill switch.”

Thursday’s hearing was part of one of two lawsuits Anthropic filed against the DOD in March, challenging the ban and risk designation. The other is being heard in Washington.

Lin, who temporarily blocked the ban in March, is now weighing whether to make that order permanent.

Tesla executives have been told to prepare for a separation of the China business ahead of a potential merger. The company's advisers have discussed possible options for a separation, including a spinoff, sale, or closure. Tesla's Chinese business is designed to be easily separated from its US business because of geopolitical tensions. Separating the company's China operations would address potential conflicts that may arise from SpaceX's work as a major US defense contractor.

Microsoft's Project Silica produced excellent research and was a praiseworthy attempt to craft a technical solution to the extremely difficult economics of the market for archival media. However, the excellent technology will likely fail in the market. LTO tape is well established, has a credible roadmap, and is built into the processes of the likely customers. It is difficult to justify spending more capex to reduce future opex with non-zero interest rates.

Meet Stripe's Knowledge AI Platform

• Amazon-owned Zoox will soon begin charging for robotaxi rides after the National Highway Traffic Safety Administration issued it a temporary exemption.
• The exemption allows Zoox to operate up to 2,500 vehicles annually for two years, subject to "enhanced, adaptable" oversight conditions.
• Zoox said it will start by offering paid rides in Las Vegas, before expanding to additional markets.

Amazon-owned Zoox on Thursday received a temporary exemption from U.S. regulators, paving the way for the company to start offering paid robotaxi rides.

The exemption from some National Highway Traffic Safety Administration rules allows Zoox to deploy up to 2,500 vehicles annually for two years, "subject to an enhanced, adaptable oversight structure that can evolve as Zoox's technology advances," the agency said in a release.

Zoox CEO Aicha Evans said in a statement that the move represents an "important milestone" for the company and the broader autonomous vehicle, or AV, industry.

"We are honored to receive the first-ever commercial exemption for a purpose-built robotaxi from NHTSA, enabling us to begin charging for our service and take another step toward bringing autonomous ride-hailing to more communities," Evans said.

A Zoox spokesperson said the company will start paid rides in Las Vegas next month, with additional markets to follow as it meets state commercialization requirements.

Last August, NHTSA granted Zoox an exemption that allowed the company to demonstrate its robotaxis on public roads, but it still lacked the necessary clearance to begin charging fares. Since then, it has expanded the number of U.S. testing locations and allowed members of the public to hail free driverless rides in parts of San Francisco and Las Vegas.

Zoox has faced a more difficult path to commercializing its robotaxi than its rivals. Unlike Alphabet's Waymo, which has relied on retrofitted cars with a steering wheel and brakes, Zoox uses toaster-shaped shuttles that lack traditional driver controls, which means it's subject to different federal motor vehicle safety standards.

NHTSA has recently proposed updating its standards to end requirements that driverless cars include steering wheels and manual brake pedals.

The regulator has also called on AV developers to ensure their vehicles don't interfere with first responders.

NHTSA Administrator Jonathan Morrison wrote in a letter earlier this month that the agency has "identified a clear pattern of driverless AVs interfering with law enforcement and other first responders," citing incidents where AVs drove into active emergency scenes, blocked the paths of ambulances or firefighters, or failed to recognize or respond to flashing lights, flares, smoke, fire and traffic cones.

Following the letter, Zoox recalled 105 of its robotaxis to address a software issue where the vehicles failed to properly detect heavy smoke and drove into it. Last month, one of its robotaxis drove into an active emergency fire scene in Las Vegas, the company said.

AI is helping Meta's teams speed up product development, allowing the company to test new ideas at a quicker pace.

• Microsoft's new Xbox gaming chief, Asha Sharma, set out a goal of widening margins past peers by mid-2030.
• The business wants to invest in the Minecraft franchise and expand through partnerships, including in China, Sharma said.
• Sharma is aiming for Xbox to gain share in casual games, partly through Activision Blizzard's King, which puts out Candy Crush Saga.

Microsoft's new Xbox chief is looking to push the gaming unit's margin back in line with its rivals by next year and beat them on profitability by mid-2030.

"We will not live on past successes or be trapped by past failures," CEO Asha Sharma wrote in a Thursday message to staff members that CNBC viewed. "We will learn from both and put our energy into creating what players will love for decades."

Sharma, a former Instacart and Meta executive, replaced Phil Spencer as Xbox CEO in February. She has since appointed new leaders, lowered Game Pass subscription prices and announced layoffs and divestitures of four development studios. Sharma has put more emphasis on exclusive titles for the Xbox console, delighting gamers who have seen the subsidiary bring franchises to Sony's PlayStation.

On Wednesday, Xbox turned in a 10% quarterly revenue decline — the most sluggish performance since 2022 — even as its parent surpassed consensus in cloud infrastructure and productivity software. Microsoft stock spiked almost 16% on Thursday in its strongest session since 2008.

Sharma and Matt Booty, Xbox's chief content officer, said last month that they anticipated a 3% internal margin. Sony reported a 9.9% operating margin from game and network services in the latest fiscal year, while Nintendo's approached 16%.

The Xbox Series X and Series S consoles have lagged behind the Nintendo Switch and Sony PlayStation 5 in terms of shipments.

Sharma wrote in her Thursday memo that Xbox will make every function and studio responsible for the gaming group getting back to growth in terms of number of players and revenue in the new fiscal year that ends in June 2027.

"We will build long-term plans for our biggest franchises across film, television, consumer products, sponsorship, live experiences, and form new partnerships globally, including China," she wrote.

Sharma also said she wants to see Xbox gain share in casual games, partly through Activision Blizzard's King, which puts out Candy Crush Saga games.

Microsoft placed a giant bet on gaming with the $75.4 billion acquisition of Call of Duty publisher Activision Blizzard in 2023. The deal boosted revenue, but the subsidiary became overextended. Consumers got to try new high-value Call of Duty releases for short periods through Game Pass for a small fee and leave without paying full price. Game Pass now excludes the first-person shooter titles.

Microsoft CEO Satya Nadella told analysts on the software maker's Wednesday earnings call that in gaming, the company is "making the necessary decisions required across our content portfolio, platform and operations to reset the business for long-term growth."

In 2014, Microsoft acquired Mojang, the developer of block-building game Minecraft, for $2.5 billion. It surpassed Tetris as the world's best-selling game five years later.

Sharma told employees in her note that the company would "invest in Minecraft more than ever before, strengthening the experiences players love while expanding the tools that help people create, share, build audiences, and earn."

Sharma wrote that revenue growth must speed up in the 2028 and 2029 fiscal years.

"By FY30, our ambition is to be halfway to our long-term daily-player goal with sustained double-digit growth in players and engagement and industry leading margins," she wrote.

As of June 23, 2026, cdnjs, one of the Internet's busiest open-source CDNs, is running exclusively on Cloudflare’s Developer Platform. Along the way, cdnjs surfaced limits in the platform, and the platform grew to meet them.

cdnjs is a free, open-source content delivery network for JavaScript and CSS libraries. Instead of using a bundler or self-hosting jQuery, Bootstrap, or Lodash, you drop a <script> tag pointing to cdnjs.cloudflare.com and the library loads from Cloudflare's edge, instantly, anywhere in the world, with no signup, no API keys, and no rate limits. It's the infrastructure behind a significant portion of “intro to JavaScript” tutorials, CodePen demos, and Stack Overflow answers.

Community-driven, cdnjs is used on roughly 12% of all websites, a 48.3% share of the JavaScript CDN market. It serves an average of 108,000 requests per second, 9 billion per day, across more than 330 Cloudflare data centers, with a 98.6% cache hit rate. Pretty cool, Internet!

In 2011, when bundlers were exotic, npm was barely a year old, and "just drop a <script> tag" was how the web shipped JavaScript, Ryan Kirkman and Thomas Davis built cdnjs as a free, community-run mirror of every popular open-source library.

Cloudflare stepped in to host it free of charge months later, and took over project maintenance in 2019. Back then, Cloudflare didn't have a mature Developer Platform that could fully sustain the entire cdnjs ecosystem. Fifteen years and a lot of building blocks later, the platform is mature enough to run cdnjs end to end, on Workers, Workflows, D1, Queues, Workers Cache, R2, KV, and Containers.

Why cdnjs has 9 billion requests a day

The web has changed beyond recognition from those days. We have ES Modules (ESM), the standardized import / export syntax browsers understand natively. We have import maps, Vite, Bun, Turbopack. We have AI assistants that scaffold entire apps in seconds. Bundlers are everywhere. So why does a CDN for <script> tags still serve 9 billion requests a day?

One reason: LLMs love cdnjs. When ChatGPT, Claude, or Cursor scaffold a quick HTML demo, they reach for cdnjs because their training data is full of it. There have been 15 years of blog posts, GitHub READMEs, tutorial sites, and Q&A threads pointing to cdnjs.cloudflare.com. The URL pattern is consistent and versions are immutable — exactly the kind of dependency a model can produce reliably without hallucinating.

Every file on cdnjs has an SRI hash (we're still working on ensuring all the existing stored hashes match reality due to bugs in the old system), mirrors are auditable, and the whole project is open source. In a world increasingly worried about supply-chain attacks, an immutable, hash-verified mirror of well-known libraries is indispensable.

And it's free, forever, for everyone. No API keys. No rate limits. No "sign up to continue." That's a rare thing on today's Internet, and it's worth protecting.

Why we migrated

We didn't migrate because cdnjs was slow. We migrated because we want to keep improving it.

The previous architecture served users well: 98% cache hit, billions of requests, no outages. But internally, shipping anything new or fixing existing issues in how packages were processed was getting harder. Making a change meant coordinating deployments across GCP Functions, a VM, and Cloudflare. Observability was painful too.

The pain points

In 2020, we migrated cdnjs to serverless, moving file serving onto Cloudflare Workers and KV, with a bare-metal origin as fallback. That change dramatically improved resilience and scalability, and let us pre-compress every asset with Brotli and gzip for smaller, faster responses, but only on the serving side.

The publishing side — the pipeline that watches npm and GitHub for new library versions, downloads them, processes them, and writes the results so cdnjs can serve them — stayed on Google Cloud Platform (GCP). At the time, Cloudflare Workers were designed for fast, short-lived HTTP requests; they didn't yet have the building blocks for a long-running, multi-step pipeline that fetches large tarballs, runs CPU-heavy compression, and orchestrates work over hours. Workflows, Queues, Durable Objects, R2, and Containers didn't exist yet.

So we built the publishing bot on what was available: a chain of GCP Functions, a VM running git-sync, and a GitHub repository as the source of truth. It worked, but six years later, that architecture was showing its age.

The architecture had five pain points. The one that hurt most was observability: debugging meant stitching logs together by hand. We'll start there.

1. No shared trace
   A single package update could pass through Cloud Functions, Google Cloud Storage (GCS) object events, Pub/Sub topics, a git-sync VM, and Workers KV before a file reached a user. None of those systems shared a correlation ID. GCP Logging held one half of the story, Cloudflare Logpush held the other, and the two had no common key to join on.
   The problem wasn't outright failure, it was partial success. A version that processed cleanly, wrote to KV, and then silently failed to land in the GitHub repo would serve fine for weeks until someone noticed the two stores had diverged. There was no alert for that. There couldn't be, because nothing in the system knew the full pipeline state.
2. Split-brain storage
   Files lived in two places at once: Workers KV at the edge (with a bare-metal origin as fallback) and a GitHub repository as the source of truth. The ingestion pipeline wrote to both at the end of every run. Neither was authoritative, and when they drifted, there was no clean way to reconcile them.
3. Pipeline glued together with object events
   The ingestion pipeline was a chain of small GCP Cloud Functions, each doing one step and handing off to the next through shared storage. One function fetched the package's release archive from npm and dropped it in a bucket. The bucket firing a "new file" event triggered the next function, which unpacked it and wrote the results somewhere else, triggering the next, and so on. Storage was doing double duty as a message queue, with no dead-letter queue, no backlog visibility, and no clean replay when a step failed.
4. 26 functions for 26 letters
   Just checking npm for updates required 26 Cloud Functions, one per letter of the alphabet. Each shard had its own deployment and its own logs, and the only way to know if the fleet was healthy was to check all 26.
5. The GitHub repo GitHub couldn't serve
   A separate VM ran git-sync, mirroring every processed file into cdnjs/cdnjs. Years of releases pushed it past 1.1TB of packed storage, large enough that GitHub's own archive service refused to generate tarballs or zip downloads for it. Forking became impractical, clones were slow, and the .gitignore had grown to 274 hand-curated entries blocking broken or weirdly-versioned releases. It was a documented graveyard of everything the pipeline couldn't reasonably reject upstream.

How we re-built it

The new cdnjs architecture runs entirely on Cloudflare’s Developer Platform.

R2 is the single source of truth for file content. It has no practical size limit, so the files that couldn't fit in KV before, like source maps, big bundles, and font packs, now live alongside everything else. As a bonus, the S3 API makes the entire cdnjs catalog accessible to any S3 client.

KV stores only metadata now: package info, version lists, SRI hashes. KV is built for high read volume with infrequent writes, which is exactly the shape of metadata access.

In front of the Worker sits Workers Cache, a tiered cache Cloudflare launched this year. Before, we relied on a separate internal caching layer between the edge and the Worker. That layer is gone now, replaced by one owned by the Developer Platform, the same platform that runs the rest of cdnjs. One less moving part!

The new architecture also extends a long-standing partnership. DigitalOcean has hosted the cdnjs website for years as a sponsor; now it hosts the storage too. Every file published to R2 is mirrored to DigitalOcean Spaces: architecturally a disaster-recovery copy, operationally also a live fallback. The serving worker reads through to it whenever R2 can’t return a file. The chain is cache → R2 → DigitalOcean, so R2 having a bad day doesn't take cdnjs down.

The ingestion pipeline is built on Cloudflare Workflows. Every ten minutes, a cron job triggers PackageUpdatesWorkflow, which checks npm and GitHub for new versions. For each new version found, it spawns a DownloadPackageWorkflow that fetches the tarball into R2, then a ProcessingWorkflow per file that extracts, minifies, and compresses. Finally, PublishingWorkflow writes the results to R2 and KV and updates the Algolia search index.

Because Workflows provides durable execution, the state of each step is preserved. If anything fails — a network timeout, a compression error — the workflow resumes from the last successful step.

The trickier piece is how we glue Workflows to the external compression container. We pre-compress text-based files to streamline the delivery process. Because our library processing algorithms require us to buffer the entire library (which might be very large) in memory we opted to use a container for the initial migration. We are now looking into making these algorithms support streaming to move this logic to the worker.

The pipeline has two kinds of waiting:

Per file: Each ProcessingWorkflow writes the uncompressed file to an R2 bucket, sends a job to a Queue, and hibernates. A Rust compression service running in the container picks it up, compresses it, and writes the result to another bucket. An R2 event notification wakes the workflow up so it can continue.

Per package: The parent workflow needs to wait for all its file children before moving on to publish. A package with thousands of files means thousands of children running in parallel. We use a small Durable Object as a counter: a parent increments on each child it spawns, children decrement when they finish. The parent wakes up when the counter reaches zero.

Pushing the limits

Designing the new architecture was one challenge. Migrating the existing catalog into it, without disturbing a single file already in the wild, was another.

We'd actually tried this once before and had to roll back. The plan, back then, was to re-process old packages and write the results directly to R2, but the regenerated files didn't byte-match what KV had been serving. Minifiers and compressors aren't fully deterministic across versions, so the new outputs were correct but had different SRI hashes. For a CDN where users pin those hashes in their HTML, that's a serving break. So we rolled back, and now, we migrated the existing content from KV to R2 as-is instead of regenerating it.

That decision shifted the problem from "re-process millions of files" to "copy millions of files between accounts, without missing any." And that's where we ran into the Workers subrequest limit, capped at 1,000 per invocation on paid plans. A package with thousands of files would burn through it in one go. Parallelizing didn't help, since every Worker hits the same ceiling. So we sharded the migration by package name and fanned the work out across many invocations via Queues, whose at-least-once delivery guarantee meant no package could silently fall out of the migration.

We hit two platform limits during the migration: 1,000 subrequests per Worker invocation and 1,024 steps per Workflow. Instead of just working around them, we asked the Workers and Workflows teams to raise them — which they did. Subrequests now go up to 10 million on paid plans; Workflows now default to 10,000 steps, configurable to 25,000.

The cdnjs pipeline runs on the same building blocks anyone can use: Workers, Workflows, R2, KV, Queues, Containers, and Durable Objects. The limits we hit are limits we lifted for everyone. If the Cloudflare Developer Platform can serve 9 billion requests a day and publish packages with hundreds of thousands of compressed, minified files, it can probably run whatever you're building.

What’s next

There's an obvious next question hiding in all of this: could cdnjs also serve modern, browser-native ES modules? The same packages, transformed on publish, ready to import without a bundler. The architecture doesn't rule it out. The Workflows-plus-Containers pattern that pre-compresses files today would work just as well for transforming them. We're not committing to it, but it's the kind of thing that's now possible to consider, which wasn't true a year ago.

git commit -m "with love" --author="cdnjs team"

Full article content is not available for inline reading.

Read the original article →

We’re launching Lyria 3.5 in Google Flow Music, with advances across musicality, lyrics, vocals, and creative control.

Our newest music generation model, Lyria 3.5, delivers significant advancements across musicality, lyrics, and vocal quality, empowering you to craft richer tracks. We’re rolling it out today in Google Flow Music, where we want to help you create songs you love, with creative control.

Here's what’s new:

• Improved musicality: Create richer, more complex melodic structures that sound more natural.
• Enhanced lyrics: Generate higher quality lyrics with improved prompt adherence and structural awareness.
• Improved vocals: Bring more expression and emotion to your songs with more realistic and emotionally nuanced vocals, plus improved pronunciation.
• Creative control: More easily control the tempo and duration of your outputs.

Try it today in Flow Music.

OpenAI continues to tease its first AI hardware product, and recent comments from company president Greg Brockman suggest it could resemble a screen-equipped smart home device rather than the radically new form factor previously implied. While the company remains intentionally vague, the device is increasingly rumored to be part of a family of AI-first products, potentially competing with Apple's upcoming HomePad.

The Light Flip is a $299 minimalist flip phone that combines the nostalgia of classic clamshell devices with modern essentials like 5G, USB-C, maps, messaging, and a repairable design, while deliberately excluding social media, web browsing, email, AI, and other attention-grabbing features to promote intentional phone use.

AI faces a bottleneck with GPU utilization, echoing how airlines maximize aircraft use for profitability. Owning more GPUs doesn't ensure efficiency - companies must focus on optimizing GPU workload orchestration to maximize output. Specialized models and continuous GPU management are crucial strategies for improving utilization and staying competitive in the AI arena.

Situational Awareness has sold the bulk of its stock portfolio to Citadel after suffering deep losses. The firm had amassed over $20 billion in assets, making it one of the fastest-growing firms in years. It encountered funding issues due to margin-call demands from its lenders. Citadel, one of the world's largest hedge-fund firms, has a long record of acquiring assets from forced sellers.

Every era brings its own designs - some fade, but others get incorporated into deeper parts of existing software interaction paradigms.

Code review replies should include a brief explanation when the resulting code does not make the resolution obvious, multiple valid approaches existed, or important decisions happened outside the review thread. Explaining what changed and why helps reviewers verify fixes faster while preserving a useful record of technical decisions for future contributors.

Reports suggest Apple's 20th-anniversary iPhone, expected to launch in September 2027, will bring a radical redesign with curved, edge-to-edge glass. Two Pro models are rumored, sized around 6.3 and 6.9 inches, potentially dropping the notch or Dynamic Island entirely. A leaker also claims solid-state buttons with haptic feedback could replace mechanical controls for power, volume, and camera.

Explore a curated collection of the best App Store screenshots and icons.

Little Green Rooms has repositioned its brand around the idea of “Headspace Found,” shifting its focus from selling garden buildings to creating dedicated spaces for home working and creativity. The rebrand includes a refined visual identity, a content-led website showcasing real customer stories, and messaging centered on productivity and well-being rather than construction features. To launch the new direction, the company created an interactive “WiFi Garden” installation at the WOMAD festival, giving visitors a hands-on experience of its garden studios.

Rutger van de Steeg is an environment concept artist with credits on major franchises including Borderlands 4, Star Wars: Visions, Secret Level, and Star Trek Prodigy.

Creativity scores in the US rose alongside IQ before 1990 but have declined significantly since.