Compute, tokens, and model selection

Use model and compute usage to choose AI settings, understand costs, and control venture spending.

In short

• Choose models by capabilities, price, and the work involved.
• New runs keep a snapshot of their AI settings.
• Model tokens and execution compute are measured separately.
• Cache usage can explain differences between token totals.
• Spend limits, alerts, and invoices serve different purposes.

MODEL DECISION PATH

From configuration to attributable usage

1. 01

   Choose

   Select the provider, model, and scope.

2. 02

   Resolve

   The most specific valid setting wins.

3. 03

   Execute

   The run keeps its resolved model snapshot.

4. 04

   Attribute

   Tokens, cache, compute, and cost become visible.

Select a provider and model

Use the current model selector for available providers and native models. Each choice needs usable credentials or a configured platform-paid path.

Path	When to use it	Access needed
Direct model provider	Supported coding or reasoning models	Usable provider credential or platform path
Model catalog provider	Broader model choices	Usable catalog-provider credential or platform path

Economy, balanced, and premium describe model choices, not subscription plans or guaranteed quality.

The selector shows input/output prices per million tokens, context length, and maximum output. It also lists quality tier and support for tools, vision, and structured output.

The broader catalog refreshes in the background. Failed refreshes retain the previous catalog.

1. Open Settings → AI & Compute and choose a provider.
2. Select a compatible model; changing provider clears the previous model.
3. Use Undo to restore the previous provider/model pair if needed.

Choose which work uses the model

The most specific matching configuration wins.

Priority	Scope	Applies to
First	Workflow phase	One phase in one workflow
Second	Workflow	Model-using phases in that workflow
Third	Named phase	Matching phase names across eligible workflows
Fourth	Global	Work without a more specific choice

System workflow defaults fill remaining gaps. A compatible agent default can supply a missing model.

Only phases that use a model offer overrides. Waiting, notifications, and infrastructure steps do not need model selections.

Venture settings are copied onto new runs. Editing defaults affects future runs, leaving active runs' saved settings intact.

Try a model for one run

Developer, Discovery, Research, Content, and Health Check launch forms can expose LLM Configuration. Per-run workflow or phase selections take priority over venture defaults for that run.

Use these overrides for experiments or exceptional work. Save venture defaults once a choice proves appropriate for repeated use.

Preserve session reuse and prompt cache

Developer phases can resume or fork earlier sessions. Child phases normally inherit the parent provider/model to reuse context.

A specific phase override still applies. Changing models can cause a full cache miss; changing provider may make resume unsupported.

The run records a warning when it detects that mismatch. Keep adjacent reused sessions on the same provider/model unless the benefit justifies losing cache reuse.

How should you choose a model?

Start with the workflow default and change one dimension at a time.

Work	Consider	Reason
Ambiguous planning or difficult review	Premium reasoning	Avoid costly repairs and repeated review
Routine implementation or content	Balanced model	Compare capabilities and catalog prices
Classification or bounded extraction	Economy model	Simpler output may need less reasoning
Large repositories or research collections	Larger context	Reduce truncation; context use is not guaranteed
Tool-heavy work	Tool support	Supported tool calls are required
Typed output	Structured-output support	Reduce parsing and repair attempts
Screenshot review	Vision support	Text-only models cannot inspect pixels

Compare output prices as well as input prices. Retries, repairs, and verbose answers can outweigh a lower token price.

What do token totals include?

Completed model calls can report four counters.

Counter	Meaning	In detailed total?
Input	New prompt/context tokens	Yes
Output	Generated tokens	Yes
Cache creation input	Tokens written to prompt cache	Yes
Cache read input	Tokens served from prompt cache	Yes

The compact actual tokens label counts input plus output. The detail popover's total tokens also counts cache creation and cache reads.

Completed phase details can show cache hit rate, estimated cache savings, and per-model costs. They can also show resolved provider/model settings and execution limits.

Cache hit rate divides cache-read tokens by all input-side tokens. Running counters are provisional; final cost and cache analytics appear after completed usage is saved.

How is model cost estimated?

Organ recalculates estimates from recorded tokens and its pricing catalog rather than provider-reported dollar totals.

