Discord Bot for Summarizing Voice Meetings

[mohi-devhub]

Description
RUXAILAB holds regular Discord voice meetings for coordination and future planning. Contributors who are unable to attend often miss important discussions, context, and decisions made during these calls. This issue proposes building a custom Discord bot that automatically captures and summarizes voice meetings for internal reference.

Proposed Approach

• Bot joins a Discord voice channel on command
• Records the meeting audio
• Converts audio to text using speech-to-text
• Generates an AI-based summary highlighting key points and decisions
• Posts the summary to a designated Discord text channel

Scope

• Internal tooling only
• Maintained in a separate repository, decoupled from the main website

[KarinePistili]

Hi! As we talked about starting this issue out, let's move it to the new repository and we will be updating it with more information and use it as a follow up 👍

[KarinePistili]

@mohi-devhub I think the first step would be to plan how the technical aspect could be done.

For us it is important that the AI model that will be used is lighweighted and easy to deploy on cloud services (like Google Cloud Run for example), with the minimum cost possible (the best would be zero).

Regarding the usage of the bot, feel free to propose what you believe suits best and we can talk about it and progress the project step by step.

[mohi-devhub]

Thanks for the context! That makes sense 👍

As a first step, I can draft a technical plan that focuses on a lightweight, low-cost setup. At a high level, I’m thinking along these lines...

• Discord bot layer: A simple bot (likely using discord.py or similar) that can be triggered via command to join/leave a voice channel and manage recording.
• Audio handling: Record and chunk audio locally during the session to avoid heavy memory usage.
• Speech-to-text: Use a lightweight, open-source STT model (e.g., Whisper small/base or faster-whisper) that can run efficiently on CPU and be containerized for Cloud Run.
• Summarization: Start with an efficient, open-source summarization model or rule-based + prompt-based approach, keeping inference costs minimal and optional.
• Deployment: Package everything in a single container so it can run on services like Google Cloud Run, with an emphasis on staying within free tiers as much as possible.
• Output: Post the generated summary to a designated Discord text channel after the meeting ends.

For usage, I’d propose keeping it simple initially (e.g., /start-meeting and /end-meeting commands), and we can iterate once the core flow is validated.

I’ll put together a more concrete technical breakdown and trade-offs , so we can review and refine it step by step.

[Abhigyan-GG]

Building on Mohi’s proposal and keeping the near-$0 cost constraint front and center, I think we can refine the direction slightly by clarifying the MVP while noting a few optional enhancements that don’t add much complexity.

Key technical choices + trade-offs

Audio handling

• Choice: Record audio in fixed-size chunks (e.g. 1–5 min WAV files)
• Why: Avoids high memory usage and simplifies failure recovery
• Trade-off: Slight post-processing step to concatenate audio

Speech-to-text

• Choice: faster-whisper (small/base), CPU-only
• Why: Fully open-source, good accuracy, works on Cloud Run free tier
• Trade-off: Slower than GPU / paid APIs, but acceptable for post-meeting flow

Processing model

• Choice: Post-meeting batch processing only
• Why: Predictable CPU usage, simpler infra, stays within free limits
• Trade-off: No real-time transcript

Summarization

• Choice: Single lightweight summarization pass (prompt-based or rule-assisted)
• Why: Minimal compute, easy to iterate on output format
• Trade-off: Less nuanced summaries compared to larger models

Deployment

• Choice: Single container, stateless, scale-to-zero
• Why: Lowest operational complexity and cost
• Trade-off: Cold starts add a small delay after meetings

Explicit non-goals for v1

• Real-time transcription
• Speaker diarization
• External paid APIs
• Persistent audio storage (delete after summary generation)

If this breakdown looks reasonable, we can refine each part step by step or split them into small implementation tasks.

[rakshityadav1868]

@mohi-devhub One thing that can be included is instead of a plain paragraph summary, it can have a section such as (Key topics discussed, Decisions taken, follow-up, etc.).This could help contributors easily understand and catch up.

