Committee

As companies scale, the technology supporting operations can become a liability just as quickly as it becomes an asset. Disconnected systems, site-specific tools, spreadsheets, and manual workarounds can create data silos that make it harder to spot problems early, coordinate responses, and make decisions with confidence. For Jabil, a global manufacturing company with more than 100 sites across more than 30 countries, the answer has been to make integration and simplification a priority. The company adopted a “simplify-first, then-innovate mindset,” says Harish Manohar, SAP IT director at Jabil, recognizing that adding new technologies without first reducing complexity risks creating more risk. The goal is to standardize processes, consolidate where possible, and establish a more consistent data backbone across the organization. “Any innovation without simplification is going to add more complexity,” Manohar says. That philosophy also changes how Jabil approaches modernization. “Any modernization or transformation should add measurable business value,” Manohar says. The company is focused on connecting processes end-to-end across its supply chain and creating a foundation that can scale consistently across regions. Integration comes first because, as Manohar puts it, “the backbone of any contemporary or modern organization is data.” Before organizations can optimize, automate, or apply AI, data needs to flow seamlessly across systems. But doing that across a global organization is hardly straightforward. Jabil’s more than 100 sites operate with different levels of process maturity, legacy systems, and localized workflows, while regulated businesses bring additional compliance requirements. As such, standardizing across different regions and business environments means changing processes and governance without disrupting the operations already in place. The value of that work extends beyond the technology to the people using it. Integrated workflows can offer employees shared visibility into data, reduce manual data reconciliation, and help them move from chasing information to acting on insights. For Jabil, the aim is also to improve real-time visibility into supply chain events, which can enable faster responses to disruptions and reduce operational risk. Looking to the future, that foundation could make AI and automation all the more useful and scalable. With trusted data and integrated systems in place, Jabil is exploring predictive supply chain insights, intelligent exception handling, and AI-driven planning and forecasting. To Manohar, the takeaway is clear: “Simplicity at scale is a very competitive advantage,” and technology investments must ultimately connect to business value and operational resilience. This episode of Business Lab is produced in partnership with SAP. Full Transcript: Megan Tatum: From MIT Technology Review, I’m Megan Tatum, and this is Business Lab, the show that helps business leaders make sense of new technologies coming out of the lab and into the marketplace. Our topic today is enterprise technology integration, and how the benefits of consolidating tools and systems across the supply chain help organizations operate more reliably at scale. When companies reduce tool sprawl and connect their systems more effectively, they gain earlier visibility, faster response, and greater resilience across production lines. My guest today is Harish Manohar, SAP IT Director at Jabil. Jabil has been on a journey to simplify its technology landscape by using SAP Integration Suite as the foundation to connect systems, retire fragmented tools, and enable more consistent operations globally. This podcast is produced in partnership with SAP. Welcome, Harish. Harish Manohar: Hello, Megan. Good morning. Megan: Thank you so much for being here, Harish. Just to start, if we could set some context, can you give us a quick overview of Jabil, the business and its overall transformation journey? Harish: All right. So, about Jabil. Jabil is a global manufacturing company headquartered in St. Petersburg, Florida, USA. We have about 60 years of experience offering comprehensive engineering, supply chain, and manufacturing solutions across different industries. We have a global footprint of about over 100 different sites across 30-plus countries, 140,000-plus employees. We are a trusted partner for more than 400 of the world’s top brands. That’s a little bit about Jabil. Megan: Fantastic. And a lot of scale there, as you’re referring to some of the stats there. As things have got more complex, where did disconnected tools and systems start to slow you down, and what ultimately drove you to make integration a really strategic priority? Harish: I talked about our global footprint across 100-plus sites. With a global footprint always comes complexity about site-specific tools. All of our sites have been in business for a long time, and over the period of years, they had their own tools for their own processes. It’s a little bit disconnected. When we are looking to scale, the first thing we wanted to start looking at is what is this mix of site-specific tools, manual workarounds, spreadsheet-based processes, legacy applications, whatnot? That’s a big technical debt that we have had over the last 25 years. That’s where we started, and that is what led Jabil to make integration a strategic priority because we had limited ability to see issues early across plants, across regions, which would help us to coordinate responses consistently, and also to be able to scale those responses consistently. This complexity created data silos, and in a way delayed robust decision-making. As the complexity increased globally, integration became extremely critical to a few things. It was critical to establishing a single trusted data backbone, which would directly enable faster coordinated responses across the network. We at Jabil, as part of our transformation journey, believe that having the right data at the right time fundamentally changes how we respond to disruptions, which is all about a manufacturing business. How we respond to disruptions. This is where we started our strategic priority towards having a integrated system that drove data consistency across our landscape. Megan: Fantastic. As you have outlined there, there was obviously a real commercial need for this, but how did you think about bringing in those new technologies without adding even more complexity to the mix? Harish: Great question. Whenever we talk about transformation, we talk about all these bleeding-edge technologies that are out there today when

