> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Separate work with projects
description: >-
  Use projects or subaccounts to isolate keys, budgets, sources, destinations and cost
  allocation. Each project carries its own ceiling, so one team's spend never draws down
  another team's budget.
route: /docs/compute/configure/projects
page_id: docs-compute-configure-projects
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Organization administrators splitting Compute work across teams
voice: D
reader_question: How do I isolate one team's Compute work, keys, budget and costs from another's?
primary_action: Review spend and approval settings
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-configure-projects-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## Before you start

You need an organization with an administrator and an organization ceiling already in place. Projects divide what the organization holds; they do not replace it.

Decide what a project means to you first. The common choices are one project per team, one per product, or one per client engagement.

## What a project isolates

A project is the unit Compute isolates. Create, update, archive and read back each one like any other resource.

| Resource | Scoped to the project |
|---|---|
| Work keys | Yes — a key belongs to one project |
| Spend ceiling | Yes — checked before admission |
| Sources | Yes — registered per project |
| Destinations | Yes — registered per project |
| Cost allocation | Yes — spend reports by project |
| Organization ceiling | No — shared, and always the outer bound |

A project ceiling can only be narrower than the organization ceiling. Setting a higher project number does not widen the organization.

## Create a project

1. Inspect the existing projects, so you do not create a near-duplicate.
2. Plan the project with its name, its ceiling and its cost-allocation label.
3. Apply the plan and read the project back.
4. Mint one work key inside the project, and store its plaintext value at once.

A work key is bound to the project that issued it. Moving work between projects means issuing a new key, not editing the old one.

## Attach sources and destinations

Register the source the project's workflow reads, and the destination it writes to, inside the project.

Register a credential as a reference, never as a value you paste into a shared document. Compute stores the reference and resolves it at run time.

Test the source and the destination before the first real run. A failed write after a paid job is a delivery problem you then have to repair forward.

## Allocate cost

Give each project the cost-allocation label your finance team already uses. Matching your existing labels is what makes the export usable.

Statements and usage reports then split by project without anyone reconciling by hand. Read back the mapping once, and check it against one real statement line.

## Confirm success

The project reads back as `VERIFIED`, its ceiling is visible, and a status call with the project's work key succeeds.

Run one small job in the project and confirm it appears under that project's usage, not the organization default.

## When a project refuses a change

`CONFLICT` means the project moved since your plan was made, usually because someone else edited it. Inspect, replan and apply again.

Archiving a project does not delete its results or its receipts. Those stay readable so past spend remains explainable.

[Review spend and approval settings](/docs/compute/configure/spend-and-approvals)