Ship AI changes without shipping code
Prompt, models and output contract live in one versioned Cube behind a single API call. The people who know the domain change what the AI does — eval-gated, one click from rollback — and nobody redeploys.
No credit card. 1,000 credits a month, forever.
drag to spin · click a face
That's the whole integration — the prompt, the model stack and the schema resolve server-side.
AI behaviour changes weekly. Your release process wasn't built for that.
Change the model on Tuesday. Rewrite the prompt on Friday. If those edits live in your codebase, each one is a branch, a review and a deploy — and the rollback plan is a revert commit at 2am.
| AI behaviour in the codebase | AI behaviour on Cubic |
|---|---|
| Prompt strings in a constants file, model names hard-coded at every call site | Prompt, model stack, strategy and output schema in one versioned Cube |
| A copy tweak waits for a sprint, a review and a deploy | Edits publish through staging → production in minutes; callers update on the next request |
| "Who changed it?" is a git blame across three repos | Every version carries an author, a change note and a computed semver; every channel move records actor and reason |
| Quality is checked by vibes | Evals judge every version; regressions pin to the exact edit |
| A provider outage is a 2am hotfix | The fallback stack answers; the incident is a row in Logs |
The prompt is business logic. The codebase is the wrong place for it.
A Cube is a fully-specified unit of LLM work — saved once, called forever.
Prompt — The instructions and their {{variables}}. The words live here, not in your code.
Models — A ranked stack drawn from the whole provider catalog, called through one interface.
Strategy — How the stack works together: take turns, answer all at once, or compete.
Tools — Search and read the live web before the model answers; long runs deliver by signed webhook.
Validation — A JSON Schema every response is held to — checked server-side, every run.
Versioning — Every publish is a computed semver you can diff, pin and roll back.
The prompt, the model stack, the strategy, the tools, the output contract and the version history were never six products. They were always six faces of one object — and treating them as one is what makes the whole thing versionable, priceable and safe to hand to the entire team.
Your code sends {{message}}. Everything around it is now safely editable by people who never open the repo.Read the concepts →Define it once. Improve it forever.
Define
Write the prompt in the editor, the API, the SDK — or hand the authoring guide to your coding agent. Declare typed variables and the output schema.
Release
Publishing computes the version for you. Promote it through staging to production; roll back by moving the pointer back.
Observe
Every run lands in Logs with its cost, latency and attempts. Wasted spend names the fallback rungs that failed.
Improve
Evals judge each version against saved tests. Outcome deltas show what your edit did to cost, p95 and pass rate.
Every change is a version. Every version is a promise.
Two runs of the same version cannot differ because someone edited the Cube in between. Pin version 12 and you get version 12's model stack — not today's.
- Computed semver — A 40% content change or a swapped rank-0 model is a major; every rule that fired is stored with the version.
- Channels —
productionandstagingare movable pointers. Promotion is one call, rollback is moving the pointer back — actor and reason recorded. Address one straight from a request:cbe_…@staging. - Diffs — Compare any two versions: content lines, config fields, schema changes.
- Outcomes — Cost per run, p95 latency, success rate and eval pass rate, per version, with deltas against the version before.
One model is a single point of failure.
Every Cube carries a ranked stack of models and a strategy for using them. Reliability becomes a setting, not a project.
- Fallback — Models take turns until one succeeds. Retries within a run cost nothing extra, and your users never see the outage.
- Broadcast & Contest — Ask every model at once, or let them compete while a judge model picks the winner.
- Model aliases — Re-point
#fast-defaultonce and every Cube naming it switches. A re-point that would break a Cube is blocked with a per-Cube conflict list — never forced. - Your keys — 54 providers, 1,474 models, on your own API keys: envelope-encrypted, and a failing key fails over to the next one.
Responses match the schema, or they don't ship.
Attach a JSON Schema and every response is validated server-side after the model answers — provider support is a bonus, not a dependency.
- Self-repair — On a validation failure, the same model gets one retry with the errors fed back, before the stack falls through.
- Evals, preview-first — An eval is saved together with the exact run you reviewed, then judges every future version. 10 credits a run, judge included.
- The regression trail — A failed eval names the version; the version names the edit and its author.
- Text, JSON or binary — A Cube's output kind — text, structured, image, audio — is part of its contract, fixed at creation.
Cost per run, per version, per caller.
Every credit is attributed — to the Cube, the version, the application that called and the tag you gave the job.
- The trace tree — A batch, a Polycube and its nested calls roll up under one request in Logs.
- Wasted spend — See what the failed fallback rungs and losing contestants cost, and which rung to reorder.
- Slices — Usage by project, application and tag. Tag the nightly job; read its bill in the morning.
- Export — The filtered request list leaves as CSV. Same filters, one file.
Not every AI feature needs an agent.
An agent discovers its context in a loop: call a tool, read the result, decide, call again. Powerful — and unbounded. You can't price a run before it happens, cache it, or promise when it ends.
A Cube declares its context instead. Variables arrive typed from your caller. Function markers pull in the rest before the model runs — search the web, read a document, query your knowledge base or your database — concurrently, each stage metered, and every stage's output passed upward as data, so scraped text can never mint a call.
A document read and translated into prompt context. Two stages, priced per stage, no loop anywhere.
- 01Declared means bounded — the ceiling on a run is arithmetic.
- 02Bounded means priceable before it runs.
- 03Priceable means cacheable, and deadline-able.
- 04And all of it means versionable, and one click from rollback.
- ✕An open loop can promise none of those.
Most production AI features are bounded transforms: triage the ticket, extract the schema, summarise against the knowledge base, translate the filing. For those, an agent is overkill — a Cube is the whole job.
Need more than two stages? That's deliberate.
Marker nesting caps at two, and past it the pipeline becomes a Polycube: Cubes chained on a visual canvas, one Cube's output flowing into the next one's variables, the whole graph running on the same single request and versioning like a Cube — publish, promote, roll back. The graph is validated acyclic at save. A Polycube cannot loop by construction.
Explore Polycubes →And when you do run agents, hand them Cubes as tools: versioned, priced, schema-validated — and authorable by the agent itself. The authoring guide is written to be pasted straight into a system prompt.
Works with your stack. Leaves with your blessing.
Python, sync and async clients, typed exceptions
REST with the OpenAPI reference at /docs; idempotent creation
HMAC-SHA256-signed deliveries, stable across retries, verify helper in the SDK
Usage and changelog as CSV; completion records over the API
Leaving is a supported feature.
Your provider relationships are already yours.
Cubic runs on your keys at your rates — cancel tomorrow and your OpenAI account doesn't notice.
Your data exports.
Usage, logs and the changelog leave as CSV; completion records read back over the API.
Your inference can come home.
External execution renders any Cube's resolved prompt for you to run on your own infrastructure — Cubic still versions, prices and traces the run. The exit ramp and the on-ramp are the same endpoint.
Start free. Grow when you're ready.
- ✓1,000 credits / month
- ✓5 Cubes, 2 projects
- ✓All strategies, Polycubes & async callbacks
- ✓Marketplace: buy & sell (you keep 70%)
- ✓Free test mode & cached runs
- ✓12,000 credits / month + rollover
- ✓50 Cubes, 10 projects
- ✓Credit top-ups & 10% grace buffer
- ✓Marketplace: you keep 80%
- ✓30-day analytics retention
- ✓75,000 credits / month + rollover
- ✓Unlimited Cubes, projects & evals
- ✓Batch up to 1,000 items
- ✓Marketplace: you keep 90%
- ✓5 seats included, 90-day analytics
- ✓Custom credit volume & limits
- ✓SSO, roles, audit logs & SLAs
- ✓Private marketplace listings
- ✓Negotiated take-rate
- ✓Dedicated support
Questions engineers ask, and the ones their teammates do.
What is Cubic, in one paragraph?
I'm a PM, not an engineer — can I use this without writing code?
What's a credit?
Why do I bring my own provider keys?
Will this lock us in?
What's the latency overhead?
Do you support streaming?
202 immediately and delivers the signed result to your webhook when it finishes.Is Cubic an agent framework?
Can we self-host?
Your prompt is now an API.
1,000 free credits a month, forever. No credit card. Your first validated completion is three minutes away.