DEV Community: AS

Your quantized model got worse, and nothing told you

AS — Sun, 02 Aug 2026 15:14:41 +0000

Getting a model onto a phone means exporting it, and almost always quantizing it. Both of those change the numbers. Everyone knows that part.

What got me is that nothing tells you when they change too much. The export succeeds. The app builds. The model runs on device and hands back something that looks completely reasonable. And the thing you shipped is worse than the thing you evaluated, by some amount nobody measured, and you find out from a support ticket a month later. Or you don't find out.

I went looking for the standard answer, assuming I'd just missed it. There is one, sort of. Compare your offline predictions against your online ones, and against the post-serialization ones. Every deployment guide says some version of that. Not one of them turns it into something a build can fail on. It's written up as a thing you should do, which in practice means you do it once, the week before launch, while you're doing forty other things, and then never again.

There's a second gap and it fails the opposite way. Preprocessing gets written twice. Once in Python, for training. Once in Dart, for serving. Same normalization constants, same resize, same channel order, sitting in two files that nobody diffs. They agree the day you write them. Then someone changes the mean and std on the Python side six weeks later and the app just quietly starts feeding the model something it's never seen.

So I built the thing I wanted. It's called Fluttorch, it hit 1.0.0 this week, and honestly the release is the least interesting part of this post.

One document, three readers

The idea is small: the exporter writes a manifest next to the artifact, and nothing on the Dart side is allowed to restate what's in it.

Shapes, dtypes, preprocessing constants, labels, the weight hash. Written once. Three things read them, the code generator, the parity gate and the runtime, and none of them declares its own copy. If the Dart side can't restate it, the Dart side can't disagree with training.

The runtime also refuses to load an artifact whose content hash doesn't match what the manifest recorded. That sounded a bit paranoid when I wrote it. Then I re-exported and updated only half the pair, and got an artifact that satisfied every shape check and returned every number wrong, and I stopped thinking it was paranoid.

The generated side

fluttorch_gen is a build_runner builder. It turns the manifest into Dart sitting next to it, and you commit what it generates so CI can regenerate and diff. That diff is what catches a manifest that moved without anyone rebuilding.

final classifier = await Classifier.load(runtime, artifact: bytes);
final out = await classifier.run(image: ClassifierImage(pixels));
final scores = out.logits.values;   // Float32List, over the same memory

Three things that used to be runtime surprises are compile errors now. Passing the wrong tensor, since each one is its own extension type. Passing them in the wrong order, since run takes named arguments. Reading an output that doesn't exist.

None of that costs anything at run time. An extension type is just the underlying tensor once it's compiled. Wrong length still gets caught, at construction, and it tells you which tensor:

TensorShapeException on "image": expected 3072 values, got 100

The bit I actually care about

At export time you hand the exporter some representative inputs and it records what the model answered. Those answers replay in your test suite, against the quantized artifact, on the real backend.

test('the quantized model still agrees with the one we evaluated', () async {
  final goldens = await DirectoryGoldenBundle.open(
    'build/classifier/classifier.fluttorch.json',
  );
  final model = await runtime.load(
    artifact: await File('build/classifier/classifier.pte').readAsBytes(),
    manifest: goldens.manifest,
  );

  await expectParity(model, goldens: goldens);
});

The tolerance comes from the recipe and the precision the manifest recorded, so an int8-dynamic model isn't judged against the bound a full-precision one answers to. You can pass your own, and you probably should if your activation ranges look nothing like the ones the defaults came from.

When it fails it looks like this:

FAIL  parity/case-3
      backend: xnnpack  quantization: int8-static
      output "load_mw"  max |Δ| 1.72  >  Tolerance(atol 0.1, rtol 0.1, cos ≥ 0.998)
        worst at [0]: 14.0210 vs 12.3000
        2 of 4 elements (50.0%) exceed the elementwise bound
      no layer attribution: backend "xnnpack" offers no activation taps

Which tensor drifted, which bound broke, which element broke it, which backend produced the number. I put all four in because I kept hitting failures where I had three of them and was still guessing. That last line is there because per-layer attribution needs the backend to expose intermediate activations and xnnpack won't, so instead of silently giving you less, it says so.

The thing I got wrong

I measured the default tolerances instead of picking them, mostly out of stubbornness, and the measurement told me something I'd have got backwards.

The two-layer model drifts up to eight times further than the convolutional one. The simpler network. I stared at that for a while assuming I'd broken the harness.

It isn't complexity. The two-layer model's outputs land around 9.4, the other ends in a softmax, and relative error is measured against the output while the rounding happened on intermediates. Big outputs absorb the same underlying error inside a much smaller relative bound. Obvious once you see it, and I did not see it for an embarrassingly long time.

One bound in that table is still unmeasured and says so, because nothing in the suite exports int4 yet and I'd rather have a hole than a plausible-looking number.

There's also a model that ExecuTorch happily lowers and then can't execute, identically under its own Python runtime. I left it in the suite as a failing expectation rather than skipping it, so whenever upstream fixes it, my tests are what tell me.

What it doesn't do

It doesn't train anything, convert between formats, or serve inference. It takes something you exported with torch.export and makes the border between Python and Dart typed and checked, and that's the whole scope.

ExecuTorch was just the first backend, not the shape of the thing. ONNX Runtime and LiteRT sit behind the same seam, and nothing above it knows which one is running.

Where it is

fluttorch and fluttorch_gen are on pub.dev, Apache-2.0. The native bindings aren't published because pub.dev can't carry the native half, so you pull those from the repo.

Repository: https://github.com/NaCode-Studios/Fluttorch
Documentation: https://nacode-studios.github.io/Fluttorch/

If you ship models to phones I'd genuinely like to know how you handle this, especially if the answer is "I don't". That's the part I'm least confident I've got right, and I'd rather hear it now than after someone builds on it.

Kmemo 2.0 is out, and the two gaps I admitted to in the first post are closed

AS — Sat, 01 Aug 2026 11:27:36 +0000

This is a follow-up to Kmemo: a semantic cache for LLM calls that refuses to serve you the wrong answer. If you have not read it, the one-line version is that Convert 100 USD to EUR and Convert 250 USD to EUR sit at 0.99 cosine similarity, no threshold separates them, and Kmemo reads the candidates as text instead of trusting the number.

That post shipped 1.0 and ended with two things I could not report. 2.0.0 is out now, and both of them have an answer. One of the answers is not the one I was hoping for.

Gap one: I never said what a verifier catches

The figures in the first post were 67% of near misses rejected and 88% of paraphrases kept, and I labelled them guard-only. The lexical chain runs for free; the optional Verifier is a model call that sees whatever the guards let through. I described that residual as the verifier's job without ever measuring how much of it a verifier actually stops.

Against a named reference implementation, sentence_transformers.CrossEncoder over cross-encoder/quora-distilroberta-base:

Corpus	Residual the guards serve	The verifier stops	False-hit rate	Rephrasings kept
held-out	50 lookups	40 (80%)	0.291 → 0.058	0.881 → 0.452
validation	66 lookups	51 (77%)	0.324 → 0.074	0.882 → 0.686

