OpenAI4S review: a Code-as-Action science agent that runs on a ¥9.9 Doubao plan

What OpenAI4S is trying to solve, and for whom

Most research agents force a choice. Either the model calls a fixed set of named tools, which is auditable but cannot express a loop over a hundred CSV files, or the model writes free-form code, which is flexible but leaves no clean record of what was permitted. OpenAI4S, from the Peking University and YuanKong Intelligence AI Joint Research Laboratory, refuses the choice and runs two action planes at once. Provider-native JSON tool calls handle orchestration, permissions, metadata, external services and human approval. Python and R Code-as-Action handles computation, exploration, analysis and simulation in persistent kernels. The README states the intent plainly: each plane does the job it is good at. The target reader is a researcher or research engineer who wants an agent that can hold a 100k-row DataFrame in kernel memory while the control plane stays structured. The pricing pitch is aimed at the same person's budget: the README says the entry Small tier of the Volcengine Ark Agent Plan costs ¥9.9 per month, roughly US$1.4, and that picking the ark provider in the UI is all it takes to use Doubao instead of a frontier model key.

Two action planes, one ledger, and the host.submit_output contract

The architecture is easier to understand as two state machines sharing one session. The JSON plane advances one ordered native-tool batch at a time and appends to an Action Ledger, which the README describes as append-only. The science plane advances one complete code cell at a time, keeps state in kernel memory, and writes versioned artifacts. Python cells can synchronously call the in-kernel host API while they run, and R is described as an independent persistent analysis channel. Completion differs between the planes in a way worth reading twice. Tool-only and conversational work finishes through finalize_response, which the Engine owns and which is strictly structured. Scientific cells finish through host.submit_output, and the README says that is the only completion signal that can fire inside a Cell, with a later sole finalize_response still able to close the Engine after earlier Cells have run. R has no in-cell completion at all. The README's own illustration of the payoff is a ReAct loop of roughly fourteen round trips (read, then filter, then sort, then plot) collapsing into a single code cell, with only a summary string such as a DataFrame shape reaching the context window while the full frame stays in the kernel.

Installing OpenAI4S and running a first session

There are three documented routes. PyPI packaging arrived with v0.1.0, the macOS .dmg ships an embedded Python and the default kernel science stack, and v0.2.0 added a relocatable Linux x86_64 tarball. For a Python environment, the project requires Python 3.10 or newer and declares no core dependencies at all: the pyproject file comments that the LLM client uses urllib. Scientific libraries are an optional extra, and every numpy, pandas or matplotlib import in the tree is guarded by a try/except ImportError.

pip install openai4s
openai4s --version

The version flag was added in v0.2.0, so a v0.1.0 install will not answer it. To get the optional science stack, install the extra rather than the bare package.

uv sync --extra science

The extra pulls numpy, pandas, matplotlib and scikit-learn. The README's startup guide is at docs/startup-guide.md and is the place it sends new users. For a container instead of a Python environment, the repository ships a Compose file whose comments give the exact sequence.

docker compose up -d --build
docker compose exec openai4s openai4s url
docker compose logs -f openai4s

The second command prints the URL together with its access token, which is what you paste into the browser. The Compose file pins the published port to 127.0.0.1:8760 on purpose, and its comments explain why: publishing 0.0.0.0:8760 would put a code-execution surface on every host interface with a single bearer token in front of kernel/execute. Reach it over an SSH tunnel, or put a TLS reverse proxy in front. If you use a bind mount instead of the named volume, the comments warn that the host directory needs chown -R 1000:1000 first or the daemon cannot create its own database.

The Skill library and the npx installer

The science plane is extended by importing a library or loading a Skill, and the repository ships a separate npm package for that. @pku-yuangroup/openai4s-skills is versioned 0.2.0, licensed MIT, requires Node 18 or newer, and describes itself as installing the OpenAI4S Skill library into Claude Code, OpenAI4S, or any directory. Its bin entry is openai4s-skills, so the install path is a single npx invocation rather than a clone. The counts differ between two documents in the same repository: the v0.2.0 release note describes a pinned 561-recipe bioSkills collection within 603 Skills in all, while package.json describes 604 scientific recipes. That is a one-recipe discrepancy between the release note and the package metadata, and nothing in the repository explains it. Treat the number as approximate and check the installed directory if the exact count matters to you. The npm package has no runtime dependencies; playwright appears only as a devDependency.