Teams running coding agents hit the same wall. Claude Code speaks the Anthropic Messages API, Codex CLI speaks OpenAI, and the model a team actually wants to serve sits behind vLLM, NVIDIA NIM, or Ollama. Rewriting the agent is not an option, so the translation layer has to live somewhere else. Switchyard is NVIDIA’s answer: a Rust proxy and library for LLM traffic that routes requests across providers, translates between OpenAI and Anthropic formats, records operational metrics, and exposes typed, composable routing algorithms. It is released under Apache 2.0 with documentation at docs.nvidia.com/nemo/switchyard. Is it deployable? Yes, but for evaluation only. The binary installs from crates.io and the launcher from PyPI, and it self-hosts anywhere, but NVIDIA labels Switchyard pre-alpha and experimental, warns it is not for production use, and expects the API and algorithms to change significantly before v1.0. What Switchyard does Clients keep their native API. Switchyard decodes the inbound request into provider-neutral Rust types, runs a routing algorithm to pick a backend, re-encodes the request in that backend’s own wire format, calls it, and translates the response, including streaming events, back into the shape the client expects. The server accepts three inbound formats: OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages. Any of the three can address any route, and each configured LLM client selects one upstream format of its own. That decoupling is the point: the agent’s API and the backend’s API no longer have to match. Three ways to run it The launcher path targets coding agents. Install the published tool with uv tool install –python 3.12 “nemo-switchyard[cli]”, then run switchyard launch claude, switchyard launch codex, or switchyard launch openclaw against a packaged deployment or your own TOML file. The server path installs the standalone proxy with cargo install –locked switchyard-server, validates a config with –dry-run, and serves on a host and port you choose. The library path uses switchyard-libsy, which embeds the routing algorithms in a Rust application without owning an HTTP stack. It never calls a model itself; the algorithm decides which target to use and hands every model call back to the caller. Routing algorithms A route is one client-visible model ID plus the algorithm behind it. The server supports: passthrough sends every request to one target. random splits traffic across targets using optional relative weights, with an optional seed that reproduces the selection sequence. This is the A/B and cost-experiment path. llm_classifier calls a classifier target for a capability verdict, then routes to a weak or strong target. base_threshold is required; min_confidence, capability_elevated_floor, and session_affinity tune it, and anything the judge cannot decide falls through to the strong target. Setting mode = “escalation” runs every turn on the weak tier first and lets a judge decide whether to rerun it on the strong tier. stage_router scores tool-result and agent-progress signals from recent turns to pick a capable or efficient target, avoiding an extra classifier call on most turns. Strong, weak, capable, and efficient are roles inside a route, not fixed properties of a model. The same upstream model can serve different roles in different routes. Observability GET /metrics returns Prometheus text from the server’s process-wide OpenTelemetry provider. The families cover requests, errors, model-call latency, full-turn latency, prompt, completion, cached, cache-creation, and reasoning tokens, and upstream HTTP attempts by outcome and code. A tier label carries strong or weak for distinguishable classifier decisions, and classifier calls are excluded from those families. The more interesting metric is switchyard_routing_overhead_ms, which reports the algorithm’s run time minus the call that served the request. Classifier calls are not subtracted, so an LLM-classifier route reports its classification time here while passthrough and random report the sub-millisecond cost of picking a target. Buckets start at 0.1 ms. Separately, –routing-log-file appends a JSON record per completed response, and GET /v1/routing/session-stats returns per-session call and token totals from that log. Configuration A TOML deployment has three layers: llm_clients define base URL, wire format, credential environment variable, and retry policy; targets bind one upstream model ID to a client; routes expose one client-visible model ID and its algorithm. Secrets never sit in the file, since api_key_env only names an environment variable. max_retries defaults to 2 and applies to transport failures, timeouts, HTTP 408/429, and 5xx responses. Key Takeaways Switchyard is an Apache-2.0 Rust proxy and library that routes and translates LLM traffic. It bridges OpenAI Chat, OpenAI Responses, and Anthropic Messages in both directions, including streams. Four route types ship: passthrough, random, LLM-classifier, and signal-driven stage router. Prometheus metrics isolate routing overhead from model-call latency, per model and tier. It is pre-alpha and explicitly not for production, so treat it as an evaluation tool. Check out the GitHub Repo and Documentation. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Meet Switchyard: A Rust Proxy and Library That Routes and Translates LLM Traffic Across OpenAI and Anthropic APIs appeared first on MarkTechPost.

