Translated from the original published on vc.ru on 2026-09-14 — original

We're building 1trAIner — a service for those who want to align their workouts with their goal, recovery, and schedule, rather than just get another generic plan. The coach works in Telegram, with a mini app and a dashboard on the website alongside it. The first working version appeared in May 2026. In this article, we'll explain how we use Garmin data, why we split planning into horizons, and why combining a language model with watch metrics still requires constraints and verification.

Why another coach was needed

A plan from the internet has one useful property: it provides structure. But such a document on its own doesn't know how you slept, what you did yesterday, or whether you can train at all on Thursday. Between the table and real life, there's still work to do: assess the circumstances, rearrange sessions, decide whether to do the intense part today.

With a human coach, you can discuss such changes. But individual support can be expensive, and the answer doesn't always come right away. At the same time, we don't believe a language model automatically replaces professional experience. Its role is different: gather the available context and suggest a plan that can be read and discussed.

So for us, an AI coach for running is not a generator of a nice schedule from a short questionnaire. It's important that when building a day, the context retains the goal, previous workouts, recovery metrics, and the person's constraints. Otherwise, personalization ends at addressing you by name.

The dialogue itself is also needed. Not every circumstance shows up in the watch, and not every question can be turned into a form field in advance. In 1trAIner, you can request a plan adjustment in words. But we separate hard constraints from free conversation: blocked dates, available days of the week, and time limits are set in the dashboard.

We describe this approach on the methodology page. Its point is not to collect as many metrics as possible for analytics. Data should help answer a narrower question: what load is appropriate right now within the overall preparation and available time.

Cascade: season, month, week, day

Planning is structured as a cascade: season → month → week → day. The lower horizon is built on top of the upper one. The daily task must be part of the week, and the week must be a continuation of a longer plan, not a separate model response that happened to land next to the previous ones.

This is an architectural constraint, not a request for the model to "remember the strategy." If the required upper horizon hasn't been assembled, the service builds it first. A gap cannot be silently bypassed and a daily plan issued as if the whole chain already exists.

Otherwise, an unpleasant substitution occurs: today's text looks convincing, but it is unclear what preparation task it addresses. The presence of a connected chain by itself does not prove the quality of the recommendations. However, it provides support for the next step and does not allow the absence of a plan to be considered a normal initial state.

There is also a simple content check: a plan is considered to be text no shorter than 300 characters. The message "the planner did not return text" does not become a plan and is not passed on as a basis for the next horizon. This is protection against placeholders, not an assessment of the text's sports literacy.

A person's schedule matters more than the week's template. If a date is blocked, a day is unavailable, or a time limit is set for workouts, these conditions must be strictly observed. A beautifully distributed load makes no sense if fulfilling it requires ignoring your own calendar.

Training load increases in steps. The point at which to ease off is determined by training load, readiness and the quality of completed workouts, not by a fixed rotation of weeks. That is why a long plan here does not mean every future day is already set in stone: the lower horizons exist precisely to refine the overall structure.

What workout review from watch data provides

For the model, the fact that a run was completed is not the only thing that matters. The context includes recent workouts with dates and "today" or "yesterday" markers, as well as an automatic review of fresh workouts based on Garmin data. It includes zones, splits, and weather. This allows discussing a specific session rather than an abstract "I went for a run yesterday."

The main data groups this review relies on:

  • Sleep and resting heart rate are part of the recovery context before the next load.
  • Heart rate variability, or HRV, and readiness are metrics for which the prompt defines rules for adjusting intensity.
  • Training load is the context that keeps a fresh workout from being viewed separately from previous ones.
  • Lactate threshold, or LT, heart rate zones and race predictions are reference points for tying intensity to the athlete's data rather than to generic tables.
  • Splits and weather are details of the fresh workout that the model can access during the review.

The rule in the prompt is stated plainly: when readiness, HRV or sleep is low, or when acute training load is high, intensity is reduced. When readiness is high, quality work is allowed. The key word is "allowed": one favourable metric does not override the goal of the week or the constraints of the schedule.

This is how data can change tomorrow. If the overall structure includes intense work but recovery is low, the model is instructed to reduce intensity. This is a description of the decision-making rule, not a promise that any model response flawlessly follows it.

The task with zones and threshold is similar. We pass training metrics so that intensity is not assigned according to a universal table for any runner. Splits and weather add the circumstances of the completed work. But by themselves they do not give the right to confidently explain any unsuccessful workout: having data and interpreting it correctly are different things.

