Stardog Voicebox is a conversational AI chat interface for your Enterprise Data. This document provides instructions for using Voicebox within Launchpad.
Launchpad can operate with or without the Voicebox. To enable Voicebox, you'll need to run an additional Docker image (Voicebox Service) and provide its address to Launchpad. The two services communicate over HTTP.
Think Mode is powered by a multi-agent architecture and Voicebox 3, enabling chain-of-thought reasoning to handle complex, multi-step questions. When enabled, users will see a "Think Mode" button in the Voicebox input interface.
To enable Think Mode in your Launchpad deployment, add the following environment variable to your Launchpad configuration:
VOICEBOX_THREE_ENABLED=trueImportant
Think Mode requires Voicebox Service version v0.22.0+ and Stardog version v11.2.0+. See the Voicebox Release Notes and Stardog Release Notes for more information.
Voicebox Suggestions makes it possible to create a Voicebox-enabled Knowledge Graph, complete with spotlight questions, from just a project description, input data, and a few clicks. When enabled, users will see the new Voicebox-assisted project creation flow when creating a new project in Designer.
To enable Voicebox Suggestions in your Launchpad deployment, add the following environment variable to your Launchpad configuration:
VOICEBOX_SUGGESTIONS_ENABLED=trueImportant
Voicebox Suggestions requires Voicebox Service version v0.22.0+ and Stardog version v11.2.0+. See the Voicebox Release Notes and Stardog Release Notes for more information.
You can interact with Voicebox programmatically using the Launchpad REST API. This allows you to send queries to Voicebox and receive responses in a structured format, which can be useful for integrating Voicebox functionality into other applications or workflows.
In order to use the Voicebox REST APIs, you must have the Voicebox Service running and configured with Launchpad. You can access the REST API documentation served by Launchpad at /api/v1/docs endpoint. There's a Swagger UI that provides an interactive interface to explore the API endpoints. Additional documentation about how to use the API is contained there.
To use the Voicebox REST API, you need to create a Voicebox application in Launchpad and generate an API key that is scoped to that application. This API key will be used to authenticate your requests to the Voicebox REST API:
To do so, follow these steps:
- Create a Voicebox application. In the bottom left corner of the Launchpad UI, click on your username opening the user menu, then click on Manage API Keys.
- Click on New Voicebox App and fill in the details for your application. It will ask you to scope the application with details such as the connection to use, database, model, etc.
- Once the application is created, you will need to create an API key that is scoped to the Voicebox application. Click on New App Key in the Voicebox application you just created. You can provide a name for the API key, and adjust the expiration date if desired.
- After creating the API key, you will be able to copy it only once. This API key will be used to authenticate your requests to the Voicebox REST API.
The API key should be provided in the Authorization header of your requests as a Bearer token. You must also include a X-Client-Id header with an identifier < 255 characters long that identifies a user of the Voicebox application. This can be any alphanumeric string.
# Voicebox App token
token=sdc_xyz...
curl --silent -X 'POST' \
'http://launchpad.local:8080/api/v1/voicebox/ask' \
-H 'Accept: application/json' \
-H 'X-Client-Id: someones-id' \
-H "Authorization: Bearer $token" \
-H 'Content-Type: application/json' \
-d '{
"query": "Who is Cersei Lannister married to?"
}' | jq '{ "Result": .result, "SPARQL Query Used": (.actions[] | select(.type == "sparql") | .value)}'
{
"Result": "Cersei Lannister is married to [Robert Baratheon](urn:stardog:marketplace:demos:got:characters:901).",
"SPARQL Query Used": "# Who is Cersei Lannister married to?\n\nSELECT DISTINCT ?spouse0 \nWHERE {\n ?character0 a got:Character . \n ?character0 stardog:label \"Cersei Lannister\" . \n ?character0 got:spouse ?spouse0 . \n ?spouse0 a got:Character . \n FILTER ( ?character0 != ?spouse0)\n}"
}
When making API requests to the Voicebox REST API, the Voicebox Service makes requests to Stardog in order to answer your question. There is a Stardog credential associated with the Voicebox application by means of the Launchpad connection you selected when creating the Voicebox application. In some cases, you may need to override the default authentication method used by Launchpad.
The authentication method depends on your Stardog connection type:
When you authenticate through the Launchpad interface (create a new connection), Launchpad obtains a JWT from the Stardog server on behalf of the authenticated user and persists it beyond the Launchpad session for subsequent requests. If you try and use the connection in Launchpad and your token is invalid or expired, Launchpad will prompt you to re-authenticate, obtaining a new JWT and persisting it for future use. This means that it is possible for a JWT associated with the connection to expire when using it programmatically and not through the Launchpad UI since you will not be prompted to re-authenticate.
If you encounter authentication errors or want to ensure you always have a valid token for programmatic requests, you can manually retrieve a fresh token from the Stardog server associated with the Voicebox app's connection using the /admin/token endpoint (as described below) and include it in your requests using the X-SD-Auth-Token header to override the stored credential. You could also log
into Launchpad and re-authenticate the connection to obtain a new JWT, but this is not always practical for programmatic use.
SSO connections (such as Microsoft Entra) require manual token management since Launchpad does not persist JWTs from external identity providers beyond the session. For these connections, you must:
- Obtain a valid token from your SSO provider that Stardog is configured to accept
- Include the token in your API requests using the
X-SD-Auth-Tokenheader
The X-SD-Auth-Token header can also override any JWT that Launchpad has persisted for a connection. This is particularly useful for ensuring you always have a valid, unexpired token.
As noted earlier, if Stardog is configured to issue JWTs, you can manually retrieve a token using the /admin/token endpoint. This is useful for obtaining a fresh token when needed.
Example:
curl -u <username>:<password> https://<stardog-server-url>/admin/token \The returned JWT issued by Stardog can then be included in your Voicebox API requests:
X-SD-Auth-Token: <your-jwt-token>Tip
If using the Stardog CLI, you can also use the stardog-admin user token command to obtain a JWT from Stardog for a user.
The Voicebox Service is distributed as a Docker image. The Voicebox Service is a stateless HTTP server that packages up Stardog Voicebox functionality. It is intended to be run in conjunction with Stardog Launchpad. The Voicebox Service will communicate directly with whichever Stardog servers you are interacting with in Launchpad, so they should be accessible to this image when run as a container.
When Voicebox makes requests to Stardog servers, it uses server-side connections that may require different network routing than browser-based requests. To support architectures where the Voicebox service container cannot access Stardog on the public endpoint, Launchpad v3.5.0+ allows you to configure an additional internal endpoint for connections.
When an internal endpoint is configured for a connection, Voicebox automatically uses the internal endpoint while browser-based applications (Studio, Explorer, Designer, Knowledge Catalog) continue using the public endpoint. This is particularly useful in scenarios where:
- Stardog is behind a firewall accessible only within a private network
- Different DNS resolution is needed for internal vs. external access
- Network policies restrict container-to-container communication to internal networks
See the SSO Connection Configuration section and individual provider documentation for details on configuring internal endpoints.
-
Similar to Launchpad, the Voicebox Service image can be pulled from Stardog's private Docker registry.
docker pull stardog-stardog-apps.jfrog.io/voicebox-service:current
- The
currenttag will always point to the latest version of the Voicebox Service. You can also specify a specific version tag to avoid accidental upgrades.
- The
-
To run the Voicebox Service with Docker, you can use the following command:
docker run \ --env-file .env.voicebox-service \ -p 8000:8000 \ -v /host/path/to/vbx-config.json:/voicebox-config/vbx-config.json \ stardog-stardog-apps.jfrog.io/voicebox-service:current
.env.voicebox-servicecan be named anything but contains the configuration for the Voicebox Service. See Configuration for more details./host/path/to/vbx-config.jsonis mounted from the host to/voicebox-config/vbx-config.jsonin the container. This configuration has more LLM specific configuration..env.voicebox-serviceshould haveVBX_CONFIG_FILE=/voicebox-config/vbx-config.jsonin it.
- The Voicebox Service HTTP server is exposed on port 8000 so Launchpad can communicate with it.
-
Update Launchpad configuration to point to URL of the Voicebox Service.
VOICEBOX_SERVICE_ENDPOINT=http://<host>:8000
-
Assuming you have restarted Launchpad with the Voicebox Service endpoint configured, you should be able to access Voicebox from the Launchpad UI.
launchpad-voicebox-demo.mov
The following options should be provided as environment variables to the Voicebox Service. Additional environment variables might be needed based on the LLM provider configured. See the Voicebox Configuration File section below for more details.
| Environment Variable | Required | Description | Available Options |
|---|---|---|---|
LOG_TYPE |
N |
The format of the logs sent to STDOUT. Default is JSON |
TEXT, JSON. |
LOG_LEVEL |
N |
Modifies the log level. Default is INFO. |
DEBUG, INFO, WARNING, ERROR |
VBX_CONFIG_FILE |
Y |
The absolute path to the Voicebox configuration file. You will need to mount a directory with the file in it. The Voicebox configuration file contains information like which LLM model provider and model you want to use. Example: /config/vbx-azure-config.json |
In addition to the environment variables provided to the Voicebox Service, the Voicebox Service also requires you to give it a configuration file in JSON.
Here's an example configuration file for using Voicebox with AWS Bedrock:
{
"enable_external_llm": true,
"enable_analytics": true,
"enable_charts": true,
"default_llm_config": {
"llm_provider": "bedrock",
"llm_name": "us.meta.llama3-1-70b-instruct-v1:0"
}
}The following table explains the fields that can be specified in this configuration file. LLM Configuration is explained in the following section.
| Configuration Option | Required | Description | Type |
|---|---|---|---|
default_llm_config |
Y |
Configuration for the LLM provider. | LLM Configuration |
enable_analytics |
N |
Enable the analytics agents that can perform further analysis over results returned from the Knowledge Graph | boolean |
enable_charts |
N |
Enable the capability to turn tabular results in answers to charts | boolean |
enable_external_llm |
N |
Enable the ability to use the LLM to answer questions with its background knowledge instead of the Knowledge Graph | boolean |
external_llm_config |
N |
Configuration for an alternate LLM provider to use for background knowledge if enable_external_llm is enabled. If this configuration is not provided the default_llm_config will be used. |
LLM Configuration |
The LLM configuration is specified as a JSON object in the Voicebox configuration file with the following fields.
| Configuration Option | Required | Description | Type |
|---|---|---|---|
llm_provider |
Y |
Name of the LLM provider | String |
llm_name |
Y |
Name of the LLM | String |
server_url |
N |
Optional server URL for the LLM provider. May be required based on the provider configured. | URL |
max_tokens |
N |
Maximum number of tokens for LLM requests. This limit can be used to control LLM costs to prevent LLM from returning very long responses. | Integer |
provider_args |
N |
Provider-specific arguments. See Custom Headers for details. | Object |
The following LLM providers are supported:
Voicebox can use Anthropic as an LLM provider, either directly via the Anthropic API or through AWS Bedrock and Azure AI Foundry endpoints that host Anthropic models.
The following configuration options are used with Anthropic in the Voicebox configuration file.
| Configuration Option | Available Options |
|---|---|
llm_provider |
anthropic |
llm_name |
claude-sonnet-4-6, claude-haiku-4-5-20251001 |
server_url |
(Optional — set to an Azure AI Foundry endpoint to use Azure-hosted Anthropic models, e.g. https://AZURE_AI_ENDPOINT.services.ai.azure.com/anthropic/) |
The following environment variables are used with Anthropic.
| Environment Variable | Required | Description |
|---|---|---|
ANTHROPIC_API_KEY |
Y (unless using Azure AI Foundry with AZURE_API_KEY) |
Anthropic API key |
When server_url points to an Azure AI Foundry endpoint, you can use either ANTHROPIC_API_KEY or AZURE_API_KEY for authentication. If both are set, ANTHROPIC_API_KEY takes priority.
Anthropic models can also be used via AWS Bedrock using the bedrock provider.
Voicebox can use an Azure AI endpoint deployed within Azure AI Foundry.
The following configuration options are used with Azure LLM in the Voicebox configuration file. Update the AZURE_AI_ENDPOINT in the server URL to point to your endpoint.
| Configuration Option | Available Options |
|---|---|
llm_provider |
azure |
llm_name |
Meta-Llama-3.1-70B-Instruct , Meta-Llama-3.3-70B-Instruct, Llama-4-Maverick-17B-128E-Instruct-FP8 |
server_url |
https://AZURE_AI_ENDPOINT.services.ai.azure.com/models |
Azure AI also supports custom headers via provider_args.headers.
The simplest way to authenticate with Azure AI is using an API key.
| Environment Variable | Required | Description |
|---|---|---|
AZURE_API_KEY |
Y |
Azure API key |
As an alternative to API key authentication, Voicebox supports authenticating to Azure AI Services using a Service Principal via the OAuth 2.0 client credentials flow. When SPN variables are configured, the API key is not required.
Client Secret Authentication
| Environment Variable | Required | Description |
|---|---|---|
AZURE_TENANT_ID |
Y |
Azure Entra ID tenant ID |
AZURE_CLIENT_ID |
Y |
Service Principal application (client) ID |
AZURE_CLIENT_SECRET |
Y |
Service Principal client secret |
Certificate Authentication
| Environment Variable | Required | Description |
|---|---|---|
AZURE_TENANT_ID |
Y |
Azure Entra ID tenant ID |
AZURE_CLIENT_ID |
Y |
Service Principal application (client) ID |
AZURE_CLIENT_CERTIFICATE_PATH |
Y |
Path to PEM file containing private key and certificate |
AZURE_CLIENT_CERTIFICATE_PASSWORD |
N |
Password for the certificate private key, if encrypted |
Note
If both certificate and client secret are configured, certificate authentication takes priority. If neither SPN method is configured, Voicebox falls back to AZURE_API_KEY.
Additional SPN Configuration
| Environment Variable | Required | Description |
|---|---|---|
AZURE_CREDENTIAL_SCOPES |
N |
Token audience scope(s) for the OAuth 2.0 client credentials request, comma-separated. Defaults to https://cognitiveservices.azure.com/.default. |
AZURE_AUTHORITY_HOST |
N |
Authority host for sovereign clouds. Defaults to login.microsoftonline.com. |
Azure Setup for SPN Authentication
-
Create a Service Principal: Go to Microsoft Entra ID → App registrations → New registration. Name it (e.g.
voicebox-service) and register. Note the Application (client) ID and Directory (tenant) ID from the Overview page. -
Create credentials:
- Option A: Client Secret — Go to Certificates & secrets → Client secrets → New client secret. Set a description and expiration, then copy the secret Value (shown only once).
- Option B: Certificate — Generate a certificate, upload the public cert to the app registration, and mount the combined private key + cert PEM file into the Voicebox container. Set
AZURE_CLIENT_CERTIFICATE_PATHto the mount path.
-
Assign the Cognitive Services User role: Go to your Azure AI Services resource → Access control (IAM) → Add role assignment. Search for Cognitive Services User, select it, and assign it to your Service Principal.
Voicebox can use a Bedrock endpoint deployed within AWS.
The following configuration options are used with Bedrock LLM in the Voicebox configuration file.
| Configuration Option | Available Options |
|---|---|
llm_provider |
bedrock |
llm_name |
meta.llama3-1-70b-instruct-v1:0 , us.meta.llama3-1-70b-instruct-v1:0, meta.llama4-maverick-17b-instruct-v1:0, us.meta.llama4-maverick-17b-instruct-v1:0, us.anthropic.claude-haiku-4-5-20251001-v1:0, (application inference profile name) |
AWS Bedrock allows users to create application inference profiles to track usage and costs when invoking a model. The ARN associated with an inference profile can be used as the llm_name in Voicebox configuration. All LLM calls initiated by Voicebox will be done using this inference profile.
The following environment variables are used with Bedrock.
| Environment Variable | Required | Description |
|---|---|---|
AWS_ACCESS_KEY_ID |
Y |
AWS access key ID |
AWS_SECRET_ACCESS_KEY |
Y |
AWS secret access key |
BEDROCK_PROFILE |
N |
AWS profile that can be specified instead of the access key ID and secret access key |
BEDROCK_REGION |
Y |
Name of the AWS region where the Bedrock LLM is deployed, e.g. us-west-1 |
It is also possible to use IAM roles for accessing Bedrock models instead of specifying access keys if Voicebox service is running on an EC2 instance. The IAM role should have the permissions bedrock:Get*, bedrock:List*, bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream. The AWS built-in policy AmazonBedrockLimitedAccess includes these permissions and can be used directly or a new role can be defined with these permissions.
Once the IAM role containing correct permissions is defined, the role can be attached to the EC2 instance where the Voicebox service is running. For the IAM role to take effect none of the environment variables AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, or BEDROCK_PROFILE should be set. When everything is configured correctly, in the Voicebox service logs, you should see a message as follows for the role you have defined:
Found credentials from IAM Role: VoiceboxBedrockRole
Voicebox can use an LLM endpoint deployed within a Databricks workspace.
The following configuration options are used with Databricks LLM in the Voicebox configuration file. Update the DATABRICKS_WORKSPACE in the server URL to point to your workspace.
| Configuration Option | Available Options |
|---|---|
llm_provider |
databricks |
llm_name |
databricks-meta-llama-3-1-70b-instruct, databricks-meta-llama-3-3-70b-instruct, databricks-llama-4-maverick |
server_url |
https://DATABRICKS_WORKSPACE.cloud.databricks.com/serving-endpoints |
The following environment variables are used with Databricks.
| Environment Variable | Required | Description |
|---|---|---|
DATABRICKS_API_KEY |
Y |
Databricks API key |
Voicebox can use Fireworks.ai as an LLM endpoint.
The following configuration options are used with Fireworks in the Voicebox configuration file.
| Configuration Option | Available Options |
|---|---|
llm_provider |
fireworks |
llm_name |
accounts/fireworks/models/llama-v3p1-70b-instruct, accounts/fireworks/models/llama-v3p3-70b-instruct, accounts/fireworks/models/llama4-maverick-instruct-basic |
The following environment variables are used with Fireworks.
| Environment Variable | Required | Description |
|---|---|---|
FIREWORKS_API_KEY |
Y |
Fireworks API key |
Voicebox can use Llama models hosted at Google Vertex Model Garden as an LLM endpoint.
The following configuration options are used with Google Vertex in the Voicebox configuration file. Replace the Google_Vertex_AI_Project_Name value in the example with your project name.
| Configuration Option | Available Options |
|---|---|
llm_provider |
vertex |
llm_name |
meta/llama-3.1-70b-instruct-maas, meta/llama-3.3-70b-instruct-maas |
provider_args |
{ "project": "Google_Vertex_AI_Project_Name" } |
Note that, provider_args is a JSON object itself. An example LLM configuration for Google Vertex looks like this:
{
"default_llm_config": {
"llm_provider": "vertex",
"llm_name": "meta/llama-3.3-70b-instruct-maas",
"provider_args": {
"project" : "My Project Name"
}
}
}The following environment variables are used with Google Vertex.
| Environment Variable | Required | Description |
|---|---|---|
GOOGLE_APPLICATION_CREDENTIALS |
Y |
The location of a credential JSON file |
See Google documentation for the details of creating credential files.
Voicebox can use OpenAI as an LLM endpoint.
The following configuration options are used with OpenAI in the Voicebox configuration file.
| Configuration Option | Available Options |
|---|---|
llm_provider |
openai |
llm_name |
gpt-4o, gpt-4o-mini |
server_url |
(Optional - can be set if OpenAI endpoint is access via proxy) |
OpenAI also supports custom headers via provider_args.headers.
The following environment variables are used with OpenAI.
| Environment Variable | Required | Description |
|---|---|---|
OPENAI_API_KEY |
Y (unless basic_auth is configured) |
OpenAI API key |
For OpenAI-compatible proxies that require HTTP Basic authentication instead of an API key, you can configure basic_auth in provider_args. When basic_auth is configured, OPENAI_API_KEY is not required.
{
"default_llm_config": {
"llm_provider": "openai",
"llm_name": "gpt-4o",
"server_url": "https://your-llm-proxy.example.com/v1/",
"provider_args": {
"basic_auth": {
"client_id": "my-client-id",
"client_secret": "$LLM_CLIENT_SECRET"
}
}
}
}The client_id and client_secret are Base64-encoded at runtime to produce an Authorization: Basic <token> header. Values support the same $ENV_VAR template substitution used by provider_args.headers — use environment variable references (e.g. $LLM_CLIENT_SECRET) for sensitive values and hardcoded strings for non-sensitive values like client_id.
An optional auth_scheme field can be set within basic_auth to change the authorization scheme (defaults to "Basic").
The OpenAI and Azure AI providers support custom HTTP headers included in LLM requests. Custom headers are configured via provider_args.headers in the LLM configuration. Here is an example:
{
"default_llm_config": {
"llm_provider": "openai",
"llm_name": "gpt-4o-mini",
"server_url": "https://api.openai.com/v1/",
"provider_args": {
"headers" : {
"OpenAI-Organization": "org-gnSjNrpIz0bb7V1modfLrNof",
"OpenAI-Project": "$PROJECT_ID"
}
}
}
}Header values support Python string template substitution. Variables referenced in the template string (e.g. $PROJECT_ID) should be defined as environment variables on the Voicebox Service. Environment variables are a better choice for sensitive values whereas non-sensitive values can be directly included in the configuration file.
In addition to environment variables, the special variable $VOICEBOX_USER is automatically resolved to the identity of the user making the request. For web users this is the authenticated username. For Public API requests this is the X-Client-Id header value.
This allows LLM requests to carry user identity, which can be useful for auditing and access control at the LLM provider level:
{
"default_llm_config": {
"llm_provider": "azure",
"llm_name": "Meta-Llama-3.3-70B-Instruct",
"server_url": "https://my-endpoint.services.ai.azure.com/models",
"provider_args": {
"headers" : {
"X-User-Identity": "$VOICEBOX_USER"
}
}
}
}For deployments with multiple Stardog servers or databases, you can provide different Voicebox configurations for each endpoint and database combination. This allows you to customize LLM settings, enable/disable features, or use different models based on the target Stardog server.
Instead of (or in addition to) a single configuration file, you can specify a directory containing multiple configuration files:
| Environment Variable | Required | Description |
|---|---|---|
VBX_CONFIG_DIR |
N |
The absolute path to a directory containing Voicebox configuration files. All .json files in this directory will be loaded. |
Each configuration file can include endpoint and database fields to specify which Stardog connections it applies to:
{
"endpoint": "https://stardog-prod.example.com:5820",
"database": "my-database",
"default_llm_config": {
"llm_provider": "bedrock",
"llm_name": "us.meta.llama3-1-70b-instruct-v1:0"
}
}| Field | Description |
|---|---|
endpoint |
The Stardog server URL to match. Use * to match any endpoint. |
database |
The database name to match. Use * to match any database. |
When a request is made, Voicebox selects the most specific matching configuration:
- Exact match - Config with matching endpoint AND database
- Endpoint wildcard - Config with matching endpoint and
database: "*" - Global wildcard - Config with
endpoint: "*"anddatabase: "*"
/voicebox-config/
├── default.json # endpoint: "*", database: "*"
├── prod-server.json # endpoint: "https://prod.example.com:5820", database: "*"
└── prod-analytics.json # endpoint: "https://prod.example.com:5820", database: "analytics"
With this setup:
- Requests to
prod.example.comwith databaseanalyticsuseprod-analytics.json - Requests to
prod.example.comwith any other database useprod-server.json - All other requests use
default.json
Note
If both VBX_CONFIG_FILE and VBX_CONFIG_DIR are specified, configurations from both sources are loaded. No two configuration files can have the same endpoint and database combination.
Important
If no matching configuration is found for a request, Voicebox will return an error. You should provide a global default configuration (endpoint: "*", database: "*") unless you intentionally want to disable Voicebox for specific endpoints or databases.
For enterprise deployments requiring OAuth-based authentication between Launchpad, Voicebox, and your LLM Gateway, see the dedicated guide:
This guide covers:
- Okta authorization server setup
- On-Behalf-Of (OBO) token exchange configuration
- Launchpad and Voicebox Service environment variables
- Public API JWT authentication
The Voicebox Service is released independently of Launchpad.
Note
All available releases of the Voicebox Service are listed below. The image tag for a release is simply the release name prepended with v as in v0.1.1.
Note
This is a beta build of the next-generation Voicebox Service, distributed under the v1.0.0-beta.3 tag. It powers the Launchpad public API beta and runs alongside the stable 0.x service. See Deploying the Voicebox Service for the Beta for deployment details.
- Answer questions faster by loading matching example queries up front, and answer immediately when a question exactly matches a saved query
- Return a summary of what was attempted when a question is too complex to finish, instead of a generic "cannot find an answer" response
- Fix intermittent authentication errors when answering questions against a knowledge graph whose cached schema outlived the token that loaded it
- Add
VOICEBOX_QUERY_EXEC_TIMEOUT_SECONDS(default:60),VOICEBOX_QUERY_MAX_RESULTS(default:100000), andVOICEBOX_RECURSION_LIMIT(default: unset) to tune query execution limits and the agent step cap - Update dependencies to address reported CVEs
- Do not store expired tokens in the schema cache
Note
This is a beta build of the next-generation Voicebox Service, distributed under the v1.0.0-beta.2 tag. It powers the Launchpad public API beta and runs alongside the stable 0.x service. See Deploying the Voicebox Service for the Beta for deployment details.
- Fix an error when answering questions against knowledge graphs where a relationship is mapped from multiple source columns
- Pick up republished or edited knowledge graph schemas immediately instead of serving a cached schema for up to an hour
- Fix an error when a question returned results with too many columns to summarize; these questions now complete successfully
- Add
VOICEBOX_CODE_EXEC_TIMEOUT_SECONDS(default:30) to configure how long the service may spend analyzing query results while answering a question, and add per-run telemetry to thecode_executedlog event - Emit error tracebacks as structured log events instead of plain-text stack traces
Note
This is a beta build of the next-generation Voicebox Service, distributed under the v1.0.0-beta.1 tag. It powers the Launchpad public API beta and runs alongside the stable 0.x service. See Deploying the Voicebox Service for the Beta for deployment details.
- First beta of the next-generation Voicebox Service.
- Add support for Anthropic as an LLM provider
- Support Anthropic models hosted on AWS Bedrock and Azure AI Foundry
- Always return query lineage even when metadata collection is disabled
- Support custom HTTP headers for Azure AI Foundry LLM provider
- Add
$VOICEBOX_USERspecial variable for custom headers that resolves to the authenticated username
- Fix streaming memory accumulation for improved memory efficiency
- Add HTTP basic authentication support for OpenAI
- Support Azure Service Principal (SPN) authentication for Azure AI
- Include timing and LLM usage information in #debug output
- Update dependencies to address security advisories
- Add endpoint/database-specific Voicebox configuration support
- Add #debug command to show query generation diagnostics
- Support executing queries with GRAPH keyword
- Sanitize var names that start or end with underscore
- Slimmer base image with reduced vulnerabilities
- Sanitize XSD IRIs in example queries
- Handle default prefix in schema serialization
- Prevent dataset description errors when statistics is missing
- Fix date/time reference errors in result summarization
- Use more robust LLM formatting during query linting
- Do not include BITES schema when querying the knowledge graph
- Backend support for on behalf of flow token exchange for LLM providers
- Several improvements to Think Mode
- Better handle large outputs
- Improve responses when an answer is not found
- Support user-configured LLMs for powering Think Mode
- Enhancements to model and mapping creation in Designer
- Create more detailed project summaries using markdown
- Improve evaluation of competency questions
- Generate synthetic data
- Increase default max token configuration for query generation
- Handle escaped characters that are included in generated queries
- Consider inferences when computing query lineage
- Update dependencies to address vulnerabilities
- Support for generating SPARQL queries for competenecy questions in Designer
- Include Voicebox core version in the diagnostics report
- Support for competency question evaluation functionality in Designer
- Use entity summarization from the KG with RAG
- Add chunk IRIs to the RAG response
- Handle incomplete tags in LLM output during query generation
- Support for virtual graphs in Think mode
- Extend support for local prefixes for plain query-generation
- Upgrade Docker image to use Debian 13 and pull in OS patches
- Fix compatibility issues with AMD processors
- Improve handling of binary data, date/time fields, and token limits when generating mappings for Designer
- Return labels of instances from virtual graphs