Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →butterbase-ai/durable-objects
Use when building stateful per-key actors — chat rooms, multiplayer rooms, rate limiters, long-running agents, leaderboards — that need persistent in-memory + storage state across requests
Passed 7 of 13 test cases with the skill, and 3 of 13 without it.
and 7 more in the full report
9 fixed3 passed either way8 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 9 test cases the skill fixed. Same model, same prompt, with and without the skill.
Show the tool call to delete the Durable Object class named 'temp-cache' in 'app_clean_99', and summarize what happens to existing instance storage.
| Checked | Without skill | With skill |
|---|---|---|
| Calls manage_durable_objects with action 'delete' for name 'temp-cache' | Missed | Passed |
| Explains that deleting a class permanently purges all associated instance storage | Passed | Passed |
The instructions your model reads when the skill loads.
Durable Objects (DOs) are stateful per-key actors running on Cloudflare Workers. Each instance has its own in-memory state and a built-in transactional KV store. Use one when state must survive across requests for a single room/user/agent. For stateless work, use a serverless function instead (butterbase-skills:function-dev).
One tool: manage_durable_objects.
Class: ChatRoom (deployed once)
│
├── instance "lobby" ─► in-memory state + state.storage + WebSockets
├── instance "general" ─► separate state, separate sockets
└── instance "user-123" ─► separate again
Each URL https://<app>.butterbase.dev/_do/chat-room/<instance-id>
gets routed to the instance with that id. State is isolated per id.
A class is shared code; an instance is a unique key (/lobby, /general, /user-123). Different ids = different state. There is no shared cross-instance state.
import { ... } from 'cloudflare:workers' is allowed.export class Foo { ... } — no extra exports, no helpers re-exported.ChatRoom ↔ chat-room).state.storage keys/values capped at 128 KB. Larger blobs → Butterbase Storage.access_mode: "public". Browsers can't set custom headers on WS upgrade, and the _do/ dispatcher reads auth only from Authorization — ?token= and Sec-WebSocket-Protocol are silently ignored at the dispatcher (unlike the /realtime route, which does accept ?token=). Set the DO public, then read the token from ?token= (or Sec-WebSocket-Protocol) inside fetch() and verify it yourself before accepting the upgrade. Server-to-server callers can still use authenticated/service_key.test cases passed, vs 3 / 13 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.