DEV Community

Fenju Fu
Fenju Fu

Posted on

Astron Open Source Β· Bi-Weekly Report (Aug 24 – Sep 6, 2026)

🌟 Highlights

  • The Spark-X2.5 open model series launched globally on Sep 1 β€” Spark-X2.5-4B and Spark-X2.5-1.7B, Apache-2.0, with a hybrid-attention architecture, a native 1M-token context, and support for 200+ languages. Day-0 serving support arrived from SGLang and vLLM, and the models shipped simultaneously to Hugging Face, ModelScope, Ollama, Modelers and SCNet.
  • Ten Spark-X2.5 model repositories and one dataset are now public on Hugging Face, together accounting for roughly 74,000 downloads and 1,096 likes at the time of writing. Spark-X2.5-4B reached the Hugging Face 7-day trending models board during the cycle.
  • Thirteen repositories across the ecosystem merged 138 PRs: SkillHub 62 Β· Astron Agent 30 Β· Dolphin MCP Pilot 12 Β· MemFlywheel 6 Β· Domux 5 Β· Astron RPA 2 Β· AstronClaw Tutorial 1 Β· HarnessClaw 1 Β· and 19 across the XHToken repositories.
  • Six releases landed: SkillHub v0.2.18 and v0.2.19 plus CLI 0.1.10 and 0.1.11, Dolphin MCP Pilot v0.3.1, and the first vllm-spark2_5-plugin v0.1.0.
  • Astron Agent spent the cycle on security hardening. Thirty merged PRs covering the code-node executor, SSRF, XSS/artifact/sandbox boundaries and internal service authentication were released as the v1.1.2 security release on Sep 7, one day after this reporting window closed. Operators on v1.1.1 or earlier should upgrade.
  • Three community-reported SkillHub bugs were filed, fixed and closed inside the same two weeks β€” the disabled download button on promoted global Skills, the missing pagination on the promotion review page, and a stale SESSION cookie that blocked re-login.
  • Two challenges ran in parallel: HER Hack-Astron #4 (Domux) completed judging on Sep 2, and HER Hack-Astron #5 (Spark-X2.5) closed submissions on Sep 6 with judging scheduled for Sep 7–13.

Spark-X2.5-4B on the Hugging Face 7-day trending models board

πŸ‘₯ Top 10 Active Community Contributors

Based on message volume across 25 exported open-source discussion-group records. Automated Q&A and welcome accounts were excluded; display-name aliases were normalized and nicknames anonymized. Thank you to everyone who answered questions, asked questions, and built alongside us πŸ™Œ

Top 10 Active Community Contributors


πŸ“¦ Release & Development Highlights

✨ Spark-X2.5 β€” a compact on-device model series, open-sourced

Spark-X2.5-4B and Spark-X2.5-1.7B are general-purpose models built for practical, efficient deployment rather than benchmark-only appeal.

  • 🧠 Efficient architecture with a native 1M-token context. The models combine one full-attention layer with three sliding-window attention layers, which cuts the overhead usually associated with long context while still supporting up to 1M tokens natively.
  • πŸ€– Coding and agent capability at a small size. The models integrate with common agent harnesses including Codex, Claude Code, OpenClaw and Hermes.
  • πŸ–₯️ Broad hardware and framework coverage. NVIDIA, Huawei Ascend, Hygon and HOUMO.AI hardware; vLLM, SGLang, llama.cpp and MLX inference; Ollama and LM Studio for quick local deployment; LLaMA-Factory for fine-tuning.
  • πŸ“… Release timeline inside the window: global launch across five distribution platforms (Sep 1) β†’ AtomGit added as a channel (Sep 2) β†’ vLLM and SGLang deployment support on Ascend NPU (Sep 3) β†’ FP8 and INT8 quantized weights for both sizes (Sep 4) β†’ native Spark2_5ForCausalLM support merged upstream into llama.cpp b10829 (Sep 6).

FP8 and INT8 weights published to Hugging Face on Sep 4

