Remote vs on-location workers

If the period is not a positive number the task fails with invalid_input instead of inventing a horizon.

What remote versus on-location savings means and how both sides are formed

A positive net_savings means remote is the better cash path; a negative figure means the office wage still wins after commuting; a zero is a tie after rounding to currency. This identity does not discount cash flows to present value, does not add home-office furniture or broadband, does not price recovered commute hours, and does not fetch income-tax tables. Those belong to a fuller total-rewards model. Pin net_savings and verdict in tests so a later change to rounding cannot silently flip which offer looks cheaper.

Input contract, response shape, and error behaviour

Magnitudes above one trillion are rejected so a single isolate cannot be asked to emit non-finite products. Rounding is half-up so goldens compare byte-for-byte across runtimes. POST a JSON body with four required finite numbers. remote_salary is the annual pay of the remote role in currency units per year; aliases remote_pay and wfh_salary are accepted. on_location_salary is the annual pay of the office role in the same currency; aliases office_salary, onsite_salary, and on_site_salary are accepted. commute_cost is the annual cash cost of commuting for the on-location role; aliases annual_commute, commute, and commuting_cost are accepted. period is the comparison horizon in years; aliases years, horizon, and period_years are accepted. Each field may arrive as a JSON number or as a numeric string. Missing fields, empty strings, and non-finite values fail with invalid_input naming the field. remote_salary, on_location_salary, and commute_cost may be zero: an unpaid trial, a volunteer role, or a walk-to-work commute are valid planning cases, not errors. The distinctive failure is a non-positive period: if period is zero or negative the task fails rather than returning a horizon of nothing that would always report zero savings. On success the body echoes the four inputs; remote_total_pay; on_location_total_pay; commute_total; on_location_net after subtracting commute; salary_difference over the period; annual_net_savings; net_savings as the primary figure; verdict as remote, on_location, or tie; and a formula string.

Where a remote versus on-location workers calculator earns its keep

People operations teams that publish remote and on-site bands can show employees the commute offset from the same module the employee can re-run after the meeting. Failed validation does not consume balance. Candidates weighing a location-adjusted remote offer against a city wage can paste both salaries, a realistic annual commute, and a two-to-five-year horizon, then store net_savings beside the decision log. Personal-finance coaches can call the free browser path for a first look and the API for a stored file, guaranteeing that the figure a client saw on the landing page matches the figure filed after signup. Relocation advisors comparing a move-plus-office package with a stay-and-work-from-home package can hold commute_cost as the variable and read verdict without rebuilding the arithmetic. Keep the four numbers finite, keep period strictly positive, pin net_savings in tests, and you get a reproducible remote-versus-office call for widgets, offer letters, and edge workers without standing up a full total-rewards stack of your own.