Work is accepted by tests, not by the agent's word.
Cruise independently checks each attempt within your approved ladder and token limit, accepting a passing result or stopping for review or at a limit.
Scope and operating details
You start it from your own terminal: describe the goal, approve the checks the client found in your repository, and run. Every attempt, save point and cost is on the record. The ladder is the list of models a job may try, cheapest first. When an attempt fails its checks, the exact save point taken before that attempt is restored and the next model on the ladder tries. When the last model fails, the job waits in your review queue instead of retrying. Supported today: bounded coding tasks that carry their own deterministic tests, on the KeepState runtime, across two model families (Anthropic-native and OpenAI-compatible).
Cruise runs a bounded coding task automatically from the released client: the acceptance manifest is drafted from the repository's own checks and locked on approve; each rung is a fork of the parked parent at its exact workspace digest; verification runs on the host, out of the agent's reach, on the pinned tests; the ladder escalates only within break-even and ends accepted or in the account's review queue; every attempt is reconciled on the job's ledger; and a synthetic tenant's job completed through the customer route on the standing production daemons. Publication is an authorization; no external pull request is created.
Publication authorization only. The verified winner receives a signed, scoped authorization. Any external effect, including an actual pull request, would be a separate object with its own record, and none is claimed here.
Data policy, enforced in production since the er-1-prod-green gate: customer data may enter a session under the acceptance manifest's classification and authorization enforcement. A customer classification requires a named authorization. The manifest never detects sensitivity; it enforces what you classified and authorized. Erasure is crypto-shredding, enabled in production.
- 25.2 s measured kill-and-resume downtime record
- 99 of 100 release gates green record
- Once billed at most once, gateway-enforced record
- Non-billable a negative trial result costs nothing record
Suitable work
Bring a repeatable coding queue, existing tests or other dependable acceptance checks, and someone who can authorize both the integration and the trial budget. Use public or synthetic data, or customer data covered by named authorization.
Available to every hosted account, from the released client. A job bills as the hosted sessions it runs: platform usage and model charges follow the price book, the signup credit applies, and the token limit and the spend limit you set are both active: Cruise starts no attempt that the rest of the limit cannot cover. There is no general savings guarantee. For larger workloads under agreed terms, a trial is available; its terms are published below, in what we agree before a trial.
Access:self-serve Measurement:illustrative exampleOne job's execution
Illustrative workflow. Not a customer result.
Example task
Update a dependency and pass the repository's existing tests.
- step 1 Agree the checks
- step 2 Run the first attempt
- step 3 Restore and retry if needed
- step 4 Review the verified result and cost record
In the currently verified publication scope, KeepState authorizes a result for review. It does not create an external pull request.
What we agree before a trial
A trial is for larger workloads under agreed terms; it is not needed to run Cruise on a hosted account. We agree the task family, acceptance checks, baseline, authorized data, job allocation method, spending ceiling and measurement policy before running jobs. The trial statement includes all accounted attempts, not just successful ones.
Trials run on the KeepState runtime. The terms below are the ones the signed agreement fixes; the agreement itself is reviewed by both sides before anyone signs it.
A negative result is publishable and non-billable
If the measurement shows no savings, or a loss, that is what the statement reports. No fee is due for a period whose conservatively estimated net is at or below zero, and neither side may suppress the result: you are free to publish it, and nothing in the agreement is conditioned on your withholding it. KeepState may publish it only with your written consent, and never in a way that identifies you without it.
- Spending ceiling
-
$2,000 per month by default
How this term applies
A spending ceiling is set per trial, and unless we agree otherwise it is $2,000 per month. You set it. It is enforced by the gateway rather than by a promise: a session that reaches its budget checkpoints and parks, and never overruns.
- Baseline
-
your existing policy, measured over the first week
How this term applies
The baseline is your existing policy: what the same accepted task costs you today. It is measured over the first week of the trial, written down before the comparison runs, and frozen at signature. It is the counterfactual every later figure is measured against.
- Performance fee
-
20% of conservatively estimated net savings
How this term applies
The fee is 20% of the conservatively estimated net savings under the agreed measurement policy: the lower confidence bound of accepted-work value minus KeepState's all-in cost. The rate is a term of the agreement. It is not a savings figure, it does not predict one, and this site publishes none.
Under the offered trial policy, the performance fee is 20% of conservatively estimated net savings that are eligible for settlement under the agreement. A negative result does not generate a performance fee. Platform usage, model charges and any other obligations follow the signed trial kit. There is no general savings guarantee.
These three are terms of an agreement, not measurements, which is why none of them carries a MEASURED or ESTIMATED badge. A rate states how a fee would be computed. It is not a saving, it does not predict one, and no settled customer trial result is published on this site.
what is frozen at signature
Four things are fixed when the agreement is signed, each attached to it as a versioned exhibit.
- The acceptance rules, including the pinned test manifest and its hash.
- The agreed baseline policy.
- The price book version.
- The analysis policy: the randomization, intention-to-treat, the sequential method and its spending function, negative carry-forward, and the reversal rule.
None of them may be chosen or adjusted after results are visible, which is the only way a savings number would mean anything.
Deviations are logged, never silently applied
Any change to a frozen item after signing is recorded in a deviation log attached to the settlement statement, with the date, the reason, who asked for it, and whether it took effect before or after the affected jobs ran. A deviation applied without that entry voids the affected period's fee. If a deviation changes the analysis policy, the statement reports the result both ways, under the frozen policy and under the deviated one.
The unsuccessful side is reported beside the accepted work
Every settlement statement reports, for the same period and with the same prominence as accepted work: jobs attempted but not accepted, escalations from the cheap tier to the strong tier and to human review, delayed rejections where work was accepted and later reversed, and any extra expenses incurred, including spend on jobs that produced nothing. A statement that shows only accepted work is incomplete and is not a valid basis for a fee.
A reversal is carried back, not quietly dropped
Work accepted and later rejected is carried back out of the value line by negative carry-forward, so a reversal reduces the settlement in the period it is discovered.
Settlement is blocked while any host-failover billing is unreconciled
If a host failover leaves billing unreconciled, settlement does not proceed until it is reconciled.
Free credits are never counted as value
Subsidies such as free credits are tracked separately and never counted as value, and every figure in a statement is labelled MEASURED or ESTIMATED.
what the trial costs to run, beside the fee
The performance fee is separate from what the trial costs to run, and both are stated.
- Session-minutes for as long as a session is awake, at the ratified price book.
- Checkpoint storage for what its checkpoints occupy after deduplication, at the same book.
- Model calls on your own key, paid to your provider directly, with no KeepState spread.
Attempts that are not accepted cost what they consumed. Their spend is metered, reported and counted in the all-in cost, not written off.
The trial does not run under the synthetic tariff the L-1 record used: the trial uses the ratified price book and every cost category. The rates are in the ratified price book, published on the pricing page, and what a branched or failed attempt bills is set out on the fork page.
the data a trial may touch
A trial admits public data, synthetic data, or your own data in a category you classify and authorize. The category is agreed in the acceptance manifest before any job runs, and the manifest enforces what you classified and authorized rather than detecting sensitivity for you. What KeepState does with data once it is admitted is set out in how KeepState handles data, and that policy, not this page, is the statement of record.
What we need to qualify a trial
A trial is agreed in writing before any job runs. To qualify one, we need these, and the acceptance manifest is locked from them.
- A repeatable task family
- the queue of bounded coding jobs the trial may cover, and nothing outside it.
- Existing acceptance checks
- the deterministic tests or other dependable pass condition each job must satisfy. Work with no machine-checkable done condition is out of scope.
- An authorized data category
- public, synthetic, or your own data in a category you classify and authorize, agreed in the acceptance manifest.
- An integration owner
- the named person who can connect the queue and answer for it.
- Buying authority
- the person who can authorize the spending ceiling and sign the agreement.
- Your intended spending ceiling
- if it is not the default.
Do not send source code or provider keys to qualify a trial. Nothing here asks for them.
Public results require separate permission. Positive, negative and inconclusive outcomes use the same reporting standard. Private participation does not become a testimonial. The statement a trial arrives in is set out below, in how trials are measured.
Bring the answers above in your first message. Signing up is account access for hosted sessions; it does not open a trial.
How trials are measured
No settled customer trial result is published yet; one appears only after it is signed and its publication permitted, with its numbers and its name. Here is how a trial is qualified, measured and reported.
A trial runs your real workload under checks agreed in writing before it starts. The report has fixed sections: the task family, the authorized data, the pre-agreed checks, the baseline, the allocation policy, the complete costs, the accepted jobs, the uncertainty, the limitations, the fee calculation, the settlement, the continuation and the publication permission. Every measure is badged MEASURED, ESTIMATED, or unavailable, with its provenance named.
A report that appears here may be a negative one. Under the agreed trial terms, a period whose conservatively estimated net is at or below zero carries no performance fee, and the customer is free to publish that result. The terms are in what we agree before a trial.
Cruise itself is self-serve on hosted accounts; an agreed trial adds the published terms above for larger workloads. Hosted sessions are self-serve too: create an account, bring a model key, and follow the hosted quickstart.
trial report template
What a trial report contains.
Template, not a customer result.
This template is published before the first trial so the format cannot bend to flatter the first result. No customer, no quote, no logo and no figure appears in it. Each heading is a section a signed report must carry.
- task family
- The kind of work the trial is allowed to cover, written down before it starts. Anything outside it is out of scope for the report.
- authorized data
- Which of your data the trial may touch, who authorized it, for how long, and where it was held.
- pre-agreed checks
- The acceptance checks, agreed in writing before any work runs. The report states the outcome of every one of them, in the order they were agreed.
- baseline
- What the trial is measured against, recorded before it starts: your existing policy for getting the same task accepted, measured over the first week and frozen at signature. It cannot be adjusted once results are visible.
- allocation policy
- How work was allocated between the compared arms, fixed in advance so the allocation cannot be chosen after the result is known.
- complete costs
- Every cost the trial incurred on both sides, including the attempts that were not accepted. A partial cost is not a result.
- accepted jobs
- Which jobs met the pre-agreed checks and were accepted, and which were not, counted the same way in both arms.
- uncertainty
- How much of the difference could be noise: the interval, the method that produced it, and what the report therefore cannot say.
- limitations
- What the trial does not establish, including the conditions it never ran under and the parts of your workload it never touched.
- fee calculation
- How the fee follows from the measurement: 20% of the conservatively estimated net savings under the agreed measurement policy. A period whose conservatively estimated net is at or below zero carries no fee at all, and this section shows the arithmetic either way.
- settlement
- What is owed, by whom and when, with the deviation log for the period attached beside it. Settlement is blocked while any host-failover billing is unreconciled.
- continuation
- Whether the work continues after the trial, under what agreement, and what happens if it does not.
- publication permission
- The written permission to publish this report, the scope that permission covers, and its date. Without it nothing publishes, in whole or in part, down to a single number.
In a signed report each field carries MEASURED or ESTIMATED and names the record it came from. Missing data renders unavailable, never zero; that is a law of this site, not a style.
The baseline rule, the spending ceiling and the fee rate these sections are computed under are agreed before any job runs and published in full in what we agree before a trial. What no page states, here or there, is a savings figure: none has been measured.
the three outcomes
The same template carries all three. Which one a report is cannot be chosen after the numbers arrive.
positive
The pre-agreed checks were met on the accepted jobs.
- States which checks were met, on which jobs, against the recorded baseline.
- States the complete cost of the trial, including the attempts that were not accepted.
- States the uncertainty and the limitations before it states the conclusion.
- Publishes only inside the scope the written permission covers.
negative
The pre-agreed checks were not met.
- Is written and delivered on the same schedule as a positive result.
- Describes the failure in enough detail for you to check it against your own records.
- States the complete cost anyway, because the cost was incurred whether or not the checks passed.
- Carries no performance fee for a period whose conservatively estimated net is at or below zero, and the customer is free to publish it.
- Is not withheld, shortened or renamed.
inconclusive
The pre-agreed checks cannot decide the question on the evidence the trial produced.
- Says so in its first line, and does not present the direction of the difference as a finding.
- Names what prevented a decision: the scope that changed, the run that was interrupted, or the data that was never authorized.
- States the complete cost and the uncertainty exactly as the other two do.
- Makes no claim in either direction, here or anywhere else on this site.
None of the three carries a figure. A variant fixes the shape of the statement; the numbers exist only inside a settled, signed report, and they reach this site only with written permission.
what did not work
This section is mandatory in every signed report. A trial that fails its pre-agreed checks still ships its report, and the failure is described in enough detail for you to check it. A report format that cannot record a loss is an ad, and we did not build an ad.
the technical recovery report is separate
Durability measurements taken on our own bench belong to a technical recovery report, not to a commercial trial statement. Held in one document they let bench work read as accepted customer work, so they are kept apart. The technical evidence we can show today, dated per row, is on the proof page. No gate tag names a customer. A green gate is our own test, and a test is never a paying reference.
Reports will be written from meter output, not from interviews. If a figure in one ever disagrees with your own measurement, that is a finding and we will publish the correction.
How a task is accepted
-
Step 1
Attempt
Try the bounded task on the cheaper model.
-
Step 2
Verify
An independent runner checks the work against the tests. The agent cannot reach that runner.
-
Step 3
Retry if needed
If verification fails, restore the exact save point, escalate to the next model on the ladder, and verify the result again. After the last model, the job waits in your review queue: resume it with another ladder, or cancel it.
-
Step 4
Authorize the verified result
The verified result receives signed, scoped authorization for a review branch or pull request. This scope does not create an external pull request.
A cheap result that verifies is accepted and authorized directly. Step 3 runs only when verification fails.
What Cruise requires
- A bounded coding task that carries its own deterministic tests.
- A hosted account and the released client. The goal is one sentence; the checks are the tests the client finds in your repository, which you approve before a run.
- Your own provider key in the console vault: hosted inference is bring-your-own-key, and a job is refused at submission if the account holds no key for a model on its ladder. Managed inference is planned.
- The KeepState runtime.
- A supported model family: Anthropic-native or OpenAI-compatible.
- Customer data classified by you, with a named authorization. The manifest enforces what you supply and does not detect sensitivity.
Accounting test: attempts reconciled
In the accepted-work test, settlement cleared only after every attempt reconciled, including the failed ones. The recorded run uses a placeholder tariff and is not a customer price.
Evidence behind this page
Verified accepted work and the cheap-first cascade are gated, evaluated at release v0.1.26. The dated public summary states the tested environment and limitations; current deployment is not independently verified. record
Bring a task that can prove itself.
If your work has deterministic tests, Cruise tries it on a cheaper model, verifies the result with an independent runner, and restores the checkpoint before escalating a failed attempt. The record shows every attempt and its cost.
keepstate.ai · the durable agent session cloud