You’re training an LLM with RL. Single-turn looks great: clean curves, sane rewards, things converge. But modern models are enhanced with tools, and that’s exactly what you want: to train an agent.

So you upgrade your training loop to allow the model to call a tool mid-rollout. You start with an easy task, and the curves get weird. Loss occasionally spikes for no obvious reason. And eventually it fails with a shape mismatch error.

What’s almost certainly going on: your rollout loop is silently violating the Token-In, Token-Out (TITO) invariant. You parsed the model’s response to detect tool calls, then re-tokenized the updated conversation for the next turn. Usually that round-trip gives back the same tokens. Sometimes it doesn’t, and the gradient ends up on a sequence the model never sampled. The code doesn’t crash, but the math is silently broken and the gradient signal becomes completely unreliable.

Two ways to fix it.

The first is to abstract the chat template behind a per-model interface. For every family you train on, you hand-code a renderer that knows how to format messages, parse completions, and bridge between turns without re-rendering. It’s tricky to get right. The renderers library does this. It works, and it covers the major open-weights families today. The cost is structural: every new model needs a new hand-coded renderer, and changes to any template propagate as ongoing maintenance.

The second is to design the training around one rule: never re-encode tokens you’ve decoded. Follow it, and the tricky edge cases vanish. You’re left with a single property to check on the chat template: it must be prefix-preserving for tool messages (we’ll explain). Turns out the vast majority of templates in the wild already satisfy it. This is Token-In, Token-Out done right, and that’s what this post is about.

Train on the model’s own tokens

tl;dr RL updates the model on the exact tokens it sampled, and nothing else. Simple now, load-bearing later.

Reinforcement learning, in one breath: you sample a prompt, the model generates a completion, you score the completion, you backprop the gradient through the model’s generated tokens.

sample prompt [{"role": "user", "content": "What's 2+2?"}] tokenize prompt 1023421799 "<user>What's 2+2?</user><eos>" generate completion 4799 "4.<eos>" compute reward +1 backprop on assistant tokens ∇ on 4799

One detail matters more than it looks. The gradient is computed on the tokens the model generated. That sounds obvious. What else would you train on? It is obvious. Remember it anyway, because you’re going to break it sooner than you think.

Multi-turn doesn’t change much. The model is allowed to call a tool mid-rollout: it emits a tool call, something on the outside runs the tool, the result is appended back into the conversation, and the model picks up from there. The rollout is just longer now: a few model turns, a few tool turns, a final answer.

sample prompt [{"role": "user", "content": "What's 2+2?"}] tokenize prompt 1023421799 "<user>What's 2+2?</user><eos>" generate completion 50711399 "<tool_call>calc(2+2)</tool_call><eos>" execute tool and append result 6046199 "<result>4</result><eos>" generate completion 4799 "4.<eos>" compute reward +1 backprop on assistant tokens ∇ on 50711399 + 4799

The rule carries over: backprop on the tokens the model produced. Not the tool’s response (those didn’t come from the policy).

The takeaway is small and very specific: in RL, you optimize on the exact tokens the model produced. Right now it reads like a definition. Later in the post, it’s the thing that breaks.

Decoding doesn’t undo encoding

tl;dr Tokenization isn’t reversible: decode a sequence, re-encode the text, and you can land on different tokens.

Going from messages to tokens is mechanical: a chat template renders the messages into a string, then the tokenizer chops that string into integer IDs.

>>> from transformers import AutoTokenizer
>>> tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-0.5B-Instruct")
>>> messages = [
...     {"role": "user", "content": "What's 2+2?"},
...     {"role": "assistant", "content": "4."}
... ]
>>> tokenizer.apply_chat_template(messages, return_dict=False)
[151644, 8948, 198, 2610, 525, 1207, 16948, 11, 3465, 553, 54364, 14817, 13, 1446, 525, 264, 10950, 17847, 13, 151645, 198, 151644, 872, 198, 3838, 594, 220, 17, 10, 17, 30, 151645, 198, 151644, 77091, 198, 19, 13, 151645, 198]

Most of the time you don’t think about it. You feed messages, you get tokens, the model does its thing.

Multi-turn is where it starts to matter. When the assistant emits tokens, you don’t know whether it’s about to call a tool until you look. So you decode the generated IDs back into text, parse out the structure, dispatch the call. The pipeline runs backwards, conceptually.

The model can generate a response without calling a tool:

>>> output_ids = [19, 13, 151645]  # what the model just generated
>>> tokenizer.parse_response(output_ids)
{"role": "assistant", "content": "4."}

or it can call a tool:

>>> output_ids = [151657, 198, 4913, 606, 788, 330, 88821, 497, 330, 16370, 788, 5212, 9413, 788, 330, 17, 10, 17, 95642, 151658, 151645]
>>> tokenizer.parse_response(output_ids)
{'role': 'assistant', 'content': '', 'tool_calls': [{'type': 'function', 'function': {'name': 'calculator', 'arguments': {'expr': '2+2'}}}]}

Here’s the catch. Decoding isn’t injective. Multiple distinct token sequences can decode to the same string. Which means: take some tokens, decode them, encode the result back, and you may land on a different sequence than the one you started with.

Here, briefly: byte-pair merges aren’t stable across token boundaries. Given a string, BPE has one canonical greedy segmentation, but many other valid segmentations exist. Anything you stack on top of that (JSON serialization with negotiable whitespace, argument ordering, boolean casing (false vs False), how special tokens get re-rendered after a parse) adds more degrees of freedom.

The natural-but-wrong loop

tl;dr Re-rendering the message list every turn drifts the tokens, so you backprop on a sequence the policy never produced.

The natural way to write the loop is the one you’d write on a Friday afternoon. Keep the conversation as a list of messages. Loop over turns. At each turn, render the conversation, generate, parse, append, repeat. When the model finishes, tokenize the whole thing and backprop.

sample prompt while model should generate a new turn: tokenize conversation so far generate tokens until model stops parse the response and append if there's a tool call: execute tool and append result else: stop compute reward tokenize the full conversation compute loss on the tokenized conversation backprop on assistant tokens user "What's 2+2?" assistant tool_call: calc(2+2) tool "4" assistant "It's 4." tokens 1023421799507113996046199875799

But it’s broken in two specific ways.

The first is small but unpleasant. When you tokenize the full conversation at the end, you’ve lost the per-turn boundaries. The trainer no longer knows which tokens came from the assistant and which came from the tool, and you only want to compute loss on the assistant turns. So you have to recover that mapping after the fact: walk the rendered string, find the role markers, figure out which token indices fall inside each assistant turn. Doable, but every chat template does this differently, and you end up writing a small parser per model family. The renderers library exists in part to do exactly this. It attaches a message_indices array to the rendered ids so each token knows which message it belongs to.

The second is much worse. You broke the rule sooner than you thought: re-tokenizing the conversation at the end can give you a slightly different token sequence than the one the model sampled. Same string, different integer ids. We saw why in the previous section: encode and decode aren’t inverses. Consequently, you backprop on these new ids. The gradient targets tokens the policy never produced. The rule from before breaks.

That’s the loop everyone writes first. And it’s why this post exists.

TITO Done Right

tl;dr Keep the sampled tokens in one buffer, never re-encode them, and both failure modes disappear.

The fix is one rule: never re-encode tokens you’ve decoded.

The model’s sampled tokens go straight into a running buffer, and that buffer is the source of truth. The messages list becomes bookkeeping. We do parse the sampled tokens. We have to, to know whether to dispatch a tool. But the parsed dict is for routing only. It never feeds back into the prompt.

sample prompt tokenize prompt while model should generate a new turn: generate tokens, append to buffer parse the response if there's a tool call: execute tool, tokenize response, append to buffer else: stop compute reward compute loss on buffer backprop on assistant tokens user "What's 2+2?" assistant tool_call: calc(2+2) tool "4" assistant "It's 4." buffer 1023421799507113996046199875799

That single change solves both problems from the previous section.

The per-turn boundaries are never lost because they’re never recovered. They were known the moment each chunk was appended. The buffer keeps the structure as it grows: these tokens came from the prompt, these from the model, these from the tool, these from the model again. The loss mask is built as you go, not reconstructed afterwards from a re-rendered string.

The token drift is gone for the same reason. The buffer never gets re-encoded. The tokens the policy sampled are exactly the tokens under the gradient. Encoding and decoding are still non-injective. That hasn’t changed. But we never use the non-injective round-trip. We decode (for tool dispatch), use the result for routing, and throw it away. Nothing decoded ever goes back through encode.

The only chat-template operation left in the loop is “tokenize the tool response and append.” Everything else is token concatenation.

The tool-response delta

tl;dr The only template operation left: diff two dummy renders for the tool-response tokens, then append them by id.

The TITO loop has one chat-template operation left: tokenize the tool response and append it.

How do you go from the tool result (e.g., "4") to the full wrapped sequence the model expects (<|im_start|>user\n<tool_response>\n4\n</tool_response><|im_end|>\n<|im_start|>assistant\n)?

The way is to use the template only for the tool message. Render the conversation twice (with and without the tool), subtract, and the suffix is exactly the bridge you need to append.

>>> from transformers import AutoTokenizer
>>> tok = AutoTokenizer.from_pretrained("Qwen2.5-0.5B-Instruct")
>>> messages_prefix = [
...     {"role": "user", "content": "What's 2+2?"},
...     {"role": "assistant", "tool_calls": [
...         {"type": "function", "function": {"name": "calc", "arguments": {"expr": "2+2"}}}
...     ]},
... ]
>>> messages_full = messages_prefix + [{"role": "tool", "content": "4"}]
>>> prefix = tok.apply_chat_template(messages_prefix, return_dict=False)
>>> full = tok.apply_chat_template(messages_full, return_dict=False, add_generation_prompt=True)
>>> delta = full[len(prefix):]
>>> delta
[151644, 872, 198, 27, 14172, 9655, 397, 19, 198, 522, 14172, 9655, 29, 151645, 198, 151644, 77091, 198]
>>> tok.decode(delta)
'<|im_start|>user\n<tool_response>\n4\n</tool_response><|im_end|>\n<|im_start|>assistant\n'

That’s the entire template-aware part of the loop. The running buffer never sees a re-rendered version of anything the model sampled. It just gets delta appended.

The prefix doesn’t even have to be a real conversation. Any dummy that ends in an assistant tool call works, since the delta only depends on the tool message and the template’s transition logic, not on the prior turns.

The trick has one precondition: the chat template must be prefix-preserving for tool messages. Concretely:

>>> assert full[:len(prefix)] == prefix

If that fails, the subtraction lands on a corrupted suffix. That condition is the subject of the next section.

Prefix preservation

tl;dr It all rests on one property: appending a tool result must extend the render verbatim. Nearly every template already does.

The tool-response delta asks one thing of the chat template, and it’s worth stating precisely because the whole loop rests on it. Take any tool messages appended after an assistant tool call. Rendering the conversation with them must extend the render without them, token for token:

render([user, asst_with_tool_call, tool_result])  starts with  render([user, asst_with_tool_call])

That is the prefix-preservation property, and the striking thing is how narrow it is. It is required only for tool messages. The template is free to do whatever it likes everywhere else (collapse old thinking, rewrite the system prompt, reorder fields) as long as appending a tool result never disturbs bytes it already emitted. User, assistant, and system turns are under no such obligation.

Checking it is a property test, not a proof. Render the prefix, render the extension, compare:

def is_chat_template_prefix_preserving(tokenizer) -> bool:
    dummy_tool_calls = [{"type": "function", "function": {"name": "dummy", "arguments": {}}}]
    messages1 = [
        {"role": "user", "content": "dummy"},
        {"role": "assistant", "content": "", "tool_calls": dummy_tool_calls},
    ]
    messages2 = [
        {"role": "user", "content": "dummy"},
        {"role": "assistant", "content": "", "tool_calls": dummy_tool_calls},
        {"role": "tool", "name": "dummy", "content": "dummy"},
    ]
    ids1 = tokenizer.apply_chat_template(messages1, tokenize=True, return_dict=False)
    ids2 = tokenizer.apply_chat_template(messages2, tokenize=True, return_dict=False, add_generation_prompt=True)
    return ids2[: len(ids1)] == ids1

