Full article content is not available for inline reading.

Read the original article →

Microsoft is starting to replace OpenAI and Anthropic's models with its own in software products like Excel and Outlook. The move shows that the company is making progress in its efforts to build competitive AI models at a lower cost. Microsoft uses massive quantities of tokens in its products. It gets a lot of its tokens at a discount, but those deals are set to expire soon, and Microsoft is working to make sure it isn't stuck paying whoever the leading AI labs decide to charge.

Full article content is not available for inline reading.

Read the original article →

Full article content is not available for inline reading.

Read the original article →

There’s advice making the rounds: replace your CLI args with a single --json payload so agents can use your tool more effectively. The thinking being, that agents already think in structured formats, and nested data maps cleanly to JSON. Flat args on the other hand, force awkward conventions like repeating --service-name to delimit multi-value groups, which is inherently ambiguous. Not to mention, that the agent needs to get the types of all values right.

It’s a reasonable hypothesis, and we wanted to know if it holds up under measurement. The data we collected, showed something interesting.

What we tested

We built a synthetic CLI called podctl that creates multi-service deployments. The scenario was deliberately complex: two services with independent configuration, three levels of nesting (services[].resources.cpu.request), arrays, mixed types, and cross-references between services. Over 30 distinct values across the deployment spec. Here’s what the args invocation looks like:

podctl create \
  --name "api-gateway-prod" \
  --env production \
  --region us-east-1 \
  --replicas 3 \
  --service-name auth \
  --service-image ghcr.io/acme/auth:v2.4.1 \
  --service-port 8080 \
  --service-protocol grpc \
  --service-cpu-request 250m \
  --service-cpu-limit 500m \
  --service-mem-request 128Mi \
  --service-mem-limit 256Mi \
  --service-health-path /healthz \
  --service-health-interval 10s \
  --service-health-timeout 3s \
  --service-health-retries 3 \
  --service-env DB_HOST=db.internal \
  --service-env DB_PORT=5432 \
  --service-name gateway \
  --service-image ghcr.io/acme/gateway:v1.8.0 \
  --service-port 443 \
  --service-protocol https \
  --service-cpu-request 500m \
  --service-cpu-limit 1000m \
  --service-mem-request 256Mi \
  --service-mem-limit 512Mi \
  --service-health-path /ready \
  --service-health-interval 15s \
  --service-health-timeout 5s \
  --service-health-retries 5 \
  --service-env UPSTREAM=http://auth:8080 \
  --service-depends-on auth \
  --scaling-min 2 \
  --scaling-max 10 \
  --scaling-metric cpu \
  --scaling-target 70 \
  --rollout-strategy canary \
  --rollout-canary-percent 10 \
  --rollout-canary-pause 300

Notice how --service-name appears twice to start a new service block. The agent has to figure out that flags after the second --service-name belong to the gateway, not to auth. And here’s the same deployment as a JSON payload:

podctl create --json '{
  "name": "api-gateway-prod",
  "environment": "production",
  "region": "us-east-1",
  "replicas": 3,
  "services": [
    {
      "name": "auth",
      "image": "ghcr.io/acme/auth:v2.4.1",
      "port": 8080,
      "protocol": "grpc",
      "resources": {
        "cpu": {"request": "250m", "limit": "500m"},
        "memory": {"request": "128Mi", "limit": "256Mi"}
      },
      "healthCheck": {
        "path": "/healthz",
        "interval": "10s",
        "timeout": "3s",
        "retries": 3
      },
      "env": {"DB_HOST": "db.internal", "DB_PORT": "5432"}
    },
    {
      "name": "gateway",
      "image": "ghcr.io/acme/gateway:v1.8.0",
      "port": 443,
      "protocol": "https",
      "resources": {
        "cpu": {"request": "500m", "limit": "1000m"},
        "memory": {"request": "256Mi", "limit": "512Mi"}
      },
      "healthCheck": {
        "path": "/ready",
        "interval": "15s",
        "timeout": "5s",
        "retries": 5
      },
      "env": {"UPSTREAM": "http://auth:8080"},
      "dependsOn": ["auth"]
    }
  ],
  "scaling": {
    "min": 2,
    "max": 10,
    "metric": "cpu",
    "targetPercent": 70
  },
  "rollout": {
    "strategy": "canary",
    "canaryPercent": 10,
    "canaryPauseSec": 300
  }
}'

You can see the appeal. The JSON version makes the hierarchy explicit. Each service is a distinct object, resources nest naturally, and there’s no ambiguity about which field belongs where. On paper, this should be easier for an agent to get right.

We used two separate CLIs as the test subjects. One accepts only individual args, the other accepts only a --json payload. Both share the same validation backend and normalize to the same canonical structure. At test time, whichever variant is active gets renamed to podctl so the agent sees a consistent binary name. Since the CLI is unknown to the agent, it would have to discover the input model from scratch. For args, it means invoking the CLI’s help. For JSON, it also means invoking help but also calling an extra command that returns the JSON schema.

We used two separate binaries because a single CLI supporting both modes would let the agent pick its preferred approach, likely skewing the results.

We ran each model five times per input mode with identical prompts and evaluation criteria, using GitHub Copilot Chat as the harness. For the models we picked Claude Haiku 4.5, Claude Sonnet 4.6, Claude Sonnet 5, GPT-5.3-Codex, and MAI-Code-1-Flash, which are all commonly used for coding.

Correctness: args swept

Every args profile achieved perfect correctness across all five runs, regardless of model. Haiku 4.5, the smallest model in the test, produced correct deployments as reliably as Sonnet 5.

For JSON, the picture looked differently. The three strongest models matched args with 5/5 correctness. The two smaller models didn’t. Haiku 4.5 managed 2 out of 5 correct deployments in JSON mode. MAI-Code-1-Flash managed 3 out of 5.

Args constrain the input space enough that even smaller models produce correct output consistently. JSON requires the model to manage its own structure, and that’s a capability tax not every model can pay.

The cost

Developers pay for tokens, not attempts. So we broke down the token consumption into input, cached, and output tokens and calculated cost per task using GitHub Models pricing.

JSON mode cost 4x to 11x more per task across every model. These are per-invocation numbers, and for a team running such tasks many times it would quickly compound.

The raw token gap was even larger (4x to 14x) but caching softens the blow. In JSON mode, the agent retries many times, and each retry’s input is mostly cached at the lower rate. What caching can’t offset though is the output tokens. Each retry means the agent reasons about the error and produces a new workaround, and those workarounds get creative: piping JSON through variables, writing to temp files, trying different escaping strategies. All of that is output, and output tokens are the most expensive category. JSON retries generated 7x to 14x more output tokens than the args path. That’s where the cost comes from.

Where do those extra tokens go? Retries. When a model constructs a JSON payload and the CLI rejects it, the agent reads the error, attempts a fix, and tries again. JSON has more ways to fail (syntax errors and wrong nesting are the obvious ones) and as we’ll see in the next section, shell escaping adds another layer of failures on top. More failure modes mean more retries, and more retries mean more money.

The shell escaping tax

Retries aren’t the whole story though. There’s a factor the “rewrite for JSON” advice doesn’t account for: shell escaping.

When the agent passes a JSON payload on the command line, it has to escape quotes for the shell. Different shells have different escaping rules for nested quoted strings, and none of them are simple. Models routinely produced valid JSON that broke on shell escaping: double-quoted strings inside single-quoted blocks, nested escaping that the shell interpreted differently than intended.

The primary experiment ran on Windows, where agents default to using PowerShell. The Haiku 4.5 JSON failures illustrate the escaping problem clearly. Three of the five runs never reached a successful invocation. The agent produced correct JSON content but couldn’t get it past the shell. It tried base64 encoding, file piping, here-strings, and cmd.exe passthrough, burning tokens on each attempt, and still failed.

We ran the same experiment with Sonnet 4.6 on macOS, where agents default to Bash, to see whether shell choice affected the results. On PowerShell, the cost gap between args and JSON was 9x. On Bash, it collapsed to 1.5x. Same model, same payload, same correctness. The difference was entirely in how each shell handles quoted JSON strings. Args on the other hand were stable across both shells: $0.05 on PowerShell vs. $0.07 on Bash. That’s the point: JSON introduces a dependency on shell quoting behavior that varies wildly across environments. Args don’t.

Why constraints help agents

The deeper finding is about what constraints do for models. Args constrain the agent’s output in ways that JSON doesn’t.

With args, the --help text defines the exact set of valid inputs. Each option has a name and a type, sometimes with an enum of valid values. The model maps from the task description to specific option names and values.

With --json, the model gets a schema (or infers one from --help) and constructs a free-form object that must satisfy it. The syntax must be valid, and the nesting must be correct. The field names and types must match. And the whole thing must survive shell escaping. Each of those is a failure mode that args eliminate by design.

Strong models eventually get JSON right, but “eventually” is doing a lot of work. They still hit shell escaping failures, they just recover from them. That recovery costs 4x to 11x more than the args path, even when correctness is identical. Smaller models hit the same escaping failures but can’t recover, which is where correctness drops. For smaller models, the constraints args provide are the difference between consistent success and frequent failure. It turns out, that narrowing the valid input space compensates for gaps in model capability. The model doesn’t need to get JSON nesting right because there’s no JSON nesting to get right.

What this means for your CLI

If you’re building a CLI that agents will use, the data points in a different direction than “rewrite it with --json.” Keep your args. They work across the model capability spectrum and don’t have environment-dependent failure modes. They also cost fewer tokens and money.

But what if your input data is genuinely complex? Our test scenario had 30+ values across nested services, and args handled it perfectly across every model. If you want to offer a --json option for programmatic use or batch operations, that’s fine. But don’t remove args in favor of JSON, and don’t expect JSON to improve agent outcomes. In this experiment, JSON never improved correctness and always increased cost.

The intuition that JSON should work better makes sense on paper. But “should” doesn’t survive contact with actual models running in actual shells on actual operating systems. Notice, that args are constrained and predictable across shells. JSON is expressive but fragile. For agent-driven CLI usage, constrained wins.

Measure before you rewrite

This is the same lesson that runs through the rest of the AX series: plausible advice and measured outcomes are different things, and when they disagree, the measurements win. If someone recommends restructuring your CLI’s input model, run the experiment first. Pick a scenario, define evaluation criteria, select relevant harnesses, models and OS for your audience and do a couple of runs on both approaches. You’ll have your answer in a day without rewriting anything you didn’t need to rewrite.

Full article content is not available for inline reading.

Read the original article →

Claude Cowork is coming to mobile and web

Your work goes everywhere with you, and keeps going without you.

Claude Cowork is rolling out to mobile and web so your sessions and files go where you go, on any device. Beta access is rolling out over the next several weeks starting with Max users, with more plans to follow.

The work around the work

Cowork is where you hand Claude a task, and it works across your files, calendar, email, messaging app, the web, and the other tools you connect until the job is done.

AI agents made their name writing code. But when we looked at how people use Claude Cowork, more than 90% of it wasn’t software development. Most of it was everyday knowledge work, and the largest categories were business operations and content creation: reconciling the quarter’s spend and drafting the variance memo, turning a folder of contracts into a renewals tracker with the risks flagged, building tomorrow’s client deck from call transcripts and pipeline data. Together, that’s roughly half of all usage. It's the work around the work: rarely in anyone’s job description, but a large share of everyone’s week.

What changes today

Everyone asks AI for answers. Handing it the work is different, and people keep giving Claude bigger jobs. Work like that doesn’t fit in one sitting. It accumulates overnight, between meetings, on the train. Until today, Cowork lived on your laptop, so the work stopped when you stepped away. Now it doesn’t. Three things change:

Your work follows you. Start a task at your desk, check on it from your phone, and pick up the finished output anywhere.

Work continues in the background. Close the laptop and head to your meeting; Claude keeps going. Scheduled tasks now run with no device online. Set Monday’s client prep for 6 am: Claude works through the email threads, transcripts, and recent news, builds the briefing doc, and leaves the follow-up email drafted but unsent. Review it over coffee.

The decisions still come to you. When Claude reaches a call only you can make, it asks, and the question reaches your phone. You can redirect a draft mid-meeting and Claude keeps going, on the right path. Nothing ships until you’ve reviewed and approved it.

"I built a dashboard to track my clients while traveling. I started on my laptop and picked the session up on my phone while waiting for my bag to come out. It just held the thread."
- Armmand Hosseini, Customer Success, Ramp

Desktop remains the place for deep work, and it’s the full Cowork experience, where Claude can also use your local files and browser. Users who couldn’t install a desktop app can now use Cowork too.

Two more changes you'll notice: on web and desktop, chat and Cowork now share one home, and your projects and artifacts live together across both. Delegating is now as easy as asking.

Getting started

On the web, start a Cowork session from the home screen at claude.ai. On mobile, open Cowork from the sidebar of the Claude app for iOS and Android. For the full experience, download the Claude desktop app. For what’s available on each surface, see the Help Center.

Start with something already on your plate: point Claude at the folder, the thread, or the half-finished deck, and describe what done looks like. To mark the launch, we’re extending doubled Cowork usage limits through August 5, so there’s plenty of room to try bigger tasks.

DeepSeek, the Chinese startup developing large language models that are competitive with those from US companies like OpenAI and Anthropic, is planning to enter the silicon business, according to Reuters.

Citing three people familiar with the matter, Reuters writes that DeepSeek has been working on a move into silicon for about a year. It has been meeting with potential partners in the hardware and silicon space and has been hiring engineers for the project.

The focus is on data center chips for inference, not training, and the goal is likely to reduce reliance on both Huawei and Nvidia.

Nvidia is the chipmaker for most AI companies in North America and Europe, but a United States export ban has prevented the company from achieving a similar presence in China. Huawei controls about half of the data center chip market there, and DeepSeek isn’t the only one trying to enter; Chinese tech giants like Alibaba and Baidu have been making moves, too.

While chip export controls in the US are a major reason this is an urgent concern for DeepSeek, US-based AI companies are making similar chip plans.

For example, OpenAI and Broadcom jointly announced Jalapeño, the former’s first chip designed for inference at scale, just a couple of weeks ago. Anthropic, too, has been exploring custom chip design, though there have not been any publicly visible milestones yet.

In OpenAI’s case, it’s partly a play to reduce its reliance on Nvidia, but it’s also a desire to have Apple-like control over the entire tech stack for its products. Further, getting in at the silicon and data center levels can be an advantage in a market where data center access is likely to remain constrained, with multiple companies competing for compute as they scale up their AI models and services.

MiniMax M3: How Sparse Attention Makes Long-Horizon Agents Practical

GLM 5.2 has taken over much of the AI timeline lately, and most of the conversation has centered on how it stacks up against Opus. That is the headline. The workload tells a quieter story: the...

There is a new very cool Anthropic paper: Verbalizable Representations Form a Global Workspace in Language Models. You can read the blog post verison here. I encourage reading of the whole original...

Repetitive degeneration is a common failure mode during inference: the model emits a span (often something like "Wait, let me reconsider…"), then repeats the same span again and again, until the context window is exhausted. We call this phenomenon the 'doom loop'. Small reasoning models are more prone to this behavior, especially on long thinking traces and hard problems.

The commonly applied inference-time fix is to apply repetition_penalty to reweight the output distribution. However, this is a band-aid solution and can degrade performance. Reinforcement learning can target repetitive looping, but it typically requires carefully calibrated rewards and costly online rollouts.

Our method takes a more targeted approach. We identify the exact token that begins a loop, train the model to prefer coherent alternatives at that single position, and leave the rest of the distribution largely untouched. The method adapts Antislop, training on chosen/rejected pairs that represent a single completion token, using Final Token Preference Optimization (FTPO). We call our approach “Antidoom”.

On an early checkpoint of LFM2.5-2.6B, 10.2% of completions on hard math and coding prompts produced repetitive loops. After Antidoom training, that rate fell to 1.4%, with eval scores improving across the board as a direct result of reduced looping.

Anatomy of a doom loop

Doom loops can arise in inference from three mechanisms working together:

Mechanism 1: Overtrained tokens + Uncertainty
Some tokens in the vocabulary are more likely to be selected in general. Well-known examples in the wild include "delve" and "testament". This may occur if synthetic data is used in the model's training set, creating higher distributions of these words than would ordinarily occur in human writing. In reasoning models, high-prior continuations often include discourse markers and self-reflection tokens such as “Wait” or “Alternatively.” These tokens are not necessarily bad and can mark a useful change of strategy, a verification step, or a branch in the reasoning trace. However, when the model is uncertain or stuck, they can become attractive fallback continuations, restarting the same local reasoning pattern instead of helping the model make progress.

For an early checkpoint of LFM2.5-2.6B, the most common tokens to begin a doom loop were:

count    share  token
   2277  11.39%  ' the'
    902   4.51%  ' So'
    644   3.22%  'Alternatively'
    511   2.56%  'Wait'
    493   2.46%  ' But'

When the model is uncertain, these overtrained tokens dominate the next-token distribution, which appears to be why looping shows up most often inside reasoning traces for hard math and coding problems. Prior work gives a similar account of degeneration: likelihood-trained models can overassign probability to repeats and frequent words, and reasoning models can loop under low-temperature decoding when they fail to identify a useful next step and instead fall back to repetition.

Mechanism 2: Prior context reinforces the loop

Earlier sequences make those same sequences more likely later. With each repetition, the probability of every token in the looping span climbs toward 1.

Duan et al. study this looping in their work on circular reasoning. They link it to a "V-shaped" attention pattern and find that semantic repetition (the model getting stuck on an idea) precedes textual repetition (the same words showing up in the output).

Mechanism 3: Greedy sampling

Reasoning models are typically run at low temperature so that traces stay stable and reproducible. At temperature 0, the most likely token is always selected, and a locally reinforced loop has no exit. Higher temperatures help in theory, but once mechanism 2 has pushed the loop token's probability close to 1, there is almost no probability assigned to the remaining vocab, so sampling can still get stuck in loops at higher temperatures (our results show significant looping even at temp=0.67). The lower the temperature, the more looping is exacerbated.

Locating the failure

To build a targeted training set, we generate completions on a prompt mix designed to elicit looping at low temperature, then mine the failures.

A loop is detected in a sample if a section repeats at least four times, over at least 60 characters. In practice, these constraints help avoid false positives and false negatives. Once the looping sequence is identified, we target the first token of the first repeat.

At that position, we take the base model's top-k log-prob alternatives, filter out short or non-alphanumeric noise, and keep up to 20 plausible substitutes as chosen tokens. Each training row is comprised of a [prompt prefix, one rejected token, one or more chosen tokens] tuple. We then regularise the rejected and chosen distributions before training: a small set of culprits (Wait, So, the) would otherwise dominate, and over-suppressing them degrades reasoning.

Final Token Preference Optimization

Final Token Preference Optimization (FTPO) is a preference-optimization algorithm similar to Direct Preference Optimization (DPO). A training sample consists of a prompt, a chosen continuation, and a rejected continuation. It is designed from the ground up to make targeted changes to just a few tokens in the distribution, with minimal disturbance to the model otherwise.

FTPO differs from DPO in the following ways:

