RELEASE NOTES
Release notes
The contents, test records and supported environments of each Tai-IoT toolkit release. Every capability names the tools, models and versions it applies to.
0.2.1 trial
Released 31 October 2026 · tested on Linux · includes a Windows and VS Code guide
Improves how the development board example installs and checks the ESP-IDF tools. The board projects, tool servers, host example and the way to get the toolkit are the same as in 0.2.0; all three boards were cross-compiled again with this release, and the firmware SHA-256 values match the 0.2.0 record.
- Installing the ESP-IDF tools: the new
prepare_vscode.py --install-esp-idf-toolsinstalls ESP-IDF's compilers, CMake, Ninja and Python environment with the toolkit's own Python, so ESP-IDF's Python environment uses the same Python version as the toolkit. - Choosing the install folder: write a folder into
tools_pathintools.jsonto install the ESP-IDF tools on another drive, with no system environment variable to set. - Checks and errors:
--checkshows whether the ESP-IDF tools and Python environment are complete and gives the install command when they are not; a build that runs into the same problem states the cause and the install command.
0.2.0 trial
Released 31 October 2026 · tested on Linux · includes a Windows and VS Code guide
Adds the development board example: the same temperature acquisition task as projects for three development boards, based on each vendor's official SDK and that board's official examples, cross-compiled into real firmware. The toolkit is now requested online: after accepting the trial terms, the applicant receives the download links by email automatically.
| Part | Contents | Notes |
|---|---|---|
| Development board example projects | ESP32-S3-DevKitC-1 (N16R8), NUCLEO-H723ZG, AT-START-F413 | Read the chip's internal temperature, print one line per sampling period and mark an alarm above the threshold. Vendor SDKs are not included; you install the pinned versions as the toolkit guide describes. |
| Board tool server | 7 tools | Read board and project information, change the sampling settings, cross-compile, flash, read back and check the serial output, and show the Git diff; flashing and read-back work only on the one board whose serial port was designated at start. See engineering tools. |
| VS Code connection | prepare_vscode.py | Creates a project from an example and writes the workspace configuration, so you can use your own model service in the VS Code AI chat. |
| Guides | Linux; Windows and VS Code | dev-boards/README.en.md and its Chinese original; WINDOWS_VSCODE.md (in Chinese) goes step by step from a fresh Windows and VS Code installation. |
| Host example | Example project and 6 tools | The tools tell the client which operations only read and which change the project or run a program; the server version shown in the client matches the toolkit. |
| How to get it | Online request | After you accept the trial terms, the download links and SHA256 checksum are sent to your email, valid for 14 days. |
Cross-compilation test record
On 31 October 2026, on Linux (Debian 13, Python 3.13), a script used the tool server once for each board: read the project, change the sampling period from 1000 ms to 500 ms and the alarm threshold from 60 °C to 28 °C, cross-compile, and show the Git diff. For all three boards the compiler actually received SAMPLE_PERIOD_MS=500U and ALARM_THRESHOLD_DECI_C=280; repeated builds of the same source give the same firmware SHA-256.
| Board | SDK and compiler | Firmware |
|---|---|---|
| ESP32-S3-DevKitC-1 | ESP-IDF v6.1; xtensa-esp-elf-gcc 15.2.0 (esp-15.2.0_20251204) | 156,448 bytes, 85% of the app partition free |
| NUCLEO-H723ZG | STM32CubeH7 v1.13.0; Arm GNU Toolchain 15.2.Rel1 (gcc 15.2.1) | 13,892 bytes, 1.32% of flash and 1.68% of RAM |
| AT-START-F413 | AT32F413 firmware library v2.1.7; Arm GNU Toolchain 15.2.Rel1 (gcc 15.2.1) | 8,516 bytes, 3.25% of flash and 6.25% of RAM |
These are cross-compilation records; the examples read the chip temperature, not the ambient temperature. The host example's natural-language test record below comes from the 0.1.1 tool server.
0.1.1 trial
Released 15 October 2026 · Linux
Adds an English guide to 0.1.0 and ships the final trial terms. The tool server, example project, environment diagnostics, automatic demo and client configuration are the same as in 0.1.0, so the test records below apply to this release as well.
- English guide: new
README.en.md, matching the Chinese guide section by section with identical commands. - Trial terms: applicants confirm the terms by email before the toolkit is sent; the trial lasts 90 days and covers the applicant and colleagues at their organization who take part in the evaluation.
0.1.0 trial
Released 15 October 2026 · Linux
The first trial release provides a local MCP tool server and a temperature acquisition C example project, so engineers can complete a full engineering task with an AI client on their own computer: read, change, build for real, run simulated tests and review the diff.
| Component | Contents | Notes |
|---|---|---|
| MCP tool server | 6 tools, 1 resource, 1 task template | Runs locally over stdio; see engineering tools for the list. |
| Example project | Temperature acquisition C program | Built with the local C compiler; 7 checks cover the sampling period, clock wraparound and alarm boundaries, using a simulated clock and synthetic temperature data. |
| Environment diagnostics | doctor.py | Checks Python, the MCP SDK, Git, the compiler and the example project. |
| Automatic demo | run_demo.py | Needs no AI account; changes, builds, tests and shows the diff automatically. |
| Client configuration | prepare_client.py | Generates Codex CLI (TOML) and Claude Code (JSON) configuration without touching personal settings. |
Natural-language tests
On Codex CLI 0.162.1 (gpt-6.1-sol, Linux), the model called the local MCP tools itself and completed the following tasks in three separate workspaces, with the tasks written in Chinese. The request logs were checked item by item against the real build output, test output, Git diffs and final reports, with no human intervention during the tasks.
- Normal task: sampling period changed to 500 ms and alarm threshold to 28 °C, built for real, 7 checks passed, 10 samples, 3 alarms.
- Error recovery: an invalid period, testing without a build and a stale build were all refused; after rebuilding, a 700 ms run passed.
- Compile failure: broken source returned a compiler error and the test was refused; the model explained the cause accurately and stopped.
Test environment
| Item | Version | Notes |
|---|---|---|
| Operating system | Linux | Regular local processes. |
| Python | 3.13.5 | Python 3.11 or later required. |
| MCP SDK | 2.3.0 | Installed from the locked dependencies. |
| Git | 2.47.3 | Local repository operations. |
| C compiler | cc 14.2.0 | Local C builds. |
System requirements
- Host example: Linux with Python 3.11 or later (including venv)
- Git and a C compiler (cc, gcc or clang)
- Development board example: the vendor SDK and compiler for the boards you use, with versions and installation steps in the toolkit guide, and about 10 GB of disk space
- Access to a Python package source; a company mirror works
- Your own accounts for the AI client and model service; the automatic demo runs without an AI account
- Guides in Chinese and English; the Windows and VS Code guide and the trial terms are in Chinese; help in English by email
For other operating systems, email web@tai-iot.com.
Chip and PLC support packs
Support packs are delivered per project and adapted to the target model, development tools and versions. Each support pack comes with an adaptation record that states:
- MCU: the chip or board, SDK, compiler, debug probe, operating system and test conditions.
- PLC: the CPU, firmware, engineering software, device packages, libraries and supported project operations. PLC work goes through the official interface provided by the vendor's engineering software, uses the customer's own licensed copy of the software, and is evaluated project by project.
- Scope of operations: reading, changing, building, simulation, flashing or downloading, and on-device verification are recorded separately.
- Separate interfaces: project programming and runtime data are adapted and authorized separately.
Submit a chip adaptation request online, or contact us at web@tai-iot.com or 400-009-9300 (within China).
Enterprise options
For enterprise R&D teams, we can discuss the following options around your existing projects and toolchains:
| Area | Scope |
|---|---|
| Your own repositories | Remote authentication, separate branches, commits and merge requests, integrated with your repository platform. |
| Environment recovery | Restoring tool versions, preparing dependencies, offline installation and reproduction across computers. |
| Permissions and task management | Task scope, operation authorization, execution records and failure handling. |
| Enterprise models | Designated model services and clients, with defined data scope and deployment conditions. |