Supporting repositories moved with the model. vllm-spark2_5-plugin v0.1.0 (Aug 28) brings Spark2_5 to vLLM as an out-of-tree plugin with no upstream patches, registering a spark25 tool-call parser that emits typed JSON, and shipping with Apache-2.0 licensing, third-party attribution, a lint/test/build CI pipeline and automated PyPI publishing. Spark-MLX-LLM added Spark2_5 inference for MLX plus tool wrappers, the XHToken llama.cpp fork landed the tokenizer hash, auto parser and chat-template work, and LlamaFactory gained a fine-tuning template and guide.

🧰 SkillHub v0.2.18 and v0.2.19 β€” personal namespaces, workspace sync, and a reviewable publishing loop

SkillHub merged 62 PRs, the highest of any repository this cycle, and published two server releases plus two CLI releases.

v0.2.18 (Aug 29)

  • 🏷️ Personal namespaces can be auto-provisioned for newly activated accounts, with operator-configurable naming and idempotent ownership handling (#712).
  • πŸ”„ CLI workspace synchronization arrived in CLI 0.1.10: sync pull, status, diff and push, backed by incremental fingerprint metadata (#724). Follow-ups made fingerprints deterministic across server and Node path ordering, so a clean mixed-path workspace is no longer reported as locally changed (#780).
  • πŸ“‚ Folder publishing in the Web UI: the browser builds a validated ZIP client-side, filtering VCS, build and OS metadata, with no new dependency (#757).
  • 🧱 linux/riscv64 Server and Web images, with the Scanner and the full Compose dependency stack explicitly out of scope (#725); Russian localization was contributed by @michael-xiii (#700).
  • πŸ›‘οΈ Transactional scan-task outbox: scan tasks can no longer be lost between the database commit and Redis publication, with retries, reclaiming, cleanup and consumer idempotency (#752).
  • 🐳 Upgrade safety: the Server's numeric UID/GID is preserved across the Alpine-to-Noble runtime-image change, so local-storage volumes created by v0.2.17 stay writable (#779). Flyway V44/V45 apply automatically β€” back up PostgreSQL first.

v0.2.19 (Sep 4)

  • πŸ“ The review loop became visible to authors: review progress, durable attempt history, and resubmission of rejected versions (#791), plus public text reviews with author editing and audited administrator moderation (#793).
  • πŸ” Failed security scans became recoverable: a permission-checked, idempotent retry for terminal SCAN_FAILED versions (#811), and bounded recovery so expired deliveries become SCAN_FAILED rather than pending forever (#809).
  • 🧭 Install-for-agent prompt on skill details, preserving full namespace coordinates (#788), and the pinned HOL Guard plugin-scanner Skill added to the curated starter collection β€” a Skill, not an extension of the Server scanner pipeline (#814).
  • βš™οΈ CLI 0.1.11 adds bounded source-safe Skill upgrades, fingerprint-safe install and sync, explicit namespace pull selection, and accurate asynchronous submission status (#796, #804, #815, #816).
  • πŸ› Correctness work included deterministic conflicts for concurrent publishes of the same coordinate (#784), converged concurrent OAuth identity binding and atomic governance-plus-audit mutations (#786, #787), paginated promotion review queues (#774), and SPA entry revalidation after deployments (#812).

πŸ€– Astron Agent β€” a security-hardening cycle, released as v1.1.2

Astron Agent merged 30 PRs during the window. Almost all of them fed into the v1.1.2 security release published on Sep 7, one day after this window closed.

  • 🚨 Workflow code execution and tenant isolation. Versions <= v1.1.1 using the legacy unsandboxed local code executor allowed an authenticated user with workflow-creation permission to execute code inside the workflow service container and, in affected deployments, reach other tenants' data. v1.1.2 rejects unsafe local execution and defaults to the built-in isolated LangChain/Pyodide executor, migrating untouched legacy configuration while preserving explicit process-level overrides (#1650, #1651). Advisory: GHSA-mh3w-4q3f-2fg5. Reported by Noy Pearl and the Lasso Security team.
  • πŸ”’ SSRF prevention in outbound plugin requests (#1669) and hardened XSS, artifact and sandbox boundaries with scoped CSRF exclusions (#1643).
  • 🐳 A secure deployment contract enforced in the Docker layer (#1633), MinIO policy compatibility preserved (#1634), and static migration statements in the console (#1640).
  • 🧩 Workflow runtime fixes: isolated code fallback enabled by default (#1649) and zero-parameter code entrypoints supported (#1636).
  • πŸ“š Documentation and build reliability: a FAQ entry for workflow publishing failing when basic info is missing (#1630), a Related Projects section linking sibling Astron repositories (#1627), a repaired Japanese README image path (#1653), a VitePress example gallery fix (#1655), and PyPI/Maven Central retry handling (#1660, #1657).

⚠️ Upgrade note. CODE_EXEC_TYPE=local is no longer supported. Update deployment files and service images together β€” updating only the source checkout or only the workflow image does not apply the complete fix.

βš™οΈ Astron RPA β€” log sanitization and a repaired MCP discovery chain

Astron RPA merged 2 PRs, both closing reported defects.

  • πŸ” Sensitive data could reach OpenAPI, rpa-auth and nginx logs (#858, closing #855). A unified sanitizer now redacts API keys and secrets, bcrypt hashes, Authorization/Token/Cookie/Session values, passwords, verification codes, temporary credentials and phone numbers across application logs, Uvicorn access/error logs, Logback output and stack traces. The nginx access-log format switched to $uri without query parameters and dropped Referer, while keeping method, status, size, User-Agent and latency for troubleshooting.
  • πŸ”— Published workflows were invisible to MCP tools/list (#860, closing #859). robot-service synced workflows to a container address that does not exist in the official Compose stack, and omitted active-status and name metadata. The sync URL is now configurable via OPENAPI_WORKFLOWS_UPSERT_URL with the old address retained as a fallback, and the published-workflow DTO carries project_id, name, description, version, status = 1 and parameters.

🐬 Dolphin MCP Pilot v0.3.1 β€” discoverable through the official MCP Registry

Dolphin MCP Pilot merged 12 PRs and published v0.3.1 on Aug 31.

  • πŸ“‡ Published to the official MCP Registry as io.github.iflytek/dolphin-mcp-pilot, so MCP hosts can find and install it without being pointed at the repository by hand (#20). Publication is gated on the image push, authenticates with GitHub OIDC, validates server.json against its schema, and re-checks the GHCR ownership label before publishing.
  • πŸ—‚οΈ A community case-study gallery under cases/ collected six accepted studies covering release-gate recovery, safe weekday schedule changes, human-gated project cleanup, request-scoped team isolation, and nightly-ETL incident firefighting (#24, #39, #40, #41, #46).
  • πŸ“¦ PyPI trusted publishing was added (#44); until it lands, Docker and source remain the supported install paths.

🏠 Domux β€” the HER Hack-Astron #4 case corpus

Domux merged 5 PRs: the case framework with automatic validation (#15) plus four community case studies (#23, #24, #26, #29). See the Community Spotlight below.


πŸ’¬ Community Q&A & Discussions (Bi-Weekly Picks)

The following themes were distilled from anonymized WeCom support and open-source discussion records for Aug 24 – Sep 6. Automated Q&A answers were not treated as authoritative unless a human resolution or repository evidence confirmed them β€” several were wrong in this cycle and were corrected in-thread by maintainers or by other community members. 🟒 Resolved Β· ℹ️ Clarified Β· 🟑 Follow-up needed.

Spark-X2.5

  • ℹ️ What hardware does it actually need? For a single stream at the full 1M context, plan on about 32 GB of VRAM; 128 K context runs comfortably on 16 GB. CPU-only is viable for the 1.7B: community members measured roughly 2–3 tokens/s for BF16 weights on a 16 GB business laptop, and about 24 tokens/s prefill with 9.5 tokens/s decode for a quantized build on 8 CPU cores. Non-NVIDIA accelerators including Ascend and Hygon are supported.
  • 🟒 Ollama and LM Studio need a local build for now. Until upstream support landed, running Spark-X2.5 through Ollama or LM Studio required compiling the XHToken llama.cpp fork and pointing the runtime at it β€” a macOS LM Studio load error in one thread was resolved exactly this way. Community members shared the working build path, and a contributor noted you can skip the manual GGUF download entirely with ollama run SparkLLM/Spark-X2.5-4B. Native Spark2_5ForCausalLM support then merged upstream into llama.cpp b10829 on Sep 6.

Community-shared Ollama build path for Spark-X2.5

  • ℹ️ Does it conflict with an existing Ollama install? Shut the stock Ollama service down first; the Spark-enabled build then serves on the same 11434 port, so other applications keep working against the familiar endpoint.
  • ℹ️ Is there a GGUF build of the 4B? Yes β€” XHToken/Spark-X2.5-4B-GGUF. The Q&A bot answered that only the 1.7B had GGUF weights; a community member supplied the correct link in the thread. FP8 and INT8 weights followed on Sep 4, with GGUF builds of those quantizations expected the following week.
  • ℹ️ How much does 4-bit quantization cost you? One contributor benchmarked IQ4_NL, IQ4_XS, XS-UD and Q4_K_M against the BF16 baseline on their own instruction-following task set and measured 94.5%–95.8% retention, using an imatrix calibrated for that specific task β€” a task-tuned calibration set, not a general-purpose claim.

Community 4-bit quantization retention measurements against the BF16 baseline

  • 🟑 The 1.7B can fall into repetition loops on some prompts where the 4B stays stable; this was independently observed by more than one person and by the team. Separately, the SGLang nightly image referenced in the documentation did not have the hybrid sliding-window attention pool enabled β€” the fix was committed to the repository but had not yet reached a published image at the time of the thread.
  • ℹ️ Is there a vision or multimodal variant? No. Spark-X2.5 is text-only.
  • ℹ️ Downloading from mainland China: use the ModelScope mirror; AtomGit, Modelers and SCNet are also official channels.

SkillHub

  • 🟒 Why is the download button greyed out on a Skill promoted to @global? This was reported on Aug 27 by a member who noticed the behaviour contradicted the documented rule that @global + PUBLIC allows anonymous search, inspect and download. The maintainer confirmed it as a bug rather than intended design, asked for an issue, and #763 was closed on Sep 2 with regression coverage added in #792.

The documented @global + PUBLIC download rule that the promoted-Skill card contradicted

  • 🟒 Older pending promotion requests disappeared from the review page. The administrator promotion queue rendered without pagination, so once enough requests accumulated the earlier ones became unreachable. Reported Aug 28 as #772, closed Aug 31, with paginated review queues shipping in v0.2.19 (#774).
  • 🟒 A stale SESSION cookie blocked re-login with "Session expired" until cookies were cleared (#802, closed Sep 3). The fix keeps public routes accessible when a browser carries an expired session (#783) alongside broader session-boundary hardening (#801); a member asked whether #801 was in the latest release β€” it shipped in v0.2.19 on Sep 4.
  • ℹ️ When is LDAP support landing? A contributor pointed out that the roadmap item was still unchecked even though #672 looked merged. The maintainer clarified that it merged into a feature branch rather than main, that an earlier community PR was not general enough, and that the unified identity design needs another pass before it ships.
  • ℹ️ Will SkillHub keep tracking the ClawHub CLI? No. Chasing every ClawHub release is not sustainable, so the recommendation is the SkillHub CLI from npm. v0.2.19 documents which ClawHub search, inspect, install and publish workflows remain compatible (#806).
  • 🟑 skill-scanner reports "scan failed" with 0 findings. v0.2.19 makes terminal SCAN_FAILED versions retryable (#811) and bounds recovery of unavailable tasks (#809), so the state is no longer a dead end. The underlying cause is still per-deployment: capture the scanner worker logs and the version's audit record before escalating.

A terminal skill-scanner failure with zero findings, reported during the cycle

Astron RPA

  • 🟒 An MCP call returns code: O000 / "运葌成功" but data: {}. Fixed by #860 on Sep 3. The published workflow was never fully registered with the OpenAPI service, so MCP could report success without the workflow being discoverable or returning output. Upgrade to a build containing the fix, and set OPENAPI_WORKFLOWS_UPSERT_URL if your deployment does not use the official Compose service names.
  • ℹ️ The EXE installs but the client shows 502 on launch. The desktop client is not a standalone application β€” it requires reachable backend services. A 502 means the client started but could not reach a working server. Note also that the GitHub release artifact and the client published on the official site are not interchangeable.
  • ℹ️ Is there a web console in the open-source edition? No. The open-source stack is desktop-client based and currently targets Windows 10/11.
  • ℹ️ Does it support scheduled execution? Yes β€” direct run, scheduled tasks with cron expressions, scheduler mode and API invocation are all available.
  • ℹ️ Fingerprint-browser integration for multi-account scenarios? Not currently supported. The browser automation path is built on the browser plugin architecture for Chrome, Edge and Firefox; there is no documented way to attach to a fingerprint browser or bind through the Chrome DevTools Protocol.
  • ℹ️ Is there a KingbaseES (人倧金仓) Docker image? Not provided. MySQL and Redis are the documented defaults for server deployment.
  • 🟑 Nightly runs fail with "user actively closed" although nobody touched the machine. The record did not establish a root cause. Before escalating, capture the client and scheduler logs around the failure timestamp, the session/idle timeout configuration, and whether the host sleeps, locks or drops its network connection overnight β€” treat "user actively closed" as a symptom label, not a diagnosis.

Astron Agent

  • ℹ️ Publishing a workflow fails without a clear reason. The most common cause is incomplete basic information on the workflow; the cycle added an FAQ entry covering it (#1630).
  • 🚨 If you self-host, upgrade. See the v1.1.2 notes above. Automated vulnerability scanners may not flag this application-level issue, so verify deployed image versions explicitly rather than relying on a scan result.

πŸ”­ Community Spotlight: HER Hack-Astron #4 and #5

HER Hack-Astron #4 β€” Domux smart-home real-world cases (judged Sep 2)

Contributors ran real inference, evaluation, quantization, training or integration experiments against Domux, published the full write-up in the model's Hugging Face Discussions, and submitted it as a PR into cases/.

πŸ† Champion β€” domux-seniorsafe (Discussion #7, PR #29 by @qrx-joe). It won not for the best-looking numbers. It was the only entry that completed a three-round freeze-then-run-then-publish progression: after fixing a normalization defect it re-ran the entire dataset rather than cherry-picking, lifting normalized exact match from 75.7% to 85.7%, and proved both runs used the same model and configuration by showing 80/80 raw-pipeline outputs were byte-identical to round one. Round three froze a 160-case challenge set, the evaluation protocol and a SHA-256 fingerprint before running 320 real CPU inferences β€” then published the unflattering results in full (raw 55.1%, normalized 61.8%, 5/24 input-strategy misses, 2/24 blocked-label requests still surfacing as candidates) and explicitly declined to patch defects discovered after the freeze. The case also labelled its own "100% rule-layer safety" figure as true by construction, not a model metric, dismantling a number that could easily have been presented as capability.

🌟 Outstanding contributions: domux-4057-full-eval (full 4,057-sample BF16 vs NF4 comparison on an RTX 4090D, publishing 97.58% / 93.57% accuracy and the "saves memory but does not speed things up" deployment boundary); domux-4057-rtx3090-eval (PR #23, consumer-GPU reproduction reporting accuracy, concurrent latency and single-request latency separately); domux-safety-gate (PR #24, advancing from input-only checks to all seven output fields and keeping 18/28 false interventions in the report); domux-clarify-commit (PR #26, 96 BF16 inferences driving real Home Assistant REST state changes, 3/3 exact commits and 1/1 pre-dispatch rejection of genuine state drift); and domux-mcp-server (a four-tier auth, high-risk confirmation, audit-log and risk-scoring integration direction).

Two award-winning entries were deliberately not merged: an award does not waive the repository's hard acceptance criteria β€” one failed the account-reputation check, the other had an unsigned DCO and was missing the source, tests and raw evaluation artifacts its own reproduction commands required.

HER Hack-Astron #4 β€” Domux smart-home real-world case challenge

HER Hack-Astron #5 β€” Spark-X2.5 edge-agent cases (submissions closed Sep 6)

The fifth challenge opened the same day the model launched. Every entrant from #4 was personally invited to carry their frozen-evaluation, CPU/GPU deployment, failure-analysis and safety-gate methods into the new subject matter.

Submissions landed across a wide hardware and topic range: tool-calling safety boundaries on an Apple M3; Q4_K_M coding, throughput and OOM boundaries on a discrete-GPU-free 8-core/16 GB Linux box; Chinese meeting-note JSON extraction on a 24 GB laptop CPU; multilingual (English/Chinese/Thai) guardrails on an Intel Mac showing that valid JSON can still be unsafe; a bilingual CPU safety gate for destructive automation; a Godot game prototype driven from bad JSON to a playable hundred-round build; an OpenClaw agent tool-calling and safety evaluation scoring 20/21; agent-handoff continuity testing on an M3; edge deployment on an 8 GB AMD RX 580 over Vulkan; and a repository-review case that traced a vLLM 0.23 parser compatibility break through three fixed-protocol reviews and landed the fix upstream as Spark-plugin #10.

Submissions closed at 24:00 Beijing time on Sep 6 and judging runs Sep 7–13, so this report does not announce a winner.

πŸ‘‰ HER Hack-Astron #5 Β· Spark-X2.5 edge-agent challenge

HER Hack-Astron #5 β€” Spark-X2.5 edge-agent real-world case challenge

Hack-Astron x openKylin #1 β€” running skills on a domestic OS (Sep 3 – 24)

A new challenge opened on Sep 3, jointly with openKylin. Entrants deploy the open-source editions of Astron Agent and SkillHub locally on openKylin Desktop 2.0+, implement skill logic with Astron Agent's native RPA engine, and submit through a PR to the openKylin-skills repository. Cloud-only submissions without a completed local deployment are not accepted. Suggested directions include UKUI desktop automation, package management, community-operations automation, WPS/LibreOffice RPA and system health inspection. Contest runs to Sep 24, judging Sep 25–30.

πŸ‘‰ Hack-Astron x openKylin #1

Community momentum

The @SparkLLM account passed 500 followers within 12 hours of the launch, and independent reviews, videos and mobile-integration experiments β€” including PocketPal AI with the XHToken llama.cpp fork for iOS and Android local inference β€” appeared within days.

The @SparkLLM account passing 500 followers within 12 hours of launch


πŸ™Œ Build With Us

Good starting points from this cycle include:

  • run Spark-X2.5 on hardware we have not covered yet β€” Ascend, Hygon, older consumer GPUs, or plain CPU β€” and publish throughput, memory and failure boundaries rather than a single score;
  • contribute a reproducible quantization comparison with a general-purpose calibration set, so the community has a counterpart to the task-tuned measurements published so far;
  • reproduce the 1.7B repetition-loop behaviour with a minimal prompt and a fixed revision, and file it with raw outputs;
  • validate SkillHub's namespace workspace sync and the new review/resubmission loop against a realistic multi-reviewer setup;
  • test the Astron Agent v1.1.2 isolated code executor against workflows that previously relied on host filesystem, subprocess or network access, and report what needs adapting;
  • contribute a redacted Dolphin MCP Pilot case that changes real workflow state and verifies the terminal outcome;
  • build an openKylin skill end-to-end on a local Astron Agent + SkillHub deployment for Hack-Astron x openKylin #1.

Before starting, leave a comment on the relevant issue so maintainers can confirm scope and avoid duplicated work.


πŸ”— Explore the Astron Open-Source Ecosystem

Methodology note: PR totals use GitHub merged_at timestamps from Aug 24 through Sep 6, 2026, across the eleven repositories tagged iflytek-astron plus the XHToken organization repositories. Release dates use GitHub published_at. Hugging Face download and like counts are a snapshot taken on Sep 8, 2026 and will keep moving. Astron Agent v1.1.2 was published on Sep 7, one day after the window closed, and is reported here because the work it contains was merged inside the window. Community questions were anonymized and condensed; screenshots reproduced here were shared in the open-source discussion groups, and images containing identifiable account, host or organization details were excluded. Customer and group identities and environment-specific details were not published.

Questions, ideas, or a contribution to share? Join the community discussion or open an Issue / PR in the relevant repository. Let's keep building open, production-ready infrastructure for enterprise AI Agents πŸš€


Originally published in the iFLYTEK open-source community discussion: https://github.com/orgs/iflytek/discussions/14

Top comments (0)