Projects

A project is a named container for a body of work: the documents it involves, the instructions you want followed while you work on it, and the chats you have about it. Every chat inside a project starts with that context already in place — you don’t attach the same files again, and you don’t re-explain the ground rules.

It’s the difference between “here’s a file, now answer” and “here’s the thing we’re working on.” A project can hold a handful of reference documents — or an entire codebase you dropped in as a zip.

Creating a project

Projects live in their own section of the sidebar. Click the + beside Projects, type a name, and Catalyst creates it and opens its page. On that page you can click the title or the description to edit them in place; open the project again any time from the sidebar.

Instructions and documents

Two things make a project more than a folder.

Instructions are standing guidance — “Added to every chat in this project.” Use them for the rules that should hold across the whole body of work: the audience, the conventions, how you want answers shaped (“always answer with citations from the attached documents”). They apply to new and existing chats in the project alike.

Documents are the files the project is about. Drop them on the upload area or click to pick them.

Catalyst handles them the same way prompts handle their knowledge base:

• Small documents are included in full, so they’re always in view.
• Large documents are split into chunks and embedded, then recalled by meaning when a question touches them — a long report costs you nothing on the questions it doesn’t touch.

A project holds up to 2000 files and 50 MB in total, with a 15 MB cap on any single file you upload directly. The counter above the upload area shows where you are.

Chats in a project

1. Start one in place. New chat in this project (top right of the project page) opens a fresh chat already attached to it.

2. Or move an existing one. Open a chat’s ⋯ menu — in the sidebar’s session list or on the All chats page — and choose Move to project…, then pick the project. The same picker has Remove from project when a chat is already in one.

A chat that belongs to a project shows the project’s name beside its title in the header, and the project page lists its chats at the bottom. Deleting a project deletes its documents but keeps the chats — they simply leave the project.

Add a whole project (zip)

Drop a .zip onto a project’s Documents area and Catalyst unpacks it into a folder named after the archive — ReactCam-main.zip becomes a ReactCam-main/ folder the assistant can browse. This is how you hand over a codebase, an export, or any tree of files instead of uploading them one at a time.

When the unpack finishes you get a summary of what landed and what didn’t:

The folder then appears in the Documents list as a tree you can expand, with per-folder file counts and sizes:

What gets left out

Unpacking is deliberately selective — a repository is mostly noise to a language model, and some of it you actively don’t want uploaded. Catalyst drops:

• Version control, dependency and build directories — .git, node_modules, __pycache__, .venv, Pods, DerivedData, dist, build, target, .next, coverage, and the rest of the usual suspects.
• Secrets — .env files, private keys, certificates and keystores (.pem, .key, .p12, .jks, id_rsa…), and credential files like .npmrc or service-account.json. Templates are kept, so .env.example still comes through.
• Binaries and media — images, video, audio, fonts, archives, compiled objects. PDFs, Office documents and spreadsheets are not treated as binaries; those come through.
• Empty files, symlinks, and anything larger than 2 MB inside the archive.

The rest lands in the folder. Files that read as documents — Markdown, text, PDF, Word, PowerPoint and friends — are also indexed for recall by meaning, exactly like any other project document. Everything else, including all source code, is stored for reading and searching and carries a source badge: it isn’t embedded, and it isn’t dumped into the model’s context. The assistant goes and gets it when it needs it.

Limits

• 2000 files and 50 MB per project, counting everything in it.
• A single zip up to 50 MB.
• Files over 2 MB inside a zip are skipped.

If an archive would blow past the caps, Catalyst unpacks what fits and says so in the summary.

How the assistant reads it

The model gets a files tool with three actions:

• list — the folder tree, or one folder at a time.
• read — one file, with line numbers, paged automatically when it’s long.
• search — a regular-expression grep across the tree, narrowable to a folder and to a file pattern like *.swift.

In the transcript these show up as Files tool blocks with a folder-tree icon, each labelled with what it actually did — a path with a line range for a read, a /pattern/ (plus the folder and glob it was narrowed to) for a search:

That’s the whole point of the workspace: asked “where does this app decide which model to use by default?”, the assistant searched for likely names, opened the files that matched, and answered with real paths and line numbers — reading a dozen-odd files out of a hundred rather than swallowing the repository whole.

The same tree is also mounted read only inside the Python sandbox at ./project_inputs/, so in agentic mode the model can run code against the files as well as read them. It’s told to reach for files first and read only what it needs, rather than unpacking and printing the tree in Python.

Tips

• Zip the folder, not its contents — the archive’s name becomes the folder’s name. On GitHub, Code → Download ZIP gives you exactly the right shape.
• Re-uploading a zip with the same name replaces that folder, so refreshing a snapshot is just uploading again. The summary tells you when it replaced something.
• Delete a folder with the trash action on its row — it removes the whole subtree in one go.
• Point at it in your question. “Where is X handled?” works far better than “read this codebase”; the tool is a scalpel, not a firehose.

Also in a single chat

You don’t need a project to do this. Drop a .zip into the composer’s attach control and it’s unpacked into that conversation’s files, where the same files tool works on it — see Files & data in chat. A project is the right home when the same tree should back many chats. The files tool is a chat tool; workflows take their inputs through file & image inputs instead.

Projects, prompts, and memory

• Projects — a body of work: documents plus instructions, shared by every chat inside.
• Prompts — a reusable setup you select for a conversation: instruction, knowledge base, data, and tools.
• Memory — what the model knows about you, everywhere.