See this http://keepachangelog.com link for information on how we want this document formatted.
- Enhanced debug output for tool call events, including file search.
- Handle tool hallucination using helpful outputs.
- Use
process.env.DEBUG_PRETTY_JSON=1- To pretty format event JSON when usingDEBUG. - Use
process.env.DEBUG_EVENTS=0- Disable event logging when usingDEBUG.
Dual package approach.
New beforeAsk(message) callback for assistant.
Dual package approach.
Subpath imports. Please import or require only "experts".
Use dual package approach. Now supports both ES6 import syntax and CommonJS require statements.
Added another lifecycle hook, afterInit() Example use case, write out newly created Assistants' IDs to an environment file.
async afterInit() {
// ...
}Streaming support for buffered output added in v1.4.1.
New buffered output support for non-LLM tools. This allows a tool to add string data as part of the ask() response. However, this data is not submitted to tool outputs, hence is not seen by the parent. Useful for bespoke UI where an LLM assistant is formatting data for display.
See Bespoke UI Assistant test for a full example.
Default to GPT-4o mini. Reminder, you can use EXPERTS_DEFAULT_MODEL environment variable to set the default model.
Allow Assistants or Assistants as Tools to have OpenAI tools that can be invoked on your Run's behalf. Prior, there was a heavy bias that all tool calls were experts and this is not the case.
Now parentsTools can have multiple functions present. This should have worked all along but was overlooked. See changes around MyTool.toolName below.
No documented usage of MyTool.toolName. It is still used internally for a Tool's thread meta. The function is still available for use, but it is not recommended.
Caution
It is critical that your tool's function name be unique across its parent's entire set of tool names.
Major Assistant & Tool Constructor Changes
Both Assistant & Tool have removed their (name, description, instructions) ordinal parameters in favor of a single options object. Now, the constructor signature is:
// Using Assistant.create() factory.
//
assistant = new Assistant.craete({
name: "My Assistant",
instructions: "My Assistant Instructions",
...
});
// Or using ES6 Classes.
//
class MyAssistant extends Assistant {
constructor() {
super({
name: "My Assistant",
instructions: "My Assistant Instructions",
});
}
})A new skipUpdate option to use for deployments such as staging where it might be desirable to use the Assistant's remote resource instructions or other properties.
Names are no longer unique when assistants are created. This means the find/recreate by name is no longer needed. Recommend if deployments must track a fixed assistant to use the assistant id environment variable.
OpenAI now seems to validate the tool JSON when an Assistant is created. Fixed a bug in a test fixture where required was in the wrong place.
New Assistant run_options for all Runs created, ex: forcing a tool_choice. Alternatively, you can pass an options object to the ask method to be used for the current Run.
await assistant.ask("...", "thread_abc123", {
run: {
tool_choice: { type: "function", function: { name: "..." } },
additional_instructions: "...",
additional_messages: [...],
},
});All Run create options are supported.
https://platform.openai.com/docs/api-reference/runs/createRun
However, not all make sense with Experts.js.
- Assistant init updates configs after finding by name or id.
- Initial Release
- Modified
debugEventfunction insrc/helpers.jsto remove instructions from event data when logging in DEBUG mode, preventing large instruction strings from cluttering debug output.