---
title: The code workspace in guest mode
description: How the code workspace behaves in signed-out chats, and the rate limits that apply.
tags:
  - sandbox
  - guest
  - limits
  - rate-limit
---

You can use the platform without an account, and anonymous ("guest") chats can still run code in the [code workspace](/docs/sandbox). Guest sessions run through a separate, isolated proxy path that keeps them rate-limited and credential-scoped, so they are a lower-privilege slice of the full experience rather than a full account. This page explains what changes when you are not signed in and why some things are throttled. To lift the limits, [sign in](/docs/getting-started).

## How guest workspaces are isolated

Guest workspace requests route through a dedicated guest proxy instead of the direct tunnel that authenticated sessions use. That proxy:

- Runs the workspace against a **guest-scoped session** keyed to an anonymous guest ID and the chat, so guest work is isolated from other guests and from signed-in users.
- Requires a valid guest ID on every call.
- Applies per-guest **burst limits** to workspace runs, on top of the create limits below.
- Allows a **smaller set of operations**: shell commands, Python, R and notebooks; reading, editing, listing and saving files; installing extra packages; and fetching public data or repositories. Octave, starting compute jobs from workspace code, multi-step hand-offs, lab-automation protocols and native figure rendering (gnuplot, Circos) need a signed-in account.

## The create rate limit

The most visible guest limit is on **starting a workspace**. Each guest chat has a cap on workspace starts within a 10-minute window, and each guest client has a daily cap across chats. When a start is refused, the server returns a retry-after time, and the chat cannot run code for 10 minutes. Ivy tells you the workspace is temporarily unavailable instead of failing silently.

This is why a guest chat whose workspace keeps stopping and restarting can stall: each cold start counts against the cap. Signed-in sessions do not have this cooldown.

## What still works

Guest workspaces support the core interactive workflow — running shell commands and Python, reading and listing files, and saving results — which covers most analysis a guest chat will ask for. The limits you will actually feel are the create-rate cooldown above and the ephemeral nature of the session: guest work is not tied to a persistent account, so there is no long-term job history or durable project storage the way a signed-in account has.

> **Signing in removes the friction**

> An authenticated session drops the guest cooldown, connects the workspace to your persistent job history and projects, and gives you the full workspace lifecycle described in the [overview](/docs/sandbox).

## Read next