Tokens are energy, not intelligence.

Two calls to reusable context.

Send stable source material to /v1/compress and get a persistent handle back, then activate that handle through /v1/context/run for task-specific prompts. Evaluate the handle on your own representative work and route production traffic only after your quality, safety, and operational requirements pass.

Quickstart

Two calls to your first answer.

Mint a scoped key in the developer console, then create a hosted context handle and activate it. Every request authenticates with Authorization: Bearer <key> and needs the compress:write scope.

export DISTIL_API_KEY="..."               # from /developers/keys
BASE="https://dev.primarydesignco.com/api/v1"

# 1 — Create a hosted context handle from stable, reusable source
curl -s "$BASE/compress" \
  -H "Authorization: Bearer $DISTIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "<your large, reusable source text>",
    "task": "Answer production rollout questions.",
    "rubric": ["preserve blockers", "preserve owners", "preserve dates"],
    "must_preserve": ["owners", "dates"]
  }'
# -> 200 { "data": { "context_handle": "ctx_...", "expires_at": "...", ... },
#          "usage": { ... } }

# 2 — Activate the handle for a task. Reuse the same handle across many runs.
curl -s "$BASE/context/run" \
  -H "Authorization: Bearer $DISTIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "context_handle": "ctx_...",
    "task": "What blocks the next rollout?",
    "output_contract": "Answer as a short bulleted list."
  }'
# -> 200 { "data": { "answer": "...", "context_handle": "ctx_...", "model": "..." },
#          "usage": { ... } }

# 3 — Delete a handle early (optional, no credit charge)
curl -s -X DELETE "$BASE/context/ctx_..." \
  -H "Authorization: Bearer $DISTIL_API_KEY"
Large sources are async. /v1/compress may return 202 Accepted with data.status_endpoint. Poll GET /v1/compress/jobs/{job_id} until data.status is "completed", then read data.context_handle.
Request fields

Exactly what each endpoint reads.

Only these fields are honored. Send the names below verbatim — unknown fields are ignored, not errors.

/v1/compressTypeNotes
textstringThe reusable source. Or send sources, images, audio, or video.
sourcesarrayMixed document, text, image, audio, or video source records.
documents / filesarrayConvenience arrays for document or text records.
imagesarrayImage assets or records used by the approved workflow.
audioarrayAudio assets or records used by the approved workflow.
videoobjectA video asset or record used by the approved workflow.
taskstringWhat the context is being prepared for. (request is also accepted.)
rubricstring | string[]Quality criteria the preprocessing must respect.
must_preservestring[]Exact facts that must survive preprocessing.
/v1/context/runTypeNotes
context_handlestringRequired. The ctx_… handle from /compress.
taskstringRequired. The task-specific question. (request and input are also accepted.)
output_contractstringOptional. Plain-language output shape, e.g. “Answer as a short bulleted list.”
stylestringOptional. Tone or voice guidance.
max_output_tokensnumberOptional. 256–6,000; default 1,600.
Field names: the run question is task (input also works); output_contract is a string, not an object; the compress quality list is rubric, not review_criteria.
Preparation controls: chunk sizing, output sizing, and execution mode are selected by Distil. Undocumented fields are ignored.
Errors

Every failure is { "error": { "type", "message" } }.

Retry 429 and 5xx with bounded exponential backoff. Do not retry 400, 401, 403, 404, or 422 unchanged.

Statuserror.typeMeaning
400invalid_request_errorMissing or invalid field (e.g. no task).
401authentication_errorMissing, invalid, or revoked API key.
403permission_errorKey lacks the compress:write scope.
404not_found_errorHandle or job not found for this exact key.
422disclosure_policy_errorTask tries to reveal or reconstruct the hosted context.
429rate_limit_errorPer-key rolling one-minute limit; honor Retry-After.
502 / 503upstream_error / service_unavailableTransient. Back off and retry.
Methodology

Build the smallest useful context.

Use Distil as a source-preparation layer. Define the job, preserve required facts, create a hosted context handle, then measure quality and cost against the raw-source baseline.

  1. Define the user-facing job: answer, brief, edit, classify, detect change, or match an item.
  2. Gather a bounded source package from customer-owned systems.
  3. Write a quality contract using task, review criteria, and must-preserve fields.
  4. Call the right Distil primitive and store only a hosted context handle.
  5. Run task-specific requests through the hosted context handle and return only the output needed by the workflow.
  6. Compare quality, cost, and retry rate against the raw-source baseline.