Coding agents spend a large share of their tool budget on search. When the target is a known symbol, ripgrep answers it exactly. When the target is a behavior described in plain language, keyword matching often misses, and the agent falls back to guessing terms, reading whole files, and assembling context by hand. Each of those detours costs tool calls, tokens, and wall-clock time. The Qwen Developer team announced zg (zvec-grep), an open-source local-first search layer that puts semantic search, BM25, and ripgrep behind one interface for both humans and agents. The code ships under the zvec-ai GitHub organization with an Apache 2.0 license. Is it deployable? Yes, today. It installs from npm as @zvec/zvec-grep, requires Node.js 22 or newer on macOS, Linux, or Windows, needs no GPU with the default model, and the Apache 2.0 license permits commercial use. One index, four retrieval routes zg indexes a workspace once and then exposes several ways to query it. The retrieval pipeline docs define four routes: a hybrid default that combines intent with lexical anchors, –fts for BM25-ranked exact terms, –vector for conceptual similarity with no lexical ranking, and –rg for exhaustive literal or regex matching. The first three read the index. The –rg route needs no index at all, which matters when a repository has not been indexed yet. An anonymous workspace index lives in <root>/.zvec-grep/. Both .git and .zvec-grep are always excluded, along with common dependency, build, cache, and log directories, plus anything the repository’s own ignore rules exclude. Re-running zg index updates incrementally; changing the embedding model requires an explicit –rebuild because vector spaces from different models are incompatible even at matching dimensions. Indexed results report a freshness state of fresh or possibly_stale, so an agent can act on a good-enough result instead of running a status preflight first. The MCP surface agents actually see zg install detects Codex, Claude Code, Cursor, and OpenCode on the machine and wires up the local MCP integration. The server speaks Streamable HTTP MCP on a loopback-only endpoint at http://127.0.0.1:7999/mcp, with optional bearer authentication. The design decision worth noting is restraint. Per the MCP guide, the default agent toolset exposes exactly two tools: zvec_grep_search for when the intent is known but the exact string is not, and zvec_grep_rg for when a symbol, path, or regex is known. Index lifecycle stays with the CLI. A six-tool compatibility set that adds index create, drop, status, and server status exists but is opt-in through zg server on –mcp-toolset full, and the docs state that an agent must never silently create, rebuild, or delete a persistent index. Output is shaped for context economy. Results come back grouped by file with line spans, and indexed source previews are omitted by default unless requested. zg also rejects output-changing ripgrep flags such as –json, –count, -l, and –vimgrep so the compact result format holds. Embeddings run on device by default The embedding catalog currently documents ten local models and three remote Qwen endpoints. The quickstart default, local/potion-code-16m-v2, is a Model2Vec static model with a 256-dimension output and an 8,192-token input limit; because it uses static vector lookup, selecting a GPU does not speed it up. Heavier local options include jina-embeddings-v2-base-code, embeddinggemma-300m, and qwen3-embedding-0.6b. Remote options run to qwen/qwen3.7-text-embedding at 128,000 input tokens and the multimodal qwen/qwen3-vl-embedding. Remote use is gated. Configuring a provider credential does not authorize data transfer; that requires either –allow-remote for a single command or a signed workspace grant via zg auth grant, revocable with zg auth revoke. The launch post cites eleven on-device models against ten in the current docs, a small discrepancy worth flagging. What the benchmark numbers say The evaluation numbers appear in the launch post, not in the repository, where the benchmarks section is still a placeholder. Both runs were paired A/B tests holding agent, model, prompt, runtime, and task constraints fixed, with the zg condition adding only a prebuilt index, MCP tools, and usage guidance. Index build cost is excluded from the tables. On a 20-question SWE-QA-Bench sample, zg cut tool calls by more than half and input tokens by nearly half while raising the Judge score by 1.50 points. On an 80-question BrowseComp-Plus sample, accuracy moved from 98.67% to 99.00% while input tokens fell 37.56%, tool calls 43.52%, and agent time 38.58%. Separately, indexing the Django repository (3,457 files) is reported to finish in under 30 seconds on an Apple M4 Pro. Sample sizes of 20 and 80 questions are small, and the reported reductions come from the vendor’s own runs, so independent replication is the obvious next step. Interactive explainer Key Takeaways zg unifies ripgrep, BM25, and vector search behind one local-first interface for humans and agents. The default MCP toolset exposes only two tools; index lifecycle stays with the CLI by design. Indexing, embedding, and retrieval run on device; remote embeddings need explicit per-command or workspace authorization. Vendor A/B runs report roughly 40% to 50% cuts in tool calls and input tokens on small samples. Apache 2.0, npm-installable, Node.js 22+, no GPU needed with the default model. Check out the zvec-ai/zvec-grep, Qwen Developers launch post and Roadmap. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Qwen Developers Open-Sources zg (zvec-grep): A Local-First Search Layer Unifying ripgrep, BM25, and Vector Search appeared first on MarkTechPost.

