DEV Community: Alexei Ledenev

CCGram - Control AI Coding Agents from Your Phone via Telegram and tmux

Alexei Ledenev — Mon, 16 Mar 2026 12:27:11 +0000

AI coding agents — Claude Code, Codex CLI, Gemini CLI — run in your terminal. When you step away from your desk, the session keeps working, but you lose visibility and control. Especially when the agent hits a permission prompt or needs your input.

CCGram fixes this. It bridges Telegram to tmux so you can monitor and control your agents from your phone.

The key insight: operate on tmux, not on SDKs

Your agent runs in a tmux window on your machine. CCGram reads its transcript output and forwards it to a Telegram Forum topic. You type in Telegram — keystrokes go to the agent's tmux pane. Walk away from your laptop, keep the conversation going. Come back, tmux attach, full scrollback. Nothing lost.

Other Telegram bots wrap agent SDKs to create isolated API sessions that can't be resumed in your terminal. CCGram is different — it's a thin control layer over tmux.

One topic, one window, one agent

Each Telegram Forum topic binds to one tmux window running one agent session. You can run Claude Code, Codex CLI, and Gemini CLI in parallel across different topics.

Creating a session: open a Telegram topic, send any message. A directory browser appears — pick your project directory, choose the agent (Claude, Codex, or Gemini), choose the mode (Standard or YOLO), and you're connected.

Or create a tmux window manually, start an agent — CCGram auto-detects the provider and creates a matching topic.

Interactive prompts as inline keyboards

When your agent asks for permission, approval, or input, CCGram renders the prompt as Telegram inline keyboard buttons. Tap to approve — no typing "yes" or copying options.

This works across providers:

Claude Code: AskUserQuestion, ExitPlanMode, permissions
Codex: edit approvals (reformatted with compact summary + diff preview), selection prompts
Gemini: action-required prompts from @inquirer/select

Claude Code: deepest integration

Claude Code gets 7 hook event types — SessionStart, Notification, Stop, SubagentStart, SubagentStop, TeammateIdle, TaskCompleted. These provide instant session tracking and notifications rather than polling.

Multi-pane support for agent teams: blocked panes in non-active panes are auto-surfaced as inline keyboard alerts. /panes command shows all panes with status and per-pane screenshot buttons.

Session management

Recovery: when a session dies, the bot offers Fresh (new session), Continue (last conversation), or Resume (pick from past sessions). Buttons adapt to provider capabilities.
Sessions dashboard (/sessions): overview of all active sessions with status and kill buttons.
Message history (/history): paginated browsing of past messages.
Terminal screenshots: capture the current pane as a PNG image — useful for visual context.
Auto-close: done topics close after 30 minutes, dead sessions after 10. Configurable or disabled.
Provider commands: /commands shows all slash commands available for that topic's agent. Menus auto-switch per provider context.

Operations

Multi-instance: run separate bots per Telegram group on the same machine, sharing a single bot token. Each instance has its own tmux session, config, and state.
tmux auto-detection: start ccgram inside an existing tmux session — it discovers all agent windows, no creation needed.
Emdash integration: auto-discovers emdash-managed tmux sessions with zero configuration.
Diagnostics: ccgram doctor validates setup, checks hooks, finds orphan processes. ccgram doctor --fix auto-fixes.
Persistent state: thread bindings, read offsets, window states survive restarts.
Run as service: systemd unit, launchd plist, or detached tmux.

Install

  uv tool install ccgram

Alternatives: pipx install ccgram, brew install alexei-led/tap/ccgram

Configure a Telegram bot token via BotFather, enable Topics, add to a group, set your user ID in ~/.ccgram/.env, run ccgram.

For Claude Code, install hooks for best experience: ccgram hook --install

Links

GitHub: https://github.com/alexei-led/ccgram
PyPI: https://pypi.org/project/ccgram
Documentation: https://github.com/alexei-led/ccgram/blob/main/docs/guides.md

MIT licensed, Python. If you run AI coding agents and want mobile access without losing your terminal workflow — give it a try. Contributions and feedback welcome.

Hope you find this useful.

Kubernetes 1.33: Resizing Pods Without the Drama (Finally!) 🎉

Alexei Ledenev — Fri, 16 May 2025 13:32:12 +0000

Ever found yourself in that classic Kubernetes predicament? You meticulously set up your pod resources, patted yourself on the back, deployed to production... and then reality hits. Your application is either gasping for resources like a marathon runner at mile 25, or it's hoarding CPU like it's preparing for the computing apocalypse.

What happens next? In the dark ages of pre-1.33 Kubernetes, you'd have to restart the poor pod! It was like performing open-heart surgery just to adjust someone's diet.

But rejoice, fellow Kubernetes wranglers! Version 1.33 has arrived bearing gifts, and the showstopper is in-place pod vertical scaling in beta and enabled by default! 🎁

What Is This Sorcery? 🧙‍♂️

In-place pod resizing allows you to change the CPU and memory allocations of running pods without restarting them. Let that sink in for a second.

