Skip to content
Quark

products · ai

Everything between your model and your product.

Calling a model is easy; getting from a prompt in a notebook to a workload in production is not. The AI tier closes that gap — routing, execution, orchestration, and retrieval, designed as one system.

gateway

One door for every model.

Point your code at one endpoint and call models by alias. Behind each alias is an ordered chain of upstreams, tried in fallback order — so an upstream outage becomes a routing decision, not a war room.

Bring your own upstreams

Connect the model endpoints you already use; their credentials live as secret references, never as plaintext in config.

Aliases, not hardcodes

Code calls a model by name; you decide which chain of upstreams serves it. Change the chain, not the code.

Live serving checks

Each model shows whether it is genuinely serving — verified from the data path, not assumed from a config entry.

Limits that bite

Cap requests or tokens per key, per window. The limit is enforced where the call lands, not in a dashboard nobody watches.

Usage you can trace

Every completion is attributed to the key that made it, and rollups break usage down by key and by model.

A playground built in

Send a prompt through the gateway and see the response, without leaving the console.

for the finance team

Model usage stops being a mystery and becomes an attributed, capped metric — per key, per model, per window.

sandboxes

Built to vanish.

Some work should never outlive itself. Sandboxes launch untrusted code, evaluation runs, and batch fragments with an optional time-to-live — and are destroyed when they're done.

Create with a TTL

When the clock runs out, so does the sandbox.

Destroy on demand

A first-class action, not a cleanup script.

Scoped by grant

A sandbox receives exactly the secrets and permissions it was granted — nothing ambient, nothing inherited.

Runs you can inspect

Input, output, and status on the same timeline as everything else the platform runs.

Real compute when it matters, gone when it doesn't — one execution story, not two.

workflows

Durable orchestration over the whole platform.

Workflows chain the platform's own capabilities into versioned step graphs: call a model through the gateway, run a command in a sandbox, query an index, wait, branch, repeat.

Versioned, immutable definitions

Updating a workflow publishes a new version — running history stays honest.

Checkpointed execution

Each step is checkpointed as the workflow runs, so a long pipeline survives interruption and picks up where it stopped.

Start, watch, cancel

Runs appear on a live timeline with their status; cancel the ones that shouldn't finish.

Inputs as data

Kick off a run with JSON input and watch it on the run timeline.

for the engineering team

The nightly index rebuild, the multi-step data prep, the model-eval sweep — they become reviewable, rerunnable graphs instead of fragile cron folklore.

knowledge graphs

Your data, as relations.

Retrieval shouldn't require a separate stack. Knowledge Graphs turn the data you already hold into entities and relations you can query — with the platform taking no custody of it.

Datasets are declarations

Point at the data you already hold; nothing moves, and nothing is copied away.

Entities and relations, first-class

Model the domain as nodes and typed edges — traversal is the query.

Pipelines build the graph

A staged, declarative build from raw data to a queryable graph — resumable, repeatable, visible.

Query it interactively

Walk neighbors from any node right in the console before you trust it in a run.

Workflows consume it directly

Retrieval is a step in the graph, not a side quest of scripts.

for the data team

The retrieval substrate is a product surface — declarations, pipelines, and query — not a pile of ad-hoc scripts.

vector indexes

Similarity, as an index.

Semantic lookup over your content, treated like infrastructure: declared, versioned, and rebuilt by workflows — never regenerated by whoever still has the script.

Declared like everything else

An index is a named resource in your project — typed, inspectable, and owned.

Similarity with filters

Blend nearest-neighbor search with structured filters, so answers stay in the right lane.

Rebuilds you can rerun

Index builds are workflows — versioned, resumable, and visible on the run timeline.

Serving checked live

An index reports whether it is genuinely serving — verified, not assumed.

for the platform team

Search stops being a separate stack and becomes another accountable resource in the project.

contact

Talk to us about running Quark.

Tell us about your workloads — we will show you what your own cloud can do.