Four fifths of what the guards miss, and a third of what they had kept. The second column is why this belongs in a table rather than a sentence, and why the verifier stays a seam you opt into rather than a default. Your verifier is not this one; what the table shows is how much of the residual is reachable at all by a model that reads the two prompts.

Gap two: the comparison was against a baseline I built myself

The first post compared Kmemo to a threshold-only cache. That is the thing every "add a semantic cache" tutorial builds, so it is a fair thing to beat, but I wrote it, which makes it a weak claim.

2.0 compares against GPTCache on the same blind corpora, same pairs, retrieval factored out so both sides are handed the identical candidate and asked only whether to serve it.

At zero cost my free lexical chain loses the headline number. GPTCache's ONNX cross-encoder serves fewer false positives than standard(): 0.221 against 0.291 on one split, 0.108 against 0.324 on the other. It gets there by refusing more than half the genuine rephrasings it is shown, where my chain keeps 88%, so roughly half the cache savings is what that strictness costs.

At comparable cost the picture reverses. Their cross-encoder is a transformer inference per candidate, so the row that costs what theirs costs is my guards plus a verifier, which also spends a model call:

Corpus	Kmemo guards + verifier	GPTCache `OnnxModelEvaluation`
held-out	false-hit 0.058, rephrasings kept 0.452	false-hit 0.221, kept 0.476
validation	false-hit 0.074, rephrasings kept 0.686	false-hit 0.108, kept 0.451

Both columns are in the README, including the one I lose. A benchmark reported by the metric that flatters its author does not get believed on any of the others.

One thing worth knowing if you run that comparison yourself. OnnxModelEvaluation.evaluation wraps its entire body in except Exception: return 0, so every internal failure comes back as a similarity of zero and looks identical to a confident refusal. A harness that trusted the documented entry point would have recorded a false-hit rate of 0.000 for GPTCache, which reads like a broken competitor and would have been entirely my own bug. The harness in the repository proves the evaluator works before it believes a single score, and the gate is mechanical rather than semantic: it asks whether the evaluator functions, never whether it agrees with me about a hard pair.

The comments found something I had missed

Someone read the first post and pointed out that every guard receives two strings, and both of them are prompts. The stored answer is right there on the entry and nothing in the match path reads it.

They were right, and it is the one shape the whole chain is blind to by construction:

what is the capital gains tax rate when i sell a second home
what is the capital gains tax rate when i sell a primary residence

No number differs. No unit, no negation, no flipped comparison. Nothing either prompt says is evidence, so every guard abstains, correctly. The cached answer opens Gain on a second home is taxable in full, and it goes to somebody asking about a different house.

2.0 adds a guard that reads it. When the two prompts differ only by a substitution and the cached answer names the word the query replaced, that answer was written for the other question.

SemanticCache(embedder, guards = MatchGuards.responseAware())

It refuses 14 of the 116 near-miss lookups the default chain still serves and none of the 164 rephrasing lookups, and it is still opt-in. The reason is the evidence rather than the result: those answers were written by me for this measurement, because no corpus of real paired answers exists to harvest. A semantic cache corpus records prompts, and the near misses worth catching are exactly the ones whose prompts look alike. That makes it a regression check rather than the blind measurement every other guard is held to, and folding the two together under one default would quietly downgrade the evidence behind all of them.

What else shipped

The core is no longer JVM-only. kmemo-core and InMemoryStore compile for the JVM, iOS, macOS, Linux, Windows, JS and WasmJS, at the cost of no new dependency, since kotlin.time.Instant and kotlin.time.Clock went stable in Kotlin 2.4. The Redis, Postgres and Spring adapters stay JVM-only, because they wrap drivers that exist nowhere else.

The interesting part of that port was not java.time. It was the access-ordered LinkedHashMap, which does not exist outside the JVM and which the store's eviction, the exact-match layer and the verifier's memo were all built on.

The default chain has an eleventh guard, for the near miss where nothing changed and something was added. How do I deploy a Rails app against the same question on Heroku has perfect word overlap, so no lexical check saw it. Measured at zero false rejections across all three corpora.

And four opt-in pieces sit around the match path: reranking so each candidate tried adds something the last did not, quantized retrieval that decides which candidates are looked at and never whether one is served, deduplication on write, and adaptive per-scope thresholds that refuse to run without a verifier watching what comes through.

Upgrading from 1.x

Five named breaks, each with who it affects and the edit that resolves it, in the migration guide. The one easiest to miss: Maven users need kmemo-core-jvm, since Maven does not read Gradle module metadata. Gradle builds change only the version number.

implementation("io.github.nacode-studios:kmemo-core:2.0.0")

Apache 2.0, on Maven Central. Repository: NaCode-Studios/Kmemo.

If something here is wrong, or a configuration is missing from the comparison, say so. That is how the guard in the third section got written.

Kdrant 2.0: I removed the reason to use the official client

AS — Fri, 31 Jul 2026 15:04:41 +0000

In the post where I introduced Kdrant there was a paragraph I never liked writing:

For raw throughput and streaming, gRPC/HTTP2 still wins. If that's your bottleneck, use the official client.

It was true, and it was also the one line in the post that sent people somewhere else. Kdrant 2.0 answers it. There's a gRPC engine now, sitting behind the same QdrantClient as the REST one.

Same client, your choice of wire

val qdrant = Kdrant(host = "localhost")        // REST, port 6333
val qdrant = KdrantGrpc(host = "localhost")    // gRPC, port 6334

That's the migration. Every call after that line is identical, because the API was never protocol-aware: the wire has been behind a QdrantTransport interface since the first release.

Let me be precise about what that's worth, because "we have a clean abstraction" costs nothing to say. Adding the gRPC engine changed zero lines of kdrant-core. Not a handful of small changes. The diff on that module is empty. It's the only test of a seam that means anything, and running it required writing a second implementation.

The engine generates its own stubs from Qdrant's .proto files instead of wrapping io.qdrant:client. Two reasons for that. grpc-kotlin emits suspend functions and Flows, which is the shape the transport already had, so there's no ListenableFuture to adapt back into coroutines. And generating decides the dependency set rather than inheriting it: this engine resolves grpc-okhttp, not the shaded Netty jar that accounts for about 9 MB of the official client on its own.

If you don't want gRPC you pay nothing for it. It's a separate artifact, and a build that depends on kdrant-transport-rest resolves no gRPC, no protobuf and no Netty. That's checked on every build rather than asserted in a README. There's a Gradle task that fails if anything from those groups shows up on the REST engine's runtime classpath, and I confirmed it works by adding grpc-stub to that module and watching it name the five artifacts that arrived.

The test suite turned out to be the interesting part

Two engines are only interchangeable if something proves it, and the existing tests couldn't. They assert HTTP request bodies, which a gRPC engine can't satisfy by construction.

So there's a shared suite now: about 30 behavioural tests that take a QdrantClient from outside, talk to a real Qdrant in Docker, and never mention a protocol. Both engines run the same file against the same server.

It earned its keep on the first run. One test failed on gRPC, and only on gRPC: an ordered scroll came back with no payloads at all.