Twelve lines, milliseconds to run, and you can point it at any model the day it ships. So does the property hold in the wild? We ran it across the open-weights families people actually reach for in agentic RL:

family	prefix-preserving for tool messages?
Qwen2.5	✅
Qwen2.5-Coder	✅
Qwen3	❌ (one-line fix below)
Qwen3 Instruct (2507)	✅
Qwen3-VL	✅
Qwen3.5 (think and non-think variants)	✅
Qwen3.6	✅
DeepSeek-V3.1	✅
DeepSeek-R1	✅
DeepSeek-R1-0528	✅
Llama 3.1	✅
Llama 3.2	✅
Llama 4	✅
Gemma 4	✅
Function Gemma	✅
gpt-oss	✅
GLM-4.5	✅
GLM-5	✅
MiniMax-M2.1	✅

Eighteen of nineteen, untouched. The property isn’t fragile or rare, it’s the quiet default. That’s the load-bearing observation for everything that came before: prefix preservation for tool messages is a weak, narrowly-scoped condition modern templates satisfy almost by accident, not a demanding one that justifies reimplementing the template per family.

Then there’s Qwen3. Easiest way to see what’s going on is to render the dummy conversation and inspect the output, before and after appending the tool message:

>>> from transformers import AutoTokenizer
>>> tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3-4B")
>>> dummy_tool_calls = [{"type": "function", "function": {"name": "dummy", "arguments": {}}}]
>>> messages1 = [
...     {"role": "user", "content": "dummy"},
...     {"role": "assistant", "content": "", "tool_calls": dummy_tool_calls},
... ]
>>> messages2 = messages1 + [{"role": "tool", "name": "dummy", "content": "dummy"}]
>>> print(tokenizer.apply_chat_template(messages1, tokenize=False))                                # left column below
>>> print(tokenizer.apply_chat_template(messages2, tokenize=False, add_generation_prompt=True))    # right column below

apply_chat_template(messages1) apply_chat_template(messages2) <|im_start|>user <|im_start|>user dummy<|im_end|> dummy<|im_end|> <|im_start|>assistant <|im_start|>assistant <think> </think> <tool_call> <tool_call> {"name": "dummy", "arguments": {}} {"name": "dummy", "arguments": {}} </tool_call><|im_end|> </tool_call><|im_end|> <|im_start|>user <tool_response> dummy </tool_response><|im_end|> <|im_start|>assistant

The first one slips an empty <think>...</think> block in front of the tool call; the second drops it. The prefix breaks at that exact spot.

One Jinja conditional gates this:

{%- if loop.last or (not loop.last and reasoning_content) %}

When reasoning_content is empty, the <think> block renders only on the last assistant turn. Appending a tool result demotes that turn from being last, and the block disappears.

The fix is one line:

- {%- if loop.last or (not loop.last and reasoning_content) %}
+ {%- if true %}

It costs nothing at inference and restores prefix preservation for training. Qwen3: ✅

Do you need a renderer for this?

tl;dr A per-model renderer guards against re-encoding bugs TITO never has; the lone real requirement is the property from the previous section.

There’s a heavier alternative to the loop above. Instead of a ten-line compute_delta, you build a renderer: a per-model object that owns the messages-to-tokens boundary. It renders messages, parses completions, and exposes a bridge_to_next_turn(prev_prompt_ids, prev_completion_ids, new_messages) that extends the sampled stream byte-for-byte (or returns None when it can’t prove the extension is safe). One is hand-coded per model family. The renderers library ships them for Qwen3, GLM, DeepSeek-V3, Kimi, gpt-oss and a dozen others; tinker-cookbook ships its own variant.

one turn → next turn, viewed by each design renderers prev_prompt_ids ++ prev_completion_ids p₁p₂p₃c₁c₂c₃ + new_messages Renderer.bridge_to_next_turn hand-coded per family · returns Δ or None Δ ids next_prompt_ids p₁p₂p₃c₁c₂c₃d₁d₂ extends prev stream byte-for-byte TITO buffer (single stream) p₁p₂p₃c₁c₂c₃ parse c₁..c₃ for dispatch only compute_delta(messages, tok) ~10 lines · shared across all models Δ ids buffer += Δ p₁p₂p₃c₁c₂c₃d₁d₂ nothing re-encoded · loss mask grows with the buffer Both paths arrive at the same token stream. The difference is where the chat-template logic lives: inside a per-family Renderer object, or inside one shared compute_delta the trainer calls.

Both paths start from the same (prev_prompt_ids, prev_completion_ids) and end at the same extended stream. The only difference is where the template logic lives: inside a hand-coded per-family object, or inside the one shared compute_delta the trainer already calls. The renderer route buys things: a unified API across model families, a message_indices array that gives you loss masks by indexing, a bridge that fails loud rather than drifting silently, and the ability to work when you don’t control the inference endpoint. If you’re plugging into a vendor API that only speaks messages (not tokens), that is not nothing. And the logic lives in Python rather than Jinja: something you can read, test, and step through in a debugger, which the template it replaces (you saw a slice of that Jinja in the Qwen3 fix above) is not.

For RL specifically, most of those are guards against problems TITO never has, and the ergonomic pull rarely gets spent: Python beats Jinja only when you reimplement the template, and TITO doesn’t. BPE retokenization drift, canonicalization, JSON whitespace: they only bite a pipeline that re-encodes a string it got from decode. TITO never does, so even a non-canonical sample ([he][llo] where the canonical encoding is [hello]) stays verbatim in the buffer, exactly the tokens under the gradient. It is also why the one property we do need can be checked at the token level rather than the text level: the test runs on a canonical dummy where the two coincide, and the delta is appended by plain id concatenation at an atomic special-token seam (<|im_end|> then <|im_start|>, neither merges). That property, prefix preservation for tool messages, is the whole and only requirement.

The honest edges

tl;dr Two places reality pushes back: history rewriting genuinely breaks the math, truncation barely registers.

History rewriting

A growing class of agents edit their own past as they go. Z.ai’s reasoning models ship a clear_thinking flag that strips <think> blocks from every turn but the last. Long-running coding agents (Claude Code, aider, Codex) compact the conversation when it nears the context limit, replacing dozens of past turns with a short summary. Sub-agent setups go further: a child agent runs, produces a long trace, and only its distilled summary makes it back to the parent. Useful, increasingly standard, and all the same thing under the hood: at some point in the rollout, the tokens that came out of the model are no longer the tokens that go back in.

That breaks TITO at the source. The rule we started with was you optimize on the exact tokens the model produced. The “previous turn” the next step is conditioned on never existed as a sampled trajectory, and the PPO/GRPO importance ratio has nothing to say about a Frankenstein prompt the policy never generated. The objective itself is undefined, not just the implementation.

The workaround keeps what you can justify and drops the rest, and it doesn’t care which kind of history rewriting happened. Pick the last point in the rollout where the past was edited (a compaction, a clear_thinking strip, a sub-agent summary, anything) and freeze everything before it as prompt. Loss mask is zero across the frozen part, so prefix preservation and BPE drift no longer apply to it: it’s just a prompt the trainer happened to construct in a funny way. Everything after is genuine sampled tokens, still under the gradient, still TITO.

sampling… compacting… sampling… what the trainer can use prompt asst 1 tool asst 2 tool asst 3 compaction summary asst 4 tool asst 5 loss is computed here

The price is the obvious one: the further along the last rewrite lands, the shorter the loss-bearing tail. A long trajectory with periodic rewrites can leave you training on the final few hundred tokens out of tens of thousands sampled.

Truncation

A rollout that hits max_seq_len mid-turn ends without its canonical close token. For a renderer, that’s a real problem. The bridge anchors on that token to extend the stream byte-for-byte; with it missing, the bridge can’t prove a safe extension, returns None, and the caller falls back to a full re-render, which re-triggers exactly the drift modes the renderer was built to prevent. The fix is to teach each renderer to recognize a truncated tail and synthesize its own close token there as non-loss context. Another defense, another per-model file, another set of tests.

Under TITO it’s a non-event. Generation hits the limit, the buffer ends, the rollout terminates. Mid-reasoning, the dangling <think> never needs to close: the tokens are in the buffer as the model produced them, and the loss mask doesn’t care that the structure doesn’t parse. Mid-tool-call, the parser sees an incomplete block and dispatches nothing; there was no budget left for the tool’s result anyway. Nothing on our side of the page, because there was nothing to defend.

The right primitive

You don’t need to reimplement a chat template to train on it, as long as you hold the tokens. (When you don’t, say you’re training against an endpoint that only speaks messages, a renderer is the right and maybe only tool.) You need to know one thing about the template: does appending a tool result extend the render token-for-token? If the answer is yes (it usually does), and you’ve followed the main rule of “never re-encode tokens you’ve decoded,” then your training loop is already correct. The only thing left is to implement the tool-response delta, which is a few lines of code.

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 →

How to Automate AI Model Documentation with the NVIDIA MCG Toolkit

AI-Generated Summary

• NVIDIA's Model Card Generator (MCG) toolkit automates and standardizes the creation of comprehensive AI model documentation in Model Card++ format, improving transparency and regulatory compliance by extracting information directly from source code and associated files.
• The MCG pipeline operates in three stagesIngestion, Extraction, and Renderingleveraging NVIDIA Inference Microservices and GPT-OSS-120B for high-precision data retrieval, content generation, and formatting, producing overview and four subcards covering Bias, Explainability, Privacy, and Safety & Security.
• Customization options include configurable language models, templates, and field-level guides, allowing organizations to adapt the toolkit for different compliance needs and industry standards without altering core extraction logic.
• Performance testing shows the toolkit generates model cards quickly (under a minute for most repositories) with a completion rate of 91% and accuracy of 76%, though results depend heavily on the availability and quality of supporting documentation.
• When documentation is sparse or absent, the toolkit flags missing information instead of guessing, serving as both a documentation generator and a gap-finder to assist teams in maintaining up-to-date, auditable model records.
• Oracle is a key early adopter, integrating the MCG toolkit into its OCI AI infrastructure to enhance model documentation and GPU resource optimization within dedicated AI clusters and cloud environments.

AI-generated content may summarize information incompletely. Verify important information. Learn more

As AI models grow in complexity and regulatory scrutiny intensifies under frameworks including  California’s AB-2013 and the EU AI Act, software teams face a challenge beyond delivering great code: They need to produce comprehensive, auditable model documentation before the models are released.

Model cards describe how a model works, its intended use and license, training data, performance, and limitations. They promote transparency and accountability so downstream users—customers, regulators, and affected communities—can make informed decisions when selecting and deploying AI. That audience extends beyond developers: Policymakers, procurement teams, and risk assessors rely on model cards to evaluate fitness for use and compare models across vendors.

In practice, creating model cards manually is tedious and slow. Documentation lags behind development, and metadata is often outdated by ship date. As models grow more complex, inconsistent formatting and missing required fields create unnecessary audit risk and slow adoption. The NVIDIA model card generator (MCG) toolkit automates and standardizes model documentation in Model Card++ format in under a minute, by reading directly from source data.

Introducing the NVIDIA MCG toolkit

The MCG toolkit is a containerized pipeline that automates the generation of model cards by reading in the model source code. It follows a modular Ingestion → Extraction → Rendering pipeline. A central orchestrator receives your request—either a URL or an uploaded file—coordinates the workflow, and returns a complete model card. Each stage runs as a separate service, so you can update or swap individual components without affecting the rest of the pipeline.

How the MCG toolkit works

The toolkit exposes an interactive UI that accepts a URL (GitHub, GitLab, HuggingFace, or any public web page) or an uploaded file (ZIP, PDF, DOCX, or Markdown). A REST API is also available for programmatic integration. 