Endpoint selection

Start with the hosted-context primitive.

Send a bounded package to /v1/compress, then ask task-specific questions with /v1/context/run.

NeedEndpointTypical output
Shrink large text, code, docs, records, images, audio, or video assets/v1/compressHosted context handle and account-visible status
Run a task against hosted evidence/v1/context/runTask-specific output and measured usage
Large bundles may return 202 Accepted. Follow the returned public status until the run is complete. Status responses intentionally show coarse progress only.
Integration template

Scope the workflow in enough detail to ship.

Use this template to define the first production workflow, align stakeholders, prepare the source package, and measure whether Distil improves quality, cost, or throughput.

1. System classification

Choose the closest operating environment so the first workflow uses the right inputs and acceptance checks.

  • Retail commerce
  • Marketplace or social platform
  • Support or customer-success operation
  • Education or research workflow
  • Engineering system
  • Multimodal source-preparation workflow

2. Business outcome

Write the target outcome as a concrete, measurable job.

  • Improve product-page quality.
  • Reduce support handle time.
  • Summarize source-heavy research materials.
  • Prepare a safer software-change context.
  • Detect changing topic or sentiment signals.

3. source package definition

Define exactly what raw material enters the workflow. A useful source package should be bounded, repeatable, and mapped to the downstream job.

{
  "workflow": "priority SKU product-page improvement",
  "sources": [
    "catalog record",
    "recent reviews",
    "Q&A",
    "return reasons",
    "support snippets",
    "search queries",
    "optional product or shelf images"
  ],
  "refresh": "nightly or when review/return volume crosses threshold",
  "max_raw_tokens": 40000,
  "owner": "merchandising operations",
  "sensitive_fields_to_exclude": ["payment data", "private account identifiers"]
}

4. Endpoint sequence

Pick the smallest public sequence that supports the job. Distil performs source preparation inside the managed service.

  • /v1/compress: large source packages, including text, documents, images, audio, and video.
  • /v1/context/run: task-specific answers from a hosted context handle.

5. Request template

Use task-aware fields so the hosted context supports what the workflow actually needs. The public /v1/compress body accepts text and/or mixed sources; media normalization runs inside the managed Distil pipeline.

{
  "text": "<optional source notes>",
  "sources": [
    {"type": "document", "name": "policy.pdf", "text": "<document text>"},
    {"type": "image", "name": "shelf.jpg", "data": "<base64>"},
    {"type": "audio", "name": "call.m4a", "data": "<base64>"}
  ],
  "video": {"name": "walkthrough.mp4", "mime": "video/mp4", "data": "<base64>", "duration_seconds": 120},
  "task": "Prepare hosted context for the target workflow.",
  "rubric": [
    "Preserve required facts",
    "Separate source facts from interpretation",
    "Keep uncertainty visible"
  ],
  "must_preserve": [
    "policy limits",
    "citations",
    "return reasons",
    "failure messages",
    "customer commitments"
  ]
}

6. Hosted context contract

Define what a usable hosted context must support before another system relies on it. Customer applications store the handle and consume task-specific outputs.

  • Required facts and identifiers.
  • Source counts and time window.
  • Evidence examples or citation anchors.
  • Known uncertainty and missing material.
  • Downstream action or handoff shape.

7. Handle and refresh strategy

Reuse hosted context handles so the same source material is not processed repeatedly.

  • Store context_handle, expires_at, package version, workflow name, and review criteria version.
  • Handle key: workflow + package version + task/review criteria version.
  • Refresh on source change, time window, or business event.
  • Store raw source references separately from handle metadata.
  • Expire handles when policy, pricing, or source ownership changes.

