DEV Community: dsplce.co

Claude Opus 5: everything you need to know

dsplce.co — Sun, 26 Jul 2026 07:08:55 +0000

Claude Opus 5 shipped on the 24th of July, 2026, as claude-opus-5. It's priced at $5 per million input tokens and $25 per million output tokens — the same as Opus 4.8, and half of what Fable 5 costs.

The context window is 1M tokens long, the max output is 128K. And there's one breaking change: the model thinks by default now. In other words, on the older Opus you had to ask for thinking explicitly, and it's now set up so it thinks on its own automatically.

What actually changed from the previous Opus?

Now it's allocating thinking depth per turn itself depending on the set effort level; the higher the effort, the more it thinks, but you can still set it explicitly in the request, and the parameter itself hasn't changed — thinking: {"type": "adaptive"} is still valid and still means the default. This means that when migrating a project that didn't do any thinking just by renaming it to this new Opus, you need to make sure you have enough room for both the thinking and the visible part of its response, so raise max_tokens.

Also, if you disable thinking — which you can now do only at high effort or below, because pairing it with xhigh or max returns a 400 — it may output a call to a tool as plain text instead of emitting a proper tool_use block, or leak some of its internal tags into the output. So they recommend keeping it enabled and controlling the cost via the effort level instead.

How much does it cost?

It's priced at $5 per million input tokens and $25 per million output tokens, just like Opus 4.8. The price didn't move, but capability did. Fable 5 is $10 and $50 for the same volumes, so this is exactly half.

There's also fast mode — a separate pricing line, and a research preview that's been running since February (fast-mode-2026-02-01), on Opus 4.8 as well. It's available only through the Claude API; it's not on Amazon Bedrock, Google Cloud or Microsoft Foundry. It's priced at $10 per million input tokens and $50 per million output tokens, so 2x the price for up to 2.5x the output tokens per second (for the record this is throughput, not time to first token, so don't expect end-to-end latency to halve).

The minimum length a prompt needs to be to be cacheable is now 512 tokens instead of 1024, so prompts that were too short to get cached before are being cached automatically now.

Should you use it or Fable 5?

Opus 5 is half the price of Fable 5, and they're very close in terms of the numbers, so for most use cases it's usually about the price. According to their benchmarks:

on CursorBench 3.2 at max effort it comes within half a percent of Fable 5 for half the price
on OSWorld 2.0, which is computer-use work, it does even better than Fable 5 for a third of its cost
it's state of the art on Frontier-Bench and GDPval-AA
it more than doubles Opus 4.8 on Frontier-Bench v0.1
it scores 3 times higher than the next best model on ARC-AGI 3
it reaches around 1.5x the next best pass rate on Zapier's AutomationBench at the same cost

These are Anthropic's figures, so take them with a grain of salt; they're grading themselves. But generally speaking — mid-tier is no longer a compromise pick, and if you were to use Fable 5 by default, it's worth reconsidering in light of these numbers.

One place it doesn't win is exploit development. While on OSS-Fuzz it finds vulnerabilities about as well as Mythos 5, writing the exploits is scored separately — and there it's far behind.

Which effort level should you use?

The effort level starts at high by default; it's the default level both on the Claude API and for Claude Code, and this is what Anthropic document as a starting point. There are five levels in total — low, medium, high, xhigh and max — and in terms of this new Opus, it's more important than ever to choose the right one, as this model translates more effort into better output than any previous Opus, so it makes more of a difference which level you pick.

We'd recommend testing yourself and adjusting up or down from high based on these results — lower when the quality is good enough to save time and money, higher for the hardest tasks. It's also worth noting that especially in this model, the two lowest levels are actually really capable, so the quality there is really good for a fraction of the cost, and the code review is very decent even at the lower levels.

On the other hand, if you're planning to use the top two levels, make sure to set max_tokens high enough, 64K is a good place to start; you need it to have space for both thinking and acting across tools and subagents. Stream the responses rather than awaiting one of them.

Why does it show a smaller context window than a million?

The context window is 1M tokens long, and that's both its size and the max. It's not 200k long, this figure is about the client app; update it if possible. It's a single size, so you can't have reduced variants.

What breaks when you switch?