From there, data flows through three stages:

1. Input → Ingestion. The system fetches the content and processes it into document chunks, categorized by type: documentation, config files, and code.
2. Documents → Extraction. The extraction stage runs ingested documents through a retrieval-augmented generation (RAG) pipeline powered by NVIDIA Inference Microservices (NIM). NVIDIA Nemotron RAG  handles high-precision embedding (llama-nemotron-embed-1b-v2) and reranking (llama-nemotron-rerank-500m-v2), with separate retrievers for code, config files, and documentation to prioritize higher-signal sources. The core extraction is performed by GPT-OSS-120B, which reads the retrieved passages and applies expert-curated formatting and content guides—the NVIDIA MC++ template and field-level style guides—to generate compliant information in the expected format. A validation step checks responses before they are accepted. Output is structured JSON. After the overview is complete, the same content flows to a subcards stage, which produces the four Model Card++ subcards: Bias, Explainability, Privacy, and Safety & Security.
3. JSON → Rendering. The structured JSON renders into human-readable Markdown using a configurable template. You can edit the content in the interface and re-render before downloading or integrating with other systems. The final artifact is a complete model card – overview plus four subcards – ready for review or publication.

Designed for flexibility

You’re not locked into one model, template, or standard. The toolkit is customizable across three dimensions:

1) Models: The system uses configurable endpoints for the language model, embeddings, and reranking. Point to different NIMs or compatible APIs to match your performance, cost, or data residency requirements, whether you’re prototyping on a smaller model or scaling up for production.

2) Templates: The output format is driven by a Markdown template. Organizations can customize it for Model Card++, internal standards, or emerging regulatory formats without modifying the extraction logic. Outputs are also CycloneDX-compliant. When a new disclosure requirement appears, you update the template rather than the pipeline.

3) Guides: Field-level guidance—what to capture, how to phrase it—comes from configurable knowledge bases. As regulations or domain needs evolve, update the guides without touching the core code. The same pipeline can serve different industries and compliance regimes.

Run it where you need it

The toolkit ships as containerized services with a one-command setup. The orchestrator, ingestion, extraction, and subcards stages each run as separate containers, with infrastructure (database and task queue) included. There’s no proprietary cloud lock-in: MCG runs on-premises or in your own cloud, with Kubernetes support to help you spin up on your own infrastructure.

Performance results

We ran the toolkit through standardized testing on public model repositories to measure completion rate, generation time, and accuracy. Each field was scored against the source documentation. Accuracy is calculated as correct fields over non-placeholder fields. Table 1, below, shows the results.

Model	Time to Generate	Completion Rate	Accuracy
NVIDIA Nemotron Nano 8B	56s	97%	92%
NVIDIA Cosmos Reason 2	86s	94%	82%
NVIDIA Parakeet	65s	92%	87%
NVIDIA Proteina	52s	94%	82%
Third-party models(DeepSeek-V3, Evo2, Gemma, Llama)	~80s avg	~89%	~80%

The toolkit generates a full model card (overview plus four subcards) in under a minute for most repositories. Overall completion reaches 91% (third-party baseline), with accuracy at 76% across the standardized test set. Completion and accuracy vary by model and repository; repositories with richer READMEs and config files yield higher results.

The toolkit performs best when supporting documentation exists and the codebase is well-structured, using code analysis to supplement where possible. When documentation is sparse or absent, fewer fields are populated and rather than guessing, the system surfaces “not found” or “information not available” to flag gaps for human review.

We also tested what happens when documentation is removed entirely. Using the same repositories from our standard test set, we stripped all .pdf, .md, and .txt files and re-ran the toolkit against code alone. Across five models, average completion rate dropped to 61% from 91%, and strict accuracy, measured only over verifiable fields, fell to 28%, compared with 76% in the standard test that scores accuracy over completed fields only.

The 61% completion shows the toolkit still extracts meaningful signals from code, config files, and repository structure alone; the accuracy drop reflects how much documentation contributes to getting those fields right. 

Critically, the toolkit doesn’t compensate by guessing. If it cannot confidently populate fields, they are surfaced as “not found” or “information not available,” making it a useful gap-finder for teams whose documentation is still being written, as well as a generator for teams whose documentation is complete.

Early adopters and industry partners

Oracle is among our first partners to integrate the MCG Toolkit into production infrastructure. As part of their OCI AI offering, which spans GPU configurations from the A10 to the GB200 NVL72, Oracle deployed the toolkit combination of OCI container engine for Kubernetes and AI offerings, running MCG pods and NIM pods within a standard VCN architecture backed by Object Storage for the NIM models.

Their deployment uses Llama-3.3-Nemotron-Super-49B-v1 as the core extraction model, with Nemotron RAG handling embedding and reranking. GPT-OSS-120B model was hosted and tested on both the dedicated AI cluster with 2xH100 cards as well as the on-demand offering of the model. OCI supports increasingly powerful GPU infrastructure for large-scale AI training and inference, the need for consistent, auditable model documentation grows alongside it.

An OCI Dedicated AI Cluster (DAC) is a private, fully managed generative AI environment with its own dedicated GPUs, endpoints, and security boundary inside OCI. The MCG toolkit brings not only AI transparency tooling directly into that workflow without requiring customers to build it themselves but also the ability for customers to identify the optimal GPU configuration that is needed for hosting the models both in the OCI Dedicated AI cluster environments and baremetal GPU infrastructure.

Getting started

If you’d like to be an early adopter, reach out to the Trustworthy AI team. We’re happy to discuss partnerships.

Not ready for the fully automated toolkit? The Trustworthy AI GitHub repository has open source Model Card++ templates and AI transparency cards for blueprints, datasets, containers, and systems you can use today.

Documentation should keep pace with the models you ship. Whether you adopt the MCG toolkit or start with our open source templates, NVIDIA’s Trustworthy AI initiative is committed to making that easier.

Tags

Trustworthy AI / Cybersecurity | General | Nemotron | Intermediate Technical | Announcement | Deep dive | Machine Learning & Artificial Intelligence | Trustworthy AI

About the Authors

About Pratyusha Maiti

Pratyusha is the software engineer for trustworthy AI products at NVIDIA, where she is responsible for the development of tools advancing transparency and documentation in AI systems. Prior to NVIDIA, she was a research scientist at Georgia Institute of Technology, where she led the development of AI-powered virtual teaching assistants for online classrooms. She combines her expertise in language modeling and AI evaluation with a commitment to developing trustworthy AI tools that prioritize transparency, safety and responsible deployment. View all posts by Pratyusha Maiti

About Michael Boone

Michael Boone is the Manager for Trustworthy AI Product at NVIDIA. He is responsible for building NVIDIA’s technology according to its guiding principles—driving the implementation of products, tools, and processes that enable the company, its customers, and the larger ecosystem to deploy AI with confidence. Beginning his career as a licensed civil engineer, Michael pivoted from transportation infrastructure project management and operations to owning NVIDIA’s global core computer vision product marketing strategy, as well as product feature definition for DRIVE AV. Michael brings a safety-first engineering mindset to the AI frontier, drawing on his background in physical infrastructure to ensure digital systems are built with the same principle and rigor. An inventor and car enthusiast, Michael is a highly trusted collaborator and a leading voice in the deployment of emerging technology across public, private, and research environments. View all posts by Michael Boone

Thursday night’s detonation of Blue Origin’s New Glenn rocket during a static-fire test produced a spectacular fireball over Florida, sending shards of the rocket flying far and wide, into the sea and across the coastal scrubland nearby.

With sunrise on Friday teams from Blue Origin, the US Space Force, and NASA will be able to begin more thoroughly assessing the damage to Blue Origin’s facilities and begin picking up pieces of the rocket.

pic.twitter.com/EfYn4QWW9M

— Nick Johnson (@NickJohnson315) May 29, 2026

Metaphorically, the effort to pick up pieces will extend far beyond Blue Origin. This launch failure will be devastating not just for Blue Origin but also NASA and broad segments of the US space industry. Here’s a look at some of the major issues that will stem from the explosion.

No launch pad

There’s a reason why, before the very first launch of the Falcon Heavy rocket in 2018, SpaceX founder Elon Musk defined success as the vehicle clearing the launch pad. “I hope that it makes it far enough away from the pad that it does not cause pad damage,” he said. “I would consider even that a win to be honest.” Musk had similar thoughts about the first Starship launch, saying he would consider anything that did not destroy the launch mount a “win.”

Big rockets produce big explosions. And ground infrastructure is a challenging and underrated component of a rocket launch.

Multiple sources have confirmed that there is significant damage to Blue Origin’s launch site in Florida, LC-36A. The company invested years and at least hundreds of millions of dollars in this facility. The scale of the massive lightning towers is difficult to comprehend unless one has climbed one of them.

The company does not have another launch site for New Glenn. It has begun preliminary work on a nearby pad, LC-36B, and has plans to develop another site at Vandenberg Space Force Base in California. But these projects are just getting started.

Rebuilding the company’s pad, or finishing a new one, will likely take at least a year, even with a major effort by Blue Origin, and drawing upon Jeff Bezos’ nearly infinite resources. One source familiar with pad rebuilds estimated that 15 months was a “best case” scenario.

A maturing design

You might wonder what the big deal is. SpaceX has been blowing up Starship rockets left and right, and the space nerds seem to be cheering them on.

The reality is that Blue Origin took a more traditional design route with New Glenn, as opposed to SpaceX’s iterative design, which seeks to test, fly, fail, and fix hardware. The New Glenn first stage had performed nearly flawlessly during its first three flights. It is a mature design.

Because of this, Blue Origin had reached the point where it was poised to begin near-monthly launches of the vehicle during the second half of the year, serving a variety of customers, from NASA to Amazon, AST SpaceMobile, and its own internal payloads.

With the Vulcan rocket also currently offline due to an anomaly, it once again places all of the US medium- and heavy-lift launch capacity in SpaceX’s basket, with its Falcon 9 and Falcon Heavy rockets.

Speaking of Vulcan, if this is a problem with the BE-4 engine—and early indications are that the anomaly leading to Thursday night’s failure originated in the central engine of the booster—it would further compound United Launch Alliance’s difficulties in getting the large rocket back into service.

Blue Moon Mark 1

Blue Origin’s cargo lander has emerged as the supreme workhorse of the early stages of NASA’s Artemis program and Moon Base. It has a capacity to deliver up to 3 tons to the lunar surface and would serve as a pathfinder for a larger version of a lander to take humans to the Moon.

This week, NASA announced that its Moon Base I mission would fly on Blue Moon Mark 1, and it awarded Blue Origin $280.4 million to deliver two lunar rovers in 2028. Multiple other missions are planned on the lander, which was designed to be sent to the Moon on a single New Glenn vehicle.

Could Blue Moon Mark 1 launch on other rockets? SpaceX’s Falcon Heavy and United Launch Alliance’s Vulcan vehicles both likely have the lift capacity to push the vehicle to the Moon. But Vulcan is also sidelined at present and has a long line of Space Force payloads in the queue. So what of Falcon Heavy?

The Mark 1 lander is powered by the BE-7 engine, which runs on liquid hydrogen and liquid oxygen. There may be compatibility issues related to the Falcon rocket’s kerosene-powered upper stage, although this has not been confirmed. Also, it is unlikely that Blue Origin would partner with a direct rival, SpaceX, in this manner.

Artemis program

Due to the Mark 1 issues outlined above, there will either be significant delays to, or the need to restructure the early phases of, the Moon Base program. The lunar rovers under development by Astrolab and Lunar Outpost, for example, have a mass of about 1 ton. Only Mark 1 and SpaceX’s Starship have that kind of delivery capacity.

There are also major implications for the main Artemis crewed missions.

NASA recently changed Artemis III to become a mission that will see the Orion spacecraft rendezvous with one or both of the Human Landing Systems under development by Blue Origin (Blue Moon) and SpaceX (Starship) in low-Earth orbit. NASA appears determined to launch this mission in 2027 and plans to announce its four crew members in a couple of weeks.

