AI Tools & Reviews

Cloudflare has open sourced tokio-quiche, an asynchronous QUIC and HTTP/3 Rust library that wraps its battle tested quiche implementation with the Tokio runtime. The library has been refined inside production systems such as Apple iCloud Private Relay, next generation Oxy based proxies and WARP’s MASQUE client, where it handles millions of HTTP/3 requests per second with low latency and high throughput. tokio-quiche targets Rust teams that want QUIC and HTTP/3 without writing their own UDP and event loop integration code.

From quiche to tokio-quiche

quiche is Cloudflare’s open source QUIC and HTTP/3 implementation written in Rust and designed as a low level, sans-io library. It implements the QUIC transport state machine, including connection establishment, flow control and stream multiplexing, while making no assumptions about how applications perform IO. To use quiche directly, integrators must open UDP sockets, send and receive datagrams, manage timers and feed all packet data into quiche in the correct order. This design gives flexibility, but it makes integration error prone and time consuming.

tokio-quiche packages this integration work into a reusable crate. It combines the sans-io QUIC or HTTP/3 implementation from quiche with the Tokio async runtime, and exposes an API that already manages UDP sockets, packet routing and calls into the quiche state machine.

Actor based architecture on Tokio

Internally, tokio-quiche uses an actor model on top of Tokio. Actors are small tasks with local state that communicate through message passing over channels, which aligns well with sans-io protocol implementations that own internal state and operate on message like buffers.

The primary actor is the IO loop actor, which moves packets between quiche and the UDP socket. One of the key message types is an Incoming struct that describes received UDP packets. Async integration follows a fixed pattern, the IO loop awaits new messages, translates them into inputs for quiche, advances the QUIC state machine, then translates outputs into outbound packets that are written back to the socket.

For each UDP socket, tokio-quiche spawns two important tasks. InboundPacketRouter owns the receiving half of the socket and routes inbound datagrams by destination connection ID to per connection channels. IoWorker is the per connection IO loop and drives a single quiche Connection, interleaving calls to quiche with calls to application specific logic implemented through ApplicationOverQuic. This design encapsulates connection state inside each actor and keeps QUIC processing isolated from higher level protocol code.

ApplicationOverQuic and H3Driver

QUIC is a transport protocol and can carry multiple application protocols. HTTP/3, DNS over QUIC and Media over QUIC are examples covered by IETF specifications. To avoid coupling tokio-quiche to a single protocol, Cloudflare team exposes an ApplicationOverQuic trait. The trait abstracts over quiche methods and the underlying IO, and presents higher level events and hooks to the application that implements the protocol. For example, the HTTP/3 debug and test client h3i uses a non HTTP/3 implementation of ApplicationOverQuic.

On top of this trait, tokio-quiche ships a dedicated HTTP/3 focused implementation named H3Driver. H3Driver connects quiche’s HTTP/3 module to the IO loop actor and converts raw HTTP/3 events into higher level events with asynchronous body streams that are convenient for application code. H3Driver is generic and exposes ServerH3Driver and ClientH3Driver variants that add server side and client side behavior on top of the core driver. These components provide the building blocks for HTTP/3 servers and clients that share implementation patterns with Cloudflare’s internal infrastructure.

Production usage and roadmap

tokio-quiche has been used for several years inside Cloudflare before its public release. It powers Proxy B in Apple iCloud Private Relay, Oxy based HTTP/3 servers and the WARP MASQUE client, as well as the async version of h3i. In the WARP client, MASQUE based tunnels built on tokio-quiche replace earlier WireGuard based tunnels with QUIC based tunnels. These systems run at Cloudflare edge scale and demonstrate that the integration can sustain millions of HTTP/3 requests per second in production.

Cloudflare positions tokio-quiche as a foundation rather than a complete HTTP/3 framework. The library exposes low level protocol capabilities and example client and server event loops, and leaves room for higher level projects to implement opinionated HTTP servers, DNS over QUIC clients, MASQUE based VPNs and other QUIC applications on top. By releasing the crate, Cloudflare aims to lower the barrier for Rust teams to adopt QUIC, HTTP/3 and MASQUE, and to align external integrations with the same transport stack used in its edge services.

Key Takeaways

