# ZJU-OmniAI Data-Copilot for Chinese Financial Data Workflows

> Data-Copilot is a Python system that turns natural-language requests into financial data workflows for Chinese stocks, funds, economic indicators, company information and news. It is best suited to researchers and developers willing to provide model and Tushare credentials and adapt its dated interfaces.

**ZJU-OmniAI/Data-Copilot** — Data-Copilot: Bridging Billions of Data and Humans with Autonomous Workflow

- Repository: https://github.com/ZJU-OmniAI/Data-Copilot
- Website: https://arxiv.org/abs/2306.07209
- Stars: 1,513 · Forks: 154
- Language: Python
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/zju-omniai-data-copilot

## Data-Copilot's Chinese Financial Data Boundary

Data-Copilot addresses a specific problem: converting a human request about Chinese financial information into a sequence of data operations and a result that can include text, charts and tables. The released repository focuses on Chinese stocks, funds, economic data, company financial data and live news. That scope is narrower than the broad title suggests, and it is an important adoption boundary. The README says the release was built on GPT-3.5, whose input was limited to 4k tokens at the time, so this version covers Chinese stocks, funds and economic data. Data from foreign financial markets may be supported in the future, but the repository does not provide that support as a documented current feature.

The intended users are people who already need to inspect, analyze, predict or visualize financial data and are willing to describe the task in natural language. A user can request information such as a stock analysis, fund comparison or economic indicator analysis through the command-line script or the Gradio demo. The system is not presented as a general-purpose financial database or as a conventional query language. Its differentiator is the workflow layer: the request is interpreted, divided into tasks, connected to interfaces and turned into outputs without requiring the user to assemble every call manually.

The financial scope also affects how the tool should be judged. It depends on external data access through Tushare and on an LLM provider. Some Tushare interfaces used by the repository are only available to accounts with enough credits. The README also warns that stock names are matched against a local list saved on 2023-04-21, so companies listed or renamed after that date are not found. These are concrete constraints for anyone considering adoption, not hypothetical edge cases.

## The Five-Stage main.py Workflow

The workflow is centered on `main.py`, which the project structure identifies as the path from intent detection to task planning, tool calls, visualization and summary. The README lists five stages. First, intent detection rewrites the user's request into a precise instruction with concrete dates and indicators. This step is intended to reduce ambiguity before data access begins. Second, task planning breaks the revised instruction into smaller operations. The remaining stages connect those operations to tools, transform the returned data, and prepare a summary and visual output.

The repository separates the system into several code areas. `tool.py` contains interface tools for data acquisition, processing, prediction and visualization. `tool_lib/` contains interface descriptions shown to the LLM, with one file per task. `create_tool/` contains atomic Tushare API descriptions used during interface design. `prompt_lib/` holds prompts and in-context examples for the workflow stages and tasks. This separation suggests that the LLM is not given unrestricted access to arbitrary Python. Instead, it receives descriptions of available interfaces and chooses among tools intended for specific operations.

The dispatcher can invoke corresponding interfaces sequentially or in parallel. According to the README, the Designer independently produces interface tools through self-request and iterative refinement, while the Dispatcher connects those tools to the planned workflow. Raw data from heterogeneous sources can then become graphics, tables and text. In the web demo, the intermediate process appears in the `Solving Step` box, while the final response is shown under `Summary and Result`, together with a chart and table. That visibility is useful for understanding why a result was produced, although the README does not document how errors from a failed Tushare call are repaired or retried.

## Command-Line Setup and First Request

The README requires Python 3.8 through 3.10 and says the project was tested with Python 3.9 and 3.10. It does not provide a prebuilt command-line binary or a separate package release. The documented setup clones the repository, creates a Conda environment, installs the pinned requirements and configures credentials before running `main.py`.

The following commands reproduce the documented installation path. After changing into the repository and activating the environment, `pip install -r requirements.txt` installs the versions listed by the project. The requirements include older releases such as `pandas==1.4.3`, `numpy==1.22.4`, `openai==0.27.0` and `gradio==3.34.0`, so compatibility with a newer system Python should not be assumed.

```bash
git clone https://github.com/ZJU-OmniAI/Data-Copilot.git
cd Data-Copilot
conda create -n data-copilot python=3.10 -y
conda activate data-copilot
pip install -r requirements.txt
```

Financial access requires `TUSHARE_TOKEN`. The model call in `main.py` uses `OPENAI_KEY` for GPT or `DASHSCOPE_API_KEY` for Qwen. Set the variables in the shell before launching the script. The README's Qwen instructions name the DashScope variable, but its example exports only the Tushare and OpenAI variables.

```bash
export TUSHARE_TOKEN="your-tushare-token"
export OPENAI_KEY="sk-..."
```

Run the script with the documented command:

```bash
python main.py
```

The script answers the example request at the end of the file. To change the question, edit `instruction`. To change the model, set `model` to `"gpt"` or `"qwen-chat-72b"`. The README says the model names are set in `lab_gpt4_call.py` as `gpt-3.5-turbo` and in `lab_llms_call.py` as `qwen-72b-chat`. If those names are no longer offered by the provider, the files need to be edited.

## Running the Gradio Demo and Reading Its Output

The web demo is a separate entry point, `app.py`, and uses Gradio 3.x. The requirements file pins `gradio==3.34.0` because the application uses that older API. It also pins `gradio_client==0.2.7`, noting that newer versions break Gradio 3.34, and pins `fastapi==0.99.1` because Gradio 3.34 needs Pydantic 1 and Starlette below version 1.0. The dependency combination is therefore part of the installation decision, not an incidental detail.

Start the demo with:

```bash
python app.py
```