But it’s now all but certain that a Blue Moon lander will not be ready for such a mission within the next 18 months. NASA will need to decide whether to wait on Blue Origin or press ahead solely with a Starship mission.

As for Artemis IV, the lunar landing mission, this failure further complicates that plan. It is difficult to imagine a scenario in which a crew-rated Blue Moon lander is ready at any point in 2028 now. Even if the hardware is far along, Blue Origin still needs to fly test missions with Blue Moon Mark 1, which are on hold indefinitely.

A number of senior NASA officials had come to view Blue Origin’s plan to use a slimmed down version of the Mark 2 lander, which would not require in-space refueling, as the prime option for Artemis IV. Now, like much of the US space industry, NASA finds itself highly dependent on SpaceX’s ability to deliver with Starship.

Note: This article has been edited to clarify interoperability issues between the Blue Moon Mark 1 lander and the Falcon Heavy rocket.

Full article content is not available for inline reading.

Read the original article →

TL;DR

Tech internship postings fell 30% since 2023. AI now handles the tasks companies used to give interns. The entry-level pipeline is breaking.

Katelyn Watterson owes her career to a summer internship. As a student at American University, she spent a summer working for a high-end beauty brand in New York. Her boss offered her a full-time job over drinks at the Plaza Hotel.

Almost two decades later, Watterson runs her own marketing agency, Fifty Six. At times, she managed as many as eight interns. She enjoyed mentoring them and opening doors for the next generation.

Then AI arrived. The hours she spent tracking down unfinished work and teaching college students professional basics started to add up. Meanwhile, AI could do more and more of the tasks she delegated to interns, and faster.

The data confirms it. A Drexel University annual survey shows that the number of companies scaling back internship programmes is growing. The number expanding them is shrinking. Tech internship postings have dropped 30% since 2023.

Only 7% of new hires at major tech companies are now recent graduates, down from 9.3% in 2023. Internships have declined 11% year on year. The traditional pipeline, where students perform routine tasks in exchange for experience and a shot at a full-time offer, is breaking because AI handles the routine tasks.

The economic logic is straightforward. An intern costs time, supervision, and management overhead. AI costs tokens. When the tasks are structured, repetitive, and low-stakes, the cost comparison is not close. Research, data entry, scheduling, first-draft writing, and basic analysis were the bread and butter of internship programmes. They are now the bread and butter of ChatGPT.

Salesforce cut its support staff from 9,000 to 5,000 after deploying AI agents. Detroit’s automakers eliminated 20,000 white-collar jobs while posting AI roles. The pattern at the top of the corporate ladder, replacing humans with AI for structured tasks, is now reaching the bottom rung.

The paradox is that AI simultaneously makes internships less necessary and more valuable. Companies need fewer interns to handle busywork. But the interns who do get hired are expected to arrive with AI fluency that previous generations never needed.

McKinsey now tests candidates on their ability to collaborate with its AI assistant Lilli. The firm has 25,000 AI agents supporting 60,000 employees. It launched a free AI practice tool so candidates can prepare for a hiring process that evaluates how they work with machines, not just how they think alone.

AWS CEO Matt Garman has argued that replacing juniors with AI is “one of the dumbest ideas” a company can have. His rationale is that junior employees are often the most proficient AI users, having adapted to the tools during their education. The 2025 Stack Overflow Developer Survey found that 55.5% of early-career developers use AI tools daily, a higher rate than their senior counterparts.

The counterargument is that AI fluency without domain experience produces workers who can prompt well but cannot evaluate the output. The “Editor Problem,” as researchers have called it, describes a generation that can generate content with AI but lacks the judgment to know when the content is wrong. That judgment historically came from internships.

The AI job market is booming at the senior level. Forward deployed engineer postings are up 19x year on year. Claude Evangelists earn $240,000. Chief AI Officers command nearly $500,000. The jobs AI creates pay more and require more experience than the entry-level positions it eliminates.

Some companies are pivoting to apprenticeships as an alternative to internships. Accenture now fills 20% of its entry-level hiring through apprenticeships. IBM and Microsoft have scaled programmes that prioritise skills verification over degree pedigree. The apprenticeship model offers longer, more structured training than a summer internship, but it also requires more corporate investment.

The deeper question is what happens to the career pipeline when the first rung disappears. Watterson built a career in marketing because someone gave her a summer job. If that job now goes to an AI tool, the next Watterson does not get the Plaza Hotel moment. She gets a rejection email from an automated screening system that was trained on resumes from people who had internships.

The entry-level pipeline that built millions of careers is not collapsing overnight. It is being squeezed from both sides: fewer positions available and higher expectations for the candidates who fill them. AI is both the cause and the qualification. The tool that replaced the intern is now the skill the intern needs to have.

Get the TNW newsletter

Get the most important tech news in your inbox each week.

What a good website does.

A platform-agnostic specification of the technical features every decent website should have — from <title> to /.well-known/security.txt, from WCAG contrast to llms.txt. Written for humans and agents.

Categories

Ten areas, mapped to widely-accepted standards.

• Foundations

  The HTML, head, and document basics every page needs.

• SEO

  Search visibility — robots.txt, sitemaps, canonicals, structured data.

• Accessibility

  WCAG-aligned rules so people of all abilities can use the site.

• Security

  Headers, transport, and policies that keep visitors safe.

• Well-Known URIs

  Standard, agreed-upon paths under /.well-known/.

• Agent Readiness

  Things that make a site legible to AI agents and crawlers.

• Performance

  Core Web Vitals, caching, images, fonts, network behaviour.

• Privacy

  Consent, signals, and respecting visitor choice.

• Resilience

  Graceful failure — error pages, offline, redirects.

• Internationalisation

  Language, locale, direction, and translated content.

Standards, not opinions

Each topic links back to the source standard — WHATWG, W3C, IETF RFCs, WCAG, MDN, and the organisations defining the modern web.

Platform agnostic

Whether you ship WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, a Django app, or plain HTML, the spec is the spec. Implementation hints follow it, not the other way round.

Built in the open

Every page has an Edit on GitHub link. PRs welcome. Sources credited on every page.

Let your agent query the spec.

The whole spec is available as an open MCP server — read-only, no auth — plus a published Agent Skill that teaches any compatible agent when and how to use it. Per-page Markdown is available via /llms.txt and Accept: text/markdown on any spec URL.

{
  "mcpServers": {
    "specification-website": {
      "transport": "http",
      "url": "https://mcp.specification.website/mcp"
    }
  }
}

How to use this site

1. Audit

   Run through the checklist. Each item is a “does the site do this — yes or no.”

2. Learn

   Click into any item for what it is, why it matters, and how to implement it.

3. Improve

   Found a gap, a stale fact, or a missing topic? Open a PR. Sources required.

Full article content is not available for inline reading.

Read the original article →

OpenClaw's broad system access creates a high-risk security model where untrusted skills or prompt injection can lead to full system compromise. When deployed in standard containers, its reliance on shared-kernel isolation introduces container escape risks, making host takeover and lateral movement possible through kernel exploits, misconfigurations, or exposed privileged interfaces.

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 →

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 →

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 →

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 →

Full article content is not available for inline reading.

Read the original article →

Microsoft looks set to use its Build conference on June 2 in San Francisco to lay the groundwork for the unified Copilot super app it has been building under the internal slogan “Delivering one Copilot.”

Freshly surfaced screenshots provide the clearest look yet at the shell. Earlier views showed the Scout always-on agent within an Autopilot section; two new tabs now complete the picture.

The first is a coding surface with the GitHub Copilot mark, closely mapping to the Claude Code panel in the Claude app. It allows users to pick a work tree, points to both remote environments and local repositories, carries a model selector, lists every repo, and adds Routines, a scheduled-task layer built for code. Sitting atop GitHub Copilot and its millions of paying developers, it could be a real upgrade for teams already standardized on GitHub, especially once Microsoft’s own coding model arrives tuned for GitHub Copilot-specific tool use.

ICYMI: Microsoft is preparing upgrades for image and voice models, too.

The second tab, Cowork, pulls from several sources, aggregates the data, and proposes prompts like preparing for the week from a calendar or researching a company, similar to Copilot’s current document and presentation work. The open question is about local files: the screenshot shows it running in Edge via a URL, so whether it reaches the desktop or remains fully remote is unconfirmed. A sidebar with Library and Projects keeps these jobs apart from plain chat, coding, and Autopilot.

The division matters because the company, with Jacob Andreou now leading Copilot after a reshuffle, is trying to boost weak adoption by folding scattered tools into a single home, just as OpenAI and Anthropic converge on the same always-on, multi-mode pattern. Teams integration hints that Scout could run remotely, the nearest Microsoft may get to the chat-app control that made such agents popular. A nod at Build looks probable, though the app itself is aimed at late summer.

Introducing MiniMax M3: The First Open-Weights Model to Combine Three Frontier Capabilities

• Coding & Agentic Frontier: 59.0% SWE-Bench Pro, 66.0% Terminal Bench 2.1, 34.8% SWE-fficiency, 28.8% KernelBench Hard, 74.2% MCP Atlas
• MiniMax Sparse Attention scales context to 1M
• Natively Multimodal from Step Zero

API: platform.minimax.io

Token Plan: platform.minimax.io/subscribe/toke…

🚀New! MiniMax Code: code.minimax.io

Weights & Tech Report in ~10 Days

API Pricing & Promotion

• 50% off standard usage (≤512K context) during the first 7 days
• Priority access available through: api@minimax.io
• Self-serve access for all users coming in the next few days

Although CES 2026 was a massive disappointment for consumers, Computex 2026 looks to inject some much-needed excitement back into the beleaguered tech space.

In what is arguably the biggest consumer hardware launch of the year, Nvidia and ARM have already started teasing their highly anticipated N1X laptop chip, an APU based on the same GB10 chip used in the DGX Spark. Now, as Jensen prepares to take the stage at Computex next week, let's take a look at what Nvidia has planned for the show.

Nvidia's Laptop Chip Finally Launches, Packing 20 CPU Cores With An RTX 5070 Equivalent GPU

Nvidia, Arm, and Microsoft have taken Twitter by storm recently, with a series of cryptic X posts declaring "A new era of PC", accompanied by coordinates pointing to Taipei Music Center. This obviously refers to the much-anticipated N1X laptop APU, packing 20 ARM cores and 6,144 CUDA cores into a single package, all sharing a unified memory pool over a 256-bit LPPDR5X bus.

In theory, this should put N1X ahead of AMD's strongest APU, but as we've seen with Qualcomm's laptop chips, real-world gaming performance is still hit-or-miss on ARM-based CPUs, not to mention the significant memory bandwidth deficit with LPDDR5X. Another important note is that although the GPU has the same core count as a desktop RTX 5070, power consumption will be significantly lower, so expectations should be kept in check.

Obviously, the real draw with N1X will be the ability to allocate massive amounts of VRAM to the GPU from the shared memory pool. This will allow users to run intelligent, 100B+ parameter LLMs locally, just as we've seen with Strix Halo in its 128GB config. Nvidia's advantage here will be more robust, day-one support for various AI applications, as despite AMD's massive leaps with ROCm recently, CUDA remains king for crucial consumer use cases such as image and video generation.

In terms of partners for this launch, Dell, Lenovo, and ASUS have each either accidentally leaked confirmation of N1X models or hinted at such. HP hasn't teased (or leaked) anything yet, but they'll likely have models available too. Prices are still up in the air, but given that Strix Halo laptops with 128 GB of RAM retail for close to $3k nowadays, I'd expect a figure north of that for equivalently spec'd N1X laptops.

Vera Rubin, Nvidia's Complete "AI Factory" Platform, Rolls Out

Nvidia's next-gen platform for datacenter and AI, "Vera Rubin", has already been hashed out in significant detail by Jensen across multiple events. From Rubin GPUs to Vera CPUs, Nvidia is coming for the whole AI stack and has developed an impressively broad portfolio of products to present a cohesive solution for any workload.

