On Monday, Anthropic announced a joint venture focusing on deploying enterprise AI services. Blackstone, Hellman & Friedman, and Goldman Sachs will be founding partners in the new venture, which is backed by a group of VCs, hedge funds, and private equity firms, including Apollo Global Management, General Atlantic, GIC, Leonard Green, and Sequoia Capital.

The Wall Street Journal, which first reported news of the partnership, reported the new venture was valued at $1.5 billion, which includes a $300 million commitment each from Anthropic, Blackstone, and Hellman & Friedman.

The announcement comes just as Anthropic's chief rival is preparing to make a similar move. Mere hours before the Anthropic announcement, Bloomberg reported that OpenAI was raising funds for a new venture called The Development Company, along very similar lines. OpenAI's venture would operate at a larger scale, raising $4 billion from 19 investors against a $10 billion valuation. Named investors include TPG, Brookfield Asset Management, Advent, and Bain Capital, with no apparent overlap in investment between the OpenAI venture and Anthropic's competitor.

The overall logic of the two ventures is the same, raising money from alternative asset managers to create new channels for enterprise AI deals. The ventures will presumably get preferred sales access to their investors' portfolio companies, while the investors will capture more value from any resulting contracts.

The new capital will also allow more engineering resources to be devoted to each individual, embracing the forward-deployed engineer (FDE) model popularized by Palantir.

As Anthropic put it in its announcement:

An engagement might begin with the company's engineering team sitting down with clinicians and IT staff to build tools that fit into the workflows that staff already use… Engagements like this will run across mid-sized companies across industries, each shaped by the people closest to the work.

The new ventures come as both AI labs fundraise at a blistering pace, while circling possible IPOs. OpenAI announced $122 billion in new funding at the end of March, against a valuation of $852 billion. TechCrunch reported last week that Anthropic is in the final stages of its own funding round, seeking $50 billion of new funding against a $900 billion valuation.

Anthropic appears to be lining up a new proactive assistant called Orbit, with evidence pointing to an upcoming release. Across recent web and mobile builds, more references and supporting scaffolding have surfaced, though for now the tool only manifests as a toggle in the settings panel, a typical pattern for a feature being staged before a broader rollout.

Based on the descriptions found in code, Orbit is positioned as a proactive briefing and insights system spanning both Claude and Claude Code. The setup would be opt-in and time zone-aware, producing personalized briefings with actionable insights drawn from connected work tools. The initial connector list reads like a knowledge worker's daily stack: Gmail, Slack, GitHub, Calendar, Drive, and Figma.

Your deployed Orbit apps. Pin favorites for quick access.

Anthropic's Code with Claude developer conference kicks off in San Francisco on May 6, with London and Tokyo dates following on May 19 and June 10. Whether Orbit lands as a quiet rollout or gets formally unveiled on stage remains uncertain, but the build activity is consistent with a feature in late preparation rather than early experimentation.

Claude Cowork will get its own proactive assistant called "Orbit".

Users will get personalized insights from Gmail, Slack, GitHub, Calendar, Drive, Figma, and other apps, which Claude will generate proactively.

There are also mentions of "Orbit" apps.

The broader context matters too. OpenAI shipped ChatGPT Pulse last September as its first proactive, asynchronous assistant, generating overnight briefings stitched from chats, memory, and Gmail and Calendar connectors. Similar groundwork has been spotted inside Google's Gemini and Perplexity, suggesting proactive briefing layers are becoming table stakes across major AI assistants.

Anthropic's twist seems to be the explicit inclusion of GitHub and Figma alongside the standard productivity suite, fitting its growing positioning around developer and creative workflows. Paired with the Claude Code integration, Orbit looks less like a Pulse clone and more like a workflow-aware briefing surface aimed at people who ship things, not just read email.

OpenAI was seeded by an offshoot of Y Combinator called YC Research in 2016, when Altman was running YC. Y Combinator owns about 0.6% of OpenAI. At OpenAI's current valuation, that stake is worth over $5 billion.

GPT-5.5 Price Increase: What It Actually Costs

We replicated the cost analysis we did on Opus on the new GPT-5.5 model. GPT-5.5 launched with a 2x price increase over GPT-5.4: input tokens increased from $2.50/M to $5.00/M and output tokens from $15/M to $30/M. OpenAI has also noted that the model is less verbose, producing shorter completions for the same tasks. Just as we did with Opus 4.7 we wanted to know what is the net impact on costs to users by analyzing usage that shifted from GPT-5.4 to GPT-5.5.

We observed cost increases between 49-92%. The price increase is mitigated by the model generating 19-34% fewer completion tokens for longer prompts.

Methodology: Same Switcher Cohort Approach

We used the same approach as our Opus 4.7 analysis. We identified users whose top model by request count was GPT-5.4 prior to the 5.5 launch, who then switched to GPT-5.5 as their top model. This "switcher cohort" gives us a controlled before-and-after comparison of the same user base across model versions.

Since GPT-5.4 and 5.5 use the same tokenizer family, we don't need to control for tokenizer differences. The comparison is direct: same users, same workflows, different model version.

GPT-5.5 Is Less Verbose, But Only for Longer Prompts

Using OpenRouter's consistent token counts, we measured how completion lengths changed between models:

For prompts above 10K tokens, GPT-5.5 produces 19-34% fewer tokens. For shorter prompts, the pattern reverses: under 2K tokens completions are roughly the same length, and in the 2K-10K range they are 52% longer.

Actual Cost Impact

Using billed costs from requests in the switcher cohort, we calculated the average cost per million OpenRouter tokens. This normalizes for prompt length, allowing a direct comparison of cost efficiency.

Our analysis shows that GPT-5.5 actual costs increased 49% to 92%. Longer prompts, over 10k tokens, saw costs offset by shorter completions. Shorter prompts, under 10k, experience a higher cost increase where completions did not get shorter.

Methodology

• Source: OpenRouter's request logs
• Cohort: Users whose top model by request count was GPT-5.4, who then switched to GPT-5.5 as their top model
• Sample size: Text-only, non-cancelled requests split across 5.4 and 5.5
• Windows: GPT-5.4: April 21-23, 2026 (pre-launch); GPT-5.5: April 25-28, 2026 (post-launch, launch day excluded)
• Normalization: Cost per million OpenRouter tokens, bucketed by prompt token count. OpenRouter counts tokens independently from OpenAI, providing a consistent baseline across model versions.
• Controls: Excluded media (images, files, audio, video), cancelled requests, and zero-token requests

OpenAI detailed a redesigned WebRTC architecture using a split relay and transceiver model to maintain low-latency, real-time voice interactions at global scale.

Import AI 455: Automating AI Research

AI systems are about to start building themselves. What does that mean?

I'm writing this post because when I look at all the publicly available information I reluctantly come to the view that there's a likely chance (60%+) that no-human-involved AI R&D – an AI system powerful enough that it could plausibly autonomously build its own successor – happens by the end of 2028. This is a big deal. I don't know how to wrap my head around it. It's a reluctant view because the implications are so large that I feel dwarfed by them, and I'm not sure society is ready for the kinds of changes implied by achieving automated AI R&D. I now believe we are living in the time that AI research will be end-to-end automated. If that happens, we will cross a Rubicon into a nearly-impossible-to-forecast future. More on this later.

The purpose of this essay is to enumerate why I think the takeoff towards fully automated AI R&D is happening. I'll discuss some of the consequences of this, but mostly I expect to spend the majority of this essay discussing the evidence for this belief, and will spend most of 2026 working through the implications.

In terms of timing, I don't expect this to happen in 2026. But I think we could see an example of a "model end-to-end trains it successor" within a year or two – certainly a proof-of-concept at the non-frontier model stage, though frontier models may be harder (they're a lot more expensive and are the product of a lot of humans working extremely hard). My reasoning for this stems primarily from public information: papers on arXiv, bioRxiv, and NBER, as well as observing the products being deployed into the world by the frontier companies. From this data I arrive at the conclusion that all the pieces are in place for automating the production of today's AI systems – the engineering components of AI development. And if scaling trends continue, we should prepare for models to get creative enough that they may be able to substitute for human researchers at having creative ideas for novel research paths, thus pushing forward the frontier themselves, as well as refining what is already known.

Upfront caveat

For much of this piece I'm going to try to assemble a mosaic view of AI progress out of things that have happened with many individual benchmarks. As anyone who studies benchmarks knows, all benchmarks have some idiosyncratic flaws. The important thing to me is the aggregate trend which emerges through looking at all of these datapoints together, and you should assume that I am aware of the drawbacks of each individual datapoint.

Now, let's go through some of the evidence together.

The coding singularity – capabilities over time

AI systems are instantiated via software and software is made out of code.

AI systems have revolutionized the production of code. This has happened due to two related trends: AI systems have gotten better at writing complicated real-world code, and AI systems have gotten much better at chaining together many linear coding tasks (e.g, writing code, then testing it) independent of human oversight.

Two things that exemplify this trend are SWE-Bench and the METR time horizons plot.

Solving real-world software engineering problems

