​
Overview

The /context slash command shows exactly what is occupying the agent’s context window in the current session. It applies the same pre-API transforms — compact boundary, context collapse, and microcompact — so the token count matches what the model actually sees, not the raw conversation history. Use /context when:
  • A session feels sluggish or starts losing earlier details
  • You want to verify how much of the window is consumed by tools, skills, memory, or agents
  • You need to decide whether to compact, fork, or start a new session
  • You are debugging why a long attachment or MCP server is not loaded
The command has two forms:

​
Basic usage

In an interactive session, type:
The TUI renders a grid where each block represents a slice of the context window, color-coded by category. In non-interactive mode, the same command prints a markdown report:

​
What the report shows

The output is split into several sections.
  • Model — the active main-loop model
  • Tokens — estimated tokens currently in context versus the model’s effective window
  • Percentage — share of the window consumed

​
Context strategy

When context collapse is enabled, a one-liner describes the current strategy:
This tells you that earlier conversation spans were summarized and replaced with <collapsed> placeholders, and that another span is queued for summarization.

​
Estimated usage by category

Categories include conversation history, system prompt, built-in and MCP tool definitions, custom agents, memory files, skills, and any autocompact or manual compact buffer.

​
MCP tools

Lists attached Model Context Protocol servers and the token cost of their exposed tools: Tools that exceed the available budget are marked as deferred and are not sent to the model.

​
Custom agents

Source can be Project, User, Local, Flag, Policy, Plugin, or Built-in.

​
Memory files

​
Skills

​
Message breakdown

A detailed breakdown of where conversation tokens come from: Plus top tools and attachments by token cost.

​
Understanding the colored grid

The interactive visualization divides the context window into squares. Each square is color-coded by category, and partially filled squares indicate categories that do not align cleanly with a single grid cell. Hovering is not required — the legend beneath the grid maps colors to categories and token counts. Colors are stable within a session, so you can run /context multiple times and watch a single category grow or shrink after compactions.

​
When numbers change

The token estimate updates immediately after:
  • A message is sent or received
  • A tool definition is loaded or deferred
  • A skill, agent, or memory file is added or removed
  • Context collapse summarizes a span
  • Autocompact or manual compact rewrites history
Because /context uses the same code path as the API request, its total should match the billed input tokens closely. Small differences are expected due to provider-specific tokenization and caching metadata.

​
Non-interactive output

When running through gizzi exec, /context returns the same data as markdown instead of Ink graphics:
This is useful for:
  • Logging context state in CI pipelines
  • Comparing token usage across sessions
  • Generating reports from headless runs

​
Prompt-cache countdown

After a cache-bearing response, Gizzi Code shows a separate cache row under its model/context footer. Desktop and the web/phone/PWA workspace show the same indicator beside the latest reply’s run telemetry. Existing custom status-line commands are preserved. The row updates every 30 seconds without sending a model request. Green means warm, amber means less than 20% of the TTL remains, and red means the estimated TTL has elapsed. The block bar shows time remaining. last hit is the share of the latest request’s input read from cache, not a session-wide hit rate. When cold, may re-cache shows the latest reported input footprint. Expiry is an estimate from the request TTL, not a guarantee that the provider still holds the cache. Changes to model, tools, or context may invalidate it earlier. Unknown provider TTLs have no countdown. Native requests with a known TTL currently use five-minute ephemeral markers; Gizzi’s interactive cache path uses its configured five-minute or one-hour TTL. No keepalive requests are sent. Miss counts and causes are omitted when not reported.