However, even though we probably won't be seeing any new hardware launches for AI datacenters at Computex, there's still bound to be plenty of new details shared by Nvidia. Expect to see Jensen dive deeper into the ecosystem and supply chain that enables Vera Rubin, with partnership announcements and availability windows.

Physical & Agentic AI Take Center Stage

Nvidia has been steadily investing in Physical AI over the years, and it looks like the time is ripe for the company to go all in. With recent developments in Agentic AI, we've finally reached the point where independent agents can reason, act, and operate in the real world thanks to Physical AI.

Or at least, that's what Nvidia's pitch will be; myself, I'm not so sure yet. Regardless, you can expect to hear a lot about how Nvidia's Edge AI platforms, such as Jetson Thor, enable real-time Physical and Agentic AI applications in robotics and autonomous machines, alongside partnership announcements and new applications.

That's Cool And All, But What About Gaming?

In light of recent news that Nvidia has rolled financial reporting for their Gaming business into "Edge Computing", it should come as no surprise that gaming will take a back seat at Computex 2026. Hot off the back of the DLSS 5 controversy, I doubt Nvidia will be too eager to share more details about it, unless they've somehow made massive strides to address the issues gamers had with it since GTC. In terms of new hardware launches, the best we're going to get is N1X, since Blackwell's Super refresh has been indefinitely delayed due to the RAM crisis. Perhaps we'll finally see official confirmation that the RTX 3060 has been revived, as has been rumored for the past couple of months, but I wouldn't expect much more than that.

About the author: Rayan is an aspiring Computer Engineer, currently pursuing his undergraduate studies. He built his first computer in the pandemic, and has been hooked on the hobby ever since. He brings a unique blend of academic knowledge and technical know-how to his articles, which include everything from detailed instructional guides to performance comparisons in wccftech hardware section. When not stressing out over finals or writing articles, you can find him reading fantasy books or hitting the gym.

Follow Wccftech on Google to get more of our news coverage in your feeds.

Further Reading

NVIDIA’s Jensen Huang & AMD’s Lisa Su Touch Down in Taipei as Computex Showdown Looms, Showcasing Next-Gen Technologies

AMD Claims Leadership Tokens/$ With Its Ryzen AI Halo Dev Platform, Tackles NVIDIA’s Spark at $3999 & Pays For Itself Within 6-Months

Origin Code Straps An LCD Screen And Liquid Cooling Onto Its Vortex 48 GB DDR5-6200 Kit Ahead Of Computex 2026

Arm Doubles AGI CPU Revenue Forecast to $2 Billion by 2028 as OpenAI, Cerebras, and Hyperscalers Pile Into Agentic AI Orders

Introducing 1-bit and Ternary Bonsai Image 4B: Image Generation for Local Devices

Today we’re releasing Bonsai Image 4B, a family of compact image-generation models designed to run high-quality diffusion inference on local hardware: from laptops to phones.

Bonsai Image 4B comes in two variants:

• 1-bit Bonsai Image 4B uses binary {−1, +1} transformer weights with an FP16 group-wise scaling factor, giving 1.125 effective bits per weight. It targets maximum compression and is the right fit when memory pressure, bandwidth, and the deployment footprint are the primary constraints.
• Ternary Bonsai Image 4B uses {−1, 0, +1} transformer weights with an FP16 group-wise scaling factor, giving 1.71 effective bits per weight. The additional zero state gives the model more representational flexibility, improving visual quality and prompt fidelity while remaining extremely compact.

The result is a new deployment regime for image generation: capable outputs, open weights, and practical local inference on devices that were previously out of reach for this class of model. To our knowledge, Bonsai Image 4B is the first image model in its parameter class to run directly on an iPhone.

Built for local generation

Local image generation starts with a hard constraint: the model has to fit within the device’s memory budget.

For a 4B-class image model, the diffusion transformer is the largest part of the model and the part that runs repeatedly during generation. Each denoising step invokes the transformer again, so transformer size directly shapes memory pressure, bandwidth demand, and local inference speed.

Bonsai Image 4B is built from the FLUX.2 Klein 4B. It keeps the architecture intact but changes how the transformer weights are represented. By moving those weights into binary and ternary form, Bonsai reduces the part of the image pipeline that matters most for local deployment.

Model	Diffusion Transformer	Reduction vs FP16
FLUX.2 Klein 4B	7.75 GB	1.0x
1-bit Bonsai Image 4B	0.93 GB	8.3x
Ternary Bonsai Image 4B	1.21 GB	6.4x

Table I: Diffusion transformer footprint for models.

The binary layers provide roughly a 14x reduction relative to full-precision transformer weights. A small set of precision-sensitive supporting tensors (~5%), called the projection layers, remains in FP16 so the final 1-bit Bonsai Image 4B transformer is 0.93 GB: an 8.3x reduction from the 7.75 GB full-precision FLUX.2 Klein 4B. 

The ternary variant follows the same structure. Its ternary layers provide roughly a 10x reduction and the final Ternary Bonsai Image 4B transformer is 1.21 GB, a 6.4x reduction from the full-precision transformer. It is slightly larger than the 1-bit model, but the additional zero state improves visual quality and prompt fidelity.

Including the compressed text encoder and FP16 VAE, the Apple Silicon deployment payload is 3.42 GB for 1-bit Bonsai Image 4B and 3.88 GB for Ternary Bonsai Image 4B. For comparison, the full precision FLUX.2 Klein 4B requires a deployment payload of 15.97 GB. Since, at runtime, the text encoder is offloaded after prompt encoding, the mean memory usage is smaller than the total payload. When generating a 512x512 image, the mean-active memory is 1.5 GB and 1.96 GB, for the binary and ternary models, compared to 11.74 GB for the original FLUX.2 Klein 4B (a reduction of 7.8x and 6.0x, respectively). For a 1024x1024 image, the mean-active memory is 1.95 GB and 2.38 GB, for the binary and ternary models, compared to 14.39 GB for the original FLUX.2 Klein 4B (a reduction of 7.4x and 6.0x, respectively).

This reduction in memory footprint changes where the model can run. Our deployment stack supports Apple Silicon iPhones, iPads and Macs and CUDA GPUs, using MLX low-bit paths on Apple hardware and Gemlite low-bit GEMM kernels on CUDA. On iPhone 17 Pro Max, the full-precision FLUX.2 Klein 4B pipeline does not fit within the device memory budget, while both Bonsai Image variants run on-device.

Video I: Image generation on Bonsai Studio

In practice, Bonsai Image 4B generates a 512x512 image in 9.4 seconds on an iPhone 17 Pro Max and about 6 seconds on Mac M4 Pro. On Mac M4 Pro, Bonsai Image 4B is up to 5.6x faster than the stock full-precision MFLUX pipeline. 

Benchmarking performance

Compression only matters if the model remains useful. We evaluated Bonsai Image 4B across three complementary benchmarks: GenEval for object composition and attribute binding; HPSv3 human preference and aesthetic quality; DPG-Bench dense prompt following and semantic faithfulness.

Model	Diffusion Transformer Footprint (GB)	GenEval	HPSv3	DPG-Bench	Size reduction relative to FLUX.2 Klein 4B	Performance relative to FLUX.2 Klein 4B
1-bit Bonsai Image 4B	0.93	0.671	11.15	0.822	8.3x	88%
Ternary Bonsai Image 4B	1.21	0.723	12.22	0.851	6.4x	95%
FLUX.2 Klein 4B	7.75	0.819	12.84	0.853	1x	100%
SDXL	5.14	0.3	10.05	0.74	1.5x	67%
BK-SDM-Small	0.98	0.297	3.05	0.559	7.9x	42%
Stable Diffusion 1.5	1.72	0.396	4.2	0.601	4.5x	51%
PixArt-Σ XL 2	1.2	0.541	11.93	0.769	6.4x	83%

Table II: Image quality benchmark comparison across Ternary Bonsai Image 4B and other models.

Ternary Bonsai Image 4B is the quality-oriented variant. At 1.21 GB, it retains 95% of the FLUX.2 Klein 4B accuracy across GenEval, HPSv3, and DPG-Bench, while reducing the diffusion transformer footprint by 6.4x.

1-bit Bonsai Image 4B is the footprint-oriented variant. It brings the diffusion transformer below 1 GB, an 8.3x reduction, while still delivering strong benchmark scores across the same three evaluations (it retains 88% of the accuracy of FLUX.2 Klein 4B).

Together, the two variants move the quality–footprint frontier. Bonsai Image remains competitive with modern 4B-class image models while using a fraction of their diffusion-transformer footprint. At the same time, it substantially outperforms smaller models with similar memory footprints. That is the same Pareto shift we have seen in our prior Bonsai language models. Bonsai Image brings modern diffusion-transformer behavior into a memory range that previously belonged to much smaller, lower-capability models.

Why this is important

Image generation is not only a model-quality problem. It is also a deployment problem.

Cloud APIs will continue to be the right choice for many products. But cloud-only generation imposes certain product constraints: every prompt is a remote request, every iteration carries marginal serving cost, and every interaction adds round-trip latency.

That matters because image generation is naturally iterative. Users rarely stop at one image. They revise prompts, compare outputs, generate variations, discard failures, and try again. When each attempt is a server-side job, the creative loop becomes something users have to meter and wait for. 

Local inference changes that. Once the model fits on the device, generation can sit directly inside the product experience. It becomes cheaper to run, faster to iterate on, and easier to use in environments where prompts, and generated assets should remain private.

Bonsai Image 4B is a step toward that deployment regime: capable image generation running closer to the user, on hardware they already own.

Availability

Both 1-bit and Ternary Bonsai Image 4B will be released with open weights and code under the Apache 2.0 license. 

With this launch, we are also launching Bonsai Studio, its iOS app for trying Bonsai Image 4B directly on iPhone.

Join Us

PrismML emerged from a team of Caltech researchers and was founded with support from Khosla Ventures, Cerberus and Google. We’ve spent years tackling one of the field’s hardest problems: compressing neural networks without sacrificing their reasoning ability.

If you want to help build the next generation of state-of-the-art AI, we’d love to hear from you. Check out our careers page.

Resources

• Whitepaper
• Hugging Face
• WebGPU demo
• Bonsai Studio for iPhone
• GitHub

PrismML emerged from a team of Caltech researchers and was founded with support from Khosla Ventures, Cerberus and Google. We’ve spent years tackling one of the field’s hardest problems: compressing neural networks without sacrificing their reasoning ability.

If you want to help build the next generation of state-of-the-art AI, we’d love to hear from you. Check out our careers page.

Resources

• Whitepaper
• Hugging Face
• WebGPU demo
• Bonsai Studio for iPhone
• GitHub

pi-dynamic-workflows

Claude-Code-style dynamic workflows for Pi.

A Pi extension that adds a workflow tool. Instead of one assistant doing everything sequentially, the model writes a small JavaScript script that fans out the work across many isolated subagents, then synthesizes the results.

Great for codebase audits, multi-perspective review, large refactors, and fan-out research.

Inspired by Anthropic's dynamic workflows in Claude Code.

Install

pi install npm:pi-dynamic-workflows
# or from a local checkout
pi install /path/to/pi-dynamic-workflows

Then in Pi:

/reload

That's it. The extension registers a workflow tool and activates it on session start.

Usage

Just ask Pi for a workflow in plain language:

Run a workflow to inspect this repository and summarize the main modules.

The model will write a workflow script and call the workflow tool. Live progress shows up inline:

◆ Workflow: inspect_project (3/3 done)
  ✓ Scan 1/1
    #1 ✓ repo inventory
  ✓ Analyze 2/2
    #2 ✓ source modules
    #3 ✓ final summary

Press Esc to cancel a running workflow. Active subagents are aborted and surfaced as skipped.

Workflow script shape

A workflow is plain JavaScript. The first statement must export literal metadata. name and description are required; phases is optional documentation for an expected outline. The live progress view is driven by phase(...) calls at runtime:

