Vacation-rental operations
Revenue Radar AI Agent
I built a TypeScript system that uses Hospitable booking data and PriceLabs recommendations to update eligible nightly rates every morning at 5 AM Eastern, with Claude-powered chat that explains the changes and lets the operator request confirmed adjustments.
Actual interface and pricing-engine decisions. Fictional portfolio; chat explains a recorded sample run.
Weekly and monthly reports connect pricing activity with booked nights, revenue, and average nightly rates.
Why I built it
Automate nightly pricing within operator-defined rules.
The operator reported spending two hours each morning reviewing bookings and overriding PriceLabs prices, so I used his intake, property strategy, and ongoing feedback to define which decisions the system could make automatically and which needed his review.
My role
Client discovery, scoping, architecture, implementation, testing, evaluation, and delivery.
The stack
- Runtime & reasoning
- Node.js · TypeScript · Anthropic SDK
Node runs the pricing engine and dashboard, while Claude uses defined tools to look up data and prepare operator changes.
- Operational APIs
- Hospitable v2 · PriceLabs v1 · monday.com GraphQL
These connect bookings and calendars, pricing recommendations and updates, and the operator’s briefs and approval workflows.
- Storage & deployment
- Railway · JSONL · Supabase PostgREST
Railway stores run and change logs, while Supabase stores operator memory and copies of decision data through its REST API.
- Validation & monitoring
- Zod · Vitest · Langfuse · Sentry · OpenTelemetry
These check configuration and pricing behavior, trace model calls, track usage, and make failures visible.
Model selection & prompt caching
I use prompt caching to reuse the operator’s playbook and earlier conversation context, while keeping straightforward formatting on Haiku and using Opus for reasoning that can affect pricing. Within chat, I also adjust reasoning effort so routine follow-up lookups use less computation and price-related requests receive deeper reasoning.
Implementation & decisions
- 01
Connect and reconcile the operating data
I wrote API adapters that bring Hospitable bookings and calendar rates together with PriceLabs recommendations, market data, and price limits. The code distinguishes the recommended rate from a manual override so each calculation starts from the right baseline.
- 02
Calculate a target for each available night
My TypeScript pricing engine adjusts the recommended rate using booking pace, when guests typically book, local demand, time until check-in, and weekend rules. Starting from an independent recommendation prevents the same daily adjustment from repeatedly multiplying yesterday’s price.
- 03
Enforce the operator’s pricing limits
I turned the intake into minimum and maximum rates, limits on individual changes, exclusions, and approval thresholds, with Zod checking the configuration. The code rechecks current limits before writing overrides to PriceLabs, which syncs them to the property system, and blocks automatic writes when required limits are missing.
- 04
Let the operator question and adjust decisions
Claude’s chat tools use recorded runs, pricing reasons, and the same saved operator guidance as the morning cycle, so its answers have a concrete source. A requested price change needs a preview and confirmation in a later message before the code can apply it.
More engineering detail
How I track model cost and cache reuse
I track model usage, cache reads, and cache writes to check whether repeated requests actually reuse context. Revenue Radar’s chat keeps Opus as its model and adjusts reasoning effort within the conversation, which is a separate control from choosing a cheaper model for a simpler task elsewhere in the workflow.
How I test changes before live pricing
Vitest tests cover differences between API data formats, pricing calculations, limits, approvals, chat confirmation, and failed updates. Dry-run mode and an explicit list of permitted properties let me evaluate changes before enabling real writes, while Langfuse, OpenTelemetry, and Sentry help trace calls and failures.
Where AI ends and the pricing code takes over
AI helps research demand and explain decisions, but the TypeScript engine calculates rates and enforces the operator’s limits before anything reaches PriceLabs. Chat shares the same playbook and saved guidance, and uploaded files can inform its reasoning without directly changing a computed price or the property’s minimum-stay rules.
The value
Automatic morning pricing that the operator can explain.
Eligible rates update before the operator starts his day, and he can review exceptions or ask why a rate changed because the system records its inputs, limits, and whether each update succeeded.
Client-reported: 2 hours saved each morning.