Home
Ashavid
Back to Portfolio
Built by AshaVidConsumer Utility / Open SourceBuilt 2025–2026

Gheychee

A media utility bot that turned into a study in operating at scale — rate limiting, localisation, and format negotiation across a genuinely global user base.

LightStandardPremium25 languages
One engine, three tiers — the shared core is what keeps the line from fragmenting.
  1. Application

    Where the rules run

    • Python 3.10+
    • Pyrogram
    • yt-dlp
    • gallery-dl
  2. Platform

    What it runs on

    • Docker

A compact view of the venture

Venture
Gheychee
Category
Consumer media utility
Stage
Shipped, open source
Core challenge
Operating a global utility under platform rate limits
Our role
Product design and engineering
Focus areas
Localisation, format negotiation, rate limiting

Why we started building this

Gheychee started as a small utility and became the venture in this portfolio that taught the most about operating at scale, because consumer utilities expose engineering problems that low-traffic products never surface.

The moment a bot serves users across two dozen languages and time zones, everything soft becomes hard: rate limits stop being theoretical, format edge cases stop being rare, and error handling stops being optional.

It also became the group’s reference implementation for a three-tier product line — a light version, a standard build, and a premium tier — sharing a core while serving different needs.

Utility products live or die on the unglamorous parts: rate limits, retries, and what happens when the format you asked for does not exist.

What we built

A Pyrogram-based Telegram bot wrapping yt-dlp and gallery-dl, with advanced format and codec selection, subtitle handling, proxy support, and per-user configuration, shipped as a containerised deployment.

  • 25-language localisation

    Full interface localisation across 25 languages, including right-to-left scripts — a first-class concern rather than a community patch.

  • Smart format selection

    Codec-aware selection across H.264, AV1, and VP9 with container preferences and an interactive quality menu with live filtering.

  • Subtitle handling

    Subtitle integration with language detection rather than blind attachment.

  • Flood-wait protection

    Rate limiting and flood-wait handling built around Telegram’s actual constraints, which is what keeps the bot alive under load.

  • Proxy support and direct links

    Global proxy control plus direct stream URLs for external players, for users on constrained networks.

  • Per-user settings and statistics

    User-specific configuration, a tagging system, and usage statistics held per account.

Why this needed to exist

  • Telegram enforces hard rate limits, and a naive implementation gets throttled into uselessness at modest scale.

  • Media format negotiation has a very long tail of edge cases across sources and codecs.

  • A 25-language interface is an architectural commitment, not a translation task.

  • Users on restricted networks need proxy paths and direct links, not a single happy path.

  • A three-tier product line risks three divergent codebases without a disciplined shared core.

How we framed the opportunity

Nearly every hard problem here was operational rather than conceptual, which is exactly what makes consumer utilities good engineering teachers.

Rate limiting is a core feature

Flood-wait handling had to be designed in, because at scale it determines whether the product works at all.

Localisation shapes the architecture

Twenty-five languages including RTL scripts means the string layer and layout assumptions are structural decisions.

Format selection needs to be interactive

Automatic selection fails often enough that an interactive menu with real-time filtering is the more honest interface.

Tiering works only with a shared core

Light, standard, and premium builds stay maintainable because the underlying engine is common to all three.

Where the existing options fell short

What comparable bots offered

  • Single-platform downloading with basic quality options.
  • English-only interfaces with community translations bolted on.
  • Simple implementations that work well until they hit real concurrency.

What was missing

  • Genuine multilingual support as a design constraint.
  • Codec-level format control with interactive selection.
  • Rate-limit handling robust enough for sustained load.
  • Proxy paths for users on restricted networks.

The decisions that shaped the product

Design for the platform’s real limits

Telegram’s rate limits are a fixed constraint, so flood-wait handling is part of the core loop rather than an error branch.

Localisation as architecture

Treating 25 languages as structural rather than additive is what keeps the interface coherent across scripts.

One engine, three tiers

Light, standard, and premium builds share a common core so the product line does not fragment.

How it came together

  1. Phase 1

    Core download engine

    Wrap yt-dlp and gallery-dl behind a single interface with codec-aware format selection.

  2. Phase 2

    Scale and resilience

    Add flood-wait protection, proxy support, per-user settings, and containerised deployment.

  3. Phase 3

    Localisation and product tiers

    Ship 25-language localisation and split the line into light, standard, and premium builds on the shared core.

Where the product stands today

  • A shipped open-source bot with 25-language localisation
  • Codec-aware format selection with an interactive quality menu
  • Flood-wait protection and rate limiting sized for sustained load
  • Proxy support and direct stream links for constrained networks
  • Per-user settings, tagging, and usage statistics
  • A three-tier product line sharing a single core engine

What building this taught us

  • Consumer utilities teach operational engineering faster than anything else.
  • Platform rate limits are product constraints, not error cases.
  • Localisation at this scale is architecture, not translation.
  • When automation fails often, expose the choice to the user.
  • A shared core is what makes a tiered product line survivable.

We build the products we would want to operate ourselves.

Gheychee is one of the ventures we design, build, and run in-house at AshaVid.