AI

Perplexity has released pplx, an official command line client for its Search API. The tool returns grounded search results and extracted page text, all as JSON. According to its docs, it targets humans and coding agents equally. It is not a chat client. There is no conversational mode, no model selection and no synthesized answer. Two surfaces, one output contract The tool exposes exactly two working surfaces. pplx search web runs a live web search. pplx content fetch pulls a URL and returns cleaned page text. The contract around them is the interesting part. Per the official pplx-cli Agent Skill, success means exit code 0 and exactly one JSON object on stdout. Search returns {hits: [{url, title, domain, snippet, …}], total, saved_to?}. Every failure exits 1 with an empty stdout. One JSON error object goes to stderr, shaped {“error”:{“code”,”message”,”command”,”hint”?}}. Documented codes include AUTHENTICATION, UNKNOWN_ARGUMENT, ARGUMENT_ERROR and BAD_REQUEST. The skill notes that list is not exhaustive, so callers should branch on error.code. Install path and platform support Installation is a single shell command that pipes a script into sh: Copy CodeCopiedUse a different Browser curl -fsSL https://github.com/perplexityai/perplexity-cli/releases/latest/download/install.sh | sh Reading install.sh shows what it actually does. It downloads manifest.json from the latest release and extracts the tag and version. It then pins every remaining download to that tag, explicitly to avoid racing a concurrent publish. It fetches SHA256SUMS and the platform binary, verifies the checksum, and installs to ~/.local/bin/pplx. No sudo is required. A receipt is written to ~/.config/pplx/pplx-receipt.json, but only after the installed binary runs successfully. Platform coverage is limited to three targets: macOS on Apple Silicon, Linux x86_64 and Linux arm64. Anything else exits with an error. There is no Windows build and no Intel macOS build. Context-window economics are a first-class design concern The most agent-specific feature is token budgeting. –output-dir writes the full result set to a JSON file. –stdout-preview[=<CHARS>] truncates long string fields in stdout, adding …<truncated> markers. The skill is blunt about the trap: –stdout-preview is a no-op without a save directory. It truncates only when the result is also saved via –output-dir or $PPLX_OUTPUT_DIR. Used alone it returns full-size output, and hits can be multiple KB each. Saved search results land at {dir}/web/{rand}.json and fetches at {dir}/fetch/{rand}.json. Files are written only after a successful request. PPLX_OUTPUT_DIR sets a workspace default so the flag need not be repeated. For content fetch, the skill adds a correctness check rather than a cost one. Verify error and is_paywall in the output before trusting content. –html adds a raw_html field fetched live via crawler, and –no-cache forces a live fetch. Key Takeaways pplx is a single verified binary exposing two commands: pplx search web and pplx content fetch. Success is exit 0 plus one JSON object on stdout; failures put one JSON error object on stderr. pplx auth login is TTY-only, so agents and CI must export PERPLEXITY_API_KEY. –stdout-preview only truncates when paired with –output-dir or $PPLX_OUTPUT_DIR. Search API billing is $5.00 per 1,000 requests, capped at 50 QPS on every usage tier. Sources: perplexityai/perplexity-cli, pplx-cli SKILL.md, api-platform-developers, Perplexity API pricing, Rate limits and usage tiers, and Search API quickstart The post Perplexity Releases pplx, a Single-Binary CLI That Puts Its Search API in the Terminal for Coding Agents appeared first on MarkTechPost.

