Compute, tokens, and model selection

Organ tracks two independent consumption axes: model usage and execution compute. Subscription fees, included compute credits, provider billing, and venture spend controls sit on top of those measurements but do not change what the underlying metrics mean.

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

The product exposes three provider pathways:

Provider	Use it when	Credential
Claude	You want a direct Claude coding or reasoning workflow.	A usable Anthropic credential or configured platform path.
Codex	You want an OpenAI/Codex model supported by the execution harness.	A usable Codex/OpenAI credential or configured platform path.
OpenRouter	You need a routed model catalog or a non-native model.	An OpenRouter credential or configured platform path.

The model selector shows the catalog price per million input/output tokens, context length, maximum output, quality tier, and declared support for tools, vision, and structured output. OpenRouter entries are loaded from the live model endpoint; if that request fails, its list can appear empty even while saved configuration still exists.

Changing the provider clears the previous model because model identifiers are provider-specific. Select a compatible model after changing provider, or use the product's Undo action to restore the previous provider/model pair.

Configuration scopes

Venture LLM configuration supports four scopes. The most specific matching scope wins:

1. Workflow phase: one phase in one workflow, such as Developer VALIDATING.
2. Workflow: every model-using phase in Developer, Research, Content, and so on.
3. Named phase: a phase name shared across eligible workflows.
4. Global: every model-using phase without a more specific selection.

The workflow UI offers overrides only for phases that use a model. Infrastructure, waiting, and notification phases do not need a model selection.

Business configuration is snapshotted onto a new workflow run. Editing venture defaults affects future runs; it does not silently change the configuration already attached to an active run.

Per-run overrides

Developer, Discovery, Research, Content, and Health Check launch forms can expose an expandable LLM Configuration section. A per-run workflow or phase selection takes priority over venture defaults for that run.

Use per-run overrides for controlled experiments or exceptional work. Promote a selection to venture configuration only after it proves appropriate for repeated use.

Session reuse and prompt cache

Developer phases can resume or fork an earlier model session. By default, the child phase inherits the parent provider/model so its existing context remains reusable. A hard phase-specific override is respected, but changing the model on a reused session can cause a full cache miss; changing the provider may make resume unsupported. The run records a warning when it can identify that mismatch.

When planning phase overrides, keep adjacent resume/fork phases on the same provider/model unless the quality benefit clearly outweighs cache loss.

How to choose a model

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

Work characteristic	Prefer	Why
Complex architecture, ambiguous planning, difficult review	Premium reasoning model	Quality failures can cost more retries and human review than the token difference.
Routine implementation, synthesis, or general content	Balanced model	Usually the best quality, latency, and cost tradeoff.
Classification, title generation, bounded extraction	Economy model	Low-complexity output rarely needs the most expensive reasoning tier.
Large repository or long research corpus	Larger context window	Prevents truncation, but does not guarantee the agent will use all context well.
Tool-heavy workflow	Model with tool support	The model must produce the provider's supported tool-call structure.
Strict JSON or typed artifact	Structured-output support	Reduces parsing and repair loops.
Screenshots or generated-image review	Vision support	Text-only models cannot inspect the pixels.

Do not choose from input price alone. Output tokens can cost materially more than input tokens, and a weaker model can consume more calls through retries, repairs, or verbose output.

Token terminology

Each completed LLM call can report four counters:

Counter	Meaning	Included in displayed total
Input	New prompt/context tokens processed normally.	Yes
Output	Tokens generated by the model.	Yes
Cache creation input	Prompt tokens written into provider cache.	Yes
Cache read input	Prompt tokens served from provider cache.	Yes

The compact phase label uses actual tokens, defined as input plus output. The detail popover's total tokens also includes cache creation and cache reads. This distinction explains why the compact number can be lower than the detailed total.

Final phase metadata can also include:

• cache hit rate: cache-read tokens divided by all input-side tokens;
• estimated cache savings;
• model-level token and cost breakdown for phases that called multiple models;
• the resolved provider/model and execution limits.

While a phase is running, streaming counters can show input, output, cache tokens, and model. Cost and final cache analytics appear only after the completed usage payload is persisted.

