twenty-four: what's next

Two weeks after the service consolidation, here’s what’s been added.

Training Plan Generator

The big one: AI-powered training plan generation for endurance events.

What it does:

Give it a race (distance, date, sport) and it generates a complete training plan:

1
2
3
4
5
6
7
8

POST /training-plan
{
  "race_date": "2026-03-07",
  "race_distance": 13.1,
  "race_name": "Half Marathon",
  "sport": "Run",
  "start_date": "2026-01-01"
}

The service:

1. Fetches your current fitness metrics from Intervals.icu (CTL, ATL, recent training)
2. Checks your calendar for holidays and time off
3. Sends everything to Claude with instructions
4. Gets back a week-by-week plan
5. Creates structured workouts in Intervals.icu

Holiday awareness:

This was critical. The system:

• Detects existing calendar events marked as holidays
• Shows them in the prompt: “2026-03-07 to 2026-03-14: Spring Break”
• Enforces complete rest during those periods
• Adjusts training volume leading into and out of holidays

No more manually editing plans when you book a vacation. The AI sees it and routes around it.

Example prompt to Claude:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

Generate a training plan for a Half Marathon on 2026-03-07.

Current fitness:
- CTL (fitness): 45.2
- ATL (fatigue): 42.1
- Form: +3.1

Recent training (last 4 weeks):
- Week of 2025-12-09: 25 miles (4 runs)
- Week of 2025-12-16: 28 miles (4 runs)
- Week of 2025-12-23: 15 miles (2 runs) - holiday week
- Week of 2025-12-30: 30 miles (5 runs)

Holidays (NO workouts during these periods):
- 2026-02-14 to 2026-02-16: Presidents Day Weekend

Create a week-by-week plan from 2026-01-01 to 2026-03-07.

Format each workout as:
{
  "date": "YYYY-MM-DD",
  "name": "Workout Name",
  "type": "Run",
  "duration_minutes": 45,
  "description": "...",
  "warmup": "10 min easy",
  "main": "5x (4 min @ threshold, 2 min recovery)",
  "cooldown": "10 min easy"
}

Claude generates workouts that:

• Ramp volume gradually
• Include recovery weeks
• Respect holidays
• Peak 2-3 weeks before race day
• Include a proper taper

The system converts this to Intervals.icu format and creates all the workouts automatically.

Current state:

Tested with half marathon, 10k, and Olympic triathlon plans. Works well. The AI understands training periodization, knows when to schedule long runs vs. intervals, and respects your current fitness level.

Cost:

Each plan generation:

• ~2,000 input tokens (fitness context + holidays + instructions)
• ~6,000 output tokens (10-12 weeks of workouts)

Cost per plan: ~$0.10

Service Reorganization

Renamed services to better reflect scope:

Before:

• calendar (orchestrator)
• workouts (gym + Strava + workout plans)
• dining (meals)
• routine (dashboard)

After:

• routine (orchestrator - calendar sync, gym sync, Google Calendar)
• fitness (gym + Strava + workout plans + stretching + training plans)
• health (meals + quotes)
• dashboard (status monitoring)

The name workouts was too narrow. The service now handles:

• Gym class scraping and reservations
• Strava activity processing (emoji injection, commute detection)
• Claude-powered workout plan generation
• Daily stretching routines
• Multi-sport training plan generation

So it’s fitness now.

Similarly, dining was just meals. But I added daily inspirational quotes (also Claude-generated), so it’s health - mental + physical.

Caloric Goals

The health service (formerly dining) now lets you set daily calorie targets.

Interface:

Simple form at /meals/goals:

• Weekday target (Mon-Fri): 2800 cal
• Weekend target (Sat-Sun): 2500 cal

Saved to S3, integrated into the meal planning prompt:

1
2
3
4
5
6
7

Generate meals targeting approximately 2800 calories for today (weekday).

Distribute roughly:
- Breakfast: 600-700 cal
- Lunch: 800-900 cal
- Dinner: 900-1000 cal
- Snacks: 400-500 cal

The AI adapts meal sizes and portions to hit the target. If you increase your goal after a heavy training week, breakfast gets bigger. If you lower it for a rest day, portions shrink.

Why separate weekday/weekend?

Training volume differs. Most hard workouts happen during the week (gym, morning runs). Weekends are longer but easier efforts. Different caloric needs.

Weekly Meal Plans

Switched from daily meal generation to weekly.

Before:

Every day at 4am PT, generate today’s meals. Show one day at a time. Navigate forward/back through history.

After:

Every Monday at 4am PT, generate the full week. Display as a table:

Why weekly?

1. Shopping efficiency: See the whole week, make one grocery list
2. Meal variety: The AI can plan complementary meals across days (fish Monday, chicken Tuesday, etc.)
3. Training awareness: The AI sees the full week’s workouts and adjusts meals accordingly

Example:

1
2
3
4
5

