Getting startedCore conceptsThe context window

Context & compaction

The model can only look at a limited amount of text at once: its context window. Everything in the session competes for that space: the built-in instructions, your SYNTIC.md files, the tool descriptions, every message and every tool result. Syntic Code’s default model has a 256K-token window. Each model’s window comes from the platform’s model list; if that list arrives after the session has started, the window (and when compaction starts) is adjusted at the next turn.

See what is using the space

Run /context. It shows how full the window is and what fills it, for example:

17.7k / 262.1k tokens
System prompt   2.8k
Memory            327
Conversation    ...
Tools & other   14.4k
Free              93%

Compaction

When the conversation fills up, Syntic Code compacts it: older messages are replaced by a summary, and the most recent messages are kept word for word. Work carries on without you doing anything.

You want toDo
Compact now (for example before switching to a new subtask)/compact (also /condense)
Change when automatic compaction starts/autocompact <size> for this model, or autoCompactThreshold (share of the window, default 0.8)
Turn automatic compaction off/autocompact off, "autoCompact": false, or SYNTIC_DISABLE_AUTO_COMPACT=1
Run a script before every compactionA PreCompact hook

A short conversation is not compacted: /compact answers “Nothing to compact yet” until there is enough to summarize.

Your task survives compaction

A summary alone can lose track of where the work stands. So every compaction also carries a task state block, built from the real project rather than from memory:

  • the objective you are working toward;
  • the git branch and commit;
  • the files that are modified, read from the working tree itself;
  • pending work and the next actions;
  • the tests that were run and any failures;
  • the permission mode in force.

If the summary and the working tree disagree (say, about which files changed), the tree wins. Memory files (SYNTIC.md and auto memory) are re-read after a compaction, so edits made to them during the session are not lost.

Compaction keeps the full history in the saved transcript. Only what the model sees is shortened, so you can still read or export everything.

Keep the window lean

  • Start new topics in a new conversation. /clear when you switch tasks; the old session stays resumable.
  • Hand big searches to a subagent. A subagent does the digging in a separate context and hands back a short report, so dozens of file reads never land in your main conversation.
  • Point at files directly. @path/to/file beats “find the file that does X” when you already know where it is.
  • Keep SYNTIC.md short. It loads every turn. Put area-specific notes in .syntic/rules/ files with a paths: filter so they only load when relevant (Memory).
  • Turn off what you do not use. Each MCP server adds tool descriptions. Disable a server for the session in /mcp, or a plugin in /plugin. /skill-doctor shows which skills cost context and went unused.

Tools load on demand

When many tools are connected (lots of MCP servers, for example), Syntic Code does not send every tool description up front. The model sees a short list and loads full descriptions with the ToolSearch tool when it needs them. ToolSearch only ever finds tools this session may actually use. Control this with ENABLE_TOOL_SEARCH (always, never, auto, or auto:N%; default auto:10%). An MCP server marked "alwaysLoad": true is always sent in full.

Not every model handles on-demand loading. Whether a model does is decided in this order:

  1. The model list from the Syntic platform, when it says so for that model.
  2. SYNTIC_TOOLSEARCH_DENY_MODELS, a comma-separated list of model names or * patterns.
  3. The toolSearch setting: {"disabledModels": ["Amara Deep", "amara*"]} sends every tool up front for those models.
  4. Otherwise it is on.

Big repositories

A step-by-step setup for monorepos is in the Large codebases guide. The short version:

  • Start Syntic Code in the folder you are working on, not the repository root, when the repo is huge. Instruction files from parent folders still load.
  • Use --add-dir (or /add-dir) to bring in just the extra folders you need.
  • Give each area of a monorepo its own SYNTIC.md; files in subfolders are loaded when the agent starts working there.
  • For very large codebases, a long-context model such as Amara S2 (1M tokens) may be offered on your plan; see Plans & models.

Prompt caching

Repeated parts of each request (instructions, tools, earlier messages) are cached by the Syntic platform, which makes follow-up turns faster and cheaper. By default the cache lasts five minutes between requests; "promptCacheTtl": "1h" keeps it for an hour. What keeps the cache warm, what breaks it and every related setting are on Prompt caching.

The .syntic folderPrompt caching