Session workspace

A pipeline session keeps planning, measurement, results, testing, and delivery views together. Open a pipeline from the dashboard, then use the session views for the work described below.

​

Return to a background session

The dashboard can show one latest background session beside Weights. It chooses the newest eligible pipeline session in your current workspace:

• A running session remains eligible until it reaches a terminal state.
• A completed, blocked, or canceled session remains eligible until you visit its latest update.
• Terminal updates are returned for up to seven days.

Only one session appears at a time. There is no background-session list, overflow count, or close control in this navigation item. The top navigation shows a status symbol and the truncated pipeline name. The sidebar layout also shows the status word. The states are: RunInfra does not display a separate Failed state here. Failed and recoverable-failed executions appear as Blocked. Running uses a pulsing dot, Completed uses a check, Blocked uses an alert, and Canceled uses a cancellation symbol. Select the item to return to that pipeline session. After you visit a terminal update, the dashboard can move to the next eligible session or remove the item when none remains. The item refreshes when the dashboard loads, when the window regains focus, and every 30 seconds while session rows are available. A network error keeps the last trusted item instead of clearing it.

​

Compare candidates in Experiment

Before you start a session, open the Mode menu in the composer:

• Optimize measures candidates and can apply the winner. This is the default.
• Experiment measures candidates side by side without applying an optimization.

The selected mode is locked after the session starts. Start a new plan if you need to change it. Choose Experiment, then describe the comparison in chat. RunInfra creates a comparison plan for you to review in Plan. Select Accept and run, review the spend disclosure, then select Run plan. No live measurement starts before that confirmation.

​

What an experiment spec contains

An experiment spec is the comparison matrix attached to the plan. It contains one or more slices. Each slice changes one axis while keeping the other configuration fixed: Each slice must contain 2 to 5 candidates. The spec also records the requested priority: latency, throughput, cost, quality, or balanced. A plan-level cell budget limits the total matrix size. RunInfra does not start a matrix that exceeds that limit or mixes more than one axis within a slice. Comparison Lab appears only when the current plan contains a valid experiment spec. If the selected model type does not support comparison experiments, or if the matrix is invalid, the tab explains the block and does not start paid work.

​

Approve experiment spend

Choosing Experiment does not spend credits. Starting the comparison uses the plan consent flow. For a multi-model experiment, the consent dialog shows a price for each model based on its size and planned techniques. The displayed total also includes any shared-GPU component and is rounded. Use Estimated charge (all models) as the source of truth instead of adding the model rows yourself. For a chargeable run with a priced preview, the consent dialog itemizes the cost, shows your balance, and shows any temporary hold before you select Run plan. If you edit the plan after it was priced, the dialog replaces stale amounts with a reduced disclosure. Trial, non-chargeable, and postpaid paths can show a reduced or no-cost confirmation instead. Any unused hold is refunded after settlement.

​

Read Comparison Lab results

Comparison Lab is scoped to the current plan and current execution. Use the slice tabs to move through a multi-slice matrix. The header shows the number of finished candidates and the requested priority. The candidate matrix keeps the plan order while results arrive. Each candidate has one of these states: Completed, Failed, Unsupported, Not reported, or Pending. The result tiles can show:

• P50 and P99 latency
• Throughput
• Peak VRAM
• Quality score
• Measured workload cost per request

RunInfra keeps unavailable values separate from measured values. A slice that mixes request throughput and token throughput does not receive one combined throughput chart. A quality comparison requires measured quality scores for every candidate. The lab also states when concurrency was not varied. Recorded cells restore after reload. If a refresh fails, the lab keeps the latest trusted cells and labels the result as degraded instead of replacing it with an empty result.

​

Run standard benchmarks

Open Benchmarks after an optimization run has produced a verified winner. Benchmark reports are tied to an optimization version. Select a version before you start a new run or open an older report. The available suite depends on the selected model: Select one or more checks. Then choose a sample tier:

• Standard runs the standard sample for each selected benchmark.
• Full requests the full sample.

Each check measures the baseline and optimized model. The progress view separates those two passes and reports completed or failed work. A typical run takes about nine minutes per selected benchmark. You cannot start a benchmark while optimization is running or while another benchmark run is active.

​

Approve benchmark spend

