of reasoningChatModel.ts and messageProcessor.ts in favor of
alternaitngMessageValidator.ts
- Removed src/lib/deepseekChat.ts as it was duplicative
- All functionality is now handled by reasoningChatModel.ts
- No imports or references to deepseekChat.ts found in codebase
- Removed src/utils/messageProcessor.ts as it was duplicative
- All functionality is now handled by alternatingMessaageValidator.ts
- No imports or references messageProcessor.ts found in codebase
the reasoning models using ReasoningChatModel Custom Class.
1. Added the STREAM_DELAY parameter to the sample.config.toml file:
[MODELS.DEEPSEEK]
API_KEY = ""
STREAM_DELAY = 20 # Milliseconds between token emissions for reasoning models (higher = slower, 0 = no delay)
2. Updated the Config interface in src/config.ts to include the new parameter:
DEEPSEEK: {
API_KEY: string;
STREAM_DELAY: number;
};
3. Added a getter function in src/config.ts to retrieve the configured value:
export const getDeepseekStreamDelay = () =>
loadConfig().MODELS.DEEPSEEK.STREAM_DELAY || 20; // Default to 20ms if not specified
Updated the deepseek.ts provider to use the configured stream delay:
const streamDelay = getDeepseekStreamDelay();
logger.debug(`Using stream delay of ${streamDelay}ms for ${model.id}`);
// Then using it in the model configuration
model: new ReasoningChatModel({
// ...other params
streamDelay
}),
4. This implementation provides several benefits:
-User-Configurable: Users can now adjust the stream delay without modifying code
-Descriptive Naming: The parameter name "STREAM_DELAY" clearly indicates its purpose
-Documented: The comment in the config file explains what the parameter does
-Fallback Default: If not specified, it defaults to 20ms
-Logging: Added debug logging to show the configured value when loading models
To adjust the stream delay, users can simply modify the STREAM_DELAY value in
their config.toml file. Higher values will slow down token generation
(making it easier to read in real-time), while lower values will speed it up.
Setting it to 0 will disable the delay entirely.
1. Search Functionality:
-Added a search box with search icon and "Search your threads..." placeholder
-Real-time filtering of threads as you type
-Clear button (X) when text is entered
2. Thread Count Display:
-Added "You have X threads in Perplexica" below the search box
-Only shows in normal mode (hidden during selection)
3. Multiple delete functionality:
-"Select" button in the top right below Search Box
-Checkboxes that appear on hover and when in selection mode
-Selection mode header showing count and actions
-When in selection mode, shows "X selected thread(s)" on the left
-Action buttons (Select all, Cancel, Delete Selected) on the right
-Disabled Delete Selected button when no threads are selected
-Confirmation dialog using the new BatchDeleteChats component
4. Terminology Update:
-Changed all instances of "chats" to "threads" throughout the interface
configurable delay feature.
1. Created AlternatingMessageValidator
(renamed from MessageProcessor):
-Focused on handling alternating message patterns
-Made it model-agnostic with configuration-driven approach
-Kept the core validation logic intact
2. Created ReasoningChatModel
(renamed from DeepSeekChat):
-Made it generic for any model with reasoning/thinking capabilities
-Added configurable streaming delay parameter (streamDelay)
-Implemented delay logic in the streaming process
3. Updated the DeepSeek provider:
-Now uses ReasoningChatModel for deepseek-reasoner with a 50ms delay
-Uses standard ChatOpenAI for deepseek-chat
-Added a clear distinction between models that need reasoning capabilities
Updated references in metaSearchAgent.ts:
4. Changed import from messageProcessor to alternatingMessageValidator
-Updated function calls to use the new validator
-The configurable delay implementation allows
to control the speed of token generation, which
can help with the issue you were seeing. The
delay is set to 20ms by default for the
deepseek-reasoner model, but you can adjust
his value in the deepseek.ts provider file
to find the optimal speed.
This refactoring maintains all the existing
functionality while making the code more
maintainable and future-proof. The separation of
concerns between message validation and model
implementation will make it easier to add support
for other models with similar requirements in the future.