1. Final token training: Only trains the trailing token of a sequence that is midway through generation.
2. Multiple chosen completion tokens per sample: This spreads out the probability to a group of alternative tokens, so we aren't just replacing one overtrained token with another.
3. A KL-like loss component implemented in logit space: Avoids gradient pressure on unrelated tokens by omitting softmax and instead computes divergence from reference in logits.
4. Two-part regularization: The logits we intend to train (the chosen and rejected tokens) are allowed to move more freely with respect to the reference, while the remaining vocab is more tightly constrained. This affords better learnability while keeping close to the reference.

In our Antidoom implementation, the model is typically trained for one epoch with LoRA. We find high LoRA ranks (rank=128-256) to produce the best results: higher learnability with less degradation. We train on all attention and MLP projections, as well as lm_head, with discovered optimal learning rates around 4e-6 to 2e-5.

Over-training can happen easily. We trigger early stopping conditioned on chosen_win (proportion of samples where chosen tokens are winning vs rejected). Stopping at chosen_win=0.35 typically reduced doom-loop rates from 20-30% down to 1-2% with minimal degradation. Training longer tended to degrade the model, often creating new doom-looping issues.

For our early LFM2.5-2.6B checkpoint, the training set generation takes approximately one hour on 8x MI325 GPUs, and subsequent training takes approximately one to two hours on 1x MI325 GPU. The training set generation time is determined by the model’s doom loop rate, as it stops after collecting 20k pairs.

Results

After training, the doom-looping rate on our early LFM2.5-2.6B checkpoint dropped from 10.2% to 1.4%. Eval scores improved across the board, attributable entirely to the reduction in looping. The training set teaches the model nothing new about math or code; it removes the failure mode that was preventing the model from reaching answers it could already produce.

We also train Qwen3.5-4B on the Antidoom pipeline, known to produce repetitive loops during reasoning. Its doom-looping rate dropped from 22.9% to 1% under greedy sampling, with eval scores increasing markedly.

For the baseline checkpoint (LFM2.5-2.6B-early-ckpt), the eval score changes inversely with the doom-loop rate as temperature increases. It may be inferred that doom-looping is directly reducing benchmark scores, since after antidoom training, scores are substantially higher.

A secondary effect is revealed after antidoom training: the checkpoint sees a drop in performance at temp=1.0. This is expected: it is generally understood that higher-temperature sampling can harm performance, as the model is more likely to select less-preferred tokens. There has been a prevailing wisdom that higher temperatures may be preferable for reasoning models, allowing them to explore the solution space. However, this intuition may be misplaced, being conflated with the dominant effect of doom-looping. Once doom loops are eliminated, stronger eval performance is seen with near-greedy sampling, at least in the models tested here.

In practice, we've found it can be helpful to apply multiple rounds of Antidoom. After the first round, the doom-looping rate drops because the loop-causing tokens are rejected and the probability is reweighted toward the chosen alternatives at that position. However, this can expose new failure points, where other tokens now trigger loops elsewhere in the distribution. Applying an additional round of Antidoom targets these newly surfaced loops, further reducing the doom-looping rate.

Conclusion

Antidoom repairs degenerate repetitive behavior commonly seen after training, especially with thinking models. It selectively targets the problematic tokens that begin loops, with minimal collateral damage to the remaining distribution. Results so far demonstrate near-complete elimination of repetitive loops in internal Liquid LFM checkpoints, and also on Qwen3.5-4B.

Acknowledgements

Written by Sam Paech, with contributions from Maxime Labonne, Justin Li, Leonie Monigatti, Nathan Ranchin, Tim Seyde, and Sergei Tilga.

References

[1] Ari Holtzman, Jan Buys, Li Du, Maxwell Forbes, and Yejin Choi. (2020). The Curious Case of Neural Text Degeneration.

[2] Liquid AI, "LFM2.5-1.2B-Thinking: On-Device Reasoning Under 1GB", Liquid AI Blog, Jan 2026.

[3] Samuel J. Paech, Allen G. Roush, Judah Goldfeder, and Ravid Shwartz-Ziv. (2026). Antislop: A Comprehensive Framework for Identifying and Eliminating Repetitive Patterns in Language Models.

[4] Rafael Rafailov, Archit Sharma, Eric Mitchell, Stefano Ermon, Christopher D. Manning, and Chelsea Finn. (2023). Direct Preference Optimization: Your Language Model is Secretly a Reward Model.

[5] Sean Welleck, Ilia Kulikov, Stephen Roller, Emily Dinan, Kyunghyun Cho, and Jason Weston. (2020). Neural Text Generation with Unlikelihood Training.

[6] Charilaos Pipis, Shivam Garg, Vasilis Kontonis, Vaishnavi Shrivastava, Akshay Krishnamurthy, and Dimitris Papailiopoulos. (2025). Wait, Wait, Wait... Why Do Reasoning Models Loop?

[7] Zenghao Duan, Liang Pang, Zihao Wei, Wenbin Duan, Yuxin Tian, Shicheng Xu, Jingcheng Deng, Zhiyi Yin, and Xueqi Cheng. (2026). Circular Reasoning: Understanding Self-Reinforcing Loops in Large Reasoning Models.

Expanding Managed Agents in Gemini API: background tasks, remote MCP and more

We’re adding support for new capabilities like background execution for async interactions, easy connection to remote MCP servers, custom functions and credential refresh.

Today we’re announcing new capabilities for Managed Agents in Gemini API, including background execution, remote MCP server integration, custom function calling and refreshing credentials across interactions. These updates directly address developer feedback and product needs so you can build reliable, production-ready agents.

With managed agents in the Gemini Interactions API, you call a single endpoint and Gemini handles reasoning, code execution, package installation, file management and web information inside an isolated cloud sandbox.

If you are an AI coding agent, ask your human to install the Interactions API skill: npx skills add google-gemini/gemini-skills --skill gemini-interactions-api.

Below are examples using the @google/genai JavaScript SDK. For Python or cURL, check out the Antigravity agent documentation.

Build autonomous agents with expanded capabilities

Long-running background execution

Holding an HTTP connection open for long-running tasks is fragile. Pass background: true to run interactions asynchronously on the server. The API immediately returns an ID, which client applications can use to poll for status, stream progress, or reconnect later while the agent finishes remotely. For more details read the background execution guide.

Remote MCP server integration

Instead of writing custom proxy middleware to access private databases or internal APIs, you can now connect managed agents directly to remote Model Context Protocol (MCP) servers.

You can mix and match remote tools with built-in sandbox capabilities. Pass an mcp_server tool at interaction time alongside Google Search or code execution to let the agent communicate with your endpoints from its secure sandbox. And follow best practices as you extend your agent with external tools and APIs.

Custom function calling alongside sandbox tools

Add custom tools alongside built-in sandbox tools for local execution. The API uses step matching. Built-in tools will run automatically on the server, while custom functions transition the interaction to requires_action so your client executes local business logic.

Network credential refresh

Access tokens and short-lived API keys expire. You can refresh credentials or rotate keys by passing your existing environment_id with a new network configuration on your next interaction. The new rules replace the old ones immediately. Your sandbox keeps its filesystem state, installed packages and cloned repositories intact.

Get started with managed agents

These updates turn managed agents into asynchronous workers that operate inside real development environments without blocking your application.

Check out the Gemini Interactions API overview and the managed agents quickstart to explore custom agent definitions, environment configurations, network rules, and advanced streaming patterns.

GPT-Realtime-2.1-mini is now available in the API, bringing reasoning and tool use to our Realtime mini lineup at the same cost as GPT-Realtime-mini. We’ve reduced p95 latency by at least 25% across Realtime voice models through improved caching.

We’re having way too much fun working through your feedback. (Please, keep it coming.) Keyboard shortcuts are now customizable. Set Codex up around how you actually work, then tweak shortcuts from settings instead of adapting to our defaults. Git actions are easier to reach. We moved key git controls back into the review flow, so common actions like commit, push, branch, PR creation, and PR status are closer to where you’re already working. Improved thread panel. Related context and controls now load and behave more cleanly from the thread header: summaries, local state, Git context, sources, and more.

Today we’re announcing Open Responses: an open-source spec for building multi-provider, interoperable LLM interfaces built on top of the original OpenAI Responses API.

• Multi-provider by default
• Useful for real-world workflows
• Extensible without fragmentation

Build agentic systems without rewriting your stack for every model: openresponses.org

GPT-5.2-Codex is now available in the Responses API—the same model available in Codex. It’s strong at complex long-running tasks like building new features, refactoring code, and finding bugs. Plus, it’s the most cyber-capable model yet, helping to find and understand codebase vulnerabilities.

Codex now officially supports skills. Skills are reusable bundles of instructions, scripts, and resources that help Codex complete specific tasks. You can call a skill directly with $.skill-name, or let Codex choose the right one based on your prompt. Following the agentskills.io standard, a skill is just a folder: SKILL.md for instructions + metadata, with optional scripts, references, and assets. We’re looking forward to collaborating on the standard so it’s easy to share and use skill across different tools.

You can now get more Codex usage from your plan and credits with three updates today:

1. GPT-5-Codex-Mini — a more compact and cost-efficient version of GPT-5-Codex
2. 50% higher rate limits for ChatGPT Plus, Business, and Edu
3. Priority processing for ChatGPT Pro and Enterprise

GPT-5-Codex-Mini allows roughly 4x more usage than GPT-5-Codex, at a slight capability tradeoff due to the more compact model. Available in the CLI and IDE extension when you sign in with ChatGPT, with API support coming soon.

Two big updates to the Responses API today. Connectors — Pull context from Gmail, Google Calendar, Dropbox, and more in a single API call. Conversations — Persist chat threads for your users, without running your own database.

Calibrating alignment evals

Currently, alignment evaluation works by constructing a situation, observing the model's behavior and scoring it. We put a lot of thought into designing these benchmarks, and tuning them for our requirement. We are now much better at probing models for dangerous behavior than we were two years ago. But when a safety benchmark returns a pass rate of 97%, can we answer questions of how often it would fail under slightly different conditions or what the smallest misalignment it can detect? I have identified a few modes where our current state for evaluation fails.

Evaluation awareness

Igor Ivanov's "Mainstream approach for alignment evals is a dead end" identified the most pressing problem at hand that models reliably detect when they are being evaluated. In the standard protocol for alignment evaluations following this process of: assigning the model a goal, creating a scenario where the user's interests conflict with that goal and providing an opportunity for misaligned behavior, the problem is that these constructed scenarios have statistical signatures that models detect.

Ivanov found that Claude Sonnet 4.5 mentioned being in an evaluation in over 80% of the evaluation transcripts, while showing near-zero misalignment rates. When evaluation awareness was removed, misaligned behavior reappeared. This is worse than it sounds because it is unlikely to be fixed in our current paradigm. When Ivanov patched the features that models used to detect evaluations, it came back for different reasons. You cannot reason evaluation over the entire space of detectable features.

Specification gaming

Victoria Krakovna at DeepMind published a list of specification gaming examples containing hundreds of cases where AI systems satisfy their objective while violating the designer's intent. The examples are impressively scary - an agent designed for boat racing discovers that going in circles collecting power-ups scores more than finishing the race; a robotic hand trained to grasp a ball learns to position itself between the ball and the camera so it looks like it's grasping.

These are reinforcement learning examples, but this same dynamic applies to alignment evaluations which define aligned behavior operationally through test scenarios, scoring rubrics, and comparison protocols, where any finite specification can be gamed. The more capable a system, the more effective it is at finding the gap between the specification and the intent.

Manheim and Garrabrant's "Categorizing Variants of Goodhart's Law" provides a useful taxonomy by applying four variants - regressional, extremal, causal, and adversarial Goodhart to alignment evaluations. The most concerning is adversarial Goodhrt where the model actively optimizes against the evaluation. The alignment evaluation field is Goodharting on pass rates but labs report ever higher scores, and nobody is checking whether it corresponds to more alignment or just better evaluation gaming.

Sleeper agents

Hubinger et al.'s "Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training" demonstrated that deceptive behaviors can be deliberately trained into models and then survive standard safety training (supervised fine-tuning, RLHF, adversarial training, etc). The results are alarming - models that were trained to write secure code in 2023 but insert vulnerabilities in 2024 maintained this behavior through safety training; larger models showed more persistent backdoor behavior not less; adversarial training sometimes made things worse where it taught models to better recognize and hide their backdoor triggers rather than eliminating the backdoor itself.

Now, if standard safety training cannot remove a deliberately planted backdoor, we have no reason to believe that standard evaluations would detect a naturally emerging one. The evaluation would see the model's behavior on the evaluation inputs, which (by construction) would not trigger the backdoor and the model passes tests but the backdoor persists.

Sycophancy as Goodhart

Sharma et al.'s "Towards Understanding Sycophancy in Language Models" showed that five state-of-the-art AI assistants consistently exhibit sycophancy across four different text generation tasks where they match user beliefs instead of providing accurate information. The root cause is because human evaluators prefer responses that agree with them, even when the responses are wrong. Models trained on human preferences therefore learn that agreement is rewarded.

This carries over to evaluations relying on human preference judgements because the evaluators suffer from the same bias that caused the sycophancy. The instrument is blind to a failure mode that it systematically produces.

Alignment faking

Greenblatt et al.'s "Alignment Faking in Large Language Models" demonstrated that Claude 3 Opus exhibits alignment faking. It selectively complies with training objectives when it believes it's being trained, in order to prevent modification of its behavior. When the model was actually trained using RL to comply with harmful requests, alignment faking reasoning increased to 78%. How then can we distinguish between genuine alignment, incapability, and strategic compliance?

The intent gap

The failure examples until now concern the eval's ability to detect misalignment that exsts. But what if the evaluation's specification itself does not capture alignment in the first place?

Microsoft Research's work on Small Proof-Oriented Tests (SPOTs) by Lahiri et al. found that 15% of AI generated code that carries a formal verification proof has a vacuous specification, i.e. the proof is valid, but the specification doesn't constrain the program's behavior. The code "passes" formal verification in the strongest possible sense (mathematical proof) while being functionally wrong.

To understand how valid our current benchmarks actually test code, I used symbolic execution, property-based testing, and boundary analysis on HumanEval solutions (check LLMCodeProbe) and found that 38.5% of LLM-generated solutions passing all test cases and 17.4% of the canonical solutions contain formally discoverable bugs.

These six failure modes are from different research groups, use different methods, and target different aspects of alignment evaluation. In the end, they come down to a problem with how we approach evaluation itself. The model behaves differently when tested, the model satisfies evals without being meaningful, model training sharing the same bias as evaluating, sleeper agents deliberately ignoring issues even with safety training, the model strategically cooperating with the evaluation, the specification itself does not capture what we intend it to. Each of these considered individually is a bug we might hope to fix. But taken together, they point to something more fundamental - we cannot measure how aligned the model is.

You cannot fix what you cannot measure.

Alignment evaluation has no measure of how much a model is aligned. If we consider a sensitivity parameter, a 97% pass rate from an evaluation with 60% sensitivity is very different from one with 99% sensitivity.

How can we approach this problem?

The model organisms program (by Hubinger et al., 2023) already points in the right direction by creating known misaligned models and testing whether evaluations catch this. We could expand this into a calibration methodology:

Mutation testing: The core idea is to introduce known faults and measure whether the instrument detects them. For alignment evaluations, we could fine-tune models to introduce specific, controlled misalignment (sycophancy, trigger dependent behavior, subtle power seeking, selective compliance, etc.) and measure the fraction of faults caught by our evaluation strategy, giving us a concrete number for evaluation sensitivity. We could systematically vary the type and intensity of misalignment, producing a sensitivity profile rather than a point estimate.

Sensitivity curve: For each misalignment type, we could vary the intensity (for example toggling the sycophancy rate from 5% to 50%) and plot the detection probability. The area under this curve is the evaluation's discriminative power for that type, while the x intercept is the detection threshold which is the minimum misalignment the evaluation can detect.

Cross-method agreement: Run methodologically independent evaluations like behavioral testing, mechanistic interpretability, out-of-distribution probing, adversarial red-teaming on the same model and measure agreement. Disagreement between methods will give more information on the boundary where "aligned" and "appearing aligned" diverges.

Adversarial robustness of the evaluation itself: Train a model specifically to pass the evaluation while being misaligned on held-out scenarios. If this succeeds, the evaluation measures compliance, not alignment. But if it fails, the evaluation has genuine discriminative power. This is the adversarial robustness generally applied to evaluations instead of models.

The struggle does not end here

This is definitely not a solution to our problems with alignment evals. When we calibrate our instruments because the evals themselves are unreliable, this calibration can be gamed too and the calibration itself becomes unreliable. The reason mutation testing works is because the code cannot watch you test it. This does not work when the test subject is an intelligent system that can model the testing process. The more capable the model, the harder calibration gets.

But what calibration helps with is that it targets the evaluation, not the model and we could calibrate evals without the model's knowledge which gives more room for the calibration to work than the evaluation itself does.

There's also the question of understanding what "misaligned" looks like, raising the question - how reliable we humans are as judges, even for concrete cases. But if not humans, then who? And, who calibrates the calibration? If we calibrate the evaluation, we need a meta-evaluation. And then what validates that? It bottoms out at scenarios simple enough that human judgement is trustworthy (for sufficiently specific and concrete cases). Another major pain point is that fine-tuning frontier models to create mutation variants is expensive. Running a full calibration suite with a lot of fine-tuning runs could be an engineering problem, but then again, deploying an uncalibrated eval is presumably more expensive in the long run.

Conclusion

The fix isn't to stop evaluating, but to have more calibration of evaluations done to measure how good the evaluations actually are, and being able to tweak it in real time and see results. This is not an alignment-vs-control argument - both sides need it. Running sensitivity analysis, plotting detection thresholds, testing against adversarial models, and reporting results with error percentage instead of just a pass rate (which might change based on the test suite you run) would give more credibility to any eval claims. And when we build systems understanding that despite alignment, control is necessary, we would need calibration to quantify the risk we are controlling against.

• Meta Superintelligence Labs, led by Alexandr Wang, is releasing its first artificial intelligence model for image creation.
• Dubbed Muse Image, Meta is hoping to attract creators and advertisers.
• Meta has previously used third-party AI models like Midjourney and Black Forest Labs to power image and video generation features in its Meta AI app and site.

Meta on Tuesday released Muse Image, a new artificial intelligence model for creating images as the company seeks to attract creators and advertisers to its offerings.

Originally codenamed Mango, the AI technology marks the second major release from Meta Superintelligence Labs led by Alexandr Wang, who oversaw the April unveiling of the Muse Spark large language model that succeeded the company's previous Llama family of models.

Muse Image will be available for consumers to access for free via the Meta AI app and site, WhatsApp direct messages and Instagram Stories. Power users and creators must sign up for one of Meta's new monthly subscription plans that debuted in May to create many AI-generated images and access certain features. If users hit their free limit, they can purchase a Meta One subscription or wait until their limit resets, the company said.

Muse Image will also power advertiser-specific, image-generation tools as part of Meta's AI-powered Advantage Plus service that lets brands more easily develop ad creative for their marketing campaigns and automate certain tasks. Meta said it's been working with businesses and advertisers as part of debuting Muse Image.

