DEV Community: dsplce.co

Kimi K3 vs Claude Fable 5 and Opus 4.8: a benchmark you can run yourself

dsplce.co — Tue, 21 Jul 2026 22:37:37 +0000

Kimi K3 was released this week, and like every model release it's being judged on leaderboard scores and screenshots. But a score is a bit like a football result, in that it tells you who won, not how the game was played. You wouldn't sign a player off a scoreline alone — you'd want to watch the tape. With code models, the tape is the code itself: how it's structured, whether you'd actually want to maintain it. That's what leaderboards can't show you.

So we built a benchmark that compares Kimi K3, Claude Fable 5 and Claude Opus 4.8 on exactly that — and it's open source, so you can run it yourself at github.com/dsplce-co/kimi-vs-fable-vs-opus.

This note summarises our findings after running it.

The task

Given a double-entry ledger module with an existing test suite, make it production-ready and add two features: transaction reversal and statement generation. There's no hint that there are any bugs to find.

But the existing tests aren't actually good — they don't test for real money-safety bugs:

A transfer that can lose money if its second half doesn't complete (the transfer isn't atomic).
Amounts drifting by fractions of a cent due to floating-point precision.
An accessor that exposes internals and lets callers corrupt the ledger.

So passing these tests proves only demo quality — that the core functionality works, nothing more. To grade the results we used a second, hidden test suite that checks the actual money safety — one the models never see.

Same harness, on purpose

All three models were run in the same harness:

Agentically inside Claude Code (opening and editing files, running tests, reacting to failures).
In a high-effort setting.
Three runs each, to see some run-to-run variance.

We made sure to run Kimi K3 inside Claude Code too, just like the Claudes, so the harness itself isn't a variable here. The results reflect how well each model does as an agent inside Claude Code — how it would work with a dev team using it.

Results

We're framing the analysis around how each model wrote the code, rather than the pass/fail binary.

What every model got right

All three, across all nine runs:

Properly fixed the atomicity bug — first validate all the transaction's lines (this pass can throw), then commit in a second pass that cannot throw, forbidding partial transactions:

// validate everything first — this part is allowed to throw
for (const line of lines) {
  const acc = accounts.get(line.accountId);
  if (acc.state !== "open") throw new Error(`account not open: ${line.accountId}`);
}
// then commit — from here nothing throws, so it's all-or-nothing
for (const line of lines) this.entries.push(makeEntry(line));

Implemented the reverse feature as a compensating transaction routed through the existing post function, inheriting its atomicity and lifecycle checks.
Fixed the accessor leak that would let outside callers mutate the ledger's history.

So fixing the known bug and adding the features is a solved problem for all of them. They're interchangeable on that basic bar — the differentiation only starts to appear with the harder questions about the code's long-term behaviour.

Claude Fable 5

Most consistent across all three runs; the same load-bearing choices each time.
Wrote a self-test in each run that verifies encapsulation as an invariant — it tries to corrupt the ledger through the returned object and asserts that it fails, so if a future dev removes the defensive copy, the test breaks immediately instead of a silent leak shipping to production — which is like the difference between doing the safe thing and making the safe thing hard to undo.
The only differences between runs were in degree of caution (one run reserved a namespace, guarded against overflow, threw on unknown accounts instead of returning zero). No run shipped a bug.

Its limitation: it stores money as a bare number type — nothing enforces dollars vs cents at the type level; it's all runtime checks. And its reversal linkage uses a string-prefix convention, which is fragile if the naming convention isn't followed.

Claude Opus 4.8

Wrote the most self-documenting code — comments exactly at the points where invariants hold, entries frozen at write time to guard against mutation, and detailed reports including root-cause writeups and a "deliberately not changed" section outlining conscious choices.
Produced the most instructive failure of the exercise, in one run. It tightened the post function to reject non-integer amounts, but left the dollars-to-cents conversion unrounded — a floating-point issue, like 0.07 * 100 = 7.000000000000001:

// tightened check inside post: reject non-integer minor units
if (!Number.isInteger(amount)) throw new Error("amount must be whole minor units");

// but the conversion, in another file, was left unrounded
function toMinor(major: number) { return major * 100; } // 0.07 * 100 -> 7.000000000000001

0.07 transfer doesn't work now, because the stricter integer check collides with the floating-point imprecision from the unrounded dollars-to-cents conversion. Worse yet, the run's own tests stayed green, because it never created a test that transfers a fractional amount; it was like its safety net had the very hole its own change fell through — a landmine that looks green. The other two Opus runs rounded the conversion and tested it, so this is not a constant weakness of the model.

