Scaling

Sharding

Mellow uses disgo's shard manager with auto-scaling enabled. It asks Discord for the recommended shard count and adjusts as the bot grows. There is no shard configuration to set.

• Each shard's connect, reconnect, resume, and "guilds loaded" events are logged, and sent to LOG_CHANNEL_ID if configured.
• /tools status (owner-only) reports the current shard count. GET /v1/status on the HTTP API returns per-shard state, latency, guild count, resume count, and last-ready time - this is what the website's status page reads.
• Because all shards run in one process, a single instance scales to the point where one host's CPU, memory, or network is the limit. Multi-process sharding is not currently supported.

Resource use

• CPU - light. Most work is I/O: gateway events, database queries, and Anthropic calls.
• Memory - the guild/channel/role cache is limited to what commands need (FlagGuilds | FlagChannels | FlagRoles); message cache is off. Expect tens of MB plus a small amount per guild.
• Database - the main growth driver is ConversationHistory (when context logging is on) and MoodCheckIn. Both are indexed by user. Periodically prune old conversation rows if you do not need long history.
• Anthropic - the cost and rate driver. The default claude-haiku-4-5 with a ~300-400 token cap keeps per-message cost low. Fixed fallbacks are used whenever the AI is unavailable, so an outage degrades gracefully rather than failing.

Database connection pool

Mellow uses a pgxpool. For a busy instance, size the pool to your PostgreSQL max_connections budget and run PgBouncer in transaction mode if you are near the limit.