Context

When comparing usage hours between Recall and Assembly systems, you may notice that Recall shows higher usage numbers. This difference occurs because the two systems track usage differently during bot lifecycles:

• Assembly: Bills based on the actual meeting recording.

• Recall: Bills based on the total server (EC2 instance) uptime.

Bot Lifecycle Events

A bot typically goes through:

• joining_call: Bot starts its session.

• in_call_recording: Bot begins recording the meeting.

• call_ended: Meeting recording stops.

• done: Bot session fully ends.

How Billing Works

• Assembly Billing:

  • What it measures: Only the meeting recording time (from in_call_recording to call_ended).

  • Example: Time spent in the waiting room or if the bot isn’t allowed into the meeting isn’t billed.

• Recall Billing:

  • What it measures: The total time the bot’s EC2 instance is active (from joining_call to done).

  • Example: Even if the bot never joins the meeting, you’re billed for the entire server uptime because the instance was running.

Why the Difference?

• Assembly aligns costs with the actual recorded meeting.

• Recall recovers the cost of spinning up and running the EC2 instance, regardless of whether the bot successfully joins the meeting.

Common scenarios that cause higher Recall usage include:

• Time spent in waiting rooms

• Cases where bots are never admitted to meetings

• Server startup and shutdown time

Managing Waiting Room Timeout

To minimize excess usage from waiting rooms, you can configure how long a bot will wait before leaving if not admitted to a meeting:

1. Use the Create Bot API

2. Set the `automatic_leave.waiting_room_timeout` parameter to your desired timeout duration