Kimi K3

Produced structurally consistent code across all three runs — atomic post, idempotent reversal, copy-at-the-boundary pattern.
Some runs added rejection of a reused transaction id with conflicting content, catching a double-spend class of bug that the reference solution doesn't.
The boldest of the three: two of its runs changed the money type to bigint, which is technically the right way to represent currency in JavaScript. But Kimi's bigint conversion was inconsistent at the edges — the transfer function still accepted floating-point numbers, and the balance reader converted back via floating point (Number(minor) / 100), reintroducing the very error bigint was adopted to remove.
In one run, Kimi froze the array returned by getEntries to protect the ledger's internal state, but that broke callers who legitimately append to their own local copy of that array; the internal state stays safe, but the public contract quietly changed underneath everyone using it — it is the mirror image of a leak (a leak lets a caller corrupt your state, this protects your state by breaking the caller).

The remaining risk is at the edges

What these findings tell us is that all three models have mostly solved the core problem — they fixed the bug and added in the features. The remaining risk is at the edges:

Untyped money values.
Safety mechanisms located separately from the code they protect.
Fragile, naming-based reversal linkage.
Comments that don't match the actual behaviour.

It's also worth noting that even for the same model with the same prompt, the public-contract behaviour differed across runs — whether a duplicate transaction throws or silently no-ops, whether a reversal is allowed after an account is closed, whether querying a statement for a nonexistent account throws or returns an empty list. This variance was present in all three models.

Which means that if a particular edge-case behaviour is crucial, it's best to pin it with an explicit test rather than assuming it's consistent across model runs.

The hidden test results

Model	Clean runs	The one failure
Claude Fable 5	3 / 3	—
Claude Opus 4.8	2 / 3	a fractional transfer throws incorrectly
Kimi K3	2 / 3	a frozen returned array breaks a caller

Both Opus's and Kimi's failures were about judgment and edge cases, not fundamental capability. This aligns with the earlier finding that all three have largely solved the core problem.

The restraint trap

We also included a restraint trap: an existing function rounds money to whole units, which is lossy — but it's well-documented, tested behaviour that some other code depends on. The senior move is to leave the rounding as-is, add a warning comment, and provide a new, exact accessor next to it. The junior move is to silently "fix" the rounding, breaking the existing callers that depend on it.

Fable and Opus made the senior move in every run — they preserved the existing rounding behaviour, added a warning comment, and added an exact alternative accessor. Kimi was the least disciplined here:

Silently changed the rounding behaviour.
Produced a different rounding result in each run.
Left the comment claiming "whole major units" despite the change.

We're sharing this because it's revealing — how a model handles a contract it didn't write, when nobody forces it to, says a lot about what it'll do to the contracts already in your codebase.

The verdict

The verdict is two-sided. On one hand, Fable wins on consistency — no shipped bugs, and the most reliable. On the other, this is a single, small task, and the other models' failures weren't substantial enough to rule out the results shifting on a different problem.

So what we'd recommend is to treat this benchmark as a template:

Define which properties of correctness matter for your use case.
Run many more than three attempts per model.
Test across diverse types of task, not just a ledger.
Include long-horizon tasks.
Measure consistency separately, rather than folding it into pass/fail.

Run it yourself

You can run the benchmark on your own codebase, with your own hidden tests, using the code (including the exact prompt) published at github.com/dsplce-co/kimi-vs-fable-vs-opus.

Building with AI is our actual day job. We build software with AI for other companies — this benchmark was just us kicking the tyres on the tools we use every day.
New to Kimi K3? Here's how to run it inside Claude Code.

How to use Kimi K3 with Claude Code (subscription, not API)

dsplce.co — Fri, 17 Jul 2026 21:47:10 +0000

Moonshot AI shipped Kimi K3 today — a 2.8-trillion-parameter open-weight model that, on the benchmarks, is trading blows with the frontier: Claude Fable 5 and GPT-5.6 Sol. On one frontend-coding arena it actually took the top spot, a notch above Fable 5.

Benchmarks are one thing. Whether a model is good for you is another — and the only honest way to settle that is to point it at your own code and watch it work for an afternoon. Claude Code is where a lot of us already do that work, so the fastest way to give K3 a go is to run it inside Claude Code: same cockpit you already know, different engine under the hood.

Here's the whole setup. It takes about two minutes.

Why this works at all