export const meta = {
  name: 'inspect_project',
  description: 'Inspect a repository and summarize the main modules',
  phases: [
    { title: 'Scan' },
    { title: 'Analyze' },
  ],
}

phase('Scan')
const inventory = await agent('Inspect the repository structure.', {
  label: 'repo inventory',
})

phase('Analyze')
const summary = await agent(
  'Summarize the main modules from this inventory:\n' + inventory,
  { label: 'module summary' },
)

return { inventory, summary }

Phases are discovered as the script runs, so conditional and loop-created phases work naturally. If a branch is skipped, its phase does not show up as an empty progress row.

Editor IntelliSense

Reusable workflow files can opt into editor hints for workflow globals:

/// <reference types="pi-dynamic-workflows/workflow" />

This declares agent, parallel, pipeline, phase, log, args, cwd, and budget for TypeScript-aware editors.

Available globals

Global	Description
agent(prompt, opts)	Spawn an isolated subagent. Returns its final text or, with opts.schema, a validated object.
parallel(thunks)	Run an array of () => agent(...) thunks concurrently. Results are returned in input order.
pipeline(items, ...stages)	Run each item through sequential stages while items fan out. Each stage receives (prev, original, index).
phase(title)	Mark the current phase. Used for grouping in the live progress view.
log(message)	Append a workflow-level log line.
args	Optional JSON value passed in via the tool's args parameter.
cwd, process.cwd()	Current working directory for subagents.
budget	{ total, spent(), remaining() } token budget tracker.

Determinism rules

Workflow scripts are evaluated inside a Node vm sandbox. The following are intentionally unavailable:

• Date.now(), new Date()
• Math.random()
• require, import, fs, network APIs
• spreads, computed keys, template interpolation, function calls inside meta

This keeps meta parseable, runs reproducible, and the surface area small.

Structured subagent output

Pass a JSON Schema via opts.schema and the subagent will return a validated object:

const finding = await agent('Find security-sensitive files.', {
  label: 'security scan',
  schema: {
    type: 'object',
    properties: {
      paths: { type: 'array', items: { type: 'string' } },
      reason: { type: 'string' },
    },
    required: ['paths', 'reason'],
  },
})

Under the hood this is a Pi structured_output tool with terminate: true, so the subagent ends on that call without an extra assistant turn.

How it works

user prompt
  → Pi model writes a workflow script
  → workflow tool parses + runs script in a vm sandbox
  → script calls agent(), parallel(), pipeline()
  → each agent() spawns an in-memory Pi subagent session
  → snapshots stream back as compact progress
  → final structured result returned to the parent assistant

Subagents run in fresh in-memory Pi sessions with the standard coding tools, so they can read files, run shell commands, and call structured output exactly like a normal Pi turn.

Library modules

File	Purpose
src/workflow.ts	AST-validated parser and sandboxed workflow runtime.
src/workflow-tool.ts	The Pi workflow tool, prompt guidelines, rendering, abort handling.
src/agent.ts	WorkflowAgent, an in-memory Pi subagent runner.
src/structured-output.ts	Terminating structured-output tool backed by TypeBox/JSON Schema.
src/display.ts	Workflow snapshots and compact text renderers.
extensions/workflow.ts	The Pi extension entrypoint.

Development

npm install
npm test     # biome check + tsc + unit tests
npm run dev

Parser unit tests live in tests/workflow-parser.test.ts and cover both accepted and rejected script shapes.

Status

This is a prototype. It implements the core workflow primitive (script, subagents, parallel/pipeline, phases, abort, structured output) but does not yet implement persisted or resumable runs, or a /workflows manager.

License

MIT

xAI's grok-build-0.1 is now in public beta via the API, designed for agentic coding tasks like web development and debugging. The model processes over 100 tokens/second, costing $1 per million tokens in and $2 per million out. It integrates well with platforms like Grok Build, Cursor, and OpenClaw.

Cognition's Ido Pesok shares lessons from building autonomous end-to-end testing into Devin, noting that for the first time, more Devin sessions are now triggered asynchronously than interactively, making verified-before-merge results a hard requirement rather than a nicety. Devin's harness gained computer-use tools roughly six months ago, and the breakthrough came when engineers started running 10-20 Devins in parallel, each with its own dev server, something impossible on a single laptop.

London AI lab Inherent raised $50M from Index Ventures and Radical Ventures to build self-improving AI for scientific discovery. Ex-UK AI tsar Matt Clifford advises.

London-based AI lab Inherent emerged from stealth on Wednesday with a $50 million seed round co-led by Index Ventures and Radical Ventures. Nvidia’s venture arm NVentures also participated, alongside Ex/Ante, Metaplanet, Macroscopic Ventures, and Mythos Ventures. It is among Europe’s largest AI stealth-to-launch rounds in 2026.

The founding team comes from DeepMind, Microsoft, and Reka AI. Tantum Collins and Edward Hughes previously collaborated on cooperative AI research at DeepMind. Louis Kirsch, another co-founder, also worked at DeepMind. Kaloyan Aleksiev came from Reka AI and Microsoft.

Collins has a policy background that most AI lab founders lack. He worked on AI policy at the Biden White House before co-founding Inherent. Matt Clifford, co-founder of Entrepreneurs First and the UK government’s former AI tsar, has joined as an adviser.

Inherent is building a platform called Faraday, named after the scientist. Its purpose is not to answer questions faster. It is to figure out which questions are worth asking in the first place.

“Most AI is built to answer questions. What it can’t do yet is figure out which questions are worth asking, the open-ended curiosity that produced penicillin, the microwave, the GPU,” said Danny Rimer, partner at Index Ventures. “That’s the gap Inherent is building into.”

Faraday pairs human researchers with AI agents that are designed to improve themselves iteratively on hard scientific problems. The company describes this as “AI-native science,” a paradigm it says will look and feel different from the scientific method as practised for the past 400 years.

Index Ventures framed the bet in those terms. “AI-native science will be messier, less legible, but capable of exceptional outcomes,” the firm wrote in a blog post announcing the investment. The conviction is that the most valuable application of frontier AI is not automating existing workflows but enabling discoveries that human researchers could not reach alone.

Inherent is structured as a public benefit corporation, a legal form that requires the company to consider its impact on society alongside shareholder returns. The structure is unusual for a venture-backed AI lab. It signals that the founders view governance as a competitive advantage rather than a constraint.

European AI startups are increasingly demonstrating that they can raise at scales previously reserved for Silicon Valley. Inherent’s $50 million seed sits alongside Peec AI’s $10 million ARR in six months, Lovable’s $100 million single-month revenue, and Mistral’s $300 million ARR. The gap between European and American AI funding is narrowing for companies building in categories where the technology is genuinely new.

Anthropic’s Glasswing project demonstrated that frontier AI can find vulnerabilities at a rate that outpaces human remediation. Inherent’s bet is that the same dynamic applies to scientific discovery: AI agents that can explore hypothesis spaces faster than human researchers can, while humans provide the judgment, taste, and ethical guardrails that agents cannot.

The team’s combination of DeepMind research credentials and White House policy experience gives it unusual positioning. It can credibly pitch to both the scientific establishment and the government institutions that fund basic research. Whether Faraday delivers on the promise of AI-native science will take years to evaluate. The $50 million buys the time to find out.

Get the TNW newsletter

Get the most important tech news in your inbox each week.

OpenAI Robotics is hiring, looking for exceptional full-stack hardware, ops, systems, and ML engineers to help us program and manufacture robots that are useful for society.

AI should be able to help people in the physical world. In the short term, we are focused on robots to support skilled workers to build our future infrastructure; in the long term, we imagine everyone having a personal robot doing anything they need.

Our world simulation research program, led by Aditya Ramesh (@model_mechanic), has evolved over the past year into OpenAI Robotics. Progress is rapid, and based on a foundation of co-design between robotics hardware and ML research.

If you love working hands-on across the robotics stack and want to build the future, please consider joining us. Send an email with your background and evidence of exceptional accomplishment to: robotics-recruiting@openai.com

• • •

Missing some Tweet in this thread? You can try to force a refresh

More from @sama

Sam Altman

@sama Mar 1 I'd like to answer questions about our work with the DoW and our thinking over the past few days. Please AMA.

@natseckatrina who leads some of our national security work is going to jump in to answer some of your questions

@boazbaraktcs is also going to help out with answers!

Sam Altman

@sama Feb 27 We have raised a $110 billion round of funding from Amazon, NVIDIA, and SoftBank.

We are grateful for the support from our partners, and have a lot of work to do to bring you the tools you deserve.

We are excited to partner with Amazon to bring a new generation of products to market, especially around new enterprise products like the stateful runtime environment. We are also very excited to make great use of Tranium.

We continue to have a great relationship with Microsoft. Our stateless API will remain exclusive to Azure, and we will build out much more capacity with them.

Sam Altman

@sama Aug 7, 2025 going to try live-tweeting the GPT-5 livestream.

first, GPT-5 in an integrated model, meaning no more model switcher and it decides when it needs to think harder or not.

it is very smart, intuitive, and fast.

it is available to everyone, including the free tier, w/reasoning!

evals aren't the most important thing--the most important thing is how useful we think the model will be--but it does well on evals. for example, a new high on SWE-bench and many other metrics.

it is by far our most reliable and factual model ever.

rolling out today for free, plus, pro, and team users. next week to enterprise and edu.

making this available in the free tier is a big deal to us; PhD-level intelligence for everyone!

plus users get much higher rate limits.

pro users get GPT-5 pro; really smart!

Sam Altman

@sama Apr 10, 2025 a lot of people were interested in how we made GPT-4.5 and what comes next.

we did a podcast with alex paino, dan selsam, and @atootoon who helped drive the project.

full episode coming soon, but here are some interesting clips:

Sam Altman

@sama Feb 3, 2025 today we launch deep research, our next agent.

this is like a superpower; experts on demand!

it can go use the internet, do complex research and reasoning, and give you back a report.

it is really good, and can do tasks that would take hours/days and cost hundreds of dollars.

people will post lots of great examples, but here is a fun one:

i am in japan right now and looking for an old NSX. i spent hours searching unsuccessfully for the perfect one. i was about to give up and deep research just...found it.

it is very compute-intensive and slow, but it's the first ai system that can do such a wide variety of complex, valuable tasks.

going live in our pro tier now, with 100 queries per month.

plus, team, and enterprise will come soon, and then free tier.

Sam Altman

@sama Sep 12, 2024 here is o1, a series of our most capable and aligned models yet:

o1 is still flawed, still limited, and it still seems more impressive on first use than it does after you spend more time with it. openai.com/index/learning…

but also, it is the beginning of a new paradigm: AI that can do general-purpose complex reasoning.

o1-preview and o1-mini are available today (ramping over some number of hours) in ChatGPT for plus and team users and our API for tier 5 users.

screenshot of eval results in the tweet above and more in the blog post, but worth especially noting:

a fine-tuned version of o1 scored at the 49th percentile in the IOI under competition conditions! and got gold with 10k submissions per problem.

OpenAI published a comprehensive guide on May 28 for conducting trustworthy third-party evaluations of frontier AI models like GPT-5.5.

Multiple leaks point to a Monday reveal of new Nvidia chipsets that will power Windows 11 on Arm-based PCs this year. Nvidia has allegedly created multiple chipset tiers, and Dell, Microsoft, and other hardware makers will allegedly announce new PCs, all timed for the opening day of the Computex conference in Taiwan.

Rumors about Nvidia’s re-entry into PC chipsets–the firm powered the first Arm-based Surface RT laptops back in 2012–have come and gone for years, with many pointing to a secret Microsoft/Qualcomm exclusivity arrangement that’s never been confirmed as the major reason for the delays. And though the most recent reports from earlier this year were curiously more specific and highly confused, it did seem like a release was imminent this year.

Now we have new leaks. And they indicate that we don’t have long to wait to see what Nvidia has in store for Windows 11 on Arm.

