AI may or may not be pushing lots of people out of the workforce, but Anthropic has good news as the Claude creator is creating temporary positions to promote the adoption of AI, even as CEO Dario Amodei ponders policy interventions to counter "job displacement." The AI biz has announced the launch of Claude Corps, a $150 million program that will pay 1,000 Claude Corps Fellows $85,000 (plus benefits and a token budget) for one year to help advance the missions of nonprofit organizations using generative AI. Meanwhile, the tech industry continues to take on debt to build datacenters while balancing its books by shedding employees. According to job search biz TrueUp, the tech sector this year has averaged 935 layoffs per day, up from 674 per day in 2025. Anthropic's program debuts alongside the publication of Amodei's latest musing about his optimism "that, even in a world with AIs that are better than everyone at everything, humans can live lives of deep purpose and strive to build awe-inspiring and beautiful things." Claude Corps' stated goal is to provide host organizations with valuable tools and systems and to help participating fellows "build AI skills that will serve them in their careers" – however long those careers last until AIs are better than everyone at everything. There is, of course, no guarantee that AI will surpass human cognition or folly. But Amodei likes to talk about the idling of human labor, just in case, even if that sort of chatter fuels the firebombers. Anthropic says that it is announcing Claude Corps alongside its policy framework for dealing with AI's impact on work. The framework is titled "Policy on the AI Exponential," which is the same title Amodei used for his post. The policy's call for company-endorsed regulatory intervention is predicated on the claim that "AI is advancing at exponential speed," though the document cites no evidence of exponential capability gains and offers no time frame – a necessary variable to calculate periodic gains. Judging by AI model benchmark metrics, recent AI improvement has been incremental, a rate of advancement too timid to turn heads in the attention economy. Using data from Stanford HAI's 2026 AI Index report, even impressive gains such as AI model performance on the SWE-bench Verified benchmark rising from 60 percent to nearly 100 percent of the human baseline in a single year are not, by themselves, evidence of broad "exponential" progress across AI. Alarmism aside, Claude Corps will be funded and steered by Anthropic and implemented by computer education nonprofit CodePath, which will serve as the employer of record for fellows. The 12-month-long fellowships begin with "intensive training on using Claude in non-profit settings," augmented by five hours of additional training each week. Fellows are expected to use their remaining time coaching their respective nonprofits on the ins and outs of AI workflows. The gig comes with support from a CodePath mentor and office hours from Anthropic, which may prove useful for reactivating Claude accounts that have been suspended after triggering Claude's overly sensitive safety guardrails. Some 400 nonprofits are expected to host Claude Corps Fellows over the next 12 months, including Braven (job prep for low-income students), Code the Dream (coding education), and Heartland Forward (economic growth for middle America). "If Claude Corps works, we'll have a foundation for something much larger: a model for widening AI's benefits during a period of vast economic change," Anthropic says. And if not, as New Yorker cartoonist Tom Toro put it, "Yes, the planet got destroyed. But for a beautiful moment in time we created a lot of value for shareholders." ®

The boffins on Google’s DeepMind team unveiled an experimental new language model this week that uses techniques originally developed for AI image generators to boost text output performance by as much as 4x when running on resource-constrained consumer hardware. It's free to download and you can run it with just 18 GB of DRAM or VRAM. The model, codenamed DiffusionGemma, is the latest addition to Google’s open weights model family. But unlike Gemma 4, which launched this spring, the 26 billion-parameter mixture of experts (MoE) model isn’t a large language model in a conventional sense. Instead, it’s actually closer to image models like Stable Diffusion or Flux. Rather than generating tokens one after another in an autoregressive fashion, DiffusionGemma generates entire paragraphs' worth of tokens at the same time. The process looks a lot like how a diffusion model turns what’s essentially static into an image through a series of denoising steps. As Google explains it, DiffusionGemma works by laying out a canvas of random tokens, and then refining them until the final output is reached. Compared to conventional LLMs, which are memory-bandwidth bound and require a lot of VRAM, diffusion models are a predominantly compute-bound workload, which is why the Chocolate Factory is positioning these models for local deployment. LLMs are autoregressive. During token generation, the model’s active parameters need to be streamed from memory for every token generated, making memory bandwidth a major bottleneck. In the cloud, inference providers balance compute and memory bandwidth by processing hundreds or thousands of requests in parallel. As you might have guessed, this isn’t something the average user running a local model on their notebook can do. However, many consumer products, like high-end graphics cards, have plenty of excess horsepower, which DiffusionGemma can take advantage of to boost output performance. Diffusion language models aren’t perfect. Google isn’t the first to explore this tech. Previous models, like DREAM or Mercury 2, demonstrated major speedups over conventional LLMs, but generally underperformed them in benchmarks for their size. DiffusionGemma doesn’t appear to be any different. According to Google, the 26 billion-parameter model falls just behind Gemma 4 12B in the GPQA-Diamond benchmark, with its main advantage being output speed, and even then it’s not as impressive as Google has made it out to be. The chart shows a roughly 2.25x speedup for DiffusionGemma over the 12B parameter LLM with speculative decode enabled. Compared to Gemma 4 26B-A4B, the speedup is nearly 4x when running a single Nvidia H100. DiffusionGemma is being released as an experimental model rather than an enterprise focused one, like we saw with Gemma 4. The model is available for download on popular model repos like Hugging Face under a highly permissive Apache 2.0 license with support already merged into popular inference engines like vLLM, MLX, and HF Transformers, with support for Llama.cpp coming soon. While local inference has largely been the domain of AI enthusiasts, companies like Google are increasingly leaning on the tech to cut cloud costs associated with their AI services. As you may recall, back in May, Google quietly began shipping a small LLM with its Chrome web browser. ®