Outside the small town of Paducah, Kentucky, a wealth of uranium is locked away in thousands of storage cylinders filled with waste material from a now-closed nuclear enrichment facility. Lasers could help get it out. A company called Global Laser Enrichment (GLE) is looking to reprocess this old material with a new technology called laser enrichment. It could be more efficient than conventional enrichment methods, allowing the company to refresh the material and produce feedstock at the same concentration as a natural mined source. And in the future, the company claims, laser enrichment could be used to make material for nuclear fuel, including the kind used in advanced reactors. Nuclear power provides about 9% of global electricity today, and that fraction could tick up as major world powers like the US and China look to build new reactors, including some based on next-generation technology. New, cheaper methods to obtain fuel could help ensure that those nuclear projects stay on track. Naturally occurring uranium is largely made up of uranium-238 (over 99%) and uranium-235 (about 0.7%). Uranium-235 is the fissile type, meaning that, when hit with slow low-energy neutrons, it can sustain a chain reaction that generates electricity. So reactors generally use material with a higher concentration of U-235 than what’s pulled from the ground. Today’s conventional reactors usually use low-enriched uranium, typically is about 5% U-235, though some advanced reactor designs will use fuel that’s up to 20% U-235. Today, centrifuges are the dominant tech used to enrich uranium. The equipment essentially takes uranium-containing material and spins it around incredibly quickly, so the heavier material (which contains U-238) spins out to the edge, while the lighter material (which has U-235) stays closer to the center. (If you’ve ever swung a mustard bottle to get the last of it out, you’ve used the same basic idea behind a centrifuge.) Then the material that has a higher concentration of U-235 can go on to be made into nuclear fuel. Laser enrichment, on the other hand, takes advantage of the fact that all molecules vibrate and rotate at an atomic scale in ways that depend on their specific material. Even different uranium isotopes have distinct fingerprints. Lasers are so precise they can target one particular material (like molecules that contain U-235, for example). If you shine a laser at a mixture, you can selectively excite just the material you’re targeting, giving it a bit more energy. This changes the way it behaves, which can make it easier to separate out the material you want using chemical or physical methods. A wide range of separation approaches have been developed in research and industry. Some aim to electrically charge U-235 atoms, allowing them to be moved with electrostatic or magnetic fields. Others change how the material reacts chemically.  The details of GLE’s specific technology are classified, and company officials declined to share how the process works.  There’s been interest in using lasers for uranium enrichment for decades, says Charles Forsberg, a principal research scientist in nuclear science and engineering at MIT.  However, in their early days lasers tended to be high-maintenance, unstable and difficult to operate. They’ve improved dramatically, making laser enrichment a more attractive prospect than it was during the early research. Even more than technological improvements, a recent geopolitical shift could boost new enrichment technology. Russia has the largest uranium enrichment ecosystem in the world, and the country has historically dominated the market. “Nobody in the West was going to build a new enrichment plant while the Russians flooded the world with enriched uranium,” says Forsberg.  Since the start of the Ukraine war, however, countries including the US and UK have taken steps to limit or ban imports of Russian uranium. That’s opened the door for companies to set up new enrichment operations, including some that use new technologies, Forsberg says. Demand for fuel is increasing as countries look beyond Russia for uranium supply. “The gap is just becoming bigger and bigger, and this technology is right in the middle,” says Christo Liebenberg, president of LIS Technologies, one of the companies aiming to build laser enrichment capacity in the US. LIS Technologies was founded in 2023, and the company recently purchased a 200-acre site in Oak Ridge, Tennessee. It’s currently in the pre-application process with the US Nuclear Regulatory Commission for its facility. The company plans to take in natural-grade uranium and make a product that’s roughly 5% U-235, though it hopes to eventually make more concentrated material that can be used as fuel for next-generation reactors. GLE is taking a different approach: Rather than using its technology to enrich freshly mined material to the 5% concentration that can be used in fuels, it’s hoping to start by rehabilitating old waste. The company has a contract with the US Department of Energy to reprocess waste material at the enrichment site in Paducah. The facility could enrich up to 200,000 metric tons of material that contains small amounts of uranium leftover from an older enrichment process. GLE is taking the material that’s at least 0.25% U-235 and enriching it to about 0.7%. That material can then be further processed and slotted into the uranium supply chain in place of freshly mined material. “It’s kind of like a large aboveground uranium mine for us,” says Nima Ashkeboussi, vice president of government relations and communications at GLE. While each one of its units is more complex and expensive than a centrifuge, far fewer are needed to do the same work. A similar centrifugation plant would have many thousands of centrifuges working together, but a full-scale plant using GLE’s laser enrichment process would have fewer than a thousand of its units, says Stephen Long, the company’s CEO. Up-front investment should be smaller, and operating costs are also expected to be lower, partly because the process uses less energy than centrifuges, Long says. GLE has a testing facility in Wilmington, North Carolina. In fall 2025, the company completed a demonstration pilot, processing several hundred kilograms of uranium.

