Calorie cycling zigzag planner
Turn a weekly calorie budget into alternating high and low days: 14000 kcal with a 20% zigzag gives 2400 kcal high days and 1466.7 kcal low days, and the week still sums to 14000. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Weekly calories
- 14,000
- Zigzag percent
- 20
- Precision
- 1
- Average daily kcal
- 2,000
- High day kcal
- 2,400
- Low day kcal
- 1,466.7
- High day count
- 4
Calorie cycling, often called a zigzag diet, keeps the same weekly energy budget while alternating higher-intake and lower-intake days so the average stays on target. Coaches, app builders, and people tracking macros use it to ease adherence on social days, support harder training sessions with more fuel, and avoid the flat daily deficit that can feel restrictive every single meal. This calorie cycling zigzag planner accepts a weekly calorie total and an optional zigzag percent, then builds a deterministic seven-day plan: high days sit a fixed percent above the weekly average, low days are solved so the week still sums exactly to your budget, and the pattern alternates from Monday through Sunday.
How the zigzag week is calculated
Start from the weekly calorie total you already trust—maintenance times seven, a deficit plan, or any fixed budget—and divide by seven to obtain the flat daily average. The zigzag percent lifts high days above that average: high calories equal the average multiplied by one plus the percent over one hundred.
Because a seven-day alternating pattern cannot place the same number of high and low days, the planner counts how many high slots the pattern creates (four when the week starts high, three when it starts low) and solves low-day calories so that high count times high calories plus low count times low calories equals the original weekly total. That identity is what keeps the week honest: you are not inventing extra energy when you feast, and you are not under-delivering the budget when you lean out on quieter days.
Days are labeled Monday through Sunday with kind high or low and a calorie figure rounded to the requested precision; the last day absorbs any residual from rounding so the reported sum still matches the weekly total.
Where a calorie cycling zigzag planner earns its keep
Personal trainers and online coaches export a zigzag week into client meal templates so Friday dinner can sit higher without blowing the weekly deficit they already negotiated. Fitness apps that already compute TDEE or a straight deficit can call this planner as a pure post-step: same weekly calories, richer day-by-day targets for grocery lists and push notifications. Spreadsheet users who used to hand-tune high and low columns stop drifting off the weekly total when rounding creeps in; the residual day adjustment keeps the sum locked.
What you can do with it
Coach weekly client plans
Turn a fixed weekly calorie budget into seven alternating high and low targets clients can follow without exceeding the agreed energy total.
Fitness app post-processing
After computing TDEE or a deficit, call the zigzag planner to emit deterministic day-by-day intakes for grocery lists and reminders.
FAQ
Why do low days drop further than high days rise?
Because a week that starts high has four high days and three low ones. With 14000 kcal and a 20% zigzag, high days get 2400 kcal, so the three low days must fall to 1466.7 kcal to keep the weekly total.
Can I start the week on a low day?
Yes. Starting low gives three high days and four low ones, and the low-day figure is worked out again so the seven days still add up to exactly your weekly budget.
Why is the last day slightly different from the other high days?
The last day absorbs whatever rounding is left over, so the reported week matches your total exactly. In the 14000 kcal example, Sunday shows 2399.9 kcal instead of 2400.
Is there a limit to the zigzag percentage?
Yes. If the percentage is so large that low days would fall to zero or below, the plan is refused instead of forcing a starvation day. If you leave it empty, 20% is used.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your 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)Example request
{
"weekly_calories": 14000
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "health.calorie_zigzag",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Invalid or non-positive inputs fail with a clear invalid_input error instead of inventing calories.
How the zigzag week is calculated
If the percent is so large that low days would fall to zero or below, the request is rejected rather than returning a plan that would force a starvation day.
Input contract, response shape, and validation rules
Optional precision is an integer from zero to six decimal places and defaults to one. POST a JSON body with weekly_calories as a finite positive number—the seven-day budget in kilocalories. Optional zigzag_percent defaults to twenty and must be finite and positive; it is the percent elevation of high days above the weekly average. Optional high_first defaults to true so day one is high and the week alternates high, low, high, and so on; set it false to begin on a low day. Field aliases are accepted for ergonomics: weekly_kcal, week_calories, weekly_total, and total_calories map to the weekly budget; percent, variation_percent, swing_percent, and zigzag_pct map to the swing; start_high and begin_high map to high_first; decimals and dp map to precision. Missing fields, non-finite values, non-positive weekly totals, non-positive percents, and swings large enough to drive low days non-positive all fail with invalid_input and are not billed. On success the body echoes weekly_calories, zigzag_percent, and high_first; reports average_daily_kcal, high_day_kcal, low_day_kcal, high_day_count, and low_day_count; returns days as an array of seven objects each with day, label, kind, and calories; and includes sum_kcal, formula, and precision. Example: fourteen thousand weekly calories at twenty percent with high_first true yields a two-thousand average, high days at twenty-four hundred, and low days solved so four high and three low days still sum to fourteen thousand.
Where a calorie cycling zigzag planner earns its keep
Pair the output with your own macro split or meal generator if you need protein and carbs per day; this endpoint plans energy only, not macros, recipes, or medical advice, and it will not invent a week when the inputs are non-positive or otherwise invalid.
Integration use cases
Content widgets and demos
Power a free browser calorie cycling tool that matches the paid API byte-for-byte for SEO landings and product screenshots.
Technical questions
How does the calorie cycling zigzag planner work?
It divides your weekly calorie total by seven for the average, raises high days by zigzag_percent above that average, solves low days so the week still sums to the same total, and alternates high and low across Monday–Sunday.
What inputs are required?
weekly_calories (finite positive). Optional: zigzag_percent (default 20), high_first (default true), precision (default 1). Non-positive or invalid values return invalid_input.
Do high and low days still match my weekly total?
Yes. Low-day calories are solved from the weekly budget and the high-day level so n_high×high + n_low×low equals the weekly total before rounding; the last day absorbs rounding residue.
What if zigzag_percent is too large?
If low days would be zero or negative, the task fails with invalid_input. Reduce the percent so every day stays strictly positive.
What does the calorie cycling zigzag planner cost?
The browser tool is free. API requests use prepaid KIT balance at $0.002 per successful call; invalid input is not billed.