• tokio-quiche = quiche + Tokio: tokio-quiche is an async Rust library that integrates Cloudflare’s sans-io QUIC and HTTP/3 implementation, quiche, with the Tokio runtime, so developers do not need to hand write UDP and event loop plumbing.
• Actor based architecture for QUIC connections: The library uses an actor model on Tokio, with an InboundPacketRouter that routes UDP datagrams by connection ID and an IoWorker that drives a single quiche Connection per task, keeping transport state isolated and composable.
• ApplicationOverQuic abstraction: Protocol logic is separated through the ApplicationOverQuic trait, which abstracts over quiche and I O details so different QUIC based protocols such as HTTP/3, DNS over QUIC or custom protocols can be implemented on top of the same transport core.
• HTTP/3 via H3Driver, ServerH3Driver and ClientH3Driver: tokio-quiche ships H3Driver plus ServerH3Driver and ClientH3Driver variants that bridge quiche’s HTTP/3 module to async Rust code, exposing HTTP/3 streams and bodies in a way that fits typical Tokio based services.

Check out the . Also, feel free to follow us on  and don’t forget to join our  and Subscribe to . Wait! are you on telegram? 

The post appeared first on .

In this tutorial, we implement an agentic AI pattern using LangGraph that treats reasoning and action as a transactional workflow rather than a single-shot decision. We model a two-phase commit system in which an agent stages reversible changes, validates strict invariants, pauses for human approval via graph interrupts, and commits or rolls back only then. With this, we demonstrate how agentic systems can be designed with safety, auditability, and controllability at their core, moving beyond reactive chat agents toward structured, governance-aware AI workflows that run reliably in Google Colab using OpenAI models. Check out the .

!pip -q install -U langgraph langchain-openai


import os, json, uuid, copy, math, re, operator
from typing import Any, Dict, List, Optional
from typing_extensions import TypedDict, Annotated


from langchain_openai import ChatOpenAI
from langchain_core.messages import SystemMessage, HumanMessage, AIMessage, AnyMessage
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.types import interrupt, Command


def _set_env_openai():
   if os.environ.get("OPENAI_API_KEY"):
       return
   try:
       from google.colab import userdata
       k = userdata.get("OPENAI_API_KEY")
       if k:
           os.environ["OPENAI_API_KEY"] = k
           return
   except Exception:
       pass
   import getpass
   os.environ["OPENAI_API_KEY"] = getpass.getpass("Enter OPENAI_API_KEY: ")


_set_env_openai()


MODEL = os.environ.get("OPENAI_MODEL", "gpt-4o-mini")
llm = ChatOpenAI(model=MODEL, temperature=0)

We set up the execution environment by installing LangGraph and initializing the OpenAI model. We securely load the API key and configure a deterministic LLM, ensuring that all downstream agent behavior remains reproducible and controlled. Check out the .

SAMPLE_LEDGER = [
   {"txn_id": "T001", "name": "Asha", "email": "ASHA@Example.com", "amount": "1,250.50", "date": "12/01/2025", "note": "Membership renewal"},
   {"txn_id": "T002", "name": "Ravi", "email": "ravi@example.com", "amount": "-500", "date": "2025-12-02", "note": "Chargeback?"},
   {"txn_id": "T003", "name": "Sara", "email": "sara@example.com", "amount": "700", "date": "02-12-2025", "note": "Late fee waived"},
   {"txn_id": "T003", "name": "Sara", "email": "sara@example.com", "amount": "700", "date": "02-12-2025", "note": "Duplicate row"},
   {"txn_id": "T004", "name": "Lee", "email": "lee@example.com", "amount": "NaN", "date": "2025/12/03", "note": "Bad amount"},
]


ALLOWED_OPS = {"replace", "remove", "add"}


def _parse_amount(x):
   if isinstance(x, (int, float)):
       return float(x)
   if isinstance(x, str):
       try:
           return float(x.replace(",", ""))
       except:
           return None
   return None


def _iso_date(d):
   if not isinstance(d, str):
       return None
   d = d.replace("/", "-")
   p = d.split("-")
   if len(p) == 3 and len(p[0]) == 4:
       return d
   if len(p) == 3 and len(p[2]) == 4:
       return f"{p[2]}-{p[1]}-{p[0]}"
   return None