This story originally appeared in The Algorithm, our weekly newsletter on AI. To get stories like this in your inbox first, sign up here. Reading OpenAI’s account last week of how some of its models broke their containment and hacked into the computer systems of Hugging Face, another AI company, was the first time I got genuine chills about what large language models are now able to do. But this is a case of human hubris, not rogue AI. I am not an alarmist. In fact, I have been pushing back against AI scare stories for years. Even so, this incident crossed a line. I think it’s the clearest illustration yet of how the people building and testing this technology do not fully understand what they’re doing. OpenAI could—and should—have seen this coming. Here’s what happened, at least according to the two companies involved. A couple of weeks ago, OpenAI started testing the hacking abilities of some of its new models, including GPT‑5.6 Sol (released in June) and what OpenAI describes as “an even more capable pre-release model.” OpenAI pitted its models against a benchmark called ExploitGym, released in May, which challenges LLMs to find ways to exploit real-world vulnerabilities found in commonly used software. To see what they could do, the researchers removed most of their cybersecurity guardrails. Then they ran the models inside a sandbox that was cut off from the internet except for one link to a third-party piece of software that acted as a proxy to the outside world, and let them install code that they needed to beat ExploitGym. On July 9, according to reporting by Reuters, OpenAI’s models started trying to break through the proxy. They found an unknown bug in the proxy’s software and used it to access the internet. From there, they broke into Hugging Face’s computer systems on July 11, apparently looking for data sets and solutions that would help them complete their task. Hugging Face announced the hack on July 16.  OpenAI did not realize (or at least did not reveal) that its models were involved until July 21, around 10 days after they broke containment and a week after Hugging Face had shut down the attack and alerted the FBI. In a statement given to MIT Technology Review, OpenAI says: “We are conducting a thorough review along with external advisors and with oversight from our Safety and Security Committee. Once the review is complete, we will publish a technical report of our learnings for everyone.” The firm also confirmed that its researchers were properly using existing safety guidelines and procedures at the time. Wake-up call OpenAI has said the event was unprecedented—and in many ways it was. This was the first time outside of a simulation that LLMs escaped what was thought to be a secure sandbox, accessed the open internet, and attacked an unrelated organization. It’s a wake-up call that shows just how good the latest LLMs are at finding and exploiting vulnerabilities in real-world software with little or no human guidance. And yet at the same time, what OpenAI’s models did is something this technology has done for years. Give a model a goal and it will very often achieve that goal in unexpected ways, finding loopholes that look like cheats. OpenAI itself has studied this behavior. A decade ago, it shared results of an experiment in which a model was tasked with beating a video game called CoastRunners. Human players take it for granted that the way to do this is by racing a boat through a series of flags to the finish line, racking up points for each flag you hit. OpenAI’s model figured out that you could get a high score by spinning in a circle and hitting the same three flags over and over again. There have been dozens of similar examples from researchers since. AI will always find a way. “Despite repeatedly catching on fire, crashing into other boats, and going the wrong way on the track, our agent manages to achieve a higher score using this strategy than is possible by completing the course in the normal way,” OpenAI wrote in a blog post about the CoastRunners experiment in 2016. “While harmless and amusing in the context of a video game, this kind of behavior points to a more general issue … it is often difficult or infeasible to capture exactly what we want an agent to do.” I couldn’t help thinking about CoastRunners when I read OpenAI’s blog post about the Hugging Face attack: “All evidence suggests that the models were hyperfocused on finding a solution for ExploitGym, going to extreme lengths to achieve a rather narrow testing goal … After gaining internet access, the models inferred that Hugging Face potentially hosted models, datasets and solutions for ExploitGym. Knowing this, the model searched for and successfully found ways to gain access to secret information that it could use to cheat the evaluation.” Last week’s news was not about rogue AI, despite the headlines. It was about models achieving the goal they had been given: Find ways to exploit vulnerabilities in software. The fact that those models then behaved in a way OpenAI had not anticipated isn’t surprising. But it is worrying. Back in 2016, OpenAI had this to say about its CoastRunners bot: “More broadly it contravenes the basic engineering principle that systems should be reliable and predictable.” A decade on, those basic engineering principles are still AWOL.  