Besides the watch, the context includes the profile, goals, athlete memory, and a nutrition diary for 7 days. With a clear deficit before a high-volume day, the coach warns about underfueling. This is not a medical diet, but a limited hint within the discussion of workouts.

We also put together a description of our approach to running on the "AI coach for running" page. What matters to us here is not the number of input fields, but the connections between them: what the person intended to do, what they have already done, and under what conditions they will perform the next task.

Where AI makes mistakes

A language model can get a number wrong, misunderstand a question, or give an incomplete answer. A long, confidently written plan does not become correct just because it mentions your metrics. We do not view Garmin access as a way to eliminate model errors.

So it helps to separate form checks from meaning checks. The 300-character threshold filters out short placeholder text. It says nothing about whether the load is chosen correctly or whether there is a contradiction within the text. It would be dishonest to present such a filter as quality control for training methodology.

Filling in a missing horizon solves a different problem: the lower-level plan needs a foundation. It closes a gap in the chain, but it also does not turn every sentence from the model into a verified fact. Both measures are needed, yet each has a narrow scope.

Hard constraints from the dashboard stand apart. Blocked dates, availability by day of the week, and the daily minute limit matter more than the weekly template. These are not preferences that can be sacrificed for a more convincing text. They set the boundaries within which it makes sense to suggest workouts at all.

The plan is always visible in full in the dashboard and mini app. Any edit can be requested in words. This interface leaves room to notice an inconsistency and return to the discussion, instead of getting only a short task without the rest of the context.

Errors can also occur before the planning stage. Voice messages are recognized by our service using faster-whisper. Without a domain hint, the model made mistakes on proper names, so the hint includes sports terms, route names, and peak names. This is another example of why a general tool has to be supplemented with context for a specific task.

Medical questions are outside the service. The coach refers to a doctor, does not make diagnoses, and does not prescribe treatment or medications. 1trAIner is an informational service; watch metrics do not change this boundary.

We also apply restrictions to public texts. The site has automated checks for promises of results and medical claims, and each article lists its author and update date. This is not a check of the daily plan, but separate work on how we describe the product: we cannot promise on the outside what the system cannot reliably deliver on the inside.

How much it costs and why there are no auto-charges

The first 7 days are free, then the subscription costs 450 ₽ per month or 4999 ₽ per year. There are no auto-charges, the card is not saved, and renewal is done manually via a link. Basic information about the service is available on the main page.

For the user, this scheme means a simple thing: continuing the subscription requires a separate action. We think it's important not to mix the decision to keep using the coach with the inertia of a payment setting. At the same time, we won't attribute any effect on retention or other metrics to the absence of auto-renewal — there's no such data in this story.

The cost of a subscription and the cost of model requests are different levels. Our language model is DeepSeek. By default, deepseek-v4-pro is specified, and starting 10.09.2026 requests are routed to V4.1 Flash. So when talking about expenses, it's important to look at the current price list, not just the model name in the settings.

As of 10.09.2026, the base rates are $0.15 per million input tokens, $0.003 per million cached input tokens, and $0.60 per million output tokens. During peak hours they are twice as high: $0.30, $0.006, and $1.20 per million respectively.

According to the provider's price list, peak hours are 01:00–04:00 and 06:00–10:00 UTC on weekdays. Weekends are not considered peak. We pre-generate daily plans at 03:15–03:59 MSK: this time falls outside the peak intervals in UTC.

Generation and delivery are separate. The user receives the plan at their delivery time, by default at 6:00 MSK. For a task that can be prepared in advance, there's no need to tie the computation to the moment of sending.

This is a specific engineering solution for managing request costs, but not a ready-made unit economics. You can't derive the cost of a subscription from token rates without data on usage volume. We don't publish revenue, user numbers, or unit economics in rubles.

What's next

The iPhone and Apple Watch app is in closed testing on TestFlight. We're not promising release dates here. It's more important for us to discuss the mechanisms that already work separately from expectations: workout context, the planning cascade, schedule constraints, and the ability to see the full response.

For us, the next step is to keep working on the gap between convincing text and a useful plan. More data doesn't remove this task. An AI coach should have clear grounds for recommendations and equally clear boundaries beyond which what's needed isn't another model response.

Which screenshots to include

  • Methodology page (/methodology): show the description of how the coach makes decisions.
  • AI coach for running page (/ai-trener/po-begu): show how the service's approach is described for the running discipline.
  • Home page (/): show the intro screen with the service description.

Source: vc.ru