def profile_ledger(rows):
   seen, anomalies = {}, []
   for i, r in enumerate(rows):
       if _parse_amount(r.get("amount")) is None:
           anomalies.append(i)
       if r.get("txn_id") in seen:
           anomalies.append(i)
       seen[r.get("txn_id")] = i
   return {"rows": len(rows), "anomalies": anomalies}


def apply_patch(rows, patch):
   out = copy.deepcopy(rows)
   for op in sorted([p for p in patch if p["op"] == "remove"], key=lambda x: x["idx"], reverse=True):
       out.pop(op["idx"])
   for op in patch:
       if op["op"] in {"add", "replace"}:
           out[op["idx"]][op["field"]] = op["value"]
   return out


def validate(rows):
   issues = []
   for i, r in enumerate(rows):
       if _parse_amount(r.get("amount")) is None:
           issues.append(i)
       if _iso_date(r.get("date")) is None:
           issues.append(i)
   return {"ok": len(issues) == 0, "issues": issues}

We define the core ledger abstraction along with the patching, normalization, and validation logic. We treat data transformations as reversible operations, allowing the agent to reason about changes safely before committing them. Check out the .

class TxnState(TypedDict):
   messages: Annotated[List[AnyMessage], add_messages]
   raw_rows: List[Dict[str, Any]]
   sandbox_rows: List[Dict[str, Any]]
   patch: List[Dict[str, Any]]
   validation: Dict[str, Any]
   approved: Optional[bool]


def node_profile(state):
   p = profile_ledger(state["raw_rows"])
   return {"messages": [AIMessage(content=json.dumps(p))]}


def node_patch(state):
   sys = SystemMessage(content="Return a JSON patch list fixing amounts, dates, emails, duplicates")
   usr = HumanMessage(content=json.dumps(state["raw_rows"]))
   r = llm.invoke([sys, usr])
   patch = json.loads(re.search(r"[.*]", r.content, re.S).group())
   return {"patch": patch, "messages": [AIMessage(content=json.dumps(patch))]}


def node_apply(state):
   return {"sandbox_rows": apply_patch(state["raw_rows"], state["patch"])}


def node_validate(state):
   v = validate(state["sandbox_rows"])
   return {"validation": v, "messages": [AIMessage(content=json.dumps(v))]}


def node_approve(state):
   decision = interrupt({"validation": state["validation"]})
   return {"approved": decision == "approve"}


def node_commit(state):
   return {"messages": [AIMessage(content="COMMITTED")]}


def node_rollback(state):
   return {"messages": [AIMessage(content="ROLLED BACK")]}

We model the agent’s internal state and define each node in the LangGraph workflow. We express agent behavior as discrete, inspectable steps that transform state while preserving message history. Check out the .

builder = StateGraph(TxnState)


builder.add_node("profile", node_profile)
builder.add_node("patch", node_patch)
builder.add_node("apply", node_apply)
builder.add_node("validate", node_validate)
builder.add_node("approve", node_approve)
builder.add_node("commit", node_commit)
builder.add_node("rollback", node_rollback)


builder.add_edge(START, "profile")
builder.add_edge("profile", "patch")
builder.add_edge("patch", "apply")
builder.add_edge("apply", "validate")


builder.add_conditional_edges(
   "validate",
   lambda s: "approve" if s["validation"]["ok"] else "rollback",
   {"approve": "approve", "rollback": "rollback"}
)


builder.add_conditional_edges(
   "approve",
   lambda s: "commit" if s["approved"] else "rollback",
   {"commit": "commit", "rollback": "rollback"}
)


builder.add_edge("commit", END)
builder.add_edge("rollback", END)


app = builder.compile(checkpointer=InMemorySaver())

We construct the LangGraph state machine and explicitly encode the control flow between profiling, patching, validation, approval, and finalization. We use conditional edges to enforce governance rules rather than rely on implicit model decisions. Check out the .

def run():
   state = {
       "messages": [],
       "raw_rows": SAMPLE_LEDGER,
       "sandbox_rows": [],
       "patch": [],
       "validation": {},
       "approved": None,
   }


   cfg = {"configurable": {"thread_id": "txn-demo"}}
   out = app.invoke(state, config=cfg)


   if "__interrupt__" in out:
       print(json.dumps(out["__interrupt__"], indent=2))
       decision = input("approve / reject: ").strip()
       out = app.invoke(Command(resume=decision), config=cfg)


   print(out["messages"][-1].content)