If you change the model to Opus 5, apart from renaming it, you need to update the surrounding configuration. The biggest potential pitfall is a prompt scaffolding that you might have left behind from older models — the model self-validates out of the box, so any leftover lines like "add a final verification step" or "use a subagent to verify" are prompting it to do additional verification now. Make sure to remove them.

Two things simply aren't available on this Opus: web fetch and Priority Tier. If you're relying on either, that's a blocker rather than something you configure around.

If you're an agent-infra maintainer, there are also 2 new features for you (both behind beta headers at the moment):

you can now add/remove tools between conversation turns without losing the cached prompt, so you no longer need to resend a prompt with a fixed list of tools every time (beta header mid-conversation-tool-changes-2026-07-01)
they have introduced a new fallback mode, which uses their recommended fallback models per refusal category instead of a list you maintain yourself (server-side-fallback-2026-07-01) — Claude API only, and explicitly not supported on Microsoft Foundry

What does it do differently with no code change at all?

If you change the model to this new Opus, you may notice a few differences in terms of behaviour even if you haven't changed anything in your prompts:

longer answers and written deliverables
talks more during agent sessions, narrating its steps
is more eager to use subagents in multi-agent setups
does self-verification

None of these are bugs, they're all steerable by prompting. If you feel like the new Opus is slower or noisier than the previous one after the name change, make sure to check if it's not one of these differences before concluding that the model must've regressed; the "thoughtful and proactive" part of their description is the same thing from their side of the fence.

In terms of its actual capabilities:

sustains long chains of reasoning
can implement features and do big refactors in agent coding across long tool loops, writing multi-file code without leaving stubs or placeholders behind
does really good code review and finds a lot of real bugs with a low number of false positives
is good at reading charts, documents, and diagrams
builds multi-sheet spreadsheets and slide decks
runs subagent teams without them stepping on each other's toes

What we would do on day one

In terms of the day 1 plan:

rename the model
check every max_tokens, as now it needs to accommodate thinking too; it's the most likely reason your output gets cut off after the switch
find and remove any verification scaffolding in prompts and agent instructions
make sure that anywhere you've disabled thinking, the adjacent effort level is high or below, as pairing it with xhigh or max will throw a 400; enforce this before shipping

And perhaps most importantly: run your own code against it, not their benchmarks, and not ours either — although they could be a good start. We recently published a runnable benchmark with Kimi K3, Fable 5 and Opus 4.8 already hooked up. It contains a TypeScript ledger seeded with real bugs, with hidden tests and a prompt to benchmark the models against.

Building with AI is our actual day job. We build software with AI for other companies — this is us reading the release notes on the tools we use every day.
Curious how our benchmarks went? See how Kimi K3, Fable 5 and Opus 4.8 handled the same production task.

Building an MCP server in Python (and connecting it to Claude Code)

dsplce.co — Sat, 25 Jul 2026 15:46:57 +0000

An MCP server is a small app that extends an AI model's capabilities by giving it access to custom tools, a particular set of data or workflows. It's based on the Model Context Protocol, which is an open standard for connecting AI apps with these external sources.

The most straightforward way to create an MCP server is to use the official SDK, implement a single function and mark it as a tool and then expose it through stdio (standard input/output) which you can register in Claude Code; it basically boils down to a single Python file with a single tool and connecting it end-to-end took us around 10 minutes.

Background

Generally, the Model Context Protocol defines two sides:

The server — it's the app you write that you use to publish tools/data
The client — for example Claude Code; it finds and calls available tools based on your permission

As for the main purpose of the Model Context Protocol — before it was introduced, every AI app needed its own custom integration with every tool; the Model Context Protocol replaces this with a single standard connector, so to say it's like USB-C for the AI world — you have a single standardised port instead of having to use a separate cable with every device. In terms of the protocol, a tool is just a function that the model can decide to call.

So if you want to build an MCP server, you do it when you want your model to have access to some resources you have (like your internal API or database for example) which aren't available through any of the already-published servers.

Let's have a look at a minimal example of what such server might look like — a single Python file with a single tool that returns the number of words, characters and lines in the input text.

Scaffold the project

To set up the project we used uv (a CLI for managing Python projects) and installed the official SDK:

uv init word-count-mcp
cd word-count-mcp
uv add "mcp[cli]"