How model cost is estimated

Organ ignores provider-reported dollar totals and recomputes cost from recorded token counts and its model-pricing catalog:

input cost       = input tokens / 1,000,000 × input price
output cost      = output tokens / 1,000,000 × output price
cache-write cost = cache-write tokens / 1,000,000 × input price × write multiplier
cache-read cost  = cache-read tokens / 1,000,000 × input price × read multiplier
estimated cost   = sum of those four amounts

For Anthropic-priced models, the current estimator treats cache writes as 1.25× base input price and cache reads as 0.10× base input price. Other catalog entries use their configured cache multipliers.

For example, 100,000 normal input tokens and 20,000 output tokens on a model priced at $3/$15 per million produce an estimated cost of:

(100,000 / 1,000,000 × $3) + (20,000 / 1,000,000 × $15) = $0.60

Historical estimates can be approximate when an older run does not contain the same model detail available on current runs.

Aggregation and attribution

One model-using phase can make several calls and can use more than one model. Organ groups usage by model within the phase, aggregates phases into the workflow, then aggregates workflows into venture analytics.

Cost Analytics provides:

• total recorded model cost over 7 days, 30 days, or all time;
• trend against the previous equivalent period;
• workflow-type and daily cost breakdowns;
• Developer average cost, failure cost, major-phase cost, token count, and department attribution;
• estimated container compute as a separate summary card in Developer mode.

The headline model total includes recorded workflow types plus Brain synthesis. Developer-specific denominators and phase/status charts intentionally use Developer runs only, so do not divide a cross-workflow total by the Developer task count.

Compute usage

Compute is execution runtime, not model inference. The displayed estimate is derived from completed workflow duration and the workload/capacity selected when its runner starts:

compute estimate = completed runtime × workload tier × capacity rate

Standard and Large workloads have different runtime weights, and Spot and on-demand capacity have different rates. The values shown in Organ are product estimates, not a reconciled cloud-provider invoice. Real capacity price, utilization, and scheduling vary.

The compute view:

• counts completed runs only;
• refreshes hourly;
• does not accrue an in-progress run live;
• excludes unattributed history from before compute snapshots were introduced;
• limits “all time” analytics to the available compute history.

Subscription and usage billing

The platform fee and usage charges are separate:

• paid plans include a monthly compute-credit allowance for agent runtime;
• model tokens are separate—use your own provider key where supported, or use the configured metered provider path;
• during the seven-day trial, trial compute and token credits are deducted before metered usage is reported.

Cost Analytics is operational telemetry; the billing-provider invoice is the commercial record. Small differences can occur because of refresh timing, credits, rounding, legacy records, or which provider credential paid the underlying model.

Venture spend caps

The venture Billing tab compares month-to-date recorded AI model cost with the configured spending threshold. Brain synthesis contributes to the displayed AI spend; compute is shown separately.

Use this control to guide and restrict supported new work, but do not treat it as a guaranteed organization-wide financial ceiling. Work already in progress is not canceled when it crosses the threshold, and provider charges can settle after the platform view refreshes. Configure provider-side budgets and cloud controls when strict financial enforcement is required.

Diagnose unexpected usage

1. Match the venture and date window.
2. Open the workflow and identify the expensive phase.
3. Open the phase token popover and compare input, output, cache, model, and per-model rows.
4. Check whether the phase retried; failed attempts can still consume tokens.
5. Confirm the resolved model rather than the currently configured default—the run uses its snapshot.
6. Check for a phase-specific or per-run override.
7. For compute, wait until the run completes and the hourly view refreshes.
8. Compare platform estimates with the provider or billing invoice, accounting for credits and rounding.

Common explanations include a large repository context, low cache reuse, a model change across a resumed session, repeated validation/repair loops, verbose output, parallel plan/review calls, an older run with less attribution, or a long-running Large/on-demand workload.

What to expect

• Model prices and limits are a catalog snapshot; confirm consequential commercial decisions with the provider.
• Available phase/model detail depends on the workflow and when the run was recorded.
• Compute is an hourly refreshed estimate for completed, attributable runs—not live infrastructure billing.
• The billing-provider invoice is the commercial record.