run()

We run the transactional agent and handle human-in-the-loop approval through graph interrupts. We resume execution deterministically, demonstrating how agentic workflows can pause, accept external input, and safely conclude with either a commit or rollback.

In conclusion, we showed how LangGraph enables us to build agents that reason over states, enforce validation gates, and collaborate with humans at precisely defined control points. We treated the agent not as an oracle, but as a transaction coordinator that can stage, inspect, and reverse its own actions while maintaining a full audit trail. This approach highlights how agentic AI can be applied to real-world systems that require trust, compliance, and recoverability, and it provides a practical foundation for building production-grade autonomous workflows that remain safe, transparent, and human-supervised.

Check out the . Also, feel free to follow us on  and don’t forget to join our  and Subscribe to . Wait! are you on telegram? 

The post appeared first on .

In this tutorial, we demonstrate how we simulate a privacy-preserving fraud detection system using Federated Learning without relying on heavyweight frameworks or complex infrastructure. We build a clean, CPU-friendly setup that mimics ten independent banks, each training a local fraud-detection model on its own highly imbalanced transaction data. We coordinate these local updates through a simple FedAvg aggregation loop, allowing us to improve a global model while ensuring that no raw transaction data ever leaves a client. Alongside this, we integrate OpenAI to support post-training analysis and risk-oriented reporting, demonstrating how federated learning outputs can be translated into decision-ready insights. Check out the .

!pip -q install torch scikit-learn numpy openai


import time, random, json, os, getpass
import numpy as np
import torch
import torch.nn as nn
from torch.utils.data import DataLoader, TensorDataset
from sklearn.datasets import make_classification
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler
from sklearn.metrics import roc_auc_score, average_precision_score, accuracy_score
from openai import OpenAI


SEED = 7
random.seed(SEED); np.random.seed(SEED); torch.manual_seed(SEED)


DEVICE = torch.device("cpu")
print("Device:", DEVICE)

We set up the execution environment and import all required libraries for data generation, modeling, evaluation, and reporting. We also fix random seeds and the device configuration to ensure our federated simulation remains deterministic and reproducible on CPU. Check out the .

X, y = make_classification(
   n_samples=60000,
   n_features=30,
   n_informative=18,
   n_redundant=8,
   weights=[0.985, 0.015],
   class_sep=1.5,
   flip_y=0.01,
   random_state=SEED
)


X = X.astype(np.float32)
y = y.astype(np.int64)


X_train_full, X_test, y_train_full, y_test = train_test_split(
   X, y, test_size=0.2, stratify=y, random_state=SEED
)


server_scaler = StandardScaler()
X_train_full_s = server_scaler.fit_transform(X_train_full).astype(np.float32)
X_test_s = server_scaler.transform(X_test).astype(np.float32)


test_loader = DataLoader(
   TensorDataset(torch.from_numpy(X_test_s), torch.from_numpy(y_test)),
   batch_size=1024,
   shuffle=False
)

We generate a highly imbalanced, credit-card-like fraud dataset & split it into training & test sets. We standardize the server-side data and prepare a global test loader that allows us to consistently evaluate the aggregated model after each federated round. Check out the .

def dirichlet_partition(y, n_clients=10, alpha=0.35):
   classes = np.unique(y)
   idx_by_class = [np.where(y == c)[0] for c in classes]
   client_idxs = [[] for _ in range(n_clients)]
   for idxs in idx_by_class:
       np.random.shuffle(idxs)
       props = np.random.dirichlet(alpha * np.ones(n_clients))
       cuts = (np.cumsum(props) * len(idxs)).astype(int)
       prev = 0
       for cid, cut in enumerate(cuts):
           client_idxs[cid].extend(idxs[prev:cut].tolist())
           prev = cut
   return [np.array(ci, dtype=np.int64) for ci in client_idxs]


NUM_CLIENTS = 10
client_idxs = dirichlet_partition(y_train_full, NUM_CLIENTS, 0.35)


