Planificador ciclo calórico zigzag
Convierta un presupuesto semanal de calorías en días altos y bajos alternos: 14000 kcal con un zigzag del 20 % dan días altos de 2400 kcal y bajos de 1466,7 kcal, y la semana sigue sumando 14000. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Calorías semanales
- 14 000
- Zigzag (%)
- 20
- Precisión
- 1
- Promedio diario (kcal)
- 2 000
- Día alto (kcal)
- 2 400
- Día bajo (kcal)
- 1 466,7
- Número de días altos
- 4
El ciclo calórico, también llamado dieta en zigzag, mantiene el mismo presupuesto energético semanal alternando días de mayor y menor ingesta para que la media siga el objetivo. Entrenadores, desarrolladores de aplicaciones y personas que controlan macros lo usan para facilitar la adherencia en días sociales, apoyar sesiones de entrenamiento más exigentes con más combustible y evitar el déficit diario plano que resulta restrictivo en cada comida. Este planificador de ciclo calórico en zigzag acepta un total semanal de calorías y un porcentaje de zigzag opcional, y construye un plan determinista de siete días: los días altos quedan un porcentaje fijo por encima de la media semanal, los días bajos se calculan para que la semana sume exactamente su presupuesto, y el patrón alterna de lunes a domingo.
Cómo se calcula la semana en zigzag
Parta del total semanal de calorías en el que ya confía—mantenimiento por siete, un plan de déficit o cualquier presupuesto fijo—y divídalo entre siete para obtener la media diaria plana. El porcentaje de zigzag eleva los días altos por encima de esa media: las calorías altas equivalen a la media multiplicada por uno más el porcentaje entre cien.
Como un patrón alterno de siete días no puede colocar el mismo número de días altos y bajos, el planificador cuenta cuántas ranuras altas crea el patrón (cuatro si la semana empieza alta, tres si empieza baja) y resuelve las calorías de los días bajos de modo que el conteo alto por las calorías altas más el conteo bajo por las calorías bajas iguale el total semanal original.
Esa identidad mantiene la semana honesta: no se inventa energía extra al festejar ni se entrega menos presupuesto en los días más tranquilos. Los días se etiquetan de lunes a domingo con tipo high o low y una cifra de calorías redondeada a la precisión pedida; el último día absorbe el residual del redondeo para que la suma reportada siga coincidiendo con el total semanal.
Si el porcentaje es tan grande que los días bajos caerían a cero o por debajo, la solicitud se rechaza en lugar de devolver un plan con un día de inanición.
Dónde un planificador de ciclo calórico en zigzag aporta valor
Los entrenadores personales y los coaches en línea exportan una semana en zigzag a plantillas de comidas del cliente para que la cena del viernes pueda ser más alta sin romper el déficit semanal ya acordado. Las aplicaciones de fitness que ya calculan el TDEE o un déficit recto pueden llamar a este planificador como un paso posterior puro: las mismas calorías semanales, objetivos día a día más ricos para listas de la compra y notificaciones.
Quienes afinaban a mano columnas altas y bajas en hojas de cálculo dejan de desviarse del total semanal cuando el redondeo se cuela; el ajuste del día residual mantiene la suma fija. Combine la salida con su propio reparto de macros o generador de comidas si necesita proteínas e hidratos por día; este extremo planifica solo la energía, no macros, recetas ni consejo médico, y no inventará una semana cuando las entradas sean no positivas o inválidas de otro modo.
Qué puede hacer con ella
Planes semanales para clientes del coach
Convierta un presupuesto calórico semanal fijo en siete objetivos altos y bajos alternos que el cliente puede seguir sin superar el total energético acordado.
Postprocesado en aplicaciones de fitness
Tras calcular el TDEE o un déficit, invoque el planificador zigzag para emitir ingestas deterministas día a día para listas de la compra y recordatorios.
Preguntas frecuentes
¿Por qué los días bajos bajan más de lo que suben los altos?
Porque una semana que empieza en alto tiene cuatro días altos y tres bajos. Con 14000 kcal y un zigzag del 20 %, los altos reciben 2400 kcal, así que los tres bajos deben quedarse en 1466,7 kcal para respetar el total.
¿Puedo empezar la semana con un día bajo?
Sí. Si empieza en bajo, la semana tiene tres días altos y cuatro bajos, y la cifra de los días bajos se vuelve a calcular para que los siete días sumen exactamente su presupuesto.
¿Por qué el último día no coincide del todo con los otros días altos?
El último día absorbe el resto del redondeo, de modo que la semana cuadra exactamente con su total. En el ejemplo de 14000 kcal, el domingo muestra 2399,9 kcal en lugar de 2400.
¿Hay un límite para el porcentaje de zigzag?
Sí. Si el porcentaje es tan grande que los días bajos quedarían en cero o menos, el plan se rechaza en vez de imponer un día de ayuno forzado. Si lo deja vacío, se usa el 20 %.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/health/calorie-zigzag \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"weekly_calories":14000}'const res = await fetch("https://api.kit.forhosting.com/health/calorie-zigzag", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"weekly_calories": 14000
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/health/calorie-zigzag",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"weekly_calories": 14000
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/health/calorie-zigzag", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"weekly_calories":14000}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"weekly_calories":14000}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/health/calorie-zigzag", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"weekly_calories": 14000
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "health.calorie_zigzag",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
Las entradas inválidas o no positivas fallan con un error invalid_input claro en lugar de inventar calorías.
Contrato de entrada, forma de la respuesta y reglas de validación
La precision opcional es un entero de cero a seis decimales y vale uno por defecto. Envíe un cuerpo JSON por POST con weekly_calories como número finito positivo—el presupuesto de siete días en kilocalorías. El zigzag_percent opcional vale veinte por defecto y debe ser finito y positivo; es el porcentaje de elevación de los días altos sobre la media semanal. El high_first opcional vale true por defecto para que el día uno sea alto y la semana alterne high, low, high, y así sucesivamente; póngalo en false para empezar en un día bajo. Se aceptan alias de campo por comodidad: weekly_kcal, week_calories, weekly_total y total_calories apuntan al presupuesto semanal; percent, variation_percent, swing_percent y zigzag_pct a la variación; start_high y begin_high a high_first; decimals y dp a precision. Campos ausentes, valores no finitos, totales semanales no positivos, porcentajes no positivos y oscilaciones tan grandes que dejen los días bajos no positivos fallan con invalid_input y no se facturan. En caso de éxito el cuerpo repite weekly_calories, zigzag_percent y high_first; informa average_daily_kcal, high_day_kcal, low_day_kcal, high_day_count y low_day_count; devuelve days como matriz de siete objetos con day, label, kind y calories; e incluye sum_kcal, formula y precision. Ejemplo: catorce mil calorías semanales al veinte por ciento con high_first true produce una media de dos mil, días altos a dos mil cuatrocientos y días bajos resueltos de modo que cuatro altos y tres bajos sigan sumando catorce mil.
Dónde un planificador de ciclo calórico en zigzag aporta valor
Como la implementación es parse pura de nivel A, cada llamada exitosa cuesta el precio base publicado $0.002 sin tokens de modelo ni red saliente, y la validación fallida no consume saldo.
Casos de integración
Widgets de contenido y demostraciones
Impulse una herramienta gratuita de ciclo calórico en el navegador que coincide byte a byte con la API de pago para landings SEO y capturas de producto.
Preguntas técnicas
¿Cómo funciona el planificador de ciclo calórico en zigzag?
Divide su total semanal de calorías entre siete para la media, eleva los días altos en zigzag_percent sobre esa media, resuelve los días bajos para que la semana sume el mismo total y alterna high y low de lunes a domingo.
¿Qué entradas son obligatorias?
weekly_calories (finito positivo). Opcional: zigzag_percent (por defecto 20), high_first (por defecto true), precision (por defecto 1). Valores no positivos o inválidos devuelven invalid_input.
¿Los días altos y bajos siguen coincidiendo con mi total semanal?
Sí. Las calorías de los días bajos se resuelven a partir del presupuesto semanal y el nivel de días altos de modo que n_high×high + n_low×low iguale el total semanal antes del redondeo; el último día absorbe el residual.
¿Qué ocurre si zigzag_percent es demasiado grande?
Si los días bajos serían cero o negativos, la tarea falla con invalid_input. Reduzca el porcentaje para que cada día se mantenga estrictamente positivo.
¿Cuánto cuesta el planificador de ciclo calórico en zigzag?
La herramienta del navegador es gratuita. Las peticiones API usan saldo prepago KIT a $0.002 por llamada exitosa; la entrada inválida no se factura.