A Worklet is a directed acyclic graph of code and model execution that is backed by an API endpoint.
Worklets are where you define your application's business logic. A Worklet is a directed acyclic graph of code and model execution that is backed by an API endpoint. It allows you to think in terms of your application's business logic and flow, rather than worrying about Kubernetes, Docker, Flask, and DB instances. Once you create your worklet, you can then invoke it through its auto-generated API endpoint or a view component, or set it to run on a fixed schedule.
Worklets are composed of blocks of different types, including Code, Model, and Decision blocks, plus actions such as a Slack block.
In the example below, we want to operationalize a zero-shot classification model. The worklet receives English text as input, pre-processes it, runs the model, and stores the results in the database.
A Worklet graph containing a Model block and two Code blocks

How does data flow through a worklet?

As the flow suggests, the output of each block is fed as the input to the next block. The worklet's input becomes the first block's input, and the final block's output is the complete worklet's output.
Inputs and outputs must be JSON-serializable. For instance, dicts, lists, strings, numbers, and booleans are all valid. However, each node can only take a single input, so for named parameters a dict is usually the best option.

Invoking worklets

While developing and testing, the easiest way to invoke the worklet is through the Baseten UI. See testing for more.
In production, you can invoke a worklet in four different ways:

Through an API endpoint

You can call the worklet through its auto-generated API endpoint. Think of worklets like AWS Lambda functions but without all of the configuration; the API endpoint is live from the moment the worklet is created.
Example invocation:
curl -X POST \
-H 'Authorization: Api-Key YOUR_API_KEY' \
-d '{"worklet_input": WORKLET_INPUT }'
Worklets have a cold start. The first invocation of a worklet can take a few seconds to wake up if the worklet has not been run recently.

On a set schedule

To schedule a worklet, find the worklet in the left sidebar, click the "..." menu, and open the Settings dialog. Then, enable the "Schedule this worklet" option then choose a frequency and time for the worklet to run.
While you can't configure input values for your scheduled worklets, there is a way to pass input values to a scheduled worklet. Let's say Worklet A takes user input and is an API endpoint, but you also want to schedule it to run every hour. Instead of scheduling Worklet A directly, create a new worklet, Worklet B, and add a code block that returns the desired input. Finish Worklet B with a worklet block that invokes Worklet A, and schedule Worklet B at the desired frequency.
You can see which worklets are scheduled by looking for the clock icon in the worklet list.

From an event handler

You can send a request to a worklet from a view component like a button, and assign its input and output to various view components. Configure this kind of worklet invocation with an event handler.

As a binding

You can bind the worklet to the data value of a component (such as Table or JSON Viewer) and assigns its input to various view components. This will result in the worklet being run reactively in response to changes to any input value. Configure this kind of worklet invocation with a binding.

Managing worklets

To create a new worklet, click the "+" button on the left-side worklets menu. You can immediately rename the newly created worklet, and if you change your mind you can rename it later by clicking the three dots next to the worklet to open up the menu for that worklet.
For every worklet, you can:
  • Rename: The new name will be how you refer to the worklet in the Application, but will not change how you call it via the API.
  • Clone: Create an exact copy of the worklet in the application.
  • Delete: Delete the worklet. Any associated Files and Models will not be affected, but Views that rely on the worklet may break, as will any worklets and APIs that call the deleted worklet. Carefully ensure the worklet is totally unneeded before deleting it.

Testing worklets

When I write code, it works perfectly the first time, every time ... said no one ever. To test and debug your worklets, click the "Testing" tab in the bottom navigation menu.
Select the worklet you want to test from the dropdown. If you want to run just a single block, select it in the next dropdown. Selecting "Start" will run the full worklet.
The testing tab
This two-paned tab accepts an input in the left pane and prints worklet output and logs in the right pane. When you're ready, click the "Run" button to run the worklet or block.


Your input must be JSON-serializable.
Example valid inputs:
  • "this is a string"
  • 12345
  • [1, 2, 3, 4]
  • {"this is": "JSON"}
Example invalid inputs:
  • these are random words but not a string
  • 1, 2, 3, 4, 5
  • 1 + 2
  • {"this is": "would be fine except", "the JSON is invalid"; "because semicolon"}
Calling this "input," not "inputs," is intentional. Worklets assume you only give one input, and the function signatures for code blocks use positional arguments. If you need multiple variables passed into a function, that's what the JSON is for; create a dictionary with as many keys as necessary.

Output logging

While debugging a Code or Decision block, it might be handy to log some information. You can use Python's print() statements.

Worklet run logs

Every time a worklet is run, it generates a log entry. These logs are available in the "Logs" tab at the bottom of the page. Each log contains a timestamp, application and run ids, and the worklet run's output, state, and logs. Write to worklet logs from code blocks with the print() function.
The logs tab
Logs are fully searchable by string or regular expression, and can be filtered to any time range. Default ranges from the past five minutes to the past week are built-in, but you can use the calendar to select logs from any date.