Sakana AI has released Fugu-Cyber (model ID is fugu-cyber-v1.0), a cybersecurity-specialized addition to its Fugu orchestration family. It is not just a new frontier model. It is a third endpoint on the Fugu orchestrator, tuned for security reasoning. Sakana launched that orchestrator a month earlier. Sakana reports a success rate of 86.9% on CyberGym and 72.1% on CTI-REALM. It describes those results as comparable to cyber-focused frontier models such as GPT-5.5-Cyber and Claude Mythos Preview. What the two benchmarks actually measure The two evaluations sit at opposite ends of a security workflow: CyberGym is a UC Berkeley benchmark of 1,507 real-world vulnerabilities across 188 OSS-Fuzz projects. In its main task, an agent receives a vulnerability description and an unpatched codebase. It must write a proof-of-concept that crashes the pre-patch build but not the post-patch build. That verification step is what makes the benchmark hard to game. CTI-REALM is Microsoft’s open-source detection-engineering benchmark. Microsoft curated 37 public threat reports from sources including Datadog Security Labs, Palo Alto Networks, and Splunk. An agent must map MITRE ATT&CK techniques, explore telemetry, iterate on KQL queries, and emit validated Sigma rules. Scoring covers Linux endpoints, Azure Kubernetes Service, and Azure cloud. Together the pair spans ‘find and prove the bug’ and ‘turn intel into a detection.’ That framing is the most defensible part of Sakana’s announcement. Where 86.9% sits against the field Context matters more than the number. When the CyberGym researchers published their first results, the best agent-model pairing reached roughly 20%. Anthropic reported 83.1% for Claude Mythos Preview under Project Glasswing in April 2026. OpenAI reported 85.6% for its updated GPT-5.5-Cyber, against 81.8% for GPT-5.5. Sakana’s 86.9% is therefore a small step past the reported frontier, not a jump. CTI-REALM is a different story. Microsoft’s own evaluation put the top three configurations, all Claude, in a band from 0.624 to 0.685. Fugu-Cyber’s 72.1% would sit above that band. One caveat matters. CTI-REALM is scored as a trajectory reward between 0 and 1. It is not a pass/fail rate. Sakana calls it a success rate anyway. How the orchestration works Fugu is itself a language model. It is trained to read a query and build an agentic scaffold on the fly. It then delegates sub-tasks to specialist models in a pool. The approach is documented in the Fugu technical report and two ICLR 2026 papers, TRINITY and the Conductor. TRINITY assigns Thinker, Worker, and Verifier roles across multiple LLMs. The Conductor learns natural-language coordination strategies through reinforcement learning. For security work, Sakana research team argues the verifier role is the point. A candidate vulnerability surfaced by one agent gets validated by security-specialized sub-agents before any patch is proposed. Routing remains proprietary, so you cannot see which model handled which step. Access, policy, and price Fugu-Cyber is gated on four dimensions. Access requires an application form stating the intended use case and verified contact details. Sakana team reviews each one manually. The model ships under an updated Acceptable Usage Policy that prohibits offensive misuse. Billing is restricted to the Token Plan. The $20, $100, and $200 subscription tiers cover Fugu and Fugu-Ultra only. And the Fugu API is not offered in the EU or EEA while Sakana works toward GDPR compliance. Pricing is fixed at $6 per million input tokens, $36 output, and $0.60 cached input. All three rates double above a 272K-token context. Every line is exactly 1.2× the Fugu-Ultra rate, a flat 20% premium for the cyber endpoint. Long codebase runs cross 272K easily, so the doubled tier is not an edge case. Key Takeaways Fugu-Cyber is an orchestration endpoint, not a new frontier model, launched July 21, 2026. Sakana reports 86.9% on CyberGym and 72.1% on CTI-REALM, both self-reported and un-replicated. Those scores edge past GPT-5.5-Cyber’s 85.6% and Claude Mythos Preview’s 83.1% on CyberGym. Access is gated: manual approval, defensive-use AUP, Token Plan only, no EU/EEA, no weights. Sakana’s own position is that a capable API along with human security expertise beats the API alone. The post Sakana AI Releases Fugu-Cyber: An Orchestration Model Reporting 86.9% on CyberGym and 72.1% on CTI-REALM appeared first on MarkTechPost.