The cause is worth knowing if you ever write against Qdrant directly. It defaults with_payload to true on scroll and retrieve. The REST engine just omits the field when you haven't asked for anything, so you get that default. My gRPC engine was translating "the caller said nothing" into an explicit enable = false, which is a different request. Every scroll and every retrieve that didn't ask for a payload was quietly coming back empty.

You don't find that by reading code, and no unit test on either engine would have caught it. It needs a test that runs on both and compares them against a server that has opinions.

The core is multiplatform

kdrant-core builds for the JVM and eight Kotlin/Native targets, covering iOS, macOS, Linux and Windows. Same reason as everything above: code that never knew there was a wire has nothing platform-specific to port. Moving it into commonMain changed exactly one declaration, the default dispatcher, because only the JVM publishes Dispatchers.IO.

I want to be clear about what that does and doesn't buy you today. The engines are still JVM-only, since Ktor CIO and grpc-java are. An Android app and an iOS app can share their models, their filter DSL and their query building, and the iOS side brings its own transport. That is not the same as "Kdrant runs on iOS", and I'd rather say so than let a list of target names imply it.

Kotlin/JS is deliberately absent. With no JS engine it would ship a DSL with nothing to send, and its test tooling was the only npm dependency graph in the repo, which arrived carrying a high-severity advisory. One line brings it back the day there's an engine worth having there.

What upgrading costs you

Every 1.x call site compiles unchanged, so source compatibility is intact. Binary compatibility is not, in two places, and it's worth being exact about both.

The first is the artifact layout. kdrant-core is multiplatform now, so its coordinate carries Gradle module metadata and the JVM classes live in kdrant-core-jvm. On Gradle you change the version number and nothing else, because Gradle reads that metadata and picks the variant. On Maven, if you named kdrant-core directly, you move to kdrant-core-jvm. Depending on kdrant-transport-rest or kdrant-transport-grpc, which is what I'd recommend anyway, spares you both.

The second is smaller and easier to miss. ScrollRequest and SearchRequest gained a shardKey parameter when cluster support landed, which changes their generated copy and componentN. The constructor keeps its defaults so your code still compiles, but if you call copy() on either type against a jar built for 1.x, recompile.

The multiplatform migration itself changed no public API at all. The *.api dump is identical either side of it, which is worth saying because it's the part that sounds like it should have broken something.

One limit to know before you switch engines. Qdrant serves eleven operations over HTTP only: telemetry, Prometheus metrics, the issues endpoint, snapshot recovery, snapshot download and upload, and the shard-scope snapshots. On the gRPC engine each one throws, naming itself and naming REST. A snapshot download that quietly returned nothing would be a backup that quietly doesn't exist, so I'd rather it fail loudly.

Try it

dependencies {
    implementation("io.github.nacode-studios:kdrant-transport-rest:2.0.0")
    // or, for gRPC:
    implementation("io.github.nacode-studios:kdrant-transport-grpc:2.0.0")
}

Repo: https://github.com/NaCode-Studios/Kdrant
API docs: https://nacode-studios.github.io/Kdrant/
Changelog: https://github.com/NaCode-Studios/Kdrant/blob/main/CHANGELOG.md

There are Spring Boot, Spring AI, LangChain4j, Koog and Micrometer modules too, all on the same version.

Feedback still welcome, and especially from anyone running the gRPC engine under real load. That's the case I built it for and the one I can't properly test on my own.

The cleanup that could never run: a silent Web Push leak in Go

AS — Mon, 27 Jul 2026 22:16:24 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Nothing reported this bug. No crash, no stack trace, no failing test, no alert. I found it by reading through the notifications path in agentrq, a Go backend for a human-in-the-loop task manager for AI agents, and noticing that a block of error handling could not execute.

The code was not missing a case. It handled the case, in the wrong branch, and had a comment explaining what it was doing.

The code

push.sendToUser loops over a user's browser push subscriptions and delivers a notification to each one. Browsers hand out push endpoints that expire: the user clears site data, uninstalls the PWA, or the subscription lapses on its own. When that happens the push service starts answering 410 Gone or 404 Not Found, and the sender is supposed to drop the subscription.

Here is what the code did, abbreviated:

resp, err := webpush.SendNotification(...)
if err != nil {
    zlog.Warn().Err(err)...
    // Remove invalid/expired subscriptions (410 Gone)
    if resp != nil && resp.StatusCode == 410 {
        _ = c.repo.DeletePushSubscription(ctx, userID, sub.Endpoint)
    }
    continue
}
resp.Body.Close()

Read on its own, that block is fine. It knows about 410 Gone. It nil-checks the response before touching it. It calls the right repository method with the right arguments. Someone understood the problem well enough to write a comment naming it.

Why it can never run

webpush.SendNotification comes from SherClockHolmes/webpush-go (v1.4.0), and it ends with return client.Do(req). So the function inherits the http.Client.Do contract, which splits results in a way that matters here:

A transport-level failure, like a DNS error or a refused connection, returns (nil, err). err is non-nil, so we enter the branch, but resp is nil, so resp != nil && resp.StatusCode == 410 is false.

A request that completes returns (resp, nil), and that includes a 410 Gone and a 404 Not Found. As far as net/http is concerned, receiving a 410 is a success: the round trip worked, the server answered. err is nil, so the entire if err != nil block is skipped.

The two conditions the code needs are in different universes. Whenever resp is non-nil, err is nil. Whenever err is non-nil, resp is nil. DeletePushSubscription was unreachable from the moment it was written.

What I find interesting is where the mistake actually sits. Everything about Web Push in that block is correct: the right status code, the right RFC semantics, the right cleanup call. The wrong assumption is one layer down, about what err means in Go's HTTP client. The author was right about the domain and wrong about the platform, and the compiler has no opinion about that.

What it cost

RFC 8030 §7.3 says a push service returns 404 or 410 once a subscription no longer exists. Since those never triggered a delete, and since DeletePushSubscription is otherwise only called from the explicit user-initiated unsubscribe handlers, nothing in the system ever removed a dead subscription.

Two things followed. Stale rows accumulated in push_subscriptions with no upper bound. And every future task or message event kept re-attempting delivery to endpoints that were already gone, which is one wasted outbound HTTP request per event, per dead subscription, forever.

This is the part I keep thinking about. The cost is not a spike, it is a slope. Each dead subscription adds a small permanent tax on every event the system will ever process, and the tax compounds as more subscriptions die. There is no moment where it breaks, so there is no moment where anyone looks.

It is also invisible to error monitoring, and not by accident. A dead endpoint answering 410 is a completed HTTP request. There is no exception to capture, no non-2xx client error thrown in the app, no log line above warning level. A dashboard would show a healthy delivery path with a slowly rising request count, which is exactly what a growing product looks like.

The fix

The cleanup moves off the error branch and onto the successful one, where the status code actually lives:

if err != nil {
    zlog.Warn().Err(err).Str("endpoint", sub.Endpoint).Msg("[push] failed to send notification")
    continue
}
resp.Body.Close()