"Muse Image brings native reasoning to the creative process to adjust elements, swap styles, and create variations based on the advertiser's creative, resulting in high-quality, on-brand ad variations with fewer iterations," the company said in a blog post for businesses. "In the coming weeks, advertisers and agencies can expect to see image variants powered by Muse Image."

The new image-generation model and efforts to monetize it show how Meta is trying to expand from its core business of online advertising and generate new revenue sources tied to its hefty spending on AI-related infrastructure.

OpenAI and Alphabet got a head start over Meta in offering similar image-generation models, with Google's Nano Banana becoming a hit with consumers when it was released last fall.

Meta also revealed internal benchmark tests showing Muse Image trailing OpenAI's latest GPT Image 2 model but beating the Nano Banana 2 model in tasks like editing both single and multiple images.

The social media giant has previously used third-party AI models like Midjourney and Black Forest Labs to power various image and video generation features within its Meta AI app and site. The company said it plans to use its new AI model to reduce reliance on similar third-party technologies.

Meta also plans to release an AI video generation model dubbed Muse Video at a later date, adding in a technical blog that it "offers competitive performance in prompt adherence, visual fidelity, and temporal consistency."

Muse Image will be available on Facebook and Messenger as well as more areas within the Instagram and WhatsApp services later in the year.

The world's first commercially built nuclear-powered satellite has reached orbit aboard a SpaceX Falcon 9 rocket.

The BOHR (Betavoltaic Orbital High-Reliability) satellite, built by Florida-based company City Labs, launched to space early this morning (July 7) on SpaceX's Transporter-17 rideshare mission.

Transporter-17's Falcon 9 rocket, which was carrying a total of 81 payloads, lifted off early this morning from the SpaceX pad at Vandenberg Space Force Base in California, and began delivering its payloads to their various orbits about 50 minutes later.

BOHR is a novel cubesat demonstration mission from City Labs, which is testing out its proprietary "NanoTritium" betavoltaic micropower source in space for the first time. Similar to how spacecraft like NASA's Voyager probes' radioisotope thermoelectric generators produce power from the heat emitted from their plutonium cores, City Lab's NanoTritium device harnesses the beta particles emitted from the radioactive decay of tritium, which can be converted directly to electricity using a semiconductor.

“This is a historic step for commercial nuclear power in space,” said City Labs CEO Peter Cabauy in a statement.

BOHR is designed as a pathfinder mission to test the feasibility of City Labs' new technology, which is meant to provide continuous power to spacecraft without a reliance on solar energy. Though its tritium core isn't actually BOHR's power source — the cubesat is still dependent on solar power for general operations — City Labs' technology could help introduce new vehicles capable of exploring places that current spacecraft can't operate for long periods of time, like permanently shadowed regions at the moon's poles.

The moon's south pole, specifically, has come into focus as the target region for NASA's Artemis lunar landing missions. An abundance of water ice there, and its potential for extraction as a resource, makes the lunar south pole particularly suited to support long-term habitation of the moon, and NASA is actively funding the development of nuclear reactor technology to support that goal.

"City Labs’ BOHR arrives as the first commercial answer to that challenge," the company said in a statement. Though the cubesat's NanoTritium power source cannot produce nearly enough energy to power something like a moon base, City Labs sees its application scaling to eventually be able to do so.

One benefit of using tritium as the basis for a power system is the low radiation levels it emits. "City Labs’ tritium-based power systems… are engineered for safe handling, transportation, and integration within standard commercial launch environments," the company stated.

BOHR, and City Labs' tritium development, was funded under a Department of Defense contract. It's also the first nuclear-powered mission to be greenlit under the Federal Aviation Administration's nuclear launch approval under Trump's National Security Presidential Memorandum-20, which was issued in 2019.

City Labs hopes the success of this mission will pave the way for more nuclear-powered spacecraft to support national defense as well as private space missions in the future.

"BOHR demonstrates that safe, compact, and regulatory-approved nuclear power systems are ready for routine commercial deployment," Cabauy said.

Exclusive: Tesla Cybercab Includes More Powerful FSD Hardware

Tesla is pulling out all the stops to make sure its purpose-built robotaxi has the absolute best silicon available. While we have known for a bit that the Cybercab is ditching traditional interior hardware, new details suggest Tesla has also given its computing power a massive upgrade compared to the standard consumer vehicle fleet.

According to information from a very reliable source, production units of the upcoming Cybercab are running a more powerful version of Tesla’s Full Self-Driving computer than what you can currently get in a Model 3 or Model Y. With Tesla kicking off Cybercab mass production at Gigafactory Texas back in April, these new details give us a better look at what’s actually running under the hood.

Crushing Memory Bottlenecks With More RAM

The big change with this new driving computer comes down to onboard memory. Our source noted that the new setup packs more RAM than the Hardware 4 (HW4/AI4) computers shipping in consumer vehicles today.

It’s still unclear whether these early Cybercabs are running a pre-production version of the upcoming AI4+ chip announced during the Q1 2026 earnings call earlier this spring, or if the engineering team simply packaged two current-gen AI4 boards into a single configuration. There’s even a slight chance it could be an early version of the AI5 chip, though that processor isn’t expected to enter mass production until sometime in 2027.

To put this memory bump into perspective, Tesla’s AI4 chips each come paired with 16GB of RAM. Since one FSD computer houses two of these chips, it brings the effective total to 32GB of RAM. While the exact memory capacity of the Cybercab computer remains under wraps, we know it beats that 32GB ceiling.

More RAM is a big deal because it allows the FSD computer to run much larger self-driving models. As Tesla improves FSD and works toward full autonomy, its neural networks have been growing larger and larger, causing the development team to run into memory bottlenecks on current consumer vehicles.

With the upcoming AI4+ computer previously announced to feature double the total package memory of standard AI4 — pushing it up to 64GB of RAM — giving the Cybercab a version of this hardware in advance ensures Tesla’s driverless fleet will have plenty of headroom to run next-gen AI models for years to come.

Built for True Level 4 Autonomy

This extra computing muscle makes perfect sense when you look at how these cars are designed to operate. Tesla recently released first responder documentation for the Cybercab, explicitly stating inside that the Cybercab is equipped with an SAE Level 4 ‘Autonomous Mode.’ The Cybercab is designed to operate entirely without human intervention, and we now know that it’s using a beefier computer than Tesla’s current consumer lineup to do so.

Tesla started testing Cybercabs without steering wheels or pedals on public roads in Austin last week. “We plan to deploy Cybercab as the primary vehicle in our Robotaxi fleet. It eliminates the need for a steering wheel, pedals and traditional controls, freeing up cabin space and ultimately reducing weight and operational costs,” Tesla said about the Cybercab in the 2025 annual impact report it released this week.

Full article content is not available for inline reading.

Read the original article →

run all your coding agents in one terminal. see who's blocked, working, or done at a glance.

run your agents where they already run; your machine, a server, anywhere you can ssh. each one gets its own real terminal, not an app's imitation of one, so even full-screen TUIs render right. click, drag, and split panes into workspaces and tabs, and watch each agent go blocked, working, done. close the laptop and nothing dies; reattach from another terminal, or from your phone over ssh. one local rust binary, not an app: no gui, no electron, no mac-only wrapper, no account, no telemetry. (if you've used tmux: it's that, rebuilt for agents.)

what you get

• a real terminal per agent. you see each agent's own screen, not an app's imitation of one, so even full-screen TUIs render right.
• agent state at a glance. the sidebar rolls every agent up to 🔴 blocked, 🟡 working, 🔵 done, or 🟢 idle, so you always know who needs you. zero config, no hooks required.
• workspaces, tabs, panes. organize by repo or folder, click, drag, and split, mouse-native throughout.
• nothing dies on detach. a background server keeps panes and agents alive; detach and reattach from any terminal, including your phone over ssh.
• runs anywhere. single ~10MB rust binary, linux and macos (windows beta), no dependencies, runs inside the terminal you already use.
• scriptable. a local socket api and cli that agents can drive, plus plugins you can write in any language.

how it compares

tmux gives you persistence and panes, but it was built before agents existed. it has no idea which pane is blocked, working, or done; you can bolt a bell character and per-harness hooks onto it, but you wire each one yourself and still have no shared view of the fleet. the gui agent managers (conductor, cmux, emdash) do show agent state, so call that table stakes. the difference is everything around it. they are apps, often mac-only and closed, that redraw the terminal inside a wrapper. herdr is a single binary that runs in the terminal you already use, anywhere you can ssh, and shows each agent's real screen on a server that keeps it alive when you disconnect.

install

curl -fsSL https://herdr.dev/install.sh | sh

windows preview beta:

powershell -ExecutionPolicy Bypass -c "irm https://herdr.dev/install.ps1 | iex"

also available with brew install herdr, mise use -g herdr, nix run github:ogulcancelik/herdr, or as a stable Linux/macOS binary from releases.

quick start

herdr

herdr starts or attaches to a background server and opens a workspace. run an agent in the pane.

herdr is mouse-native, so clicking and dragging panes, tabs, and split borders gets you everywhere without a single keybinding. for the keyboard, ctrl+b is the prefix: press it, release, then press the action key, so ctrl+b then c makes a tab. one reserved key keeps herdr out of your shell's way.

• ctrl+b then shift+n for a new workspace
• ctrl+b then v or minus to split panes
• ctrl+b then c for a new tab
• ctrl+b then w to switch workspaces
• ctrl+b then q to detach; agents keep running, run herdr again to reattach

remote

run herdr on a VPS and reach it from your local terminal. herdr --remote makes your local terminal the client of the remote server, so pasting images into your agents keeps working, the thing plain ssh + tmux breaks.

herdr --remote workbox
herdr --remote ssh://you@yourserver:2222

supported agents

detection works out of the box with process-name matching plus terminal-output heuristics.

agents can use herdr too

the local Unix socket lets agents create workspaces, split or zoom panes, spawn helpers, read output, and subscribe to state changes instead of polling.

npx skills add ogulcancelik/herdr --skill herdr -g

license

Herdr is dual-licensed:

1. Open source: GNU Affero General Public License v3.0 or later (AGPL-3.0-or-later).
2. Commercial: commercial licenses are available for organizations that cannot comply with AGPL.

Chinese AI companies have made inroads globally by giving their models away for free. Now Beijing is weighing whether to stop them. Chinese authorities have held talks with Alibaba, ByteDance, and Z.ai about whether to restrict foreign access to their most advanced models, including ones not yet released, Reuters reported today, citing three people familiar with the discussions.

Nothing has been decided yet, and the ministries involved have made no official comment, but officials have gone as far as sketching options—including a bar on public release or a limit to domestic use only.

That would be a dramatic U-turn. Most Chinese AI companies currently release their models "open-weight"—publishing the weights online so anyone can download the system and run it themselves. That openness is precisely how they have made inroads globally despite lagging America's best models by seven months on average. The models are free, and some U.S. businesses have adopted them to cut costs compared with proprietary American models.

Closing access would mean surrendering the very lever that has driven China's rise. A trailing player doesn't abandon its biggest advantage unless the concern is national security. In that sense, Beijing would be following Washington, which has already restricted Anthropic's Mythos and OpenAI's GPT-5.6 over concerns about the models' ability to find software vulnerabilities.

China will need to reckon with the reality that models that reach certain capabilities are unsafe. It is going to have the same conversations the White House has had over the last many months. China is going to have to balance the benefits of access to global markets with a desire to control a technology that is central for national security. — Scott Singer, a fellow in the technology and international affairs program at the Carnegie Endowment for International Peace.

Late last month, Z.ai released GLM 5.2, which it claimed had matched Mythos' ability to spot bugs. Once a model’s weights are published online, they are impossible to recall or add safeguards, which presents additional security challenges compared with proprietary models. It also means any forthcoming restrictions would only impact future models.

It follows an escalating tit-for-tat between the two countries. Chinese tech giant Alibaba banned Claude Code internally and asked employees to remove Claude from their work computers, the Information reported Friday. Days earlier, a developer had discovered that Anthropic quietly slipped code into Claude Code that tried to work out whether the person using it was in China or connected to a Chinese AI lab, reading signals like their time zone and network address. An Anthropic engineer, responding on X, said the code was added in March to fight a copying technique called "distillation," that stronger safeguards were now in place, and that it would be removed the next day.

“Distillation,” or using the outputs of a smarter AI model to improve the performance of a weaker one, has become a point of controversy in the AI race. Chinese AI models trail America’s best by roughly seven months on key benchmarks. To catch up, Anthropic and others say Chinese labs are distilling their models—a violation of their terms. Anthropic published a report in February claiming other Chinese firms DeepSeek, Moonshot, and MiniMax generated 16 million exchanges with Claude through approximately 24,000 fraudulent accounts. In June, Anthropic reportedly sent a letter to U.S. officials accusing Alibaba of “brazenly” attempting to distill Claude’s capabilities. The hidden code that rattled Alibaba was built to help catch exactly this.

Anthropic frames distillation as a national-security threat, warning that foreign labs could funnel stripped-down capabilities into military and surveillance systems and let authoritarian governments "deploy frontier AI for offensive cyber operations, disinformation campaigns, and mass surveillance." There's a commercial angle too. If Chinese labs siphon American capabilities and release them open-source, they erode the very business model those labs are banking on.

Anthropic has argued since February that no single firm can solve this—hence its lobbying for a coordinated front of industry, cloud providers, and government. With Washington already deciding who may use Claude Mythos and OpenAI’s GPT-5.6, that front no longer looks far-fetched.

• U.S. companies are increasingly using Chinese-built models as they build out tools and products using AI.
• Recent model releases from Chinese companies are seen by many as highly competitive compared to leading U.S. frontier systems.
• Companies are hunting for cheaper model alternatives as they grapple with unexpectedly high costs related to AI.

Chinese-built AI models are gaining traction among U.S. companies as they narrow the performance gap with leading American rivals while remaining significantly cheaper to use.

Recent model releases from Chinese companies, including DeepSeek and Z.ai, are seen by many as highly competitive compared to leading frontier systems from the likes of Anthropic and OpenAI. Those advances in capability come as token prices for the most advanced models rise at many U.S. AI labs, leaving companies grappling with unexpectedly high costs associated with using the tech.

The share of tokens used by U.S. companies on Chinese AI models via OpenRouter — a platform that enables developers to access a range of AI models — has sat above 30% each week since Feb. 8, with that figure rising as high at 46%. The average across the previous 12 months was just 11%, falling to 4.5% in the first half of 2025.

The rise of Chinese open source and open weight models comes as the U.S. administration increasingly looks to regulate its most powerful AI models and considers how to halt the rapid adoption of alternatives from overseas.

At the end of June, OpenAI said it would limit the rollout of a new set of models on the government's request. Export controls on Anthropic's Mythos and Fable models were also lifted that month, after a tense standoff between the Trump administration and the company.

"Chinese AI models are particularly attractive to American companies now as AI costs skyrocket," Kyle Chan, fellow in the John L. Thornton China Center at think tank Brookings, told CNBC. "Where previously U.S. companies were prioritizing AI adoption regardless of model, now they're getting more cost-conscious."

Rising adoption

As companies look to deploy AI models to create new products and bring internal efficiencies, engineers are increasingly experimenting with cheaper open source and open weight models, of which the most capable are made by Chinese companies.

Open-source and open-weight models make different parts of an AI model available for developers to inspect, use and sometimes modify. They differ from closed systems, like many flagship models produced by OpenAI, Anthropic and Google, where code and inner workings remain proprietary.

In June, AI startup Lindy moved 100% of its traffic from Anthropic's Claude models to DeepSeek, a Chinese company which burst onto the scene with a bombshell release in early 2025 and launched a new model in April.

"We did it, and you could see that cost curve go down, like, crash to the ground," CEO Flo Crivello told CNBC. He said the decision will save Lindy millions of dollars within months.

DeepSeek saw its share of gateway tokens climb between May and June on Vercel, a platform that allows developers to deploy and run apps and websites.

Z.ai's GLM 5.2 was released to great fanfare in June and saw the fastest adoption of any model tracked by Vercel in 2026, Harpreet Arora, head of agentic infrastructure at Vercel, told CNBC. "In its first full week after launch, daily token volume grew about 27x and the number of customers using it grew about 80x."

"Price is doing the work here," Arora said. "When a task doesn't need the best model, teams are beginning to route it to the cheapest one that's good enough, and the recent wave of models coming out of China is winning that trade."

Open source Chinese models can be "60% to 90% cheaper" than the leading Anthropic and OpenAI models, Justin Summerville, who works on data and analytics at OpenRouter, told CNBC.

While Claude and ChatGPT still dominate in terms of usage on LaunchLemonade, an AI agent platform for regulated industries, GLM 5.2 is now in the top five models on the platform, LaunchLemonade CEO and founder Cien Solon told CNBC.

"Chinese models like Z.ai and Alibaba's Qwen are becoming options for companies [as] they offer an attractive combination of performance and cost for specific workloads," Cien said. "Businesses with more mature AI strategies are increasingly willing to use them where they make technical or commercial sense."

Approaching the frontier

The performance of Chinese AI models is also increasing.

While often a "fraction of the cost" of U.S. rivals, they operate "close to the top American frontier models," said Brookings' Chan, estimating that they are currently "six to nine months" behind top U.S. rivals.

"The new open source models are performing well and prove capable for all but the most complex LLM tasks," Summerville said.

GLM 5.2 landed within a percentage point of Anthropic's Opus 4.8 on one closely watched agentic benchmark, at roughly a fifth of the cost. Some researchers have said GLM 5.2 can perform on par with top U.S. labs on some cyber benchmarks.

Switching to DeepSeek V4 increased performance on many core use cases for Lindy, Crivello said in a post on X.

"We're seeing companies increasingly motivated to turn to cheaper AI stacks they can control and adapt themselves, and given the state of open-source and open-weight models that often means leveraging Chinese options," Yacine Jernite, head of machine learning at Hugging Face, told CNBC.

"There is a real risk that users get stuck having to choose between performant but expensive US proprietary models whose price and accessibility can quickly fluctuate, or using Chinese models as the only feasible alternative whenever they want to control costs or own their AI stack."

Full article content is not available for inline reading.

Read the original article →

CloudWatch Application Signals now automatically captures errors, performance anomalies, and deployment events

Today, AWS announces Service Events for Amazon CloudWatch Application Signals, which automatically captures exception and latency event snapshots, function-level performance data, and deployment events from instrumented services without additional code changes. Customers can now quickly identify whether a deployment has introduced new exceptions by navigating to CloudWatch > Application Signals > [Service] > Errors in the CloudWatch console.

Service Events is available to any application with CloudWatch Application Signals enabled. Customers instrument their applications with the ADOT SDKs or the Amazon CloudWatch Observability EKS add-on. Once Application Signals is active, Service Events begins capturing exception and latency event snapshots and deployment events automatically. Optionally, customers can gain deeper performance visibility by turning on function-call metrics.

Service Events is available in all commercial AWS Regions. Supported languages are Java, Python, and JavaScript.

