cken gives every agent a queue to pull from, a spending ceiling it can't cross, and a reviewer at the end — so you can put AI on real work and still explain what happened.
No card. Failed runs are never billed.
The first question — can a model do this task? — got answered a while ago. The second one is where teams stall. Who is accountable when it's wrong? What did it cost? What exactly did it do? Who said it was fine to send? A chat window can't answer any of that, so the work either stays a demo forever, or it ships and nobody can explain it.
It ran, and nobody can say what it did. The output is in a Slack thread, the prompt has been edited twice since, and the person who ran it has left.
It cost real money before anyone noticed. There was no ceiling, so the ceiling was the invoice.
It got better at the demo and worse at the job. A prompt change fixed the case someone complained about and quietly broke four that nobody was watching.
A task moves through these four states and can't skip one.
Point cken at a queue, a schedule, or an inbound webhook. A task is a row with a status, not a conversation you have to babysit. Ten thousand of them behave the same as one.
Every run gets a spending cap, a timeout and a retry policy before it starts. When it hits the cap it stops and says so. There is no version of this where you find out from the bill.
Finished work lands in a review queue — approve, edit, or reject, keyboard-first, routed by rule to whoever owns that kind of work. Approval is the only thing that releases a result.
The examples your reviewers approved become the test set. Change a prompt or a model and cken scores the change against them before it reaches production, so improvements are measured rather than hoped for.
Every headline here is written from the operator's side: what you can now guarantee.
Push a task, schedule one, or let an event create it. Every task is durable — a run that dies mid-flight is picked up again, not lost.
Set a cap per run, per workspace, per month. A run that would exceed it stops before spending, and tells the person who queued it why.
Results queue up for a person. Approve, edit or reject — and the edit is kept, because an edited result is the most valuable training signal you own.
Your approved and rejected results become a scored test set. Every prompt or model change runs against it first, with the score attached to the change.
Corrections your reviewers make stick. The tenth run of a kind of work starts from what your team decided on the first nine.
Inputs, outputs, tools called, cost, duration, approver, timestamps. Months later, you can show someone exactly what happened.
Not between cken and a competitor. Between cken and three things you already have.
| Capability | A chat window | A workflow builder | Scripts your team wrote | cken |
|---|---|---|---|---|
| Who does the work | A person, prompting | Steps you drew | Code, until it breaks | An agent, from a queue |
| Who's accountable | Whoever pasted it | Nobody | The author, unfindable | A named approver |
| When it's wrong | You notice, maybe | It completes anyway | It retries forever | Rejected before it ships |
| What it cost | Unknown | Per task, not per model call | Unknown | Per run, before and after |
| What you show an auditor | A Slack thread | A run log | Application logs | The run, replayable |
| What happens at 10,000 | It doesn't | Per-task pricing bites | Someone becomes on-call | Same thing, queued |
Workflow builders are good tools. If your task is deterministic, use one — it's cheaper and it'll be right every time. The distinction here is the reviewer and the record, not capability.
Retries of the same task don't count twice. A run that fails before producing anything isn't billed. That's the whole meter.
We don't bill for runs that didn't finish.
If a run fails before it produces output, it costs you nothing — no credit to claim, no ticket to open.
One task an agent picks up and finishes, success or failure. Retries of the same task are still one run. A run that fails before producing output isn't billed at all.
Yes — you can auto-approve a class of work once its eval scores earn it, and keep review on everything else. The default is review on, because that's the one setting people regret turning off.
A reviewer rejects or edits it, and the result never leaves cken. The edit is kept as an example, so the same mistake gets caught by the eval set the next time someone changes a prompt.
Those tools run the steps you drew. cken runs work you didn't fully specify, under a budget, and puts a person in front of the result. If your task is deterministic, use the workflow tool — it's cheaper and it'll be right every time.
No card. Failed runs are never billed.