// webpush.SendNotification only returns a non-nil error for transport-level
// failures; a delivered-but-rejected request comes back here with err == nil and
// the failure encoded in the status code. Per RFC 8030 §7.3 the push service
// returns 404 Not Found or 410 Gone once a subscription no longer exists, so
// prune it — otherwise it lingers in the DB and every future event re-attempts
// delivery to a dead endpoint.
if resp.StatusCode == http.StatusNotFound || resp.StatusCode == http.StatusGone {
    _ = c.repo.DeletePushSubscription(ctx, userID, sub.Endpoint)
}

I widened 410 to 404 because RFC 8030 treats both as gone, and the original comment had only mentioned one of them. The transport-error path keeps doing what it did, logging and continuing, since a network failure says nothing about whether the subscription is still valid. Retrying later is correct there.

The comment is longer than the code. That was deliberate. The thing that made this bug survive is that the broken version looked reasonable, so I wanted the next person reading it to find the reasoning about err and status codes right there, rather than having to rediscover the client.Do contract.

The tests, and the part I am glad I did the slow way

This delivery path had no test coverage at all, which is the other reason the bug lasted.

The easy version of the test mocks out SendNotification and asserts the delete. It would have passed against the broken code just as happily, because it never exercises the branch structure that was wrong. So I stood up a real httptest.Server returning 410 and 404 and let the actual library make the actual round trip.

That has a cost: webpush.SendNotification encrypts the payload before sending, so it needs real keys or it fails long before any HTTP happens. The tests generate them.

// newTestSubscriptionKeys returns a valid P-256 ECDH public key (p256dh) and a
// 16-byte auth secret, base64url-encoded exactly as a browser PushSubscription
// provides them. Real keys are required because webpush.SendNotification encrypts
// the payload before sending, so bogus keys would fail before any HTTP round-trip.
func newTestSubscriptionKeys(t *testing.T) (p256dh, auth string) {
    t.Helper()
    priv, err := ecdh.P256().GenerateKey(rand.Reader)
    // ...
    return base64.RawURLEncoding.EncodeToString(priv.PublicKey().Bytes()),
        base64.RawURLEncoding.EncodeToString(authBytes)
}

TestSendToUser_PrunesExpiredSubscription asserts DeletePushSubscription(userID, endpoint) is called for both statuses. TestSendToUser_KeepsSubscriptionOnSuccess asserts a 201 does not delete, which is the assertion that would catch someone later "simplifying" the condition into something that prunes healthy subscriptions.

go test -race ./internal/... is green, gofmt and go vet clean.

The PR

agentrq/agentrq#252, merged on July 9. It closes #251, the issue I opened with the diagnosis before writing the fix. Two files, 99 lines added, 4 removed, and most of the additions are tests.

What I took from it

A comment is a claim, and a claim can be false. // Remove invalid/expired subscriptions (410 Gone) was not a description of what the code did. It was a description of what someone meant it to do, and it made the block read as solved to everyone who came after.

The other thing is about where to look. This bug was not in unfamiliar or clever code. It was at a seam, in the handful of lines where application logic meets a library's error convention. The domain reasoning above the seam was right and the assumption below it was wrong, and that combination produces code that reviews well, tests green, and quietly does nothing.

The half-fixed bug: two upstream crashes in dio and flutter/packages

AS — Sun, 26 Jul 2026 23:02:35 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Both of these bugs were already known before I touched them. One had a linked issue and a fix that covered half the cases. The other had a unit test that asserted the crash, with a comment above it saying // Remove when fixed!.

They also had the same shape. In both projects the correct behavior already existed elsewhere in the same file: a sibling transformer that handled the input, a sibling branch that reported the failure instead of dying. One path had been left out of it.

So neither fix invents behavior. Each one extends a decision the project had already made to the branch that missed it.

Project Overview

dio (12.8k stars) is the HTTP client most Dart and Flutter apps are built on: interceptors, form data, request cancellation, timeouts, and a pluggable Transformer layer that turns raw response bytes into the typed object your code receives.

flutter/packages (5.3k stars) is the Flutter team's own monorepo of first-party plugins. The one here is file_selector_android, the Android implementation behind file_selector, the plugin you call when the user needs to pick a file from their device.

Bug Fix or Performance Improvement

1. dio: `FormatException` on an empty response body

FusedTransformer is dio's default transformer. When a request sets a custom responseDecoder and the server returns an empty body with a JSON content type (a normal 200, 204, or 304), the transformer's slow path fed the empty string straight into jsonDecode:

FormatException: Unexpected end of input (at character 1)

SyncTransformer and BackgroundTransformer are handed the identical input and both guard the empty string and return it, which dio then normalizes to null for typed JSON responses. Only the default transformer crashes.

This was the residual half of #2279. PR #2285 had already fixed the empty-body behavior for the fast path, the one with no custom decoder, but the slow path was never given the same guard. The issue looked closed and the fix looked shipped, and anyone who happened to set a responseDecoder still got an exception.

2. flutter/packages: a crash when a picked file can't be copied

file_selector_android crashed the app when a selected file couldn't be copied to a readable location: a SecurityException from a content provider that has withdrawn permission, or an IOException on a full disk.

FileSelectorApiImpl.toFileResponse looked like it handled this. Abbreviated:

String uriPath;
FileSelectorNativeException nativeError = null;

try {
  uriPath = FileUtils.getPathFromCopyOfFileFromUri(
      activityPluginBinding.getActivity(), uri);
} catch (IOException e) {
  // If closing the output stream fails, we cannot be sure that the
  // target file was written in full. […]
  uriPath = null;
} catch (SecurityException e) {
  // Calling `ContentResolver#openInputStream()` has been reported to throw a
  // `SecurityException` on some devices in certain circumstances. Instead of crashing, we
  // return `null`.
  //
  // See https://github.com/flutter/flutter/issues/100025 for more details.
  uriPath = null;
} catch (IllegalArgumentException e) {
  uriPath = FILE_SELECTOR_EXCEPTION_PLACEHOLDER_PATH;
  nativeError = new FileSelectorNativeException(/* … */);
}

return new FileResponse(uriPath, contentResolver.getType(uri), name, size, bytes, nativeError);

In the two branches that crash, uriPath = null is not an oversight. It is deliberate, and commented as such: "Instead of crashing, we return null." The comment cites flutter/flutter#100025, an earlier report of the same class of failure.

The method then builds a FileResponse on that null anyway. path is non-null in the Pigeon-generated FileResponse, so the constructor rejects it at runtime, and the branch written to avoid a crash produces one.

The third branch survives because IllegalArgumentException assigns a placeholder path instead of null, so it reaches Dart with a populated nativeError. The file already had a way to report an unreadable file without dying. The two branches that chose null just didn't use it.

The crash had also shifted shape over time, which is part of why it survived. flutter/flutter#159568 reported it as an IllegalStateException, thrown by the older Java Pigeon generator; since the move to the Kotlin generator, the same failure surfaces as an NPE.

The test suite knew about it too. There was a passing test named openFileThrowsNullPointerException_whenSecurityExceptionInGetPathFromCopyOfFileFromUri, which asserted the crash:

