AiToEarn joins creation, publishing, engagement, and paid tasks
AiToEarn covers more of the creator workflow than a normal social scheduler. It can generate text, images, and video through model providers, hold drafts, schedule posts, distribute them to social accounts, and automate some engagement through a browser extension. Its monetization area lets creators complete promotional tasks under sale, engagement, or view-based settlement models. The supported channel list spans Douyin, Rednote, Kuaishou, Bilibili, WeChat, TikTok, YouTube, Facebook, Instagram, Threads, X, Pinterest, and LinkedIn.
That breadth is the reason to look at it and the reason to be cautious. Every network has different OAuth flows, media limits, review rules, rate limits, and failure responses. A calendar that shows one scheduled item can still trigger several unrelated remote operations. Teams need a per-channel record of authorization, upload, publish identifier, final URL, and retry state rather than assuming one local task means one public post.
English documentation exists beside a Chinese-first project
The default README and v2.5.0 release notes are written in Chinese. A full English README mirrors the product, setup, MCP, Docker, and source-development sections, and a Japanese version is linked as well. International developers can evaluate the main workflow without machine-translating the setup guide. Issue discussion and some linked deployment material still mix languages, so operating the whole project may require translation.
Release v2.5.0 arrived on June 24, 2026. It moved relay configuration into the interface, separated Server Relay from AI Relay, updated open-source front and back ends, expanded draft generation controls, and revised Docker documentation. GitHub recorded a push on August 15, 2026, with 25,300 stars and 17 combined open issues and pull requests. The small open count is combined, not a count of confirmed defects.
What happened when we ran it
Our sandbox cloned commit d3aa8be into a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. The repository contained 3,395 files, about 332,747 lines of source, and occupied 127.4 MB. The detected pnpm project was project/aitoearn-backend/, where installation succeeded in 58 seconds with 1,487 packages and 986 MB on disk.
No build script or target was available in the measured project, so the harness skipped building. It also found no test script or target and skipped tests. The checkout had 6 CI workflow files, a Dockerfile, workspace configuration, and no tests directory. Those signals show automation and packaging around the repository, but our run produced no compiled artifact or passing test count to support a stronger claim.
We did not start MongoDB or Redis, launch the web interface, connect a relay, authorize a social account, generate media, or publish content. The 58-second result covers dependency installation only. Before adoption, a team should run a disposable channel from authorization through draft, approval, publish, failure recovery, and deletion while recording every outside identifier.
Docker starts the stack, while Relay supplies outside authority
The README presents docker compose up -d as a 3-command deployment that opens on port 8080. That can avoid manual database installation. It does not remove the need for credentials. Server Relay uses the hosted platform's social authorization, while AI Relay uses models made available by the platform. Both require an AiToEarn API key matched to either the China or international environment. A mismatch returns 401.
Teams can instead configure model API keys and apply for their own social-platform developer credentials. That route gives more control but increases setup and maintenance. Source mode starts separate AI and server applications, a frontend, MongoDB, and Redis. Storage, OAuth callback URLs, secrets, backups, and service restarts remain production responsibilities even when Compose creates the containers.
MCP turns a posting bug into an agent safety issue
AiToEarn exposes an HTTP MCP endpoint and an SSE endpoint for Claude Desktop, Cursor, and other compatible clients. An API key authorizes the connection. MCP can be useful for drafting or checking account state, but publishing and media tools have effects outside the workstation. Each mutating tool should require a clear human checkpoint and return a durable result that the agent can reconcile after a timeout.
Open issue 579 reports that the generateSubtitle tool passed a caller-supplied mediaUrl to FFmpeg without restricting its protocol. The report describes local-file reads, internal network requests, and FFmpeg argument handling as possible effects for an authenticated caller or prompt-injected agent. It proposes HTTP and HTTPS validation plus a protocol allow list. This is a public report, not something our sandbox reproduced, and it should be checked against the exact deployed commit.
Publishing retries need idempotency before scale
Issue 586 reports TikTok Direct Post creating duplicates when TikTok accepts initialization but AiToEarn fails before saving the returned publish identifier. A retry can then initialize another post for the same local task. The suggested approach is to persist the remote checkpoint before upload and reconcile ambiguous outcomes instead of blindly initializing again. That is the right reliability test for every supported network, not only TikTok.
Automated likes, follows, bookmarks, replies, and bulk publishing also need account-level policy review. AiToEarn can centralize the mechanics, but it cannot make every action acceptable to each network or brand. Start with one low-risk channel, require approval, cap retries, and audit the exact remote outcome. The project is ambitious and unusually broad; its unverified build path and open external-effect reports make controlled adoption essential.