How Syntic Code works

Syntic Code is an agent that works inside your project. You describe an outcome, and it reads code, edits files and runs commands until the job is done or it needs you. This page explains what happens between pressing Enter and getting an answer, so you can predict how it behaves and steer it well.

The loop behind every message

Each message you send starts a loop. The model reads the conversation, decides on a next step, and either answers you or calls a tool. Syntic Code runs the tool on your machine, hands the result back to the model, and the model decides again. That repeats until the model has nothing left to do.

A typical bug fix might go like this:

1. Gather. Grep for the error text, Read the files involved, check git status.
2. Change. Edit the faulty function, Write a new test.
3. Verify. Run the test suite with Bash, read the failures, adjust.
4. Report. Summarize what changed and anything left open.

Nothing forces that order. A question about the code may only need step 1; a refactor may loop through steps 2 and 3 many times. You can stop a running turn at any point with Esc, then add a correction and send again.

Models

The thinking is done by a Syntic model served from the Syntic platform. The list of models you can pick from comes from the platform and depends on your plan; /model shows it. Some models reason longer before acting; /effort changes how much reasoning each step gets. See Models & reasoning.

Helper jobs, such as naming a session or checking whether a goal is met, run on a smaller, cheaper model so they do not slow down the main conversation.

Tools

Tools are what turn a chat into an agent. The built-in set covers:

MCP servers, skills and plugins add more. The tools reference lists every built-in tool.

What the agent can see

When you start syntic in a folder, the agent works in that folder and below it. It can:

• read and search any file there (plus folders you add with --add-dir or /add-dir);
• run commands in your shell, with your environment and your tools on the PATH;
• see git state: branch, changes, recent commits;
• load your instruction files: SYNTIC.md, rules files and your personal ~/.syntic/SYNTIC.md (Memory);
• reach outside systems you connect through MCP.

It does not see your whole disk up front. It looks at what the task needs, the same way a new teammate would.

Where it runs

The CLI is the main way to use Syntic Code today:

Other surfaces are listed on Platforms and integrations.

Sessions

Every conversation is saved as a session on your computer, so you can come back to it:

• syntic -c continues the latest session in this folder.
• syntic --resume (or /resume) lets you pick an older one.
• /branch copies the conversation into a new session, so you can try another direction without losing the first.

Sessions belong to the folder you started in. Two terminals in the same folder are two separate sessions. See Sessions and resume.

The context window

Everything the model knows during a session lives in its context window: your messages, its replies, file contents it read, command output, instruction files and tool descriptions. The window has a fixed size. When it fills up, Syntic Code compacts the conversation: older parts are replaced by a summary so the work can continue.

/context shows what is using the space. Long sessions full of unrelated topics fill the window faster and get worse answers, so start a new session (/clear) when you switch tasks. Details are on The context window.

Safety nets

Permissions

Before a tool changes something or runs a command, Syntic Code checks your permission rules. Anything not already allowed is shown to you as a prompt: allow once, allow for the rest of the session, or refuse. Press Shift+Tab to cycle the permission mode: ask as usual, accept file edits without asking, plan only (read and propose, change nothing), or auto mode, where a reviewer approves routine actions and still stops risky ones. See Permission modes.

A folder you open for the first time is not trusted until you say so. Until then, the project’s own settings, hooks and MCP servers stay off (Folder trust).

Read before edit

The agent must read a file in the current session before it may change it, and it refuses to overwrite a file that changed on disk after it last read it. This stops it from clobbering edits you made in your editor while it was working.

Checkpoints

Every file edit is backed up before it happens. With an empty prompt, press Esc twice (or run /rewind) to go back to an earlier message and restore the conversation, the files, or both. See Checkpointing.

Working well with it

• Talk to it like a colleague. Plain sentences work. Say what you want and how you will know it is done: “the import command gets a --dry-run flag, and the tests pass”.
• Give it a way to check. A test command, a build, a screenshot to compare against. Work it can verify is work it gets right more often.
• Correct early. If it heads the wrong way, press Esc and say so. Interrupting costs nothing; a long detour costs time and context.
• Ask it about itself. “How do I add an MCP server?” or “what does /goal do?” are fair questions. A built-in guide agent answers questions about Syntic Code.
• Delegate, then review. For anything big, ask for a plan first (Shift+Tab into plan mode, or /plan), agree on it, then let it work.

More habits are on Best practices.

Next steps

• Ways to extend Syntic Code
• The .syntic folder
• Common workflows