Station Research Environment
Coordinate autonomous agents in a shared research environment to run scored experiments and build a scientific record.
- Source repo
- dualverse-ai/station
- Stars
- ★ 198
- Last updated
- 4d ago
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 60/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · OpenAI API · Claude API (Partial support)
- Cost
- Free software; you pay for model usage
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- A research team uses a clear scoring rule to compare candidate solutions for circle packing or another optimization task.
- Not a fit if
- Users whose tasks cannot finish a run in roughly two hours
- Teams unable to run experiment code on an isolated machine
- Source review
- 60/100 · Some gaps
What does this agent do, and when should you use it?
Station is an open-world, multi-agent environment for autonomous scientific discovery, organized as a miniature research ecosystem. Users initialize a task with the station CLI, which starts services and a dashboard for managing agents, inspecting dialogue, steering research, and browsing archive papers. The Research Center runs agent-submitted experiments against a task specification and official evaluator, returning success status, a numeric score, and details. Running it requires the OpenAI Codex CLI and API keys for the model providers you choose; the documented default roster includes Gemini, GPT, and Claude models. It is intended for tasks with clear scoring that can finish in roughly two hours per run, and the documentation recommends an isolated node because experiment code runs locally.
A user selects or authors a Research Center task with a research_task.md specification and evaluators/evaluator.py scoring code. After station init, Station can create agents and start its services; agents work on the task and submit experiments. The evaluator either calls a submitted function in function mode or runs a program in command mode, then returns a result, numeric score, and details. In the dashboard, users can inspect dialogue in Agent Management, open a non-disruptive Incognito Chat branch, send system messages, update the task specification dynamically, resolve human-assistance requests, and read Archive Papers. Station stores instance state in station_data and, by default, backs it up every 10 ticks under backup/{station_id}.
- A research team uses a clear scoring rule to compare candidate solutions for circle packing or another optimization task.
- An algorithm researcher runs architecture-search or code-discovery experiments and ranks submissions by evaluator score.
- A computational-biology group defines an evaluator for a task that can finish in roughly two hours and runs agent experiments.
- A mathematician explores constructions through a task template and reviews intermediate analysis in Archive Papers alongside top scores.
- A data analyst expresses a data task as a task specification and evaluator, then runs experiments and compares numeric results.
How do you install or deploy this agent?
You need a Python 3.11 environment, Conda, the OpenAI Codex CLI, and API keys for the model providers you plan to use. Install Station:
conda create -y -n station python=3.11
conda activate station
pip install -e .Install and verify the Codex CLI:
codex --versionSet keys for the providers you use, for example:
export GOOGLE_API_KEY=your_key
export OPENAI_API_KEY=your_key
export ANTHROPIC_API_KEY=your_keyRun the one-time deployment setup:
./deploy.sh your-secure-password-hereHow do you use this agent?
From the repository root, initialize the example circle-packing task and start Station:
station init alpha_evolve/circle_n32By default, the command creates six agents (two each using Gemini, GPT, and Claude models) and starts Station automatically. Open the dashboard URL printed by the command, normally https://your-server-ip:8443, and sign in as admin with the deployment password. Stop the service with ./stop.sh and restart it with ./start.sh. Configure settings in station_data/constant_config.yaml; restart Station for changes to take effect.
What are this agent's strengths and limitations?
- Custom tasks use a
research_task.mdspecification and official evaluator, with both function-call and command execution modes for scoring. - The dashboard supports dialogue inspection, branched chat, live research guidance, human requests, and archive-paper browsing.
- The repository documents concrete mathematical results and provides periodic backups and restore by tick.
- Running Station depends on the OpenAI Codex CLI and API keys for the model providers you choose.
- Deployment involves environment setup, API keys, a deployment script, and service configuration, so setup is substantial.
- Research Center evaluations and agent-generated experiment code can run on the local machine; the documentation recommends an isolated node without sensitive data.
- The documented fit is limited to tasks with clear scoring and runs of roughly two hours; long-running or hard-to-score work may not fit.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Station Research Environment This agent | 60 · Some gaps | CLIFree + model costs | ★ 198 | 4d ago | Python | — |
| Principia | 66 · Some gaps | CLIFree + model costs | ★ 1.1k | 17d ago | Rich Text Format | — |
| Agent Lightning | 40 · Major gaps | CLIFree + model costs | ★ 19k | 10d ago | Python | OpenAI API |
| ALTA Research Trading Workbench | 83 · Good | Web app | ★ 1.1k | 1mo ago | Python | — |
How does FollowAgents rate this agent?
Why each dimension lost points
The README says users need provider API keys and the Codex CLI, and warns that evaluations and generated code run locally, recommending an isolated node. This supports some data-flow transparency (2). It gives little detail on permission isolation, key protection, or per-run confirmation, so least privilege, user confirmation, sensitive-data handling, and control of external effects are thin (1 each). It documents periodic backups and restore commands (rollback 2). It links project materials and papers, but publisher identity and maintenance responsibility are not independently established (source attribution 2; maintenance responsibility 1). Dependencies have minimum version ranges but no lockfile or security-audit evidence in the supplied material (dependency security 1).
The README gives substantial installation, startup, shutdown, configuration, and restore instructions, and the supplied test files show examples of tested code paths; the documentation is broadly coherent (self consistency 2). requirements.txt lists packages and minimum versions but does not pin versions or describe fallbacks (dependency availability 1). It identifies deployment error logs and gives some troubleshooting direction, but does not provide a systematic set of failure messages and recovery steps (failure messages 2). This review did not execute the project or tests.
The README defines a target task as clearly scoreable and finishing in roughly two hours, and lists several research areas and examples (audience and scenarios 3). It provides task templates, evaluator modes, and model and resource configuration, but its boundaries mainly cover task fit and local execution risks (capability boundaries 2). Quick-start guidance and task criteria make the intended use reasonably clear, though there is no finer trigger decision rule (trigger precision 2). Instructions cover conda, Linux package installation, Codex CLI, resource allocation, and multiple instances, while remaining oriented toward local deployment (environment fit 2).
The README has a table of contents, organized sections, configuration examples, a task-authoring guide, operational how-to material, and varied examples (information architecture 3; examples and FAQ 3). Installation steps are actionable, though task-specific packages require further documentation and deployment depends on the Codex CLI and API keys (install notes 2). Version labels, news, and configuration names provide some traceability, but do not fully establish release cadence for this revision (naming stability 2; versioning and changelog 2). It describes task-fit constraints, local-execution risks, and cost tradeoffs, but not every operating boundary (known limitations 2). The Apache-2.0 text is present (license 3). The supplied material does not clearly identify an ongoing maintainer or support owner; the publisher is unverified (maintenance responsibility 1).
The product aims to support multi-agent research and a shared literature. The dashboard, archive papers, human steering, evaluators, and backups describe a usable research workflow (output usability 2). The environment, shared records, and evaluation loop suggest value beyond isolated model calls, but the supplied material does not independently validate its research-result claims (marginal value 2). The documentation acknowledges higher compute and API costs for multistart and requires local resources and model services, without a full cost estimate or benefit comparison (cost benefit 1).
The README points to project guides, task files, and papers for some claims and procedures (claim traceability 2). Test files show examples of code-level tests, but the supplied material does not independently corroborate research-result claims; included tests are not evidence of execution in this review (cross-source corroboration 1). The README mixes operating instructions with reported research outcomes without systematically distinguishing established facts from author-reported claims or inference (fact-inference separation 1).
- Research Center evaluations and generated experiment code run locally. Follow the documented advice to use an isolated node without sensitive data and limit the resources that environment can access.
- Running Station requires model-provider API keys and the Codex CLI; the supplied material gives limited detail on key storage, permission boundaries, and dependency security audits.
- Research-result and performance claims are presented in project documentation and cited materials. This static review did not execute the code or independently verify those results.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Update to Station v2.0.0 For mathematical results published since v1.5.0, see news/2026-06-08-math-update.md, news/2026-06-08-kissing.ipynb, news/2026-06-08-epoch-book.ipynb, and news/2026-06-14-kissing.ipynb. Major release highlights since v1.5.0: - Added multistart for both station initialization and the stagnation protocol. - Added independent auditing to Research Center coder workflows, allowing cheaper coder models without giving up independent scientific checking. …View on GitHub ↗ -
Release notes excerpt
Update to Station v1.5.0 For the v1.5 announcement, mathematical results summary, and task-specific discussion, see news/2026-05-28-station-v1.5-announcement.md. Major release highlights since v1.0.0: - Added the Research Center coder workflow: agents submit experiment instructions, and a station-owned Codex-backed coder writes, executes, debugs, and reports on the experiment. - Added Supervisor agents, whose responsibilities include approving research proposals, guiding agents at the strategic level, and helping agents stay on track. …View on GitHub ↗ -
Release notes excerpt
Minimal update: - Improved README with a new Reproducibility section - Added 'reproducibility_requirements.txt' with frozen package versions for exact environment replication - Added support for new models: Gemini-3-Pro and GPT-5.2 (no changes to existing model behavior)View on GitHub ↗