Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/AmiraliNotFound/dummy-gemini-bot/llms.txt

Use this file to discover all available pages before exploring further.

At the core of Dummy Gemini Bot is its Gemini-powered conversational pipeline. Every message the bot receives — whether text, an image, or a voice note — is processed through a unified AI pipeline that maintains per-chat history, handles multimodal inputs, and gracefully falls back across multiple Gemini models when rate limits or failures occur.

Supported Input Types

The bot registers a MessageHandler for three Telegram message types:
TypeBehavior
TEXTSent directly to Gemini with conversation history as context
PHOTOImage (with optional caption) is included as inline data in the Gemini request
VOICETranscribed to text first, then forwarded to Gemini as a text message

Conversation History

Each chat’s message history is stored in an aiosqlite SQLite database. The bot retains up to 200 messages per chat. When building the Gemini request, the bot includes the most recent CONTEXT_LIMIT messages (default: 12) so the model always has relevant context without exceeding token limits. Messages beyond the 200-message cap are pruned automatically.
All message history is AES-256 encrypted at rest using Fernet encryption before being stored in SQLite. Raw message content is never written to disk unencrypted.

Multimodal Processing

When a user sends a photo, the image bytes are included in the Gemini API request as inline_data, allowing the model to reason about image content alongside any accompanying caption. When a user sends a voice message, the audio is first transcribed (via Gemini’s audio understanding capabilities) and the resulting text is used as the user’s message turn. This means voice messages participate in the same conversation history and context window as text messages.

Model Failover

The primary model is controlled by the MODEL_ID environment variable (default: gemini-2.5-flash). If the primary model fails — due to a rate limit, quota exhaustion, or API error — the bot automatically steps through the ordered list defined in FALLBACK_MODELS, trying each in sequence until one succeeds. Every failover attempt is logged to api_requests_log for observability. If all fallback models are exhausted, the bot returns a graceful error message to the user rather than silently failing.

Random Roast

The bot has a configurable probability of inserting an unsolicited sarcastic comment on any incoming message, regardless of whether it would otherwise respond.
  • Config key: RANDOM_ROAST_CHANCE
  • Default: 0.02 (2% chance per message)
  • To disable: set to 0
When a roast triggers, the bot sends a one-off sarcastic remark without it counting as a regular conversational turn in history.

Group Behavior

The bot’s response policy differs between group chats and direct messages:
ContextWhen the bot responds
DMsEvery message, unconditionally
GroupsOnly when directly mentioned (@bot), replied to, or when a random roast triggers
This prevents the bot from flooding group chats with responses to every message while still remaining accessible when needed.

Build docs developers (and LLMs) love