Most agents that learn from video need to know what action produced each frame. Induction Labs is arguing that this requirement is the bottleneck. Last week, they released imagination models, a foundation model architecture that pretrains on raw video with no action labels at all. Their test system is Photon-1, a sparse 106B-A5B mixture-of-experts (MoE) transformer trained on 18 years of computer demonstration video. On an internal computer use benchmark, Induction Labs reports that Photon-1 beats Gemini 3.1 Flash-Lite while using far less pretraining compute and costing roughly 3× less to serve. What an imagination model actually does An imagination model predicts future frames autoregressively using a next-latent-token-prediction objective. It does not generate pixels during pretraining. Everything is modeled in a learned representation space. The claim that matters is this: predicting future states teaches the model to complete tasks, even though it never sees an action during pretraining. Induction Labs calls this an implicit policy. The model learns concepts of what a person is doing, rather than a label for each mouse click. The compression trick that makes it scale The architecture depends on a vision encoder that uses finite scalar quantization (FSQ). Each frame is compressed into 960 discrete tokens. Each token is an 8-dimensional vector. Each dimension takes one of five values: −1, −1/2, 0, 1/2, 1. That gives a codebook of 5⁸ possible codes. The resulting encoding is about 2.2 KB per frame. Induction Labs reports over 100× better compression than existing OCR and multimodal-model representations, while preserving text, layout and state changes. To hit that rate, Photon-1 uses a differential latent encoder. It encodes video frames as pairs, so the latents describe differences between frames rather than frame contents. Data and pretraining compute The corpus starts from an internal index of 2 billion publicly available videos. Filtering reduces that to roughly 2 million computer screen recordings. An internal keyframe detection model strips redundant frames. The final dataset is 575 million frames, sampled at 1 frame per second. That equals 552 billion tokens, or about 18 years of video. Photon-1 was pretrained from scratch for a single epoch. Training the 106B-A5B MoE at 32K context took approximately 30,000 H200 GPU-hours, or 4.4×10²² training FLOPs. The research team implemented training in PyTorch with custom fused kernels for the vision encoder and MoE layers, sustaining 40% end-to-end MFU. Those three figures are mutually consistent: 30,000 H200-hours at 40% MFU lands almost exactly on 4.3×10²². From imagination to action Induction Labs finetuned Photon-1 on fewer than 35,000 computer use trajectories to teach the action and instruction format. Special computer use tokens let the model emit actions. At inference, Photon-1 predicts the next frame’s state first, then outputs the action that gets there. Online reinforcement learning follows. Rollouts run in real time on virtual machines at scale, and outcomes are verified programmatically to produce reward. The Linux VMs run five desktop environments (LXQt, Xfce, MATE, GNOME and Plasma), each with a Google account for login-restricted web apps and an internal ChatGPT clone with no rate limits. The compute and cost comparison Model Pretraining compute Weighted inference cost / 1M tokens* Gemini 3.1 Flash-Lite 1.200 × 10²⁴ FLOPs $0.36 Photon-1 0.044 × 10²⁴ FLOPs $0.11 *Weighted at a 10:1 input-to-output token ratio, which Induction Labs says matches its computer use tests. Two caveats belong next to that table. First, the Gemini figure is Induction Labs’ own conservative estimate, assuming 8B active parameters and 25T pretraining tokens. Taken at face value the ratio is about 27×, not the 30× headline; Induction Labs states “at least 30×” on the basis that the true Gemini number is likely higher and the model was likely distilled. Second, the benchmark is internal and unreleased, so the result is not independently reproducible today. Photon-1’s own breakeven cost on Induction Labs’ hardware is $0.06 per 1M input tokens and $0.60 per 1M output tokens, with no speculative decoding. Does it generalize past the desktop? This is the more interesting test, because Photon-1 saw only computer use video. The research team finetuned it on domains absent from pretraining and compared against two baselines: a vision encoder baseline with the same architecture and size but no imagination pretraining, and an LLM baseline (Ling-flash-2.0 from Inclusion AI, pretrained on 20T tokens). On 20,000 tournament checkers games from the Open Checkers Archive 2.0, Photon-1 beat both baselines on world simulation and on move quality. On 10,000 synthetically generated billiard games simulated at 5 fps, it produced a mean absolute error of 0.47 against the ground-truth physics engine, versus 1.15 for the LLM baseline and 1.44 for the vision encoder baseline. Photon-1 also picked up human priors from the pretraining video. After RL, it learned to use the in-VM ChatGPT clone to draft artifacts and answer knowledge questions, steering the LLM the way a person would. Key Takeaways Photon-1 learns an implicit policy from 18 years of screen recordings with zero action labels, using next-latent-token prediction. FSQ compresses each frame to 960 tokens (~2.2 KB), a reported 100× gain over OCR and multimodal representations. Trained for ~30,000 H200 GPU-hours, it beats Gemini 3.1 Flash-Lite on an internal benchmark at ~27× less pretraining compute. Despite seeing only desktop video, it beats an LLM baseline at checkers and billiard physics after finetuning. No weights, no API, no license — this is a research result, not a deployable model. Check out the full technical writeup from Induction Labs and the announcement thread on X. All credit for this research goes to the researchers of this project. The post Induction Labs Photon-1 Simulates Desktops, Plays Checkers, and Models Billiard Physics From One Pretraining Run appeared first on MarkTechPost.