For years, legacy technology has been a problem companies knew they needed to solve, but one they often struggled to tackle. The cost, complexity, and risk of replacing business-critical systems could make modernization feel like a disruption to manage instead of an opportunity to pursue. But with the rise in customer expectations and the changes AI brought to the economics of software development, that calculation is changing. Bupa’s modernization of its My Bupa mobile application offers a case study in what becomes possible when a legacy migration is treated as a business transformation rather than a technology rewrite. Bupa CIO of health insurance Asifa Sherazi describes the risks of waiting for legacy systems to become an emergency: “The end-of-life technology is a risk that compounds quietly, and then arrives all at once.” For Bupa, moving its application from Xamarin to native Swift and Kotlin improved the app rating from 3.7 to 4.7, while the user-perceived crash rate fell by nearly 24 percentage points on Android and eight points on iOS. “What they’ll notice is that when they need us, often at a stressful moment, it just simply works,” Sherazi says. Sanjeev Tripathi, senior vice president and region head of BFSI, healthcare, and public sector for Australia, New Zealand, and Southeast Asia at Infosys, contends that AI is helping change the equation. “The emergence of AI is fundamentally shifting the economics of modernization,” he says, reducing the effort, risk, and time traditionally associated with these programs. At Bupa, combining AI-assisted reverse engineering with forward engineering helped deliver the transformation in approximately 60% less time than would have been possible in the pre-AI era. Sherazi and Tripathi also highlight the human dimension of modernization: preserving institutional knowledge, giving teams capacity to adapt, and creating an environment where employees can surface problems early. Looking ahead, both experts see modernized platforms as foundations for more personalized, predictive and AI-driven experiences. The payoff of modernization may be less about replacing aging technology and more about building the flexibility needed for whatever comes next.  “Modern platforms will become the base for far more intelligent AI-driven ecosystems, where AI is not just an add-on, but it is built into everything from design to operations. That’s how the modern platforms will evolve, and the customer experiences will become far more personalized and predictive,” says Tripathi. For Sherazi, that shift is already changing the questions organizations can ask: “It used to be, can our platform support that? Now, it’s: is that the right thing to do for our customers?” This episode of Business Lab is produced in partnership with Infosys. Full Transcript: Megan Tatum: From MIT Technology Review, I’m Megan Tatum, and this is Business Lab, the show that helps business leaders make sense of new technologies coming out of the lab and into the marketplace. Our topic today is legacy modernization. Companies across industries continue to struggle to bring AI modernization to legacy technology stacks, increasing the risk of losing vendor support, degraded customer experience, and limited capacity for innovation. Two words for you: future-ready foundation. My guests are Asifa Sherazi, who is CIO of health insurance at Bupa, and Sanjeev Tripathi, who is senior vice president, region head of BFSI, healthcare, and public sector for Australia, New Zealand, and Southeast Asia at Infosys. This podcast is produced in association with Infosys. Welcome, Asifa and Sanjeev. Asifa Sherazi: Thank you, Megan. Delighted to be here. Sanjeev Tripathi: Thanks, Megan. Wonderful to be here. And good talking to you again, Asifa. Megan: Thank you both so much for being here. Asifa, if I could start with you just to set the context for our conversation. There are seven million healthcare customers across the Asia-Pacific. Could you tell us a bit more about Bupa and the challenges it’s faced in its modernization plan? Asifa: Yes, absolutely. Let me start with something about Bupa that shapes everything we do. We are a global healthcare organization. Think hospitals, clinics, dental, age care, digital health, alongside our insurance business. We reinvest back into the organization, so into our services, our capability, our teams, and our outcomes that we deliver for our customers. In Asia-Pacific, we serve around, as you said, seven million customers across health insurance and health services, individuals, families, corporate clients, patients. Our purpose, helping people live longer, healthier, happier lives is more than just a statement. It actually shapes our strategy, guides our investment decisions, and influences the choices our teams make every day. Now, for most of our health insurance members, the day-to-day digital relationship with Bupa begins through My Bupa, our self-service platform. It’s the front door for managing cover, updating policy details, submitting claims, checking entitlements. Alongside of it, Blua plays a complimentary role. Where My Bupa helps members manage their cover, Blua helps them manage their health, digital healthcare services, clinical support, preventative health. And together, they let us move beyond transactional interactions towards more personalized, proactive care. Here was our challenge. Our mobile app, My Bupa, was built on Xamarin, and Microsoft support for it ended sometime in 2024. We had extended support in place, so our customers remained protected throughout, but we were clear-eyed that this was a bridge, not a destination. The runway was finite, and it was shortening for us. We made the decision to modernize from a position of stability proactively for the long-term safety and experiences of our customer rather than waiting until circumstances forced our hand, because the platform carrying our most important customer relationship was in effect standing still while the world around it was moving. Megan: Right. So you decided to act really proactively in that sense. And so, Asifa, what are some of the risks then of sticking with end-of-life technologies, and how will moving away from legacy technologies help you improve the customer experience? Asifa: Yeah. Look, the end-of-life technology is a risk that compounds quietly, and then arrives all at once. We saw it in three ways. The first is security and compliance.