Hosted context lifecycle and runtime contract

  • Access boundary: a handle can be run or deleted only by the same account and exact API key that created it. A replacement key cannot access prior handles; revoke the old key when rotating credentials.
  • Scopes: use compress:write for /v1/compress, /v1/context/run, and handle deletion.
  • Retention: handles are accessible for 365 days by default and return expires_at. Create a new version when sources or the quality contract change.
  • Deletion: DELETE /v1/context/{context_handle} removes a handle early at no credit charge.
  • Idempotency: every successful hosted-context request creates a new immutable handle. Keep a customer-side package version and review criteria version to avoid duplicate work.
  • Runtime: /v1/context/run runs the requested task against the hosted handle and reports account-visible usage.
  • Output: optional output_contract, style, and max_output_tokens fields control the task-specific output. Output tokens are bounded from 256 to 6,000 and default to 1,600.
  • Errors: retry 429 and 5xx responses with bounded exponential backoff. Do not retry validation, ownership, or expiration errors unchanged.

8. Downstream handoff

Specify where the task output goes after Distil: dashboard, automation, review queue, answer generator, or enterprise tool.

Handoff rules:
- Use the task output as the primary context.
- Do not invent missing facts.
- Preserve uncertainty labels.
- Escalate to raw source when exact wording, policy, legal, medical, financial,
  security, or high-impact details are required.

9. Output boundary

Define what the workflow should receive from each run. Keep the hosted context behind the handle and return only the task-specific evidence needed for the workflow.

Output rules:
- Do not return downloadable hosted context state.
- Return only task-necessary facts, uncertainty labels, citations, and actions.
- Reject requests that ask to reveal, decode, export, or reconstruct hosted context state.
- Log that output validation passed before delivery.

10. Quality contract

Quality is the gate. A smaller request only matters if the resulting workflow stays reliable enough for production.

{
  "required_checks": [
    "all must-preserve facts present",
    "no unsupported claims",
    "citations or source anchors preserved when available",
    "uncertainty is labeled",
    "output schema validates"
  ],
  "human_review": [
    "first 50 production cases",
    "all high-impact decisions",
    "all low-confidence recognition matches"
  ],
  "fallback": "use the customer-controlled raw-source baseline when the candidate fails the quality contract"
}

11. Cost scenario

Estimate value from the actual workflow, not a generic compression claim.

  • Package size and update cadence.
  • Expected activation pattern.
  • Monthly source packages.
  • Account-visible credits.
  • Repeated work avoided.
  • Review and operations cost.

12. Observability

Instrument the workflow from first request through downstream result.

  • Endpoint used first.
  • Credits consumed per workflow run.
  • Handle readiness and activation behavior.
  • Output validation pass/fail reason.
  • Validation pass/fail reason.
  • Fallback rate.
  • Human correction rate.

13. Security and privacy

Minimize source material before it enters any automated workflow.

  • Exclude payment secrets and private account identifiers.
  • Mask or remove fields not needed for the task.
  • Log request metadata, not raw source packages.
  • Restrict access to raw source fallbacks.
  • Define retention for hosted handles and customer-visible task outputs.

14. Enterprise operational readiness

Confirm the operating contract before production traffic begins.

  • Rate limits are per API key in a rolling one-minute window; isolate services with separate scoped keys.
  • Measure p50, p95, and p99 latency on the customer's own payload distribution.
  • Set alerting for 429, validation, service, and billing failures.
  • The public API does not include a contractual SLA, configurable data residency, or dedicated throughput commitment.
  • Document required region, support response, throughput, retention, and incident-reporting terms during enterprise onboarding.

15. Rollout plan

Expand only after the measured workflow improves.

  • Offline replay on historical examples.
  • Internal review dashboard.
  • Limited production cohort.
  • Automatic use for low-risk passing cases.
  • Continuous sampling against raw-source baseline.

16. Acceptance checklist

  • The source package is bounded and repeatable.
  • The endpoint sequence is minimal for the job.
  • The hosted context preserves required facts.
  • The downstream handoff labels uncertainty.
  • The handle key includes workflow, package version, and review criteria version.
  • Retention, deletion, key rotation, and duplicate-request behavior are tested.
  • The output boundary is validated before delivery.
  • The quality contract has deterministic checks and human review rules.
  • The cost model uses account-visible credits, downstream usage, and review cost.
  • The fallback path is tested before production launch.
  • SLA, residency, throughput, support, and incident terms are either accepted as public limitations or covered by an enterprise agreement.
Tip: the best first workflow is usually one with repeated large inputs, obvious human review cost, and a clear baseline answer or decision to compare against.
Ready to build

Reuse approved context without rebuilding it for every task.

Choose one source-heavy workflow, run a representative evaluation, then measure quality, latency, and cost against your raw-source baseline.

Start integration