You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Your custom service must implement the expected OAuth2 client‑credentials flow and provide JSON endpoints
94
94
for listing models, obtaining completions, and fetching tokens as used by `CustomLLMService`.
95
95
96
+
#### Optional provider threads (conversation IDs)
97
+
98
+
For deployments using a custom LLM service, you can enable provider‑side threads to cache context between turns. This is optional and disabled by default. When enabled, the LMS/XBlock remains the canonical chat history as that ensures vendor flexibility and continuity; provider threads are treated as a cache.
99
+
100
+
- Site configuration (under `ai_eval`):
101
+
- `PROVIDER_SUPPORTS_THREADS`: boolean, default `false`. When `true`, `CustomLLMService` attempts to reuse a provider conversation ID.
102
+
- XBlock user state (managed automatically):
103
+
- `thread_map`: a dictionary mapping `tag -> conversation_id`, where `tag = provider:model:prompt_hash`. This allows multiple concurrent provider threads per learner per XBlock, one per distinct prompt/model context.
104
+
105
+
Reset clears `thread_map`. If a provider ignores threads, behavior remains stateless.
106
+
107
+
Compatibility and fallback
108
+
- Not all vendors/models support `conversation_id`. The default service path (via LiteLLM chat completions) does not use provider threads; calls remain stateless.
109
+
- If threads are unsupported or ignored by a provider, the code still works and behaves statelessly.
110
+
- With a custom provider that supports threads, the first turn sends full context and later turns send only the latest user input along with the cached `conversation_id`.
111
+
96
112
### Custom Code Execution Service (advanced)
97
113
98
114
The Coding XBlock can route code execution to a third‑party service instead of Judge0. The service is expected to be asynchronous, exposing a submit endpoint that returns a submission identifier, and a results endpoint that returns the execution result when available. Configure this via Django settings:
0 commit comments