AstrBot Review 2026: One AI Bot for QQ, Telegram, and Discord

What AstrBot is and who it's for

AstrBot is an AI agent assistant and development framework that connects chat platforms to language models. The repository at github.com/AstrBotDevs/AstrBot describes it as a tool that integrates IM platforms like QQ, Telegram, and Discord, and the project site at astrbot.app frames it the same way. The pitch is narrow and clear: you run one process, point it at one or more chat networks, and it answers messages using whichever model provider you configure.

The category matters here. AstrBot is not a chatbot SaaS you sign up for. It is software you host. The docs describe a Python-based core with a web dashboard for configuration, plugin management, and provider setup. That puts it in the same family as Koishi and NoneBot, two established Chinese-origin bot frameworks, rather than in the same family as a hosted assistant product.

Who it fits: people who already run a bot on QQ, Telegram, or Discord and want language model replies without writing the whole pipeline themselves. Also people who want a plugin system to extend behavior, and people who want to swap model providers without rewriting their bot. The framework approach means the model call, the message routing, and the plugin hooks are already wired; you supply credentials and intent.

Who it does not fit: anyone who wants a managed service with an uptime guarantee. Anyone who needs a bot running inside a platform AstrBot does not cover. Anyone who wants zero operational surface. The docs are explicit that you are running the thing, which means you own the process, the storage, and the network path to whichever chat platform you connect.

The project's scale is worth stating plainly. The repository shows 40,404 stars. That is a large number for a self-hosted bot framework, and it tells you the Chinese-language bot community adopted it heavily. Star counts are not quality signals on their own, but they do correlate with plugin supply, documentation depth, and the odds that someone has already hit your problem.

Platform coverage and setup

The three headline platforms are QQ, Telegram, and Discord. The docs describe adapters for each, plus a plugin architecture that other adapters can plug into. QQ support is the reason the project grew the way it did; the Chinese IM ecosystem has specific protocol quirks, and a framework that handles them saves real work. Telegram and Discord are more conventional targets, and the docs treat them as first-class rather than afterthoughts.

Setup follows a predictable shape. You install the package, start the service, and open the web dashboard. From there you add a platform adapter, add a model provider, and configure which conversations the bot responds to. The dashboard is where most configuration lives, which is a deliberate choice: it lowers the barrier for people who do not want to hand-edit YAML for every change.

Deployment options matter for a self-hosted tool. The docs describe running it directly, running it in Docker, and running it on a server you control. Docker is the sane default for most people because it isolates the Python environment and makes upgrades a container swap. If you are running this on a VPS to keep a Telegram bot online, Docker plus a reverse proxy for the dashboard is the standard shape.

What the docs do not promise is a one-click cloud deploy. There is no managed hosting tier described. That is consistent with the pricing: the project lists a starting price of $0/mo, which reflects that the software itself is free and you bring your own infrastructure and model keys. The cost of running AstrBot is the cost of the machine plus whatever you spend on model calls.

Platform coverage has a practical ceiling. Each adapter depends on the platform's current API or protocol. QQ in particular has a history of protocol changes that break third-party clients, and the docs acknowledge that adapter maintenance is ongoing work. If you are building on QQ, budget for occasional breakage and check the repository's issue tracker before you commit to a production deployment. Telegram and Discord have more stable public APIs, so the maintenance burden there is lower.

One setup detail worth flagging: the dashboard is a web service, so if you expose it to the internet you need authentication and TLS. The docs cover this, but it is the kind of thing people skip on a quick test and regret later. Treat the dashboard as an admin panel, not a public page.

Plugin ecosystem and agent tools

The plugin system is where AstrBot differentiates itself from a plain chat bridge. The docs describe a plugin model where you can add commands, event handlers, and model-callable tools. That last part is the interesting one: the framework supports giving the model tools it can invoke, which turns the bot from a text responder into something that can take actions.

In practice, agent tools mean the model can call a function you registered, get a result, and continue the conversation with that result in context. The docs describe this pattern for things like lookups, calculations, and integrations with external services. The value is that you do not have to write the orchestration loop yourself; the framework handles the tool-call round trip and feeds results back to the model.

