Remoto frente a presencial

Si el periodo no es un número positivo, la tarea falla con invalid_input en lugar de inventar un horizonte.

Qué significa el ahorro remoto frente a presencial y cómo se forman ambos lados

Un net_savings positivo significa que el remoto es la mejor vía de caja; una cifra negativa significa que el sueldo de oficina sigue ganando tras desplazarse; un cero es un empate tras redondear a moneda. Fije net_savings y verdict en las pruebas para que un cambio posterior de redondeo no invierta en silencio qué oferta parece más barata.

Contrato de entrada, forma de la respuesta y comportamiento ante errores

El fallo distintivo es un period no positivo: si period es cero o negativo, la tarea falla en lugar de devolver un horizonte nulo que siempre informaría un ahorro cero. Las magnitudes por encima de un billón se rechazan para que un isolate no tenga que emitir productos no finitos. El redondeo es half-up para que los goldens coincidan byte a byte entre entornos. Envíe por POST un cuerpo JSON con cuatro números finitos obligatorios. remote_salary es la paga anual del puesto remoto en unidades de moneda por año; se aceptan los alias remote_pay y wfh_salary. on_location_salary es la paga anual del puesto de oficina en la misma moneda; se aceptan los alias office_salary, onsite_salary y on_site_salary. commute_cost es el coste anual en efectivo de desplazarse para el puesto presencial; se aceptan los alias annual_commute, commute y commuting_cost. period es el horizonte de comparación en años; se aceptan los alias years, horizon y period_years. Cada campo puede llegar como número JSON o como cadena numérica. Los campos ausentes, las cadenas vacías y los valores no finitos fallan con invalid_input nombrando el campo. remote_salary, on_location_salary y commute_cost pueden ser cero: una prueba no remunerada, un rol voluntario o un trayecto a pie son casos de planificación válidos, no errores. En caso de éxito el cuerpo ecoa las cuatro entradas; remote_total_pay; on_location_total_pay; commute_total; on_location_net tras restar el desplazamiento; salary_difference a lo largo del periodo; annual_net_savings; net_savings como cifra principal; verdict como remote, on_location o tie; y una cadena formula.

Dónde una calculadora de remoto frente a presencial aporta valor

Los equipos de people operations que publican bandas remotas y presenciales pueden mostrar a la plantilla la compensación del trayecto desde el mismo módulo que la persona puede volver a ejecutar después de la reunión. La validación fallida no consume saldo. Los candidatos que sopesan una oferta remota ajustada por ubicación frente a un sueldo de ciudad pueden pegar ambos salarios, un desplazamiento anual realista y un horizonte de dos a cinco años, y guardar net_savings junto al registro de la decisión. Los asesores de finanzas personales pueden llamar a la vía gratuita del navegador para un primer vistazo y a la API para un expediente guardado, de modo que la cifra que un cliente vio en la página de aterrizaje coincida con la cifra archivada tras el registro. Los asesores de reubicación que comparan un paquete de mudanza más oficina con quedarse y trabajar desde casa pueden dejar commute_cost como variable y leer verdict sin reconstruir la aritmética. 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. Mantenga los cuatro números finitos, conserve period estrictamente positivo, fije net_savings en las pruebas y obtendrá una llamada remoto-frente-a-oficina reproducible para widgets, cartas de oferta y workers en el borde, sin levantar un stack completo de retribución total propio.