assertThrows(
    NullPointerException.class,
    () -> listenerArgumentCaptor.getValue()
              .onActivityResult(222, Activity.RESULT_OK, resultMockIntent));

Above it, a comment: "The behavior is actually an error case and should be fixed … Remove when fixed!" So the crash was documented, asserted, and passing CI.

Code

dio: cfug/dio#2550, merged
flutter/packages: flutter/packages#12107, merged and shipped in file_selector_android 0.5.2+9

My Improvements

dio: widen the guard instead of adding a branch

The whole fix is one extra condition:

if (isJsonContent &&
    decodedResponse != null &&
    decodedResponse.isNotEmpty) {
  // slow path decoder, since there was a custom decoder specified
  return jsonDecode(decodedResponse);
} else if (customResponseDecoder != null) {
  return decodedResponse;
}

The obvious patch is a new early return for the empty case. I didn't write one, because the branch that already handles it correctly sits directly underneath: else if (customResponseDecoder != null) { return decodedResponse; }. Adding isNotEmpty to the guard lets an empty body fall through into it, and dio's existing normalization turns that into null for a typed JSON response.

So the fix adds no new code path. It narrows a claim that was too broad: "this string is JSON" becomes "this non-empty string is JSON."

A non-empty malformed body still throws, as it did before and as SyncTransformer and BackgroundTransformer do. I wanted the three transformers to agree on this input. Making the default one more forgiving than the other two would have been a different change.

The regression test pins the behavior to the specific combination that was broken (empty body, JSON content type, custom decoder) rather than to the fix:

String decoder(List<int> bytes, RequestOptions o, ResponseBody rb) =>
    utf8.decode(bytes, allowMalformed: true);

final response = await FusedTransformer().transformResponse(
  RequestOptions(
    responseType: ResponseType.json,
    responseDecoder: decoder,
  ),
  ResponseBody.fromBytes([], 200, headers: {
    Headers.contentTypeHeader: [Headers.jsonContentType],
  }),
);
expect(response, '');

flutter/packages: return null instead of an invalid object

Again the correct behavior already existed one level up. The callers of toFileResponse handle a null return: they complete the Dart result with completeWithError("Failed to read file: …"), which is what they do everywhere else a file can't be read. toFileResponse was the only place that pushed on regardless.

if (uriPath == null) {
  // `getPathFromCopyOfFileFromUri` can fail to produce a path: either by
  // throwing (handled above by returning a null `uriPath`) or by returning
  // null directly. Return null so the caller surfaces the failure to Dart,
  // instead of building a `FileResponse` with a null `path`, which the
  // non-null field rejects at runtime.
  // See https://github.com/flutter/flutter/issues/159568.
  return null;
}

Checking uriPath == null rather than catching the exception at the call site was deliberate. getPathFromCopyOfFileFromUri can also return null without throwing, and that path led to the same crash, so one check covers both.

The failure now reaches Dart as a PlatformException you can catch, which is what the uriPath = null branches were aiming for.

I inverted the test that asserted the crash rather than deleting it. It now drives onActivityResult for real and asserts that the callback completes with a failure whose message contains "Failed to read file". I added a second one for the single-file openFile path, which had the same defect and no coverage at all.

I also kept the PR scoped to the crash. #159568 suggests routing these branches through the typed FileSelectorNativeException mechanism, the way #8184 did elsewhere. That is the better long-term design, but it needs a Pigeon regeneration and a Dart-facing API change, which would put a breaking change in the same PR as a crash fix. The API cleanup is worth doing on its own.

What I took from both

The reflex when you find a crash is to add a check. In both of these the check already existed, in the transformer next door or in the caller one frame up, so most of the work was reading enough of the surrounding code to find it. Once you have, the patch is small enough to review in one sitting.

Both bugs had also been looked at before. dio's had an issue and a fix that covered the fast path. The Android one had a test asserting the crash and a comment saying to remove it when fixed. Writing a bug down is not the same as fixing it, and it makes the bug much harder to see the second time around.

We built the benchmark we'd want any AI estimation vendor to pass. Then we failed it.

AS — Sun, 26 Jul 2026 09:59:29 +0000

Large IT projects run about 45% over budget on average. That figure comes from McKinsey and Oxford looking at more than 5,400 of them, and it is the reason a wave of tooling now promises to read your spec and tell you what it will cost.

We were about to build one of those tools. Before writing the product, we wrote the test.

The claim is falsifiable, which is the useful thing about it. The effort-estimation research community has been publishing datasets with real recorded effort for decades. So we asked the version of the question that can come back "no":

On public data with real logged effort, can a statistical engine beat the standard baselines and the human expert, out of sample, without leakage?

It cannot. Not with any model class we threw at it. The benchmark is public, MIT, and reproducible from a pinned environment.

The bar, frozen before any result

We fixed what "passing" meant and committed it to git before running each gate experiment. The git history is the pre-registration.

Criterion	Threshold
PRED(25), the share of estimates within 25% of actual	≥ 55% on at least 2 datasets per channel
MdAPE, median absolute percentage error	≤ 22% on at least 2 datasets per channel
Coverage, actuals inside the nominal-90% interval	within 5 points of 90%
Baselines	beat median-by-category and log-size regression
Expert	beat the recorded human estimate, in aggregate

PRED(25) and MdAPE are the standard metrics in this literature, so the results sit next to published papers without translation. And 55% is deliberately lenient: it is a lower bar than the KPIs we would set on one organization's own history, because public datasets mix organizations and are messier by construction.

Nine datasets, two channels. Tabular project attributes (PROMISE Desharnais, COCOMO81, China, Kitchenham, Maxwell, Albrecht, plus SEERA) and the natural-language text of requirements (JOSSE, SiP, with Deep-SE as secondary evidence).

Four choices that make a negative worth reading

A disappointing number is not a finding. These are the parts that turn one into the other.

Time-ordered evaluation, never random. Random splits let the model peek at the future and inflate every metric. We used rolling-origin cross-validation on the dated datasets and leave-projects-out grouped k-fold on the task datasets. The second one is deliberately the cold-start case: a new project retrieves only from other projects' history, which is exactly the situation a vendor walks into with a new client.

An adversarial leakage audit. Plenty of dataset attributes secretly encode the outcome. SEERA's Requirements stability is computed from modifications during testing and deployment. Team continuity counts developers who left the project. Programmers' capability is built from realized work accuracy. None of that is knowable before a project starts. An independent three-way automated audit classified all 76 SEERA attributes against their published formulas, and we kept only the ones that survived unanimously: 51 of 76.

Conformalized intervals. We do not promise a point, we promise a range that holds. CQR wraps any model and calibrates a distribution-free interval, and we check the empirical coverage rather than the assumed one.

A stop rule committed in advance. Before seeing results we fixed this: if the honest feasibility ceiling, meaning the best out-of-sample PRED(25) across a flexible zoo (Gaussian process, gradient boosting, random forest, k-NN, TF-IDF), sits below 55% on more than one gate dataset, then 55% is unreachable on this data and the channel closes as "threshold unreachable, demonstrated".