Axios reports that Nvidia will “debut the first Windows [11 on Arm] computers that use its chips as the main processor [since 2012].” It will do so with Microsoft, as the chips were designed in partnership with the software giant, which, to date, has closely aligned itself with Qualcomm and its Snapdragon X family of Arm-based chips for PCs.

Axios expects to see new Nvidia-powered PCs from Microsoft Surface and other PC makers, though only Dell is named explicitly. And Microsoft will make related announcements about AI agents running locally on these (and presumably other) PCs, though it’s not clear if that will happen at Computex, Build (which is also getting underway this coming week), or both.

Separately, the Videocardz hardware enthusiast site provides what it says are details about Nvidia’s new PC chips, which will apparently come in two major variants called N1 and N1x, each with two variants comprised of different CPU and CUDA core counts, and different ranges of RAM (8 to 16 GB for the N1 and 16 to 128 GB for the N1x). The N1 chips apparently run at 18 to 45 watts, which makes sense for the thin and light ultra-portable designs typically used with Snapdragon X chips. But the N1X chips allegedly consume 45 to 80 watts, which makes them more suitable for gaming laptops, portable workstations, or even desktop PCs.

It’s not clear how much we can trust that second report, as it mentions that at least one of the documents this information is based on is two years old. But something is happening, and even Nvidia has gotten in on the fun: On Friday, the company cryptically tweeted, “A new era of PC.” So we should know soon.

Tagged with

• Nvidia
• Qualcomm
• Snapdragon X
• Snapdragon X2
• Windows 11 on Arm

DUBLIN — Federal Aviation Administration documents have provided new details about a SpaceX project to develop and test reentry vehicles that could be used to support in-space manufacturing projects.

The FAA on May 15 issued an environmental assessment for test flights of Starfall, an uncrewed reentry vehicle. The FAA also issued a record of decision approving those test flights, concluding that they would not have any significant environmental impacts. The agency did not publicize the findings until it sent out an “FAA Space Update” on May 29.

The documents provide insights into Starfall, which SpaceX has not publicly discussed. Bloomberg first reported on the project last July, describing it as an in-space manufacturing program using capsules that would perform microgravity research and development, then return to Earth.

The FAA documents describe Starfall as serving both in-space manufacturing and point-to-point cargo delivery. The capsules could serve as a “proliferated successor” to the International Space Station to support “a self-sustaining manufacturing economy in space,” the documents state.

“The purpose of SpaceX’s proposal is to (1) enable point-to-point delivery of critical cargo through space on rapid timelines and (2) create a self-sustaining commercial in-space manufacturing market by offering access to microgravity and vacuum, loiter on orbit, and safe return from orbit as a service at scale,” the record of decision states.

The FAA decision approves two reentries of Starfall capsules in the Pacific Ocean about 1,300 kilometers off the coasts of California and Mexico. The capsules would launch on either Falcon 9 or Starship vehicles, going into orbit before reentry or flying a direct suborbital trajectory to the landing zone.

The capsules are disk-shaped, 0.75 meters tall and 3.1 meters in diameter at the top. The capsules have cold-gas attitude control thrusters but no other propulsion system and do not have the ability to deorbit on their own.

The vehicle consists of two parts: a top plate and a heat shield. The top plate is an aluminum structure partially wrapped in an unspecified thermal protection material and weighs 1,400 kilograms. The heat shield is a carbon-fiber structure covered in thermal protection material and also contains nitrogen gas bottles used for the thrusters and other systems. It weighs about 700 kilograms.

The vehicle would slow its descent using a single main parachute, along with pilot and drogue parachutes, with the heat shield jettisoned before splashdown. The FAA documents state that SpaceX will use boats to recover all elements of the spacecraft after splashdown.

The environmental assessment does not state when the test flights would take place and does not provide approvals for additional missions after the two test flights. However, the documents make clear SpaceX sees these as prototypes for spacecraft that would be built in large volumes.

SpaceX “plans to develop a mass producible reentry vehicle that can precisely deliver cargo from space to various locations on Earth, which would be able to launch on either Falcon 9 or Starship,” stated a document developed by contractor KBR that assessed sonic booms from Starfall reentries. That document also noted that Starfall will be able to carry up to 1,000 kilograms of payload in a volume measuring 2.5 by 1.5 by 0.5 meters inside the spacecraft.

Starfall would potentially put SpaceX into competition with companies that rely on SpaceX for launch services. Among them is Varda Space Industries, which has flown six of its W-series spacecraft on SpaceX rideshare missions, performing microgravity research and hypersonics testing with capsules that landed in Utah and Australia.

Inversion, another company developing reentry vehicles, flew its first spacecraft, Ray, on a SpaceX rideshare mission in 2025, but technical issues prevented the spacecraft from reentering as planned. Atmos Space Cargo, a European startup, flew its first reentry vehicle on a SpaceX rideshare mission in 2025 and plans to fly additional missions with SpaceX as well as on European small launch vehicles.

Several other companies, including Catalyx Space, Lux Aeterna and Reditus Space, have also announced plans for reusable spacecraft that would return to Earth and be recovered for reuse, with test flights planned through next year. They are also planning to rely in large part on SpaceX launches.

A tech startup is offering New York City residents free home cleaning with a twist—it will send “professional cleaners” wearing cameras to record everything they do. All that data will supposedly be used to train AI-driven robots.

The unusual pitch comes from the German startup MicroAGI, whose website describes the company as a “team of engineers, researchers, and operators on a mission to accelerate embodied AI.” It began publicizing the free home-cleaning service run through its newly launched Shift app on May 28, with posts on social media sites such as X and LinkedIn featuring a video set to the upbeat piano notes of the Jay-Z and Alicia Keys song “Empire State of Mind.”

The Shift app website claims it “connects New Yorkers with free, trusted professional house cleaners” in exchange for recording “first-person cleaning footage to help train the next generation of household robots.” The “book a free cleaning” link directs clients to enter information such as a phone number, email address, and home address, along with access instructions, before booking an appointment that lasts an estimated two hours.

From a privacy standpoint, the Shift app website’s FAQ states that “names, faces or other personal information is automatically anonymized, with any sensitive details blurred before it’s ever used…. We blur all personally identifiable information from screens and ID cards, to pieces of paper and cell phones to help protect both you and your home.”

The Shift app’s privacy policy says the company uses “advanced machine learning models” running directly on smart glasses or video capture devices to “perform irreversible transformations such as automated face blurring and identifier obfuscation” before any data is uploaded to the company’s cloud servers.

But there is no mention of whether people can ever request that their home cleaning videos be removed from the training datasets for robots. And it’s unclear whether the company’s anonymization techniques are enough to ensure that people’s homes can’t ever be identified when they appear in training datasets.

Although the Shift app website claims “there is no catch” for the free cleaning, the FAQ notes that booking an appointment requires payment information and warns that clients may be charged if they cancel appointments with less than 24 hours’ notice or are not available to let cleaners in at the appointment time. The Shift app terms of service document also seeks to absolve the platform of responsibility for any property damage, theft, or personal injury that may ensue from the cleaning appointments.

The reason behind the promotion

So why would a tech startup offer free cleaning? The first-person cleaning data is supposedly valuable enough for the company to “offer cleaning services free of charge for a limited time” by covering the cost of the professional cleaners, according to the Shift app website. The Shift app’s privacy policy describes the “core of microagi’s business” as “the collection of data for robotics training.”

The temporary free cleaning offer for New York City homes may also serve as a promotional hook for the Shift app’s main purpose—recruiting people to wear a “recording headstrap” to “capture short videos of everyday household or professional tasks” in exchange for supposedly getting paid $20 per hour plus bonuses.

That primary function for the Shift app is briefly highlighted in the promotional video about free home cleanings, which shows US general manager Harry Kilberg claiming the platform already pays “tens of thousands of people” across 15 countries to record daily work and chores.

The main Shift app website, designed to sign up contributors, suggests that more than 10,000 “operators” have already been collectively paid more than $5 million in the first quarter of the 2026 fiscal year.

That makes MicroAGI one of the latest known startups to be recruiting and paying ordinary people to record their everyday tasks to provide robot training data. Other such companies include Encord and Micro1, with the latter having hired thousands of contract workers across 50 countries such as India, Nigeria, and Argentina, according to MIT Technology Review.

The Shift app’s website suggests MicroAGI is launching an aggressive recruiting campaign with dozens of blog posts tailored toward NYC university and college students, teachers, restaurant and delivery workers, and even residents of specific neighborhoods.

Meanwhile, the company has spread Craigslist postings targeting residents of other US cities such as Boston—and MicroAGI founder and CEO Bercan Kilic teased the prospect of the Shift app soon launching in additional cities such as London, Munich, and Zurich.

Things I Think I Think... The New Internet Era

Mulling out loud (and defending) why I think the next few years are a new "Internet Era".

31 May 2026

Unless you are not yet old enough to drink, or lived out in a shack above the treeline in a mountain range, you probably remember to some degree the "Internet Era". Also known as the "Dot-Com Era" (along with its closely-released sequel, the "Dot-Bomb Era"), it was a time when the Internet was new, the boundaries were untested, and everyone's credulity was pushed out to the utter limits.

The reason I bring this up, of course, is that current thinking among AI critics holds that we are on the cusp of a "post-bubble" AI phase. That is to say, the "AI bubble" (which is a real thing, I hold that as axiomatic) is going to pop any day now, and when it does, all kinds of chaos and terribleness is unleashed. However, I draw different conclusions out of the "Dot-Com/Bomb" eras, mostly because (a) I already feel like I know the bubble is going to burst, so I don't have any real questions there, but (b) I want to know what's going to survive the silicon "pop" and what's not. And by "what" I mean "who"--which companies will survive the shift and which won't?

In the early days of the Internet, focus was on the Internet itself. Like it was, on its own, the end goal. Companies were formed to be "E-" companies (anything with an "e" prefix, a la "eBay") or an "I-" company (anything with an "i" prefix, a la "iMac"s, which obviously were a product and not a company but at the moment I can't think of a good "I-" company that's still around). The emphasis was on "The Internet"--whatever the company did, "The Internet" was at the center of it. Everything revolved around "The Internet". Microsoft even famously decided that it was going to put "The Internet" at the centerpiece of its operating system, when it decided to have users "browse their desktop" 1. "The Internet" was going to make everyone a ton of money, and everyone knew it.

And companies responded accordingly, in some cases going so far as to create "Chief Internet Officers". (Not to be confused with its contemporary cousin, the "Chief Web Officer".)

Before I continue on, I'd like to point out that this is not the first time the industry has responded to a new technology by seeking to create a top-level C-suite role for it and then turning to that individual and saying, "Go on! Make it happen!" At the turn of the previous century, the world saw the emergence of the Chief Electricity Officer, a role designed to bring the company in line with the burgeoning field of "electricity".

Funny how we don't have any of those around anymore.

This is because as time progressed, we came to realize that focusing on the technology itself doesn't accomplish much. All of the companies that were formed to focus on the thing--in the most recent example, The Internet--eventually came to realize that the thing is only useful as a means to some other end. OReilly (the book publisher) had a commercial web server product, as competition to Netscape's and Microsoft 2's commercial offerings. Today, the HTTP protocol is so ubiquitous (and, it turned out, simple) that we run HTTP servers out of single-line Python scripts. Just as electricity eventually just became part of the purview of the staff that manage the building's physical presence--and in some buildings, particularly manufacturing operations, that's a nontrivial task, to be sure--and dropped out of the CxO suite accordingly.

Success in either era came only when people realized that "the thing" was nothing more than a means to an end, and established the end accordingly. Electricity helps manufacture things, or helps the staff work more efficiently (consistent lighting) or provides power to automation (washers, dryers, etc). The only people who do anything around the electrical grid itself are commercial power producers, the folks who install solar panels on your roof, and electricians.

