Skip to main content
A session is one conversation with Kai Code about one task. Sessions live on the Kai Code page in the sidebar; press C for a new session and S for settings. The list on the left can be filtered to All sessions, Team or Private.

The composer

The new-session screen asks “What should Kai Code work on today?” Describe the task or ask a question and press Enter. Above and below the text field you control how the session runs:

Run on

Where the session executes. Kai Code Cloud uses AI credits; the Kai Code Bridge group lists every paired machine with its online state and, per machine, inline actions to Install or Sign in to a coding agent, Clone here or Locate… a repository. The choice is fixed once the first message is sent. The first time you open the composer, Kai Code asks where it should run and remembers your answer per browser. See Getting started.

Repositories and folders

Context chips name the repositories (cloud) or folders (Bridge) the session works in. Add repository opens the picker; on a ticket the chip starts as Repos: Auto and Kai detects the right repositories from the ticket when you send.

Model and effort

Two pills at the bottom right. The model pill lists the models available for the selected runtime — hosted models with their price per million tokens, models from your coding-agent subscription on a Bridge machine, and Local models. Reset to default returns to the project default. The effort pill sets how long the model may think before acting: Low, Medium, High, Extra high or Max, from Faster to Smarter. Higher effort handles hard problems better; every turn takes longer and costs more. Models without an effort setting hide the pill.

Plan and Build

The Agent picker chooses how Kai works:
  • Plan — Kai drafts a plan first; you review before building. New sessions start here.
  • Build — Kai edits code directly and opens pull requests.

Visibility

Sessions you start yourself are Private by default: only you can see them. Toggle the chip to make a session visible to your team. Sessions started from a ticket are always visible to the team.

Attachments, paste and voice

Attach images, PDFs and code files with the paperclip, or drop them anywhere on the page. Long pasted text becomes a file chip. The microphone dictates your prompt; hold-to-record and the input device are configurable from its menu.

Sending, queueing and steering

  • Enter sends. Shift + Enter inserts a newline.
  • While Kai is working, Enter queues the message for the next turn. ⌘ Enter (Ctrl Enter on Windows) sends it now and steers the running turn.
  • Queued messages appear above the composer; each can be edited, sent now or removed. The queue is shared with teammates and the mobile app.
  • Stop ends the current run.

Plan review

When Kai finishes a plan, the session waits for your decision. The Plan card shows the full plan; below it the composer asks “Implement this plan?” with Yes, implement this plan preselected, or No, and tell Kai what to do differently with a text field for your feedback. If the plan targets a repository the session does not have checked out on a Bridge machine, Kai offers Clone on device first.

Questions

Kai asks structured questions when it needs a decision: numbered options (press 1–9), an Other field for a free-text answer, and Skip. Answering resumes the turn.

While Kai works

  • Tasks — a live to-do list of what Kai is doing in the current turn.
  • Tool cards — every file read, edit, search and command as a one-line summary; expand for the code, the diff or the terminal output.
  • Changes (D) opens the diff of everything changed so far; Preview (Shift + P) opens the running app; Plan (P) reopens the plan; Ticket (T) jumps to the linked ticket.

Kai Verify

Kai Verify runs your app, clicks through the change and records what it sees. It needs a repository with a verified preview and runs on a Kai Code Bridge machine — cloud sessions link to Bridge setup instead. Choose Verify this change once Kai has changed something, or Verify after this turn while it is still working. A run goes through Set up the preview config → Start the app → Sign in → Click through the change → Fix the failed checks → Save the evidence. The first run in a repository writes .gleap/dev.yaml and opens a small preview config pull request; merge it so later sessions skip the setup. The result is a passed, failed or blocked card in the transcript and an evidence panel on the right: the screen recording, a screenshot grid, the list of checks with ✓/✗, and the history of earlier runs. When a login wall blocks the app, Kai asks you to sign in once on the device; the session is stored encrypted on that machine and can be forgotten under Settings → Kai Code Bridge → Saved app sign-ins. With Post results to the pull request enabled in Settings → General, the verdict and a commit status appear on the pull request. Evidence stays private to Gleap.

Pull requests

Every pull request Kai opens shows as a bar above the composer with its state (Open, Draft, Merged, Closed), number, repository, branch and the diff size, plus the Kai Verify verdict. On a Bridge session with uncommitted changes, Create PR commits and opens a pull request for every project with changes. A session that finishes without pushing shows No pull request and lists the unpushed work. Nothing is merged by Kai. You review and merge in your provider as usual; what happens on the ticket afterwards is configured under Customer replies.