MuseBot: One Go Binary in Front of Eight Chat Platforms and Five LLM Providers

The problem MuseBot solves is platform sprawl, not LLM access

Connecting one model to one chat app is a weekend task. Connecting the same assistant to Telegram, Discord, Slack, Lark, DingDing, Work WeChat, QQ and WeChat is not, because each platform has its own SDK, its own message shape, its own way of handling images and audio, and its own callback or long-connection model. The repository lists these platforms as separate documentation files, which tells you the integration work is genuinely per-platform rather than a thin adapter over a common interface. MuseBot's pitch is that you write the bot logic once and the platform layer is somebody else's problem. The README frames it as connecting a communication app to AI in about a minute, which is marketing shorthand; the honest version is that the first platform is quick and each additional platform costs you another set of credentials and another doc to read. The intended user is a developer or small team that already has bots scattered across several of these platforms and wants them to share one LLM configuration, one admin surface and one metrics endpoint instead of five half-maintained scripts.

What runs where: a Go service with per-platform adapters and HTTP callbacks

MuseBot is written in Go and the repository is organized around per-platform documentation under static/doc/, with separate files for discord.md, slack.md, lark.md, dingding.md, com_wechat.md, qq.md, wechat.md and web_api.md. That layout is the clearest signal about architecture: the platform layer is not uniform. Telegram is described as go-telegram-bot-api based and handles commands, inline buttons and ForceReply. Slack is described as supporting Socket Mode, Events API and Block Kit interactions. Lark uses the larksuite SDK over a long connection and handles image and audio download plus message update. DingDing is long connection only. Work WeChat, QQ and WeChat are described as HTTP callback driven, which means those three need a publicly reachable endpoint rather than an outbound socket. On the model side the README lists OpenAI, DeepSeek, Gemini, OpenRouter and orcarouter, with a feature table showing Gemini supporting text, image generation, video generation, photo recognition and TTS, while ChatGPT's row is truncated in the supplied material. Beyond plain chat, the feature list names streaming output, image input, voice input, function calling that transforms MCP protocol into function calls, RAG for context filling, an admin platform, a service registration module, metrics, and cron-triggered LLM calls. Each of those has its own doc file, so the config surface is broad by design.

Getting it running: Docker, config keys and the docs you actually need

The README advertises a Docker deployment badge pointing at Docker Hub searches for musebot, and describes running locally or deploying to a cloud server, so container deployment is the expected path. The README does not give the full docker run invocation or a complete environment variable list in the material provided here, and the per-platform credentials differ enough that you should read the individual doc file for your platform rather than guessing. The documentation set that matters is enumerated in the feature list: static/doc/imageconf.md for image input, static/doc/audioconf.md for voice, static/doc/functioncall.md for the MCP to function call translation, static/doc/rag.md for retrieval context, static/doc/admin.md for the admin platform, static/doc/register.md for service registration, static/doc/metrics.md for monitoring and static/doc/cron.md for scheduled LLM invocation. Platform docs live at static/doc/discord.md, static/doc/slack.md, static/doc/lark.md, static/doc/dingding.md, static/doc/com_wechat.md, static/doc/qq.md and static/doc/wechat.md, plus static/doc/web_api.md if you want to talk to the LLM over HTTP instead of through a chat app. The README also links usage videos for the easiest path, DeepSeek, Gemini and ChatGPT, which is unusual for a Go project and suggests the author expects non-Go users to deploy this. One practical note: the QQ, WeChat and Work WeChat integrations are HTTP callback based, so those deployments need a public URL and whatever signature verification the platform requires, which the README does not spell out.

The limitation is documentation depth, not feature count

