Bank Tech Lead Grows OpenCode Telegram Bot to 1,298 GitHub Stars With AI Agents

Ruslan, a tech lead at a large bank with 15 years of experience, turned a side experiment into his most visible open-source project over a few months. opencode-telegram-bot is a Telegram client for OpenCode, a popular CLI coding agent. As of the publication of his write-up on Habr, the repository has 1298 GitHub stars and 48 contributors. Agents wrote almost all of the code, and the author says he barely looked at it himself.

From idea to npx package in a few weeks

The idea came during the 2026 New Year holidays. Ruslan had installed Claude Code and wanted to control it from his phone. Gemini advised him to parse the TUI output, so he shelved the idea. OpenCode solved the problem: it can run as a server and be driven through an API, which made the Telegram client a job of a couple of days. He chose the language together with the AI: instead of his usual Kotlin, they went with TypeScript because of its convenient API.

The bot runs locally, and access is limited to a single user whose id is set in the configuration. Everything the agent does shows up in the chat: file edits, console commands, subagent activity. Diffs can be opened on the phone as a text file, and the bot supports speech recognition and voice output. The model, agent, effort and context are exposed through a reply keyboard. The bot works in a single thread, like a terminal, and the /detach command disconnects the current session and sends a notification when it finishes.

Preparing for release took about three weeks and followed a plan drawn up together with an agent. They set up .gitignore, a license, CONTRIBUTING.md and CI/CD with a linter, build and tests. The agent removed debugging code, translated the documentation into English and cleaned out Russian comments. Those had appeared because the author talked to the agents in Russian and never set a rule against it. Localization was done early, and it now covers 688 strings in 12 languages. Publishing to npm took about an hour to set up, so installation comes down to a single npx command. Version 0.1.0 went out as a single commit in a fresh repository, so the messy history stayed hidden.

What brought stars and what did not

At first, friends starred the project: it had 8 at launch. After that came 2–3 a week. The agent suggested Reddit and Hacker News. The post in r/opencodeCLI, written by the agent and revised after the author's comments, scored +65 and drew 31 thousand views. It brought 30 stars on the first day and more than 100 after a week, and the project overtook two competitors that had about 20 stars each. The other Reddit posts got 10–15 thousand views each but produced no noticeable growth. On Hacker News, nobody responded.

Steady traffic came from search. After 5–6 weeks, the repository took the top Google results for queries like "OpenCode Telegram Bot". Now about 100 people visit the page per day, which translates to 3–5 stars a day. The author's conclusion: he should have made the repository public right away, so it would already be indexed by the time promotion began.

How the agent pipeline works

At the start, Ruslan worked in Claude Code on Sonnet 4.5. He did not use Opus 4.5 because it quickly ate through the limits of his $20 subscription. He was unhappy with Sonnet's quality: features rarely worked on the first try, and the model often skipped the tests that the instructions called for. He connected his ChatGPT subscription through OpenCode and moved to GPT-5.3-Codex, then to GPT-5.4. By his estimate, the number of debugging iterations dropped noticeably, and he built most of the spring features on GPT-5.4.

Next, the author put together his own workflow from three OpenCode modes: Ask for code review and questions, Spec for planning, with the plan written to a separate file, and Code for implementation. In the summer he added Playwright MCP, and the agent began testing the bot on its own through the web version of Telegram. Now a reviewer subagent checks the plan, another subagent reviews the code, and a tester subagent runs the scenarios. Ruslan says this approach is why he dared to take on refactorings he had been putting off. Some tasks now go even further: after grooming and a specification, a manager agent launches developer agents in separate sessions and reports to the author in Telegram.

Contributors showed up after 4 days: the first pull request added proxy support. The author admits he suspected malicious code and had an agent check the changes. He always reviews submitted code with agents and runs the feature manually. He accepts small fixes after 1–2 rounds of edits and often rejects larger additions. He also specifically declines to support Telegram topics: the architecture is built around a single thread, and rewriting it has to be done carefully and with tests. Releases come out about once a week, sometimes with hotfixes, and some consisted entirely of community pull requests.

The recipe is simple, but it has limits. This is the experience of one project in a niche where interest was at its peak, and the results depend on the platforms and on how search engines index the page. The conclusions about model quality rest only on the author's subjective observations, with no benchmarks. The practical takeaway for developers: if you want an open-source project alongside your main job, the fastest route is to publish a basic version, make it installable with one command, keep the repository public and release updates regularly.