This article is aimed at bioinformatics platform leads, ML infrastructure engineers, and genomics budget owners who are now running GPU-accelerated workflows in the cloud. It's about a hidden cost problem that almost every genomics infrastructure team is paying for — and very few are actively measuring. The observations here are specific to short-read sequencing workflows, which remain the dominant data type in production genomics environments. Short-read sequencing pipelines, standard in next-generation sequencing (NGS) workflows, used to be CPU-heavy. You'd run them on a cluster, they'd grind through alignment and variant calling over hours, and the bottleneck was CPU throughput. GPU acceleration wasn't the story. That has changed. AI-driven variant calling, GPU-accelerated alignment tools like Parabricks, and deep learning models running on top of sequencing data have all moved toward the GPU, which means teams are managing serious GPU infrastructure for the first time. The cost model that comes with GPU cloud differs sharply from CPU clusters, and people are bringing CPU-era assumptions about pipeline reliability and cost accounting into a GPU environment. That mismatch is costing them. We work with a lot of these teams, and when we ask about infrastructure costs, they almost always lead with the same number: cost per sample. That's what gets reported upward, what sits in the budget. What that number hides is where things get interesting. When pipelines fail A typical short-read germline variant calling pipeline has maybe ten to 15 distinct processing steps. You start with raw FASTQ files off the sequencer, run quality control, alignment, duplicate marking, base quality score recalibration, variant calling, annotation — each step hands off to the next. These pipelines mostly run on workflow managers like Nextflow or Snakemake, which do have built-in mechanisms for resuming failed jobs. Nextflow has a flag designed to let you pick up from step eight of 11 rather than restarting from scratch. In principle, that's exactly the right solution. In practice, the problem is configuration. For that flag to work, Nextflow needs to find its cache directory — the folder that records which steps completed successfully. If the solutions architect set up the compute environment without properly configuring persistent disk space for that cache, the file isn't there when you need it, and the pipeline restarts from step one anyway. That's a setup failure rather than a tool limitation, but the result is the same: you've paid for compute you didn't get output from. When a large task fails mid-execution rather than at a clean step boundary, even proper checkpointing won't save you, because the task has to be rerun in full. A problem difficult to measure Genomics teams working with Nebius consistently report that 15 to 40 percent of their pipeline runs hit at least one failure and restart before completion. Pinning the figure down precisely is hard, and we have no definitive numbers that reflect the reality here. The range is wide because it depends heavily on how mature the infrastructure setup is. Teams with well-configured environments sit at the low end; teams newer to GPU cloud, or running on spot instances with higher interruption rates, sit at the high end. What makes this invisible is that if your metric is cost per completed sample, a failed run that eventually completes still looks like one sample at normal cost. The retry disappears from the number that gets reported. For example, a GPU-accelerated whole genome sequencing pipeline — germline variant calling — takes roughly two GPU-hours on an H200. At current on-demand rates that's about $9 of compute per sample, and that's the visible cost. Now apply a 25 percent failure rate — toward the conservative end of what teams report. For every four samples you complete, one run failed, restarted, and ran from the beginning. Your real cost per completed sample isn't $9 anymore — it's $11.25, a 25 percent hidden markup. Scale that to a team processing 2,000 samples a month: the visible compute bill says $18,000, but the real cost is $22,500. That's $4,500 a month — $54,000 a year — in compute that produced no output. For a mid-size genomics team, that's a meaningful fraction of the cloud budget, and it shows up nowhere as waste. That's before you touch storage. The hidden costs The storage picture is more nuanced than people expect. A standard whole genome generates roughly 200 gigabytes of raw FASTQ data, but that's the uncompressed figure. In practice, almost everything going into cold storage is compressed, typically down to around 30 gigabytes per sample, so the storage cost per sample is quite manageable. Where it gets complicated is retrieval. When you want to reanalyze archived samples — say, running a new cohort through an updated pipeline — you pull those compressed files back, and your infrastructure then needs to decompress them. That 30-gigabyte compressed file expands to 200 gigabytes, which means you need the disk space and memory headroom to handle the expansion. If the environment wasn't sized for it, you get failures or severe slowdowns at the decompression step, which becomes another category of hidden cost that's rarely accounted for up front. In cancer research, the numbers are much larger. Somatic mutation calling runs at 60x to 100x sequencing depth, so 600-gigabyte FASTQ files aren't unusual. Everything I've described scales accordingly. The key point: retrieval from cold storage always has a cost, regardless of where your compute lives relative to your storage. Some platforms charge for data egress between regions on top of that. Either way, the teams that haven't modeled their reanalysis frequency as a real line item are almost always surprised when they do. Tracking, tracking and tracking... Bioinformatics engineers know the failure rates, because they're the ones watching jobs fail at 2am. But by the time the numbers roll up to whoever controls the budget, it's just "cloud costs." There's no line item for "compute we paid for and got no output from." Cloud billing by service and instance type doesn't surface this. You see your GPU compute spend, your storage spend, your egress. You don't see "20% of your GPU spend this month was on runs that didn't complete." That decomposition requires deliberate instrumentation, and most teams haven't built it yet. What teams should measure instead of cost per sample Teams should measure a few things instead. First, completion rate: the percentage of pipeline runs that complete without failure or restart. That's your pipeline reliability score, directly linked to compute waste. Second, cost per attempted sample versus cost per completed sample. If those numbers are meaningfully different, you have a problem worth fixing. Third, storage retrieval frequency and the infrastructure overhead of decompression: how often you're pulling archived data back, and whether you've properly sized the disk and memory headroom for it. This is the gap between what looks cheap in the storage bill and what it costs to use the data. One thing genomics infrastructure teams should do differently starting this week Instrument your pipeline failure rate, right now, before anything else. The number itself doesn't fix anything, but it makes the problem visible. Once you can show that 15 or 25 percent of your compute spend is going toward runs that restart — with real dollar figures attached — the conversation about fixing the underlying infrastructure becomes easy to have. People move fast when they can see the waste. Everything else follows from that — better checkpointing configuration, smarter storage architecture, more stable compute — but you have to see the problem first. Discover the breakthroughs shaping the future of AI in healthcare and life sciences. Visit https://nebius.com/solutions/life-sciences-and-healthcare to learn more and register for the 2026 AI Discovery Awards ceremony: nebius.com/ai-discovery-award. Anastasia Raskolova Anastasia is a senior product manager for healthcare & life sciences at Nebius, where she focuses on infrastructure product for drug discovery and clinical AI workflows. Before that, she spent her career building ML products across computer vision, recommendation systems, and generative AI — and stays grounded in the clinical reality through volunteering in the Emergency Department at Massachusetts General Hospital. Contributed by Nebius.