The feature list is long and the README is short. That mismatch is the main risk. The README tells you RAG is supported and points at static/doc/rag.md; it does not tell you which vector store, how documents are ingested, or what happens when retrieval returns nothing. It says function calling transforms MCP protocol into function calls without describing the mapping or the failure behaviour when a tool call is malformed. The model support table shows Gemini with full multimodal coverage and leaves ChatGPT's row truncated in the supplied material, so you cannot tell from the README alone whether image generation works on every listed provider or only some. There is also a real operational asymmetry: platforms using long connections (Telegram, Slack socket mode, Lark, DingDing) behave differently behind a firewall than the three HTTP callback platforms, which need inbound reachability. If your deployment target cannot expose a public endpoint, the WeChat, QQ and Work WeChat integrations are effectively unavailable regardless of what the feature table says. Finally, the release cadence visible in the material shows v1.0.40 in January 2026, v1.0.41 later that month and v1.0.42 in March 2026, with the last push in September 2026. That is frequent enough that pinning a version matters more than usual, because config keys and platform behaviour can shift between minor releases.

Where MuseBot is the wrong tool

If you only need a bot on one platform, MuseBot is more surface area than you need. A Telegram-only bot is a few hundred lines against go-telegram-bot-api; here you would still carry the config and code paths for eight other platforms, plus the admin platform, registration module, metrics and cron subsystems, whether or not you enable them. The same applies if your requirement is a single provider with a single modality: a thin wrapper around one API is easier to audit than a service that abstracts five providers behind a feature table with uneven coverage. MuseBot also assumes you are comfortable running a long-lived Go service and, for the callback-based platforms, exposing an HTTP endpoint. Teams that want a hosted bot with no infrastructure should look elsewhere, because the README's deployment story is self-hosted Docker or a cloud server you manage. And if your compliance posture requires you to know exactly which bytes leave your network, the multi-provider abstraction means you must verify per-provider egress rather than assuming one endpoint.

Alternatives and the actual difference in approach

The obvious comparison class is single-platform bot frameworks: a Telegram bot library in Go or Python, a Slack Bolt app, a Lark SDK integration. The difference is not quality, it is scope. Those libraries give you the platform primitives and nothing else; you write the LLM call, the streaming loop, the image handling and the persistence yourself, and in exchange you have no abstraction layer to debug when a message does not arrive. MuseBot inverts that: it owns the model layer and the cross-platform routing, and you configure rather than build. A second comparison is the web API path. MuseBot exposes static/doc/web_api.md for HTTP interaction with the LLM, which means you can treat it as a backend for a custom frontend instead of a chat bot. If your real need is an internal assistant with your own UI, that mode is arguably a better fit than wiring up eight chat platforms you will never use. The trade-off is the same either way: you get breadth and shared configuration, and you give up the ability to reason about a small, readable codebase.

Maintenance, upgrades and the MIT licence in practice

MuseBot ships under the MIT licence, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is permissive and imposes no copyleft obligation on your own code. It does not, however, cover the platform SDKs or the LLM providers you connect to, each of which has its own terms, rate limits and data handling rules; the MIT grant on MuseBot says nothing about those. On maintenance, the visible release history shows roughly monthly tagged releases through early 2026 and a repository that was still being pushed to in September 2026, so the project is active. The cost of that activity is upgrade churn. Because configuration is spread across platform-specific docs and feature-specific docs, a version bump can change keys in any of them. The practical approach is to pin the image tag rather than tracking latest, read the release notes for the version you are moving to, and check the relevant static/doc/ file after upgrading rather than assuming your existing config still parses. For the callback-based platforms, an upgrade can also change the expected callback path or payload handling, which is the kind of change that fails silently in production if you are not watching logs.

Editorial conclusion

MuseBot fits teams that already run several chat platforms and want one Go service, one config surface and one LLM key set behind all of them, and it is a poor fit if you need only Telegram or only Slack, because a single-platform bot is far less to configure and operate. Before adopting, read static/doc/functioncall.md and static/doc/rag.md end to end, confirm the exact config keys your deployment needs by checking the repository rather than the README summary, and verify that the platform you care about is documented in its own file under static/doc/.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yincongcyincong/MuseBot on GitHub