Habr shows how to talk to an AI over SMS when mobile internet goes down

Habr has published a post on how to talk to a language model over SMS when mobile internet is unavailable. The author's premise is simple: in some regions, connectivity is unreliable, and a smartphone temporarily turns into a phone that can only make calls and send messages. The key number here concerns the channel, not the model. One SMS holds 160 Latin characters or 70 Cyrillic characters. The AI's answer has to be squeezed through that narrow bottleneck.

One important caveat: the publicly available part of the post contains no technical details. The rest is hidden behind a cut, so what follows covers the general logic of such solutions, not the author's specific implementation.

How the setup works

Almost every "AI over SMS" variant is built from the same blocks. The phone sends a message to a number connected to an SMS gateway. The gateway can be a GSM modem with a SIM card or the API of a messaging aggregator. The gateway passes the text to a server, which calls the language model's API. The answer is compressed and sent back through the same channel.

The main advantage is that the user has nothing to install. Any feature phone works. The server sits wherever the internet is available, while the person needs only a cellular network.

Where the channel breaks the usual scenario

Chatbots are used to giving long answers. SMS does not tolerate that. Cyrillic is encoded in UCS-2, so a single message holds 70 characters, and in a concatenated message each part carries only 67. Latin text in GSM-7 encoding gives 160 and 153 characters respectively.

Key parameters of the channel:

• a single SMS: 160 characters (GSM-7) or 70 (UCS-2, Cyrillic);
• one part of a concatenated message: 153 or 67 characters;
• a 1,000-character answer in Russian takes about 15 messages, and in Latin script about 7;
• delivery guarantees neither order nor timing, so parts may arrive out of sequence;
• the carrier bills each message separately.

This leads to several engineering decisions. The system prompt must demand answers of one or two sentences. The server has to cut the model's output to fit the limit and number the parts. Sometimes it makes sense to reply in transliteration or in abbreviated form to fit the more compact encoding, although such text is harder to read.

Risks and limitations

SMS is not end-to-end encrypted. Everything you ask is visible to the carrier and the gateway owner. That is tolerable for everyday questions, but not for medical or financial ones. Cost is another issue: if the service replies at your expense, fifteen messages for a single answer quickly add up to a noticeable sum. If the bot's owner pays, the service needs protection against abuse, meaning per-number limits and spam filters.

There is also a dependence on infrastructure. If connectivity disappears entirely, SMS will not help either. If only mobile internet is restricted while voice and messages still get through, the setup works.

What to do if you want to replicate it

Start with the minimum. Take a gateway with a simple webhook or a GSM modem, plus a small server-side script. Limit the answer length strictly in the prompt and also truncate it in code. Set up a whitelist of numbers and a daily message limit. Decide right away who bears the costs. Do not send sensitive data over such a channel. For complex queries, it is better to teach the bot to send a short answer and offer to continue on a command such as "more", rather than sending ten messages at once.

The idea is modest, but it works. It is a reminder that access to AI depends not on the quality of the model but on the channel through which the answer reaches the person.