Jan System Prompt (where?)

[abitrolly]

When starting new chat, Jan prepends some text to the context for the loaded model, doesn't it? If so, where to find it?

I guess this prepended text is called "system prompt" and for cloud models users can not control it, but when people execute llama.cpp manually there is no system prompt. Am I right?

[wellkilo]

Jan does prepend system-level context, but there are two different paths in the current app.

Normal chat

The base prompt is the selected Assistant's instructions. The built-in Jan assistant is defined in useAssistant.ts, and you can inspect/edit an Assistant's instructions in the Assistant configuration UI rather than looking in the llama.cpp model files.

At send time, CustomChatTransport.buildSystemPrompt() combines:

1. the Assistant's instructions (systemMessage);
2. attached-file instructions;
3. Web Search instructions;
4. Agent Tools instructions.

That combined string is then passed as the system field to streamText() in the same file. So there is not necessarily one static prompt file containing the exact final text; some parts are assembled dynamically from the enabled features and thread context.

Cowork / agent mode

Cowork intentionally replaces the normal chat prompt. CoworkChatTransport.buildSystemPrompt() calls buildCoworkSystemPrompt(), which contains the Jan agent identity, behavioral guidelines, workspace/sandbox rules, and optional plan/Web/subagent blocks.

The native agent path has another builder in src-tauri/src/core/agent/context.rs. It starts with the Assistant instructions when present (otherwise a default Jan identity), then adds working-directory/runtime context, the skill/memory guide, JAN.md files, and available skills.

Local llama.cpp vs cloud models

Running llama.cpp locally does not imply “no system prompt.” Jan still sends the system-role content described above. llama.cpp then formats the role/message sequence using the model's chat template (normally metadata from the GGUF, unless model settings override the prompt template).

For a cloud provider, Jan also sends its system field through that provider adapter. The provider may apply additional server-side policy/instructions that are not part of this open-source repository and are not generally inspectable from Jan.

So the practical answer is:

• To change the normal user-controlled persona, edit the selected Assistant's instructions.
• To inspect Jan's built-in agent prompt, see web-app/src/lib/coworkPrompt.ts and src-tauri/src/core/agent/context.rs.
• Treat the GGUF chat template as message formatting, not as proof that no system message exists.

If this maps the prompt layers you were looking for, please mark it as the accepted answer.

[abitrolly]

An awesome answer. Do you use Jan to help with it? I am very interested to know your setup.

[wellkilo]

Thanks — glad it helped. For this answer I did not rely on a running Jan setup; I traced the current dev branch directly.

My workflow was roughly:

1. Locate the request boundary in CustomChatTransport.sendMessages().
2. Follow buildSystemPrompt() to see which blocks become the AI SDK's system argument.
3. Compare the normal chat transport with CoworkChatTransport, since Cowork overrides that method.
4. Check the native Rust agent path separately, especially context.rs, because it assembles project context, JAN.md, skills, and runtime information outside the web transport.
5. Trace the local llama.cpp adapter far enough to distinguish Jan's system message from the model's GGUF chat template.

I generally use an evidence-first repository-analysis setup: start from the actual entry point, follow the call chain, verify behavior against tests/comments, and explicitly separate confirmed behavior from provider-side details that the public repository cannot prove.

I have not settled on a personal Jan configuration yet, so I do not want to pretend I have a polished one to share. Once I test this workflow end to end in Jan, a small JAN.md focused on source-first investigation would probably be the useful artifact to publish.