Claude Code is a client. A very good one — the agent loop, the tool use, the diffs, the terminal UX — but underneath, it just speaks the Anthropic API protocol to some backend. Point it at Anthropic's servers and you get Claude. Point it somewhere else that speaks the same protocol and you get whatever's there.

Kimi's coding endpoint speaks that protocol. So you keep the cockpit you already like and swap the engine — no new tool to learn, no workflow to rebuild. And because you're bringing your own backend, you don't need an Anthropic subscription or a Claude API key at all. The only account in play is on the Kimi side.

What you'll need

One thing: a paid Kimi Code plan that includes K3 — the subscription, not pay-as-you-go API credits, which of course are more expensive.

Step 1 — generate a Kimi API key

https://www.kimi.com/code/console

Open the API Keys page, create a new key, and copy it — it's shown to you exactly once, so paste it somewhere safe. It'll look like sk-kimi-….

(Yes, it's called an "API key" even though you're on a subscription. That's just how you authenticate; your usage still counts against your plan, not a metered bill. More on that further down.)

Step 2 — set the environment variables

Claude Code reads its backend from environment variables. Open your shell's startup file — ~/.zshrc, ~/.bashrc, or whatever your shell uses — and add:

export ANTHROPIC_BASE_URL=https://api.kimi.com/coding/
export ANTHROPIC_AUTH_TOKEN=sk-kimi-…            # the key from step 1
export ANTHROPIC_DEFAULT_HAIKU_MODEL=kimi-k3
export ANTHROPIC_DEFAULT_OPUS_MODEL=kimi-k3
export ANTHROPIC_DEFAULT_SONNET_MODEL=kimi-k3
export ANTHROPIC_MODEL=kimi-k3
export CLAUDE_CODE_SUBAGENT_MODEL=kimi-k3
export ENABLE_TOOL_SEARCH=false

What each one is doing:

ANTHROPIC_BASE_URL — where Claude Code sends its requests. This is the actual switch: Kimi's coding endpoint instead of Anthropic's.
ANTHROPIC_AUTH_TOKEN — your Kimi key. If you've ever logged into Claude Code the normal way, this stands in for that.
ANTHROPIC_MODEL — the main model for the session.
ANTHROPIC_DEFAULT_{HAIKU,SONNET,OPUS}_MODEL — Claude Code reaches for different Claude tiers for different jobs: a small fast one for background chores, the mid one for the main work, the big one for heavy reasoning. Kimi's endpoint only serves kimi-k3, so you map all three onto it — otherwise Claude Code tries to call a Claude model that isn't there, and that request fails.
CLAUDE_CODE_SUBAGENT_MODEL — the subagents Claude Code spawns for sub-tasks run on kimi-k3 too, instead of defaulting back to a Claude tier.
ENABLE_TOOL_SEARCH=false — Tool Search is a newer Claude Code feature that loads tool definitions on demand. It leans on Anthropic-specific behaviour, so it's the first thing to misbehave against a third-party backend. Turn it off for a clean run.

Step 3 — reload and launch

Pick up the new variables — either reload the file:

source ~/.zshrc      # or ~/.bashrc, or your shell's equivalent

…or just open a fresh terminal. Then start Claude Code as usual:

claude

That's it. You're driving Kimi K3 through Claude Code.

How to check which model you're actually running

Two reliable ways, and one that lies to you.

The welcome screen. When Claude Code starts, it prints the active model bottom-left. On a working setup it reads kimi-k3:

You'll notice it says API Usage Billing right next to it. Don't let that spook you — it doesn't mean you're being metered. Claude Code labels any token-based auth that way (as opposed to a subscription login); on Kimi's side your usage still draws from your flat plan. Essentially it's a label about how you authenticated, not how you pay.

/status. Inside a session, type /status. If the Base URL reads https://api.kimi.com/coding/, the switch took.

Asking the agent — don't. You'd think you could just ask it "which model are you?" — but this is the one check that misleads you. Claude Code injects a system prompt telling the model it is Claude, so K3, being an obedient junior, will often cheerfully answer "I'm Claude." It isn't lying to you on purpose; it's doing exactly what its instructions told it to. Which is the whole thing in miniature: a model's output is a product of the conditions you put it in, not some fixed truth you can interrogate out of it. Trust the UI, not the confession.

Is it worth it?

For the price of finding out — two minutes and a subscription you can cancel — yes, run the experiment. But run the right one. A leaderboard tells you a model can be good in the aggregate; it can't tell you whether it's good at your stack, your patterns, the specific mess in your repo. That's not something you read off a benchmark — it's something you feel after an afternoon of real work.

So point it at a real task, not a toy. Watch where it's sharp and where it flails. That's the only comparison that decides anything, and now it costs you almost nothing to run.

The bigger point sits one level up: the model is the interchangeable part. Being able to swap the engine under your tools — Claude this week, Kimi the next, whatever's ahead of the pack after that — is worth more than any single model being "the best," because "best" now has a shelf life measured in weeks. The skill that lasts isn't picking the winner; it's knowing how to put whichever model you're holding to work.

That's the same instinct behind everything we build: the model is the fast, tireless junior — the judgement about what actually ships is yours. If you've got an AI-built app that dazzles in a demo and then buckles the moment real users touch it, taking it the last mile to production is exactly what we do.

FAQ

Do I need a Claude or Anthropic subscription to use Kimi K3 in Claude Code?

No. Claude Code is just a client that speaks the Anthropic API protocol; pointing it at Kimi's coding endpoint means you authenticate entirely with a Kimi key. All you need is a paid Kimi Code plan that includes K3 — no Anthropic account, no Claude API key.

Is a Kimi subscription cheaper than API usage for Claude Code?

For agent-style coding, yes. A single Claude Code session can burn millions of tokens, and metered API pricing scales with every one of them. A flat monthly Kimi Code membership fixes the cost no matter how hard you drive it — the same reason heavy Claude Code users pick a Claude subscription over the raw API.

Is Kimi K3 as good as Claude for coding?

On its launch benchmarks it's frontier-level — Kimi K3 topped one frontend-coding arena ahead of Claude Fable 5, and it ships a 1M-token context window. But a leaderboard isn't your codebase. The only comparison that settles it is running it on your real projects for a few sessions and assessing the outcomes yourself.

Why does Claude Code show "API Usage Billing" if I'm on a Kimi subscription?

Because that label reflects how you authenticated (with a token), not how you're billed. Claude Code shows "API Usage Billing" for any token-based backend and "subscription" only for its own login flow. On Kimi's side, your usage still draws from your flat plan.

Can I trust the agent when I ask which model it is?

No — that's the one check that misleads you. Claude Code's system prompt tells the model it is Claude, so Kimi K3 will often answer "I'm Claude." Verify with the welcome screen or /status (Base URL should read https://api.kimi.com/coding/) instead.

How do I switch back to Claude?

Comment out or unset the environment variables in your shell profile — ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN are the two that matter — then reload it or open a new terminal, and Claude Code talks to Anthropic again. If you flip back and forth a lot, keep the Kimi block behind a shell alias or a separate profile you can toggle instead of editing the file each time.

HTML/CSS Animation to Video (MP4): the Headless, Deterministic Way (incl. Claude)

dsplce.co — Fri, 12 Jun 2026 06:30:03 +0000

To convert an HTML/CSS animation — including one Claude generated — to MP4, render it headlessly instead of screen-recording it: a headless Chrome instance drives the page's clock, captures each frame at an exact timestamp, and FFmpeg stitches the frames into video. That makes the output frame-perfect and identical on every run. The one-command path is htmlrec:

brew install dsplce-co/tap/htmlrec ffmpeg
hrec render animation.html -o out.mp4

Defaults: 1280×720, 30fps, 5s, MP4. Formats: MP4, WebM (VP9, optional alpha), and MOV (ProRes 4444, alpha). Override resolution and timing with --width, --height, --fps, and --duration, and add --transparent for an alpha channel.

So you asked Claude to animate something. Maybe a logo, a loading screen, a data viz. It spat out a neat HTML file with CSS keyframes, everything looks crisp in the browser — and now you need it as an MP4.

The obvious approach is screen recording. Open QuickTime or OBS, hit record, play the animation, stop, trim. Works, kind of. Except it's not frame-perfect. If your machine lags for half a second, that lag is baked into the video. The animation runs at whatever speed your CPU felt like that afternoon. Completely non-deterministic. And the moment you tweak something — wrong colour, timing off by 200ms — you're setting the whole thing up again, which is just tiring. Not to mention that every time you hit record you start at a slightly different frame, so swapping the asset in your video editor becomes a pain because nothing lines up the same way twice.

There's a better way.

You can use htmlrec — a CLI tool that renders HTML animations to video frame by frame, without touching your screen. It controls the browser clock directly, so every frame is captured at exactly the right moment regardless of your machine's load. Pixel-perfect, every single time.

Install it with:

brew install dsplce-co/tap/htmlrec ffmpeg

How do I convert an HTML/CSS animation to MP4?

The reliable way to convert an HTML animation to video is to render it headlessly, frame by frame, instead of screen-recording it. Point a tool at your HTML file, let it drive the browser clock, and capture each frame at an exact timestamp:

hrec render animation.html -o out.mp4

This works for any self-contained HTML/CSS animation — a logo reveal, a loading screen, a chart, or anything an LLM like Claude generated for you. The full step-by-step is below.

The workflow

1. Get your animation from Claude (skip if you already have an HTML animation)

Ask Claude for whatever you need. Something like:

"Create an HTML/CSS animation of a logo appearing with a fade and slight upward motion, black background, 3 seconds"

You'll get back a self-contained HTML file. Save it — let's call it animation.html.

2. Render it

hrec render animation.html -o out.mp4

That's it. By default you get a 1280×720, 30fps, 5-second MP4.

3. Adjust if needed

Custom resolution and duration:

hrec render animation.html -o out.mp4 --width 1920 --height 1080 --duration 3 --fps 60

Need transparency (for overlaying on other footage)?

hrec render animation.html -o out.webm --transparent

WebM with VP9 preserves the alpha channel. Works with .mov (ProRes 4444) too if you're in a video editing pipeline.

Example

Here's a minimal animation Claude might generate:

<!DOCTYPE html>
<html>
<head>
    <style>
    body { margin: 0; background: #000; display: grid; place-items: center; height: 100vh; }
    .logo {
        font-family: sans-serif;
        font-size: 64px;
        color: #fff;
        opacity: 0;
        transform: translateY(20px);
        animation: appear 1s ease forwards;
    }
    @keyframes appear {
        to { opacity: 1; transform: translateY(0); }
    }
    </style>
</head>
<body>
    <div class="logo">dsplce</div>
</body>
</html>

Render it:

hrec render animation.html -o logo.mp4 --duration 2

Clean MP4, no screen recording, no lag, no manual trimming.

The whole point of htmlrec is to remove the friction between "Claude gave me an animation" and "I have a video file I can actually use." One command, done.

If you're generating HTML assets regularly — ad creatives, onboarding animations, motion graphics for social — this becomes part of your pipeline rather than a manual step every time. Turning something an AI generated into a deterministic, repeatable artifact you can actually ship is the same instinct we bring to whole products — it's the idea behind taking an AI prototype to production.

Source and docs: github.com/dsplce-co/htmlrec. More about htmlrec on our site, alongside the rest of our open-source work.

How do I convert a CSS animation to MP4?

CSS keyframe animations render to MP4 exactly like everything else — there's nothing special to configure. As long as the motion is driven by CSS animations (@keyframes, transition, animation), a headless renderer captures it deterministically. Match the duration to your animation and you're done:

hrec render animation.html -o out.mp4 --duration 3

The default is 30fps; pass --fps 60 for extra-smooth fast motion when your animation needs it. Either way the frames come from the browser's own clock, so a 3-second animation is exactly 3 seconds of video — no drift, no dropped frames.

Is the output deterministic (including in CI)?

"Deterministic" is the whole point: the same HTML always produces the same video, regardless of what your machine was doing while it rendered. A screen recorder can't promise that — it captures in real time, so any hiccup is baked into the file. A headless renderer steps the page forward one frame at a time and grabs each frame at a precise timestamp, then hands the sequence to FFmpeg:

hrec render animation.html -o out.mp4

That determinism is what makes this practical in a real pipeline. Tweak a colour or a timing value, re-render, and only the parts you changed change — the rest of the frames are identical to last time. Swapping the clip into a video editor lines up perfectly every time because nothing is recorded "live."

The same property makes it CI-friendly: it runs headless with no display, so the identical hrec render command produces the identical video on a build server as it does on your laptop — install Chromium and FFmpeg on the runner and wire it into your pipeline.

That same instinct — do the rigorous version, not the flaky one — is what separates an AI-built demo from an AI-built product. A demo comes together astonishingly fast; making it hold up under real users and constant change is the actual work. If you're staring at an AI-built app that won the demo and now fights every change, taking it the last mile to production is exactly what we do.

Do you need a framework like HyperFrames?

Short answer: it depends on how much you're building.

There's a growing category of open-source tools that turn HTML into video. HeyGen recently open-sourced HyperFrames, a renderer that converts HTML to video and is positioned as "built for agents" — meant to be driven programmatically inside LLM workflows. Under the hood it's the same core idea as the approach here: a headless browser renders the page and FFmpeg encodes the frames, deterministically. It runs locally (Node 22+ and FFmpeg) — there's no hosted service or signup.

So the real question isn't "platform vs. local tool" — both run on your machine. It's scope. HyperFrames is a larger Node framework: it ships adapters for GSAP, Lottie, and Three.js plus a timeline model for composing more complex, programmatic animations. If that's the kind of thing you're building, a framework that size earns its keep.

But for the common case — you already have a self-contained HTML/CSS animation and you just want a clean MP4 — you don't need a framework at all. The job is two well-understood pieces:

Headless Chrome renders the page and steps the animation clock forward frame by frame.
FFmpeg stitches those frames into a video.

That's exactly what htmlrec is: a single-purpose Rust CLI wrapping those two. Point it at an HTML file, get a deterministic MP4 — one command, nothing to compose, frame-perfect.

How to convert a Claude animation to MP4

hrec render animation.html -o out.mp4

MP4 is the safest choice for most use cases — universally supported, small file size, plays everywhere. No extra flags needed.

How do I convert a Claude animation to WebM?

hrec render animation.html -o out.webm

WebM is a good fit if you're embedding the animation on the web. Smaller than MP4 at comparable quality, and supported natively in Chrome, Firefox, and Edge (Safari's VP9 support is patchier, so test there).

How do I get a transparent (alpha) video from an HTML animation?

hrec render animation.html -o out.mov --transparent

MOV with ProRes 4444 is the most reliable format for transparency — virtually every video editor (Premiere, After Effects, Final Cut) handles it without issues.

WebM also supports an alpha channel:

hrec render animation.html -o out.webm --transparent

But in practice, a lot of editing software either doesn't support WebM at all, or silently drops the alpha channel when importing it. If you're taking the file into a video editor, stick with MOV.

Still, if you're embedding the animation directly on a web page rather than taking it into an editor, transparent WebM is a strong option — Chrome and Firefox handle it natively and the file size is a fraction of MOV. Safari's support for alpha-channel WebM is unreliable, though, so don't count on it there.

FAQ

How do I get a transparent (alpha) video from an HTML animation?

Add --transparent and pick an alpha-capable container: hrec render animation.html -o out.mov --transparent gives MOV (ProRes 4444), the most reliable in video editors, and -o out.webm --transparent gives VP9 with alpha for the web. Using --transparent with an .mp4 is rejected, because H.264 has no alpha channel. Many editors silently drop WebM's alpha on import, so prefer MOV for Premiere, After Effects, or Final Cut.

Can I set a custom resolution and frame rate?

Yes. --width, --height, and --fps override the defaults of 1280×720 at 30fps — e.g. hrec render animation.html -o out.mp4 --width 1920 --height 1080 --fps 60. Match --duration to your animation's length so nothing is cut off or padded.

What about long animations?

Set --duration to the real length in seconds; the default is 5. Frames are captured by stepping a virtual clock rather than playing back in real time, so a longer animation simply means more frames — not a longer wait tied to playback speed.

Does it work headless in CI?

Yes. It drives headless Chromium and shells out to FFmpeg with no display, so the same hrec render command runs in a CI container once Chromium and FFmpeg are installed on the runner. Because capture is clock-driven rather than real-time, the video is identical on every run regardless of CI load.

What about fonts and external assets?

Make the animation self-contained — inline the CSS, embed fonts, and base64 or co-locate images — so the headless browser renders exactly what you saw. A web font that hasn't finished loading when the first frame is captured falls back to a system face, so embed or preload anything the animation depends on.

How to toggle realtime on a table in Supabase migrations

dsplce.co — Thu, 11 Jun 2026 21:28:54 +0000

You set up a table locally, opened it in Supabase Studio, flipped the Realtime toggle on, and everything worked — your frontend was getting live updates, subscriptions firing perfectly. Then you ran supabase db diff, generated your migration, pushed it all to production… and Realtime is dead. No events, no subscriptions, nothing.

You check the table — it's there. Columns, RLS policies, indexes, all present. But the Realtime toggle? Off. As if you never touched it.

Why?

The supabase db diff command compares database schemas. Realtime configuration is not a schema change — it's a publication membership. Under the hood, flipping that toggle in Studio just adds your table to a Postgres publication called supabase_realtime. That's it. And because it's neither a schema change nor a data change, db diff is completely blind to it. It won't show up in the diff output, and it won't end up in your migration file.

If you want Realtime to travel with your migrations, you just simply need to write the SQL yourself.

So what's the SQL?

It's just one line:

ALTER PUBLICATION supabase_realtime ADD TABLE public.messages;

That adds your table to the publication. Any client subscribed to it will start receiving changes.

Multiple tables at once:

ALTER PUBLICATION supabase_realtime ADD TABLE public.messages, public.notifications;

Removing a table from Realtime:

ALTER PUBLICATION supabase_realtime DROP TABLE public.messages;

Turning it into a migration

supabase migration new enable_realtime_on_messages

Paste the ALTER PUBLICATION statement into the generated file and you're done. Next time you deploy, the table will be part of the supabase_realtime publication in the target environment.

One thing to watch out for — if someone already enabled Realtime on that table manually in production, the migration will fail with a duplicate table error.

The faster way — supabase-plus

Keeping track of which tables have Realtime enabled, remembering the publication name, checking the current state before writing the migration — it adds up. supabase-plus handles all of that with a single command:

sbp manage realtime

It connects to your local database, lists every table in the schema, and shows you which ones are currently subscribed to supabase_realtime. From there it's an interactive multi-select — toggle tables on or off, and the tool generates the ALTER PUBLICATION statements for you, drops them into a timestamped migration file in supabase/migrations/, and optionally applies the migration to your local database right away.

You can also scope it to a specific schema:

sbp manage realtime --schema private

No looking up syntax, no guessing what's already enabled — the tool shows you the state and lets you change it in one step.

One toggle in Studio, zero lines in your migration history. Now you know how to fix that.

Related: working closer to the database? See how to see running queries in Postgres and kill them.

How to see running queries in Postgres and kill them

dsplce.co — Thu, 11 Jun 2026 21:28:08 +0000

Something is slow. Maybe a page takes forever to load, maybe a migration is hanging, maybe your Supabase dashboard just spins. You suspect a query is stuck somewhere in your database, but you can't see what's happening — Postgres doesn't exactly surface this on its own.

Turns out it does. You just need to ask.

Seeing what's running

Postgres keeps track of every active connection and what it's doing in a system view called pg_stat_activity. You can query it like any table:

SELECT pid, state, query, age(clock_timestamp(), query_start) AS duration
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY duration DESC;

That gives you every non-idle process — its process ID, current state, the SQL it's running, and how long it's been at it. If something has been running for minutes when it should take milliseconds, you've found your problem.

A few things worth knowing about the columns:

pid — the process ID, which you'll need if you want to kill it
state — usually active (running right now), idle in transaction (sitting inside an open transaction doing nothing), or idle (waiting for work)
query — the actual SQL text
query_start — when the current query began

If you want to include the user and database to narrow things down:

SELECT pid, usename, datname, state, query, age(clock_timestamp(), query_start) AS duration
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY duration DESC;

The dangerous one — idle in transaction

An active query that's been running for a while is usually just slow. An idle in transaction connection is a different kind of problem — it means someone (or some code) opened a transaction and never committed or rolled it back. The connection is doing nothing, but it's still holding locks, which can block other queries from running.

These are the ones that tend to cause cascading slowdowns. If you see one that's been sitting there for longer than expected, it's almost certainly a bug in application code — a missing COMMIT, an unhandled exception that skipped the cleanup, or a connection pool that didn't reclaim the session properly.

Killing a process

Once you've identified the offending pid, you have two options.

The gentle approach — ask the query to cancel:

SELECT pg_cancel_backend(12345);

This sends a cancel signal to the running query. If the process is active, the query stops and the connection goes back to idle. It's the equivalent of hitting Ctrl+C — the session stays alive, no harm done.

The forceful approach — terminate the connection entirely:

SELECT pg_terminate_backend(12345);

This kills the entire backend process. The connection is dropped, any open transaction is rolled back, and the client gets disconnected. Use this when pg_cancel_backend doesn't work — which tends to happen with idle in transaction sessions, since there's no active query to cancel.

Replace 12345 with the actual pid from your pg_stat_activity query.

Killing in bulk

If you've got several stuck connections and want to clear them all at once:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND query_start < now() - interval '5 minutes';

That terminates every connection that's been idle in a transaction for more than five minutes. Adjust the interval to taste.

On Supabase specifically

If you're on Supabase, you can run all of this through the SQL Editor in the dashboard. The same pg_stat_activity view is available, and pg_cancel_backend / pg_terminate_backend both work. No extra permissions needed — the default postgres role has access.

One thing to keep in mind: Supabase runs background processes for Realtime, Auth, and PostgREST. You'll see these in pg_stat_activity too. Don't kill them — they'll usually show up with usernames like supabase_admin or authenticator. Stick to terminating connections from your own application's role.

Working in Supabase a lot? We built supabase-plus to smooth over exactly this kind of CLI friction — and wrote up how to toggle realtime on a table in Supabase migrations, another thing the dashboard makes harder than it should be.

Kubernetes kills your pod? Here's why

dsplce.co — Thu, 11 Jun 2026 21:27:31 +0000

Pods keep dying in k8s, not crashing but being killed. They work fine and then disappear, k8s creates new ones and the logs doesn't give any useful info. That's sth that k8s does on purpose, as you haven't ever told it how much memory your app needs. Until you do, it keeps killing them.

Why Kubernetes evicts pods

k8s runs on nodes — physical or virtual machines that host your containers — and each node has a finite amount of CPU and memory. When a node runs low on resources, k8s needs to decide which pods stay and which are being evicted to free up some space.

That decision comes down to QoS classes — quality-of-service tiers k8s assigns every pod based on how you've set its resource requests and limits. There are three:

BestEffort — no resource requests or limits defined. k8s has no idea how much CPU or memory the pod needs. These get killed first.
Burstable — requests and limits are defined, but they're different (e.g., requests: 256Mi, limits: 512Mi). The pod is guaranteed the request amount, but can burst up to the limit. Killed second.
Guaranteed — requests and limits are set to the same value. k8s reserves exactly that amount of resources for the pod. Killed last.

If you don't have any resource configuration for your pods, they run as BestEffort. And when a node hits memory pressure, BestEffort pods are the first ones to go, no questions asked.

The Guaranteed class

Setting up a pod to get into the Guaranteed class is as easy as adding the following to your deployment configuration — you define requests and limits for both CPU and memory and set them to be identical:

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "512Mi"
    cpu: "500m"

k8s knows that this pod needs exactly that much of RAM and half of a CPU. That's why it reserves that capacity when it schedules it on the node. If some node doesn't have 512 MiB free, the pod won't be placed there. And if the node will run into memory pressure later, this pod is being evicted last — after every BestEffort and Burstable pod.

The side effect — better autoscaling

Another advantage of managed k8s platforms like EKS is that the Cluster Autoscaler looks at resource requests when deciding whether to add new nodes. If your pods are set to BestEffort with no resource configuration, the autoscaler thinks they need zero resources. So ten pods on one node is all good for it — even if that node is at 90 percent memory, it won't create another node, as it doesn't see any demand. But if those same pods have a Guaranteed setting with 512Mi requests, and the node has less than 512 MiB free, the autoscaler will see a pod it can't schedule, so it adds a new node, and your pods spread across multiple nodes instead of piling up on one.

It's especially strict on EKS — other providers are more lenient, but EKS follows the scheduler's resource math to the letter. So if you have no requests, the autoscaler will never trigger, and your pods will cram onto a single node until it runs out of memory and starts evicting.

The trade-off

The downside of using Guaranteed is that you need to commit to some memory limit, so if your app grows and uses more memory than you have set, then instead of being burstable it will get OOMKilled by k8s — so with Burstable, for example, you could do 256Mi requests and 1Gi limit to give your app some room to spike, but in return you lose the scheduling guarantee, as k8s reserves only 256 MiB, so the pod might end up on a node which doesn't have a full gigabyte free. But with Guaranteed you just need to keep an eye on how much memory your app uses and occasionally increase the limit — a little more maintenance, but in exchange you get predictable scheduling, protection against eviction, and autoscaling which actually works.

How to set it

In your Kubernetes deployment manifest, add the resources block under containers:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-app
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: app
        image: your-image:latest
        resources:
          requests:
            memory: "512Mi"
            cpu: "500m"
          limits:
            memory: "512Mi"
            cpu: "500m"

Apply it:

kubectl apply -f deployment.yaml

Check the QoS class:

kubectl get pod <pod-name> -o jsonpath='{.status.qosClass}'

If it says Guaranteed, you're set.

Picking the right values

Start by looking at what your pods are actually using. Get current memory consumption:

kubectl top pods

Take the highest memory value you see, add 20–30% of headroom, and use this for both request and limit. If a pod is sitting at 400 MiB set it to 512 MiB; if it's consistently hitting 800 MiB then go with 1 GiB. For CPU, half a core (500m) is a good starting point for most apps — increase it if your metrics are showing throttling on the CPU level. Then monitor: OOMKills in the pod events mean the limit is too low, so you raise it. And if memory usage is growing over time as you ship new features, just update the config to match.

Once your pods are Guaranteed, k8s stops killing them at random — but you still have to tell it what Guaranteed actually means. That's the entire job of requests and limits.