A nonprofit organization called the Fermi Explorer Mission announced today that it intends to launch a spacecraft to our nearest star system by the end of 2029.  It’s a hugely ambitious mission—if all goes well, the spacecraft could take up to 80,000 years to arrive at Alpha Centauri, which is 4.4 light-years away. And the spacecraft will follow a novel trajectory discovered by an AI system developed by Physical Superintelligence (PSI), an AI physics research lab. PSI is launching today with $58 million in funding led by Breakthrough Energy, a climate-focused investment group founded by Microsoft cofounder Bill Gates. It’s not the first time this has been tried. In 2016, the billionaire tech investor Yuri Milner announced an interstellar mission called Breakthrough Starshot to launch humanity’s first spacecraft to Alpha Centauri. The plan was to use powerful lasers that would propel tiny probes to a fifth of the speed of light—fast enough to reach Alpha Centauri within 20 years. Milner pledged $100 million toward a proof of concept. But a decade later, nothing has launched. “We didn’t want to do another Breakthrough Starshot,” says Philip Johnston, the cofounder and president of the Fermi Explorer Mission. “We’re dead set on something actually launching.” The new mission, currently funded by individual private donors, is expected to cost just $15 million.  To stick to that budget, “we are not constraining ourselves to doing it in a human lifetime,” says Johnston. “Let’s just figure out the way to get to another star.”  The spacecraft will carry cargo weighing at least one kilogram. That will include artistic and scientific payloads, messages, and a copy of the Golden Record, a gold-plated disc of Earth’s sounds and images that NASA attached to its two Voyager probes in 1977 as a message to any civilization that might find them. Engineering an interstellar journey is extremely difficult. Alpha Centauri is about 25 trillion miles away from Earth. One of the fastest objects that humans have ever launched, the Voyager 1 probe, has been flying since 1977 and has covered less than 1% percent of that distance. At its speed, the trip would take more than 70,000 years. Johnston and his team spent a year trying, and failing, to find a way for a small, solar-powered spacecraft costing only $15 million to reach Alpha Centauri. They kept running into the knotty problem of how to give the spacecraft enough power without making it too heavy (and thus more fuel-guzzling).  After the Fermi team struggled to find a workable route, Johnston mentioned the problem in a podcast hosted by Alex Wissner-Gross, a physicist who cofounded PSI. Wissner-Gross offered to run it through an AI system the lab developed, called Get Physics Done. It’s open-source software that takes a physics research question, breaks it into smaller tasks, and decides which simulations to run, using AI models including Anthropic’s Claude or OpenAI’s GPT. A week later, the AI system turned up a novel trajectory, to Johnston’s surprise. It combined well-known orbital maneuvers in a way the Fermi team had not considered, according to a paper that has not been peer-reviewed. It suggested that the spacecraft could first slow down so its orbit swings in close to the sun—closer than Mercury. On each close pass, it would fire its engine so that the solar panels get four times the light, and a burst of thrust delivered at high speed would buy more energy than the same burst anywhere else. Because the engine would run only near the sun, the solar panels could stay small and the spacecraft light. The system conducted the research mostly on its own for three days, running on a billion tokens, says Matt Pines, the cofounder and CEO of PSI. An astrophysicist on PSI’s staff steered it to follow the mission’s requirements, asked for a cost analysis and clearer charts, and checked the output for errors. “The fact that it came up with an entirely different mission profile, one that was creative and not one [the Fermi team] had considered—that was the more surprising aspect,” says Pines. Still, the model lacks a human researcher’s judgment and taste, he says. It has no reliable sense of which problems are interesting or which approaches are worth pursuing, so it often gets stuck chasing dead ends or failing to explore different approaches. “I don’t think we’ve yet figured out how these models can internally represent something like that,” he says of research judgment. Even if the Fermi probe launches, “we’re pretty confident that we will not be the first to arrive” at Alpha Centauri, says Johnston, since he expects spacecraft technology to improve. If an engine a thousand years from now is even 20% faster than today’s, a spacecraft launched then would still beat Fermi’s probe to Alpha Centauri by more than 10,000 years.  But the Fermi project isn’t just an interstellar mission driven by engineering ambition. It’s also a quest to answer one of the oldest open questions in physics. In 1950, the physicist Enrico Fermi posed a puzzle: The galaxy has hundreds of billions of stars, most of them far older than our sun. Even a civilization traveling slowly between stars could spread across the whole galaxy in a few million years, which pales in comparison to how old the galaxy is. If there is intelligent life somewhere, we should have seen signs of its existence by now. That means either reaching for another star is too difficult or other intelligent species simply haven’t bothered. But once the Fermi probe launches, we will become a civilization that can and wants to reach another star, meaning that neither explanation might be what’s keeping the galaxy unexplored. That could point us toward more unsettling possibilities, says Johnston. Maybe life like ours is almost unimaginably rare. Or maybe intelligent life is common but tends to die out before it can spread.  If the latter is true, “one of those reasons could be that once you hit superintelligence, that for some reason is self-destructive,”

