Long conversations & context limits
A conversation can grow far beyond the amount of text a model should receive in one request. Starfire therefore has to balance conversation history, attachments, Project context, Knowledge retrieval, tools, and output space inside the active model’s context budget.
Context is finite
A model’s published context window is not equal to “all prior messages plus unlimited files.” Starfire also needs room for system instructions, tool definitions, retrieved material, and the model’s output.
What can happen in a very long chat
Depending on the active model and runtime, Starfire can need to:
- select the most relevant history
- summarize earlier material
- omit unrelated turns
- retrieve durable project context separately
- reject a request that cannot fit safely
Signs a conversation should be split
Start a new chat when:
- the task changes substantially
- the model keeps referencing stale decisions
- unrelated files have accumulated
- the conversation is used as a permanent project archive
- latency grows because every turn carries unnecessary history
Preserve important decisions
If an early conversation contains a durable architectural decision, move that information into Project instructions, Knowledge, or a project note instead of relying on that turn to remain in every future prompt.
Model changes
Switching to a model with a different context window can change how much prior context remains usable. Starfire should preserve the conversation object, but the new model can have different effective context limits.
Retrieval can help, but it is not memory of everything
Project and Knowledge retrieval can reintroduce relevant durable information even when the entire chat history cannot fit. Retrieval still depends on indexing, permissions, query relevance, and result limits.
Use long conversations for sustained discussion; use Projects and Knowledge for sustained work.
