How a session starts | Ara Documentation

Sending a task does not hand your prompt straight to a model. Ara first puts a real computer behind it: a sandbox with your repository checked out and an agent runtime booted inside.

What this means day to day

You notice	Why
Follow-ups answer faster than the first message	They reattach and skip sandbox work entirely
Two identical tasks start at different speeds	One claimed a prepared slot, the other did not
Your setup script never delays the first reply	It is launched and watched, never awaited

If the Session Start Script is still running when the agent begins work, Ara tells the agent so it retries a command rather than failing on a missing tool.

Why workspace preparation takes as long as it does

Preparing the workspace is not one step. Ara clones the repository, fetches the default branch, fetches and checks out the working branch, clones any additional context repositories, and makes sure the toolchain the agent needs is present.

How long that takes is mostly a property of your repository rather than of Ara: a large repository with a long history and many files takes longer to clone than a small one, and that difference is the single biggest factor in how quickly a fresh sandbox is ready. Ara now records how long each of those steps took individually, so a slow start can be attributed to the specific step responsible instead of reported as one opaque total.

This is measurement only. It does not change how a session starts, what runs inside the sandbox, or the order in which anything happens.