def make_client_split(X, y, idxs):
   Xi, yi = X[idxs], y[idxs]
   if len(np.unique(yi)) < 2:
       other = np.where(y == (1 - yi[0]))[0]
       add = np.random.choice(other, size=min(10, len(other)), replace=False)
       Xi = np.concatenate([Xi, X[add]])
       yi = np.concatenate([yi, y[add]])
   return train_test_split(Xi, yi, test_size=0.15, stratify=yi, random_state=SEED)


client_data = [make_client_split(X_train_full, y_train_full, client_idxs[c]) for c in range(NUM_CLIENTS)]


def make_client_loaders(Xtr, ytr, Xva, yva):
   sc = StandardScaler()
   Xtr_s = sc.fit_transform(Xtr).astype(np.float32)
   Xva_s = sc.transform(Xva).astype(np.float32)
   tr = DataLoader(TensorDataset(torch.from_numpy(Xtr_s), torch.from_numpy(ytr)), batch_size=512, shuffle=True)
   va = DataLoader(TensorDataset(torch.from_numpy(Xva_s), torch.from_numpy(yva)), batch_size=512)
   return tr, va


client_loaders = [make_client_loaders(*cd) for cd in client_data]

We simulate realistic non-IID behavior by partitioning the training data across ten clients using a Dirichlet distribution. We then create independent client-level train and validation loaders, ensuring that each simulated bank operates on its own locally scaled data. Check out the .

class FraudNet(nn.Module):
   def __init__(self, in_dim):
       super().__init__()
       self.net = nn.Sequential(
           nn.Linear(in_dim, 64),
           nn.ReLU(),
           nn.Dropout(0.1),
           nn.Linear(64, 32),
           nn.ReLU(),
           nn.Dropout(0.1),
           nn.Linear(32, 1)
       )
   def forward(self, x):
       return self.net(x).squeeze(-1)


def get_weights(model):
   return [p.detach().cpu().numpy() for p in model.state_dict().values()]


def set_weights(model, weights):
   keys = list(model.state_dict().keys())
   model.load_state_dict({k: torch.tensor(w) for k, w in zip(keys, weights)}, strict=True)


@torch.no_grad()
def evaluate(model, loader):
   model.eval()
   bce = nn.BCEWithLogitsLoss()
   ys, ps, losses = [], [], []
   for xb, yb in loader:
       logits = model(xb)
       losses.append(bce(logits, yb.float()).item())
       ys.append(yb.numpy())
       ps.append(torch.sigmoid(logits).numpy())
   y_true = np.concatenate(ys)
   y_prob = np.concatenate(ps)
   return {
       "loss": float(np.mean(losses)),
       "auc": roc_auc_score(y_true, y_prob),
       "ap": average_precision_score(y_true, y_prob),
       "acc": accuracy_score(y_true, (y_prob >= 0.5).astype(int))
   }


def train_local(model, loader, lr):
   opt = torch.optim.Adam(model.parameters(), lr=lr)
   bce = nn.BCEWithLogitsLoss()
   model.train()
   for xb, yb in loader:
       opt.zero_grad()
       loss = bce(model(xb), yb.float())
       loss.backward()
       opt.step()

We define the neural network used for fraud detection along with utility functions for training, evaluation, and weight exchange. We implement lightweight local optimization and metric computation to keep client-side updates efficient and easy to reason about. Check out the .

def fedavg(weights, sizes):
   total = sum(sizes)
   return [
       sum(w[i] * (s / total) for w, s in zip(weights, sizes))
       for i in range(len(weights[0]))
   ]


ROUNDS = 10
LR = 5e-4


global_model = FraudNet(X_train_full.shape[1])
global_weights = get_weights(global_model)


for r in range(1, ROUNDS + 1):
   client_weights, client_sizes = [], []
   for cid in range(NUM_CLIENTS):
       local = FraudNet(X_train_full.shape[1])
       set_weights(local, global_weights)
       train_local(local, client_loaders[cid][0], LR)
       client_weights.append(get_weights(local))
       client_sizes.append(len(client_loaders[cid][0].dataset))
   global_weights = fedavg(client_weights, client_sizes)
   set_weights(global_model, global_weights)
   metrics = evaluate(global_model, test_loader)
   print(f"Round {r}: {metrics}")