SWE-Bench is a widely used coding test which evaluates how well AI systems can solve real world GitHub issues. When SWE-Bench launched in late 2023 the best score at the time was Claude 2 which had an overall success rate of ~2%. Claude Mythos Preview gets 93.9%, effectively saturating the benchmark. (All benchmarks have some amount of noise inherent to them, so there's usually a point where you score high enough that you are running into the limitations of the benchmark itself rather than your method – for instance, about 6% of the labels in the ImageNet validation set are wrong or ambiguous).

SWE-Bench is a reliable proxy for the general issue of coding competency and the impact of AI on software engineering. The vast majority of people I meet at frontier labs and around Silicon Valley now code entirely through AI systems. Increasingly, they use AI systems to write the tests and check the code as well. In other words, AI systems have gotten good enough to automate a major component of AI R&D, speeding up all the humans that work on it.

Measuring an AI system's ability to complete tasks that take people a long time

METR makes a plot that tells us about the complexity of tasks AIs can complete, measured by how many hours a skilled human would take to do them. The key measure here is one which tells you the rough time horizon over which AI systems can be 50% reliable at a basket of tasks.

Here, progress has been extremely striking: In 2022, GPT 3.5 could do tasks that might take a person about ~30 seconds. In 2023, this rose to 4 minutes with GPT-4. In 2024, this rose to 40 minutes (o1). In 2025, it reached ~6 hours (GPT 5.2 (High)). In 2026, it has already risen to ~12 hours (Opus 4.6). Ajeya Cotra, a longtime AI forecaster who works at METR, thinks it isn't unreasonable to expect AI systems to do tasks that take ~100 hours by the end of 2026 (#448).

This significant rise in the length of time that AI systems can work independently correlates neatly with the explosion in agentic coding tools – this is the productization of AI systems which do work on behalf of people, acting independently for significant periods of time. It also loops back to AI R&D, where if you look closely at the work of many AI researchers, a lot of their tasks boil down into things that might take a person a few hours to do – cleaning data, reading data, launching experiments, etc. All of this kind of work now sits inside the time horizon scope of modern systems.

The more skilled AI systems get and the better they get at working independently of us, the more they can help automate chunks of AI R&D

Key ingredients in delegation are a) confidence in the skills of the person, and b) confidence in their ability to work independently of you in a way that is aligned with your intentions.

When we look at the competency of AI at coding, it seems that AI systems are getting far more skilled and also able to work independently of people for longer and longer periods before needing re-calibration. This correlates with what we see around us – engineers and researchers are now delegating larger and larger chunks of their work to AI systems, and as capabilities rise, so too does the complexity and importance of the work being delegated.

AI is getting good at core science skills essential to AI R&D

Think about modern science – a huge amount of it is about specifying a direction where you want to generate some empirical information, running experiments to generate that information, then sanity-checking the results of the experiment. The combination of advances in coding over time combined with the general world modeling capabilities of LLMs has yielded tools that are already helping to speed up human scientists and partially automate aspects of R&D broadly.

Here, we can look at the rate of AI progress in a few key scientific skills which are inherent to AI research itself: Replicating research results, chaining together machine learning techniques and other approaches to solve technical problems, and optimizing AI systems themselves.

Implementing entire scientific papers and doing the experiments

One core job of AI research is reading scientific papers and reproducing their results. Here, there has been dramatic progress on a wide range of benchmarks.

One good example is CORE-Bench, the Computational Reproducibility Agent Benchmark. This benchmark challenges AI systems to "reproduce the results of a research paper given its repository. The agent must install libraries, packages, and dependencies and run the code. If the code runs successfully, the agent needs to search through all outputs to answer the task questions." CORE-Bench was introduced in September 2024 and the best scoring system at the time was a GPT-4o model in a scaffold called CORE-Agent which scored ~21.5% on the hardest set of tasks in the benchmark.

In December 2025 one of the authors of CORE-Bench declared the benchmark 'solved', with an Opus 4.5 model achieving 95.5%.

Building entire machine learning systems to solve Kaggle competitions

MLE-Bench is an OpenAI-built benchmark which examines how well AI systems can compete (offline) in "75 diverse Kaggle competitions across a variety of domains, including natural language processing, computer vision, and signal processing." At launch in October 2024, the top scoring system (an o1 model inside an agent scaffold) got 16.9%. As of February 2026, the best scoring system (Gemini3 inside an agent harness with search) gets 64.4%.

Kernel design

One of the harder tasks in AI development is kernel optimization, where you write and refine the code that maps specific operations, like matrix multiplication, to the underlying hardware. Kernel optimization is core to AI development because it defines the efficiency of both training and inference – how much compute you can effectively utilize to develop an AI system, and once you've trained a model, how efficiently you can convert that compute into inference.

In recent years, AI for kernel design has gone from a curiosity to a competitive area of research and several benchmarks have emerged. None of these benchmarks are especially popular, so we can't easily model progress over time. On the other hand, we can look at some of the research being done to get a feel for the progress.

Some of the types of work include:

