Linear Agent Pricing: Model Tokens Plus $0.25 per 20-Minute Sandbox Block

Linear has made the cost stack unusually explicit: coding sessions are charged for model usage at the provider published rate with no markup, while the sandbox costs $0.25 for each 20-minute block. The split turns an opaque credit meter into two variables engineering teams can forecast.

The factual baseline comes from Linear's August 20 changelog. Product behavior and prices can change, so confirm the current page before making a purchase or locking an annual budget.

The budgeting mistake is to look at one visible rate and treat it as the whole system. Coding work crosses planning, context retrieval, tool calls, file edits, execution, validation, repair, and review. Every stage can add tokens, runtime, or people. A useful model preserves those layers and then rolls them into cost per accepted result.

What Matters for the Cost Model

• The agent can install language toolchains and dependencies from a repository-specific environment configuration.
• It can launch the application, navigate browser flows, capture before-and-after screenshots, repair failures, and rerun verification.
• Token and runtime consumption appear separately in the usage dashboard, including the model chosen for the session.
• Admins can apply workspace and per-user limits that reset daily, weekly, or monthly, pausing additional usage at the limit.

These facts change the shape of spend, but they do not determine whether the product is economical. A higher-priced run can be the cheaper outcome if it merges on the first attempt and needs little review. A low-cost run becomes expensive when it wakes repeatedly, occupies compute while idle, or produces a patch that experts must rewrite.

Build the Equation Before the Forecast

Total session cost equals provider token cost plus $0.25 multiplied by the number of started 20-minute sandbox blocks. A 42-minute run occupies three blocks, so runtime contributes $0.75 before tokens. If the model portion is $1.60, the visible total is $2.35.

Keep cached input, uncached input, and output separate because their rates can differ by an order of magnitude. Add tool fees, search calls, image or screenshot processing, and regional premiums only when the workflow actually uses them. For runtime, model billing minimums and rounding explicitly. A spreadsheet that assumes perfect per-second billing can understate a block-priced service.

A Worked Monthly Example

Suppose a team delegates 300 issues a month. The median session uses two blocks and $0.90 of model tokens, while 10% of sessions require a second browser-test loop that adds one block and $0.35 in tokens. Baseline spend is $420: 300 times $1.40. Retry spend adds $18: 30 times $0.60. The resulting $438 budget is more useful than multiplying prompts by a guessed credit value.

Run a sensitivity range around the estimate. Use a low, expected, and high case for acceptance rate, output length, retry count, and runtime. Those variables usually move the answer more than a tiny difference in input-token price. The high case should represent a difficult but plausible sprint, not an impossible catastrophe.

Controls That Preserve the Savings

• Record token and sandbox spend separately. Make this visible in the run record so the team can connect the control to dollars and accepted output.
• Stop idle sessions before a new block begins. Make this visible in the run record so the team can connect the control to dollars and accepted output.
• Pin toolchains so setup does not consume repeated runtime. Make this visible in the run record so the team can connect the control to dollars and accepted output.
• Use browser tests only for flows whose failure cost justifies the loop. Make this visible in the run record so the team can connect the control to dollars and accepted output.

Give every automated run a durable identifier that follows retries, branches, builds, and review. Without that join key, invoices remain disconnected from engineering outcomes. Aggregate by task class, repository, team, model, and trigger so a change in workload mix does not masquerade as a price change.

The Failure Mode to Watch

The block boundary creates a small cliff: a session that ends at 20 minutes and 10 seconds may cost twice as much in runtime as one that ends just under 20 minutes. Do not pressure agents to rush blindly, but instrument where time is spent. Slow package installation, flaky tests, and unnecessary dev-server waits are operational waste, not model intelligence.

Set a stop condition before the run begins. Repeated failure on the same test, no material repository change, a spend ceiling, or a deadline can all trigger escalation. Stopping is not failure; it protects the budget and gives a human the evidence needed to change the approach instead of financing another identical loop.

How to Decide

Linear is economical when the extra environment and browser verification replace human reproduction and review time. It is less attractive for tiny text-only edits that can be completed locally without a sandbox. Compare accepted outcomes, not merely session count.

Start with a bounded pilot and preserve a control group using the current process. Track model dollars, runtime dollars, tool charges, reviewer minutes, acceptance, cycle time, and post-merge defects. After enough comparable tasks, calculate total cost per accepted result. Use the AI Cost Calculator for the token component, then add the operational layers the API invoice does not show.