uv init word-count-mcp — initialises a new project called "word-count-mcp" with an uv project file
uv add "mcp[cli]" — adds the mcp package to the project as a dependency with its CLI extras; it also creates a virtual environment and a lockfile
Note that when you run uv init for a new project, it creates a sample main.py file which you can remove if you don't need it

Implement a tool

To implement the tool, create server.py:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("word-count")


@mcp.tool()
def word_count(text: str) -> dict:
    """Count the words, characters, and lines in a block of text.

    Args:
        text: The text to analyze.
    """
    words = text.split()
    return {
        "words": len(words),
        "characters": len(text),
        "characters_no_spaces": len("".join(text.split())),
        "lines": len(text.splitlines()),
    }


if __name__ == "__main__":
    mcp.run(transport="stdio")

These three lines do the entire job:

FastMCP("word-count") — creates an instance of the FastMCP class and names it "word-count"
@mcp.tool() — annotates a function as a tool; the SDK reads its type hints and the docstring to build the tool's schema so the model knows what it does and what arguments it takes; if you don't provide any type hints, the schema will be ambiguous
mcp.run(transport="stdio") — runs the server through stdio, which means that the server waits for requests via stdin and sends responses via stdout

Run it and connect to Claude Code

Now run it to make sure everything works as expected:

uv run server.py

When you run it, it blocks until it receives some input, which is expected as it's a stdio server and hence it does nothing until a client connects; stop it with Ctrl+C.

And then, from the project folder, register it in Claude Code:

claude mcp add word-count -- uv run --directory "$(pwd)" server.py

The part after -- is the command to run the server. claude mcp add registers it as a stdio server by default; the --directory "$(pwd)" bit is a uv flag that points it at the current directory, so no matter from which folder you start Claude Code, it'll work.

And here's the confirmation that we've added a new stdio server called "word-count" to our local config:

Added stdio MCP server word-count with command: uv run --directory /…/word-count-mcp server.py to local config

If you run claude mcp list afterwards, you can see that it's Connected, which means that Claude Code started the server, connected through the Model Context Protocol and received a valid list of tools from it.

word-count: uv run --directory /…/word-count-mcp server.py - ✔ Connected

Verify the tool call

So let's try using this tool now. Run Claude Code on your machine and ask it to use the word-count tool:

Use the word_count tool on this text: "MCP turns Claude into a client for your own tools"

Claude Code sees the word_count tool (full name mcp_word-count_word_count), asks for your permission and calls the server which returns its output as is, here are the counts for the sample text:

{
  "words": 10,
  "characters": 49,
  "characters_no_spaces": 40,
  "lines": 1
}

So you can see that it's a round-trip from Claude Code through the server to the Python function and back to Claude Code.

If you want, you can also test it with the MCP Inspector — the SDK's CLI launches it via mcp dev and it runs at localhost:6274, letting you explore tools and experiment with them by providing arguments and seeing their raw output.

uv run mcp dev server.py

It's very useful for testing servers before integrating them with AI apps like Claude Code.

Common pitfalls

But there are some common pitfalls worth looking out for when working with the Model Context Protocol:

Never write to stdout in a stdio server — stdout is a channel for strictly-formatted messages to the client, if you write to it in your server, you break the stream and terminate the server; use stderr instead for logs; probably the most common beginner's mistake
Choose the right transport — use stdio for local servers, HTTP for remote servers that are available via network; generally, tools are local so prefer stdio but don't assume it works by default
Remember to type your arguments — the tool's schema is based on its type hints and docstring so if you omit the type hints, the schema becomes ambiguous which leads to suboptimal behaviour of the model; always provide type hints and add a one-line docstring for your tools as this is what the model sees
Know the scope — claude mcp add takes -s to decide where the registration is saved: local (the default, which is why you saw “local config” above) = only for you in the current project, user = you across all projects, project = written to .mcp.json so you can commit it and share it with your team; use local to experiment, project for sharing
Restart after tool changes — when you connect a client (like Claude Code) with an MCP server, it reads the list of tools once and then doesn't ask again until you restart the connection

Is it worth building your own?

So… When should you create your own MCP server? Anytime you need the model to access some resources that only you have (like your internal API or a database). If it's a system that's popular enough (like GitHub), there's usually a standard server for it but if you want to give your model access to some custom thing, you need to build this bridge.