That last one is what converts "we couldn't get a good number" into "the number is not there".

Channel A: tabular

The best engine was a log-space Gaussian process. Gradient boosting, a size mean function and hierarchical pooling across datasets were all implemented and none of them helped, because the GP already captures size through its features.

Dataset	n test	GP PRED(25)	Honest ceiling [CI95]
Desharnais	41	36.6%	46.3% [31.7, 61.0]
Kitchenham	73	45.2%	45.2% [34.2, 56.2]
Maxwell	31	51.6%	51.6% [35.5, 67.7]
COCOMO81	62	41.9%	41.9% [30.6, 54.8]
SEERA (sealed holdout)	59	25.4%	33.9%
China (no signal)	499	19.2%	~21%

Aggregated over the four gate development datasets (n=207) the engine reaches 43.5% [36.7, 50.2] and beats the log-size baseline by 12.1 points [5.3, 18.8]. That lift is real and confident. It is also not enough: no dataset's central estimate reaches 55%, and the ceiling's point estimate is below 55% on all five including the sealed holdout, which fired the stop rule.

I want to be careful about what that does and does not say. The tabular test blocks are small, 12 to 73 projects, and Maxwell's ceiling has an upper bound of 67.7%. We are not claiming 55% is impossible on any single small dataset. We are claiming its central estimate is below 55% everywhere we looked, on data whose noise floor is high: the best model's out-of-sample residual scatter is σ ≈ 0.6 in log space, which is roughly ±60% multiplicative, on every dataset.

Richer models do not move that. There is nothing left to extract.

Channel B: the requirement text

The hypothesis was reasonable. Semantically similar requirements should take similar effort, so embed the text, retrieve nearest neighbours, predict a kernel-weighted mean.

Method	SiP	JOSSE
Semantic k-NN (embeddings)	17.9%	14.4%
Learned regressor on embeddings (GBM)	19.5%	15.0%
Learned regressor on embeddings (RF)	18.8%	14.8%
TF-IDF k-NN (lexical)	19.6%	14.2%
Honest ceiling	19.6%	15.0%
Text-blind median (floor)	18.0%	17.2%
Human expert	41.6%	45.0%

No text method beats the text-blind median on real logged effort. On SiP it is a statistical tie. On JOSSE the entire ceiling, 15.0%, sits below the floor of 17.2%, which means the requirement text is worse than guessing the median. Cross-encoder reranking made it worse still, though that one is on us: the standard ms-marco reranker is a query-document model and task pairs are symmetric.

There is one positive in the whole channel. On Deep-SE story points the semantic channel beats the floor by 2.7 points [2.0, 3.4]. Text carries some signal. But story points are a team's own relative scale, not hours, and the signal does not transfer to logged time.

The likely mechanism is not mysterious. Logged time is dominated by who did the work, how often they were interrupted, and local logging habits. None of that is in the requirement text, and across organizations it is most of the variance. Two identically worded tasks take very different logged time on two different teams.

Two things survived

The intervals are honest. A nominal-90% conformal interval covers the truth 94.6% of the time [91.5, 97.7] on unseen projects, distribution-free. It over-covers at lower nominal levels, so the guarantee is kept but loose. The failure here is accuracy, not calibration, and those are different products. "Here is a range that holds 90% of the time" is deliverable today. "Here is the number" is not.

The human expert wins. Where a dataset records a strong expert estimate, the expert beats every model: Kitchenham 61.6%, JOSSE 45%, SiP 41.6%. Experts use team and codebase context that public features and public text simply do not contain. The one place the model holds its own is the SEERA holdout, where the recorded expert is itself weak at 25.4% and the model ties it.

The follow-up that surprised me

If the expert beats the model, the obvious product move is to blend them. Average the two, keep the best of both.

We tested it properly and it does not work. Pooled over 10,551 paired projects, an inverse-variance blend loses to the expert alone with McNemar p < 0.0001, at power ≈ 1.00. That is a real negative, not a wide confidence interval. The diagnostic is that the model and expert residuals correlate, so the diversification a blend is banking on is largely fictitious.

Worth stating the scope: on SiP and JOSSE the "model" in that test is the Track B engine that had already failed to beat the text-blind floor, so this measures blending that model, not blending in general. The weighting machinery is model-agnostic. If some future model measures a smaller residual spread than the expert on a client's own calibration data, the same formula shifts weight toward it automatically.

The first version of this test, at G0, was under-powered: n=73, about 11 discordant pairs, power ≈ 0.16, McNemar p=0.2266. It showed a +6.8 point difference with a confidence interval of [-1.4, +15.1] that included zero. An earlier draft of our own report framed that as a positive direction. It is retracted in the repo, because absence of proof is not proof of presence either, and a 0.16-power test is not evidence of anything.

What this does not prove

Every gate split was a cross-organization cold start on public data. That is the hardest case, and it is precisely not where an estimation tool gets deployed.

A single organization's own history, same team, same logging conventions, same codebase, is the regime public datasets cannot proxy. This benchmark does not measure it and I make no claim about it here. It is the obvious next experiment, and it needs data we do not have.

If you have that history and it interests you, the README says how to reach us. What I can promise is the same discipline you can read in the repo, applied to your data, and a straight answer either way.

Run it yourself

git clone https://github.com/NaCode-Studios/metis-benchmark
cd metis-benchmark
python -m venv .venv && source .venv/bin/activate
pip install -e ".[models,semantic,plots,dev]" -c constraints-g0.txt
make reproduce-g0

constraints-g0.txt is a pip freeze of the environment the numbers were produced in, on CPython 3.14.4. Bootstrap seeds are fixed, but a library upgrade can still move third-decimal behaviour in the GP optimizer or the XGBoost splits, so exact reproduction needs the constraints file.

Every number in this post is produced by those scripts. The protocol, its amendments and the pre-registration timestamps are in reports/protocol.md, the per-phase results are in reports/results/, and the full write-up with the errata section is reports/REPORT.md.

Why publish this

We wrote a test designed to be hard, ran it on ourselves, and it came back no. Publishing that is cheaper than the alternative, which is shipping a claim about cold-start estimation from a spec and finding out in front of a client.

There is also a shortage of this. Negative results in applied ML mostly do not get written up, so the same hypothesis keeps getting re-tested privately by people who cannot see each other's results. If you are evaluating an effort-estimation vendor, the benchmark is a thing you can point at and ask them to run.

Repo: github.com/NaCode-Studios/metis-benchmark. Issues are open, and disagreement with the method is the most useful kind.

Kmemo: a semantic cache for LLM calls that refuses to serve you the wrong answer

AS — Sat, 25 Jul 2026 18:50:51 +0000

An exact-match cache misses "how do I reverse a list in Python" when it has already answered "python list reverse". A semantic cache doesn't: it embeds the prompt, finds the closest one it has seen, and replays that answer instead of calling the model. Fewer API calls, lower latency, same answers.

Except for the part where it hands back the wrong one.

"Convert 100 USD to EUR"
"Convert 250 USD to EUR"      cosine similarity: ~0.99