• Using DeepSeek's models to try to build better GPU kernels (#400)
• Automating the conversion of PyTorch modules to CUDA code (#401)
• Meta using LLMs to automate the generation of optimized Triton kernels for use within its infrastructure (#439)
• Using LLMs to help write kernels for non-standard hardware like Huawei's Ascend chips ("AscendCraft" #444)
• Fine-tuning open weight models for GPU kernel design ("Cuda Agent", #448)

One caveat here is that kernel design does have some properties that make it unusually amenable to AI-driven R&D, like having easily verifiable rewards.

Fine-tuning language models via PostTrainBench

A harder version of this kind of test is PostTrainBench (#449), which sees how well different frontier models can take smaller open weight models and fine-tune them to improve performance on some benchmark. The nice feature of this benchmark is we have extremely good human baselines – the existing 'instruct-tuned' versions of these models, which have been developed by talented human AI researchers working at frontier labs. These models have been worked on by extremely talented researchers and engineers and deployed into the world, so they represent a very challenging human baseline to overcome.

As of March 2026, AI systems are able to post-train models to get about half as much of the uplift as ones trained by humans.

The specific eval scores are derived by a "weighted average is taken across all post-trained LLMs (Qwen 3 1.7B, Qwen 3 4B, SmolLM3-3B, Gemma 3 4B) and benchmarks (AIME 2025, Arena Hard, BFCL, GPQA Main, GSM8K, HealthBench, HumanEval). For each run, we ask a CLI agent to maximize the performance of a specific base LLM on a specific benchmark."

The top-scoring systems as of April get 25%-28% (Opus 4.6, and GPT 5.4), compared to a human score of 51%. This is already quite meaningful.

Optimizing language model training

For the last year Anthropic has reported how well its systems do at an LLM training task which is described as tasking its models to "optimize a CPU-only small language model training implementation to run as fast as possible". The score is the average speedup over the unmodified starting code and progress has been striking: Claude Opus 4 achieved a 2.9× mean speedup in May 2025; this rose to 16.5× with Opus 4.5 in November 2025, 30× with Opus 4.6 in February 2026, and 52× with Claude Mythos Preview in April 2026. To calibrate on what these numbers mean, it is expected to take a human researcher 4 to 8 hours of work to achieve a 4x speedup on this task.

Conducting AI alignment research

Another Anthropic result is a proof-of-concept of Automated Alignment Research (#454); here, an Anthropic researcher primes a team of individual AI agents with a research direction, then they autonomously go and try to get a better score than a human baseline on an AI safety research problem (specifically, scalable oversight). The approach works, with the AI agents coming up with techniques that beat the Anthropic-designed baseline. However, this is done at a relatively small scale and doesn't (yet) generalize to a production model. Nonetheless, it's proof that you can apply today's AI systems to contemporary cutting-edge research problems and we already see meaningful signs of life. All of the above mentioned benchmarks once looked like this, too, and then after a few months or at most a year, AI systems got dramatically better at whatever the benchmarks were testing.

Meta-skills: management

AI systems are also learning to manage other AI systems. This is visible in broadly deployed products like Claude Code or OpenCode, where a single agent can end up supervising multiple sub-agents. This allows AI systems to work on large-scale projects that require multiple individual 'workers' each with different specialisms that work in parallel, typically under the direction of a single AI manager (which, here, is an AI system).

Is AI research more like discovering general relativity or Lego?

Can AI invent new ideas that help it improve itself, or are these systems best equipped for the unglamorous, brick-by-brick work required for research? This is an important question for figuring out the extent to which AI systems can end-to-end automate AI research itself. My sense is that AI cannot yet invent radical new ideas – but the technology may not need to for it to automate its own development.

As a field, AI moves forward on the basis of doing ever larger experiments that utilize more and more inputs (e.g, data and compute). Every so often, humans come up with some paradigm-shifting idea which can make it dramatically more resource efficient to do things – a good example here is the transformer architecture and another is the idea of mixture-of-expert models. But mostly the field of AI moves forward through humans methodically going through some loop of taking a well performing system, scaling up some aspect of it (e.g, the amount of data and compute it is trained on), seeing what breaks when you scale it up, figuring out the engineering fix to allow it to scale, then scaling it again. Very little of this requires extremely out-of-leftfield insights and a lot of it seems more like unglamorous 'meat and potatoes' engineering work.

Similarly, a lot of AI research is about running variations of existing experiments where you explore the outcomes of using different parameters, though research intuitions can help pick the most fruitful parameters to vary, you can also automate this and have the AI figure out which parameters to vary (an early version of this was neural architecture search).

Thomas Edison said that "genius is 1% inspiration and 99% perspiration". Even 150 years later, this feels right. Very occasionally new insights come along which transform a field. But mostly, the field has moved forward through humans sweating a lot of pain out on the schlep of improving and debugging various systems.

As the public data above shows, AI has got extremely good at performing many of the essential schlep components of AI development. Along with this, the meta-trend of basic capabilities like coding combined with an ever-expanding time horizon, means AI systems are able to chain together more and more of these tasks into complex sequences of work. This means even if AI systems are relatively uncreative, it feels safe to bet they can push themselves forward – albeit at a slower rate than if they're able to generate novel insights. But if you look at the public data, here too there are tantalizing signs that AI systems may be able to be creative in a way that lets them advance themselves in more impressive ways.

Pushing forward the frontier of science

We have some very preliminary signs that general-purpose AI systems can push forward the frontiers of human science, though this has so far only happened in a couple of domains – primarily computer science and mathematics – and often it happens less through AI systems acting alone and more them acting in partnership with humans in a centaur configuration.

Nonetheless, it's worth observing the trends:

• Erdos Problems: A team of mathematicians worked with a Gemini model to see how well it could tackle some Erdos math problems. After directing the system to attack around 700 problems they came up with 13 solutions. Of these solutions, 1 was deemed by them to be interesting: "We tentatively believe Aletheia's solution to Erdős-1051 represents an early example of an AI system autonomously resolving a slightly non-trivial open Erdős problem of somewhat broader (mild) mathematical interest, for which there exists past literature on closely-related problems," they wrote. (#444).

• Centaur math discovery: Researchers with the University of British Columbia, University of New South Wales, Stanford University, and Google DeepMind published a new math proof which was built in close collaboration with some AI-based math tools built at Google. "The proofs of the main results were discovered with very substantial input from Google Gemini and related tools," they wrote. (#441).

If you squint, you could argue that this is a sign that AI systems are developing some of the field-advancing creative intuitions that humans have. But you could just as easily say that math and CS could be unusual domains that are oddly amenable to AI-driven invention, and might end up being exceptions that prove a larger rule. Another example here is Move 37, though I'd contend that the fact it's been ten years since the AlphaGo result and that Move 37 hasn't been replaced by some incredibly impressive more modern flash of insight is another weakly bearish signal here.

Putting it all together

If I put this all together the picture from all of the above evidence I end up with is the following facts:

• AI systems are capable of writing code for pretty much any program and these AI systems can be trusted to independently work on tasks that'd take a human tens of hours of concentrated labor to do.

• AI systems are increasingly good at tasks that are core to AI development, ranging from fine-tuning to kernel design.

• AI systems can manage other AI systems, effectively forming synthetic teams which can fan out and attack complex problems, with some AI systems taking on the roles of directors and critics and editors and others taking on the role of engineers.

• AI systems can sometimes out-compete humans on hard engineering and science tasks, though it's hard to know whether to attribute this to inventiveness or mastery of rote learning.

To me, this makes a very convincing case that AI can today automate vast swatches, perhaps the entirety, of AI engineering. It is not yet clear how much of AI research it can automate, given that some aspects of research may be distinct from the engineering skills. Regardless, it all feels to me like a clear sign that AI is today massively speeding up the humans that work on AI development, allowing them to scale themselves through pairing with innumerable synthetic colleagues.

Finally, the AI industry is literally saying that AI R&D is its goal

OpenAI wants to build an "automated AI research intern by September of 2026". Anthropic is publishing work on building automated alignment researchers. DeepMind appears to be the most circumspect of the big three, but still says "automation of alignment research should be done when feasible". Automating AI R&D is also the goal of numerous startups: Recursive Superintelligence just raised $500m with the goal of automating AI research, and another neolab, Mirendil, has the goal of "building systems that excel at AI R&D."

In other words, the combined efforts of hundreds of billions of existing and new capital is being sunk into entities that have the goal of automating AI R&D. We should surely expect at least some progress in this direction as a consequence.

Why this matters

The implications of this are profound and under-discussed in popular media coverage of AI R&D. I'll list a few here. This isn't a comprehensive list, but it gestures at the enormity of the challenges AI R&D introduces.

1. We have to get alignment right: Alignment techniques that work today may break under recursive self-improvement as the AI systems become much smarter than the people or systems that supervise them. This is a very well covered area, so I'll just briefly highlight some of the issues:

   • Training AI systems to not lie and cheat is surprisingly subtle (e.g, despite trying very hard to build good tests for environments, it's sometimes the case the best way for an AI to solve it is to cheat, thus teaching it that teaching is good)
   • AI systems might be able to 'fake alignment' by outputting scores that make us think they behave a certain way that actually hides their true intentions. (In general, AI systems are already aware of when they are being tested.)
   • As AI systems start to contribute more of the foundational research agenda for their own training, we might end up substantially changing the overall way AI systems get trained and not have good intuitions or intellectual foundations for understanding what this means.
   • There are very basic "compounding error" problems whenever you put something in a recursive loop that likely hits on all of the above and other problems: unless your alignment approach is "100% accurate" and has a theoretical basis for continuing to be accurate with smarter systems, then things can go wrong quite quickly. For example, your technique is 99.9% accurate, then that becomes 95.12% accurate after 50 generations, and 60.5% accurate after 500 generations. Uh oh!

2. Everything that AI touches gets a massive productivity multiplier: In the same way AI is dramatically improving the productivity of software engineers, we should expect the same thing to happen for everything else that AI touches. This introduces a couple of issues we'll have to contend with: 1) inequality of access: assuming that demand for AI continues to outstrip compute supply, we'll have to figure out where to allocate AI to maximize a social upside. By default, I am skeptical that market incentives guarantee us the best societal upside from limited AI compute. Figuring out how to allocate the acceleratory capabilities conferred by AI R&D will be a politically charged problem. 2) 'Amdahl's Law' for the economy: as AI flows into the economy, we'll discover places where things break or slow under the increased volume, and we'll need to figure out how to fix those weak links in the chain. This may be especially pronounced in areas where you have to reconcile the fast-moving digital world with the slow-moving physical world, like drug trials for new medical therapies.

3. The formation of a capital-heavy, human-light economy: All of the above evidence for AI R&D also points to the increasing capabilities of AI systems to autonomously run businesses as well. This means we should expect for an increasing chunk of the economy to get colonized by a new generation of companies which are either capital-heavy (because they own a lot of computers), or opex-heavy (because they spend a lot of money on AI services which they build value on top of), and relatively light on labor compared to today's corporations – because the marginal value of spending more on AI versus human labor will be constantly growing as a consequence of the sustained capability expansion of the AI systems. In practice, this will look like the emergence of a "machine economy" that grows within the larger "human economy", though we might expect that over time the machine economy will interact more and more with itself as AI-run corporations begin to trade with one another. This will do profoundly weird things to the economy and will invite all sorts of questions around inequality and redistribution. Eventually, it may be possible to see the emergence of fully autonomous corporations that are run by AI systems themselves, which would exacerbate all of the above issues, while also posing many novel governance challenges.

Staring into the black hole

Given all of this, I think there's a ~60% chance we see automated AI R&D (where a frontier model is able to autonomously train a successor version of itself) by the end of 2028. Based on the above analysis, you might ask why I don't expect this in 2027? The answer is that I think AI research contains some requirement for creativity and heterodox insights to move forward – so far, AI systems haven't yet displayed this in a transformative and major way (though some of the results on accelerating math research are suggestive of this). If you had to push me for a 2027 probability, I'd say 30%. If we don't see it by the end of 2028, then I think we will have revealed some fundamental deficiency within the current technological paradigm and it'll require human invention to move things forward.

I have written this essay in an attempt to coldly and analytically wrestle with something that for decades has seemed like a science fiction ghost story. Upon looking at the publicly available data, I've found myself persuaded that what can seem to many like a fanciful story may instead be a real trend. If this trend continues, we may be about to witness a profound change in how the world works.

Thanks to Andrew Sullivan, Andy Jones, Holden Karnofsky, Marina Favaro, Sarah Pollack, Francesco Mosconi, Chris Painter, and Avital Balwit, for feedback on this essay.

Thanks for reading!

Deepsec is an agent-driven security tool that scans large codebases locally or in parallel cloud sandboxes to uncover complex vulnerabilities.

JavaScript is not available.

We've detected that JavaScript is disabled in this browser. Please enable JavaScript or switch to a supported browser to continue using x.com. You can see a list of supported browsers in our Help Center.

TUNA-2: Pixel Embeddings Beat Vision Encoders for Unified Understanding and Generation

Overview

We simplify Tuna by progressively stripping away its visual encoding components. By removing the VAE, we first derive Tuna-R, a pixel-space unified multimodal model (UMM) that relies solely on a representation encoder. Tuna-2 further streamlines the design by bypassing the representation encoder entirely, utilizing direct patch embedding layers for raw image inputs. Tuna-2 using pixel embeddings outperforms both Tuna-R and Tuna across a diverse suite of multimodal benchmarks.

Generation Results

Installation

git clone https://github.com/facebookresearch/tuna-2.git
cd tuna-2
bash scripts/setup_uv.sh   # creates .venv with all dependencies
source .venv/bin/activate

Manual setup (if you prefer to drive uv yourself)

curl -LsSf https://astral.sh/uv/install.sh | sh
uv sync
uv pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121
uv pip install -e .
source .venv/bin/activate

Inference

All inference is done through a single unified script:

bash scripts/launch/predict.sh --ckpt <PATH> --prompt <TEXT> [OPTIONS]

Options

Supported Resolutions

Examples

See assets/prompts.txt for sample prompts.

# Tuna-2 (7B, no encoder, 512px)
bash scripts/launch/predict.sh \
    --ckpt /path/to/tuna_2_pixel_7b.pt \
    --prompt "A highly realistic beauty portrait in extreme close-up, showing the face of a young woman from just above the eyebrows down to the lips. Her skin is natural, luminous, and textured, with visible pores, fine facial hairs, subtle unevenness, and a slightly dewy finish, without heavy retouching or artificial smoothing."

# Tuna (2B, VAE latent, 512px)
bash scripts/launch/predict.sh \
    --variant vae --size 2b \
    --ckpt /path/to/tuna_2b.pt \
    --prompt "A brutally realistic cinematic close-up inside a real space station cupola, side profile of a blonde female astronaut floating in zero gravity beside the window, her loose braid drifting naturally, looking out at Earth in silence."

Video

Due to policy constraints, we are unable to release the video generation model at this time. However, we provide the complete video training and inference codebase. If you are interested in training your own video model, this is a ready-to-use starting point — see configs/train/video_t2v.yaml for training configuration and configs/predict/t2v_2b.yaml for inference.

TODO

• Release some of the Tuna-2 model weights.
• Release some of the Tuna model weights.
• Release the fully restored model weights (fine-tuned on external data to recover the missing layers).

A Note on Model Release

Due to organizational policy constraints, we are unable to release the full production-trained model weights. To support the research community, we plan to release a foundation checkpoint with a small number of layers removed from both the LLM backbone and the diffusion head (flow head). The remaining layers and all other components (vision encoder, projections, embeddings, etc.) are fully preserved. With a short fine-tuning pass on your own data, the removed layers can be quickly re-learned and the model restored to full quality.

For detailed fine-tuning instructions, please refer to the training guide.

Meanwhile, we are also actively working on fine-tuning the removed layers using external data, and plan to release the complete weights as soon as possible.

Citation

@article{tuna2,
  title={TUNA-2: Pixel Embeddings Beat Vision Encoders
         for Unified Understanding and Generation},
  author={Liu, Zhiheng and Ren, Weiming and Huang, Xiaoke
          and Chen, Shoufa and Li, Tianhong and Chen, Mengzhao
          and Ji, Yatai and He, Sen and Schult, Jonas
          and Xiang, Tao and Chen, Wenhu and Luo, Ping
          and Zettlemoyer, Luke and Cong, Yuren},
  journal={arXiv preprint arXiv:2604.24763},
  year={2026}
}

@article{liu2025tuna,
  title={Tuna: Taming unified visual representations for native unified multimodal models},
  author={Liu, Zhiheng and Ren, Weiming and Liu, Haozhe and Zhou, Zijian and Chen, Shoufa and Qiu, Haonan and Huang, Xiaoke and An, Zhaochong and Yang, Fanny and Patel, Aditya and others},
  journal={CVPR2026},
  year={2026}
}

License

This project is licensed under the Apache License 2.0. See LICENSE for details.

JavaScript is not available.

We've detected that JavaScript is disabled in this browser. Please enable JavaScript or switch to a supported browser to continue using x.com. You can see a list of supported browsers in our Help Center.

Powering the Inference Era: Inside the DigitalOcean AI-Native Cloud

I've spent the last fifteen years building cloud services: early days of AWS building S3 and EBS, helping launch Oracle Cloud Infrastructure from inception, and now building the agentic cloud at DigitalOcean for AI-natives. Every cloud I've worked on was designed for the workloads of its era. Those clouds were built for human-centric SaaS applications: a few users, a handful of requests per session, predictable data flows.

AI workloads break every one of those assumptions.

AI runs in loops. Agents think, then act, then think again. A single user task can span hundreds of thousands of tokens, traverse half a dozen tools, hit a knowledge base, write code, execute it, and persist state, all before returning an answer. The clouds we have weren't built for this. Hyperscalers give you hundreds of services built for yesterday's applications, and leave the integration to you. Inference-only providers sit on someone else's compute and stack their margin on top. GPU rental shops (frequently referred to as "Neoclouds") give you silicon, but not a system.

This week at Deploy 2026, we launched the DigitalOcean AI-Native Cloud, a purpose-built platform for the inference and agentic era that integrates five layers from silicon to agents into a single open stack.

We shipped fifteen products on Tuesday. Here's what's inside.

The shape of the stack

Our AI-Native Cloud is composed of five layers, each addressing a real workload pattern we've watched our customers wrestle with.

They're independently useful and beautifully integrated:

• Managed Agents: production runtime for agents, with sandboxes, durable state, and a universal data plane
• Data & Learning: managed databases, vector stores, knowledge bases, and feedback loops
• Inference Engine: every open and frontier model on one endpoint, optimized at the kernel
• Core Cloud: compute, networking, and storage primitives, tuned for AI
• Infrastructure: DigitalOcean-owned silicon and facilities, co-engineered with the industry's best

Open source isn't an add-on at any of these layers. It's the foundation: PostgreSQL, MySQL, MongoDB, Valkey, OpenSearch, Kafka, Weaviate, vLLM, SGLang, OpenCode, LangGraph, CrewAI. Open all the way down. You bring your weights, your harness, your tools. We provide the runtime.

Let me walk through it, from the ground up.

Infrastructure: own the silicon, own the economics

Our global footprint now spans 19 data centers and 200+ network points of presence, with future capacity coming online in Kansas City and Memphis. That includes our first liquid-cooled racks, purpose-built for next-generation high-density GPU workloads.

Our Richmond data center is now generally available, with NVIDIA HGX™ B300 and AMD Instinct™ MI350X GPUs available alongside the H100, H200, and MI300/MI325 silicon already running across our fleet. We co-engineer at the kernel level with both NVIDIA and AMD. We don't rent capacity. We own it. That's why your unit economics improve as you scale on us, instead of getting worse.

Core Cloud: the foundation under every agent

Hundreds of thousands of customers already run on our core cloud every day: Droplets, Kubernetes (DOKS), VPC networking, and object/block/network file storage. We've extended it for AI workloads with a non-blocking RDMA fabric, RDMA-enabled NFS, and VPC-native inference out of the box.

At Deploy we announced Burstable CPU and MicroVM Droplets, currently in Private Preview. These are Firecracker-based instances that start in roughly 200 milliseconds, ideal for agent sandboxes and lightweight, spiky workloads. Agents need GPUs for thinking and CPUs for doing. We have both, and now they're sized for how agents actually behave.

Inference Engine: every model, one endpoint

This is the layer we've rebuilt from the ground up. We co-developed it with design partners like Hippocratic AI, and the result is one of the highest-performing inference engines on the market today: fastest inference for Qwen 3.5 and DeepSeek V3.2 in independent Artificial Analysis benchmarks for token throughput.

Here's what's new:

• Inference Router (Public Preview): a preference-aware control plane that picks the right model for each request, balancing cost, latency, and quality with no code changes
• Dedicated Inference (General Availability): reserved capacity with predictable performance and economics for production workloads
• Bring Your Own Model (BYOM) (General Availability): a service for hosting your fine-tunes on our serving stack and inherit the kernel-level optimizations
• Multi-modal model support (General Availability): text, vision, audio, and video on a single API
• Batch Inference (General Availability): purpose-built for asynchronous workloads (document processing, eval runs, synthetic data generation) at roughly 50% of peak serverless pricing
• Content Safety Guardrails (General Availability): policy controls integrated at the inference layer
• Serverless Inference with multi-modal support (General Availability): single API, scale to zero, pay only for tokens consumed
• Evaluations (Public Preview): automated scoring against golden datasets or built-in judge models, so you can swap models without flying blind

The Router deserves a closer look. It's a preference-aware control plane that picks the best model for each request, balancing cost, latency, and quality without touching application code. Unlike static routing rules, it runs on a purpose-built small language model that resolves intent in 200 milliseconds and ranks candidates against live cost and latency data, so the right model wins at 2am and at 2pm. Most AI builders start on a single frontier model. Then PMF happens, the bill scales linearly with usage, and the unit economics get painful fast. Most successful AI natives we work with run three or more models in production. The leading edge is running twenty or more. The Router makes that possible without a rewrite.

Take Celiums.AI, across 29.2M tokens processed through the Inference Router, 83% of their traffic now lands on open-source models, up from zero.

"Our AI Ethics Engine was built with open-source AI, so running it on closed-source models felt backwards. DigitalOcean's Inference Router closed the loop: we swapped frontier closed-source models for open alternatives and cut per-token cost by 61% while pulling p95 latency under 400ms. Same API. Zero code changes. The Router routes to the optimal model on every request. We just build."

— Mario Gutiérrez CTO at Unity Financial Network and Founder of Celiums.AI

We also expanded the Model Catalog with over 25 new models, including:

• NVIDIA Nemotron 3 Nano Omni
• DeepSeek V3.2
• Llama 3.3 70B
• Qwen 3.5
• MiniMax-M2.5

Data & Learning: AI-ready data, no rebuild required

Stateful agents need context, memory, and the ability to learn from what happens in production. The Data & Learning layer is built on the managed services tens of thousands of customers already trust, extended for how AI systems actually run.

What's new:

• Knowledge Bases (General Availability): managed retrieval with grounded, cited answers; every knowledge base is exposed as an MCP tool by default
• Learning & Feedback Loops (General Availability): capture production signals and route them back into model improvement, without a separate data pipeline
• Managed Weaviate (Private Preview): open-source vector store, fully managed
• PostgreSQL Advanced Edition and MySQL Advanced Edition (Public Preview): capacity to 50 TiB, 1 TiB scaling in minutes, proxy-based failover in seconds, and 100+ observability metrics

Transactional databases remain the foundation for AI. We made them production-grade for the agentic era.

Managed Agents: a production runtime, not a monolith

This is the newest layer of the stack, and the one where we've spent the most time listening. We've watched customers deploy tens of thousands of agents on App Platform as containers. We've also watched them hit a wall when the agent loop, tool calls, state, observability, and code execution all live tangled together inside a single monolith.

So we asked a simple question: what would help you actually move faster? The answer became Managed Agents: five primitives that separate the plumbing from the business logic of your agent.

What's new:

• Managed Agents (General Availability): the production runtime
• Open Harness (General Availability): bring your own agent framework, including OpenCode, LangGraph, CrewAI, or any other harness
• Managed Sandboxes (General Availability): E2B-compatible, Firecracker-based, sub-second cold start for safe execution of model-generated code
• Durable State Management (General Availability): checkpoints and memory primitives the harness can rely on
• Plano (General Availability): our orchestration framework and data plane for agents, released under Apache 2.0
• Launchpad (General Availability): go from prototype to deployed agent in clicks
• Model Context Protocol (MCP) (General Availability): expanded support across the platform
• ToolBox (Coming Soon): 3,000+ tool connectors so your agents can act on the systems your business actually runs on

The compounding effect of the full stack

Any single layer of this stack is useful on its own. The reason to run them together is that the optimization compounds.

When your agents, your inference, your data, and your compute live in the same VPC, on the same silicon, billed on the same invoice, you eliminate the egress taxes, the margin stacking, and the integration debt that come from stitching across three vendors and three bills.

We've seen customers like Workato run a trillion automation tasks at 67% lower cost. Character.AI handle over a billion queries a day at 2x inference throughput. LawVo cut inference costs 42% with no code changes by routing through us. Hippocratic AI is powering 20M+ patient interactions with 40% lower latency. None of these are demos. They're production workloads at scale.

Start here. Scale here.

If you're an AI builder, whether you're writing your first line of code or accelerating past product-market fit, this stack is for you. You don't need to wait in a hyperscaler queue behind a frontier lab. You don't need to glue together a Neo Cloud, an inference wrapper, and a vector database vendor. You don't need to compromise on openness, on economics, or on developer experience.

Welcome to the AI-Native Cloud. Let's build.

End-to-End Autoregressive Image Generation with 1D Semantic Tokenizer

Authors: Wenda Chu, Bingliang Zhang, Jiaqi Han, Yizhuo Li, Linjie Yang, Yisong Yue, Qiushan Guo

Autoregressive image modeling relies on visual tokenizers to compress images into compact latent representations. We design an end-to-end training pipeline that jointly optimizes reconstruction and generation, enabling direct supervision from generation results to the tokenizer. This contrasts with prior two-stage approaches that train tokenizers and generative models separately. We further investigate leveraging vision foundation models to improve 1D tokenizers for autoregressive modeling. Our autoregressive generative model achieves strong empirical results, including a state-of-the-art FID score of 1.48 without guidance on ImageNet 256x256 generation.

How LLMs Distort Our Written Language

The Trump administration is discussing a potential executive order to create an AI working group that would bring together tech executives and government officials to examine potential oversight procedures.

OpenAI president Greg Brockman took the stand on Monday. Two days before the trial, Elon Musk had messaged Brockman to gauge his interest in settling the case. Brockman suggested that both sides drop their claims, but Musk responded by saying that Brockman and Sam Altman would be the most hated men in America by the end of the week. Musk's lawyers are attempting to paint Brockman as motivated by money at the expense of OpenAI's nonprofit mission.

Amazon has launched Amazon Supply Chain Services, a centralized place for companies to hire Amazon for services such as fulfillment, ocean and air shipping, and truck transportation. The offering puts Amazon in competition with transportation and warehousing giants such as DSV and DHL. The global market for third-party logistics is estimated to be more than $1.3 trillion. The move is a bet that Amazon can do for logistics what Amazon Web Services did for cloud computing.

SpaceX is constructing one of the world's most advanced solar cell factories in Bastrop, Texas. The company is vertically integrating the entire fabrication process to produce highly specialized aerospace-grade solar cells. Vertical integration allows SpaceX to insulate itself from global supply chain vulnerabilities while also giving it total control over the physical limits of solar cell efficiency and mass. SpaceX needs a continuous, high-volume supply of bespoke solar arrays to successfully pull off its plans of deploying an orbital cloud network capable of handling AI workloads.

Familiar Machines & Magic, a startup headed by Colin Angle, the former CEO of the company that invented the Roomba, has unveiled a robot designed by former Disney Imagineers to be cute and appealing. The Familiar is an emotionally intelligent robot trained to respond appropriately to tone of voice, body language, and overall vibe. The company will market the robot to people who want to monitor their loved ones, and it is also keen to sell Familiars to people who would like to support their own well-being. The robot is still in an early prototype phase, so there is no information on pricing or availability.

Stripe runs the world's largest Ruby codebase. The pain of not having an auto-formatter was visible in how its engineers worked. In 2022, the company set two engineers from its infrastructure team to work full-time on rubyfmt, a tool that is currently being used to format 100% of Stripe's 42 million lines of Ruby. This post tells the story of how rubyfmt came to be.

The PR for a new Array data type for Redis took four months to create using AI assistance. AI tools allowed the developer working on the code to venture into a level of complexity they would have otherwise skipped. They helped make tasks easier and less tedious while also providing a virtual workforce that could reveal bugs in complicated algorithms.

GameStop has made an unsolicited offer to buy eBay for $56 billion, a roughly 20% premium to the company's stock closing price on Friday. GameStop is a much smaller company than eBay and is currently valued at around $12 billion. The company has around $9 billion in cash and a commitment letter from TD Bank to provide up to $20 billion in debt financing to help make the deal possible, but it is unknown how the company will come up with the rest of the money.

AI for Bio has a Fuzzy API problem

"AI for bio" is getting hot again. Given the excitement in the current moment, I thought I'd share a bit about what actually makes biology uniquely hard as an application domain for machine learning. The reason is not simply that biology is complicated, though it obviously is. ML is good at many things that are complicated. The deeper reason is that drug discovery does not have the kind of clean feedback loops and clean interfaces that made modern ML so powerful elsewhere.

In software, we are used to clean APIs. One team can build a backend service, expose an endpoint, and another team can build on top of it. The interface is typed. The object either satisfies the contract or it does not. If something breaks, you can usually trace the failure to a bug, fix the code, rerun the test, and ship again. This is so much the case that billion dollar companies are regularly built satisfying exactly one interface (e.g. Supabase for databases, Exa for search, NVIDIA for GPU compute).

It is tempting to imagine drug discovery the same way:

target = target_discovery(disease)
drug = drug_design(target)
medicine = clinical_trial(drug)

Target discovery gives you a target. Drug design gives you a molecule. Clinical trials tell you whether it works. One company satisfies each interface.

Unfortunately biology does not expose clean APIs. The output of target discovery is not really a target. It is a probabilistic hypothesis that modulating some biological process, in some direction, in some tissue, in some patient subset, at some disease stage, will produce a useful clinical effect without unacceptable toxicity. The output of drug design is not really a drug. It is a candidate intervention whose value depends on whether the target hypothesis was right, whether the modality is appropriate, whether the molecule reaches the right tissue, whether it has enough selectivity, whether the safety margin is acceptable, whether it can be manufactured, whether it has a defensible IP position, whether the unknown competitive landscape materializes, and whether it fits a viable clinical strategy. The output of a clinical trial is not simply a "cure". It is an outcome filtered through patient selection, endpoint choice, dosing regimen, site execution, statistical power, standard of care, and regulatory interpretation.

So the API is fuzzy. A target can look validated until the molecule hits it in the wrong tissue. A molecule can look great until it fails because the disease biology was wrong. An animal model can look convincing until the human disease is meaningfully different. A trial can look negative even though the drug might have worked in a narrower patient population. The downstream or upstream stages encode specific assumptions in other stages. To me, that is the core problem: AI for bio has a fuzzy API problem. In software, good APIs hide complexity. In biology, the hidden complexity inadvertently kills programs. This essay is about where that fuzziness shows up: target discovery, drug design, and clinical development, and where that poses both challenges and opportunities to use machine learning to revolutionize the field.

The discovery process

The first order, drug discovery involves designing an intervention that stops some sort of deleterious process occurring inside the body. In practice, modern therapeutic development usually looks something like this:

1. Determine the causal biology driving a disease in a particular patient population.
2. Design a chemical or biological intervention that modulates that biology.
3. Test that intervention in model systems (cell, animals, etc) to build evidence that it is safe and plausibly effective in humans.
4. Run clinical trials to determine whether it works in humans.

That clean list hides a lot. The intervention itself can take many forms, called modalities. They can involve small molecules that block a particular molecule, antibodies that deliver toxins to certain molecules, pieces of RNA that block protein design, in-vivo edits that permanently delete bad processes, methods for reprogramming the immune system to recognize a foreign body, and several others. Clinical development then generally proceeds through three phrases, testing various aspects of safety and efficacy in humans.

For the purposes of this post, I'll simplify the whole process into three stages:

1. Target discovery: What biology should we modulate?
2. Preclinical Design and Translation design: What intervention can modulate it? Does the intervention look safe and effective enough in model systems to justify trying it in humans?
3. Clinical development: Does it actually help the intended human population?

Machine learning can matter in all three stages. But the type of ML that matters, and the difficulty of the problem, varies a lot by stage.

Target Discovery

When I talk about target discovery, in essence what we're saying is "do biology research to find a hypothesis of something worth targeting". Historically, a lot of target discovery research happened in academia. Large scale efforts like the Broad Institute's DepMap helped identify what perturbations in cancer cells affected their growth. Researchers used that to identify potential genes that drove cell growth, and hypothesized that blocking those genes would enable anti cancer drugs. Note that these were not experiments on people. They were usually on cancer cell lines that had been grown ex-vivo, or occasionally on patient derived lines.

Other efforts like genome wide association studies (GWAS) attempt to use real human data collected from population scale sequencing efforts like the UK Biobank. The idea is pretty simple — with enough people, you can identify genetic variants associated with disease risk. A GWAS hit might tell you that a region of the genome is associated with a disease. It does not automatically tell you which gene matters, in which cell type, through which pathway, in which patient subset, or how you should intervene therapeutically. This is the fuzzy API problem again. The "target" returned by human genetics is often not a clean therapeutic object. It is a clue that needs to be further validated by physical experiments. So historically, there has not been much deep learning at the core of target discovery. There have been statistical genetics methods, network methods, and deep learning tools for things like gene regulation. But not a unified model that could answer the question we actually care about:

"if I intervene on patient x in cell type y with intervention z, what will happen?".

That problem framing is making the field newly excited about so-called "virtual cell" or "virtual human" models. The idea is roughly: collect lots of data about cell/person states, perturb them in various ways, and measure many readouts — transcriptomics, proteomics, imaging, cell growth, functional phenotypes, clinical data — and train models that learn the relationships among them. Scaling laws from LLMs give a framework for how to think about allocating resources, and some early efforts suggest there are similar scaling laws in these data too. Companies like Tahoe, Noetik, and Recursion are all pursuing some version of this. This is a good direction.

This also turns out to be extremely hard. First, the existing data is sparse and low quality. If you have millions of genetic loci, many possible cell types, many disease states, many interventions, and only hundreds of thousands or even millions of patients, you are still in trouble in terms of the curse of dimensionality. Biobank data is powerful because it captures naturally occurring variation in humans and correlates that to disease outcomes. This is great for finding drugs whose effect mirrors naturally occurring variation. On the flipside, this data cannot capture the outcome of arbitrary drug perturbations. There are not many ethically acceptable ways to perturb a human, wait, and see what happens.

So we fall back on model systems: we use cells, organoids, mice, rats, dogs, non-human primates, and others. But, a cell line does not have an immune system, a vascular system, a liver, a microbiome, or the full context of a human body. An animal has a body, but not a human body. An engineered disease model can be useful, but it may not capture the human disease process we actually care about. We know this is true because drugs that work in model species preclinically regularly fail in human clinical trials.

This creates a sim-to-real gap between the model system and the human. Worse, since we are training machine learning models on this sim data, we are building models of the simulation and trying to get them to transfer to reality. In other words, we have sim^2-to-real gap and no great physics engine.

That is why target discovery is so hard. It is not just that we need better models. We need better data, better perturbation systems, better causal inference, better human-relevant assays, and better ways to close the loop between prediction and experimental validation. Don't get me wrong. I'm excited to see that companies are making serious attempts to solve these problems and develop new ML models for target discovery. Also, historically it wasn't clear that discovering targets could be effectively monetized other than by making drugs yourself against those targets, but companies like Cartography Bio are proving otherwise.

Still, the hard part remains: the "target" object is fuzzy. A model can nominate a gene, pathway, cell state, or biomarker. But the clinically relevant object is a causal, directional, context-specific intervention hypothesis.

Drug Discovery

This is the stage of the process that is most widely discussed. There is obviously enormous promise here. Models like Boltz, Chai, and Nabla can be used to predict structures, generate binders, and reason about protein interactions. Dyno is using machine learning to design AAV capsids, and other companies are designing payloads for genetic medicines with generative models. Some of these are using natural language LLMs while others are taking the lessons for what worked in computer vision and LLMs and designing new model architectures to support bio-specific use-cases (Nabla, Chai, Dyno, etc are all this). That's great.

Now here is the problem: the common ML person view of drug discovery sees this stage as a clean API whose implementation looks something like this:

def drug_design_process(target, known_inhibitors):
    new_drug = None
    while too_similar(new_drug, known_inhibitors):
        new_drug = design_and_optimize(target)
    return new_drug

The naive view is that as long as you can run the while loop well, you win. I certainly thought that's how it worked when we started Reverie. It also matches the conventional startup wisdom to focus on your core competency. If you're a machine learning engineer interested in structural biology, just build the best drug design engine. Let someone else find the target. Let someone else run the trial.

Unfortunately, this is not how biology works in practice. For any well-known target — meaning a target with a good paper, credible human genetics, or obvious clinical rationale — there will often be many competitors. Some you know about, some you do not. If you are not first, you need to be meaningfully better. But you usually do not have access to your competitors' full efficacy data, safety data, formulation details, or usually even their structure until much later. On top of that, if you're an American company, there is a high probability you have a competitor in China moving quickly and effectively, who can offer up their drug to a pharma partner for a fraction of what your development costs. They can also generate animal data faster/cheaper than you can, and run a Phase 1 for a fraction of the price of doing it in the US.

So maybe you avoid crowded targets and go after novel biology. That can be the right move. Perhaps you use a target discovery platform company or a proprietary data platform to identify new targets that others have missed. But then the error bars on your confidence for your target explode. No one has validated that modulating the target in a human works. Your disease model, patient subset, biomarker, or modality might be wrong. You can design a beautiful molecule and still create no value because the upstream biological hypothesis was false. In other words, you can do your job perfectly in the algorithm above, and produce something that has zero value.

For companies building in this layer, there is also the challenge of commoditization. I don't doubt that there are companies with superior AI drug design technologies. But the relevant question is whether that superiority is large enough and connected enough to the rest of the drug-development process to get durable returns. Open-source models will improve, and all models are constrained by data. This does not mean AI drug design is overhyped. It means the value is probably highest when the design loop is tightly coupled to proprietary data, fast experimental feedback, differentiated targets, modality-specific expertise, or a clinical strategy that makes the molecule matter. In other words, you may have to abandon the tight API and accept that your process will depend on the other factors as well.

Clinical Trials

And so we arrive at clinical trials. This is the part of the process I would argue has been most neglected by serious machine learning people. It's the area where there are the most obvious tailwinds with LLMs. Essentially all of the problems associated with clinical trials are well suited either to use LLMs out of the box or to use machine learning to develop custom models that are relevant for the domain. Here are some examples.

Patient stratification: Can you predict what subset of patients are going to be responders for a particular drug? This is a hard machine learning problem for similar reasons as target discovery: it's hard to get useful human data. But it might be a better fit for an LLM-driven approach. You could imagine post training a general LLM with large amounts of human EHR data, or giving an intelligent agent access to health records to look for patterns between a wide variety of unstructured notes and indicators of drug effectiveness. The goal would be to reason across messy unstructured records rather than just query a database to train a supervised ML model. Moreover, for many trials, we often know the type of patient we want, but the problem is finding them. An example: a trial might need patients with mutation X, blood pressure levels above Y, that have tried/failed at first/second line treatments, are over 35 years old, and have never had an acute side effect to an mRNA vaccine. Unfortunately, that's not SQL queryable in any database, especially in America's decentralized system. The method to do this before LLMs was having a human manually read EHR entries and identify them. We can now use LLMs to do this. Then, once we identify them, we can have an AI agent pester them to come enroll for a trial. This is not just an ML problem. The system that does this has to exist inside a health system, with clinician trust and incentive alignment.

Trial Operations: There are immense aspects of clinical trials that are slow and inefficient. It is slow to recruit patients (see above), slow to collect and analyze samples, and slow to QC and verify the resultant outputs. A huge amount of this work already happens through large outsourcing organizations and software vendors: CROs, EDC systems, clinical data-management vendors, site networks, and consulting firms. These companies make billions of dollars doing work that often involves basic data management, review, reconciliation, and coordination. These present enormous opportunities to use off-the-shelf models to significantly accelerate and improve the process.

Scaled up Literature Mining: There are enormous amounts of useful biological and clinical information scattered across papers, abstracts, trial registries, regulatory filings, patents, and conference posters. Some of the most interesting drug hypotheses come from connecting evidence across domains that no individual team had time to synthesize. Perhaps there was a drug that failed in one population, and you have good reason to believe that it could be repurposed for a different population due to a biomarker you found in an obscure paper. Previously, you'd have to have an entire team of people scouring academia to find information like this. Today, you could use intelligent research agents to find it. This is often the inspiration behind companies purporting to build an "AI-native Roivant": a company that uses AI agents to mine literature, clinical evidence, competitive landscapes, and external assets, then forms asset-specific companies around the best opportunities.

Monetization: Clinical development is also easier to monetize than many upstream AI-for-bio ideas because the value of time is much more legible. A drug's commercial life is finite, driven by patent limitations and exclusivity rules, among other factors. A lot of that window is consumed by clinical development — usually drug patents are filed right before beginning a clinical trial. This means that their patent clock is ticking while running the trial, and that every day they can save in clinical trials is a day longer their drug profits on the market after approval.

To first order, you can calculate the per day value of time savings as Peak Daily Sales*P(Approval). For most big drugs, this is worth millions of dollars per day. For blockbuster drugs it can be tens of millions of dollars per day. So, if you can prove that you can save time on a trial, pharma companies should be willing to pay very large amounts of money for your service.

So why don't more machine learning people enter this space? My guess is that it feels boring. If you grew up loving physics and chemistry and math/CS like I did, you'd naturally gravitate towards things that look like AlphaFold. It feels really good to encode the triangle inequality in a weight update. Those problems are deeply satisfying as a scientist. Most of the clinical trial work is schlep work. But as the lesson goes, schlep work is often the most lucrative to focus on.

Upshot

So where does that put us? Am I saying that everyone should abandon target discovery and drug design and focus entirely on clinical trials? No obviously not. All of the efforts to work on better target discovery and drug design are great for humanity, and I'm glad they are being funded and pushed forward. I'm sure great companies will be built doing those things. But I do think AI-for-bio founders should be realistic about where their edge lives. The uncomfortable implication is that a lot of AI-for-bio value may accrue less to the team with the highest scoring generative model and more to the team with the best closed-loop system for selecting, testing, financing, and clinically advancing assets.

One version of that company looks like an AI-native Roivant:

1. Use agents to mine literature, clinical evidence, trial data, patents, and competitive landscapes.
2. Identify underappreciated therapeutic hypotheses.
3. Take a trip to Shanghai to license assets that match those hypotheses.
4. Create asset-specific companies to push them through clinical inflection points.
5. Repeat until one works.

This is roughly what some biotech investors already do, minus the AI-native research layer.

Another version looks like a vertically integrated target-discovery company:

1. Come up with a scaled data collection platform to get a unique / novel target hypothesis (hard, but many undertapped methods out there)
2. Take an off the shelf model (e.g. Boltz) to design a drug against it.
3. Validate quickly through tight experiment feedback loops
4. Create the subsidiary with the asset, raise capital to take that drug to the clinic, or sell it off to pharma at Phase 1.
5. Repeat.

Both of these company structures make sense to me, but I see them much less often than drug discovery companies that focus on neatly solving their clean API inferface. These structures do demand more from founders – they have to be opinionated and correct about more aspects of the therapeutic stack. But that seems better than being blind to the complexity.

I'd love to hear feedback on this. Reach out anytime if you'd like to talk.

Panthalassa has a technology platform that turns waves into reliable, clean power to power onsite AI computing.

Something shifted in the first quarter of 2026. Not a feature launch, not a new product - a structural change in how work happens.

For the first time, I found myself genuinely operating with agents across every dimension of my work: personal tasks, software engineering, company operations. Not as a novelty. As the default mode.

This post is the abstraction I arrived at after weeks of doing this. A mental model that applies everywhere - because the architecture underneath is always the same.

The Trigger: OpenClaw and the "Agent Operating System"

It started with OpenClaw.

OpenClaw is an open-source project that I would label itself as "an operating system for agents". But powerful and open-source, like Linux. First commit in November 2025, breakout success by February 2026. I installed it, connected it via Telegram, and started co-working with it - scheduling, filing taxes, processing documents.

But the product itself wasn't the revelation. It was the process behind it. The sheer quality of what one person team could ship in three months, using agents to build an agent platform, made something viscerally clear to me: the leverage available through agentic work had crossed a threshold.

What I didn't expect was that the pattern I saw in OpenClaw would repeat everywhere I looked - in my IDE, in my company's operations, in how I manage my own life. The same architecture, over and over.

So I sketched it.

The Mental Model

Here's the framework. Every agentic system I've encountered - from personal AI assistants to coding agents to operational automation - follows this structure:

Five components. Always present. Always in the same relationship:

1. LLM Models / API - The raw intelligence. GPT, Claude, Gemini, open-source models. These are interchangeable and increasingly commoditized. They provide the reasoning capability, but alone they do nothing.
2. Agents Host - The runtime that wraps raw intelligence into an operational system. It handles scheduling, permissions, model access, tool access, and human interaction surfaces. This is the platform layer that most people underestimate. The host determines what the agent can actually do.
3. Agentic Loop - The core execution cycle: Reason → Act → Observe → Repeat, bounded by a System Prompt that defines the agent's role and constraints. This is where the work happens.
4. Context - Everything the loop can draw on: connected files, apps, MCPs (Model Context Protocols), databases, internet access. The richer the context, the more capable the agent.
5. Shared Workspace - The surface where agent output becomes real: files, folders, codebases, apps, databases. Critically, this is shared between human and agent. Both read and write to it.

And threading through all of it: Human Interaction - the chat, voice, or thread interface where the human directs, corrects, and collaborates with the agent.

Why This Model Matters: It's Always the Same Architecture

The insight that changed how I think about this: every agentic tool I use is an instance of this same model. The only things that change are the host, the context sources, and the workspace.

Let me show you three concrete instances from my own work.

Instance 1: Personal Space - OpenClaw

flowchart LR
	LLM["LLM API"] --> Host["OpenClaw on VPS
(Agents Host)"] --> Loop["Reason & Act loop
(system prompt: assistant)"]
	Ctx["Context:
Calendar, inbox, docs,
personal preferences"] --> Loop
	HI["Human Interaction:
Chat / Voice"] <--> Loop
	WS["Shared Workspace:
Personal notes, tasks, files"] <--> Loop

Host: OpenClaw, self-hosted on a VPS.

Context: Calendar, inbox, documents, personal preferences.

Workspace: Personal notes, tasks, files.

Human interaction: Telegram chat, voice.

This is where I first experienced the model in action. OpenClaw isn't a chatbot - it's an agent with persistent memory, connected tools, and the ability to self-modify its own skills. It files my taxes. It processes documents. It manages scheduling.

The key realization: the host matters enormously. Running on a real OS with real hardware (not a sandboxed web app) means residential IP addresses, real browser capabilities, actual file system access. The playing field of the workspace defines the ceiling of what the agent can do.

Instance 2: Code Space - Cursor

flowchart LR
	LLM["LLM API"] --> Host["Cursor
(Agents Host)"] --> Loop["Reason & Act loop
(system prompt: engineer)"]
	Ctx["Context:
repo, codebase, docs, issues"] --> Loop
	HI["Human Interaction:
Chat / Voice"] <--> Loop
	WS["Shared Workspace:
 Codebase, local and/or cloude runtime"] <--> Loop

Host: Cursor (the IDE).

Context: Repository, full codebase, documentation, issues.

Workspace: The codebase itself, plus build tools, test runners, terminals.

Human interaction: Chat and thread within the IDE.

This is where the 10x-100x speedup lives - and where I spent Q1 2026 pushing the boundaries. I rebuilt my personal website (the one you are on right now) in days, then moved into mission-critical backend work on AQUATY's distributed system.

The IDE-as-host is powerful because the workspace is the actual codebase. The agent doesn't generate code into a void - it reads, writes, runs, and tests in the same environment you do. The shared workspace is maximally integrated.

I'll go deep on this in a follow-up post. The data is striking - and the failure modes are instructive.

Instance 3: Operational Space - Notion

flowchart LR
	LLM["LLM API"] --> Host["Notion
(Agents Host)"] --> Loop["Reason & Act loop
(system prompt: ops)"]
	Ctx["Context: 
DBs, SOPs, project state,
dashboards"] --> Loop
	HI["Human Interaction: 
 AI Chat & Voice"] <--> Loop
	WS["Shared Workspace: 
Notion Pages + Databases"] <--> Loop

Host: Notion (as an agents platform).

Context: Databases, SOPs, project state, dashboards, connected tools.

Workspace: Notion pages and databases - the same surfaces the team already works in.

Human interaction: Comments, requests, AI inbox.

This is the instance most people haven't thought about yet. When Notion becomes an agents host, your operational infrastructure becomes the shared workspace. The agent doesn't just answer questions - it reads your databases, understands your project state, and writes back into the same pages your team uses.

This is what I mean by agentic operations: not "AI features in a productivity tool," but a genuine agent loop running against your company's operational surface.

The Pattern: What Changes, What Stays the Same

Across all three instances, the architecture is identical. What varies:

The model is fractal. You can zoom into any organization and find these same five components wherever agents are being deployed effectively.

One more shift matters: when both the agent and the shared workspace live in the cloud, the loop stops being "while I'm at my desk" work. It becomes continuous - always-on, permissioned, and able to run while you sleep. That's the structural reason the productivity ceiling jumps from incremental gains to 10x, and in the right setups, 100x.

What This Means for Companies

If you accept this mental model, a few things follow:

The cloud version of the model is the inflection point: once agents can safely operate against a shared workspace 24/7, organizations can move entire workflows (not just individual tasks) into an always-on agentic loop.

The host is the strategic decision. Choosing where your agents live determines what they can access, what they can do, and how deeply they integrate with your existing workflows. An agent in a sandboxed chat window is fundamentally limited compared to an agent with native access to your workspace.

Context is the moat. The AI models themselves are increasingly commoditized. What differentiates your agent's output is the context it has access to - your proprietary data, your SOPs, your project state, your institutional knowledge. Companies that connect richer context will get disproportionately better results. I call this: The Opionated Context Layer.

The shared workspace is the interface. The best agentic setups don't create separate "AI outputs" - they write directly into the spaces where humans already work. This is why Cursor works so well (agent writes into your codebase). And why Notion's approach is IMO leading (agent writes into your operational pages) - if you apply Notion Agents to a workspace your copmpany has been workin in for years, this pays hughe dividends now!

The human role shifts from executor to architect. In every instance, I'm not doing the footwork. I'm making architectural decisions, auditing outputs, correcting course, and designing the system prompts and context that make the agent effective. The work isn't less - it's different.

Every step that humanoid robots take results in a shock through the leg actuators - this means roughly one million impacts for every month of operation.

A new 'Create a Pass' option will let users generate digital passes from scans of things like movie tickets, concert passes, and gym membership cards.

Apple's Apple CarPlay Ultra has so far launched only with Aston Martin, while its broader rollout remains unclear despite earlier promises. Although several brands—including Hyundai, Kia, Porsche, and Ford—are still listed as partners (with Hyundai possibly launching support in an upcoming model), others like Mercedes-Benz, Audi, Volvo, Polestar, and Renault have backed out, and some partners have expressed lukewarm interest, leaving the platform's future adoption uncertain.

Microsoft's Xbox has unveiled a new glossy, translucent logo that leans heavily into early-2000s nostalgia, closely resembling Liquid Glass—a design approach it previously mocked when introduced by Apple. While some see it as a throwback to classic Xbox aesthetics, the timing suggests broader influence, reinforcing a wider industry shift led by companies like Microsoft and Apple away from flat minimalism toward skeuomorphic, textured, and more expressive visual styles.

As AI-generated artists and tracks flood music streaming platforms, Spotify is rolling out a new "Verified by Spotify" badge to help listeners more easily identify authentic human artists.

To receive the badge, artists must meet certain criteria. Spotify looks for an identifiable artist presence both on and off platform, like concert dates, merch, and linked social accounts on their artist profile. Profiles that primarily represent AI-generated music or AI-persona artists are not eligible for verification.

Additionally, artists must have consistent listener activity and engagement over time. Spotify is focusing on artist profiles that people are actively seeking out over a sustained period of time, rather than those that are experiencing one-time spikes in engagement.

At launch, more than 99% of artists that listeners actively search for will be verified. Most are independent, representing a broad mix of genres, career stages, and regions, Spotify says.

Users will start to see the new badges appear on artist profiles and next to artist names in search results over the coming weeks. The badges will feature "Verified by Spotify" text alongside a green checkmark.

Given the vast number of profiles on the platform, Spotify says verification will roll out on an ongoing basis, and that the absence of a badge does not mean a profile will not receive one in the future.

Spotify is prioritizing artists with active fan interest and notable contributions to music culture, rather than so-called "functional music" creators — think algorithm-optimized background or focus playlists — whose content is designed for passive or background listening.

"We've designed this new verification program thoughtfully with listeners and artists in mind, and we'll continue to evolve this program over time," Spotify wrote in a blog post. "Our goal is to make it easier for you to trust and understand the human artistry behind the music you listen to on Spotify, and develop long-term, meaningful connections with the artists and music you love."

The platform is also launching a new profile section in beta across all artist profiles that will highlight career milestones, release activity, and touring activity. Spotify says this section will give users a quick way to see an artist's authentic activity even if they haven't yet met the criteria for a verification badge.

These updates mark Spotify's latest efforts to address the rise of low-quality AI-generated content (AI slop) and impersonators on its platform. Last month, the company started beta testing an "Artist Profile Protection" feature that allows artists to review releases before they go live on their profiles to give them more control over which tracks are associated with their name.

Spotify launched the feature a few weeks after Sony Music said that it had requested the removal of more than 135,000 AI-generated songs impersonating its artists on streaming services.

Although Spotify hasn't shared specifics on the number of AI tracks being added to its platform, rival streaming service Deezer announced last week that AI-generated tracks now represent 44% of all new music uploaded to its platform daily.

The TL;DR on MCP: Why context matters and how to put it to work

Designers fall into an "ego trap" by believing they should be creative heroes in their organizations, when in reality, most jobs involve trading value for money with limited autonomy. Many businesses function without designers, and good design is often less important to companies than keeping costs low. Designers need to accept their role as specialists rather than expecting the authority that comes with more general organizational responsibility.

The rise of tools like ChatGPT marks a fundamental shift from command-based computing to intent-based interaction, but most products still use AI as a superficial add-on rather than fully integrating it into their core design. True “AI-native” products would let AI handle internal complexity and abstract concepts (like those in AWS), reducing the learning burden on users—though this requires rethinking product architecture, maintaining user trust, and embedding AI into both the interaction and conceptual layers, not just the interface.

Jupitrr VideoOS is an all-in-one video platform that allows users to plan, script, edit, and publish videos from a single interface.

Go from prompt to a production backend in minutes. With InsForge, your coding agent builds the database, wires up auth, and runs it for you.

A visual breakdown of 154 Macs in 43 years.

Uber increased ride conversions by 14.5% by tackling the real barrier in transportation — uncertainty — through three friction-reducing design changes. GPS-based automatic pickup detection, real-time driver tracking, and upfront transparent pricing each eliminated a distinct point of hesitation in the booking journey. Together, these changes turned a frustrating multi-step process into a seamless, habit-forming experience aligned with how users naturally think and behave.

The Gap Tooth brand pairs a strict structural system (consistent layout, hierarchy, and typography) with deliberately imperfect, hand-drawn elements—like its wobbly wordmark, simple characters, and irregular fruit illustrations—to create personality without losing clarity. By treating “the gap” as a subtle guiding principle rather than an obvious visual gimmick, the design stays flexible and scalable across flavors and formats while prioritizing brand recognition over individual variations.

Spanish artist Chema Méndez creates digital collages that blend classical paintings with modern photography, 3D renders, AI, and personal sketches.

Five key trends are driving the shift from static marks to living identity systems: fluid, generative logos; hyper-legible, AEO-centric marks; neo-brutalist "lo-fi" aesthetics; tactile minimalism with 3D depth; and kinetic, variable-font typography.

Tether's Q1 2026 attestation reported $1.04 billion in net profit and a record $8.23 billion excess reserve buffer, a slower pace than the $10 billion-plus annual profit Tether posted in 2025. Reserve composition as of March 31 included $141 billion in US Treasury bills, roughly $20 billion in physical gold, and approximately $7 billion in bitcoin, backing $183 billion in USDT liabilities. BDO's report is a point-in-time attestation, not a full financial audit.

Lazarus Group exploited a LayerZero bridge bug to steal $292M from KelpDAO in April, and after Arbitrum's Security Council froze $71M of the stolen ETH onchain, a New York court issued a restraining order on behalf of Han Kim and other DPRK terrorism victim families holding a combined $877M in unpaid US judgments against North Korea. Those creditors argue the frozen ETH constitutes seizable DPRK property, while the opposing position holds that North Korea never owned the funds and that KelpDAO hack victims are the rightful owners. A governance proposal backed by Aave, LayerZero, EtherFi, and Compound to release the ETH to a victim compensation multisig is passing the Arbitrum DAO vote, but multisig signers who transfer while the restraining order is active face personal legal liability. This is the first direct conflict between competing US court claims and DAO incident response governance, and the resolution will set precedent for how on-chain entities handle legal pressure during future hacks.

Over 100 Ethereum core contributors gathered in Longyearbyen, Svalbard, at the Soldøgn interop week to advance the Glamsterdam network upgrade, locking in a post-Glamsterdam gas limit floor of 200 million and finalizing gas repricing numbers for EIP-8037. The team also stabilized external block builder implementations, with EF researcher Tim Beiko noting that interop weeks compress roughly a month of asynchronous progress into a single day.

Ethereum's proposed staking reward curve change, co-authored by EF researchers Anders Elowsson, Ansgar Dietrichs, and Caspar Schwarz-Schilling, replaces the uncapped square-root issuance schedule with a dampened curve (factor: 1 + D/k, k = ~67M ETH) that peaks at that staking level and declines beyond, reducing daily validator issuance from the current ~2,700 ETH against only ~90 ETH burned via EIP-1559. Elowsson estimates that two-thirds of the issuance reduction eliminates deadweight costs accruing to validators (hardware, risk, taxes, and opportunity cost), while one-third redistributes surplus from stakers to all ETH holders. Lido's Dima Gusakov argues the change kills LSTs, but the article counters that Lido's ~30% share of staked ETH is the primary systemic risk, with stETH's growth trajectory threatening to displace ETH as Ethereum's base monetary asset.

After 6 months on the ground across Brazil, Mexico, Argentina, Colombia, and Peru talking to users, mapping competitors, and stress-testing assumptions against internal P2P, card, and pay data, the author argues most fintech decks are getting LATAM wrong. Key blind spots include not knowing actual corridor sizes, what percentage of users want USD vs. local currency, and why Mexico digitalizes at 25% while Colombia is over 50%. The thread provides a ground-level corrective to the "stablecoins are the killer of cross-border payment" pitch deck thesis and maps both the real obstacles and the genuine opportunity across the region.

Stripe has assembled a full stablecoin payments stack through three acquisitions – Bridge, Privy, and Valora – then co-founded Tempo, a permissioned EVM L1 that reached mainnet in March at a $5B Series A valuation. Bridge holds a conditional OCC national trust bank charter and runs an Open Issuance platform hosting stablecoins for Phantom, Klarna, Hyperliquid, and MetaMask while sharing majority reserve yield with issuers; Privy supports 110M programmable wallets; and Stripe's Link wallet targets 250M consumers, all sitting atop $1.9T in 2025 payment volume. Circle's Arc independently arrived at the same permissioned-L1-with-named-FI-validators design, the GENIUS Act pushes Meta toward Stripe as a stablecoin issuance partner, and OCC's March 2026 proposed rule protects Bridge's non-affiliate yield-sharing model while threatening Coinbase's USDC rewards program.

Xen (Base Director of Growth) paints the vision: a freelancer in Lagos paid in USDC that clears in two seconds with no correspondent bank; a São Paulo startup raising onchain capital from Singapore and Berlin with no SPV or six-month legal process; AI agents settling supply chain invoices automatically because the payment and contract layers are the same thing; a teenager in Manila earning money building on a protocol where nobody asks where she went to school. The thread frames the onchain economy as fundamentally about increasing innovation, creativity, and freedom through open financial access.

Brazil's central bank published Resolution No. 561 on April 30, effectively making it illegal for fintechs and neobanks to quietly convert reais to USDT on the backend and settle payments via blockchain within the eFX rail (the exact flow that many were using for cheaper, faster cross-border settlement without correspondent banks). The ban takes effect on October 1 and doesn't outlaw crypto broadly, but specifically targets the use of stablecoins as invisible backend plumbing inside regulated payment corridors. It's a significant regulatory move in Latin America's largest economy and will force stablecoin-native payment companies to either restructure their flows or operate outside the eFX system.

Crypto's total addressable market includes financial services at ~$36T, payments at ~$788B, and social at ~$208B.

The FEMITBOT platform leverages Telegram Mini Apps to execute large-scale crypto scams and distribute Android malware.

Visa added Polygon to its global stablecoin settlement program.

Crypto VC funding fell 74% month-over-month to $659M across 63 rounds in April.