The barrier of entry is really low — it's just about defining a function and annotating it with a single decorator; if you can write Python, you can write an MCP tool. But the more advanced challenges appear once your tool actually starts using some systems — authentication, error handling, rate limits, reliability etc. This word-count tool is pretty benign as it's deterministic and inert but when your tool needs to connect with a database or spend money, the actual engineering work starts.

The thing is that there's a difference between "works" and "production-grade". If you want to build an MCP server that works, it takes 10 minutes; if you want to have a production-grade MCP server, it might take 10 months. This is the kind of work DSPLCE does — we help AI companies take their AI-built software the last mile. Have a look at the example on our GitHub, clone and connect it in a couple of minutes.

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

Your pods keep getting killed. Not crashing — killed. One moment they're running fine, the next they're gone and Kubernetes is spinning up replacements. You check the logs and there's nothing useful. The pod just… disappeared.

Turns out Kubernetes killed it on purpose. And if you don't tell it how much memory your app actually needs, it'll keep doing it.

Why Kubernetes evicts pods

Kubernetes runs on nodes — physical or virtual machines that host your containers. Each node has a finite amount of CPU and memory. When a node runs low on resources, Kubernetes has to make a choice: which pods stay, and which ones get evicted to free up space.

The decision comes down to QoS classes — Quality of Service tiers that Kubernetes assigns to every pod based on how you've configured resource requests and limits.

There are three classes:

BestEffort — no resource requests or limits defined. Kubernetes 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. Kubernetes reserves exactly that amount of resources for the pod. Killed last.

If your pods don't have resource configuration at all, they're running as BestEffort. And when the node hits memory pressure, BestEffort pods are the first to go — no questions asked.

The Guaranteed class

Setting your pod to the Guaranteed class is one line in your deployment config. Define requests and limits for both CPU and memory, and make them identical:

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

That's it. Kubernetes now knows this pod needs exactly 512 MiB of RAM and half a CPU core, and it reserves that capacity when scheduling the pod onto a node. If a node doesn't have 512 MiB available, the pod won't be placed there. And if the node runs into memory pressure later, this pod gets evicted last — only after all BestEffort and Burstable pods are gone.

The side effect — better autoscaling

On managed Kubernetes platforms like EKS, this has a second benefit: the cluster autoscaler pays attention to resource requests when deciding whether to add new nodes.

If your pods are BestEffort (no resource config), the autoscaler sees them as requiring zero resources. Ten pods running on a single node looks fine to it, even if that node is at 90% memory usage. It won't spin up a new node because, from its perspective, there's no unmet resource demand.

But if those same pods are Guaranteed with requests: 512Mi, and the current node doesn't have 512 MiB free, the autoscaler sees a pod that can't be scheduled and adds a new node to accommodate it. Your pods start spreading across multiple nodes instead of piling up on one.

This is particularly rigid on EKS — other Kubernetes providers are a bit more lenient, but EKS strictly follows the scheduler's resource calculations. If you don't define requests, autoscaling won't trigger, and you'll end up with all your pods crammed onto a single node until it runs out of memory and starts evicting things.

The trade-off

The downside of Guaranteed is that you're committing to a specific memory limit. If your app grows and starts using more than what you've configured, the pod gets OOMKilled (out-of-memory killed) instead of being allowed to burst beyond the limit.

With Burstable, you could set requests: 256Mi and limits: 1Gi, giving the app room to spike without getting killed. But you lose the scheduling guarantees — Kubernetes only reserves the 256 MiB request amount, so the pod might end up on a node that doesn't have the full gigabyte available.

Guaranteed means you need to monitor memory usage and bump the limit when your app legitimately needs more. It's a bit more maintenance, but in exchange you get predictable scheduling, protection from eviction, and autoscaling that 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 value you see, add 20-30% headroom, and use that as your request and limit. If a pod is sitting at 400 MiB, set it to 512 MiB. If it's consistently hitting 800 MiB, go with 1 GiB.

For CPU, half a core (500m) is a reasonable starting point for most apps. Bump it if you see CPU throttling in your metrics.

And then monitor. If you see OOMKills in the pod events, the limit is too low — increase it. If memory usage grows over time as you ship new features, update the config to match.

Kubernetes won't kill your pods arbitrarily once they're Guaranteed. But you have to tell it what "guaranteed" actually means.