No restarts. No connection drops. No disruption. Just smooth resource adjustment while your application keeps humming along.

It works by making the resources.requests and resources.limits in your pod spec mutable - they can be changed on the fly without triggering a pod recreation. This is made possible through the new resize subresource feature and kubelet's ability to dynamically reconfigure container cgroups.

Why Should You Care? 🤔

If you're thinking "neat trick, but why does it matter?", consider these scenarios:

Stateful Applications - Your database pod suddenly needs more memory during a heavy analytics query. Previously: restart required, connections dropped, cache flushed. Now: bump the memory, carry on!
Cost Optimization - Over-provisioning "just in case" becomes unnecessary. Start conservative, scale up only when needed, scale down when the traffic subsides.
Performance Tuning - Experiment with different resource allocations to find the sweet spot, without annoying your users or operation teams.
Spiky Workloads - That batch job that needs tons of resources for 5 minutes every hour? No more choosing between wasting resources or constant restarts.

Under the Hood: How It Works 🔧

When you resize a pod, here's what happens:

You update the pod's resource specification using the new resize subresource
Kubelet validates the request against node capacity
If approved, kubelet instructs the container runtime to adjust cgroups
Container runtime updates the limits without restarting
The pod status is updated to reflect the new allocations

The pod can report its resize status through conditions:

PodResizePending - Can't resize right now (reasons include Infeasible or Deferred)
PodResizeInProgress - Changes are being applied

Show Me the Code! 💻

Here's a simple example that demonstrates this feature in action:

# Create a resource-monitoring pod
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: resize-demo
spec:
  containers:
  - name: resource-watcher
    image: ubuntu:22.04
    command:
    - "/bin/bash"
    - "-c"
    - |
      apt-get update && apt-get install -y procps bc
      echo "=== Pod Started: $(date) ==="

      # Functions to read container resource limits
      get_cpu_limit() {
        if [ -f /sys/fs/cgroup/cpu.max ]; then
          # cgroup v2
          local cpu_data=$(cat /sys/fs/cgroup/cpu.max)
          local quota=$(echo $cpu_data | awk '{print $1}')
          local period=$(echo $cpu_data | awk '{print $2}')

          if [ "$quota" = "max" ]; then
            echo "unlimited"
          else
            echo "$(echo "scale=3; $quota / $period" | bc) cores"
          fi
        else
          # cgroup v1
          local quota=$(cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us)
          local period=$(cat /sys/fs/cgroup/cpu/cpu.cfs_period_us)

          if [ "$quota" = "-1" ]; then
            echo "unlimited"
          else
            echo "$(echo "scale=3; $quota / $period" | bc) cores"
          fi
        fi
      }

      get_memory_limit() {
        if [ -f /sys/fs/cgroup/memory.max ]; then
          # cgroup v2
          local mem=$(cat /sys/fs/cgroup/memory.max)
          if [ "$mem" = "max" ]; then
            echo "unlimited"
          else
            echo "$((mem / 1048576)) MiB"
          fi
        else
          # cgroup v1
          local mem=$(cat /sys/fs/cgroup/memory/memory.limit_in_bytes)
          echo "$((mem / 1048576)) MiB"
        fi
      }

      # Print resource info every 5 seconds
      while true; do
        echo "---------- Resource Check: $(date) ----------"
        echo "CPU limit: $(get_cpu_limit)"
        echo "Memory limit: $(get_memory_limit)"
        echo "Available memory: $(free -h | grep Mem | awk '{print $7}')"
        sleep 5
      done
    resizePolicy:
    - resourceName: cpu
      restartPolicy: NotRequired
    - resourceName: memory
      restartPolicy: NotRequired
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "128Mi"
        cpu: "100m"
EOF

After your pod is running, double the CPU:

kubectl patch pod resize-demo --subresource resize --patch \
  '{"spec":{"containers":[{"name":"resource-watcher", "resources":{"requests":{"cpu":"200m"}, "limits":{"cpu":"200m"}}}]}}'

Check the pod logs, and you'll see the CPU limit magically change from 0.100 cores to 0.200 cores without any restart!

Control the Resize Behavior with resizePolicy ⚙️

Sometimes you do want a restart when changing certain resources. For example, many applications can't dynamically adjust to memory changes without restarting. That's where resizePolicy comes in:

resizePolicy:
- resourceName: cpu
  restartPolicy: NotRequired     # Live CPU tweaks!
- resourceName: memory
  restartPolicy: RestartContainer  # Safer memory changes

With this configuration, CPU changes happen in-place, but memory changes trigger a container restart.

The Fine Print: Limitations 📜

While this feature is cooler than a penguin in sunglasses, it does have some limitations:

Windows Support: None yet, only Linux containers
Resource Types: Only CPU and memory can be resized in-place
QoS Class Immutability: You can't change a pod's QoS class through resizing
Memory Decrease: You can't decrease memory limits without a restart (unless using RestartContainer policy)
Special Pods: Pods with static CPU/memory management policies can't use this feature
Cluster Requirements: Requires Kubernetes 1.33+ with a compatible container runtime