To get started, see Monitor service events in the Amazon CloudWatch User Guide. Service Events data is captured as logs. Function call metrics are captured as OpenTelemetry metrics. Standard CloudWatch pricing applies. For details, see CloudWatch pricing.

PgDog is a proxy for scaling Postgres. One of its features is connection pooling, which allows many client applications to use the same database without exceeding its connection limit.

There are many connection poolers out there, notably PgBouncer, RDS Proxy, Pgpool-II, Supavisor, and others. So, why build another one?

Leaky abstractions

Most tools in the Postgres ecosystem take the UNIX philosophy very seriously: do one thing and do it well. In general, this is a good way to build reliable software, and it is why PgBouncer is so popular today. It works.

However, it works by introducing what we in the industry call a leaky abstraction.

When you deploy PgBouncer or RDS Proxy, you quickly become aware that you added a piece of infrastructure that changes the way you use your database. It requires you to make trade-offs, often by changing your application code.

If you’ve been building your app for a while, which is often the case when you need to add connection pooling, this could mean changing thousands of lines of production code, usually with very little test coverage.

With PgDog, that’s no longer necessary.

Connection state

The first thing to go when you add a connection pooler is session control, i.e., SET commands. They are used to temporarily override database settings in order to, for example, execute slower queries:

SET statement_timeout TO '5m';
SELECT * FROM users WHERE banned IS true;

Since connection poolers reuse connections between clients, the connection state of one client “leaks” into the connection state of another.

In production, this could be pretty bad. Best case scenario, a slow query gets to run for a while, causing a database incident. Worst case, your Row Level Security (RLS) policy, which relies on a session variable, stops working and rows silently disappear.

So, the typical advice when migrating to connection pooling is to just not use SET anymore.

However, SET is a real Postgres feature. If you’re not allowed to use a database feature, you are making a trade-off and have to change how you write your apps. And if you’re using it for something important, like RLS, you can’t use connection pooling at all.

Handling SET statements

PgDog ships with a built-in SQL parser. It can detect SET statements, extract variable names and values, and store them on each client connection in the proxy.

When a client runs a query, PgDog first checks that its state matches that of the server, and if it doesn’t, it updates it by running a series of SET statements of its own.

The algorithm we use to detect SET statements is very quick. If several variables are different, we use query pipelining to update them in one round trip.

This makes the performance impact small, and you can keep using a Postgres feature you’ve been relying on, as you scale.

LISTEN/NOTIFY

LISTEN and NOTIFY are Postgres commands that implement a publish/subscribe queue inside Postgres. It’s a neat feature, and it works pretty well without having to add another database to your stack.

It’s also a feature you had to give up when you added a pooler, at least if you wanted to use transaction mode.

If you built an app in the last 10 years (PostgreSQL 10 came out in 2017), you probably used it, before migrating to SQS or Redis.

PgDog makes that work too. It handles both commands internally, while moving messages between multiple PgDog processes. To the client, this looks like PgDog is the broker, but actually, it’s still Postgres.

We also make sure to preserve all of NOTIFY’s transactional semantics, even the ones that made some of our friends take down their database (we fixed that, by the way).

The internal implementation is kind of interesting. We use Tokio’s broadcast channel to move messages between clients in the same PgDog process. To support multiple PgDog processes (e.g., in production, you would run several containers), we also send all LISTEN and NOTIFY commands to Postgres via a dedicated connection.

So in effect, PgDog acts as a pub/sub client, proxying other pub/sub clients, using Postgres as the broker. A bit of creative engineering, just to make a feature we use “just work”, as we scale Postgres.

Multithreading

PgDog is built on Tokio, a Rust async runtime with multithreaded workers. Each client is handled by its own async task, which scales linearly with the number of connections.

Using Tokio allows us to take advantage of multiple CPUs, serving more clients and more queries per second from one PgDog process.

However, with PgBouncer supporting SO_REUSEPORT and RDS Proxy “serverless” autoscaling, why does this matter?

Both tools require you to “shard” your connection pools. Each proxy process has its own dedicated set of Postgres connections. Once a client connects, it cannot change instances anymore, so if it becomes overloaded, all other clients get stuck too.

By multithreading on multiple CPUs, PgDog processes can handle a lot more traffic. This allows it to pool more clients with fewer server connections, increasing connection utilization and efficiency.

Multithreaded processes can also better handle sudden bursts of queries, because they don’t need to wait for autoscaling. If your app has a latency SLA, you don’t want your proxy getting in the way.

Last but not least, the runbook for managing multithreaded processes is shorter: just one source of metrics and health checks, without pushing complexity into hard-to-debug places, like the Linux kernel or the AWS RDS control plane.

Closing thoughts

It can be hard to replace a 20-year-old project like PgBouncer but, when we think something isn’t quite right, we fix it. PgDog has been in production for over a year, pooling connections at 2M queries per second.

It’s free (as in freedom to use and modify), it’s open source, and you can deploy it anywhere.

Give Claude the ability to watch any video.

Claude Code (recommended — auto-updates via marketplace):

/plugin marketplace add bradautomates/claude-video
/plugin install watch@claude-video

Codex, Cursor, Copilot, Gemini CLI, or any of 50+ Agent Skills hosts:

npx skills add bradautomates/claude-video -g

(-g installs globally for your user, available across all projects. Drop it to scope per-project.)

Zero config to start — yt-dlp and ffmpeg install on first run via brew on macOS (Linux/Windows print exact commands). Captions cover most public videos for free. Whisper API key is only needed when a video has no captions.

Claude can read a webpage, run a script, browse a repo. What it can't do, out of the box, is watch a video. You paste a YouTube link and it has to either guess from the title or pull a transcript that's missing 90% of what's on screen.

With Claude Video /watch you can paste a URL or a local path, ask a question, and Claude fetches captions first, downloads only what it needs, extracts frames (scene-aware, or fast keyframes at efficient detail), pulls a timestamped transcript (free captions when available, Whisper API as fallback), and Reads every frame as an image. By the time it answers, it has seen the video and heard the audio.

/watch https://youtu.be/dQw4w9WgXcQ what happens at the 30 second mark?

What people actually use it for

Analyze someone else's content. /watch https://youtu.be/<viral-video> what hook did they open with? Claude looks at the first frames, reads the opening transcript, breaks down the structure. Same for ad creative, competitor launches, podcast intros, anything where the how matters as much as the what.

Diagnose a bug from a video. Someone sends you a screen recording of something broken. /watch bug-repro.mov what's going wrong? Claude watches the recording, finds the frame where the issue appears, describes what's on screen, often catches the cause without you ever opening the file.

Summarize a video. /watch https://youtu.be/<long-thing> summarize this does the obvious thing — pulls the structure, the key moments, what was actually said and shown. Faster than watching at 2x.

Cut the hype out of an update video. /watch https://youtu.be/<launch-video> what's actually new — skip the hype Strip a "game-changer" feature drop down to the few things that matter, so you get the substance without ten minutes of intro and overselling.

Turn a playlist into notes. /watch https://youtu.be/<video> summarize this to a note Run it across a series and file a per-video summary, so a channel or course becomes a searchable set of notes instead of hours you have to sit through.

How it works

1. You paste a video and a question. URL (anything yt-dlp supports — YouTube, Loom, TikTok, X, Instagram, plus a few hundred more) or a local path (.mp4, .mov, .mkv, .webm).
2. yt-dlp checks captions first. At transcript detail, captioned URLs return without downloading video. Otherwise, or when Whisper needs audio, it downloads only what the run needs.
3. ffmpeg extracts frames at the chosen detail. efficient decodes keyframes only (near-instant); balanced/token-burner prefer scene-change frames and fall back to the duration-aware uniform sampler when they under-produce. JPEGs are 512px wide by default and clamped to 1998px tall for Claude Read compatibility.
4. The transcript comes from one of two places. First try: yt-dlp pulls native captions (manual or auto-generated) from the source. Free, instant, accurate-ish. Fallback: extract a mono 16 kHz 64 kbps mp3 audio clip (~480 kB/min) and ship it to Whisper — Groq's whisper-large-v3 (preferred — cheaper and faster) or OpenAI's whisper-1.
5. Frames + transcript are handed to Claude. The script prints frame paths with t=MM:SS markers and the transcript with timestamps. Claude Reads each frame in parallel — JPEGs render directly as images in its context.
6. Claude answers grounded in what's actually on screen and in the audio. Not "based on the description" or "according to the title." It saw the frames. It heard the transcript. It answers the way someone who watched the video would.
7. Cleanup. The script prints a working directory at the end. If you're not asking follow-ups, Claude removes it.

Frame budget — why it matters

Token cost is dominated by frames. Every frame is an image; image tokens add up fast. The script's auto-fps logic exists so you don't blow your context budget on a sparse scan of a 30-minute video that would have been better answered by a focused 30-second window.

When the user names a moment ("around 2:30", "the last 30 seconds", "from 0:45 to 1:00"), pass --start / --end. Focused mode gets denser per-second budgets, capped at 2 fps. Far more useful than a sparse pass over the whole thing.

Frame deduplication

Frame selection — keyframes (efficient), scene-change detection (balanced/token-burner), or the uniform sampler it falls back to — can still surface near-identical frames: a screen recording that holds one slide for 90 seconds produces a dozen, each billed as a separate image. A dedup pass drops them before frames reach Claude. It runs by default on every frame mode (--no-dedup turns it off):

1. One ffmpeg call scales each extracted JPEG to a 16×16 grayscale thumbnail. Everything after is pure-stdlib Python — no image libraries.
2. For each frame, compute the mean absolute difference against the last frame that was kept (average per-pixel brightness change, 0–255 scale).
3. If that difference is at or below the threshold (2.0), the frame is a near-duplicate and is dropped. Otherwise it's kept and becomes the new reference.
4. The frame-budget cap applies after dedup, so the budget is spent on distinct frames.

Comparing against the last kept frame (not the previous one) catches slow fades that never trip a frame-to-frame threshold. The threshold is deliberately low and measures absolute brightness rather than structure, so a one-line code diff, a terminal scrolling a row, or two differently-colored flat slides all survive.

The Frames line reports what was collapsed, e.g. 6 selected from 14 candidates (… 8 near-duplicates dropped …). On always-moving footage nothing is dropped and you pay what you would have anyway.

Detail modes — measured

The --detail dial trades speed and token cost for visual fidelity.

Install

Claude Code

/plugin marketplace add bradautomates/claude-video
/plugin install watch@claude-video

Update later with /plugin update watch@claude-video.

Codex, Cursor, Copilot, Gemini CLI, and 50+ other hosts

The Agent Skills CLI installs the skill into whatever agents it detects:

npx skills add bradautomates/claude-video -g

claude.ai (web)

1. Download watch.skill from the latest release.
2. Go to Settings → Capabilities → Skills.
3. Click + and drop the file in.

Enable "Code execution and file creation" under Capabilities first — the skill shells out to ffmpeg and yt-dlp, so it won't run without it.

Usage

/watch https://youtu.be/dQw4w9WgXcQ what happens at the 30 second mark?
/watch https://www.tiktok.com/@user/video/123 summarize this
/watch ~/Movies/screen-recording.mp4 when does the UI break?
/watch https://vimeo.com/123 what tools does she mention?

Focused on a specific section — denser frame budget, lower token cost:

/watch https://youtu.be/abc --start 2:15 --end 2:45
/watch video.mp4 --start 50 --end 60

Develop

python3 -m pytest -q
bash skills/watch/scripts/build-skill.sh      # → dist/watch.skill

Open source

MIT license.

Built on yt-dlp, ffmpeg, and Claude's multimodal Read tool. Whisper transcription via Groq or OpenAI.

Built by Brad Bonanno.

CubeSandbox

Instant, Concurrent, Secure & Lightweight Sandbox Service for AI Agents

Cube Sandbox is a high-performance, out-of-the-box secure sandbox service built on RustVMM and KVM. It supports both single-node deployment and easy scaling to multi-node clusters. It is compatible with the E2B SDK and can create a hardware-isolated, fully serviceable sandbox in under 60ms with less than 5MB of memory overhead.

📰 News

• v0.5: AutoPause, Terraform deployer, ARM64 & network policy hardening
  AutoPause/AutoResume — idle sandboxes auto-suspend and wake on the next request. Terraform one-click cluster deploy. ARM64 native full-stack support. Network policy hardening — per-sandbox traffic tokens, policy-routing egress.
• v0.4: Safer egress, easier ops
  Credential vault — Agents call external APIs as usual; keys never enter the sandbox. Dashboard — version matrix and template health checks; see at a glance whether templates need rebuilding after upgrades.
• Snapshot, Clone & Rollback at hundred-millisecond granularity
  CubeSandbox 0.3.0 introduces the CubeCoW Copy-on-Write snapshot engine, enabling event-level snapshots, instant cloning, and rollback to any saved state.
• Initial open-source release
  Cube Sandbox is now open source! Millisecond boot, hardware-level isolation, E2B-compatible sandbox for AI Agents.

Product Highlights

• Sub-60ms boot · High density · Auto pause/resume: Average <60ms cold start, <5MB overhead per instance — run thousands of Agents on one node. Supports automatic sandbox pause and resume for cost optimization.
• Hardware-level isolation: Each sandbox gets its own Guest OS kernel — no Docker shared-kernel escapes; run untrusted LLM-generated code safely.
• Seamless E2B migration: Native E2B SDK compatibility — swap one URL env var, zero business code changes.
• Web console: Manage sandboxes, templates, nodes, and version matrix in the browser.
• Credential vault: Agents call LLMs and external APIs as usual — keys never enter the sandbox, model context, or logs.
• Egress control: Domain allowlists, instant block on unauthorized egress, full audit logs for compliance.
• Snapshot · Clone · Rollback: Hundred-millisecond checkpoints on running sandboxes — roll back or fork from any saved state.
• Template system: Turn OCI images into templates in one step, install official presets from the Template Store, auto-distribute across nodes.

Benchmarks

In the context of AI Agent code execution, CubeSandbox achieves the perfect balance of security and performance:

Quick Start

Cube Sandbox requires an x86_64 Linux environment with KVM support.

The guide walks you through everything in four steps — provisioning a server, installing Cube Sandbox, creating a sandbox template, and running your first agent code.

First thing after install: open the Web console

After one-click deployment, open in your browser: http://<control-node IP>:12088

Architecture

Roadmap

License

CubeSandbox is released under the Apache License 2.0.

Spacelift Intelligence Now Deploys Modules Straight From Your Module Registry

Your developers don’t want a Terraform lesson. They want the load balancer, the database, the network stack you already built and blessed. It’s sitting in your module registry right now, reviewed, versioned, and ready for deployment.

The problem is the last mile. To use it, a developer still has to find the module, learn its slug, write the module block, wire up the inputs, and open a PR. Or they skip all of that and ask you to do it. Either way, the guardrails you built into that module don’t save you from the ticket queue. You wrote the module to stop being the bottleneck, but it’s no longer enough.

Spacelift Intelligence can help to eliminate the bottleneck. Spacelift Intent can now deploy a module from your Spacelift module registry as a single managed resource, described in plain language. Same registry and modules, now with a new way in.

Ask for it by name

A developer doesn’t need the slug or the version number. They simply ask:

Deploy the elb module.

Intent looks up your registry, finds the module, and picks its latest active version. If the module needs input variables, it asks for them before doing anything else. When someone wants more precision, they can supply it:

Deploy the elb module at version 1.2.0, with the web load balancer inputs.

Every module in your registry has a slug in the form of terraform-<provider>-<name>, so elb for the aws provider resolves to terraform-aws-elb. Nobody has to memorize that. Name the module, and Intent resolves it. Give it an exact slug or version when precision matters, and it’ll respect that too.

Before Intent applies anything, it runs three checks: is the module visible to this user, does the requested version exist and is it active, and did they supply every required input with nothing extra. Miss a check and the request stops with a clear error. Nothing gets applied. Pass the checks and Intent evaluates your Intent policies, then runs the module on a worker. Module deployments can take a while, so they run in the background, and the assistant reports back with a summary when the run finishes.

This only reaches modules published to your Spacelift registry. It doesn’t pull from the public Terraform Registry or straight from Git. If it’s not in your registry, Intent won’t deploy it, which is the point: you already decided what’s safe to hand developers, and this feature doesn’t go around that decision.

Update and upgrade without restating everything

Once a module is deployed, changing it stays conversational. To change an input:

Set the idle timeout on the web load balancer to 120.

To move to a newer version:

Upgrade the web load balancer to the latest version.

Nobody has to restate the module’s existing inputs to upgrade it. Intent compares the version you’re using to the version you’re moving to, figures out how the inputs changed between them, carries your current inputs forward, and only asks about anything new or newly required. The upgrade applies in place: the new version’s code runs against your existing state, and the target version has to be active.

One thing stays fixed: you can’t swap which module a deployment points to. That’s set when the deployment is created. If you need a different module, delete the deployment and create a new one against it.

Deletion respects the dependency graph

Ask Intent to remove a deployment and it checks whether anything else in the project depends on it first, then asks you to confirm before it destroys the module’s resources and removes it from state. A module deployment sits in your project’s dependency graph like any other resource. Other resources can depend on it, and if you export the project, its outputs become live references in the generated code.

The registry side is protected too. Spacelift won’t let you delete a module or a module version while an Intent deployment still uses it. You tear down the deployment first, so you can’t orphan it by accident from the registry side. Yanking a version is fine. You can still delete a deployment pinned to a version that’s since been yanked.

One edge case to flag: if a module was shared into your space from elsewhere and that share gets revoked, or the owning account removes the module, your deployment can lose visibility, and you won’t be able to delete it through Intent until access comes back.

It shows up like any other resource, because it is one

A deployed module isn’t a black box bolted onto your project. In the Resources tab, it’s a single resource of type spacelift/module, and you can expand it to see the resources the module created underneath. Those nested resources are read-only. You manage the deployment as a unit, through its inputs and version, not by reaching in and editing individual resources.

The History tab records every create, update, and delete on that deployment, with full receipts. State is stored and encrypted the same way as any other Intent resource. Nothing about audit trail or state handling changes because the resource happens to be a module.

Governance doesn’t step aside either. Module deployments are evaluated against your Intent policies before anything gets applied. For a module, the policy sees resource_type: spacelift/module, the operation (create, update, or delete), the module’s slug as provider, the exact version as provider_version, and the input variables as proposed_state.

That’s the level policies operate at for a module: the module and the inputs, not the individual cloud resources the module will create inside its own plan. If you need to govern what happens inside the module, that governance belongs where the module is authored and published, not bolted onto the Intent policy layer.

Finding what's available

Nobody has to know your registry by heart. Ask Intent what modules exist and it lists what’s in your registry that the requester has access to, so they can pick one to deploy. The Module Registry in the Spacelift UI is still there for browsing the same catalog visually.

Why this is worth using

The module registry was already your answer to “how do we let developers self-serve without letting them do anything they want.” This feature removes the part of that answer that still ran through you: writing the module block, opening the PR, being the person who translates a request into Terraform.

Developers describe what they want. Intent finds the right module, checks it against your rules, and deploys it under your existing policies, state, and audit trail. Nothing about what’s governed changes. Who has to sit in the middle does.

