Performance and Stability

Syntic Code should feel responsive, and when it does not, the cause is usually identifiable. This page covers the common patterns — slow responses, sessions that hang, high memory use, and outright crashes — along with the checks that resolve them.

Slow responses

If Amara takes a long time to reply, the most common factor is the amount of context it is carrying. Very long sessions and very large files both cost time to process. Starting a fresh session for an unrelated task, and pointing Amara at specific files rather than whole directories, both help noticeably. Network latency to api.syntic.ai also matters; a slow or congested connection shows up as sluggish streaming. Rule out the network before assuming the CLI is at fault.

Hangs and stuck sessions

A session that stops making progress is often waiting on something — an approval prompt you have not answered, or a shell command that is itself blocked. Check whether Amara is asking for permission, and look at any command it launched to see if that command is hung. You can interrupt the current action and give Amara a new instruction rather than restarting the whole session. If the CLI itself is truly unresponsive, exit and resume the session with --continue to recover your context.

Memory use and crashes

High memory use usually tracks with session length and the size of the files in play. Long-lived sessions accumulate context, so ending and starting fresh at natural checkpoints keeps the footprint down. If the CLI crashes, first confirm you are on a current version, since stability fixes land regularly. Reproduce the crash with debug logging enabled so the failure is captured, then note the exact steps that trigger it. A reproducible crash with logs is far easier to diagnose than an intermittent one described from memory.