For AI teams
Run training, fine-tuning, inference, and evaluation without operating a fleet. One key, one project, one bill.
The TDCC App is the console, CLI, and API for the compute network. Submit a job, watch it run on matched hardware, verify the result, and pay only for work that is accepted.
job_8fq2c1finetune.loraRunningjob_8fq1zainference.batchVerifiedjob_8fq0m7embeddingsVerifiedjob_8fpz44eval.suiteMatchingBuilt to route across mixed capacity
What the app is
Underneath the app there are schedulers, secure runtimes, model compatibility checks, verification policies, reputation signals, and settlement. In the app there is a job, a state, and a receipt.
Run training, fine-tuning, inference, and evaluation without operating a fleet. One key, one project, one bill.
Turn idle capacity into recurring, screened demand. Publish hardware, availability, and price; earn on accepted work.
A machine-callable API so autonomous workflows can buy compute the same way a developer does.
The console
The network view shows where work is running right now: which region, which hardware class, how far along, and what still needs to be verified.
Submit
You never browse a list of instances. You state what the workload needs and what you are willing to pay, and the router does the rest — including failover when a host drops mid-run.
finetune.loraValidqwen2.5-7bCompatible48 GB41 hosts4hFeasible$120.00EstimateObserve
Every job streams state. You see the stage it is in, the host class running it, throughput, retries, and logs — without SSH, without a bastion, without a separate monitoring stack.
eu-central · 1× 80GBDoneruntime img · sha 4c9a…Donestep 1840 / 300061%2 passes queuedPending14:02:11 loss 1.284 lr 1.4e-4 tok/s 5,910 14:02:38 loss 1.241 lr 1.4e-4 tok/s 6,042 14:03:05 checkpoint written adapter-1840.safetensors 14:03:06 budget used $38.40 / $120.00
Verify & settle
Verification is the product. Each completed job carries an acceptance record: what ran, where, against which criteria, and what was paid out. Work that fails the check is not billed to you and is not paid to the host.
inference.batch · llama-3.1-8b-instruct1,240 / 1,240host_9d21 · eu-central · 80GBschema_valid ∧ 2/2 verification passes2026-07-27T14:38:02ZWhy an app, not a marketplace
Renting a machine transfers every risk to you: wrong hardware, a stalled run, a silent failure at hour six. The TDCC App moves that risk to the network. The unit you buy is a verified result.
Rejected and requeued work sits outside the billing ring by design.
Workload catalogue
Each workload type carries its own acceptance rules, so verification means something different for a transcription batch than it does for a fine-tune.
| Workload | API type | Typical hardware | Acceptance basis | Status |
|---|---|---|---|---|
| Batch inference | inference.batch | 24–80GB | Schema validity + redundant sampling | v1.0 |
| Open-model hosting | inference.endpoint | 48–80GB | Health checks + latency SLO | v1.0 |
| Embeddings | embeddings | 24GB+ | Deterministic re-computation on a sample | v1.0 |
| Audio transcription | transcribe | 24GB+ | Sampled re-run + agreement threshold | v1.0 |
| Image generation | image.generate | 24–48GB | Output integrity + policy checks | v1.0 |
| LoRA / QLoRA fine-tuning | finetune.lora | 48–80GB | Eval delta on a held-out set | v1.0 |
| Evaluations | eval.suite | 24GB+ | Reproducible scoring run | v1.0 |
| Synthetic data | synth.generate | 24GB+ | Schema + duplication checks | v1.0 |
| Agent workloads | agent.run | Mixed | Step traces + budget ceilings | Planned |
| Full pre-training | train.full | Multi-node clusters | Checkpoint continuity + eval gates | Planned |
Bring your own environment
Jobs execute inside approved, isolated runtimes. Supply a container, pick a maintained base image, or point at an open-weight model and let the app assemble the environment.
Developer surface
The console, the CLI, the SDKs, and the REST API all speak the same object: a job with constraints, a state machine, and a receipt. Whatever you automate in one, you can inspect in another.
# submit a batch inference job curl https://api.decentralizedcompute.company/v1/jobs \ -H "Authorization: Bearer $TDCC_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "type": "inference.batch", "model": "llama-3.1-8b-instruct", "input_uri": "s3://acme-eval/prompts.jsonl", "accept": { "min_verifications": 2 }, "budget": { "max_usd": 40 } }'
from tdcc import Client client = Client(api_key=os.environ["TDCC_API_KEY"]) job = client.jobs.create( type="finetune.lora", base_model="qwen2.5-7b", dataset="tdcc://datasets/support-tickets", hardware={"min_vram_gb": 48}, budget={"max_usd": 120}, ) client.jobs.wait(job.id) print(job.receipt.status, job.artifacts[0].uri)
import { TDCC } from "@tdcc/sdk"; const tdcc = new TDCC({ apiKey: process.env.TDCC_API_KEY }); const job = await tdcc.jobs.create({ type: "embeddings", model: "bge-large-en-v1.5", inputs: docs.map((d) => d.text), accept: { minVerifications: 2 }, }); for await (const ev of tdcc.jobs.stream(job.id)) { console.log(ev.stage, ev.progress); }
# authenticate once per machine tdcc login # submit and follow tdcc jobs submit ./job.yaml --watch tdcc jobs logs job_8fq2c1 --follow # inspect capacity and proof of work tdcc hosts list --region eu-central --min-vram 48 tdcc receipts show job_8fq1za --verify
Preview interfaces from the early-access build. Request shapes may change before the API is declared stable.
App specifications
Everything below describes the version 1.0 early-access scope. Items marked Planned are on the release path and are not available yet.
| Product name | TDCC App — console, CLI, SDKs, and job API for The Decentralized Compute Company network |
| Version | 1.0, staged early access alongside the pilot network |
| Console | Responsive web app; current Chromium, Firefox, and Safari; desktop-first layout with a mobile job view |
| CLI | tdcc for macOS (Intel/Apple silicon), Linux x86-64 and arm64, and Windows via WSL2 |
| SDKs | Python 3.10+ and TypeScript / Node 18+; both wrap the same REST surface |
| API | REST over HTTPS, JSON payloads, cursor pagination, idempotency keys on job creation |
| Events | Server-sent events per job; per-project webhooks with signed payloads |
| Authentication | Project-scoped API keys with rotation; console sign-in per organization. SSO and SCIM Planned |
| Roles | Owner, admin, developer, read-only; keys inherit project scope, never organization scope |
| Isolation | Jobs run in approved, isolated runtimes on screened hosts; images are pinned by digest |
| Data handling | Encrypted transport; artifacts scoped to the submitting project; customer job data is not used to train TDCC models |
| Verification | Per-workload acceptance criteria, redundant or sampled passes, reputation updated from verified outcomes |
| Failure policy | Stalled or failed executions are requeued to another host; unaccepted work is neither billed nor paid out |
| Billing unit | Accepted job. Usage metering, budget ceilings per job, and per-project spend reports |
| Settlement | Off-chain payouts at launch; optional on-chain settlement records via Avalanche and Solana integrations Planned |
| Regions | Routing across connected data centers and host regions; explicit region pinning Planned |
| Quotas | Per-cohort concurrency and spend limits during early access; raised on request |
| Observability | Live stage timeline, streaming logs, per-job cost accrual, exportable receipts |
| Support | Direct founder contact during early access; documented escalation path at general availability |
Release plan
The app ships in cohorts so that routing, verification, and settlement are proven on real workloads before the network widens.
A small set of AI teams and host operators run real jobs against the console and API. Workload schemas, acceptance criteria, and host requirements are hardened against their feedback.
Console, CLI, Python and TypeScript SDKs, and the job API become available to accepted early-access teams. Inference, embeddings, transcription, image generation, evaluations, and LoRA fine-tuning are in scope with measured service levels.
Additional data centers and qualified GPU operators are onboarded. Region pinning, reputation-weighted routing, alerting, and dry-run cost estimates land in the app.
Stable API versioning, organization SSO, automated settlement, agent workloads, multi-node training, and enterprise controls for sustained production use.
App FAQ
Not to everyone. It is rolling out in staged early-access cohorts alongside the pilot network. Request access below and you will be placed in the next opening.
No. You describe the workload, its constraints, and your budget. The router picks capacity that fits. If you do need specific hardware, you can constrain the class, memory, or region and the router will only match hosts that satisfy it.
The job is requeued to another eligible host. You are not billed for the failed attempt, and the failed host is not paid for it.
Deterministic workloads such as embeddings can be re-computed on a sample and compared exactly. Generative workloads rely on schema checks, redundant passes, and agreement thresholds. Fine-tunes are judged on evaluation deltas against a held-out set. The criteria travel with the job.
No. Job inputs and artifacts are scoped to the submitting project and are not used to train TDCC models.
No. The compute layer is chain-agnostic and the app works with ordinary accounts and billing. On-chain settlement records through Avalanche and Solana are an optional integration path, not a requirement.
Yes. Data centers, micro-cluster operators, and independent GPU owners can register hardware, availability, and pricing, then earn on accepted work. Host onboarding is reviewed manually during early access.
Early access
Tell us what you want to run — inference volume, a fine-tune, an evaluation suite — or what capacity you can contribute. Early-access cohorts are reviewed by hand.