Then open `http://127.0.0.1:7860`, as stated in the README. The interface asks for an OpenAI key. For Azure-OpenAI, it asks for the key, API base and deployment name, also called the engine. For the Qwen path, the repository documents `DASHSCOPE_API_KEY` for `main.py`, but the README does not give a corresponding Qwen credential-entry procedure for the web page. The demo documentation specifically describes entering an OpenAI or Azure-OpenAI key on the page.

A user can type a request or select one of the example boxes, then click `Start`. The `Solving Step` box is intended to expose the intermediate workflow. The final output is presented as a `Summary and Result`, plus a chart and a table when the workflow produces them. The README warns that a free OpenAI plan is slow because of its rate limits and describes a paid plan as recommended. That recommendation concerns demo responsiveness and does not imply any claim about the quality of the financial result.

The demo's practical value is observability for a single request. It lets the user inspect the sequence of actions instead of receiving only a final answer. The README does not describe authentication, persistence, request isolation, quotas for a hosted deployment or a documented production configuration. Those omissions limit the evidence available for treating `app.py` as more than an example interface.

## Tool Design, Data Flow and External Dependencies

Data-Copilot's architecture is driven by a collection of financial interfaces rather than a single end-to-end model call. `create_tool/` describes atomic Tushare APIs, `tool_lib/` presents task-oriented interface descriptions to the LLM, and `tool.py` implements tools for acquisition, processing, prediction and visualization. Prompts and demonstrations in `prompt_lib/` guide each stage. The flow therefore separates instructions and interface knowledge from executable Python code.

The data path is external in two directions. The system needs a model provider to interpret requests and plan operations, and it needs Tushare to retrieve financial data. After retrieval, processing code uses Python libraries such as `pandas`, `numpy`, `scikit-learn`, `scipy`, `matplotlib` and `mplfinance`. The README identifies `data/` as the location for local A-share stock lists, funds and SW2021 industries, and `fonts/` as the location of a SimHei font used for Chinese chart text. `output/` stores tables saved by `print_save_table`.

This design has a clear advantage for inspection. The repository exposes where task descriptions, prompts and tools live, and the web interface shows intermediate steps. It also creates several failure points. A provider model may no longer accept the documented model name, a Tushare endpoint may require credits, a local instrument name may be absent from the dated stock list, or a plotting dependency may not render Chinese text correctly. The README documents these dependency and data constraints, but it does not promise automatic retries, structured validation of financial outputs or a guarantee that every generated chart is appropriate for the requested analysis.

## Maintenance Signals and the Cost of Upgrading

The repository is not archived, and its last push was on 2026-09-26. The project has no GitHub releases, so there is no documented release cadence or packaged upgrade path. The MIT license permits use and modification under its terms, but the license text should be reviewed for the obligations it imposes. The repository does not provide a migration guide for changing Python, Gradio, model providers or Tushare interfaces.

The fixed requirements file is the clearest maintenance constraint. It pins several packages to versions from the project's original environment and includes compatibility notes for Gradio, `gradio_client`, FastAPI, Pydantic and `setuptools`. An upgrade to a newer Python or package release can therefore change more than the application code. The documented model names are also tied to files in the repository rather than controlled through a current package version. If a provider retires `gpt-3.5-turbo` or `qwen-72b-chat`, the README directs the user to edit the corresponding call file, but it does not document compatibility tests for the change.

The local stock list dated 2023-04-21 adds data-maintenance work. A renamed or newly listed company will not be found by the documented matching process. The README does not describe a procedure for refreshing that list, so updating it would require examining the repository layout and the relevant matching code. No GitHub releases are available, and no rollback procedure is documented. In practice, adoption should include a check of the pinned environment and the external provider and data interfaces before the code is placed into a larger workflow.

## Conclusion

Data-Copilot suits developers prototyping natural-language analysis over Chinese financial data, especially when intermediate workflow steps and charts are useful. It is a poor fit for production deployment without checking provider compatibility, Tushare access, outdated reference data and the limited Chinese-market scope first. The repository's last push was on 2026-09-26, but its dependency pins and documented GPT-3.5 and Qwen model names should be verified before adoption.

## FAQ

### How do I install Data-Copilot?

The README requires Python 3.8 through 3.10, recommends Conda, and documents cloning the repository, creating a Python 3.10 environment and running `pip install -r requirements.txt`. It says the project was tested with Python 3.9 and 3.10.

### Which API keys does Data-Copilot need?

Data-Copilot uses `TUSHARE_TOKEN` for financial data. The README lists `OPENAI_KEY` for GPT in `main.py` and `DASHSCOPE_API_KEY` for Qwen in `main.py`. Some Tushare interfaces require an account with enough credits.

### How do I run the Data-Copilot web demo?

Run `python app.py` and open `http://127.0.0.1:7860`. Enter an OpenAI key, or the required key, API base and deployment name for Azure-OpenAI, then submit a request and inspect `Solving Step`, `Summary and Result`, the chart and the table.

### Does Data-Copilot support foreign financial markets?

The README says this release covers Chinese stocks, funds and economic data. It states that foreign financial-market data may be supported in the future, so foreign-market support should not be treated as a current feature.

### Why might a stock name not be found by Data-Copilot?

The README says stock names are matched against a local stock list saved on 2023-04-21. Stocks listed or renamed after that date are not found.

## Sources

- [Issues](https://github.com/ZJU-OmniAI/Data-Copilot/issues)
- [License: MIT](https://github.com/ZJU-OmniAI/Data-Copilot/blob/main/LICENSE)
- [Project website](https://arxiv.org/abs/2306.07209)
- [README](https://github.com/ZJU-OmniAI/Data-Copilot/blob/main/README.md)
- [ZJU-OmniAI/Data-Copilot on GitHub](https://github.com/ZJU-OmniAI/Data-Copilot)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zju-omniai-data-copilot