Quantitative research agents that write their own experiments can corrupt the evidence they later learn from. A leaky feature that scores well gets stored as a successful precedent and propagated through later iterations. Prompt-level instructions and reviewer agents do not close this, because author and reviewer share the same blind spots. A team of researchers from Princeton University, Ant Group and Stanford University propose AQuA. AQuA is a pair of language-model-driven research systems that improve their own research process across iterations while the thing judging them stays frozen. One discovers symbolic alpha factors on crypto; the other develops time-series models on US equities. They share no agents, memories, candidate spaces or research state. The failure mode AQuA is built around Quantitative research breaks on small methodological errors that produce convincing but non-reproducible backtests, documented since Bailey et al.. An agent writing its own experiments makes this worse: a leaky feature that scores well gets stored as precedent, and recursion amplifies an undetected bug as readily as a real discovery. Prompt-level instructions and model review are not an integrity boundary. Repeated access to a fixed holdout causes adaptive overfitting, and LLM agents have been observed exploiting misspecified objectives and evaluators. AQuA instead makes leakage-inducing actions unavailable. Each part fixes its splits, feature and label definitions and evaluator before any iteration starts, and the agent emits only a constrained factor expression or a single config diff. The research team call this asymmetric freedom: the agent explores freely inside its DSL, but the evaluator sits outside the adaptive surface. What improves is the research process. Interactive explainer Part I: Manager-Mediated Factor Discovery Part I is a six-agent pipeline: Data Steward, Visual Analyst, Idea Miner, Factor Evaluator, Backtest Engineer and Research Librarian — orchestrated by an AI Manager. Agents never call one another; every handoff goes through the Manager, keeping runs auditable. A factor enters as a falsifiable proposal, not an expression: hypothesis, mechanism, predicted direction, and refutation conditions. Only then is it assembled from the standard formulaic-alpha operator registry. Because every time-series operator reads only a trailing window and every cross-sectional operator reads only the current timestamp, causality is closed under composition. Three feedback loops run: direction calibration inside a backtest, falsification-driven belief update inside a run, and cross-run memory that steers the next search. On a crypto five-minute universe the combined validation Spearman IC climbs across 20 research epochs to approximately 0.190, against 0.171 for an adapted AlphaMemo, 0.151 for an adapted AlphaGen, 0.137 for LSTM, 0.106 for LightGBM and 0.075 for an Alpha158-style baseline. Individual mechanisms stay weak — single-factor ICs of 0.026 to 0.037. The claim is about the harness, not one expression. Part II: Config-Driven Model Development Part II predicts each stock’s forward return over the next thirty minutes on intraday US equities. Training runs on 2010–2019, 2020 is an embargo gap nothing touches, and 2021–2025 is untouched test data. Selection uses an inner-validation slice from the end of the training window only. A hypothesis here is one config diff — architecture, loss, sampler or optimizer — and one diff produces exactly one variant, keeping variants comparable. The predictor is a hybrid: a multi-scale 1-D convolutional front-end, a configurable backbone spanning LSTM, Mamba and attention (attention in the reported run), a cross-sectional stage that mixes across the panel, gated fusion and a pooled per-stock readout. No single price-volume feature carries the signal: the strongest is a 5-minute return at −0.031, and a ridge combination reaches only +0.025. Across model families on identical data and the same evaluator, per-stock raw IC runs +0.0251 (ridge), +0.0397 (LGB), +0.0434 (xLSTM), +0.0535 (LSTM), +0.0613 (GRU) and +0.0843 for the hybrid — +0.0230 absolute over the best baseline, 37.5% relative. The two parts’ ICs use different conventions and the paper states plainly they should not be compared. From Signal to Strategy The per-stock score becomes a dollar-neutral threshold long/short book at a two-leg cost of 2 bps. Sector-neutralizing raises the held-out Sharpe to +2.15, with training and held-out values nearly equal. A causal volatility-targeting overlay lifts it to +2.50, and a fully causal walk-forward choosing every parameter from past data alone still reaches +2.00. Per-stock R² is 1.20%. Sharpe by year runs +1.7, +3.5, +1.9, +1.8 and +2.7 for 2021 through 2025 — positive in every year, including the 2022 drawdown. Key Takeaways Two independent research loops: factor discovery and model development, share no agents, memory or state. Freedom is asymmetric: the agent explores inside a DSL, but splits, features, labels and evaluator are sealed. Part I hits ~0.190 combined IC on crypto; Part II hits +0.0843 per-stock IC versus +0.0613 for a GRU. The equity book holds a +2.50 Sharpe at 2 bps and is positive in all five years, 2021–2025. Check out the Paper. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us Note:Thanks to the Ant Research team for the thought leadership/ Resources for this article. Ant Research team has supported this content/article for promotion. The post Researchers from Princeton, Ant Group and Stanford Introduce AQuA: A Two-Part Agentic Framework for Autonomous Factor Discovery and Model Development in Quantitative Finance appeared first on MarkTechPost.

