Lithi Code & Tests

Start with a source-linked finding

Get a second review of a defined code change. For a fixed firstLength.ts change, the reviewer can flag the empty-array path at its source range, cite the caller and types that support the finding, and state the missing check. Your coding agent decides what to change and runs builds and tests in the approved development environment.

The returned finding is a reviewable observation, not an executed test result or a repair.

Your coding agent keeps the source context, applies any accepted edit, and runs local builds and tests before final acceptance. The Kit prepares the permitted review request; participating Macs process the bounded evidence and return findings for that decision.

Compute does not execute native code, fuzz the repository, commit edits, or guarantee a pull request. Your coding agent performs those local actions and makes the final acceptance decision.

Source trees, builds, tests, and release evidence belong to the Code & Tests information family. The packet contains changed source, callers, relevant types and schemas, and existing test evidence. Include the source revision, bounded files, and the context needed to understand each finding.

Private or proprietary source is not automatically a no-fit. The owner must permit prepared plaintext disclosure for the selected review. Aliasing protects identity or joins; it does not hide an algorithm from a review that needs to inspect it. Keep synthesis and local edits with the customer and the agent that owns the working context.

A review concern may span several related files, callers, and evidence records. Keep that context together when it changes the decision; separate concerns only when each has an independent source range, rubric question, and acceptance check. A file boundary alone does not define the review unit.

The selected operation defines the supported input and result. This guide explains preparation and review patterns: diff review, parallel review, debugging hypotheses and evidence review. Resolve the exact operation through current discovery; workflow names do not create a service the account can call.

Conceptual task brief: Review the fixed diff for firstLength.ts with its callers, relevant type contract, and recorded test evidence. Cite every finding to a source range. State supporting evidence and counterevidence, identify missing coverage, and abstain when the supplied context cannot decide. Return reviewable repair suggestions only; do not edit the repository, run code, choose a winner, or claim that a test executed.

The selected code-review operation and supported integration map that brief to the permitted request and returned findings. The coding agent remains responsible for local edits, builds, tests, and the final acceptance decision.

Keep review and test execution separate

Many bounded review units can preserve the frontier allowance when each unit has a clear source range, rubric, and deadline. The right question is whether the review overhead fits the deadline and evidence value, not whether the batch is only a huge flexible workload. Small independent units can fit when the repeated check is more useful than local serial review.

Lithi returns source-linked findings, hypotheses, conflicts, missing evidence or reviewable repair suggestions. It does not edit your repository, choose a winner or execute your code. Your agent builds and runs tests in your authorized development environment, then can ask Lithi to review the recorded evidence. Native builds, tests, browser tests and release operations are outside customer Compute.

Reviewing existing candidate outputs is also different from generating candidates or testing a model. A comparison can inspect outputs already supplied in the packet; generation and model testing require their own operation, input contract, and evidence.

Freeze the evidence and request

1. Record the source revision and digest, changed files, callers, types, schemas, and existing test evidence.
2. Define the review rubric and each independent concern with its file or source range.
3. For debugging analysis, include fixed logs, errors, relevant source, known-good behavior and existing test output.
4. For recorded test evidence, include target, environment, selected cases, toolchain, executed and skipped counts, exit state and artifacts. These identify a customer-run test; they do not ask Lithi to execute it.
5. Freeze the output contract and request identity. Obtain the applicable approval before transferring the permitted packet and requesting its analysis.

Lithi groups and assigns suitable work within the approved scope. The result does not modify source silently. The existing agent keeps decisions, local edits, and tests in the customer environment.

Inspect what the evidence proves

These expectations are illustrative, not a recorded run or universal report schema. A report with zero executed tests is not a passing suite. A test report does not prove signing, publication, or customer availability.

Keep source paths and hashes, findings, uncertainty, conflicts, missing coverage, evidence locators, executed and skipped counts, exit state, logs, and artifacts. A review that returns no findings is not a passing test run. Keep original findings when a repair and retest produce new evidence.

Worked example

Return a source-linked finding

Review this complete synthetic TypeScript source, firstLength.ts, version A, with its caller and existing test evidence:

export function firstLength(values: string[]): number {
  return values[0].length;
}

Return a finding linked to line 2: the empty-array path dereferences an absent value. State the supporting source, the hypothesis, the missing check, and a reviewable repair suggestion. An array containing "hi" is expected to return 2; an empty array needs a caller decision or an explicit failure contract. These are hypotheses to verify, not executed failures.

If a runner is unavailable, record unavailable execution. If only artifact delivery fails, recover the accepted artifact instead of rerunning tests. The customer decides whether to apply a suggestion and runs local edits and tests through the authorized development workflow.

Compare published prices

You can see what it costs to run these jobs on different AI models at batch prices, using each provider's published list price on the same token counts. These tables compare published prices for the same work, not output quality.

Review 10,000 code changes. Each change is an 8,000-token packet with its diff, callers, types and tests, and you get a 1,000-token report back.

Published list prices checked 5 October 2026.

Each provider counts tokens with its own tokenizer, so the same text can be a different number of tokens. Rows without a note apply each published rate to the same token counts. These tables compare published prices for the same work, not output quality.

Debug 5,000 failing tests. Each failing test goes in with its log and the code it touches, 9,600 tokens in, and you get a 1,200-token report with the likely cause and a suggested fix.

Published list prices checked 5 October 2026.

Each provider counts tokens with its own tokenizer, so the same text can be a different number of tokens. Rows without a note apply each published rate to the same token counts. These tables compare published prices for the same work, not output quality.

Map 2,000 modules. Each module is read once, 9,600 tokens in, and returns a 1,200-token summary so your coding agent can plan from short reports.

Published list prices checked 5 October 2026.

Each provider counts tokens with its own tokenizer, so the same text can be a different number of tokens. Rows without a note apply each published rate to the same token counts. These tables compare published prices for the same work, not output quality.

Use Data & Evaluation when candidate outputs and rubrics are the subject, and Apple ML when a qualified model asset needs typed validation. Use receipt and provenance review before using retained artifacts in a release decision.