Workbench

A safe scratch computer where your agent can run code, crunch data, and make files.

Sometimes an agent needs to do work, not just call an API — crunch numbers, parse a messy spreadsheet, generate a PDF, or run a quick script. The workbench gives it a safe, temporary computer to do exactly that, with the rest of Stacklink one call away.

Screenshot placeholderAn agent writing and running a script in the workbench

What it's good for

Crunch & transform data

Clean a spreadsheet, reshape JSON, run pandas or numpy.

Make files

Generate a PDF report, a chart, or an Excel export.

Glue steps together

Call a tool, process the result, call the next one.

Read documents

Pull text and tables out of PDFs, Word, and Excel files.

Turn it on

Enable it on the session. Your agent gets one Workbench gateway, STACKLINK_REMOTE_WORKBENCH. It loads the exact deferred schema it needs before running code, using Bash, managing files, or working with reusable runs:

const session = await stacklink.create({
  tenantId, userId,
  workbench: { enable: true, sandboxSize: 'standard' },
});

Safe by design

The sandbox is isolated and disposable, and your credentials never enter it. When a script needs to call a provider, the workbench asks Stacklink to make the call — secrets stay on our side, never in the agent's code.

Pick a size

Most jobs run fine on the smallest size. Step up only when a job is data- or compute-heavy.

StandardMost jobs — start here

Scripts, file generation, and light data work.

MediumData-heavy

Bigger datasets and more memory-hungry libraries.

LargeHeavy compute

The most demanding jobs — large transforms and parallel work.

Limits at a glance

Every run is bounded, so a runaway job can't run forever or flood your agent with output.

3 minMax run timeper code or bash call

2 MBOutput caplarger results become a file

DisposableSandboxcleaned up when idle

ZeroSecrets insidecredentials stay server-side

A long job doesn't have to block the agent — start it in the background and collect the result later with execution control.

What a script can reach from inside

The workbench isn't a sealed box. From inside a script, the agent can reach back into Stacklink and the web:

Provider tools

Search, fetch schemas, and run any connected provider tool.

AI helper

Call a language model for a sub-task — summarize, classify, extract.

Web search

Look something up on the web.

Document extraction

Turn a PDF, Word, or Excel file into clean text or data.

Packages

Install common Python libraries (pandas, numpy, pillow, requests…) on demand.

Files & artifacts

Read and write files; finished outputs become downloadable artifacts.

Results come back as files

Anything the agent produces — a report, an export, a chart — is saved as an artifact with a download link, instead of being dumped into the conversation. Large tool responses are handled the same way: the agent gets a short preview plus a link, not a wall of text.

What it costs

The workbench is billed as premium usage — mostly by how long it runs, with a small step-up for bigger sizes. Set a budget to cap spend, and see Billing & usage for the numbers.

✦ Free plan

1,000 free premium ops every month

Plenty of workbench runtime to build and test your agent — plus 20,000 standard ops a month, free and hard-capped so there are never surprise bills.

Get your API key today→No credit card or UPI mandate required

For developers

STACKLINK_REMOTE_WORKBENCH accepts a small wrapper:

{
  operation: 'run' | 'workspace' | 'files' | 'artifacts' | 'runs',
  input: {},
  contractVersion?: string,
}

Load one exact schema first with STACKLINK_GET_TOOL_SCHEMAS using stacklink.workbench.run, stacklink.workbench.workspace, stacklink.workbench.files, stacklink.workbench.artifacts, or stacklink.workbench.runs. The run schema supports Python, JavaScript, TypeScript, and Bash through the same durable execution lifecycle. Provider discovery and execution remain in their canonical Stacklink provider tools; session-bound helper clients are available inside the runtime.

Successful code and Bash runs are reusable by default. Before execution, Stacklink captures the exact workspace/package/tier manifest. After completion, it creates one immutable version and returns its state under execution.reusableRun. Use reusableRun: { mode: 'off' } for a scratch run that should not become a version. To create the next version of an existing run, pass its exact seriesId; Stacklink never guesses series membership from similar code or names.

Replay compares only stable observable behavior: terminal status and exit code, ordered output digests, stdout/stderr digests, structured-result digest, byte count, and artifact digest. Execution IDs, timestamps, cursors, duration, usage, and cost are deliberately excluded. A version can be published only after a replay matches, and publish or rollback requires the caller's expected currently published version so concurrent changes fail clearly instead of overwriting each other.

Per-tenant budgets cap maxCostMicros, maxDurationMs, maxLlmTokens, and maxArtifactBytes over a daily, weekly, monthly, or all-time period.