If you built yourself a personal assistant on top of Claude this year, June 15 is when that gravy train ends. The Agent SDK, claude -p , GitHub Actions, and third-party harnesses like OpenClaw all move off your normal subscription pool and onto a separate capped credit. Once you run through that monthly credit (at API rates no less) & without extra pay-as-you-go dollars, the bot just stops until next month’s refresh. While thinking about this, and researching it, I realized my setup dodged the whole problem by accident, because I never built a 3rd party (or custom) harness in the first place. I want to lay out what I did instead, because I think it quietly beats every homemade “Jarvis” out there IMHO, and I think it’s a use case for the community to explore and lean into. In my research trying to use Claude as a personal assistant while mobile, I found in the Claude Code docs a hidden feature: –channels released March 20, 2026, about 2+ months ago. It’s a research-preview function shipped by Anthropic, no doubt in response to the OpenClaw viral moment. If you search for it, it’s HIDDEN from –help , but it’s fully documented . All it does is bridge a messaging app into a running Claude Code session through a first-party Anthropic plugin . Telegram, Discord, iMessage all work. I prefer Telegram, so I went down that rabbit hole. So you install the official Telegram plugin into Claude Code, point it at a bot token from BotFather, allowlist your own chatID, and now texting your bot drops that message straight into a live Claude session on your own machine. Done. It’s similar in spirit to the Remote Control feature in the Claude app, except thru Telegram (which then offers me a lot of other capabilities). The session you’re connected to is running locally and you’re interacting with it directly, using an Anthropic-provided plugin. So, building on that, I built-up the CLAUDE.md to be the basic “soul.md” file you’d find in your openclaw/hermes variant and turned my Claude Code into the assistant. So there’s an important consideration here and it’s worth underscoring because I wasn’t sure about this myself until i spent 2 hours confirming my findings. This is a normal interactive Claude Code session. The exact same claude you launch in your terminal. NOT THE AGENT SDK. IT’S NOT claude -p headless. It is NOT a script hitting the model through an API either. The –channels flag requires a real PTY , a genuine terminal. Feed it -p or a piped stdin and it EOF-exits in about 1 second . It literally will NOT RUN HEADLESS IF YOU TRIED to put it in print mode. It’s a real Claude Code session living in a tmux session under systemd. TMUX is doing 1 job: holding a real interactive terminal open so the session keeps polling, that’s it. Systemd just keeps that tmux session alive and restarts it if it dies. To reiterate (because I think it’s important): This is Anthropic’s own feature. Anthropic’s own first-party plugin. A real interactive session in a real PTY. Every single turn is me, a human , texting a message in from my phone (using the --channels feature that THEY PROVIDED), and the session is reacting live to me, exactly as if I’d typed it at the keyboard, which in point of fact, I am … just a soft-keyboard on my phone. There’s no one at the terminal per se, but to be clear it is interactive, not programmatic. Those are different things and the difference is the point for the Terms of Service. I think this distinction is the whole ballgame for the billing question. The June 15 change hits automated workflows : CI, scheduled agents, GitHub Actions, scripts that call Claude programmatically . What stays on the normal subscription, per Anthropic’s own framing, is interactive Claude Code in your terminal or IDE. A tmux session running interactive claude --channels , driven by a human over Telegram through the first-party plugin, sits squarely on that side of the line. From all my searches, I haven’t seen Anthropic name --channels specifically in the billing notes, so this is my read, not a quoted ruling. If someone has a source that says otherwise I genuinely want to see it. But I think my logic holds: official feature, first-party plugin, real PTY, interactive session, my own Max subscription, every turn triggered by a person messaging in. That is not the automated-bot pattern the policy targets. Because it’s the real Claude Code and not my own duct tape, the Claude Code TMUX session inherits everything while it’s talking to me: Every skill I have, the ability to dispatch sub-agents, full-on bash access to the box, all my MCP connectors to Gmail and Google Calendar and Google Drive and my private Obsidian Notes MCP I developed as well which uses embeddings for semantic searches. It reads and writes to my entire homelab from behind the firewall. I had to build none of that. I just launched Claude Code with its own --channels feature, period. The personality and the bio live in a local CLAUDE.md in the working directory. That’s the “soul.md” variant. Then from there I can enact behaviors I want like when I drop a YouTube link without context, it knows to pull the transcript and give me a summary. if I drop a Reddit thread URL, it pulls the post plus the comment sentiment. I can send it a voice note with the Teleggram-record-voice feature and it runs the audio through my local Whisper docker container, converts it to text, then acts on that text as though I had typed it. None of these behaviors is Sonnet in the TMUX session winging it. It’s CLAUDE.md instructions (1 liners) that tell it to launch small Python scripts that sit in a local ./bin/ folder that Sonnet calls when the conditions are met. The model just does a determination of intent and pulls on the right tool (script) to do the deterministic work. Scheduled stuff runs outside the session entirely , and this matters for the billing point too. A systemd timer fires a standalone Python script twice a day that builds a news digest for me, publishes it as a dark-mode web page on here.now with a 24-hour expiry, and texts me the link. No Claude turn involved in that. The session itself stays purely reactive, only ever responding to a message I sent. So nothing in my setup calls Claude programmatically. No scheduled agent, no cron job hitting the model, no -p anywhere. If I tell it to “remind me to do XYZ at 2pm tomorrow”, and it doesn’t try to “remember” anything itself; it understands from the CLAUDE.md to schedule a one-off AT job on the Linux box that fires at that time and texts the reminder back to me through the same Telegram bot, using a small send script that runs separately from the live session (not through the --channels connection at all). AT commands survive reboots and work even though Claude is purely reactive and can’t wake itself up to do anything. So long as it can set the AT command or I tell it to set the systemd timer and/or crontab for me, I don’t need it to “wake up” at all, ever. My next phase I’ll begin this week is memory. CLAUDE.md has some of the basics I wanted it to know, but I’ll add a small local markdown file, imported at startup, holding the standing facts about me, with a fuller mirror in my notes vault for overflow (because it has access to my homegrown MCP that embeds my Obsidian vault for semantic search). Sonnet will decide what’s worth keeping. It’ll act a bit like it’s existing memory feature I think. I’ll work on this and maybe report back if there’s interet. A warning though, since this --channels thing is a hidden research preview , there’s actually occasional issues. Once in a while the channel poller (the plugin) just wedges. The claude process stays alive, systemd still reports the service up, but it quietly stops polling Telegram and goes deaf . No crash, no error in the log, it simply stops answering me. So I put a watchdog on it. It’s a small timer that checks every 5 minutes whether the bot is actually polling , not merely whether the process exists. Telegram hands you a clean tell for this: a healthy poller gets a 409 Conflict back from getUpdates because it already owns the connection, while a wedged one returns empty . When the watchdog sees alive process but no poll , it knows to do 1 graceful restart and confirms the bot is talking again. Last time this fired, it caught the hang and fixed it in about six seconds, before I’d even noticed anything was off. So it’s a little supervision around the part that isn’t stable yet, and every once in a while I’ll get a message, “♻️ claude just recovered (restart)”. A related trick fell out of this. Restarting the session also clears the context window and starts it fresh. And since I can’t pass native slash commands like /clear over the channel (the same limitation you hit with the Android app’s connection to <code> … try it and it just fails), I wired up my own version. When I type /clear in chat, a one-liner in my CLAUDE.md tells the session to run a small graceful restart script, which bounces the Claude Code session in TMUX and effectively clears my context window. That script is separate from the watchdog, but it leans on the same idea: a clean restart fixes a lot. With the harness route about to get metered, I don’t see why anyone hand-roll a bot anymore, but that’s just me. The best assistant framework available is the one Anthropic already ships and updates for you. I just had to stop reinventing it badly… TL;DR: Use –channels (research-preview, first-party Telegram plugin from Anthropic) to bridge Telegram into a real interactive Claude Code session running in a tmux PTY. It is the same claude you run in your terminal, not claude -p , not the Agent SDK, not a third-party harness , so it stays on your normal subscription instead of the new June 15 Agent SDK credit pool. Every turn is a human texting in, so it’s interactive, not programmatic. You inherit all skills, sub-agents, bash, and MCP connectors for free. Personality lives in a local CLAUDE.md, deterministic work in Python scripts the model calls, scheduled jobs run as standalone scripts outside the session so nothing hits Claude programmatically. Stop building your own Jarvis. Also for those interested here’s the outline of the rough setup, 50,000-foot view (I could offer more detail if anyone’s interested …): It wasn’t that hard to set up actually … Install Bun . The channel plugins are Bun scripts. Make a Telegram bot through BotFather and copy the token. In Claude Code, run /plugin install telegram@claude-plugins-official , then /reload-plugins . Save the token with /telegram:configure <token> . Launch it interactively, inside tmux, not with -p : claude --channels plugin:telegram@claude-plugins-official --model sonnet 5a. I chose Sonnet just to keep my usage/budget normal. I think Opus is overkill for basic personal assistant type stuff. Text your bot, then pair it with the code and lock it down: /telegram:access pair <code> followed by /telegram:access policy allowlist . Wrap that tmux session in a systemd user service so it survives reboots and restarts on crash. Drop a CLAUDE.md in the working directory of the tmux session for personality and standing instructions. That’s the gist of the whole thiing. The watchdog to reset after the wedges, the helper scripts like summarizing youtube transcripts, the memory file, and the web publishing are all stuff I bolted on top afterward with 1-liner instructions in the CLAUDE.md file. If there’s interest I’ll do a follow-up with the actual systemd unit files, the watchdog script, and how I structure the CLAUDE.md. I didn’t want to bury this post in config. Thanks for reading if you got to the bottom of this. submitted by /u/emptyharddrive
Originally posted by u/emptyharddrive on r/ClaudeCode