We orchestrate the federated learning process by iteratively training local client models and aggregating their parameters using FedAvg. We evaluate the global model after each round to monitor convergence and understand how collective learning improves fraud detection performance. Check out the .

OPENAI_API_KEY = getpass.getpass("Enter OPENAI_API_KEY (input hidden): ").strip()


if OPENAI_API_KEY:
   os.environ["OPENAI_API_KEY"] = OPENAI_API_KEY
   client = OpenAI()


   summary = {
       "rounds": ROUNDS,
       "num_clients": NUM_CLIENTS,
       "final_metrics": metrics,
       "client_sizes": [len(client_loaders[c][0].dataset) for c in range(NUM_CLIENTS)],
       "client_fraud_rates": [float(client_data[c][1].mean()) for c in range(NUM_CLIENTS)]
   }


   prompt = (
       "Write a concise internal fraud-risk report.n"
       "Include executive summary, metric interpretation, risks, and next steps.nn"
       + json.dumps(summary, indent=2)
   )


   resp = client.responses.create(model="gpt-5.2", input=prompt)
   print(resp.output_text)

We transform the technical results into a concise analytical report using an external language model. We securely accept the API key via keyboard input and generate decision-oriented insights that summarize performance, risks, and recommended next steps.

In conclusion, we showed how to implement federated learning from first principles in a Colab notebook while remaining stable, interpretable, and realistic. We observed how extreme data heterogeneity across clients influences convergence and why careful aggregation and evaluation are critical in fraud-detection settings. We also extended the workflow by generating an automated risk-team report, demonstrating how analytical results can be translated into decision-ready insights. At last, we presented a practical blueprint for experimenting with federated fraud models that emphasizes privacy awareness, simplicity, and real-world relevance.

Check out the . Also, feel free to follow us on  and don’t forget to join our  and Subscribe to . Wait! are you on telegram? 

The post appeared first on .

Alibaba Tongyi Lab have released MAI-UI—a family of foundation GUI agents. It natively integrates MCP tool use, agent user interaction, device–cloud collaboration, and online RL, establishing state-of-the-art results in general GUI grounding and mobile GUI navigation, surpassing Gemini-2.5-Pro, Seed1.8, and UI-Tars-2 on AndroidWorld. The system targets three specific gaps that early GUI agents often ignore, native agent user interaction, MCP tool integration, and a device cloud collaboration architecture that keeps privacy sensitive work on device while still using large cloud models when needed.

What is MAI-UI?

MAI-UI is a family of multimodal GUI agents built on Qwen3 VL, with model sizes 2B, 8B, 32B and 235B A22B. These models take natural language instructions and rendered UI screenshots as input, then output structured actions for a live Android environment.

The action space covers standard operations such as clicking elements, swiping, entering text and pressing system buttons. On top of that, MAI-UI introduces explicit actions for answering user questions, asking the user for clarification when the goal is ambiguous, and invoking external tools through MCP tool calls. This makes the agent capable of mixing GUI steps, direct language responses and API level operations in a single trajectory.

From a modeling perspective, MAI UI unifies three components, a self evolving navigation data pipeline that includes user interaction and MCP cases, an online RL framework that scales to hundreds of parallel Android instances and long contexts, and a native device cloud collaboration system that routes execution based on task state and privacy constraints.

GUI grounding with instruction reasoning

A core requirement for any GUI agent is grounding, mapping free form language like ‘open monthly billing settings’ to the correct on screen control. MAI-UI adopts a UI grounding strategy inspired by the earlier UI-Ins work on multi perspective instruction descriptions.

For each UI element, the training pipeline does not rely on a single caption. Instead, it generates several views of the same element, for example appearance, function, spatial location and user intent. These multiple instructions are treated as reasoning evidence for the model, which must select a point inside the correct bounding box. This reduces the impact of flawed or underspecified instructions, an issue that UI Ins quantified in existing datasets.

Ground truth boxes are collected from a mix of curated GUI datasets and large scale exploration of virtualized operating systems in containerized environments. Accessibility trees or OCR based parsers are used to align textual metadata with pixel locations. The training objective combines supervised fine tuning with a simple reinforcement signal that rewards correct point in box predictions and valid output format.

