Run history and costs

Every time someone starts a step, Alara Code records a run: which step it was, who started it, which agent did the work, how it ended and how long it took. You can read those records per project in the Run History tab, or across all your projects on the Run history page. This page also explains how Alara Code accounts for what the agent's work cost, and where that shows up.

Two places to see runs

Both lists read the same run records. They differ in scope and in how much detail each row carries.

The project's Run History tab

The tab is headed Run history with the line "The last 20 command runs for this project, newest first." Each row has four columns:

When the project has no runs yet, the tab shows No runs yet with "Run a step in SDLC Studio to see history here."

The tab refreshes itself: every 5 seconds while a step is running on the project, and every 30 seconds otherwise. The duration of a run that is still going is measured up to the last refresh, so it moves forward in steps rather than ticking every second.

The Run history page

The page is headed Run history, "Every pipeline command run across your projects." At the top are four counters:

A run waiting for review (pending_review) is counted in Total runs only.

Below the counters is a table with Command, Project, Status, Started and Duration. Click a row (or focus it and press Enter or Space) to open that run's project. This table does not show who started a run, which agent ran it, or the error text — open the project's Run History tab for those.

When none of your projects has a run yet, the page shows No runs yet with "Run a command from any project to see history here."

Run statuses

A run has one of five statuses. The badge shows the status name as recorded.

Drawing diagram…

A few details that explain what you see:

• Approval changes the run's status. RFP, Scope, SRS, SDS, STS and Proposal have an approval gate. When one of those finishes with a new draft, its run shows pending_review; approving the draft turns the same run complete. See Review, approve, request changes.
• A completed run can go back to review. An approval belongs to one exact version of a document. When a gated step is run again and produces a new version, that step's approval no longer holds, and its earlier complete runs are switched back to pending_review so the history matches what still needs approving. Later steps keep their approvals; they are only marked as built on an older input ("re-run, upstream changed" in the composer). See How the pipeline works.
• A re-run that changes nothing is an error. If a gated step runs again and produces exactly the document that was already approved, there is nothing new to review. The run ends error with a message saying it did not produce a new version.
• Request changes is a run too. When you request changes on a draft, the revision is recorded as a run of that step and lands in pending_review again.
• Chat messages are not runs. Talking to the agent in the project chat does not add rows to Run History.

Who started a run

Anyone who can open a project and holds the run permission can start its steps, so several people may drive one project. The subtitle under each command in the project's tab says by whom: the name of the person who started the run, or their email address when no name is set.

The on part names the Alara agent that did the work. The name is captured when the run starts, so if the project is later bound to a different agent, older rows still show the agent that actually ran them. See Set up the project agent.

Anyone who can see the project can stop a running step, not only the person who started it, provided they hold the stop permission. See Members and permissions.

Durations

Duration is the time from the run's start to its end, shown in whole minutes and seconds (12m 5s) or seconds alone under a minute (42s). A run that has not ended yet is measured up to now (on the Run history page) or up to the last refresh (in the project's tab).

The duration covers the whole run: every call to the agent, and every correction round when a draft fails the document checks. Time spent waiting for your approval afterwards is not part of it.

Errors in the history

A run that ends error stores a message, and the project's Run History tab shows it under the status badge. Common messages:

Other messages are the underlying technical error. The full catalogue of error codes, with causes and fixes, is in Troubleshooting. While a step is running, the live run panel in SDLC Studio gives more detail than the history does; see Run the pipeline.

A run that was stopped (aborted) shows no message in the tab, whether someone pressed stop or the run hit the time limit.

Who can see run history

Run records follow the project's visibility: you only see runs of projects you can see, within your current organization. Organization admins see every project in the organization; everyone else sees the projects they created and the projects shared with a team they belong to. See Members and permissions.

Deleting a project removes its run history along with its documents, artifacts and board.

Costs

Alara Code keeps a cost ledger per project. Each entry records the tokens a piece of AI work used and what it cost in US dollars.

What an entry records

One entry is written per model used in a unit of work. Each carries:

• the project, the organization, the person who started the work, and the step (for pipeline work) or other source;
• a link back to the run it belongs to;
• the model name;
• four token counts: input, output, cache read and cache write;
• the cost in US dollars, to six decimal places.

How cost is counted

Cost is computed from a pricing table that holds, for each provider and model, a price per million tokens for each of the four token kinds. The entry's cost is:

cost = (input x input rate + output x output rate
        + cache read x cache read rate + cache write x cache write rate) / 1,000,000

• The model is first resolved to the real model that served the request, so the right price applies.
• When no price is listed for that model, the cost the provider itself reported is used instead, so spend is never dropped.
• When usage arrives without a per-model breakdown, it is recorded against the model name <unknown>.
• A stopped or failed run is still costed for what it used before it ended.
• Writing a cost entry never fails a run. If an entry cannot be written, the run carries on and the spend is simply not recorded.

The breakdown

For a project, the ledger is summed three ways:

Where costs appear

On the Projects dashboard, a project card shows a cost strip when the project has recorded spend above zero: the input and output token counts (for example "120K in · 34K out") and the dollar total (for example "$1.42"). Projects with no recorded spend show no strip.

The per-step and per-model breakdown is available from the API (below). There is no Cost tab in a project's sections.

Under the hood

Runs live in the run_log table and cost entries in cost_entry, with prices in model_pricing; every read is scoped to your organization and to the projects you can see. See Data model, API reference and Run lifecycle and streaming.