Where OpenAI4S is the wrong tool

The project is classified Development Status 3 - Alpha in its own pyproject file, with two tagged releases behind it. That classification is the honest summary of its readiness. The v0.2.0 release note says the Windows and WSL2 zip is built and under stabilization and ships in a coming release, so Windows desktop users have no packaged option yet; the release note for the earlier main-branch work says the Windows package was built and tested there and still follows later. Anyone whose workflow depends on a Windows installer should treat this as unavailable rather than pending. The container image has a second constraint baked in: the Compose file fixes the container name to openai4s and comments that only one of these can run per engine, which matches its stated scope of one machine, one workbench. Teams that expected to scale the daemon horizontally will not find that here. The persistence model is also a single point of failure. The Compose comments state that the SQLite store, artifacts, session workspaces, user skills, the checkpoint CAS and the access token all live under one volume, and that losing it loses every session and re-mints the token, invalidating every browser cookie already issued. Finally, the API surface is versioned at /api/v1, which is a stability promise of sorts, but the release notes show the surface still moving between v0.1.0 and v0.2.0.

How it differs from Jupyter-based agent stacks

The obvious comparison is the family of Jupyter-kernel agents, where the notebook is the interface and the model writes cells into it. OpenAI4S inverts the emphasis. The notebook equivalent exists, but the Action Ledger is the primary record, and the science kernel is a subordinate execution channel whose output must pass through host.submit_output to count as completion. The practical difference shows up in failure handling. The v0.2.0 notes describe completion-evidence reconciliation, whose stated purpose is that a crashed cell can no longer render as a clean success. A notebook-based agent has no equivalent guarantee, because a cell that dies mid-execution and a cell that finishes both simply stop producing output; nothing reconciles the two. The second difference is the permission boundary. OpenAI4S routes metadata, external services and human approval through the JSON plane, and v0.2.0 added Auto Mode with a Guardian review boundary. In a notebook agent, the kernel is the whole world and there is no separate place to put a policy check. The trade is real: the two-plane design means more moving parts, and the R channel's lack of in-cell completion is a limitation the README states without softening.

Licence, maintenance and the cost of keeping up

Both the Python package and the npm Skill installer are MIT-licensed, and the repository carries a LICENSE file with license-files declared in pyproject. MIT is permissive: you can use, modify and redistribute the code, including in closed products, provided the copyright notice and permission notice travel with it. That is a description of the licence text, not legal advice, and the usual caveat applies that the optional science extra pulls in numpy, pandas, matplotlib, scikit-learn and, for single-cell work, a stack including rdkit, scanpy, PyDESeq2 and Pertpy, each under its own terms. The pyproject comments note that PyDESeq2 0.5.4 raised its Python floor, which is why CPU-first single-cell workflows require Python 3.11, and that Pertpy 1.0.3 is the newest release compatible with both that floor and Scanpy 1.11.5 while Pertpy 1.1.1 needs Python 3.12. Those are the version pins you inherit. On maintenance, the repository shows two releases, v0.1.0 on 2026-07-15 and v0.2.0 on 2026-08-25, and a last push on 2026-09-10. The upgrade path is documented for environments specifically: openai4s env plan, apply and rollback, introduced on main before v0.2.0, treat an environment change as a transaction. Whether an in-place upgrade of the daemon itself is reversible is not stated in the repository.

Editorial conclusion

Adopt OpenAI4S if your work is exploratory computation in a persistent Python or R kernel and you already hold a Volcengine Ark key, or if you want the 604-recipe Skill library inside Claude Code via npx. Stay away if you need a stable API, a Windows desktop package today, or a project with more than two tagged releases behind it. Before committing, verify three things against your own setup: that the science extras you need install on your Python version, that the data volume's ownership matches the container user, and that the Ark Small tier you bought is the one the README prices at ¥9.9 per month.

Frequently asked questions

Official sources

1. License: MIT
2. PKU-YuanGroup/OpenAI4S on GitHub
3. Project website
4. README
5. Releases