What This Means for VPA 🤖

The Vertical Pod Autoscaler has long been the awkward cousin at the Kubernetes scaling family reunion. Its main limitation? It had to recreate pods to adjust resources.

While VPA doesn't yet support in-place resizing in Kubernetes 1.33, this feature lays the groundwork for future integration. Soon, we might see VPA attempting in-place resizes first, falling back to recreation only when necessary.

Until then, you can use VPA in "Off" mode to get recommendations, then apply them manually via in-place resizing.

Conclusion: A Smoother Vertical Scaling Future 🚀

In-place pod resizing in Kubernetes 1.33 is a game-changer for vertical scaling workflows. It removes one of the most significant barriers to efficient resource management - the disruption caused by pod recreation.

Whether you're fine-tuning performance, responding to traffic spikes, or optimizing cloud costs, the ability to adjust resources without service interruption opens up new possibilities for Kubernetes-based applications.

Give it a try in your non-production clusters, and prepare to say goodbye to the "restart to resize" era of Kubernetes!

For the full blog post including more details, examples, and the future of vertical scaling in Kubernetes, check out my article on Medium.

KubeIP v2: Assigning Static Public IPs to Kubernetes Nodes Across Cloud Providers

Alexei Ledenev — Thu, 23 May 2024 14:55:38 +0000

Kubernetes nodes can benefit from having dedicated static public IP addresses in certain scenarios. KubeIP, an open-source utility, fulfills this need by assigning static public IPs to Kubernetes nodes. The latest version, KubeIP v2, extends support from Google Cloud's GKE to Amazon's EKS, with a design ready to accommodate other cloud providers. It operates as a DaemonSet, offering improved reliability, configuration flexibility, and user-friendliness over the previous Kubernetes controller method. KubeIP v2 supports assigning both IPv4 and IPv6 addresses.

Use Cases

Gaming Applications

In gaming scenarios, a console may need to connect directly to a cloud VM to minimize network hops and latency. Assigning a dedicated public IP to the gaming server's node allows the console to connect directly, improving the gaming experience by reducing latency and packet loss.

Whitelisting Agent IPs

If you have multiple agents or services running on Kubernetes that require direct connections to an external server and that server needs to whitelist the agents' IP addresses, using KubeIP to assign stable public IPs to the nodes makes this easier to manage than allowing broader CIDR ranges. This is particularly useful when the external server has strict IP-based access controls.

Avoiding SNAT for Select Pods

By default, pods are assigned private IPs from the VPC CIDR range. When they communicate with external IPv4 addresses, the Amazon VPC CNI plugin translates the pod's IP to the primary private IP of the node's network interface using SNAT (source network address translation). Sometimes, you may want to avoid SNAT for certain pods so that external services see the actual pod IPs. Assigning public IPs to nodes with KubeIP and setting hostNetwork: true on the pod spec achieves this. The pod can communicate directly with external services using the node's public IP.

Direct Inbound Connections and Custom Networking Scenarios

Assigning public IPs to nodes with KubeIP enables a variety of networking scenarios. For instance, you can forward traffic directly to pods running on those nodes, which is useful when you need to expose services on the node to the internet without using a traditional load balancer. An example would be running a web server on a pod and forwarding traffic to it using the node's public IP.

In addition, KubeIP can be used to implement custom networking scenarios that require public IPs on nodes. For example, you could create a custom load balancer that forwards traffic to specific nodes based on the public IP. This flexibility makes KubeIP a powerful tool for testing or deploying custom networking solutions in Kubernetes.

IPv6 Support

KubeIP extends its functionality beyond IPv4 by supporting the assignment of static public IPv6 addresses to nodes. This feature is increasingly important as the internet continues transitioning towards IPv6 due to the exhaustion of IPv4 addresses. With KubeIP's IPv6 support, you can assign static public IPv6 addresses to your Kubernetes nodes, enabling them to communicate directly with external services over IPv6. This is particularly beneficial for applications that require IPv6 connectivity.

Conclusion

KubeIP v2 is a powerful tool for assigning static public IPs to Kubernetes nodes across cloud providers. It enables a wide range of use cases, from gaming applications to custom networking scenarios, and supports both IPv4 and IPv6 addresses. The extensible design and simplified DaemonSet model make it easy to deploy and manage in your environment.

Get Involved

As an open-source project, we welcome contributions! Submit pull requests, open issues, help with documentation, or spread the word.

For more details, check out the original Medium post.

spotinfo - cli for exploring AWS Spot instances

Alexei Ledenev — Sun, 16 May 2021 15:17:23 +0000

The spotinfo is an open-source command-line tool you can use for exploring AWS Spot instances across multiple AWS regions.

Under the hood, the tool uses the same data feeds as AWS Spot Advisor and AWS Spot Pricing.

Compared with the AWS Spot Advisor, the spotinfo supports advanced filtering and sorting (also with regex), in-place spot prices, cross-region comparison, and multiple output formats (plain text, JSON, table, csv).

A short overview is available on DoiT blogs here