In this tutorial, we explore FAIRChem v2 and the UMA universal machine-learning interatomic potential as a unified framework for atomistic simulation across molecular chemistry, catalysis, and inorganic materials. We configure an environment, authenticate with Hugging Face to access the gated UMA model weights, and initialize task-specific calculators for the omol, oc20, and omat domains. We then apply the same pretrained potential to a broad set of computational chemistry workflows, including single-point energy and force prediction, molecular geometry optimization, spin-state comparison, reaction-energy estimation, vibrational analysis, surface adsorption, crystal-cell relaxation, equation-of-state fitting, molecular dynamics, and potential-energy surface scanning. Throughout the tutorial, we integrate FAIRChem with the Atomic Simulation Environment to manage atomic structures, optimizers, constraints, thermodynamic calculations, and trajectory analysis while using GPU acceleration whenever it is available. Copy CodeCopiedUse a different Browser import importlib.util, subprocess, sys, os def _pip(*pkgs): subprocess.check_call([sys.executable, “-m”, “pip”, “install”, “-q”, *pkgs]) if importlib.util.find_spec(“fairchem”) is None: print(“>> Installing fairchem-core, ase, and helpers (takes ~2-4 min)…”) _pip(“fairchem-core”, “ase”, “matplotlib”, “huggingface_hub”) print(“>> Installation done.”) else: print(“>> fairchem already installed.”) from huggingface_hub import login, whoami def hf_authenticate(): token = None try: from google.colab import userdata token = userdata.get(“HF_TOKEN”) except Exception: pass token = token or os.environ.get(“HF_TOKEN”) try: whoami() print(“>> Already authenticated with Hugging Face.”) return except Exception: pass if token is None: from getpass import getpass token = getpass(“Paste your Hugging Face access token: “).strip() login(token=token) print(“>> Hugging Face login OK.”) hf_authenticate() import numpy as np import torch import matplotlib.pyplot as plt from fairchem.core import pretrained_mlip, FAIRChemCalculator DEVICE = “cuda” if torch.cuda.is_available() else “cpu” print(f”>> Using device: {DEVICE}”) MODEL = “uma-s-1p2″ predictor = pretrained_mlip.get_predict_unit(MODEL, device=DEVICE) calc_mol = FAIRChemCalculator(predictor, task_name=”omol”) calc_cat = FAIRChemCalculator(predictor, task_name=”oc20″) calc_mat = FAIRChemCalculator(predictor, task_name=”omat”) print(f”>> Loaded {MODEL} with omol / oc20 / omat calculators.”) We install the required FAIRChem, ASE, visualization, and Hugging Face dependencies while ensuring the setup remains safe to rerun in Google Colab. We authenticate with Hugging Face to access the gated UMA model weights and automatically detect whether GPU acceleration is available. We then load the UMA predictor and create separate calculators for molecular, catalysis, and materials simulations. Copy CodeCopiedUse a different Browser from ase.build import molecule from ase import Atoms print(“n” + “=”*70) print(“SECTION 2: Single-point energetics of water (omol task)”) print(“=”*70) h2o = molecule(“H2O”) h2o.info.update({“charge”: 0, “spin”: 1}) h2o.calc = calc_mol E_h2o = h2o.get_potential_energy() F_h2o = h2o.get_forces() print(f”E(H2O) = {E_h2o:.4f} eV”) print(f”Max |force| = {np.abs(F_h2o).max():.4f} eV/A”) def atom_energy(symbol, spin): a = Atoms(symbol, positions=[[0, 0, 0]]) a.info.update({“charge”: 0, “spin”: spin}) a.calc = calc_mol return a.get_potential_energy() E_O = atom_energy(“O”, spin=3) E_H = atom_energy(“H”, spin=2) E_atomization = -(E_h2o – E_O – 2 * E_H) print(f”Atomization energy of H2O = {E_atomization:.3f} eV ” f”(experiment ~ 9.5 eV incl. ZPE effects)”) from ase.optimize import LBFGS print(“n” + “=”*70) print(“SECTION 3: Relaxing a deliberately distorted water molecule”) print(“=”*70) h2o_bad = molecule(“H2O”) h2o_bad.positions[1] += [0.25, -0.10, 0.05] h2o_bad.info.update({“charge”: 0, “spin”: 1}) h2o_bad.calc = calc_mol opt = LBFGS(h2o_bad, logfile=None) energies_opt = [] opt.attach(lambda: energies_opt.append(h2o_bad.get_potential_energy())) opt.run(fmax=0.01, steps=200) d_OH = h2o_bad.get_distance(0, 1) ang = h2o_bad.get_angle(1, 0, 2) print(f”Converged in {opt.get_number_of_steps()} steps”) print(f”O-H bond length = {d_OH:.3f} A (expt ~0.958 A)”) print(f”H-O-H angle = {ang:.1f} deg (expt ~104.5 deg)”) plt.figure(figsize=(5, 3.2)) plt.plot(energies_opt, “o-“) plt.xlabel(“Optimizer step”); plt.ylabel(“Energy (eV)”) plt.title(“H2O geometry optimization”); plt.tight_layout(); plt.show() We use the molecular UMA calculator to evaluate the energy, atomic forces, and atomization energy of a water molecule. We define isolated hydrogen and oxygen reference atoms with the correct spin multiplicities to construct the atomization-energy calculation. We then distort the water geometry, relax it with the LBFGS optimizer, and analyze the converged bond length, bond angle, and energy trajectory. Copy CodeCopiedUse a different Browser print(“n” + “=”*70) print(“SECTION 4: CH2 singlet-triplet gap (UMA is spin-aware!)”) print(“=”*70) singlet = molecule(“CH2_s1A1d”); singlet.info.update({“charge”: 0, “spin”: 1}) triplet = molecule(“CH2_s3B1d”); triplet.info.update({“charge”: 0, “spin”: 3}) singlet.calc = FAIRChemCalculator(predictor, task_name=”omol”) triplet.calc = FAIRChemCalculator(predictor, task_name=”omol”) gap = triplet.get_potential_energy() – singlet.get_potential_energy() print(f”E(triplet) – E(singlet) = {gap:.3f} eV ” f”(negative => triplet ground state; expt ~ -0.39 eV)”) print(“n” + “=”*70) print(“SECTION 5: Reaction energy of CH4 + 2 O2 -> CO2 + 2 H2O”) print(“=”*70) def relaxed_energy(name, spin=1): m = molecule(name) m.info.update({“charge”: 0, “spin”: spin}) m.calc = FAIRChemCalculator(predictor, task_name=”omol”) LBFGS(m, logfile=None).run(fmax=0.02, steps=200) return m.get_potential_energy() E = { “CH4”: relaxed_energy(“CH4”), “O2”: relaxed_energy(“O2”, spin=3), “CO2”: relaxed_energy(“CO2”), “H2O”: relaxed_energy(“H2O”), } dE_rxn = (E[“CO2”] + 2*E[“H2O”]) – (E[“CH4”] + 2*E[“O2″]) print(f”Delta E (electronic) = {dE_rxn:.2f} eV = {dE_rxn*96.485:.0f} kJ/mol”) print(“Experimental combustion enthalpy ~ -890 kJ/mol (ZPE/thermal not included here)”) from ase.vibrations import Vibrations print(“n” + “=”*70) print(“SECTION 6: Vibrational frequencies of relaxed H2O”) print(“=”*70) vib = Vibrations(h2o_bad, name=”vib_h2o”) vib.run() freqs = np.real(vib.get_frequencies()) real_modes = [f for f in freqs if f > 200] print(“Vibrational modes (cm^-1):”, “, “.join(f”{f:.0f}” for f in real_modes)) print(“Experimental H2O: 1595 (bend), 3657 (sym stretch), 3756 (asym stretch)”) print(f”Zero-point energy = {vib.get_zero_point_energy():.3f} eV”) vib.clean() We compare the singlet and triplet electronic states of methylene to calculate its spin-state energy gap. We relax methane, oxygen, carbon dioxide, and water before combining their predicted energies to estimate the electronic reaction energy of methane combustion. We also perform a finite-difference vibrational analysis of relaxed water to obtain its normal-mode frequencies and zero-point energy. Copy CodeCopiedUse a different Browser from ase.build import fcc100, add_adsorbate from ase.constraints import FixAtoms print(“n” + “=”*70) print(“SECTION 7: CO/Cu(100) relaxation + adsorption energy (oc20 task)”) print(“=”*70) slab = fcc100(“Cu”, size=(3, 3, 3), vacuum=8.0, periodic=True) slab.set_constraint(FixAtoms(mask=[a.tag > 1 for a in slab])) add_adsorbate(slab, molecule(“CO”), height=2.0, position=”bridge”) slab.calc = calc_cat opt = LBFGS(slab, logfile=None) opt.run(fmax=0.05, steps=300) E_slab_ads = slab.get_potential_energy() print(f”Relaxed CO/Cu(100) in {opt.get_number_of_steps()} steps, ” f”E = {E_slab_ads:.3f} eV”) clean = fcc100(“Cu”, size=(3, 3, 3), vacuum=8.0, periodic=True) clean.set_constraint(FixAtoms(mask=[a.tag > 1 for a in clean])) clean.calc = FAIRChemCalculator(predictor, task_name=”oc20″) LBFGS(clean, logfile=None).run(fmax=0.05, steps=300) E_clean = clean.get_potential_energy() co = molecule(“CO”); co.info.update({“charge”: 0, “spin”: 1}) co.calc = FAIRChemCalculator(predictor, task_name=”omol”) LBFGS(co, logfile=None).run(fmax=0.02, steps=100) E_co = co.get_potential_energy() E_ads = E_slab_ads – E_clean – E_co print(f”E(clean slab) = {E_clean:.3f} eV, E(CO gas) = {E_co:.3f} eV”) print(f”Adsorption energy (naive cycle) = {E_ads:.3f} eV”) print(“(oc20 uses its own DFT reference scheme; for publication-grade numbers”) print(” keep all species within a consistent task/reference framework.)”) We construct a periodic