Cost part	Calculation
Input	Input tokens ÷ 1,000,000 × input price
Output	Output tokens ÷ 1,000,000 × output price
Cache write	Cache-write tokens ÷ 1,000,000 × cache-write price
Cache read	Cache-read tokens ÷ 1,000,000 × cache-read price
Total	Sum of the four parts

Catalog cache prices take precedence. Where catalog cache rates are missing, applicable models calculate cache prices from input prices: writes cost 1.25× input price, reads cost 0.10×.

For example, 100,000 input and 20,000 output tokens at $3/$15 per million cost $0.60 before cache usage. Older records with less model detail can produce approximate estimates.

Read cost totals and attribution

A phase can make several calls using multiple models. Usage groups by model, then phase, workflow, and venture; Brain synthesis also contributes to venture model totals.

Cost Analytics view	What it shows
7 days, 30 days, or all time	Recorded model cost and previous-period trend
Workflow and daily breakdowns	Attribution by work type and date
Developer views	Average and failure costs, major phases, tokens, and department attribution
Detailed mode	Separate estimated container-compute summary

Developer charts and task counts use Developer runs only. Do not divide the cross-workflow model total by the Developer task count.

What counts as compute usage?

Compute measures execution runtime separately from model inference. Estimates use attributed runtime, workload tier, and capacity rate recorded when the runner starts.

Setting or interval	Effect
XSmall, Small, Standard, Large	Different runtime weights
Spot or on-demand capacity	Different capacity rates
Completed workflow	Compute settles after completion
Active chat container	Running time is added each hourly refresh and divided by calendar day in UTC

The view refreshes hourly and does not accrue in-progress workflows live. Unattributed older history is excluded from priced totals; “all time” covers available compute history.

These are product estimates, not reconciled cloud invoices. Actual capacity price, utilization, and scheduling vary.

Separate subscription and usage charges

Charge or credit	What it covers
Platform fee	Subscription access
Paid-plan allowance	Monthly credit shared by platform-paid tokens and compute
Usage beyond allowance	Charges with the platform fee disclosed in pricing
Own usable provider key	Matching model calls billed directly by that provider
Platform key	Platform-paid model calls, including shared provider subscriptions
7-day trial	One-off $10 credit shared by platform-paid model usage and compute

Trial credit has no monthly refill. Subscription credits and metered invoicing are applied separately.

Cost Analytics explains usage; the billing-provider invoice is the commercial record. Refresh timing, credits, rounding, legacy records, and paying credentials can cause differences.

Set venture spend controls

Open Settings → Usage & budget to choose the control you need.

Control	Result
Budget alert	Warns without stopping work
Monthly spend limit	Blocks supported new work when charges plus reserved unfinished work reach the limit
Hard-stop option	Also stops supported active work between model steps once recorded charges reach the limit
Temporary staff override	Can temporarily change the applicable restriction

Reserved money can become available when unfinished work completes. Recorded charges at the limit require a budget change or a new billing period.

Use provider-side budgets and cloud controls too. Provider charges and recorded usage can settle at different times.

Diagnose unexpected usage

1. Open Cost Analytics for the correct venture and date window.
2. Open the expensive run and its phase token popover.
3. Compare Input, Output, cache usage, and per-model rows.
4. Check retries and the run's saved model settings, including phase and per-run overrides.
5. For compute, wait for completion and the hourly refresh.
6. Compare the billing invoice with estimates, allowing for credits and rounding.

If you see…	Why	What to do
High input usage	Large context or repeated planning/review calls	Inspect phase inputs and repeated calls
Low cache reuse	Model changes or resumed-session mismatches	Compare adjacent phases' model settings
Expensive failed work	Retries and repairs still consume tokens	Inspect failure and attempt history
High output usage	Verbose answers or repeated repairs	Inspect phase outputs
High compute	Long runtime or larger/on-demand workload	Compare duration, tier, and capacity
Missing attribution	Older runs have less detail	Use available records and invoices

Check estimates before making billing decisions

Catalog prices and limits are snapshots. Confirm consequential commercial decisions with the provider and use the billing invoice as the commercial record.

Available phase detail depends on workflow type and recording date. Compute remains an hourly estimate rather than live infrastructure billing.