Monday (Hard): Tempo run + gym → Higher carbs
Tuesday (Easy): 30-min recovery swim → Moderate carbs, focus on protein
Wednesday (Rest): No workout → Lower carbs, lighter meals
Thursday (Hard): HIIT + bike intervals → High carbs again
...

The prompt shows the entire week’s training schedule. Claude plans meals that support the workload.

Storage:

Changed from daily keys (dining/2025-11-01.json) to weekly keys (dining/week-2025-10-28.json). Week starts Monday, ends Sunday.

History retention: 12 weeks (used to be 30 days). Easier to browse past meal plans.

Observability

Added Prometheus metrics to all services:

• Request counts (by endpoint)
• Request duration (histogram)
• Error rates
• Active requests (gauge)
• Custom metrics (sync operations, API calls, etc.)

Endpoints:

• /metrics - Prometheus metrics
• /health - Liveness probe
• /ready - Readiness probe
• /logs - Recent log tail
• /readme - Service documentation (rendered HTML)

Why /readme?

Each service has a detailed README.md explaining:

• What it does
• API endpoints
• Configuration
• Dependencies
• Deployment

The /readme endpoint serves this as HTML. Useful for quick reference:

1

curl http://fitness.twenty-four.home/readme

Gym Notification Improvements

Fixed auto-reservation:

The routine service auto-reserves gym classes when:

1. You have a workout scheduled in Intervals.icu
2. The gym class matches the workout type (HIIT, Yoga, Spin, etc.)
3. The class is within the reservation window (21 days)

The logic was broken - it checked the wrong field (Name instead of Status). Now it correctly identifies workouts that need reservations and books them automatically.

Notification deduplication:

Added a deduplication system for Pushover notifications:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

type NotificationCache struct {
    RecentNotifications map[string]time.Time
    mu                  sync.RWMutex
}

func (nc *NotificationCache) ShouldSend(key string, message string) bool {
    nc.mu.Lock()
    defer nc.mu.Unlock()

    cacheKey := fmt.Sprintf("%s:%s", key, message)
    lastSent, exists := nc.RecentNotifications[cacheKey]

    if exists && time.Since(lastSent) < 24*time.Hour {
        return false // Already sent recently
    }

    nc.RecentNotifications[cacheKey] = time.Now()
    return true
}

Prevents duplicate notifications for the same event within 24 hours. If a gym class gets waitlisted and the hourly sync runs multiple times, you only get notified once.

Better status handling:

The gym scraper now correctly handles all status variations:

• FULL → Class is full
• Reserved → You’re registered
• Waitlisted → You’re on the waitlist
• Empty → Spots available

And it cleans up status markers from workout names/descriptions for classes beyond the reservation window.

What’s Actually Running

As of today (Nov 1, 2025):

1
2
3
4
5
6

$ kubectl get svc -n twenty-four
NAME        TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)
routine     LoadBalancer   10.233.66.5     10.233.66.5     80/TCP
fitness     LoadBalancer   10.233.66.4     10.233.66.4     80/TCP
health      LoadBalancer   10.233.66.9     10.233.66.9     80/TCP
dashboard   LoadBalancer   10.233.66.2     10.233.66.2     80/TCP

Four services. All Go. All running on ARM nodes. Total memory usage: ~1.5Gi.

Service breakdown:

Cost Summary

Monthly Claude API usage:

Total: ~$4.60/month

Negligible. The most expensive part is the weekly meal plan generation ($0.035 per call) because it generates 7 days of meals in one shot. Still cheaper than any meal planning service.

What’s Next

Training plan refinements:

The generator works but needs tuning:

• Better recovery week placement (currently every 4th week, could be smarter)
• Sport-specific workout types (brick workouts for triathlon, tempo runs vs. intervals)
• Integration with actual training completion (adjust future weeks based on missed workouts)

Meal plan feedback loop:

Currently meal feedback is tracked but not used. Next iteration:

• Feed yesterday’s meal feedback into today’s prompt
• Track which meals get skipped/modified consistently
• Adjust portion sizes based on hunger/fullness feedback
• Build a preference model over time

Health metrics integration:

The health service could display:

• Weight trends (already syncing to Intervals.icu)
• Sleep data (if I start tracking it)
• Resting heart rate
• HRV (heart rate variability)

All available from wearables. Just need to wire it up.

Multi-tenancy:

Right now everything is hard-coded for me. Making it multi-tenant would require:

• User authentication
• Per-user secrets (Intervals.icu API keys, Google credentials, etc.)
• Per-user S3 storage paths
• UI for onboarding and configuration

Not planning to do this. This is infrastructure for me, not a SaaS product.

See also: Part 0: The Platform | Part 1: Building with Claude | Part 2: Calendar Service | Part 3: Gym Service | Part 4: Strava Service | Part 5: Workout Generator | Part 6: AI Recommendations | Part 7: Service Consolidation

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com