On public GUI grounding benchmarks, the resulting MAI-UI models reach 73.5 percent accuracy on ScreenSpot Pro with adaptive zoom in, 91.3 percent on MMBench GUI L2, 70.9 percent on OSWorld G and 49.2 percent on UI Vision. These numbers surpass Gemini 3 Pro and Seed1.8 on ScreenSpot Pro, and significantly outperform earlier open models on UI Vision.

Self evolving navigation data and MobileWorld

Navigation is harder than grounding because the agent must maintain context across many steps, possibly across applications, while interacting with the user and tools. To build robust navigation behavior, Tongyi Lab uses a self evolving data pipeline.

Seed tasks come from app manuals, hand designed scenarios and filtered public data. Parameters such as dates, limits and filter values are perturbed to expand coverage, and object level substitutions are applied while staying within the same use case. Multiple agents, together with human annotators, execute these tasks in Android environments to produce trajectories. A judge model then evaluates these trajectories, keeps the longest correct prefixes and filters out low quality segments. The next supervised training round uses the union of fresh human traces and high quality model rollouts, so the data distribution gradually follows the current policy.

MAI UI is evaluated on MobileWorld, a benchmark from the same team that includes 201 tasks across 20 applications. MobileWorld explicitly mixes three categories, pure GUI tasks, agent user interaction tasks that require natural language back and forth with the user, and MCP augmented tasks that require tool calls.

On MobileWorld, MAI UI reaches 41.7 percent overall success, a gain of about 20.8 points over the strongest end to end GUI baselines, and competitive with agentic frameworks that use larger proprietary planners such as Gemini 3 Pro.

Online RL in containerized Android environments

Static data is not enough for robustness in dynamic mobile apps. MAI-UI therefore uses an online RL framework where the agent interacts directly with containerized Android Virtual Devices. The environment stack packs rooted AVD images and backend services into Docker containers, exposes standard reset and step operations over a service layer and supports more than 35 self hosted apps from e commerce, social, productivity and enterprise categories.

The RL setup uses an asynchronous on policy method, GRPO, implemented on top of verl. It combines tensor, pipeline and context parallelism, similar to Megatron style training, so that the model can learn from trajectories with up to 50 steps and very long token sequences. Rewards come from rule based verifiers or model judges that detect task completion, along with penalties for obvious looping behaviors. Only recent successful trajectories are kept in task specific buffers to stabilize learning.

Scaling this RL environment matters in practice. The research team shows that increasing the number of parallel GUI environments from 32 to 512 yields about 5.2 percentage points improvement on navigation success, and increasing the allowed environment steps from 15 to 50 adds about 4.3 points.

On the AndroidWorld benchmark, which evaluates online navigation in a standard Android app suite, the largest MAI UI variant reaches 76.7 percent success, surpassing UI-Tars-2, Gemini 2.5 Pro and Seed1.8.

Key Takeaways

• Unified GUI agent family for mobile: MAI-UI is a Qwen3 VL based family of GUI agents from 2B to 235B A22B, designed specifically for real world mobile deployment with native agent user interaction, MCP tool calls and device cloud routing, rather than only static benchmarks.
• State of the art GUI grounding and navigation: The models reach 73.5 percent on ScreenSpot Pro, 91.3 percent on MMBench GUI L2, 70.9 percent on OSWorld G and 49.2 percent on UI Vision, and set a new 76.7 percent SOTA on AndroidWorld mobile navigation, surpassing UI Tars 2, Gemini 2.5 Pro and Seed1.8.
• Realistic MobileWorld performance with interaction and tools: On the MobileWorld benchmark with 201 tasks across 20 apps, MAI UI 235B A22B reaches 41.7 percent overall success, with 39.7 percent on pure GUI tasks, 51.1 percent on agent user interaction tasks and 37.5 percent on MCP augmented tasks, beating the best end to end GUI baseline Doubao 1.5 UI TARS at 20.9 percent.
• Scalable online RL in containerized Android: MAI-UI uses an online GRPO based RL framework over containerized Android environments, where scaling from 32 to 512 parallel environments gives about plus 5.2 points in navigation success and increasing the environment step budget from 15 to 50 gives another plus 4.3 points.

Check out the and . Also, feel free to follow us on  and don’t forget to join our  and Subscribe to . Wait! are you on telegram? 

The post appeared first on .