Compute
Use the .NET client
How the released .NET client is shaped: framework requirements, typed calls, cancellation tokens, and streamed results. The compatibility matrix states which of those are tested today.
Framework and package requirements
This page prints no package name and no framework version. Both move with each release, so both are published on the compatibility matrix instead.
Read your row there before you add a reference. It names the released package, its version, the target frameworks tested against it, and the protocol release that version speaks.
Your base URL and current API version appear in the portal under developer settings, and in the API description you download.
Make a typed call
The client mirrors the API namespaces, so a call site shows the authority it needs.
var quote = await client.Work.QuoteAsync(taskSpec, cancellationToken);
if (quote.State != JobState.Succeeded)
{
return Handle(quote.NextAction);
}
Your taskSpec carries the same seven objects everywhere: workflow, input, parameters, quality, policy, output and limits.
A quote is not authority. It comes back marked non_authorizing, with an expiry and a signature, and you approve as a separate act.
Pass a cancellation token
Where a released method accepts a cancellation token, the matrix says so. Do not assume every method takes one.
A cancellation token ends your call. It does not cancel the job, and the work keeps running.
Call the cancel operation when you mean to stop the work. The job moves to CANCELLING, then settles at CANCELLED, and work already accepted is charged under your applicable commercial policy.
Read a streamed result
Where the released client streams a bundle, it streams part files. Treat every part as incomplete until result-manifest.json is present, because the manifest is written last and is the only complete-bundle marker.
Read all four directories before you call a run clean. Accepted rows sit under data/, with failures/, abstentions/ and disagreements/ beside them.
Tabular output arrives with lithi_status, lithi_result, lithi_error_code, lithi_confidence, lithi_evidence, lithi_verification and lithi_usage appended.
Handle refusals separately
There is no single global error table. Every operation carries its own generated error_schema, and every refusal carries a safe reason with a non-empty next action.
Keep these four in separate branches:
EDGE_ABUSE_LIMITED— the perimeter is shedding load.CANONICAL_ADMISSION_LIMITED— the key or account is not authorized for that request.CANONICAL_BUDGET_EXHAUSTED— spend or reservation authority is exhausted.CELL_CAPACITY_UNAVAILABLE— current capacity is unavailable.
Two of them describe authority rather than load. Retrying those spends your time and changes nothing.
Confirm what your version supports
Terminal job states are SUCCEEDED, PARTIAL, FAILED and CANCELLED. Poll on the valid_until each response carries, not on an interval you picked.
If a feature you need is absent from your row, it is untested for that version rather than quietly available. Read your row on the compatibility matrix, then the released work API reference for the operation schemas.