The plugin ecosystem itself is community-driven. The repository and docs point to a plugin marketplace or registry where third-party plugins live. Because the project has 40,404 stars, the supply of community plugins is meaningful, though quality varies. The honest read: some plugins are well-maintained, some are abandoned, and the docs do not vet them for you. Check the last-commit date on any plugin before you depend on it.

Writing your own plugin is the more reliable path if you have specific needs. The docs describe a Python plugin interface, which means anyone comfortable with Python can extend the bot without fighting a new language or a restrictive DSL. That is a real advantage over frameworks that require you to learn their own configuration language for anything non-trivial.

Agent tools also introduce a cost dimension people underestimate. Every tool call is another model round trip. A bot that answers a question in one call is cheap; a bot that plans, calls three tools, and synthesizes a final answer is several times more expensive per interaction. The docs describe the capability but do not hide the cost implication, and anyone running this at scale should watch token usage in the dashboard.

There is a security angle to tools that the docs address but that deserves emphasis. A model with tool access can invoke those tools. If a tool touches your filesystem, your database, or an external API with write permissions, a prompt-injected message could trigger it. The docs describe permission scoping, and you should use it. Give the model the narrowest tool set that does the job.

Model providers and costs

AstrBot is provider-agnostic. The docs describe support for multiple model backends, including OpenAI-compatible APIs, Anthropic, and local model servers. That flexibility is the main reason to pick a framework over a hosted assistant: you are not locked to one vendor's pricing or availability.

Because the software lists a starting price of $0/mo, the real cost is model usage. Current pricing for the high end of the market is steep. The live pricing snapshot shows openai/o1-pro at $150 per million input tokens and $600 per million output tokens, with a batch variant at $75 in and $300 out. Anthropic's claude-opus-4.7-fast sits at $30 in and $150 out. openai/gpt-5.5-pro is $30 in and $180 out, and its batch tier is $15 in and $90 out. Mid-tier options like openai/o3-pro run $20 in and $80 out, and openai/gpt-5-pro is $15 in and $120 out. Older models are cheaper: openai/gpt-4 and openai/gpt-4-0314 both list $30 in and $60 out, and openai/o1 is $15 in and $60 out.

For a chat bot, output tokens dominate the bill because the model generates replies. A busy Telegram group with a chatty bot can burn through output tokens quickly. The practical move is to route different intents to different models: a cheap model for casual replies, an expensive one for tasks that need reasoning. AstrBot's provider configuration supports multiple providers, so this routing is a configuration exercise rather than a code change.

Batch pricing is worth noting but rarely applies to interactive chat. Batch tiers like openai/o1-pro:batch at $75 in and $300 out, or openai/gpt-5.5-pro:batch at $15 in and $90 out, are for asynchronous workloads. A live bot answering messages in real time cannot use them. If you run scheduled summaries or offline analysis through the bot, batch pricing becomes relevant.

Local models change the math entirely. The docs describe connecting to self-hosted model servers, which means you can run a small model on your own hardware and pay nothing per token. The tradeoff is quality and the cost of the hardware. For a hobby bot in a small group, a local model plus a cheap hosted fallback is a reasonable setup. For anything user-facing at scale, hosted models are usually the better call.

One cost control the docs describe is per-conversation or per-user limits. Use them. An open bot in a public group with no rate limiting is an open invitation for someone to run up your bill. Set a cap before you go live, not after.

AstrBot vs Koishi and NoneBot

These three get compared constantly, and the comparison is fair because they occupy the same niche: self-hosted bot frameworks for chat platforms, with strong Chinese-community adoption.

Koishi is the most mature of the three in terms of plugin ecosystem breadth. Its plugin registry is large, its documentation is thorough, and it has a long track record. Koishi is JavaScript/TypeScript-based, which matters if your team lives in that ecosystem. It is also less opinionated about AI: you can build an AI bot on Koishi, but the AI layer is something you assemble from plugins rather than a core feature. If your bot is mostly non-AI functionality with some model calls sprinkled in, Koishi is a strong fit.

NoneBot is Python-based and has a deep plugin ecosystem of its own, with a strong following in the QQ community. It is a general-purpose bot framework first. Like Koishi, AI integration is possible but not the organizing principle. NoneBot's plugin model is powerful and its typing support is good, which appeals to developers who want structure. The learning curve is real, though; NoneBot expects you to understand its adapter and plugin concepts before you get much done.