OpenAI may be headed for Wall Street, but one analyst firm is already warning enterprise customers not to get too attached. In a note published alongside OpenAI's confidential IPO filing, Forrester urged companies to keep their AI options open, arguing that today's market leader could easily become tomorrow's cautionary tale. "Don't lock into long-term contracts; keep your architectures flexible," the firm advised. "In fact, OpenAI could become AI's BlackBerry FIFO (First In, First Out). The company that defines a category is often the one most painfully displaced by it." The caution comes as OpenAI takes its first formal step toward a public listing. Alongside its confidential SEC filing, the company published a roadmap built around three ambitions: AI systems that can accelerate research, AI that boosts economic growth, and eventually a personal AGI assistant for everyone. Forrester was more interested in a fourth question: what happens if OpenAI doesn't stay on top? The firm argues that OpenAI faces what it calls a "trifecta" of challenges: persuade consumers to use its agents instead of rivals', convince enterprises to build around its technology, and stay ahead in the race toward AGI. The enterprise battle may prove the most lucrative. "Whoever automates the dull, expensive middle of a company's operations first becomes the system of record everyone else has to rip out — and almost no one does,” Forrester said. In other words, the first company to get AI agents woven into day-to-day business processes stands a decent chance of becoming yet another piece of software that everyone complains about, but nobody can remove. However, Forrester's advice is that, rather than standardizing on a single provider, enterprises should "anchor to the capability you need — not the brand that got there first — and keep your switching costs low." The warning also comes as OpenAI reportedly weighs cutting prices to fend off growing competition from rivals, including Anthropic. If the AI market is heading for a price war, enterprises may want to think twice before chaining themselves to a single supplier. Forrester also notes that a public listing could provide customers with something they currently lack: visibility into OpenAI's finances. Once public, the company would be required to disclose far more information about the cost of training and operating its models, giving enterprise buyers a clearer picture of the economics behind the AI systems they increasingly depend on. For now, OpenAI remains the company that helped define the generative AI era. Whether it becomes the next Google, the next Microsoft, or AI's answer to BlackBerry is a question investors will soon be paying very close attention to. ®