[mohi-devhub]

Thanks both ...great inputs.

@rakshityadav1868 agreed, a structured summary (key topics, decisions, action items) would be much more useful and fits well within a lightweight MVP.

@Abhigyan-GG thanks for the clear breakdown and constraints — the post-meeting, scale-to-zero, near-$0 approach makes a lot of sense. I’ll fold these points into the initial technical plan so we can iterate from there.

[rakshityadav1868]

No problem @mohi-devhub — I’ll be happy to support on this issue. Feel free to ping me anytime if you need any help.

[Abhigyan-GG]

Thanks! @mohi-devhub Always happy to help out 🙂
Feel free to ping me anytime if there’s something I can help with or pick up as this moves forward.

[Nirvanjha2004]

Hi @KarinePistili @mohi-devhub @rakshityadav1868 @Abhigyan-GG
Nice start, but having built a voice bot before, I think the Cloud Run part is gonna cause issues.
Cloud Run is stateless, so it doesn't play nice with Discord's persistent voice connections—the bot will likely disconnect constantly.
we can simply use a Google e2-micro VM. It's also free, and it keeps the WebSocket connection alive.
we should not run STT locally. It'll lag on a micro instance. Just use the Groq API (free tier)—it's way faster.
Use SSRC for speaker detection. We can map user IDs to audio packets directly from the stream to know who is speaking, rather than guessing with AI later.
I can help set up the initial structure for this if you want.
Also ,
The Groq API is free, but it has a hard 25MB file size limit ( Now only i checked ). To make this work for 1-hour meetings, we will record in 10-minute chunks and compress them to MP3 locally on the VM using ffmpeg before sending. This keeps us well under the limit and ensures the bot costs $0 to run.

[rakshityadav1868]

Nice catch @Nirvanjha2004, @mohi-devhub I also think we can use Groq AI instead of running STT locally, as running it locally will cause high lag, timeouts, etc. and also instead of Cloud Run, we can use E2 Micro VM as it is more reliable and smoother than Cloud Run.

[rakshityadav1868]

@Nirvanjha2004 There is one possible issue with recording the meeting in 10-minute chunks. If a network error happens while sending a chunk to Groq (for example, file 2), the transcript for that chunk may not be created, and that part of the meeting will be missing from the final summary. To avoid this, we can create a small status file for each chunk.
The bot should stop only when the status of all chunks is TRANSCRIBED.
If any chunk is not transcribed, the bot will automatically retry that file until it is successfully processed.

[Nirvanjha2004]

@Nirvanjha2004 There is one possible issue with recording the meeting in 10-minute chunks. If a network error happens while sending a chunk to Groq (for example, file 2), the transcript for that chunk may not be created, and that part of the meeting will be missing from the final summary. To avoid this, we can create a small status file for each chunk. The bot should stop only when the status of all chunks is TRANSCRIBED. If any chunk is not transcribed, the bot will automatically retry that file until it is successfully processed.

yeah, agree with you, these can be added as enhanchement as well once the core workflow is done!

[Abhigyan-GG]

@Nirvanjha2004 @rakshityadav1868 In terms of improving reliability around partial failures, especially during recording and transcription.

A few lightweight guardrails that could reduce failure risk without adding much complexity:

• Chunk-level state tracking: Maintain a small state file or in-memory map per chunk (RECORDED → SENT → TRANSCRIBED).
  The meeting should only be marked complete once all chunks reach TRANSCRIBED.

• Idempotent retries: If a chunk fails to upload or transcribe due to a transient network/API error, retry that chunk only, rather than restarting the whole flow.

• Local persistence before send: Always write audio chunks fully to disk before sending them for transcription to avoid data loss on disconnects.

• Graceful degradation: If a chunk repeatedly fails after retries, flag it clearly in the final summary (e.g. “~10 minutes of audio could not be processed”) instead of silently dropping it.

These should help keep summaries consistent and trustworthy even when network hiccups or API issues occur.