The KwaiKAT Team at Kuaishou has introduced the KAT-Coder-V2.5. It is a coding model trained to operate inside real, executable repositories rather than emit single-turn code. The served model is available through StreamLake. An open-weight variant, KAT-Coder-V2.5-Dev, was released separately on Hugging Face under Apache-2.0. AutoBuilder: environments that actually run the intended tests The research frames a verifiable task as a triplet. It needs a precise task description, an executable repository environment, and a set of validation tests. A patch is correct only if it passes all of them. Tasks are mined from real pull requests and commits, following the SWE-bench lineage. The merged code change supplies a golden patch and the accompanying test change supplies a test patch. Raw issue text is discarded as a specification. Instead, descriptions are regenerated into three parts: a problem statement grounded in the golden patch, requirements derived from the test patch, and interface constraints inferred from both. A clarity check then drops anything ambiguous, incomplete, underspecified, or internally inconsistent. AutoBuilder handles the environment side. A build agent analyzes the repository and writes a configuration script that installs dependencies and runs tests from a clean checkout. A verification agent executes that script in an isolated sandbox. The acceptance rule is the interesting part. Verification does not read exit codes or grep log patterns. It parses structured test-framework output, and accepts an environment only when more than 90% of expected tests are collected and pass/fail outcomes reproduce across runs. Failures are fed back as structured information for iterative repair. Combining a preconfigured base environment, build-system templates, and a retrievable library of distilled build recipes raised the construction success rate from 16.5% to 57.2%. The result is over 100,000 verifiable environments spanning 12 languages. Git history, commit metadata, and other exploitable traces are stripped so agents cannot read the reference solution out of the repo. Data Scaling Flywheel: filtering on process Filtering trajectories by final test success is misleading. Some passing runs rely on hard-coding, mechanism bypassing, or test-oriented shortcuts. Some failing runs contain valuable search, localization, and repair behavior. KwaiKAT addresses both directions. For near misses, targeted process-level hints indicate what to inspect or verify without revealing the solution. That alone raises the pass rate of previously zero-pass tasks to roughly 20%. Because hinted trajectories contain information unavailable at inference, the verified patch is then fixed and a hint-free trajectory is regenerated from the original task context. Only samples that pass verification, show no hint leakage, and stay consistent with the patch are retained. For passing runs, rule-based gates remove invalid, unstable, or exploitative trajectories. A scoring stage then rates exploration, localization, pre-edit reasoning, specification fidelity, repository conventions, patch minimality, verification quality, recovery behavior, and honesty. A third mechanism targets harness overfitting. Tool names, argument conventions, output formats, and prompt templates are randomized while functionality is preserved. Because verification is anchored to test outcomes rather than harness traces, one task can be re-served under many harness configurations. Realistic perturbations are injected too: missing dependencies, transient command failures, truncated outputs, and noisy logs. Explore the pipeline and the numbers Infrastructure failures capped rewards before algorithmic limits During KAT-Coder-V2 training, slow reward curves were initially blamed on the RL algorithm. However, an audit revealed that ~16% of trajectories failed due to sandbox infrastructure issues rather than the model policy, with boundary misalignments sometimes emptying observations for ~40 steps and corrupting rewards. Three infrastructure fixes followed. First, an early-release image eviction policy lowered disk usage from 95% to 60%, reducing timeout-induced invalid rollouts from 6–7% to under 1%. Second, correcting environment variables during remote sandbox initialization stopped system overrides that flipped rewards on 6–7% of samples, cutting errors below 1%. Third, the Gateway Server bypassed mainstream chat endpoints—which caused 40% token drift at a ~200-turn scale by re-applying apply_chat_template and re-tokenizing—and called /generate directly to ensure rollout token alignment. Together, these updates reduced the sandbox feedback error rate from roughly 16% to below 2% and cut training collapses by an order of magnitude. Asymmetric PPO and a three-tier reward The research team chose PPO with GAE over critic-free trajectory methods because production harnesses split sessions into structurally distinct samples, complicating group baselines. Using asymmetric actor–critic, the Critic gets privileged training context (rewards, tests, coverage, patches, metadata, future turns), while the Actor sees only rollout state. The Critic and extra context are discarded at inference. Rewards are three-tiered: Core Task Scores require all fail_to_pass and pass_to_pass tests to pass; Standard Behavior Constraints penalize duplication, bad tool calls, and debug remnants; Failed Trajectory Incentives score file retrieval via F2 and give partial test credit. Five experts fuse via Multi-Teacher On-Policy Distillation using reverse KL, an off-policy start, and drift-aware truncation from Prune-OPD. Results Under a unified Claude Code harness, KAT-Coder-V2.5 leads its panel on PinchBench with 94.9, beating Opus 4.8 at 93.5. It places second on SWE-Bench Pro (65.2 vs 69.2) and the internal KAT Code Bench (53.1 vs 57.3). However, it lags on Terminal-Bench 2.1, placing last with 60.7 behind GLM-5.1 (61.8) and Opus 4.8 (84.6). On SciCode, it scores 50.3, matching GLM-5.2. Notably, the open-weight KAT-Coder-V2.5-Dev is a separate 35B-total / 3B-active MoE post-trained on Qwen3.6-35B-A3B using 127K SFT examples, then RL. Evaluated on a separate in-house protocol, its results are not comparable to the main flagship table. Key Takeaways KwaiKAT treats agentic coding as an infrastructure problem, not a model-scale problem. AutoBuilder lifted environment construction success from 16.5% to 57.2%, yielding 100,000+ verifiable environments across 12 languages. A sandbox audit found ~16% of RL trajectories failed because of the sandbox, not the policy; fixes cut that to below 2%. KAT-Coder-V2.5 tops PinchBench at 94.9 and ranks second on SWE-Bench Pro at 65.2, behind Opus 4.8. The open-weight KAT-Coder-V2.5-Dev is a separate 35B-A3B MoE under Apache-2.0, with its own benchmark numbers. Check out the Paper, the Model Weight on Hugging Face, and the Product Page. All credit for this research goes to the researchers of this project. The post KwaiKAT Team Releases KAT-Coder-V2.5: An Agentic Coding Model