RunInfra requests a quote after you choose the suite and sample tier. For a chargeable run, the confirmation shows the expected cost, worst-case cost, available balance, and any required credit hold before you select Run benchmarks. Enterprise postpaid and zero-cost quotes show a reduced confirmation instead. The run does not start until the quote is ready. If your balance is too low, the panel shows the available and required amounts with an Add credits link. If the worst-case quote exceeds the displayed per-report cap, reduce the selection or run the checks in separate reports. If dispatch remains uncertain, use Check run status to reconcile the same run instead of starting another one.

​

Read a benchmark report

The report starts with a recorded verdict. The score table then shows:

• Baseline and optimized scores
• The measured delta and recovery percentage
• The number of evaluated samples
• Whether the run used a full set or a sampled subset

A pending or unsupported measurement does not receive a score. Open a row to inspect the recorded benchmark setup, model revisions, sample caps, and other report details. History is grouped by optimization version and survives a reload. If a newer version becomes active, the page identifies the version used by the displayed report and offers a new run for the active version. A run that records only refusals remains in session chat and is not added to report history.

​

Read Optimization KPIs

For a chart with no more than one data series, the top band shows four core result lenses once any of them has data:

• Latency
• Throughput
• Cost
• VRAM

All four positions remain visible together. A lens without a reported value stays pending. When the chart has multiple data series, the band shows interactive series controls instead of the four KPI items. The KPI value and change arrow come from the same recorded headline used by its chart tile. RunInfra does not calculate a second percentage in the browser. Select a KPI to move to the corresponding tile.

​

Read cost without treating missing data as free

RunInfra shows a per-request cost only when it has a positive reported value. A missing, zero, negative, or invalid value is omitted instead of appearing as $0. A reported value below $0.0001 appears as <$0.0001. For text generation, the chart cost tile uses Cost per 1M tokens. If a trusted average cost per request is also available, it appears as a separate caption with its provenance. RunInfra does not relabel a per-request value as a per-token value. The Cost KPI describes serving-workload cost. It is not the optimization run’s quote or billing receipt. Use the session cost summary for the estimated run charge, final charge, and released hold.

​

Read the final Run result

When an execution settles, chat keeps one latest terminal result card for that execution. An experiment run produces a result card like any other run. Supporting evidence can still appear beside the result. For example, a Test Set regression card can remain immediately before it. The one-card rule removes duplicate terminal summaries for the same execution. It does not hide distinct evidence.

​

Verdict and measured change

The card can show:

• An achievement headline based on measured baseline and winner values
• Target met, Target missed, or Not judged against the target
• The target and measured value
• Completed plan phases
• Techniques that were not kept or were skipped, with a reason
• A quality receipt reference

If no target was set, the card does not add a “no target” placeholder. It shows the measured value when one exists. The Before / after table joins comparison evidence from the same execution. It can include exactly these rows:

• Latency
• Throughput
• VRAM
• Cost per request

The table shows baseline, winner, and percentage change. A missing side appears as not measured, and no percentage is calculated without both values. If the execution has no matching baseline and winner comparison, the table and achievement headline are omitted. A multiplier headline requires positive measured values on both sides. A gain below 1.1x is shown as a percentage only when the rounded gain is at least 1%; smaller rounded gains do not produce a headline. A regression in the requested goal blocks another metric’s headline only when the goal ratio is below 0.99.

​

Result actions

The card orders the follow-up actions supplied for that result, then always appends Open Optimization: Opening a destination does not bypass its readiness, billing, or delivery checks. Refine and Compare never send a message automatically.

​

Use keyboard shortcuts

RunInfra shows platform-specific key labels. Windows and Linux use the same shortcuts. Press ?, which is Shift /, to open the full Keyboard shortcuts reference. You can also open the command palette and select Keyboard shortcuts. The reference groups commands under Global, Session, and Composer. Previous and next view wrap through Pipeline, Optimization, Benchmarks, Experiment, Code, Config, Workspace, Deploy, Test, and Plan. The session command bar opens Search views. If chat is covering that control, RunInfra closes chat before opening the bar. Pressing / opens chat when needed and focuses the composer. Session shortcuts become available after the session workspace is ready. They do not replace normal typing inside an editable field. ⌘ K or Ctrl K can still open the command palette while an input has focus, and Esc can close the shortcuts reference.

​

Shortcut hover help

Hover a Search control for 500 milliseconds to see its command-palette shortcut. Keyboard focus shows the same hint immediately. In a compact session composer, hovering the composer shows the / shortcut while the composer is enabled and not focused. Shortcut hints close when you leave the control or press Esc. RunInfra hides them while a dialog is open.