KraytonProjects & memory
Group chats around a folder and keep durable instructions in the files your CLI reads. Provider memory and compaction differ; a saved chat does not guarantee every earlier detail stays active.
Learn more
Know your workspace.
Know its limits.
Krayton brings your coding agents into one desktop workspace. Here is what each feature does, what carries between agents, and what to expect as your work grows.
Guide updated · Desktop preview
01 / Start here
Your agents. Your accounts.
Install Krayton, sign in to an account with desktop access, and connect an installed, authenticated coding-agent CLI. Choose a project folder, select the agent and model available to your account, and send a task in the Agent tab.
Krayton provides the workspace. Model access, provider subscriptions, API charges and rate limits belong to the agent services you use. A Krayton subscription does not include those services or increase their quotas.
First time here? Follow the installation guide. Builds are in preview; check the download picker for your operating system and architecture.
03 / Agent & model switching
Change who works on the next turn.
Select an agent, one of its available models, and a supported reasoning effort. Finish or stop the current turn before changing your main chat's route. A split's route change applies to its next turn.
Access and capabilities follow the selected agent.
A model must be offered by the installed CLI and accessible to your provider account. Image handling, tools, reasoning levels, session resume and compaction vary by adapter and version. Selecting a model does not grant access to it.
A smaller model may receive less history. A new agent may need to read a handoff before answering; cached input from another provider is not portable, so switching can add latency and usage. Krayton does not impose a separate switch-count allowance; provider quotas and context limits still apply to each run.
When a switch fails: check the CLI login, model availability and provider quota. If a session is in use by another client, release its writer before retrying or use the continuation action offered by Krayton.
04 / Parallel work
Give each split a clear job.
Use /split to start a background task from the current chat. It inherits recorded context at creation and has its own session, model selection, follow-ups, Stop control and approvals. Open it in the docked panel or a floating window, then feed its result back into the parent conversation for a later turn.
Shared starting context is a snapshot.
Later parent messages do not continuously stream into every split. Manual splits default to a maximum of 10 running splits per parent chat; the setting allows 1–10. A manual split cannot create another manual split through /split.
For planned delegation, /subagents adds planning, worker stages and review. Its task count is Auto or 1–8. Independent stages run at most four at a time, reduced by a lower split setting. This workflow runs in local workspaces, with one workflow per project folder.
Splits normally share the parent's folder. Their file changes can overlap, and provider quotas, CPU and memory can become bottlenecks before the configured cap. Each worker uses its provider account's allowance.
A good split: “Review authentication and report findings; do not edit files.” Give editing tasks separate files or run them in order. Use a separate worktree chat when work needs its own checkout.
05 / Browser tab
Bring the live page into the task.
Open a website or your local development server in Krayton's Chromium browser. Use tabs, navigation, bookmarks and history; pick page text or elements and attach them to the docked agent's composer. Picks wait for you to press Send.
The visual editor lets you preview changes to supported text and styles, then send the queued changes to an agent to apply in the project.
A preview is not a saved source change.
Browser edits begin as live page overrides. The agent needs access to the actual project to update its source, and you still need to review, test and publish those changes. Login requirements, page structure and site restrictions can affect inspection and interaction.
Each browser workspace holds up to 16 tabs. At capacity, opening a tab can close an older inactive tab. The agent composer accepts up to 12 page picks, subject to a combined 8,000-character prompt budget. Large selections can hit that budget before the pick count.
For UI work: run your development server, open its local URL, select a few relevant elements, and describe the result you want. Check the page again after the agent changes the source.
06 / Code tab
Real terminals, side by side.
Create a layout with 1–8 terminal panes for agent CLIs and shells. Set folders per pane, resize or maximize panes, and keep sessions for different programs. Projects can retain up to six saved terminal layouts.
Terminal sessions have their own lifecycle.
An independent terminal is not automatically the same conversation as your Agent chat. Use Open in Code, where available, to continue a selected local chat's native session. A linked session needs its current writer released; return to Agent before resuming it there.
Independent Code-pane agent launches use permission bypass settings. Linked chat launches use the selected chat's mode. Review the launch mode before giving a terminal agent access to a project. Terminal output and history import depend on the CLI; some providers cannot expose all terminal activity back to the chat.
07 / Control
Choose the right permission mode.
Workspace tabs and permission modes are separate controls. In the Agent workspace, Chat, Code, Agent and Yolo settings map to the selected CLI's supported restrictions and approval behavior. Exact behavior depends on that adapter and CLI version.
- Chat: use for discussion with the adapter's restricted tool settings.
- Code and Agent: use the CLI's mapped execution and approval settings; respond to requests exposed in Krayton.
- Yolo: enables the CLI's permission bypass flags, allowing work without ordinary approval prompts.
A permission mode is not a guarantee of isolation from the rest of your computer. Use a project folder you trust, review changes, and keep credentials out of prompts and shared files.
08 / Around the conversation
Keep the project close.
Commands & skills
Type / for chat controls and exposed provider commands, or $ for skills from the selected CLI. Manage provider skills, plugins and rules through that CLI's configuration.
Changes & undo
Inspect recorded tool calls and file diffs. Undo is available where an edit has a captured before-image. It cannot reverse every shell command, deployment, database write or provider action. Keep Git commits and backups.
Git & worktrees
Inspect status, commit and push, or create a separate checkout for a chat. Worktrees require a Git repository. Applying work still needs review and can encounter conflicts; splits do not each receive one automatically.
Saved agent accounts
Keep separate sign-ins for supported agents and select the one to use. Account changes wait for that agent's active work to finish. Antigravity uses a shared system sign-in; separate saved Google accounts are not supported by its current adapter.
Files & attachments
Attach files or screenshots to describe a task. The main composer's drag-and-drop filter accepts files up to 50 MiB each; the selected provider can impose smaller input or image limits. Attaching a file does not guarantee the model can process its full contents.
Notes & feedback
Keep a task list with notes and screenshots in the rail. A note supports up to 2,000 characters and three images. The Report action opens a Gmail draft for support; you review and send it from your own account.
Voice input
The current microphone integration connects to a separately installed Voice to Text app on Linux. It needs that app and its configuration; it is not built-in transcription available on every operating system.
09 / Usage & availability
Know what your build exposes.
The usage dashboard groups reported tokens and runs by agent and model. Provider quota readings are shown where available. Missing usage stays incomplete; the provider's own billing and account pages are authoritative.
The current interface temporarily hides the Routines, Skills, Plugins and Commands app pages. Provider commands and the skill picker remain available in chats. A hidden app page does not remove your saved data or uninstall a provider's skills.
In builds that expose scheduled routines, the scheduler supports two concurrent runs and requires the app, account access and provider connection to remain available. It is not a hosted job runner. Routines use restricted Code or Chat modes, cannot select Yolo, and deny exposed unattended approval requests.
10 / Local storage
Local workspace. Connected services.
Krayton stores workspace chats, project references and settings on your device. The account service handles sign-in, subscription status and device licensing. Your selected agents send the content needed for their tasks to their own providers; websites opened in the Browser tab also make network requests.
Local storage does not make an online model work offline or provide a cloud backup of your workspace. Protect your device and back up the files and conversation data you need.
Read the Privacy Policy and safety and download guide for more detail.
11 / Quick reference
Limits at a glance.
These are workspace limits in the current implementation. Installed preview versions may differ. They do not replace your provider's context window, usage quota or model access rules.
| Feature | Limit | What it means |
|---|---|---|
| Active context | Provider & model dependent | Check the context meter when readings are available. Saved history can be longer than active context. |
| Agent / model switches | No separate switch-count cap | Each run still needs model access, available quota and a handoff that fits. |
| Inline history transfer | 200,000 characters | Structured history, not tokens. Larger local handoffs use a file; remote transfers over this limit stop. |
| Manual splits | 1–10 running per parent | Default 10; configurable. Follow-ups use each split's own session. |
| Planned sub-agents | 1–8 tasks; up to 4 at once | Lower split settings reduce concurrency. One local workflow per folder. |
| Browser tabs | 16 per browser workspace | An older inactive tab can close when you open another at capacity. |
| Browser page picks | 12; 8,000 characters combined | The serialized prompt budget can be reached before the pick count. |
| Code terminals | 1–8 panes per layout | Up to six saved layouts per project. More sessions need more system resources. |
| Scheduled routines | 2 concurrent where available | The Routines page is currently hidden. Builds that expose it need the desktop app running. |
12 / Common questions
Before your next task.
Will another agent remember absolutely everything?
It receives recorded history within the transfer budget, or resumes its own session and catches up. Older entries can be omitted, tool output shortened, and provider context compacted. Ask it to read the project files when an exact detail matters.
Does a split keep following the main conversation?
It starts from a snapshot and then has its own conversation. Send follow-ups to redirect it and feed its result back to the parent. Separate sessions normally still share the same project files.
Does the Browser editor publish my changes?
It previews changes on the live page and helps you ask an agent to update the source. Applying source changes and publishing the site are separate steps.
Are tokens or agent subscriptions included?
You bring your own agent accounts. Provider charges, quotas and available models are separate from Krayton access. Switching agents or adding workers does not make usage free.
Can I rely on undo for every action?
Undo covers captured file edits where supported. It does not roll back every action an agent or shell can take. Review the diff, run the relevant checks, and use Git or backups for recovery.