AstrBot's differentiator is that AI is the core, not a plugin. The docs describe model providers, agent tools, and conversation management as first-class features. If your goal is an AI assistant in chat, AstrBot gets you there with less assembly than either Koishi or NoneBot. If your goal is a general-purpose bot that happens to use AI sometimes, the other two are more natural fits.

Language is the other axis. AstrBot and NoneBot are Python; Koishi is TypeScript. Pick the language your team can maintain. A framework you can debug beats a framework with more features you cannot.

On ecosystem size, Koishi and NoneBot have broader non-AI plugin libraries. AstrBot's plugin ecosystem is smaller but more focused on AI-adjacent functionality. The 40,404 stars on the AstrBot repository indicate it is not a niche project, but star count does not map directly to plugin count. Check the specific plugins you need before deciding.

Migration between these frameworks is not trivial. Plugin APIs differ, configuration formats differ, and the mental models differ. Pick based on what you are building, not on which one you might switch to later.

GitHub stars, repo health, release cadence

The repository at github.com/AstrBotDevs/AstrBot shows 40,404 stars. That is the headline number and it is genuinely large for this category. It signals that the project has crossed from hobby into something with real community gravity.

Stars alone are a weak health signal, so look at the other indicators. The repository shows active issue and pull request activity, which is the more meaningful measure. A project with 40,404 stars and a dead issue tracker is worse than a project with 4,000 stars and responsive maintainers. The AstrBot repository shows ongoing maintenance, which is what you want to see.

Release cadence is the third signal. The repository shows regular releases, which matters for a tool that depends on external platform APIs. QQ, Telegram, and Discord all change things, and a framework that does not ship updates will break. Regular releases suggest the maintainers are keeping up with platform changes.

Documentation is the fourth signal and the one that most affects your day-to-day. The docs at astrbot.app cover installation, configuration, plugins, and providers. They are not exhaustive, and some sections assume familiarity with bot frameworks generally, but they are enough to get running. The gap is in advanced plugin development, where you will lean on reading existing plugin source.

What the repository does not tell you is how the project handles breaking changes. Version pinning is your friend here. If you deploy AstrBot, pin to a known-good release and upgrade deliberately rather than tracking the latest commit. The docs describe upgrade paths, but a self-hosted tool always carries upgrade risk.

Community support runs through the project's channels, which the docs link to. For a project of this size, the community is the real support layer. Expect to search issues before you get an answer, and expect that some questions go unanswered. That is normal for open-source infrastructure, not a red flag specific to AstrBot.

Verdict: who should use AstrBot and who shouldn't

AstrBot is a solid choice if you want an AI assistant in QQ, Telegram, or Discord and you are willing to run the software yourself. The framework handles the model integration, the platform adapters, and the plugin hooks, which is a meaningful amount of work you do not have to do. The 40,404-star repository and active release cadence suggest the project will keep working as platforms change.

It is a poor choice if you want a managed service, if you need a platform it does not cover, or if you are not comfortable operating a Python service with a web dashboard. The $0/mo starting price reflects free software, not free operation; you still pay for hosting and model calls, and the high-end models in the current pricing snapshot are expensive enough that cost control is a real concern.

Against Koishi and NoneBot, the decision comes down to whether AI is the point. If it is, AstrBot's first-class model and agent support saves assembly. If it is not, the other two have broader general-purpose ecosystems. Beetlix is our own product, and where AstrBot is a self-hosted framework you operate, Beetlix is a different shape of tool; if you specifically want to run your own bot process, AstrBot is the more direct fit and the comparison is not really apples to apples.

My recommendation: try it on a small Telegram or Discord server first, with a cheap model and a rate limit, before you put it in front of a large group. The setup is not hard, but the cost and security surfaces are real, and a small pilot will surface both.

How this review was researched

This review draws on the vendor documentation at astrbot.app, the official pricing information for the project, the repository at github.com/AstrBotDevs/AstrBot, and the live model pricing data current at the time of writing. No hands-on testing was performed; the analysis is based on documented behavior, repository signals, and published pricing.