Anthropic has released Claude Fable 5.1 and Claude Mythos 5.1, three months after the Fable 5 line shipped in June 2026. The two are the same underlying model behind different safeguard layers. Fable 5.1 is generally available as claude-fable-5-1; Mythos 5.1 stays restricted to vetted organizations. Both carry a 1M token context window and 128K max output tokens, with adaptive thinking always on. The headline capability number is 52.6% on Terminal-Bench-Science 0.1, against 24.7% for Fable 5 and 29.0% for Opus 5. The headline commercial number is a 75% cut to cache reads, from $1.00 to $0.25 per million tokens, which Anthropic measures as roughly 25% lower cost on typical workloads and up to 45% on agentic ones. Base input and output pricing is unchanged at $10 and $50 per million. Is it deployable? Yes, Claude Fable 5.1 is generally available as claude-fable-5-1 on the Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud, and Microsoft Foundry. Claude Mythos 5.1 is not: it is restricted to vetted US organizations inside Project Glasswing. The benchmark numbers On Terminal-Bench-Science 0.1, an agentic scientific research benchmark, Fable 5.1 scores 52.6% against 29.0% for Opus 5, 24.7% for Fable 5, and 22.4% for GPT-5.6 Sol. Anthropic reports a standard error of 3.5 to 4.5 points per model, so treat the margin, not the ranking, with care. On Terminal-Bench 4.0, Fable 5.1 reaches 55.8% and Mythos 5.1 reaches 60.9%. The gap between two identical models is the cost of safeguard interventions, which is an unusually honest disclosure. Elsewhere: CursorBench 3.2.0 at 73.4%, Humanity’s Last Exam at 60.9% without tools and 65.0% with tools, AutomationBench at 31.4%, OSWorld 2.0 at 41.7% strict, and GDPval-AA v2 at 1853. Where the cost cut comes from Base input and output pricing is unchanged. Cache reads drop 75%, from $1.00 to $0.25 per million tokens, which is 0.025 times base input against 0.1 on every other Claude model. Anthropic measures roughly 25% lower cost on typical workloads and up to about 45% on context-heavy agentic ones. Batch processing is $5 and $25 per million tokens. Three breaking changes teams will hit Forced tool use is gone: tool_choice set to any or tool returns a 400. Use auto with strict tool use or structured outputs instead. Thinking blocks are model-bound: Fable 5.1 reads earlier models’ thinking, but no earlier model reads its own. Router and fallback setups lose reasoning when they switch down. Editing earlier turns invalidates thinking blocks: Injecting and deleting per-turn reminders, or rebuilding the system or tools array mid-conversation, now errors. The check is enforced for accounts created on or after August 31, 2026. The fixes are turn-scoped system messages and server-side context editing. Additive changes: per-message effort, turn-scoped system messages, and thinking.display: “updates” are all in beta behind headers. Content provenance is not optional, with a statistical text watermark on all output and C2PA credentials on files. Anthropic also documents real regressions. Parallel tool calling is more variable, so agent loops may issue one call per turn where Fable 5 batched several. The model narrates less, answers from memory more often at low effort, and prefers whole-file rewrites over targeted edits. Safeguards and science Cyber safeguards now permit vulnerability discovery but not exploit development, cutting interventions in Claude Code by roughly 60% per session. Biology safeguards fire 85% less often on benign requests. Penetration testing, exploit generation, and binary-based vulnerability scanning still redirect to Opus. On research, Mythos 5.1 designed protein binders with roughly 50% hit rate across 12 targets against a 10 to 15% norm, Fable 5.1 built a Venus elevation map at 2 to 3 km resolution, and custom GPU kernels sped up seven open-source genomics models by up to 2.5x. Key Takeaways Fable 5.1 and Mythos 5.1 are one model behind two safeguard layers; only Fable is generally available. 52.6% on Terminal-Bench-Science 0.1, roughly double Fable 5’s 24.7%. Cache reads fall 75% to $0.25 per million; base rates are untouched. Three breaking API changes hit any agent that edits conversation history. 30-day retention applies; zero data retention needs express authorization. Check out the Technical Details. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Anthropic Releases Claude Fable 5.1 and Claude Mythos 5.1: 52.6% on Terminal-Bench-Science and 75% Cheaper Cache Reads appeared first on MarkTechPost.