Arize puts code mode inside Phoenix's web UI, so its PXI agent can click through the app by script

What code mode means here

Code mode, as Arize describes it, lets an agent write code during a task as a way of getting things done, rather than as the final output. The company argues that code gives a model conditionals, loops, batching and chaining, which opens the door to behavior nobody wrote a dedicated tool for.

Arize points to two problems with classic tool calling. Every tool call is a full hop: the model decides, generates arguments, the harness executes, the result returns and the model reads it before deciding again. Three tools mean three hops. In addition, each tool is written with one use case in mind, which limits what the model can try.

The value, the author argues, comes less from giving a model a JavaScript interpreter and more from giving it a way to affect its environment through code. For Phoenix that means an SDK: "The SDK is the things that used to be tools, now expressed as functions."

Bringing it into a live web app

Phoenix already offered code mode in a conventional form. Its MCP server runs model-written Python in a Monty sandbox, with an SDK shaped like the REST API and a function for writing SQL. What Arize says it had not seen elsewhere is code mode inside a web app that a person is clicking around in at the same time.

The Phoenix UI is full of handlers tied to buttons, enter keys and route changes. Arize bundled those triggers into an auto-generated SDK. PXI, the agent built into Phoenix, writes a script on the server and sends it to the browser. The user sees a one-line description of what the script claims it will do, plus the code if they want to read it, and approves or rejects it. The script then runs in a Web Worker next to the app in the same tab. Each function it calls is noted, checked and performed by the web app as if it were a button click.

Arize gives two reasons for not simply handing PXI its API. First, not everything in the UI reaches the network. In the playground, comparisons, instances, model settings and variables are local state in the browser tab, and the server only sees prompts and outputs. Second, the frontend's synchronization is not reactive to events outside the tab. Datasets created through GraphQL would not appear until a refresh, whereas calling ui.dataset.create in a loop lets the app update the view each time, so the person watching sees it happen.

The author adds a developer benefit: adding a UI capability used to touch frontend code, backend code, a tool definition and prompting. Now it is a descriptor and a registration in the frontend, and because the catalog is rendered on request, it can change without a backend release.

Two tools, 54 operations

PXI's UI surface is now two tools. search_browser_actions returns the full catalog of browser operations, each as a TypeScript signature with a doc comment, plus whether it is usable on the current page and where it becomes usable if not. The query only ranks results. execute_browser_action takes a JavaScript program, a one-line summary for the user and, if the script changes anything, a description of the changes for approval.

The catalog holds 54 operations, derived from the 58 tools that were deleted. Most were ported directly, with a tool becoming a function. Reads of server data were dropped, since GraphQL through bash already covers them as the same authenticated user.

Arize reports that on the playground the old design advertised 33 tools costing about 14,700 tokens on every request, while the two new tools cost about 2,300 on every page. A workflow that took ten model turns as ten tool calls becomes one turn as one script. The author says extreme cases of 15 back-and-forth turns have collapsed into a single script, though only where the next step is a calculation rather than a judgment.

A script PXI wrote itself

The playground UI caps comparisons at four instances. According to Arize, PXI wrote a script that works around this with one instance: it lists every built-in model, then for each one sets the model, runs it, reads the output and stores the result, returning everything at the end. The author notes that nobody built a tool for comparing fifty models. The model composed one from three operations and a for loop.

The workflow Arize leaned on most during development is larger: starting from a bare playground and a dataset with inputs and outputs, PXI is asked to build a prompt that passes an evaluator. It must write the prompt, load the dataset, create evaluators, run the playground, read scored results and edit the prompt until everything passes. Arize calls it the most UI-heavy task it can give PXI, and the one where fewer round trips matter most.

For catalog assembly, Arize says it borrowed its approach from json-render, a library that lets a model compose a UI from existing React components using a catalog of names, descriptions and typed contracts.

What it means for Phoenix users

For people using Phoenix, the practical effects described by Arize are fewer waiting rounds when PXI handles multi-step playground work, a smaller token load per request, and an approval step before any script that changes state runs. Because actions go through the same handlers as clicks, the user can watch changes appear in the page as they happen.