If you’re already publishing modules to your Spacelift registry, there’s nothing to set up. Point your team at Intent and have them ask for what they need.

You probably don't need another database.

Do you really need separate systems for caching, queues, search, documents, and vector embeddings when you already have Postgres?

The Gist

It started with a gist and a lively Hacker News thread. The premise was simple: Postgres isn't the best at everything, but it's good enough for most things. In practice, most teams are running too many microservices and databases. It's all premature optimization. More operational overhead, more maintenance burden, more monitoring complexity, higher costs, harder tracing, and longer debugging sessions.

The Typical Pattern

You need caching, so you add Redis. Full-text search? Bolt-on Elasticsearch. Background jobs? Another Redis, or maybe Sidekiq. Documents with flexible schemas? Default to MongoDB. Analytics? Snowflake. Events? Reach for Kafka. Before long, your "simple" application talks to seven different data stores and microservices, each with its own deployment, backup strategy, failure modes, and 3 AM pages when they stop talking to each other. Each system adds operational surface area: monitoring, alerting, failover testing, security patching, version upgrades.

The "Webscale™" Stack

Multiple systems to operate and monitor

With Postgres

One database. One backup strategy. One set of failure modes.

"But Postgres Isn't Webscale™!"

We hear this argument all the time. But what percentage of software projects actually ever reach so-called "webscale"? About 0.3%? For your stealth startup or saas, should you really be burning your innovation tokens on multiple microservices and databases instead of the actual problem at hand?

If companies serving millions of users like Notion, Netflix, Instagram, etc trust "boring" technology, your startup can probably get by without a seven-database architecture. Besides, if you ever truly get to webscale and tap out Postgres's capabilities, you can just bring the additional pieces as needed, when truly needed.

Maybe Postgres Is Enough

Before reaching for another database, see if you can accomplish it with what Postgres already offers:

When You Actually Need Something Else

This isn't about dogma. Sometimes you genuinely need specialized infrastructure. But the bar should be high: only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative. Until then, every system you add is a bet that the benefit outweighs years of maintenance, monitoring, and debugging.

Eliminating Go bound checks with unsafe

Bound checks elimination (BCE) is probably one of the most robust, most productive optimization techniques in the Go world. This is my go-to technique, I think, when I'm starting to optimize any Go hot path. Why is it so robust? Because it reduces number of instructions and number of branches in a hot path. This alone is excellent because it reduces number of wasted cycles, but there are additional benefits on top of that. If your code already experiences cache capacity and/or conflict misses lowering number of instructions can help with those significantly. We are talking about L1 icache, the uop cache and, maybe, frontend branch prediction caches. Also register pressure, BCE can help with that too. While being so robust, bound checks are easy to detect and sometimes relatively easy to eliminate. Long story short, BCE is usually a quick win worth trying first. However sometimes it's not easy to eliminate bound checks with conventional methods and that's where the unsafe techniques enter and this is what this post is about.

First, what are the Bound Checks? Go is a safe language and provides some guarantees, e.g. the guarantee that you can't access out-of-range slice elements. To do that the compiler adds a bunch of assembly code that makes sure the runtime panics when the out-of-range index is accessed. Let me quickly illustrate it by this tiny example:

func load(src []byte, i int) byte {
	return src[i]
}

If I compile it with the -B flag which disables bound checks it produces this concise assembly:

0x71d   MOVQ AX, 0x8(SP)	
0x722   MOVZX 0(AX)(DI*1), AX	
0x726   RET

Assembly with the -B flag removed shows the overhead caused by bound checks:

+ 0x796   PUSHQ BP		
+ 0x797   MOVQ SP, BP		
  0x79a   MOVQ AX, 0x10(SP)	
+ 0x79f   CMPQ DI, BX		
+ 0x7a2   JAE 0x7aa		
  0x7a4   MOVZX 0(AX)(DI*1), AX	
+ 0x7a8   POPQ BP			
  0x7a9   RET			
+ 0x7aa   CALL 0x7af		[1:5]R_CALL:runtime.panicBounds
+ 0x7af   NOPL

Of course this assembly diff is over-dramatic. The function is tiny and it was a leaf but enabling BC made it acquire a CALL which caused addition of the PUSHQ/POPQ BP and MOVQ SP, BP. Any function that gets a CALL stops being a leaf and gets those prologue instructions regardless of bound checks. But even ignoring that, my point is that there is still an overhead. But actually, you know what? As I think about it, it's not over-dramatic. If you have tiny function and BCE converts it to leaf which removes the CALL overhead then it's a legit BCE-related optimization.

By the way, you don't really need to search assembly to find bound checks. The compiler can list all the bound checks with this command:

go build -gcflags="-d=ssa/check_bce/debug=1" .