Therefore, success in this upcoming era will not be to those who establish "Chief AI Officers", but understand that AI is simply now a (powerful) part of your implementation strategy, and act (and code and staff and train) accordingly. The "moat" isn't AI itself, and the frontier models are never going to be "moaty enough" to keep a decent enough distance from open-source or locally-trained models. Just having a ton of compute available (which both of them don't have, as evidenced by Anthropic having to swallow its pride and sign the deal with Musk/X) isn't enough to keep the wolves at bay.

A couple of notes that I think come out of this:

• Apple survives quite well, given its near total non-engagement with AI thus far.
• Microsoft manages, though will have to do a ton of internal re-orgs to re-re-adjust to the new AI. Likewise for Facebook 3 and Google. Their stock may take a hit, executives may get cycled out for their "bad judgment" (even though a lot of it is being demanded by Boards), but they'll survive. They have other products on which they rely.
• OpenAI and Anthropic will collapse, and quickly get snapped up by somebody else when their value degrades enough to be a "convenient buy". (Honestly, it's too easy to stand up your own "ChatGPT" using open-source tools, and many developers are now seeing "Write your own coding agent harness" as the new Coming-of-Age Trial in the same way we used to think about writing a web server back in the 2000s.) The shift of domains will likely be the biggest public impact, but the economic untangling of all the loans and VC debt could very well be a new "sub-prime"-level banking crater.
• NVidia will never be much more valuable than it is now, because while the massive data centers aren't ever going to happen, the demand for GPUs will certainly continue. However, the manufacture of a GPU is not a relatively hard problem to solve if you're already a chip manufacturer, and Intel/AMD/others have plenty of incentive to retool some supply lines to start building out cheaper (and more importantly, available) GPU lines.

Keep in mind, too, that with the growing public backlash against all things AI (as exemplified by the "boos" at speakers praising AI during graduation speeches), companies whose brand is tightly aligned with AI (which seemed like a great idea in 2025 and a terrible idea for 2027) will likely take PR hits to go along with it all. Apple, Microsoft, Meta, they all have something to be known for beyond their AI efforts; OpenAI and Anthropic, not so much.

---

---

1. Ironically, what subsequent releases later came to demonstrate was that they basically wanted the desktop to be an HTML page. The ironic part here is that this idea is so common now to so many different things--I mean, VSCode, an Electron app, is basically an HTML page with a full-page editor written in Javascript, when you boil away all the plugins--that it really doesn't even make anyone blink anymore, much less file lawsuits with the Department of Justice.

   ↩

2. Microsoft's Internet Information Server is the only one that's even remotely survived, it's now so deeply buried inside the operating system that I don't think anybody even still realizes it exists. It was there, though, last time I popped open the Control Panel and started looking around at the background services that get installed.

   ↩

3. Facebook/Meta's bigger problem appears to be the millions (literally) of lawsuits that are being brought against it for its social media algorithms. Those fines could stack up in a hurry, and the company may end up having to do some serious restructuring or become an acquisition target to survive. The social media website itself will survive, though, it's crossed the Threashold of Immortality by this point.

   ↩

---

Tags: thinking disruption ai llm coding agent code

OpenAI and Anthropic are both spending millions to influence this year's elections.

Full article content is not available for inline reading.

Read the original article →

A compaction pipeline's memory estimates at Mixpanel were causing OOMs and inefficiency due to a crude multiplier model. Replacing it with a simple “last observed value” approach, refined through AI-assisted large-scale analysis, reduced median error by 99% and dramatically improved reliability in production.

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 →

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 →

Full article content is not available for inline reading.

Read the original article →

Agent trigger architecture should be designed around delivery contracts, not a simplistic webhook-vs-polling choice. Webhooks are usually at-least-once, unordered, and best-effort. Polling can blow through rate limits. CDC and message buses offer stronger replay and durability, but still require idempotent handling. Mature agent systems typically combine fast-path events, reconciliation polling or replay, structural idempotency keys, and durable runtimes so long-running agents can survive duplicates, missed events, retries, and external waits.

Instead of synchronously rewriting entire files on every mutation (Copy-On-Write), MOR (Merge-On-Read) appends changes to log files and defers the expensive merge/compaction work to a background process, effectively time-shifting optimization from write time to a separate, controllable schedule. This design better supports high-frequency streaming updates and CDC workloads, though it introduces tradeoffs in read amplification and compaction management.

Full article content is not available for inline reading.

Read the original article →

Apache Iceberg 1.11.0 adds ‘registerView', a metadata-preserving migration primitive that lets catalogs register existing Iceberg views from metadata files instead of recreating them from SQL. The release also adds a dedicated REST Catalog endpoint enabling cleaner authorization, capability signaling, and backward compatibility. This closes a migration gap for catalog-to-catalog moves, DR workflows, blue-green catalog upgrades, and tools like the Apache Polaris Iceberg Catalog Migrator.

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 →

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 →

Full article content is not available for inline reading.

Read the original article →

Enterprise AI agents are struggling due to permissioning issues rather than model performance. Workday addresses this by using its system of record as the governance layer, integrating with Google's Gemini, and emphasizing agent accuracy. This setup ensures agents operate within defined user permissions, crucial for regulated sectors like HR and finance.

Google appears to be lining up a batch of NotebookLM features that have been in the works for months, surfacing quietly in recent builds even as the team drops hints that an announcement may not be far off. Three additions stand out, and together they sketch a clear direction.

as is tradition, NotebookLM’s big update is not on IO day…

Team has cooked.

— Simon (@tokumin) May 24, 2026

The first is Personal Preferences, which debuted in Gemini and is now set to reach NotebookLM. It would let the tool learn from your activity and build editable personas, adjusting tone and technical depth to how you work. While Gemini’s version reaches into Gmail, Drive, Photos, and Calendar, the NotebookLM signals so far lean toward in-app personalization drawn from your notebooks and chats, which is useful for anyone doing repeated, deep-context research.

Allow NotebookLM to use your past interactions (e.g., conversations, artifacts, and customization instructions) to understand your preferences and tailor the experience to your needs. 

Connectors, sitting alongside it in settings, would close that gap. Working much like MCP, it would pull outside data into a notebook, most likely starting with Google’s own services such as Calendar, Gmail, and Drive. The piece is not yet operational, and the roster of supported sources remains open.

Canvas is arguably the headline. Found in the Studio panel, it would turn sources into a custom artifact — an interactive timeline, an explainer web page, a lightweight game, or a visualizer, guided by a prompt describing what you want and how. It extends the outputs that NotebookLM already offers, including infographics, slide decks, data tables, and mind maps.

The combination is where it gets compelling. With NotebookLM now living inside Gemini, the three would let people work across their sources without copying material between tools, matching Google’s push to turn a source-grounded reader into a workspace for building structured, visual experiences on top of documents.

On models, NotebookLM moved to Gemini 3 late last year; with Gemini 3.5 Flash now the global default after I/O 2026, the Flash branch of that family is the natural next base. A firm timeline is still missing, so the open question is when, not whether.

Apple upended the mid-tier traditional wristwatch market after it showed customers the appeal of buying a device that paired with their iPhones, tracked health metrics, and still told the time. The company now sees a similar opportunity with glasses. It plans to target the broader glasses category with products sold between roughly $200 and $500. The eyewear market is valued at roughly $200 billion annually and hundreds of millions of pairs are sold each year. Apple believes that its strong brand, industrial design, and iPhone integration will lead people seeking new glasses to buy from Apple instead.

Interviewing has always been costly for both the company and the candidate. A new type of interviewing is starting to emerge in Silicon Valley. Companies are hiring potential candidates to work with them for a few days with real pay, on real codebases, with the real team. This type of interview provides a strong signal to the company, and it also provides real value to the candidates.

Meta is reportedly working on an AI pendant and more smart glasses

Meta is developing an AI pendant and will start testing it over the coming year, according to The Information. In addition, the company is reportedly gearing up to release up to four more models of smart glasses before the year ends, as part of an aggressive plan to make up for the massive losses of its Reality Labs division, which houses its hardware business.

While Meta has yet to confirm the report, it was pretty much a given that the company would start working on an AI pendant after it purchased Limitless in 2025. Limitless was the maker of an AI device literally called "Pendant," a clip-on Bluetooth microphone that listens and records everything you say or hear throughout the day so it can provide summaries, transcripts and a searchable database of conversations and things you record for yourself. "Meta recently announced a new vision to bring personal superintelligence to everyone and a key part of that vision is building incredible AI-enabled wearables," Limitless CEO Dan Siroker said at the time.

The Information also reports that Meta is planning to expand its AI glasses selection significantly and to launch a business-focused subscription service called "Wearables for Work." Meta's VP for wearables, Alex Himel, reportedly wrote in an internal memo that the goal is to get more people to use the company's AI models and to compel them to pay for subscriptions. That includes subscriptions for Hatch, its unreleased consumer AI agent that's currently under development. (Meta recently launched subscriptions tiers with exclusive features for Instagram, Facebook and WhatsApp, which will test out its new monthly payment system called Meta One.)

The company also wants to expand its smart glasses offerings beyond its collaborations with Ray-Ban and Oakley, Himel wrote in the memo. According to the publication, Meta is debuting a new pair codenamed "Modelo" as soon as June. "Luna" and "RBM2 Refresh," which sounds like another Ray-Ban model, will follow this fall. The last pair that Meta plans to release this year in December is called "Mojito VIP." Meta is also reportedly testing models named "Artemis" and "SSG" (or "supersensing" glasses) for future releases. The new glasses will, of course, be powered by Meta's AI models, along with the unreleased AI agent Hatch.

Hime told employees that Meta's goal is to sell 10 million wearables in the second half of 2026, not just by launching new products, but also by making them available in more countries. The company is aiming to get at least 10 companies to sign up for its Wearables for Work for commercial customers, as well, the publication says. It's targeting deployments to at least two large organizations that need 100 devices each.

Meta's Reality Labs division has been bleeding money for years and lost $19 billion in 2025 alone. Mark Zuckerberg told investors during Meta's earnings call for the fourth quarter of 2025 that the division is going to focus on glasses and wearables going forward, and that the company expects the division's losses to gradually become smaller.

Perfecting robotic hands could unlock many useful forms of automation and also result in better prosthetics for people who need them.

Durable AI workflows can use local SQLite plus Litestream backups instead of heavier orchestration or database infrastructure. The tradeoff is simple, cheap, inspectable state for agents, unless you need high availability or shared scalability, where Postgres still fits better.

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 →

AI image editing is making photo manipulation more accessible by letting users describe changes in plain language instead of learning complex editing tools. However, the process often becomes an iterative negotiation, as AI can misinterpret instructions, introduce unwanted alterations, and gradually degrade image quality through repeated edits, shifting the challenge from mastering software to effectively guiding the machine.

Full article content is not available for inline reading.

Read the original article →

The only true audience for your career is you and those dependent on you.

Ghost buttons significantly reduce website conversions due to their poor visibility and weak call-to-action design. These transparent or outlined buttons fail to grab users' attention compared to solid, contrasting buttons. This post explains how replacing ghost buttons with more prominent designs can dramatically improve conversion rates.

This AI video generator creates professional social media content by blending digital app interfaces with real-world footage.

EZ-Tree is a procedural tree generator that allows you to create realistic 3D tree models with ease.

A museum brand refresh was built around the idea of “Where Art Meets Life,” emphasizing the institution's role as both a cultural destination and a community gathering place. The new identity combines archival elements, a warm and accessible voice, vibrant colors inspired by art and the local environment, and welcoming photography to reflect an experience where art feels personal, inclusive, and deeply connected to everyday life.

The Young Vic's new identity redefines “youth” as energy, movement, and vitality rather than trendiness, replacing its older graffiti-inspired look with a dynamic, motion-blurred logo that feels alive and forward-moving. The visual system balances the theatre's world-class reputation with its rebellious spirit through warm, light-inspired colors, custom typography, and design elements that evoke closeness, momentum, and the immersive connection between performers and audiences.

Raja Nandepu is an Indian environment concept artist and illustrator who creates atmospheric digital art, focusing on mood, light, and storytelling through expressive brushwork and strong color contrasts.