Every mainstream embedding model scores that pair around 0.99. No threshold separates it from a genuine paraphrase, because on the similarity axis the near miss sits closer than most paraphrases do. Raise the threshold and you lose real hits before you lose that one.

So a cache built on a threshold alone will tell someone that 250 dollars is 92 euros. Quickly, with no error, and nothing in the logs.

What Kmemo does about it

Kmemo treats that as the main event rather than an edge case. Similarity is only the first filter. Candidates that clear it get read as text by a chain of ten guards looking for concrete evidence that the two answers must differ: swapped numbers, mismatched units, different entities, different time references, negation, flipped antonyms, reversed comparisons, or a different kind of answer being asked for.

The defaults follow from the cost asymmetry. A wrong rejection costs one API call. A wrong acceptance costs a wrong answer. So the guards abstain rather than guess.

Quick start

Requires JDK 17+.

dependencies {
    implementation("io.github.nacode-studios:kmemo-core:1.0.0")
}

kmemo-core declares kotlinx-coroutines-core as its only dependency. You bring the embedding source, which is any function from String to FloatArray. Kmemo ships none and depends on no provider SDK.

val cache = SemanticCache(
    embedder = Embedder { text -> openAi.embed(text) },
    store = InMemoryStore(maxEntries = 10_000, ttl = 1.hours),
)

val answer = cache.getOrPut(prompt) { llm.complete(it) }

getOrPut embeds the prompt once and reuses the vector for both the lookup and the write. Concurrent callers asking the same thing get coalesced: the first one computes, the rest wait and are served its answer.

Every miss tells you why

A cache with a 4% hit rate is untunable unless you know what caused the misses, because the fix is opposite for a threshold miss and a guard rejection:

when (val result = cache.lookup(prompt)) {
    is CacheLookup.Hit  -> result.response
    is CacheLookup.Miss -> when (result.reason) {
        MissReason.BELOW_THRESHOLD   -> // traffic repeats less than you assumed, or the threshold is too tight
        MissReason.REJECTED_BY_GUARD -> // a guard found a concrete difference; result.detail says which
        else -> null
    }
}

There's also cache.explain(prompt), a read-only companion that shows every candidate with every guard's verdict. It's what you reach for when a hit you expected didn't happen.

Scopes

Anything that changes what a correct answer looks like belongs in the scope: model, temperature, system prompt, tenant, language. Leave it out and the cache will serve one model's answer to another model's caller.

cache.getOrPut(prompt, scope = "gpt-4o|t=0.0|v3") { llm.complete(it) }

Choosing how strict to be

SemanticCache(embedder)                                    // MatchGuards.standard()
SemanticCache(embedder, guards = MatchGuards.strict())     // trades hit rate for margin
SemanticCache(embedder, guards = MatchGuards.none())       // the naive similarity-only baseline

The guards work outside English too. Curated packs ship for Italian, Spanish, German and French, each measured against a localized near-miss corpus:

SemanticCache(embedder, guards = MatchGuards.standard(Locale.ITALIAN))

What lexical guards can't see

About a third of near misses need world knowledge. Deworming a puppy is not the same as deworming an adult dog. The boiling point of ethanol is not the boiling point of methanol. No amount of token comparison catches those.

For that there's an optional Verifier, typically a cheap model call. It runs only on candidates that already cleared the threshold and every guard, so it costs nothing in the common case, and it fails closed: a timeout or an error rejects rather than serving something unconfirmed.

The numbers

The guards are judged against three labelled corpora with a blind validation split that no guard was tuned against, run as a CI regression gate on every build.

On the blind split, near misses are rejected 67% of the time and paraphrases are kept 88% of the time.

Neither number is 100%, and I would rather publish them than a marketing claim. The near misses that get through are mostly the world-knowledge cases the verifier covers. Reproduce them yourself:

./gradlew :kmemo-core:test --tests '*CorpusTest*'

How the blind splits grow without getting contaminated is written up in docs/CORPUS.md.

Calibrate the threshold, don't copy it

ThresholdCalibrator measures the right threshold for your embedding model. The value you found in a blog post was tuned for somebody else's.

Stores, resilience, observability

Embedder and CacheStore are one-method seams, so you can start in memory and move to a vector database without touching the match logic. Redis (RediSearch KNN) and Postgres (pgvector) stores ship, plus an opt-in in-process HNSW store for when the exact scan stops scaling.

The embedder is a network call on every lookup, so Kmemo lets you own its failure:

val cache = SemanticCache(
    embedder = myEmbedder.retrying(maxAttempts = 4),
    embedFailurePolicy = EmbedFailurePolicy.FALL_BACK_TO_COMPUTE,
    negativeCacheSize = 10_000,
)
cache.warm(faqPairs.map { WarmEntry(it.question, it.answer) })

For dashboards and logs, subscribe to the event stream instead of polling stats(). It costs nothing when unused:

val metrics = KmemoMetrics().also { it.bindTo(meterRegistry) }   // kmemo-micrometer
val cache = SemanticCache(embedder, listeners = listOf(metrics, Slf4jCacheListener()))

Integrations

A Spring Boot starter that auto-configures a SemanticCache bean
A Spring AI caching Advisor for ChatClient
A LangChain4j caching ChatModel wrapper
A Ktor server plugin

examples/ is a runnable demo that needs no API key. It shows a guard catching a live near miss, with a docker-compose for the Redis store.

Try it

Repo: https://github.com/NaCode-Studios/Kmemo
Maven Central: io.github.nacode-studios:kmemo-core:1.0.0
API docs: https://nacode-studios.github.io/Kmemo/
Apache-2.0

1.0 is stable under SemVer. If you have run a semantic cache in production and hit a false hit I haven't thought about, I want to hear about it. Open an issue with the pair that broke it.

If you'd want something like this to exist, a star is what makes it findable for
the next person looking.

Kdrant: an idiomatic, coroutine-first Kotlin client for Qdrant

AS — Tue, 21 Jul 2026 22:36:55 +0000

If you build on the JVM and want to use Qdrant, the official client is io.qdrant:client, and it's built for Java. Every call returns a ListenableFuture, requests are assembled with protobuf builders, and it drags a gRPC/Netty stack onto your classpath. From Kotlin that means fighting the language:

// official Java client, from Kotlin
val future: ListenableFuture<UpdateResult> = client.upsertAsync("articles", points)
val result = future.get() // block, or bolt on a future→coroutine bridge yourself

You reach for coroutines, you get futures. You want a DSL, you get protobuf builders.

Kdrant

Kdrant is the client you'd actually want to write Kotlin against:

Every operation is a suspend function, so cancellation and timeouts are cooperative.
Collections, points, payloads, and filters are built through type-safe DSLs instead of request objects.
The transport is a pure Kotlin REST engine on Ktor and kotlinx-serialization, which keeps gRPC, Netty, and protobuf off your classpath.
Failures surface as a sealed KdrantException you can handle exhaustively.

It's stable (1.1.0, SemVer) and published to Maven Central under io.github.nacode-studios.

Quick start

Requires JDK 17+. One dependency:

dependencies {
    implementation("io.github.nacode-studios:kdrant-transport-rest:1.1.0")
}

Spin up Qdrant locally:

docker run -p 6333:6333 qdrant/qdrant

Connect, create a collection, upsert, search:

val qdrant = Kdrant(host = "localhost", port = 6333) {
    apiKey = System.getenv("QDRANT_API_KEY") // omit for a local, unauthenticated node
    requestTimeout = 5.seconds
}

qdrant.use { client ->
    client.createCollection("articles") {
        vector { size = 1_536; distance = Distance.COSINE }
    }

    client.upsert("articles", wait = true) {
        point(id = 1) {
            vector(embedding) // your List<Float> from any embedding model
            payload("title" to "Introduction", "lang" to "en", "year" to 2026)
        }
    }

    val hits = client.search("articles") {
        query(queryVector)
        limit = 5
        filter { must { "lang" eq "en" } }
    }
}

Kdrant stores and searches vectors you already have. It does not generate embeddings.

A filter DSL that reads like Kotlin

Qdrant's full filtering model, written declaratively:

val query = filter {
    must {
        "lang" eq "en"
        "year" gte 2024
        "price" between 10.0..99.0
    }
    should {
        matchAny("tag", "featured", "promo")
        geoRadius("location", GeoPoint(lon = 13.40, lat = 52.52), radius = 5_000.0)
    }
    mustNot { "archived" eq true }
}

Decode results straight into your types

@Serializable data class Article(val title: String, val lang: String)

val articles: List<Hit<Article>> = qdrant.searchAs<Article>("articles") {
    query(queryVector); limit = 5
}
val first: Article? = articles.firstOrNull()?.payload

Hybrid search (dense + sparse)

Kdrant uses Qdrant's modern /points/query engine, so you can fuse several prefetch sources with Reciprocal Rank Fusion and get real dense plus keyword hybrid search:

val hits = qdrant.search("articles") {
    prefetch { query(denseVector); using = "text"; limit = 50 }
    prefetch { querySparse(indices, values); using = "keywords"; limit = 50 }
    rrf()   // or dbsf()
    limit = 10
}

recommend / discover / context, grouped and batch search, multi-vectors, and a Flow-based scroll are there too.

Integrations

If you're building RAG, you probably don't want to wire the client in by hand:

A Spring Boot starter that auto-configures a QdrantClient bean
A Spring AI VectorStore implementation
A LangChain4j EmbeddingStore implementation

There's a runnable example-rag service (ingest, embed, store, retrieve) with a docker-compose for Qdrant, so you can run the whole thing locally.

The honest tradeoff

For raw throughput and streaming, gRPC/HTTP2 still wins. If that's your bottleneck, use the official client. Kdrant trades it for idiomatic Kotlin and a much smaller footprint:

	Kdrant	Official `io.qdrant:client`
Wire protocol	REST over Ktor CIO	gRPC (HTTP/2)
Heavy deps	none, pure Kotlin	shaded Netty, protobuf, gRPC, Guava
Added footprint	~3-5 MB	~15-20 MB
API style	`suspend` + `Flow`, DSL	`ListenableFuture`, protobuf builders
GraalVM native	friendly	needs gRPC/Netty/protobuf config

For typical RAG and embedding-search workloads, that's a trade I'll take.

Try it

Repo: https://github.com/NaCode-Studios/Kdrant
Maven Central: io.github.nacode-studios:kdrant-transport-rest:1.1.0
API docs: https://nacode-studios.github.io/Kdrant/
Apache-2.0

Feedback is welcome, especially on API ergonomics. If there's something you'd want from a Kotlin-native Qdrant client, open an issue and tell me.

If you'd want something like this to exist, a star is what makes it findable for
the next person looking.

Stripe-connect-reckon – a read-only monitor for Stripe Connect balance risk

AS — Mon, 29 Jun 2026 02:23:37 +0000

I worked on a marketplace where a connected account went negative, Stripe suspended its payouts, and refunds silently queued as pending — no error, no alert, discovered via a customer complaint.

stripe-connect-reckon is a small read-only TypeScript library that watches connected accounts and reports issues with severity:

NEGATIVE_BALANCE_RISK (per-currency)
FAILED_PAYOUT
UNRECONCILED_REFUND (vs. the state your app reports)
EVENT_GAP (within Stripe's 30-day events window)

Design notes:

Read-only by design: only calls list/retrieve endpoints, never writes. v0 takes no corrective action on purpose.
Clean architecture: a pure core (no I/O, no stripe import) behind a thin read-only adapter, so detection is unit-tested with fixtures and zero network (47 tests).
Not a sync engine — it works a level up: read, evaluate, report. Pinned to stripe-node v22 / API version 2026-06-24.dahlia. Dual ESM+CJS, MIT.
It's v0.1.0 and honest about its limits (two detectors need your app's state; the event window is 30 days; it never remediates). I'd love feedback on what other read-only signals are worth catching.

npm: https://www.npmjs.com/package/stripe-connect-reckon
GitHub: https://github.com/tonytonycoder11/stripe-connect-reckon

DEV Community: AS

Your quantized model got worse, and nothing told you

One document, three readers

The generated side

The bit I actually care about

The thing I got wrong

What it doesn't do

Where it is

Kmemo 2.0 is out, and the two gaps I admitted to in the first post are closed

Gap one: I never said what a verifier catches

Gap two: the comparison was against a baseline I built myself

The comments found something I had missed

What else shipped

Upgrading from 1.x

Kdrant 2.0: I removed the reason to use the official client

Same client, your choice of wire

The test suite turned out to be the interesting part

The core is multiplatform

What upgrading costs you

Try it

The cleanup that could never run: a silent Web Push leak in Go

The code

Why it can never run

What it cost

The fix

The tests, and the part I am glad I did the slow way

The PR

What I took from it

The half-fixed bug: two upstream crashes in dio and flutter/packages

Project Overview

Bug Fix or Performance Improvement

1. dio: FormatException on an empty response body

2. flutter/packages: a crash when a picked file can't be copied

Code

My Improvements

dio: widen the guard instead of adding a branch

flutter/packages: return null instead of an invalid object

What I took from both

We built the benchmark we'd want any AI estimation vendor to pass. Then we failed it.

The bar, frozen before any result

Four choices that make a negative worth reading

Channel A: tabular

Channel B: the requirement text

Two things survived

The follow-up that surprised me

What this does not prove

Run it yourself

Why publish this

Kmemo: a semantic cache for LLM calls that refuses to serve you the wrong answer

What Kmemo does about it

Quick start

Every miss tells you why

Scopes

Choosing how strict to be

What lexical guards can't see

The numbers

Calibrate the threshold, don't copy it

Stores, resilience, observability

Integrations

Try it

Kdrant: an idiomatic, coroutine-first Kotlin client for Qdrant

Kdrant

Quick start

A filter DSL that reads like Kotlin

Decode results straight into your types

Hybrid search (dense + sparse)

Integrations

The honest tradeoff

Try it

Stripe-connect-reckon – a read-only monitor for Stripe Connect balance risk

1. dio: `FormatException` on an empty response body