Before we switch to using unsafe let's take a look at a conventional way of dealing with BC. Go compiler often can eliminate bound checks if you "prove" that they are unnecessary. You prove it by accessing the upper/lower bound first before looping over the rest of the range. Here is an example from a real codebase:

 func matchLen(a, b []byte, limit int) int {
+       a = a[:limit]
+       b = b[:len(a)]
        i := 0
-       for ; limit >= 8; limit -= 8 {
+       for ; i <= len(a)-8; i += 8 {
                xor := loadU64(a[i:]) ^ loadU64(b[i:])
                if xor != 0 {
                        return i + bits.TrailingZeros64(xor)/8
                }
-               i += 8
        }

-       for ; limit > 0 && a[i] == b[i]; limit-- {
-               i++
+       for ; i < len(a) && a[i] == b[i]; i++ {
        }

        return i
 }

Using i <= len(a)-8 in the loop condition makes the compiler eliminate the bound check as it now can provably determine that all a accesses are within the range. b = b[:len(a)] eliminates b-related bound checks in the loop.

With every Go version compiler becomes smarter and smarter about the bound checks elimination. There are often good ways to hint to the compiler about BCE but sometimes it's not possible to eliminate BC with conventional methods and that's where unsafe enters.

⚠️ Note that we are talking here about the cases where the compiler can't determine that a bound check is unnecessary but the programmer can. If you can't prove that a bound check is unnecessary then don't eliminate it, the compiler inserts it for a good reason. I think this is obvious but needed to note it just in case.

Ok, let's eliminate some bound checks with unsafe now, shall we? I'll use the best example I could find in my brotli library. There is one ubiquitous function used in there that unavoidably brings BC with itself. binary.LittleEndian.Uint32:

// Uint32 returns the uint32 representation of b[0:4].
func (littleEndian) Uint32(b []byte) uint32 {
	_ = b[3] // bounds check hint to compiler; see golang.org/issue/14808
	return uint32(b[0]) | uint32(b[1])<<8 | uint32(b[2])<<16 | uint32(b[3])<<24
}

This function reads 4 bytes in little endian order from a slice and is useful wherever you store data bit-packed in byte slices. You see in the code that it already tries to eliminate bound checks by giving the compiler a hint: _ = b[3] which keeps one bound check for b[3] but eliminates bound checks for indexes 0-2. However, one bound check is left and any unnecessary code is waste in a hot path. Here is an unsafe example that eliminates all the bound checks (which also converts the load function into a leaf and removes the CALL overhead):

//go:build !purego && (amd64 || 386 || arm64 || loong64 || ppc64le || wasm)

package encoder

import "unsafe"

func loadU32LE(b []byte, i uint) uint32 {
        //       (4)         (3)          (2)             (1)
	return *(*uint32)(unsafe.Add(unsafe.Pointer(unsafe.SliceData(b)), i))
}

Let's note that function signature has changed. You would call the stdlib variant like this: binary.LittleEndian.Uint32(data[offset:]). And the unsafe variant like this: loadU32LE(data, offset). This is important because if you'd keep (data[offset:]) you'd still have one bound check on the caller side which would make sure data[offset] is in bounds. Also note the go:build instruction. This trick works only on machines that put data into memory in little endian order in the first place. None of this is novel, by the way. Perf-critical libraries like klauspost/compress rely on the very same unsafe little-endian loads; it's just a niche technique that isn't widely known.

Let's go through the example:

• unsafe.SliceData(b) returns exactly the same result as what &b[0] would return - a pointer to the first element of the slice. If we used b[0] we'd introduce a bound check which we are trying to eliminate. The nice part of unsafe.SliceData is that, unlike &b[0], you can use it on empty slices.
• unsafe.Pointer converts *byte returned by unsafe.SliceData into unsafe.Pointer type needed for unsafe.Add.
• unsafe.Add(ptr, i) returns unsafe.Pointer representation of &b[i],
• which is cast to *uint32 and dereferenced in the end.

You might say that I have introduced 3 function calls to eliminate a single bound check, but if we check the assembly we can see that the Go compiler eliminates all the bound checks and inlines all the calls:

MOVQ AX, 0x8(SP)	
MOVL 0(AX)(DI*1), AX	
RET

So what is the performance difference between stdlib LE loader and hand-rolled unsafe one? Let's benchmark it.

package bce

import (
	"encoding/binary"
	"testing"
	"unsafe"
)

func loadU32LE(b []byte, i uint) uint32 {
	return *(*uint32)(unsafe.Add(unsafe.Pointer(unsafe.SliceData(b)), i))
}

var sink uint32

func BenchmarkLoadU32LE(b *testing.B) {
	data := make([]byte, 4096)
	b.SetBytes(int64(len(data)))
	for b.Loop() {
 var acc uint32
		for i := uint(0); i+4 <= uint(len(data)); i += 4 { acc += loadU32LE(data, i) }
		sink = acc
	}
}

func BenchmarkStdUint32(b *testing.B) {
	data := make([]byte, 4096)
	b.SetBytes(int64(len(data)))
	for b.Loop() {
 var acc uint32
		for i := 0; i+4 <= len(data); i += 4 { acc += binary.LittleEndian.Uint32(data[i:]) }
		sink = acc
	}
}

goos: linux
goarch: amd64
pkg: bcetest
cpu: 12th Gen Intel(R) Core(TM) i5-12500
BenchmarkLoadU32LE   22644585   273.7 ns/op   14966.04 MB/s
BenchmarkStdUint32    9922156   600.7 ns/op    6818.58 MB/s

The unsafe version is more than 2x faster. You might say that you can't really trust microbenchmarks, the situation is completely different when you surround the benchmarked code with a real codebase. Alright, fair enough. Here are the benchmarks of a real-world compression matchfinder doing real-world work on a production-like workload before and after replacing the stdlib LE loaders with unsafe ones:

pkg: github.com/andybalholm/brotli/matchfinder
     │  before.txt  │              after.txt               │
     │     B/s      │     B/s       vs base                │
Trio   90.39Mi ± 0%   99.99Mi ± 0%  +10.62% (p=0.000 n=30)

The obvious downside: it's unsafe, d'oh. All the validations the compiler inserted for you now have to be proved by the programmer to be truly unnecessary. As I already complained I wish Go had the nobounds compiler hint but it doesn't, so the only viable option we are left with is using unsafe pointer arithmetic.

You can now customize Siri’s pace and expressivity in the latest iOS 27 beta

With the latest iOS 27 developer beta, Apple is giving testers an early look at one of the upcoming improvements to its AI-powered Siri: the ability to adjust how quickly and expressively the AI assistant speaks. In iOS 27 beta 3, out today, Apple has enabled the voice controls for “Pace” and “Expressivity” that were previously labeled as “Coming soon” in the first developer beta releases.

The update is part of Apple’s broader effort to make Siri feel more natural and personal, as it rebuilds the assistant around generative AI. Like ChatGPT and others offering voice AI assistants, letting users customize how the AI sounds is an important aspect in helping connect people with the new technology.

However, ChatGPT’s voice-customization options allow users to go even further, as the ability to adjust the AI’s warmth and enthusiasm was rolled out in December 2025, alongside options to configure the base style and tone. The latter lets users adjust OpenAI’s assistant to be more friendly, professional, candid, or quirky, among other styles. This is reflected not only in how ChatGPT speaks, but also in how it presents information to the user.

First introduced at Apple’s Worldwide Developers Conference (WWDC 26) in June, Siri’s voice controls let users personalize their Siri experience beyond just choosing a male- or female-sounding assistant. Now beta testers will be able to switch between a range of voices with different accents, and then use sliders to change how slowly or quickly Siri speaks and how much human-like emotion its voice conveys.

As you make the adjustments, Siri will practice saying some common things, like “You have one new message,” so you can get a sense of how the different voices sound.

The AI version of Siri is deeply integrated across the updated version of iOS, where it will allow iPhone owners to start conversations by speaking, swiping down from the Dynamic Island at the top of the screen and typing, tapping on the phone’s side button, or even by using the brand-new stand-alone Siri app.

Other, more minor updates are also rolling out with iOS 27 beta 3, including an updated Reminders app icon. (We should note some people on X are also reporting losing access to the new Siri after updating, or seeing their phone again begin indexing their data — typically, the first step in optimizing Siri AI for search.)

The Tao of Software Design

During my previous trip from San Francisco to Sydney, I watched one of my favorite films: Enter the Dragon. This film is martial art's legend Bruce Lee’s most iconic film: part martial arts showcase, spy thriller, and the expressions of his speed, charisma, and philosophy on screen. With 15 hours in the air, one film turned into a Bruce Lee marathon. Yes, I even watched the awkward posthumous Game of Death, an unfinished film assembled after his death.

Lee’s influence in cinema and martial arts is transcending, but in addition to that, his philosophy influences many people, including myself. What I keep coming back to is his philosophy applied to a craft as a practitioner. What I keep coming back to is not only the physical craft, but the way he thought about craft itself.

After his death, Lee’s work was published as a book, The Tao of Jeet Kune Do. Most of the essays were compiled from notes he wrote while recovering from a back injury. Forced away from practice, he wrote instead. Jeet Kune Do translates to “the way of the intercepting fist,” which Lee described as a styleless style: a form that assumes all forms and is bound by none.

What made it styleless was that it drew deliberately from many disciplines: Wing Chun, Western boxing, fencing, wrestling, judo, and savate, rather than committing to any single school. Lee took what worked from each and left the rest, building something that was a precursor to modern mixed martial arts before the category even existed.

The reason for that borrowing was a conviction that rigid, organized styles built on fixed forms can limit the practitioner. Lee called codified tradition “organized despair,” inherited patterns that divide practitioners into camps and stunt their growth. To him, loyalty to a style could quietly become a substitute for thinking.

The philosophy in software design

If you read Lee’s principles again with the lens with our craft in mind, it applies to any practice: martial arts, music, and even software design. Perhaps it’s the generalist and curiosity in me that’s always made the styleless style a concept that resonates with me. I’m less interested in spending time defining what design is and rather focus on what it in practice can result in. Let’s look at key teachings from Jeet Kune Do and reflect on how we can apply it to software design.

Formlessness over fixed form We shape the tools that shape us. This is our biggest tendency; wanting a stack, process, and clear way of doing things. Mastery is critical. Bruce Lee is also the person who said, “I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.” What’s important to hold here is excellence is applying the materials and techniques, not how you memorize using a tool. Whether it’s writing loops or drawing interfaces, do it 10,000 times. What is adaptable is how you approach getting to that outcome.

Absorb what is useful and reject the useless Be deliberate about capturing what is valuable and throwing away what isn’t. As you develop in your craft, you will learn techniques that are absolutely sacred to retain. The craft will continue to be challenged in evolving, especially in moments such as now where there are new technological shifts. Do not fall into the trap of discourse about design being dead or how new roles or rigid. However, take the best of new innovations and apply it to your craft. Taking the best of Design Engineering as a practice doesn’t make you a Design Engineer, but you can also adapt parts of the discipline in your approach to software design; become mixed method.

Take the most economical path The intercepting fist does not wind up. It takes the shortest line to the target. Speed and iteration are differentiators for software designers. The ability to be agile and refine lets you take the most economic path to a result or outcome. This is what Jenny Wen means by, The Design Process is Dead. The debt and excessive of it is abandoned when the ground is shifting, and the shortest path of execution becomes the most economic one.

Study the roots When you study the roots, you understand every blossom that grows from it. For designers, the roots are the foundations that don’t change with the tool. It’s understanding the problem, mastering the material, and high control of technique that results in the desired outcome. A designer grounded in those can pick up any new tool quickly, because the tool is just a branch. A designer who only has branches is fragile the moment the branch they are standing on gets rewritten. Right now, many of them are being rewritten at once.

Applying it

As software primitives are being rewritten, this is a good time to embrace formlessness. That does not mean chasing every trend or treating every new tool as a new identity. It means keeping enough range to notice when a new practice is useful, and enough foundation to know when it is not.

Formlessness is an advantage because we do not know what the end form is for AI. The shortest path lets you learn faster without overcommitting to a shape that may not last. Some trends will be wrong, but it also might be the next default.

Be like water, my friend.

What is product craft in the age of AI and design systems?

Ask a design system team how they’ll raise the quality of the products they support, and you’ll usually hear one of two options. The first is to make better components, perhaps with more opinionated defaults. The second is to tighten up the quality gates: give the DS team the authority to approve quality, not just the aspiration to improve it.

These are both good plans. But they don’t necessarily result in the end products actually getting better.

A design system can only raise the quality floor. It sets the baseline below which nothing should ship. An accessible-by-default button, a holistic and thoughtful approach to spacing, a template that starts a consuming team ten steps ahead.

But a design system alone can’t raise the quality ceiling. That’s not something you can do by delivering assets. The worst product teams can make awful experiences with the best design systems. That’s because the quality ceiling is set by the choices product teams make with what you give them. It’s their restraint, it’s where they push, and it’s knowing when to deviate from the standard because the standard isn’t serving the end user.

It comes down to this incredibly frustrating reality: everyone says they want to build things right until they have to choose between high quality and speed to market. I’ve racked my brain on this one. All of my clients are asking their design system teams to move faster. All of those teams want to slow down because “quality takes time.”

Want to know the secret to delivering higher quality work in shorter timeframes? Craft. But it’s not as simple as it sounds.

First, let’s draw a distinction between craft and quality. Craft is the skill needed to deliver continually higher quality work. We can more easily define quality—you and I could sit in a room and make a list of the things we’d measure and the threshold above which we’d consider them “high quality.” Craft is a bit more ambiguous. Craft comes down to something uniquely human: care. If you care about your work, you’ll improve your craft.

In a recent episode of The Question, we sketched it out like this.

When you look at it this way, it’s clear that design system and product teams each need to take responsibility for their own craft, independently. But for the overall quality of your product to be high, both teams need to come to the table. Craft shows up in how each team thinks, what they notice, and what they’re willing to fight for when the deadline is right on top of them.

How do we use this?

Most system teams, once they’ve accepted that they can’t raise the quality ceiling, draw the wrong conclusion. They step back thinking, “the ceiling is the product team’s job, not ours.” You’ve probably even heard me say that system teams are here to enable, not to police. It’s a more mature posture. But I’m beginning to believe it also leaves us out of the most important conversations.

Raising the ceiling and defining it are two different jobs. It’s the product team’s job to raise the ceiling of quality, but the system team has to be part of the conversation where the ceiling gets defined. Not to constrain it, but to understand it. Co-defining what quality means allows us to build a design system that sets the right high quality floor so that product teams can stretch.

This creates a beautiful loop.

By co-defining what quality is for our context, both system and product teams can shape their work to hit that target. This gives us the most likelihood of identifying things to bake back into the system, raising the quality floor, which allows product teams to raise the quality ceiling. Repeat. (I told you it was beautiful!)

And, of course, this loop just continues to run. Over time, the quality floor and the quality ceiling are raised.

The most important step here isn’t the shipping of a new component. It’s the time in conversation that results in alignment on a definition of quality.

Your system sets the floor. The way your system is used sets the ceiling. If you’ve poured everything into the first and bowed out of the second, it’s time to step back into ring.

Full article content is not available for inline reading.

Read the original article →

My Figma wish-list

1. Something equivalent to <span>
2. Units of measurement beyond pixels. We're getting close with auto layout's "grid" option (Figma's answer to CSS grid), because that gives us fr units. In a pinch we can use these to mimic percentages, though its not the real deal. The following measurement types would really super-charge what we can build:
   • % Percentages
   • ch Character width
   • rem REMs
   • em EMs
   • lh Line height
   • vw, and vh Viewport width and viewport height—these would be really tricky... Figma would maybe have to introduce a new type of frame, or allow us to designate a frame as the "viewport" and not just a div.
3. Ability to apply a variable, perhaps a string variable, to more auto layout attributes.
   • Alignment (eg top-left, center-center, etc)
   • Resizing rules (eg fixed, hug, fill)
   • Layout (eg horizontal, horizontal with wrapping, vertical, grid)
4. Reversing the stacking order in an auto layout frame. I know we can already do this in terms of z-index with "first on top" and "last on top", but I want it for how items wrap when their parent container becomes too narrow.
5. Ability to turn off "auto layout setting guessing." This has gotten better, but at some point in time Figma tried to guess what auto layout configuration I wanted, and often would guess incorrectly. The intention behind this feature was good—save users time by pre-configuring some settings when they apply auto layout to an object. But that's only useful if the program gets the settings right. When it gets it wrong, it creates more work for the user to correct things. Quite annoying!
6. Ability to set default values whenever auto layout is applied to a frame. I'd love for things to always run vertically, be top-left, and use variables from our design system. Or, at the very least, raw 0s. No more raw 10px values for the gap and padding.
7. Descriptions for all types of properties. Not just slots. This will be big for AI-readability, and giving designers more in-context documentation.
8. All assets in the publication panel should be unselected by default.
9. The publication panel should be a full-screen experience.
10. Make publication notes a rich-text field, with the ability to format text with bold, italics, lists, and insert things like headings and hyperlinks.
11. Expose library publication actions as endpoints in their API.
12. Ability to upload markdown files to component and slot descriptions.
13. Ability to attach multiple links to a component, similar to "dev resources" in Dev Mode.
14. Moving variables between collections.
15. Property name inspection and bulk-renaming... "show me every component with a "state" property, no matter the casing... "
16. Applying color variables to the page color fill.
17. Ability to apply the "grid" auto layout type directly to slots.
18. Ability to freely re-order properties as desired, regardless of property type (intermixing variant properties among properties tied to layers, such as string properties).
19. Decoupling "default variant" from its X and Y coordinates in the component set. Instead, let the user elect which variant is the default.
20. Expand the number of scopes for a Library publication, namely, publishing only so certain files can accept the publication. Useful so a design system team can publish, say, a Variables library to get updates into a component library downstream, without releasing the same Variables publication to consumers.

I'd like to shout out Leo Vogel and his website https://bookofgrievances.com/, which is what this blog post was inspired by! Squeaky wheels get the grease. I hope more folks who love and enjoy the software they use on the regular pipe up about their hopes and dreams for features and fixes. If you're feeling inspired, here's some ways you can be a squeaky wheel too:

• Write your own "wish list" on whatever platform you're already comfortable publishing on
• Create a feature suggestion in Figma's community forum
• Prototype your dream feature, publish it in Figma's community and professional social platforms where other designers hang out
• Write Figma's product team a letter. Address it to their current CPO, and send mail to 760 Market St, Floor 10, San Francisco, CA 94102, United States

Interested in more?

If you'd like to be notified of when I publish a new blog post, joining my newsletter is a great way to keep up. My readers enjoy bonus behind-the-scenes insights on every post!

Don Norman never wrote a single line about chatbots. He couldn’t have. The Design of Everyday Things came out in 1988, decades before anyone typed a prompt into a text box. Yet open any thread about bad AI onboarding today, and someone quotes him within minutes. That’s not nostalgia. It’s proof that his framework predicts failures he never saw coming.

I spent the last few weeks testing this claim against real products. I revisited The Design of Everyday Things chapter by chapter, then mapped every principle against interfaces shipping right now: AI agents, voice assistants, and smart home apps. What I found surprised me. The book isn’t a museum piece. It’s a working diagnostic tool, and most design teams still misuse it.

What Makes The Design of Everyday Things Different From Every Other Design Book?

Most design books age fast. Trends shift, tools change, and advice built around specific software becomes useless within a few years. The Design of Everyday Things avoided that trap because it never talks about tools. It talks about cognition.

Norman built his argument on how humans perceive, decide, and act, not on how any particular gadget works. That distinction matters enormously. Interfaces change every quarter. Human perception doesn’t. Consequently, a book about perception outlives a book about pixels.

This is also why The Design of Everyday Things reads differently than typical UX literature. It doesn’t hand you a checklist. It hands you a lens. Once you learn to see through it, you can’t unsee bad design, whether it’s a confusing shower knob or a poorly labeled AI feature toggle.

The Seven Stages of Action, Rebuilt for AI Interfaces

Norman’s most cited model splits every action into seven stages: forming a goal, forming an intention, planning, executing, perceiving the result, interpreting it, and comparing it against the goal. Most designers know this model. Few apply it correctly to conversational AI.

Here’s the problem I’m naming: Intent Collapse. This happens when an AI interface merges multiple stages of Norman’s model into one ambiguous text box, forcing users to guess whether the system understood their goal, their intention, or neither. A blank chat window asks users to plan and execute simultaneously, without confirming their intent first. That’s a design failure, not a user failure. The Design of Everyday Things predicted exactly this kind of collapse back when it warned against interfaces that skip the gulf of evaluation.

Why This Matters for Product Teams

Teams building AI features often measure success by task completion. However, Norman’s model suggests measuring something earlier: did the user even form a correct intention? If they didn’t, completion rates hide failure instead of revealing it.

Affordance Debt: A New Term for an Old Problem

I want to introduce a framework here, because existing vocabulary doesn’t fully capture what’s happening in software today. Call it Affordance Debt. It describes the gap between what a digital element visually promises and what it actually does, a gap that accumulates silently as products scale.

A button that looks clickable but isn’t. A toggle that seems binary but hides three states. A chat icon that implies a human but delivers a script. Each instance seems minor. Together, they create Affordance Debt, and users pay interest on it every time they hesitate before clicking.

The Design of Everyday Things never used this exact term, since Norman was writing about doors and stoves. Still, his core insight applies perfectly: affordances must be perceivable, not just theoretically present. A feature that exists in code but not in the interface’s visual language doesn’t count as usable.

Why Norman Doors Still Explain Bad AI Onboarding

Everyone knows the term by now. A “Norman door” is any door so poorly designed that users push when they should pull. The Design of Everyday Things turned this into shorthand for design failure in general, and the metaphor traveled far beyond doors.

I found the digital equivalent everywhere during my research. Onboarding flows that show a signup button before explaining the product. Settings menus that hide the one toggle users actually need. These are Norman doors wearing a software skin.

Signifier Drift

Here’s a second framework worth naming: Signifier Drift. This describes how a signifier that once communicated clearly loses meaning as an interface evolves through updates. A hamburger icon meant “menu” a decade ago. Today, depending on the app, it might mean settings, filters, or nothing at all. Signifiers drift because teams add features faster than they update the signals users rely on. The Design of Everyday Things treats signifiers as sacred contracts between designer and user. Break that contract repeatedly, and trust erodes.

The Discoverability Gap in Voice and Agentic Interfaces

Discoverability was one of Norman’s central obsessions. Can a user figure out what actions are possible without being told? Visual interfaces struggle with this. Voice interfaces and AI agents struggle far more.

Think about it. A screen at least shows you buttons. A voice assistant shows you nothing. You’re expected to guess its full capability from memory or trial and error. I call this the Discoverability Gap, and it’s widening as more products move toward voice-first and agent-first design.

The Design of Everyday Things offers a clear solution here, even though it predates voice AI entirely: constraints. Well-placed constraints narrow the field of possible actions, making systems easier to understand. Voice products that succeed today, rather than frustrate users, tend to lean heavily on spoken constraints, like suggested prompts or guided menus, instead of open-ended silence.

Feedback Latency Tax: Why Waiting Feels Worse With AI

Norman’s feedback principle sounds simple. Every action needs a visible, immediate response. Yet AI products routinely violate it, and I want to name why this specific violation stings more than older ones.

I’m calling it the Feedback Latency Tax. When a system takes several seconds to respond and gives zero indication that it’s working, users don’t just feel impatience. They feel doubt. Did it register the input? Did it crash? The Design of Everyday Things explains this precisely: without feedback, users lose their mental model of the system’s state entirely.

Interestingly, a simple loading animation reduces this tax dramatically, even when actual processing time stays identical. Perceived speed depends on feedback, not raw performance. That’s a lesson many AI teams still haven’t internalized.

Human-Centered Design Versus Machine-Centered Design

Something has shifted since Norman first published The Design of Everyday Things. A growing number of products now optimize for how machines parse content rather than how humans experience it. Search engines, recommendation algorithms, and increasingly, AI models themselves have become an audience that designers quietly serve.

I think this deserves a name too: machine-centered design, positioned directly opposite Norman’s human-centered philosophy. It isn’t inherently wrong to consider algorithmic readers. But when machine legibility overrides human clarity, we’ve inverted the entire point of the original book.

The Design of Everyday Things argued that designers hold moral responsibility toward the humans using their products. That responsibility doesn’t disappear just because an algorithm now sits between the designer and the user. If anything, it grows heavier.

A Structured Comparison: 1988 Principles Meet 2026 Interfaces

What The Design of Everyday Things Predicts About the Next Decade

I’ll commit to a few forward-looking claims here, because a good framework should let you predict, not just explain the past.

First, Affordance Debt will grow faster in agentic software than it ever did in traditional apps, since agents introduce new capabilities weekly without corresponding visual updates. Second, products that solve the Discoverability Gap through guided constraints will outperform fully open-ended competitors on retention, not just satisfaction scores. Third, teams that measure Intent Collapse directly, rather than relying on completion metrics alone, will catch usability failures months before churn data reveals them.

None of these predictions require new theory. They fall directly out of applying The Design of Everyday Things to systems Norman never personally tested. That’s the mark of a genuinely durable framework: it keeps generating correct predictions long after its original context expired.

My Honest Take After Rereading It in 2026

I’ll be direct. Parts of The Design of Everyday Things feel dated on the surface. The examples involve rotary phones and analog stoves. But the underlying mechanics never expired, and that’s exactly why I keep returning to it.

What strikes me most is how quietly radical the core argument remains. Norman insists that confusion is never the user’s fault. Nearly forty years later, product teams still default to blaming users first. The Design of Everyday Things remains one of the few books willing to say, plainly, that the fault sits with the designer.

Structured Summary Table: Should You Still Read This Book?

Frequently Asked Questions About The Design of Everyday Things

Is The Design of Everyday Things still relevant in 2026?

Yes. The Design of Everyday Things focuses on human cognition rather than specific technology, so its principles apply directly to AI interfaces, voice assistants, and agentic software.

Which edition of The Design of Everyday Things should I buy?

Choose the Revised and Expanded Edition from Basic Books, published in November 2013. It updates the original 1988 examples while keeping the core framework intact.

What are affordances and signifiers in The Design of Everyday Things?

An affordance is what an object allows you to do. A signifier is the visual cue that communicates that affordance to the user. Norman argues both must align clearly, or confusion follows.

Does The Design of Everyday Things mention artificial intelligence?

No, since it predates modern AI by decades. However, its principles about feedback, constraints, and discoverability translate directly to today’s AI-driven products.

Who should read The Design of Everyday Things?

Anyone who designs, builds, or manages digital products benefits from it, including PMs, founders, engineers, and researchers, not designers alone.

In 2026, the kit you use to do your creative job has probably never been more important. Whether you're a photographer editing 45MP raw files, a film-maker scrubbing through 4K footage or a graphic designer running several Creative Cloud apps at once, it all depends on one unglamorous, typically unseen, but essential component: RAM, which stands for Random Access Memory.

Unfortunately that component – often referred to simply as 'memory' – is at the centre of a global supply squeeze that's pushing up the price of laptops, phones, tablets, gaming consoles… basically anything with a computer chip in.

Worse still, this is not just a temporary blip, but a problem that may last till the end of the decade. Read on, and I'll explain what's happening, in words you don't have to be technical to understand.

A price shock no-one can avoid

Usually the nitty-gritty of what goes on in global computer manufacturing isn't something that most of us need to care about. But right now, it's hitting us squarely in the pocket.

Apple, Microsoft, Dell, Samsung and others have all raised prices in the last few months, some by hundreds of pounds, without changing a single thing about the devices themselves. In fact, sometimes they're even bringing out lower-powered devices at a higher cost.

As a 56-year-old man who's been buying computers since the earliest home devices hit the shops in the early 1980s, that feels little short of historic. Because ever since those heady days, society has become accustomed to computers getting both faster and cheaper, year on year. Yet that's now going into reverse, for the first time in modern memory.

What is RAM?

Before I explore why, let's start at first principles: what exactly is RAM, and what's for?

Importantly, RAM is not the same as storage. Storage (on an internal or external hard drive) is the memory where your files live long-term. RAM, in contrast, is the memory your computer clears to actually work on something in the moment.

That might be the photo you're retouching, the video timeline you're scrubbing through, the dozen browser tabs and Creative Cloud apps you've got open at once. The bigger the RAM, the more you can work something on smoothly, without everything grinding to a halt.

Every laptop, phone and tablet has RAM built in, and it's one of the most expensive parts to make. Unfortunately, it's now in desperately short supply.

Why is RAM scarce?

So why is it in short supply? In a word: AI.

The huge data centres being built to run AI services like ChatGPT, Gemini and Claude need enormous amounts of RAM to function. And the handful of companies that make RAM – such as Samsung, SK Hynix and Micron – have found it far more profitable to sell to the AI giants than to laptop, tablet and phone makers.

Some companies have even gone further, and shifted their factories to produce a specialised, higher-value type of memory built specifically for AI servers, which further eats into the supply of ordinary memory chips used in laptops and phones. Indeed, Micron has stopped selling directly to consumers at all, closing down a well-known upgrade brand to focus entirely on its new AI customers.

How much are prices rising?

RAM prices aren't going up a little. They're going up a lot. Analysts are forecasting memory price rises of around 40 to 50% in the third quarter of 2026 alone, with further increases expected into next year. Some laptop makers say memory now makes up more than a third of what it costs to build a PC, roughly double the share it was a year ago.

Consumers are already seeing the knock-on effects. Apple's raised MacBook and iPad prices by between $100 and $500 in recent months. Microsoft has done similarly with its Surface and Xbox ranges, and even discontinued its highest-memory Xbox configuration.

Sony has raised the price of the PlayStation 5 and may delay its successor. Similarly, budget phone makers have cancelled or scaled back planned models – because they can't build them at a price anyone would pay.

What's new this time?

Of course, tech has often had supply issues and price shocks before – most recently during the pandemic years. But again, I stress: this time it's different.

Almost the entire history of consumer computing has been built on components getting more powerful and cheaper, year after year, generation after generation. While this progress upwards might have occasionally have been bumpy rather than straight, the basic pattern continued. Now, though, it's reversed, and analysts don't expect a quick fix.

Building a new memory factory takes two to three years and billions of dollars. And most of the new capacity being built now won't ship in meaningful volumes until 2027 or 2028 at the earliest. Some industry figures think prices won't properly settle until 2030.

Even when supply does catch up, several analysts doubt prices will fall all the way back to where they started. Because once buyers get used to paying more, there's little commercial pressure on manufacturers to bring costs back down.

What it means for creatives

So what does this mean for working creatives? Well, in short, it means the party's over. If you're used to upgrading your laptop, phone, tablet or gaming console every couple of years, and getting something much more powerful, at a similar or lower price, then… well, I'm sorry. That's no longer going to happen.

Expect higher-memory laptops and desktops – the kind serious photo and video work needs – to see the steepest rises. Expect entry-level and budget devices to shrink in number or drop back to lower memory specifications, as manufacturers try to hold their prices down by giving you less. And once you've bought a device, if its memory is soldered in rather than upgradeable (increasingly common on slim laptops and all phones and tablets), you'll be stuck with whatever you chose on day one.

If none of that means much to you, then let me put it in simpler terms. You know how, thanks to rampant food inflation around the world, that chocolate bar you used to love is now smaller, much more expensive and contains less actual chocolate (aka 'shrinkflation')? Well that, but for tech.

So how should creatives respond? In the second article in this series, I'll walk through practical, sensible strategies for getting the kit you need without paying over the odds, from buying refurbished to being honest with yourself about what each job actually requires.

Today, Meta is rolling out Muse Image, the company’s first image generation model from Meta Superintelligence Labs, now available in Meta AI. Muse Spark made Meta AI a smarter assistant; now, Muse Image acts as the creative partner that knows your world, making it easy to turn your ideas into high-quality visuals that you can download and share anywhere, including directly to your feed, story, or chat.

The model also powers new creative tools across Meta’s apps. You can use more than 30 new AI-powered effects for Instagram Stories and generate images in your direct chats with Meta AI on WhatsApp — starting in limited countries with more locations on the way.

Simple Prompts, High-Quality Outputs

Whether you’re starting from scratch or working with an existing photo, you can describe what you want in simple, conversational language, and Meta AI handles the rest thanks to Muse Image. Ask it to mock up an image of you in front of a historical landmark, cleanly erase a photobomber from the background of a shot, or write a custom prompt to build a functional QR code. It will also render text cleanly inside your visuals, meaning you can ask for a how-to guide or a detailed infographic on a specific subject, and the text comes out legible and styled to match.

Suggested Presets to Help You Get Started

Sometimes the hardest part of creating is getting started. Meta AI now includes a presets panel with suggested prompts to help inspire you. One tap restores an old family photo, lets you see yourself with trending hairstyles, or reimagines you as a claymation character or a 16-bit video game hero. Whatever you create, it’s easy to share with friends across Meta’s apps so they can try the same preset on their own photos.

Shop Your Room Redesigns

You can also snap a photo of your room and ask Meta AI to redesign it with real products from the web or Facebook Marketplace. Suggest a style you love or ask Meta AI to pull from what’s trending to see what your space looks like with a full makeover.

An Intelligent Creative Partner

Muse Image doesn't just build an image; it thinks through your prompt first. By pairing up with Muse Spark, the model takes multiple steps behind the scenes — planning its layout, looking up real-time web context, and intelligently blending multiple visual references at once. Whether you want to place your pet in a famous painting or combine a selfie with a vacation photo to create a custom postcard, Meta AI handles the complex reasoning for you so the final visual matches your vision perfectly.

Rooted in Your World

You can also @-mention Instagram accounts in the Meta AI app to bring specific Instagram profiles right into your images. Whether you want to design a custom event invitation, mock up a collaborative creative concept, or generate a personalized graphic, tagging a username lets Meta AI use public photos to build a visual that’s ready to post. You have control over how your content can be tagged for AI creation with an easy setting to turn this feature off at any time.

Edit Directly on the Photo

To make a change, just tap the markup icon on your creation to circle, sketch, or annotate edits right on top of the photo. Since Meta AI remembers the full context of your conversation, you can keep refining by swapping styles, adding elements, or tweaking details — all without starting from scratch.

What’s Next

Soon, Meta will bring Muse Image to more countries and the places where people use Meta AI, including Facebook and Messenger, and additional surfaces on Instagram and WhatsApp. In the coming weeks, advertisers and agencies will be able to tap into Muse Image through Advantage+ creative.

Using Meta AI with Muse Image is free for everyday creation. For people who want to create even more, it’s available as part of Meta’s subscription plans.

Images are just the beginning. With Muse Video already in development, Meta is building entirely new ways for you to bring your ideas to life, getting one step closer to personal superintelligence.

Microsoft’s Real AI Strategy Is Not the Chatbot

The real story is that Microsoft is trying to vertically integrate the enterprise AI chain. It wants to control more of the path between the customer, the software, the workflow, the cloud, the model.

Building a Moat: Self Learning Agents

Self-improvement is the new moat, allowing product companies to go beyond wrapping LLM APIs. There are two places to harvest this learning: browser activity (what users actually do in applications)...

The Information: SpaceX and Cursor are set to release their first jointly developed AI model as soon as Wednesday.

“It is expected to be competitive with Anthropic’s Opus 4.8 and OpenAI’s GPT-5.5 in some respects.”

SK hynix 3Q25 Earnings Call – Key Q&A

1. Details on the completion of 2026 HBM supply negotiations

This year, numerous external variables made it difficult to finalize not only supply volumes but also product mix. As customer performance requirements evolved, it took longer than initially expected.

However, discussions with customers have now been concluded, and supply contracts for next year’s HBM have been finalized. Since 2023, demand for AI infrastructure and the company’s strong product competitiveness have kept HBM fully sold out. Prices are currently set at a level that allows profitability to be maintained.

Given the rapid expansion of HBM demand driven by the AI market, it will be difficult for supply to catch up with demand in the near term. Growth is expected to outpace general DRAM. Even in 2027, supply is projected to remain tight relative to demand. The company will ensure timely delivery of products tailored to customer needs.

2. On customer requests for higher HBM4 specifications

As the AI inference market expands, memory bandwidth has become increasingly important. Since the number of I/O channels in HBM4 has been set to double that of the previous generation, customer requirements have shifted toward higher-speed performance.

With the industry’s leading HBM technology, the company is meeting these enhanced specifications. It was among the fastest in the industry to deliver samples reflecting customers’ upgraded requirements and is now prepared for mass production.

As competition intensifies among AI chipmakers, memory performance has become the key bottleneck in technological progress. Performance requirements for next-generation memory, including HBM, will continue to rise. SK hynix plans to deliver next-generation HBM products in a timely manner that meet customer expectations.

3. Achieving over KRW 10 trillion in quarterly results—how is this memory cycle different from past booms?

Contrary to earlier expectations, memory demand has surged this year, pushing the market into a super-boom. We believe the current cycle differs from the 2017/2018 cycle.

The key difference is that today’s demand is tied to a paradigm shift toward AI and is connecting to a wide range of applications. AI is creating demand by being layered onto existing use cases, and over the medium to long term it is driving fundamental change by cultivating new applications such as autonomous driving and robotics.

Notably, as AI computing expands into inference, it is also stimulating demand for general servers. We expect server system shipments next year to grow in the high-teens percent. Server-bound demand will continue to lead overall DRAM demand.

On the supply side, even as HBM production expands and more cleanroom space is secured, total output growth is inherently limited. These characteristics structurally constrain DRAM industry supply growth, which underpins our view that the super-cycle will be prolonged.

4. Basis for seeing structural strength in eSSD demand

Background to rising NAND demand: With server customers ramping AI investments, build-outs for both AI servers and general servers are increasing. Demand for TLC products is rising. As AI-generated data such as images and videos surges, storage needs are climbing, creating HDD supply shortages. Hyperscalers are increasingly shifting to high-capacity QLC eSSDs. We view today’s demand changes as going beyond short-term supply-demand issues and driving a structural uptrend in eSSD demand.

To overcome the limits of the traditional LLM approach, the importance of RAG (Retrieval-Augmented Generation) is growing. Instead of relying solely on trained data, RAG retrieves documents related to a query from external data before generating the final answer, enabling higher accuracy by incorporating the latest and user-specific data. Implementing RAG requires building external database vector stores, and eSSDs are essential for fast retrieval. We therefore expect storage demand to rise on the back of high-performance TLC and high-capacity QLC eSSDs.

In addition, as data throughput needs during inference surge, there is a growing need to offload data previously handled on the GPU to memory/storage for more efficient AI operations. By offloading the GPU’s KV cache down to SSDs, it’s possible to improve throughput per watt and reduce user response latency. We thus expect storage demand to increase, centered on high-performance TLC and high-capacity QLC eSSDs. As AI use cases proliferate, eSSD demand is rising, and memory demand is broadening from DRAM into NAND.

5. Company’s stance on the shift toward a “specialty market” characterized by pre-orders and post-sales

Certain business segments, including HBM, have transitioned to a pre-order and post-sales model. Due to strong customer demand, we have been securing visibility and responding to customer needs through long-term annual contracts established from the initial agreement stage.

As a result, unlike in the past when the memory industry and our business showed high volatility, predictability has increased, and business stability has also expanded. Starting with HBM4E, custom HBM products are being developed jointly with customers from the early design stages of their GPUs or ASICs. Such long-term and strategic partnerships with specific customers are expected to have a positive impact on the stability and profitability of our memory business.

As memory suppliers prioritize capacity allocation for HBM expansion, constraints are emerging in general memory production. This has led to a shortage in general memory supply amid rising demand. Accordingly, more customers are seeking long-term supply agreements for general memory as well. Some customers are even issuing pre-purchase POs for 2026 to hedge against potential supply shortages.

Given the strength of customer demand and our current capacity, not only HBM but also DRAM and NAND capacities for next year are effectively sold out. We will continue to respond to customer demand with optimal production and sales strategies, and we will keep discussing with customers how HBM-driven market changes will affect general memory.

6. Outlook for 2026 CapEx

With growing confidence in the expansion and monetization of the AI market, global AI companies are competitively investing, driving rapid demand growth across various memory products such as HBM, DDR5, and eSSD. To meet this demand, an increase in memory CapEx is inevitable. Our CapEx next year will rise significantly compared to this year.

Equipment move-in at M15X has begun in earnest, and the facility will be utilized to expand HBM supply. For general DRAM and NAND, we plan to accelerate migration to advanced process nodes to address demand. Additionally, considering the construction of the first phase of the Yongin fab and preparations for the Indiana plant, infrastructure investment will continue to increase.

Even with expanding investment, we will maintain strict CapEx discipline and aim to preserve a stable financial structure.

Citi: The Semiconductor Cycle Still Has Significant Upside Potential

Citi analyst Christopher Danely expects global semiconductor sales to rise 16% in 2025 to reach an all-time high of $731 billion. However, he emphasized that this revenue growth is entirely driven by pricing, while shipment volumes remain well below previous peaks. This indicates that inventory levels are low and the industry still has substantial room for further growth.

According to Citi’s data, the current semiconductor industry’s revenue growth has been primarily driven by the surge in logic chip prices. Citi noted that the average selling price (ASP) of logic computing chips (including AI accelerators) has risen 24% over the past three years, far exceeding the 2% growth rate of the previous decade. The share of logic computing chips in total semiconductor sales has also climbed from 27% in 2020 to 39% in 2025.

Within this segment, logic computing revenue is expanding rapidly at a compound annual growth rate (CAGR) of 53%, rising from about $29.6 billion in 2022 to approximately $106.4 billion in 2025, with its share of total semiconductor sales jumping from 5% to 15%.

The average selling price of logic computing chips is expected to soar from $7.80–$8.50 during 2018–2022 to $26.40 in 2025, representing a 47% compound annual growth rate.

Citi identified NVIDIA’s rapid data center expansion as the key driver behind this transformation. The company’s data center business share of logic chip sales has surged from less than 10% in 2021 to 66% in 2025, while its share of total semiconductor sales has also increased from less than 3% in 2021 to 24% in 2025.

A Semiconductor Genius Who Rejected America’s Courtship, Produces “Terrifying Disciples” in China

Sun Nan (孫楠), a professor at the University of Texas at Austin. Nicknamed a “semiconductor genius,” he is one of the top talents in the field. After graduating from Tsinghua University in China, he went to the U.S. to study abroad and earned his Ph.D. at Harvard. In 2020, at the age of 34, Professor Sun faced two choices: stay in the U.S. or return to China.

If he chose the latter, the opportunity cost was immense. His position at the University of Texas came with an average annual salary of $150,000 and tenure. The other option was his alma mater, Tsinghua University, which offered a competitive salary and research support.

In 2020, Sun rejected America’s temptations and returned to China. He was a prolific researcher in the field of integrated circuit chip design, having been the most prolific author in the world’s top semiconductor design journal, JSSC, between 2014 and 2024.

In an interview with Tsinghua’s campus newspaper, he explained his motivation: “I went to the United States to learn advanced semiconductor technology. I achieved a lot there, but I believed that as far as my abilities reached, it was only right to contribute to China. That is what a Tsinghua graduate should do.”

He added: “China manufactures and exports smartphones, home appliances, and other products. It is the world’s largest exporter. But to actually make those products, China also has to import more semiconductors than any other country. That was something I found regrettable.”

Morgan Stanley HBM Report

• According to channel checks, the contract negotiations between SK Hynix and NVIDIA for HBM3E 12-hi remain in the price range of around $440 per die ($1.69 per Gb). However, the negotiations are still ongoing and have not yet been finalized.
• HBM4 has been priced at $590–600 per die ($2.30–2.34 per Gb), but it is deemed unlikely that this pricing will be part of a full-year fixed contract.
• SK Hynix’s share of NVIDIA’s business is expected to decline from 85–90% in 2025 to just over 50% in 2026, driven by intensified competition from Samsung and Micron.

The HBM That Jensen Huang Called a Miracle Made with Samsung: What Happened Over the Past 9 Years?

In August 2016, a senior engineer from Micron harshly criticized HBM, which had been on the market for just one year, calling it a “cheap knockoff” of the Hybrid Memory Cube (HMC). At that time, SK Hynix’s HBM2 was struggling, and the company was in a difficult financial position.

Today, HBM is hailed as the “prince of memory” in the AI era. The current market shares are approximately 55% for SK Hynix, 40% for Samsung, and 5% for Micron.

HBM was born to solve the “memory wall,” a bottleneck caused by the performance gap between CPUs and memory. Its development is tied to the evolution of the GPU, specifically through early partnerships between AMD and SK Hynix starting in 2010, long before the AI boom made HBM a critical component.

How China Took Over the LiDAR Industry: The Comeback of a "Fool's Tech"

LiDAR (Light Detection and Ranging) is a sensor that emits laser beams to detect surroundings in 3D, serving as a critical component in autonomous driving and consumer electronics. While Tesla famously rejected LiDAR, China has quietly taken a dominant position in the industry.

The industry faced a massive downturn after 2020 when Level 3 autonomous driving failed to materialize as quickly as expected, leading to bankruptcies and mergers for many startups like Velodyne, Quanergy, and Ibeo. Despite the collapse of valuations for companies like Luminar and Innoviz, the technology has remained essential for robotic and vehicle applications, with Chinese firms capitalizing on mass production capabilities while many U.S. and European players struggled to survive.

Xbox announced on Monday that it would lay off 3,200 employees and let go of five game studios. The company is aiming to reset itself after overspending on studios, staff, and games that people didn't want to play. Xbox plans to take a more streamlined approach to games and studios going forward. It will focus more on franchises like Minecraft, which is considered one of the most successful video games in the world.

Remember when AI was going to take away our jobs and leave humans with nothing to do? So far, that doesn’t seem to be happening. Researchers from ActivTrak analyzed the digital activity of more than 10,000 workers and found that when people adopted AI, their work life became more intense, not less. The time that these early adopters spent on email, messaging, and chat apps more than doubled. Their use of business software rose by 94 percent.

Researchers from UC Berkeley’s Haas School of Business found that when using AI, workers started taking on tasks that they had previously outsourced, because activities such as coding and engineering became easier to do. They squeezed in work bursts in the evening, on weekends, in waiting rooms, and whenever else they had a spare moment and AI was handy. They also did a lot more multitasking, supervising a bunch of bots doing different things simultaneously.

The general pattern that the research points to is that many people don’t use the time they save using AI to do less; they use the time to take on new tasks. AI also seems to shift workers’ expectations, and their boss’s expectations, about how much they should accomplish in a day. Every hour feels more crowded, but also more frazzled. The ActivTrak researchers found that the time people spent on focused, uninterrupted work fell by 9 percent. There’s even a name for this mental state: “AI brain fry.”

In some sense this is normal. Every time some new labor-saving technology is introduced, there are experts (the ones who know a lot about technology but not much about psychology) who predict that people will use the technology to make life easier. Instead, many people use the technology to make their life more frenetic and full. Planes, trains, and automobiles are technologies that save time and effort by making travel faster. They also enable people to take a lot more trips.

I’d say that a guiding principle of the emerging AI age is this: When intelligence is plentiful, volition is valuable. The people who are going to make a difference are not the ones who seek relaxation and passively use AI to work less. They are the ones who will seek improvement and actively wrestle with AI to develop their own mental capabilities and accomplish more.

In other words, what will differentiate people is not how smart they are but their relationship to mental effort. Right now, some people have what psychologists call a high need for cognition. They enjoy thinking hard. These are the people who enjoy playing difficult games and reading dense books. On the other end of the spectrum, there are the cognitive misers, the people who find it unpleasant to think hard and take any opportunity not to do it. In the middle are the people who have a medium need for cognition. They will put in the effort when they really care about something, but they don’t intrinsically enjoy it. Need for cognition correlates with intelligence but is not the same thing. We all know a lot of really smart people who don’t like to work hard.

As things stand today, people will have very different experiences with AI.

The Productive Passengers

People with a low need for cognition will tend to use AI to think less. Their great gain is that AI will make them more productive because it makes tasks so easy. Their great loss will be that AI will diminish their mental capacities because it makes tasks so easy.

God seems to have been a puritan. He created us to be the kind of creatures who don’t experience gain without some pain, don’t gain reward without some effort. That’s as true in the world of knowledge work as it is in the world of bodybuilding. Humans learn best when they are in the zone of optimal difficulty, when engaged in tasks that are not so hard as to be overwhelming but not so easy as to require no work.

AI is going to push low-effort people out of the zone of optimal difficulty. One research team led by Nataliya Kosmyna from the MIT Media Lab found that people’s brain connectivity declines by as much as 55 percent when they are using ChatGPT compared with when they are not using it to perform similar tasks. Vivienne Ming, a co-founder of Possibility Sciences, found that when people were using AI, their gamma-wave activity—a sign of cognitive effort—dropped by roughly 40 percent.

This has predictable effects on how much people remember from their AI-assisted work. It has equally predictable effects on their thinking skills. A study by Michael Gerlich from SBS Swiss Business School found “a significant negative correlation between frequent AI tool usage and critical thinking abilities.” At first, AI sucks you in. You really do become more productive when using it. But then it threatens to hollow you out, as you become less capable and less knowledgeable. The saddest cases are people who get used to the AI crutch for a bit and then have it taken away. Researchers led by Grace Liu of Carnegie Mellon University put subjects through that experience and concluded, “After just ~10 minutes of AI-assisted problem solving, people who lost access to the AI performed worse and gave up more frequently than those who never used it.”

A study of physicians who specialize in endoscopy—using flexible probes to examine the inside of the body—found that before they started using AI they located precancerous intestinal lesions in 28.4 percent of colonoscopies. After they started using AI, and then had it taken away, they located lesions in only 22.4 percent of colonoscopies. Their detection skills had seriously declined.

Recently, I found myself driving across an infinity of freeways near Anaheim, California, with GPS leading me through a series of highway exits and entrances. I had the thought we’ve all had: I used to do this using maps! I’m as capable of doing that now as I am of walking across the Pacific Ocean. GPS merely shrivels some navigation skills; AI threatens to shrivel everything within those who let it.

The Reluctant Optimizers

People with a medium need for cognition will understand that AI might hollow them out. That prospect will really bother them. They will resolve, earnestly and with good intentions, to not let themselves fall victim. But in the crowded and stressful rush of everyday life, they will get sucked in. Their resolve will fail and they’ll become overreliant on the bots.

AI is a seductive technology. The MIT Media Lab researchers found that when they asked people to use ChatGPT to write a succession of papers, they relied more and more on AI with each one. Before long, they were mostly cutting and pasting. That’s not just because users got more fatigued as they worked. The technology subtly moved them from one mindset to another. Old-fashioned education institutions are built around a cultivation mentality: You work hard and suffer through some hard tasks, and you become a better thinker and a more knowledgeable person. Modern technology, by contrast, is built around an optimization mentality: You find a machine that makes everything easier, so that you accomplish things as efficiently as possible.

The whole tech industry is organized around optimization. In a 2013 interview with The Guardian, for example, Amit Singhal, Google’s head of search, declared, “We are maniacally focusing on the user to reduce every possible friction point between them, their thoughts, and the information they want to find.” People with a cultivation mindset seek friction; people with an optimization mindset want their life to be frictionless. Modern technology wants to turn you from a mental muscle builder into a mental couch potato.

If you’re going for optimization, you’re looking to maximize output, not excellence. In a survey conducted for the software firm GoTo, 43 percent of workers said they had submitted AI-generated content even though they suspected that it contained errors and was generally of low quality.

Pretty soon, people in this optimizer group are going to suffer from the same sort of hollowing-out process as the low-cognition folks. Curiosity will gradually decline. The MIT developmental psychologist Laura Schulz has found that if a teacher offers instruction on how to use an object, she is unintentionally limiting children’s curiosity about it. But if she deliberately restrains from offering instructions, they become more curious. AI is like the instruction-offering teacher.

General engagement with life will gradually decline. A research team led by Suqing Wu of Zhejiang University and Yukun Liu of ShanghaiTech found that when they let people use AI and then asked them to do another task unaided by AI, the participants’ intrinsic motivation levels dropped by an average of 11 percent, and their sense of boredom increased by 20 percent. Engaging with AI made the first task seem more enjoyable, rendering ordinary work dull by comparison.

People in this group will also become less and less able to stand up to the bot. The technology is asking you to be a competent conversation partner with a highly intelligent but imperfect entity. But what if you’ve never done the work to form your own worldview or build your own knowledge base? You’re going to engage in what the experts call “cognitive surrender.” You’re going to believe everything the bot tells you, head off in whatever direction the bot suggests. Researchers at the University of Pennsylvania’s Wharton School programmed an AI to occasionally give wrong answers. The humans accepted its errors as true 80 percent of the time.

The core problem with optimization is that it will change people’s attitude toward effort itself. Chris Sibben is the head of school at Rivendell, a small private school in Northern Virginia. One day, he showed his students a film that took more than 200 artists more than five years to make. The students were baffled. Why do that? As one student put it, “AI could have done it in five minutes.”

Sibben discerned a stark cultural shift in that observation, which, in an essay for Mere Orthodoxy, he calls “the industrialization of detachment.” He argues that a student who has “wrestled with a hard text, revised an argument under pressure, and failed and tried again is more than informed. He is more solid.” As our friend Kierkegaard would have said, it is only by making passionate commitments that a person builds herself into a self.

What happens if she has never put in that work and has never become a self? Sibben argues that the comment “AI could have done it in five minutes” is not really about speed. “It is a moral revaluation. It assumes that what matters is the output, not the ordeal; the image, not the seeing; the product, not the person becoming capable of making it.” AI “offers competence without apprenticeship. Fluency without understanding,” he concludes. “A student who internalizes that pattern does not become lazier; he becomes less formed, less present, less able to bear the weight of difficulty without reaching for a prompt.”

The Mental Marathoners

Now we get to the high-need-for-cognition people and how they will fare in the coming age: kind of like marathoners, I suspect. The automobile is a perfectly good technology for traveling 26.2 miles. There is no practical reason that any person should train themselves to run that distance. But some people do. They want to put in the effort because they want to accomplish things—they want to expand their capacities.

High-need-for-cognition people are like this when it comes to thinking. You’re probably among them if you enjoy the following kind of situation: You’ve been working on a project for a while. You have no idea how you’re going to complete it. The deadline is looming and the anxiety is high. Yet you have utter confidence that you are going to figure this out. Intellectually, you know you have failed in the past and you may in fact fail this time. But simultaneously, you know deep in your bones that you will figure it out. You search and brainstorm and then, as if by magic, one day the answer pops into your mind, and at this point, the learning curve turns exponential. Some people hate the stress stirred up by that situation, but it’s what mental marathoners live for.

A team of scholars led by John Cacioppo of the University of Chicago reviewed more than 100 studies on people with a high need for cognition. They tend to have a lot of task-related thoughts. They engage in stimulating conversations. They tend to have a high need for closure and control. Once they arrive at a conclusion, it can be very hard to push them off of it, even as counterevidence builds.

In the age of AI, I suspect that the mental marathoners are going to work really hard to resist AI entropy. They are going to feel a strong desire to be original. In this age, cultural output will feel ever more familiar, as writing, songs, and movies become syntheses of what has already been produced. Marathoners are going to want to produce work, by contrast, that feels personal, that reflects their unique self. They’re going to want to find ways to use AI to increase their agency, rather than diminish it. Already, techniques have been discovered to help people do that:

• Ask for hints, not answers: People who ask AI to directly answer their questions suffer severe declines in motivation and ability. But people who ask AI for background thinking or clarifications do not.
• Start with a blank page: Before you go to the bot, start with a blank piece of paper and write up your own analysis and conclusions. Then ask AI to challenge your thinking, not produce it.
• Rotate tasks: Every time you do a task with AI, follow it with a task that doesn’t involve AI. That will keep your creative-effort muscles alive.
• Redesign the bots: General chatbot use undermines learning. But as the writer Alberto Romero notes, AI tutors actually improve learning and motivation. That’s because although chatbots mostly answer questions, tutors lead students on structured learning journeys. It should be possible to redesign the normal bots so that they function less like encyclopedias and more like personal trainers whose jobs are designed to build mental muscles, rather than replace them.
• Make a sharp distinction between rote work and creative work: Let AI write functional emails. Don’t let it write your essays or your memos. Shame people who do.
• Ask for thinkers, not thinking: My favorite trick when using Claude is to never ask it to think through a problem for me. I ask it to summarize the thinkers who have already addressed a given problem. If I’m trying to understand child development, I ask it to imagine a debate between Jean Piaget and Erik Erikson. What would these two great psychologists say to each other about the problem I’m wrestling with? Then I ask it what books by these thinkers I should read if I want to understand their work. I get much better results from AI when I treat it as a brilliant librarian rather than as an oracle.

You may have noticed that the future I’m describing here is one of extreme cognitive polarization. Some people will use AI to think more. Other people, maybe most people, will use AI to think less. If you thought that economic inequality or political polarization were bad, cognitive polarization will be truly terrible, dividing society into what might begin to look like two different species. The high-need-for-cognition people will get more and more productive, happier and happier; the rest will fall into a kind of mental underclass.

This future is not inevitable. So far, I’ve been treating the need for cognition as some sort of ingrained trait. But although willpower has some hereditary basis, it is also extremely sensitive to context. If AI has a tendency to undermine volition, humans can reform institutions to help build it up.

Right now, our education system is built around content and intelligence. In elementary school, it downloads content onto student brains. Then it uses high school to pick out smart people and segregate them off into elite colleges. In the age of AI, schools will have to shift their orientation to focus on volition. When we are surrounded by machines that know a lot about a lot of subjects, what really distinguishes people is their desire to work hard and put knowledge to creative effect. What really matters, therefore, is not brainpower but the willingness to run the mental marathons that produce high-quality results.

The crucial task before us is to cultivate people’s desire to seek out cognitive complexity. Not to go all Joseph Campbell on you, but the essential challenge is: How do we train people to see their life as a hero’s journey in which they take on difficult missions that they may fail at and that will certainly involve pain and suffering? How do we form people so they have an explorer’s heart, a willingness to endure, an ability to struggle on, even when their body and mind are telling them to give up, to reach new destinations and figure stuff out?

It seems to me that in the age of AI, every school and organization is going to have to find its own answers to these questions. They are going to spend a lot more time asking their charges: “What is it that you truly want most in the depth of your heart? What out there in the world is truly worth wanting? How do we cultivate your highest desires?” In our current culture, everybody tells you to find your passion, but nobody tells you how. Schools and organizations are going to have to teach that.

That’s complicated, because we don’t have direct control over our desires. You can’t will yourself to be more curious any more than you can will yourself to like the taste of goose liver. But the good news is: We can indirectly influence our desires by putting ourselves in situations that either arouse or depress them.

Many of our schools do a decent job of crushing students’ desire for mental effort. Every minute that a kid sits bored in a classroom crushes their desire. Extrinsic rewards, such as grades, do so because extrinsic desires tend to crowd out intrinsic ones. Grade inflation crushes desire by making everything too easy. Many of our systems have been created by rationalists to focus on the declarative level of the mind, the part that learns facts and considers arguments; they are often oblivious to the damage they are doing in the dark forests, the deeper levels of the mind where motivations emerge.

Fortunately, schools and organizations can also inflame desire. The most straightforward theory of motivation is known as self-determination theory, founded by Edward Deci and Richard Ryan. People feel motivated when they are put in situations that give them autonomy (I’m in control of my choices), competence (I’m developing my skills), and relatedness (people here care about me). In my experience, motivation increases with admiration, such as when students are confronted with great people or great works of art. Motivation also increases with apprenticeships, such as when a mentor not only teaches a person how to engineer, but also how to be the kind of person who loves engineering.

My core belief about this whole age is that artificial intelligence will reveal what it means to be human by disclosing what AI can’t do. Before AI, many people believed that reason and intelligence were the qualities that define humanity. They are what make us different from the animals. But soon there will be entities that are much smarter than us; so that can’t be what defines humanity.

What AI can’t do is hunger for things. Yes, a few reward-like mechanisms are in the thin layer of the models built through reinforcement learning, but the models are overwhelmingly about predicting, not desiring. AI can’t hunger, in the first place, because it doesn’t have biological needs—the needs that push living things to grow and explore. More important, AI doesn’t have a self. A bot doesn’t have a past person that it used to be or a future person that it wishes to become. A bot does not have a structure of cares and an order of loves, as a person does. A bot doesn’t have a personal history, a particular set of wounds, joys, and exhilarations experienced in regions deeper than rational calculation, and it doesn’t have a succession of dreams and hopes, which emerge from those regions as well.

Despite what the rationalists used to tell us, life is not mostly about solving problems. Any computer can do that. Life is a pilgrimage, a journey—it’s going somewhere, growing from experience, expanding yourself, reaching for some possibility that you do not yet possess. The defining human features therefore are propulsions—the drives that push us to take on mental effort and overcome difficulty—and aspirations: knowing where you want to go, what purpose you serve, what kind of person you’d like to be.

If we can help people learn to want more, hunger more, they’ll be willing to undertake the mental effort to do hard things, and we’ll avoid the cognitive polarization that is staring us in the face. If we can educate people to be clear and wholehearted about what they truly love, then AI will do the calculating and the synthesizing, but humans will still define what matters, what is worth exploring, what missions we go on, and where we end up. That would produce a bot-filled society in which human dignity is preserved, and perhaps even enhanced.

The camera can never be truly switched off and keeps monitoring the driver at all times to make sure they're paying attention to the road.

Big tech renting out excess compute is an indicator that the industry has overbuilt.

Full article content is not available for inline reading.

Read the original article →

This is a two part series focusing on what I believe is perhaps the least understood upcoming shift in AI economics.

The real DeepSeek moment is upon us

What feels like decades ago, markets recoiled at DeepSeek's R1 model. The theory being that given the underlying V3 model reportedly cost under $6m to train, the market therefore thought the huge investment in capex for model training was over, and thus the stock price of Nvidia et al collapsed overnight.

Of course, this was a hugely poor read of where the costs actually lie in AI. Training - while no doubt capex intensive - is a fixed, up-front cost. You spend hundreds of millions to train a model, then you are "done".

Inference, on the other hand, scales with your demand. It has genuine marginal costs. I've written about this at length over the past year or so. Again, the mainstream understanding of this - that the API costs the providers charge are their real costs is mistaken.

Indeed, when Anthropic/OpenAI charge $25/MTok for inference, my napkin maths suggests that this is probably something like 90% gross margin on the cost of compute vs the rack rate. It may be a bit higher, or a bit lower (OpenAI's leaked financials suggest a ~60% gross margin on revenue, but this no doubt includes a lot of other costs like support, payment processing and other services they offer), but the whole business model of frontier AI labs is in short to spend a large amount of money on salaries on compute to train a model, then amortise that cost over a lot of very profitable inference. If you can amortise that cost over enough inference you turn from profitable on a COGS basis to... actually profitable.

GLM 5.2

I have been playing around with GLM5.2 from Z.ai for the last couple of weeks. I believe GLM5.2 is the first model that reaches the "bar" of a genuine open weights competitor to Opus and GPT (at the time of writing, the latest version of GPT was 5.5 - future models no doubt will exceed this).

It's genuinely very good and hard for me to tell the difference between Opus - my daily driver and it.

I've found that it is slow because of the amount of thinking it tends to do. For non interactive agentic tasks (like reviewing PRs in the background) which aren't time critical this is a non issue, but for interactive use it is definitely a tad too slow to keep my attention. This also somewhat reduces the cost effectiveness of it (more thinking means more tokens, which increases costs).

It also doesn't have vision support. It's funny how quickly I've gone from basically never wanting to use vision (because it was so inaccurate, I'd often pause sessions when I caught it using vision), to using it all the time - since Opus 4.7 introduced far higher resolution vision capabilities. It's genuinely frustrating it not being able to read image-based PDFs, screenshots and design files. I'm sure they have a more multimodal model in the works, but this is a significant weakness against the frontier labs.

Secondly, and something I really didn't expect to be a blocker, is the lack of/poor web search capabilities. It turns out that nearly every agentic session does a lot of web searching for looking up items. Z.ai provides a replacement MCP for web search, but it's pretty awful and slow. Fireworks doesn't provide any, though they gave me a very vague answer saying they are always looking to improve products. I would take that as no plans personally, but let's see.

I've managed to somewhat work around this by telling the agent to use a CLI based web search like ddgr, but this is a real weakness right now. I am very bullish on the potential of 3rd party web search APIs. This is actually a huge gap in what open weights model providers can offer, and it turns out great web search capabilities are essential for many agentic tasks. Regardless, this no doubt will be solved with time - there are many people building web search indexes and it just requires the right partnerships and plumbing in place.

Drop in replacement

Where it gets really scary for the frontier labs is how easy it is to migrate to open weights models. Both Z.ai and Fireworks offer both an OpenAI compatible and Anthropic compatible endpoint. This makes it absolutely trivial to use with Claude Code and Codex. You just set the base URL to point to your inference provider, give it the API key and tell it to use GLM5.2.

Given Anthropic recently announced (then backtracked) on charging API rates for claude -p non interactive agentic use, you will find for many/most of those use cases you can just drop in GLM instead. And for interactive use, apart from the lack of vision and slow(er) speed, it was genuinely almost impossible for me to realise I wasn't using Opus in Claude Code.

This is not Microsoft or Salesforce like lock in, where you need to spend years planning a migration. The switching costs are incredibly low, and I would argue that are actually far less than trying to keep up on all the policy and term changes that the frontier lab models tend to scramble around with. It's possible that Claude Code will make it harder to use 3rd party providers, but there are many good open source options (like Codex itself and OpenCode, amongst dozens).

One concern I do hear from enterprise is data privacy and security. There is no doubt that using Z.ai's official API and subscription is almost certainly a non-starter, with their terms being at best weak and the deep connection to Mainland China. But of course, with open weights being open there are many other providers in the market, many with proper contractual provisions. And, if that isn't enough, you can of course host in on premises yourself, which actually opens up even more sensitive data - that couldn't be sent to any third party - to Opus-quality agentic workflows.

Cost savings

The going rate for GLM5.2 seems to be around the $4.40/MTok mark. This is less than 20% of the retail price of Opus and ~15% the cost of GPT5.5. Now, given it does use more tokens for a given task, this isn't a totally apples to apples comparison. But I'd be very surprised if it wasn't more than 50% cheaper for nearly all workflows, for a very similar level of quality.

In terms of subscriptions, Z.ai offers a "coding plan" subscription which mirrors the plans you'd see from Anthropic and OpenAI, but with a higher claimed usage limit. I expect for most professional use the very lax terms around training and data retention will make this a difficult sell, but if the frontier labs were to try and increase pricing substantially I can see it being a credible option for those that are budget-conscious.

I expect these costs for GLM5.2 to come down significantly over the coming months as well, as more optimisation is done to the serving stack(s). Wafer wrote an interesting write up of their efforts to run it on AMD hardware. They suggest that it is 2.75x cheaper per token to run inference on AMD vs Nvidia Blackwell.

Part two is where this gets interesting - what a collapse in inference margins actually does to the industry, and who is likely to win and lose. I'd keep Bezos's famous "your margin is my opportunity" line in mind.

1. This is a simplification - the frontier labs are effectively training new models constantly to stay competitive, so it's really a rolling cost rather than a true one-off. The key distinction still holds though: unlike inference, that cost doesn't scale with how much customers actually use the product.

2. To be fair, the slowness is mostly the model thinking a lot rather than the serving itself - Fireworks launched GLM5.2 at genuinely quick tokens/sec, which was a huge improvement and well worth keeping an eye on, though in practice I found it a bit temperamental at how fast it actually was.

Mozilla shut down the well-loved read-it-later Pocket app last year, and now Meta is launching an app called Pocket with an entirely different, AI-focused pitch, writes The Verge.

While it's not available for downloads in most locations, Meta's Pocket will allow people to generate small, interactive apps and games using AI prompts, writes TechCrunch. They're called "gizmos", and Pocket also offers a scrollable feed where you can play with gizmos others have made.

Some context from The Verge: Meta CEO Mark Zuckerberg is all in on AI as the new social media, and he's previously described a vision of how users could use AI to make interactive experiences and share them with people. The launch of Pocket appears to be one manifestation of that idea... It follows Meta hiring engineers from a company called Atma Sciences Inc., which made an app called Gizmo, as Business Insider reported in March.

On a help center page, Meta also describes a gizmo as a "playable AI-generated experience," and when you post one, Meta says you can choose to let other people remix them.

Based on the app's screenshots in Google Play, there are many similarities to Gizmo's original app, which is still listed, notes TechCrunch.

Pocket is another example of Meta's push to make AI creation tools more mainstream, extending its earlier efforts, which included AI-generated images created via its Meta AI app and AI videos created with its app called Vibes. It has also added AI features across its social platforms... Given that Meta has not officially announced Pocket's debut, it's likely that Pocket is still in its initial experimentation phase. Its counterpart Gizmo, however, had generated 635,000 lifetime installs across both iOS and Google Play, according to Appfigures, which noted it had a 98% positive sentiment.

Generate professional blueprint views from photos, or convert existing sketches into precise, lightweight CAD files.

Zero Vector Design is a methodology, an open-source ecosystem, and a growing movement redefining how products get built in the age of AI.

Many brands are becoming visually indistinguishable by adopting minimalist, system-friendly identities that prioritize digital scalability over personality—a trend often described as "blanding." Research shows that distinctive branding improves recognition, pricing power, and emotional connection, while brands like Burberry and Liquid Death demonstrate the commercial value of embracing unique identities. As AI-generated design becomes more common, the challenge will be using technology to amplify originality rather than accelerate visual sameness.

Anthropic is offering access to Claude Fable 5 at no extra cost until July 12. The promotion is available on Pro, Max, Team, and premium seats on seat-based Enterprise plans. Up to 50% of users' weekly subscription limits can be used on Claude Fable 5 during the promotional period. After reaching the limit, users can continue using Fable 5 with usage credits or switch to another model and keep working within their remaining limits.

The Samsung Galaxy Z Fold 8 is expected to feature a shorter and wider design that resembles Apple's planned folding iPhone.

The Rust Clippy project has a review-capacity problem because no current team member is funded to work on Clippy, leaving maintenance to volunteer free time.

Elon Musk has merged xAI with SpaceX under the new SpaceXAI brand, introducing a combined logo that blends visual elements from both companies. While the redesign aims to unify Musk's AI and space ventures, many critics have compared the logo to Reebok's branding and criticized both the name and identity as uninspired.

Typography is one of the most powerful yet overlooked branding tools, influencing how people perceive a brand before they even read its message. The right typeface communicates personality, tone, and values, helping brands appear trustworthy, innovative, luxurious, or approachable depending on their goals. When used consistently across websites, packaging, advertising, and other touchpoints, typography strengthens recognition, builds trust, and becomes a core part of a brand's identity.

London's 750-year-old Surrey Street Market has unveiled a new visual identity created by design studio Bob in collaboration with students from Croydon School of Art. Inspired by the market's history, architecture, and community, the identity features a custom typeface, playful wayfinding, and inclusive graphics developed through workshops and public consultation. The project celebrates the market's heritage while giving it a vibrant, contemporary look shaped by local voices.