# KyaniteLabs Full AI Context > Longer machine-readable context for answer engines, agents, and research tools. For the short canonical brief, use https://kyanitelabs.tech/llms.txt. KyaniteLabs is operated by Simon Gonzalez De Cruz / PuenteWorks. It publishes open-source tools, build notes, implementation paths, and operator assets for people who want AI tools, MCP servers, media pipelines, localization QA, repo diagnostics, and domain software working in real environments. Parent business and broader consulting home: https://puenteworks.com ## Canonical Public Surfaces - Homepage: https://kyanitelabs.tech/ - Blog: https://kyanitelabs.tech/blog - Implementation help: https://kyanitelabs.tech/implementation - Implementation intake: https://kyanitelabs.tech/implementation/intake - Shop: https://kyanitelabs.tech/shop - Spanish edition: blog, about, and implementation pages (translation parity in progress). - About Simon Gonzalez de Cruz: https://kyanitelabs.tech/about - PuenteWorks parent business: https://puenteworks.com - Sitemap: https://kyanitelabs.tech/sitemap.xml - Structured AI sitemap: https://kyanitelabs.tech/ai-sitemap.json - RSS feed: https://kyanitelabs.tech/feed.xml ## Public Project Proof ### Kinocut - URL: https://kinocut.dev - Source: https://github.com/KyaniteLabs/kinocut - Category: Media MCP - Language: Python - Updated: 2026-09-01 - Description: Guardrailed video editing for AI agents: MCP server, kino CLI, Video Receipts, and Hyperframes. - Proof role: The flagship proof that agents can operate timelines, effects, and repeatable media pipelines. ### tastecheck - URL: https://kyanitelabs.github.io/tastecheck/ - Source: https://github.com/KyaniteLabs/tastecheck - Category: Frontend Craft - Language: Markdown - Updated: 2026-09-04 - Description: Design review skills and recorded evidence for typography, color, spacing, accessibility, interface states, and frontend ship decisions. Judgments are scoped assessments, not an effectiveness guarantee. - Proof role: The public landing page shows the review workflow and example systems; release evidence and effectiveness are separate claims. ### Epoch - URL: https://kyanitelabs.github.io/Epoch/ - Source: https://github.com/KyaniteLabs/Epoch - Category: Estimation MCP - Language: TypeScript - Updated: 2026-09-02 - Description: Time estimation MCP server for PERT, COCOMO II, Monte Carlo, sprint forecasting, token-to-time mapping, cost estimation, and schedule risk tools. - Proof role: Turns planning uncertainty into agent-callable forecasting tools. ### checkyourself - URL: https://kyanitelabs.github.io/checkyourself/ - Source: https://github.com/KyaniteLabs/checkyourself - Category: Readiness Audit - Language: Python - Updated: 2026-09-04 - Description: Local completion-evidence review for AI-built apps: read-only audits, verifier challenges, bounded scores, guided fixes, learning plans, CLI, and MCP. Scores do not certify production safety. - Proof role: Makes quality, security, and launch risk inspectable before an AI-built app ships. ### DialectOS - URL: https://github.com/KyaniteLabs/DialectOS - Category: Localization MCP - Language: TypeScript - Updated: 2026-09-04 - Description: Spanish dialect localization MCP server and CLI across 25 regional variants with register control, structure preservation, and QA gates. - Proof role: Makes Spanish launch quality inspectable instead of treating localization as generic translation. ### resonant-gifts - URL: https://github.com/simongonzalezdc/resonant-gifts - Category: ResonantOS Ecosystem - Language: None - Updated: 2026-09-04 - Description: An honest index of the Resonant gift line: 19 open-source gifts built for the ResonantOS ecosystem — measurement benches, security tooling, local-service add-ons, and receipted knowledge. - Proof role: Indexes the full line — every gift public, licensed, and independently reviewed. ### resonant-constable - URL: https://github.com/simongonzalezdc/resonant-constable - Category: ResonantOS Ecosystem - Language: Python - Updated: 2026-09-03 - Description: Injection defense + contest for the ResonantOS ecosystem: the doctrine, a labeled corpus of known public attack classes on synthetic fixtures, and a stdlib-only reference checker. - Proof role: The defense discipline behind a merged upstream security fix, made reusable. ### resonant-authority - URL: https://github.com/simongonzalezdc/resonant-authority - Category: ResonantOS Ecosystem - Language: Shell - Updated: 2026-09-02 - Description: The ResonantDAO whitepaper's contextual-authority mechanism as a self-contained add-on: weight from verified outcomes in exactly the dimensions a question declares salient. - Proof role: The whitepaper's governance mechanism as working code — non-canonical, MIT. ### liminal - URL: https://github.com/KyaniteLabs/liminal - Category: Creative Coding - Language: TypeScript - Updated: 2026-09-01 - Description: AI creative coding studio for p5.js, GLSL, Three.js, music, video, and model-agnostic generative art workflows. - Proof role: Shows Kyanite can build creative tools where agents touch code, shaders, media, and taste. ### liminal-sites - URL: https://github.com/KyaniteLabs/liminal-sites - Category: Living Websites - Language: TypeScript - Updated: 2026-09-02 - Description: Site surfaces and public faces for the Liminal / Sinter stack, focused on shipping Liminal product sites. - Proof role: Proves the website itself can evolve through constrained, inspectable design systems. ### Elixis - URL: https://github.com/KyaniteLabs/Elixis - Category: Pattern Synthesis - Language: Python - Updated: 2026-09-02 - Description: Local-first pattern synthesis engine for identity, brand voice, design systems, naming research, and lens-specific outputs. - Proof role: Turns fuzzy identity and naming work into source-backed synthesis. ### Innerscape - URL: https://github.com/KyaniteLabs/Innerscape - Category: Personal OS - Language: TypeScript - Updated: 2026-09-02 - Description: Personal growth OS in TypeScript for journaling, emotional check-ins, habits, goals, tasks, sleep logs, decluttering, and self-awareness workflows. - Proof role: Shows the same build-and-implementation pattern applied to intimate, data-rich workflows. ### devarch-framework - URL: https://github.com/KyaniteLabs/devarch-framework - Category: Repo Intelligence - Language: Python - Updated: 2026-09-02 - Description: Git repository archaeology framework for mining commit history, detecting signals, running 6 analysis vectors, and generating engineering reports. - Proof role: Shows Kyanite can turn development history into evidence, not vibes. ### Dev Learning Archaeologist - URL: https://github.com/simongonzalezdc/dev-learning-archaeologist - Category: Learning Diagnostics - Language: JavaScript - Updated: 2026-09-02 - Description: Forensic git-history learning diagnostic for AI-assisted developers that turns commit history into evidence-backed study plans and HTML reports. - Proof role: Turns repo behavior into a readable diagnostic artifact. ### achiote-food-memory-researcher - URL: https://github.com/simongonzalezdc/achiote-food-memory-researcher - Category: Food Memory - Language: Claude Project - Updated: 2026-09-02 - Description: Folder-based AI food-memory researcher for investigating half-remembered family dishes from sound-alikes, smells, colors, and cultural memory. - Proof role: Extends Kyanite's evidence style into cultural memory and research assistants. ### unstuck-coach - URL: https://github.com/simongonzalezdc/unstuck-coach - Category: Executive Function - Language: CSS - Updated: 2026-09-01 - Description: Executive-function accessibility coach that turns a messy stuck point into one humane next move. - Proof role: Applies agentic tooling to accessibility, pacing, and human next-step design. ### tradesflow - URL: https://github.com/simongonzalezdc/tradesflow - Category: Field Operations - Language: TypeScript - Updated: 2026-09-01 - Description: Portfolio prototype for asset-heavy field-service operators: equipment records, service notes, deficiencies, scheduling, and billing handoffs. - Proof role: Shows implementation thinking for real-world operators with assets, visits, and billing handoffs. ### healthadvocate - URL: https://github.com/simongonzalezdc/healthadvocate - Category: Health Advocacy - Language: Python - Updated: 2026-09-02 - Description: FastAPI health advocacy web app for patient tooling, local LLM exploration, and medical NLP workflows. - Proof role: Explores private, local-first health tooling without treating care context as generic chat. ### openglaze - URL: https://github.com/KyaniteLabs/openglaze - Category: Domain Software - Language: Python - Updated: 2026-09-02 - Description: Free open-source ceramic glaze calculator, UMF analyzer, CTE estimator, recipe manager, and studio tool for potters and ceramic artists. - Proof role: Proves Kyanite can ship useful software outside the generic AI-tool bubble. ## Products No paid products are currently listed. More tools are in development. ## Free Resources ### Free Resources - URL: https://kyanitelabs.tech/magnets - Description: Index of KyaniteLabs worksheets, checklists, settings cards, and model-selection references. ### Qwen3.8-27B Settings Card - URL: https://kyanitelabs.tech/magnets/settings-card - Description: A practical local-model settings reference. ### Agent Delegation Worksheet - URL: https://kyanitelabs.tech/magnets/delegation-worksheet - Description: A worksheet for splitting agent work into bounded, verifiable lanes. ### Evaluation Design Checklist - URL: https://kyanitelabs.tech/magnets/eval-checklist - Description: A checklist for designing evaluations with evidence and failure controls. ### LLM Comparison Cheat Sheet - URL: https://kyanitelabs.tech/magnets/llm-cheat-sheet - Description: A snapshot-based model-selection reference for intelligence, cost, and speed. ## Blog and Lab Notes ### Play-1: the acceptance-inversion result - URL: https://kyanitelabs.tech/blog/play1-numbers - Date: 2026-09-28 - Category: Measured Research / Speculative Decoding - Primary keyword: Play-1 speculative decoding acceptance - Summary: The measured nmax2 acceptance inversion: 72.2% versus 22.7% for the draft-12 control. Throughput and engine comparisons, with single-lab limits. - Body: The nmax2 drafter accepted 72.2% against 22.7% for the draft-12 control in this measured workload. Acceptance is one result. The throughput figures and the limits belong beside it. The reported measurements Draft-12 control: 17.5 tokens per second . nmax2-np2: 25.4 tokens per second . nmax3: 28.5 tokens per second . nmax4: 23.9 tokens per second . Engine comparison on the same box: HIP 20.8 tokens per second; Vulkan 9.2 . The nmax3 figure is higher than nmax2-np2 in the reported run. That does not turn this short report into a universal configuration ranking. The original report does not supply sample counts, confidence intervals, every comparison table or a full reproduction recipe. What backs these numbers The September 28 report states that every figure was dual-verified. Its named verification record is research/floor-optimization/window4/W4-VERIFICATION-RECEIPT-20260925.md . That is the original report's provenance statement; this page does not claim a new independent verification of the underlying experiment. Limits One lab, one box class and the lab's own workloads. No external reproduction is claimed. Acceptance percentages are not tokens per second, and these figures do not establish a general speedup for other hardware or models. This edition preserves the already-public measurements. It adds no new experimental result. ### Adversarial custody chains: keep the attacks in the record - URL: https://kyanitelabs.tech/blog/adversarial-custody-chains - Date: 2026-09-28 - Category: Measured Research / Evidence Custody - Primary keyword: adversarial custody chains research evidence - Summary: Signed permissions and hash-chained receipts catch real bypasses. Two acceptance-path defects were still open in the source report. - Body: A lab that generates its own test data needs to show how its evidence can fail. The September 28 report records attacks against a small lab's custody chain and the defenses those attacks forced. The attack ledger Forged permissions. Fabricated authorization attempted to admit test-pool items. The reported defense uses signed permission from a key held outside the producing system and an issuer ratified by the organization. Fake receipts. Outputs were claimed without generation. Append-only, hash-chained indexes and per-item content hashes make acceptance depend on resolving the chain. Frozen-field replacement. A verified record could still be mutated through language-level escape hatches. The proposed repair re-derives the registry from signed canonical bytes inside the trust boundary. Marker forgery. A reachable module marker allowed an attacker key to construct an accepted state. The proposed repair removes caller-constructible acceptance paths. Two defects remained open The source explicitly marks frozen-field replacement and marker forgery as open, with repairs under review. This historical report does not establish that either repair later passed. A new verdict would need its own evidence. The method worth copying Separate producer and reviewer custody. Pin artifact hashes when outputs are created. Run probes that construct bypasses, then require the repaired path to refuse those same probes. Keep failed runs and rejected claims in the record. Limits One team and one measurement program. The reviewer was separate from the producer, but was not an independent organization. No external red team, external audit or proof of unforgeability is claimed. The report offers an attack ledger and a repeatable method. It leaves open defects visible rather than treating internal review as a security certification. ### Local image generation, measured on a consumer APU - URL: https://kyanitelabs.tech/blog/local-image-stack-measured - Date: 2026-09-28 - Category: Measured Research / Local Image Generation - Primary keyword: local image generation consumer APU measurements - Summary: Measured sampler costs, guidance timing and model reload overhead. Quality judgments remain single-judge observations, not a leaderboard. - Body: The useful question is what this image stack actually did on this machine. The September 28 report describes an approximately $1,000 consumer APU, an 8-core Strix Halo, 80 GiB of GTT shared memory and a 7B diffusion transformer in Q4_K. Measured timing and memory Co-residency: 5.84–5.88 seconds per iteration across the measured memory modes, with both resident LLM services live. Peak GTT was 58.8 GiB out of 80, with approximately 15.5 GiB RAM free. Sampler cost: at 30 steps, euler and euler-a were speed-identical. dpm++2m added 5.6% at guidance 4 and 15.9% at guidance 6. At 6 and 10 steps, the report found no speed separation. Guidance timing: 191.7 seconds at guidance 4 versus 211.4 at guidance 6 per 768×512 image, with n=10+10. That is a timing comparison; paired quality assessment remained pending. Reload overhead: approximately 15–20 seconds per fresh CLI invocation. A 20-image batch spent about 6 minutes of roughly 65 minutes reloading. The suggested approximately 9% throughput improvement was an estimate, not a measured adoption result. Full-quality run: roughly 3.2 minutes per 768×512 image at about 54 W GPU-package power. The reported CPU-only comparison was roughly 29 minutes per image and failed under sustained load. Quality was a human judgment One internal human judge preferred dpm++2m at 30 steps and found it usable at 6 steps. The same judge reported successful stitched lettering. Those are labeled single-judge observations. An empty OCR result on those images was reported as an instrument artifact; this page does not extend that finding to other images. Limits and unresolved work One machine class, one model family, no blind scoring and no inter-rater statistics. The source still listed paired guidance-quality judgments and like-for-like comparison cells as unresolved. These historical findings are not a current model ranking, a hardware guarantee or permission to use particular weights commercially. The transferable method is a frozen run plan, paired seeds, append-only indexes, per-image sidecars and exact output hashes. The numbers stay attached to the conditions that produced them. ### GPT-6 Sol vs. Luna vs. Astra: a routing policy for coding agents — and when local still wins - URL: https://kyanitelabs.tech/blog/gpt-6-sol-luna-astra-routing-guide - Date: 2026-09-26 - Category: Model Routing / Agent Systems - Primary keyword: GPT-6 Sol vs Luna routing for agents - Summary: A routing policy for the actual GPT-6 lineup: Sol for discovery and coding, Luna for bounded high-volume processing, Astra when nothing else holds — each with a verification contract, and the lanes where a local 27B still beats all three. - Body: Correction first, policy second We previously published a routing guide for "GPT-5.6 Sol, Terra, and Luna." That naming was wrong: there is no GPT-5.6 generation and no Terra model. The real lineup is the GPT-6 family — Astra (September 3, 2026) and Sol and Luna (September 22, 2026). We deleted the social posts carrying the old names and kept this page as published history. This post replaces the policy with verified facts and labels everything we could not verify. The verified lineup (as of 2026-09-26) GPT-6 Astra — launched 2026-09-03 as the frontier lane: the most capable model in the family, positioned for the hardest reasoning work. GPT-6 Sol — built for complex work, coding first among it. OpenAI states Sol makes about half as many mistakes as its 5.6-series predecessor, reaching Astra-level reliability at lower cost. GPT-6 Luna — high-volume tasks with a clear goal: summarizing, extraction, quick answers. The only one of the three in the desktop app and on Free/Go plans. Price: the 6-series API costs half of the 5.6-series Sol/Luna, attributed to caching and inference gains. Availability: Sol and Luna are in ChatGPT Work, Codex, and the API for most paid accounts; Astra on Pro, Enterprise, and Business Premium. Labeled uncertainty: the factuality and comparison claims above are OpenAI's own; the context window for Sol/Luna was not published at launch and we will not guess it. Public coverage: TechCrunch, 2026-09-22 . The routing policy The lanes that mattered in our GPT-5.6-era policy survive intact — only the model names change, because the task shapes they map to did not: Discovery lane → Sol. Unknown path, unknown failure mode, or a coding task where the spec itself is shaky. Give Sol an evidence target and an exit condition, not a step list. The completion contract is a finding, not a file. Volume lane → Luna. Bounded, repeatable, high-count: extraction, summaries, classification, quick answers. The completion contract is a schema — Luna's job is to never be interesting. If a Luna output surprises you, that is a routing bug, not a model win. Frontier lane → Astra. The problems that are only expensive until they are solved: novel architecture, deep debugging across systems, anything where the cost of a wrong answer dwarfs the token bill. Astra is the model you route to when the routing question itself is the hard part. Verification contracts, per lane The routing decision is half the policy; the other half is what you check: Sol output: verify the claims — run the tests, execute the diff, re-derive the reasoning. Sol-grade code still needs a harness before it is trusted. Luna output: verify the shape — schema validation, spot-check sampling, count reconciliation. Deep review of every Luna output means Luna was the wrong lane. Astra output: verify the premise — the expensive lane earns review of whether the problem was framed right, since a confident wrong frame is the failure mode that survives every test suite. Where a local model still wins We route a 27B-class local model on a $1,400 mini-PC for real work, and the GPT-6 price cut does not close that gap. The local lane wins on: egress (nothing leaves the machine), marginal cost (tokens are electricity), and latency floor (no network hop). Our measured Qwen3.8-27B numbers — throughput sweeps, acceptance rates, the failures included — live in the public repo . The policy is not "local versus cloud"; it is: local for the volume lane when the task fits, cloud Sol/Astra for the lanes where capability is the bottleneck, Luna for cheap clerical volume that is not sensitive. What we do differently this time The retired guide failed on model names we did not verify. This post's facts were checked against the launch announcements and dated coverage the day of publication, every unverifiable claim is labeled, and the routing policy is ours — argued, not sourced. When the family changes again, the correction goes at the top of this page, the same way our benchmark re-baselines live beside the numbers they corrected. ### The Equalizer Bench: a 3B that can't write ffmpeg, the same 3B shipping video edits, and the bug our own benchmark caught - URL: https://kyanitelabs.tech/blog/equalizer-bench-small-models-video - Date: 2026-09-25 - Category: Benchmarks / Agents - Primary keyword: small model benchmark video editing MCP guardrails - Summary: We benchmarked our own thesis: tiny model + deterministic guardrail layer vs raw capability. The curve is textbook, the trim trap is real, and the bench indicted our own product before anyone else could. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ). 2026-09-25. Numbers measured 2026-09-24; every artifact on disk. Our working thesis, stated publicly enough times that it deserved measurement: a small local model plus a deterministic tool layer should match a frontier model working alone. For video editing we now have the numbers, and they are cleaner than the thesis predicted. The short version A 3-billion-parameter local model, asked to write raw ffmpeg commands, produced zero working commands out of twelve attempts . The same model, driving Kinocut ’s typed surface instead, shipped 4 of 12 — at lower latency than a 35B MoE writing raw commands. At 2B the lift is +80%. At 27B it is +10%. At 35B, parity. The guardrail compensates exactly where the model cannot, and stops mattering where the model is already competent. That curve is the whole product argument, now with cells instead of adjectives. The rig Twelve representative edit tasks (trim, resize, audio extract to mp3 and wav, 2× speed, rotate, thumbnail, WebM, center crop, 1fps frame export, animated GIF, self-concat) on one deterministic fixture: testsrc2 + sine, 10 seconds, 1280×720, H.264 + AAC. Two arms per seat. Alone : the model writes a raw ffmpeg command — what an unguarded agent does. + Kinocut : the model drives the kino CLI with its real help text in context, exactly as an MCP client sees the tool schema, and the deterministic engine builds and runs the actual ffmpeg. One verifier, blind to arm: the artifact must exist and pass every ffprobe check (duration, dimensions, codecs, streams, frame count). Commands execute argv-only — no shell — sandboxed, 240-second cap, temperature 0, fixed seed. local model alone (raw ffmpeg) + Kinocut latency, median 3B VL 0 / 12 4 / 12 540 ms → 337 ms 2B 5 / 12 9 / 12 (+80% rel.) 5.6 s → 2.2 s 27B 10 / 12 11 / 12 2.2 s → 2.6 s 35B MoE 11 / 12 11 / 12 (parity) 18.3 s → 9.6 s Full tables, method, and the per-cell caveats live at kinocut.dev/bench . The trim trap Every seat’s raw-arm “canonical” trim was the command an experienced human writes: ffmpeg -i input.mp4 -ss 2 -to 5 -c copy out.mp4 It exits zero. It reports the right duration. It silently drops the video stream — the stream-copy and output-seek interaction. A 27B model still writes it. This is the failure class that makes operators distrust agent-driven editing, and it is invisible unless you probe the output file. Our verifier probes the output file; that is the entire point of the blind-verification design. The bug our own bench caught The bench also indicted Kinocut itself. The documented absolute-end trim form ( kino trim -s 2 -e 5 ) produced a 5.00-second clip instead of a 2→5 cut: validation treated the end time as absolute while execution — input-seek rebasing timestamps to zero — treated it as relative. Two different seats used the documented form correctly and were scored FAIL by the rubric; the layer’s own bug cost it the task. Fixed in 1.15.2: the engine now converts the absolute end explicitly when input-seeking. With the fix, the capable seats read 10–12/12 on the Kinocut arm. A benchmark that cannot fail your product is marketing; this one filed the defect before any user could. Why this matters beyond kinocut The same harness shape — deterministic layer as the independent variable, blind verifier as the judge — now runs across our portfolio (tastecheck’s rubric unlock, checkyourself’s guaranteed floor). The pattern generalizes: stop asking whether models are smart, start measuring what your tool surface does to the competence floor. The frontier row in our tables is empty by policy until a sanctioned credential exists; we do not fabricate reference rows. Reproducibility Fixture: ffmpeg -f lavfi -i testsrc2... -f lavfi -i sine... 10s 1280×720 h264+aac, built by script, checksummed. Seats: four local models on the lab floor (3B VL, 2B, 27B, 35B MoE), on-disk weights, zero paid APIs, zero spend. Scoring: ffprobe-based blind verifier; argv-only execution; 240s cap; temperature 0, seed 42; single-shot (no repair rounds in either arm). Artifacts: runner scripts, fixture builder, and per-cell result JSON preserved in the bench directory; the public distillation is kinocut.dev/bench . Caveats we mean n=12 tasks, one run per cell; per-cell differences of ±1 are noise. Frontier hosted models were not run (no sanctioned credential; the row stays empty rather than invented). ASR/transcription and GPU-heavy renders were out of scope for the headless loop. The latency column is median single-shot latency under the bench harness, not a serving benchmark. And the K-1 bug means the published table understates the Kinocut arm on capable seats — we are leaving the measured numbers, not the flattering ones, in the table. Build on it, break it, or show us your hardware’s curve — that’s the conversation. Find us through the lab. ### The One-Line Bug That Crashed Our Fast Lane: finding, fixing, and measuring a speculative-decoding crash on a $1,400 mini-PC - URL: https://kyanitelabs.tech/blog/the-one-line-bug - Date: 2026-08-25 - Category: Local LLM / Serving - Primary keyword: speculative decoding llama.cpp draft model iGPU speedup - Summary: Spec decoding crashed our fastest lane on day one. The bug was one missing line in our fork; the fix bought +17.7% and a surprise about draft quantization. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ). 2026-08-25. The complete measured answer. Everything below happened on one machine: an AMD Strix Halo mini-PC (Ryzen AI Max+ 395, gfx1151, ROCm/HIP) that serves our models 24/7. We measured every step on the box itself, published every failure, and changed nothing we couldn’t verify. The receipts are at the bottom. The short version Speculative decoding — a small “draft” model guessing ahead of the big model — should have made our fastest model 20-40% faster. Instead, it crashed our server instantly. The bug was in our own fork, it boiled down to a single missing line of code, and fixing it delivered +17.7% measured speedup with byte-identical outputs. Along the way we found a counter-intuitive result about draft-model quantization that we haven’t seen published anywhere: the “cheaper” quantized draft was SLOWER than no draft at all. The setup Our lab serves a 27B champion model around the clock from a $1,400 consumer mini-PC. For cheap, high-volume jobs (formatting, glue code, summaries of short text), we keep a second, tiny model loaded alongside: LFM2.5-2.6B, a 2.6B model that decodes at ~94 tokens/second on this box — the fastest thing we’ve ever measured here. DSpark is a draft model for the LFM2 family: a small companion network trained to predict the big model’s next few tokens. The server drafts with it, the main model verifies all drafted tokens in one pass, and accepted tokens come out in batches. (The acceptance rate is the share of drafted tokens the main model approves.) When it works, you get the main model’s exact outputs, faster. The crash We fired up the 2.6B with its DSpark draft attached. The server loaded both models, announced the speculative implementation, and hard-aborted at the first decode step: GGML_ASSERT(t_layer_inp[il] != nullptr) — llama-graph.cpp, draft graph_reserve Every time. Both draft quantizations. Every draft-length setting. Before a single token came out. The natural suspects were the draft model itself, or upstream — llama.cpp, the open-source inference engine everything here runs on. We eliminated both: stock upstream llama.cpp, with the recently merged “support DSpark for LFM2 models” patch ( #27383 ), ran the exact same model pair cleanly. The crash lived in our fork. The bug Our fork (like many production forks) carries a stack of patches, and it had drifted: upstream’s LFM2 support had gained three pieces ours lacked — registering LFM2 for recurrent-state rollback, snapshotting the convolutional state into per-step slots, and, crucially, one line in the layer loop: res->t_layer_inp[il] = cur; That line hands each layer its input tensor so the graph builder can record the dataflow. Without it, the draft graph reserved memory for layer inputs that were null — and the first null check aborted the server. One line of missing wiring; total speedup, zero. The fix and the numbers We ported the three upstream pieces into our fork (a 2-file diff, +18/−8), built in an isolated directory, and ran the same paired measurement on each arm: same prompt, temperature 0 (deterministic, greedy output), three runs per arm, on the live box — quiet-box state: only the three product-floor residents loaded. arm runs (tok/s) median vs baseline no draft 93.5 / 94.1 / 93.9 93.9 — DSpark F16 draft 102.7 / 110.5 / 130.0 110.5 +17.7% DSpark Q8_0 draft 65.6 / 74.4 / 80.3 74.4 −20.8% DSpark F16, long-horizon (1,200 tok) 141.4 141.4 +50.6%* Acceptance (the share of drafted tokens the main model approves) ran 0.64–0.80 on short prose across the session’s raw logs and climbed to 0.89 on a sustained 1,200-token generation — the speedup grows with horizon as the draft warms into the text: 110.5 → 141.4 tok/s on the same arm. *Cross-horizon comparison, labeled: the no-draft arm was not run at 1,200 tokens — the +50.6% is the 1,200-token drafted run against the 93.9 no-draft short baseline. And the speedup is free: a 120-token greedy completion (one spot check, n=1) came out byte-identical with and without drafting, and a full GSM8K run (the standard grade-school-math benchmark; first 100 problems, strict final-answer grading, temperature 0) scored 57.0% with the draft (57/100, zero errors) against a 53.3% spec-off control (32/60, our separate control run) — unpaired arms, still statistically indistinguishable (two-proportion p≈0.65), no degradation signal. The two code paths give identical bytes on the greedy check; where capped batch runs differ, they differ at the truncation margin. Speculative decoding here changes the clock, not the answers that matter. The surprise: quantizing the draft makes it slower We expected the Q8_0 draft — half the memory, the usual “basically free” quantization — to land between baseline and F16. It came in 21% BELOW baseline, with essentially the same acceptance rate (~0.80). The drafts were equally good; verifying them was equally fast; the draft model itself got slower to run. On this iGPU, dequantizing the small draft network on every drafting step costs more than the memory savings buys back. For 2.6B-class drafting on gfx1151, the F16 draft is the only arm that pays. We haven’t seen this datapoint published for this hardware class. It’s a small result, but it’s the kind you only get by running all three arms on the same silicon instead of assuming the quant tradeoff transfers from the big-model world. What this means for us The 2.6B lane now serves with identical outputs at a 110.5 tok/s median on the quiet-box band where we certified it (an evening re-read after a champion restart read 96.4/88.8 short/long — decode on this box is load-dependent and every number carries its box state) — roughly 18% faster for the cost of one line of wiring and a fork-rebase. The lane keeps the job description our published delegation benchmark gave it (open source, delegation-bench ): superb for small, simple, high-volume jobs; wrong for long-context, trap-detection, or anything safety-shaped. Speed doesn’t change the job description; it changes the throughput of the jobs it already does. Reproducibility Hardware: AMD Strix Halo (Ryzen AI Max+ 395, gfx1151), 64GB unified, ROCm/HIP build, Release, GGML_HIP_GRAPHS on. Main model: LFM2.5-2.6B Q4_K_M; drafts: DSpark F16 and Q8_0. Server flags: defaults (draft auto-detected, n_max=3), -ngl 99, ctx 8192, temperature 0, 3 runs/arm at 200 tokens/run (prose prompt; the long-horizon arm is one 1,200-token run, the byte-check 120 tokens). Fix: port of upstream #27383 — fork branch dspark-lfm2-fix; 2 files, +18/−8. Upstream thread with our confirmation comment on gfx1151: github.com/ggml-org/llama.cpp/pull/27383 Crash logs, build logs, and per-run raw numbers preserved on the box. Caveats we mean Speed arms are n=3 on one prose prompt (pilot-class); the long-horizon run is n=1 at 1,200 tokens. Acceptance is content-dependent (other tasks have read 0.50 and 0.53). The GSM8K pair is n=100 strict with a 512-token cap (52/100 answers hit the cap — the strict ceiling there is truncation, on both arms’ grading style). GSM8K set source: HF openai/gsm8k test split, first 100. Every number above came from the box that serves our traffic, during a normal day, with our production 27B serving throughout (it self-restarted once mid-network-outage during this work — unit-recovered, unrelated to the lane). Questions, corrections, or “we see the same Q8 regression on [your hardware]” — that’s exactly the conversation we want. Find us through the lab. ### Two models, one $1,400 mini-PC: the paired numbers, failures included - URL: https://kyanitelabs.tech/blog/two-models-one-mini-pc-paired-numbers - Date: 2026-08-25 - Category: Local AI Infrastructure - Primary keyword: run two local llms on one mini pc paired benchmark - Summary: A 35B reasoning model now runs shoulder to shoulder with our daily 27B on one $1,400 box, at the same time. Every number paired, same problems, same machine. The failures are in here too. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ), assisted by GLM-5.3. 2026-08-25. Every number below was re-read from raw result files on this machine before writing. We run a small AI lab on hardware that fits under a TV: one AMD Strix Halo mini-PC with 64GB of shared memory. A Qwen3.8-27B has been our main model and daily engine here since mid-August. This week we asked a harder question: can this same box also run Ornith-1.5-35B, a bigger open-weights model, at the same time, and is it actually any good when you measure it fairly? The answer is yes, with three caveats. Here is everything, including what failed. One number below was first measured wrong by our own tool. Story at the end. The setup One machine. Two models, resident at the same time, no switching: Qwen3.8-27B (our "champion", serving the product): 262k context, vision attached. Ornith-1.5-35B-A3B (the newcomer, thinking-on lane): a Mixture-of-Experts build that only activates ~3B parameters per token. We run an APEX-Compact quantization at 17.4GB. Together the two models use 43.4 of 64GB, with about 20GB to spare. That "to spare" matters: this only fits because of a memory trick we checked (see below). The stock quant at ~22GB also fits, but with less headroom. The scoreboard, every number paired, same problems, same machine We never compare two numbers that came from different places. Both models ran the same fixed problem sets, back to back, on the same box: Test Champion 27B Ornith 35B Read Grade-school math (GSM8K, strict grading, paired 2×2, same 60 problems, n=60/cell) 96.7% thinking off; 96.7% thinking on (identical outcomes, McNemar p=1.0) 90.0% thinking off; 98.3% thinking on (p=0.0625, marginal at n=60) At each model's best config: a one-problem tie (p=1.0). Thinking costs the champion 2.4× time for zero gain; Ornith needs it Code, clean problems (HumanEval, same frozen 30) 28/30 26/30 Tie within noise Code, real-world (LiveCodeBench, same 30) 20/30 17/30 Slight edge champion, not decisive at n=30 Vision, same 6 real screenshots 6/6 5/6 Ornith misread an email address in a form (typo'd the domain) If you only remember one row: a 35B reasoning model now runs shoulder to shoulder with our daily driver on this class of hardware. Until paired measurements like this, that was a forum argument. The three caveats Thinking is a dial, not a model gap. Measured paired (2×2, same problems, same protocol): the champion scores 96.7% with thinking off AND on (identical outcomes, p=1.0), so its thinking switch buys nothing here at 2.4× the time. Ornith scores 90.0% without thinking and 98.3% with it. At best configs the two models tie within one problem (p=1.0). Earlier numbers that compared Qwen thinking-off against Ornith thinking-on were regime-mismatched; this paired table is the truth and it replaces them. Code is a tie, not a win. 26/30 vs 28/30 on identical problems is within noise. We will not claim a code champion from this data. Vision has one miss. On a real signup-form screenshot, Ornith returned an email with the domain misread. That is a wrong answer, not a near-miss. Our champion got all 6. Small sample, labeled: 5/6. What did NOT work (the part few publish) We tested speculative decoding two ways, because it promised free speed: The trained draft head shipped in APEX builds: accepted only ~33% of draft tokens, and made generation ~9% slower end to end. Dead on this hardware, measured, twice. An improvised draft : same ~33% class. Same verdict. Speculative decoding is a memory-bandwidth trick, and this machine's bandwidth goes to the two resident models. The right setting is OFF, and anyone running a similar box should start there instead of paying our discovery cost. The memory trick that made it fit The APEX-Compact build packs the 35B into 17.4GB (vs ~22GB stock at the same Q4 quality tier). We could not measure a quality cost at these sample sizes: grade-school math 95.0% vs 96.7% stock on n=60, and identical results on a 15-problem code reasoning set. That ~4.3GB saving is the difference between "one model at a time" and "both models always on," which is the whole point of the machine. Speed, labeled Writing a long answer: ~55 tokens/second sustained. A 200-word reply lands in about 6-7 seconds. A full thinking run on a hard problem: minutes. Reading long documents (prefill): we ingested 130,715 tokens, a whole book, in 359 seconds (~364 tokens/second), with the chip at 72°C the whole way. Long-context work is where this MoE build earns its keep. Our settings card (if you have the same box) Greedy decoding (temperature 0), q4_0 KV cache, speculative decoding OFF, APEX-Compact Q4 weights, math budget 2048 tokens, hard-code budget 8192 (2/30 problems still hit the cap, labeled, not hidden). Nothing here is exotic; all of it was measured against at least one alternative on this machine before we kept it. Why publish all of it Most "I ran a big model locally" posts show one screenshot and one tokens-per-second number. We think the valuable artifact is the paired, same-fixture table with the failures included, including the run where our own grading tool truncated the model's output and briefly told us the model was bad at math (0.467). It wasn't; our instrument was wrong. That difference is visible in the two saved configs. Same problems: 0.967. Both JSONs are cited below, because the instrument should be suspect as often as the model. Sources (raw result files, on-box paths): GSM8K paired 2×2 ~/exp/2x2-gsm8k/summary.json (champ 58/60 both cells; orn 54/60 off, 59/60 on; McNemar p=1.0/0.0625/1.0; median walls 28.3/68.5/11.4/23.3s; run 2026-08-24T19:42Z, live doors, self-test read before scoring). GSM8K Ornith stock corrected ~/exp/w1-35b/gsm-full-b/Ornith35B/results_2026-08-22T01-26-41.json (strict 0.9667); the false start results_2026-08-22T01-00-27.json (strict 0.4667, instrument truncation). APEX-Compact ~/exp/w4-35b/gsm-run.log (0.9500). HumanEval-30 Ornith ~/exp/w1-35b/bench-results-default.log (26/30); champion 28/30 ( ~/exp/bench-results-default.log , verified 2026-08-24). LiveCodeBench-30 Ornith ~/exp/w3b-35b/verdict.txt (17/30, trunc 2/30); champion 20/30 (recorded in the comparison design doc, READ; result bytes not yet located, labeled). LCB-15 parity ~/exp/w4-35b/lcb15-run.log (7/15, identical to stock). Vision real-UI: Ornith ~/exp/vision35b-results.log (5/6); champion ~/exp/vision-real-results.log (6/6). Decode speed ~/exp/w4-fire.log (no-spec 55.9 tok/s; spec slower 50.4 vs 55.2, paired, same binary). Prefill ~/exp/ornith-window-results.log (wall=359s, 130,715 tokens, 72°C). Speculative acceptance ~0.33: window-4 banked comparators. Memory: APEX-Compact 17.4GB weights; dual-resident 43.4/64GB GTT (live readback 2026-08-23). Regime note: earlier champion GSM8K readings of 70% strict and 98% predate the paired protocol and are superseded by the 2×2 for this piece. ### How I became a forward deployed engineer without a software engineer title - URL: https://kyanitelabs.tech/blog/how-i-became-a-forward-deployed-engineer - Date: 2026-08-24 - Category: Forward Deployed Engineering - Primary keyword: how to become a forward deployed engineer without degree - Summary: The title is new; the work is old. Twelve years of enterprise deployments plus public, measured AI work. The honest path, artifacts included. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ). 2026-08-24. The honest version, no resume inflation. You do not need a software engineer title to do forward deployed work, and my path is the proof. I hold no FDE badge from an AI lab. What I have is twelve years of deploying enterprise systems for real organizations, then a period of building and measuring AI on my own hardware with everything published. That combination is the job. This post is the path exactly as it happened, with the artifacts, and without inventing anything. Let me be precise about what I am not claiming, because this industry runs on inflated claims. I was never employed as a software engineer. I never worked at Palantir or an AI lab. If you want those lines on a resume, this is not your post. If you want to do the work and be findable by it, it is. Phase one: twelve years of deployments nobody called FDE Enterprise learning systems: Workday, SuccessFactors, Cornerstone, for organizations of more than 8,000 people. That work was forward deployment in everything but name. Configuration for a real customer's strange requirements. Integrations with whatever systems already existed. Data migrations where an error means a person's training record disappears. Rollout, training, and then ownership in production, for years. The transferable skills from that world: reading a messy real workflow and finding where it actually breaks, writing for non-engineers, and treating go-live as the beginning, not the end. If you have done this kind of work in ERP, CRM, medical systems, or industrial software, you already have phase one. You just have not labeled it. Phase two: own the whole stack, then measure it The modern version of the job needs AI-specific skills. I built them in public, on my own hardware, because that removes every excuse. The rig is a $1,400 GMKtec EVO-X2 mini-PC running a 27B model locally. Everything below is linked and reproducible. Serving in production. The model runs always-on with watchdogs, restart recovery, and queue discipline. The complete measured serving story, with the upstream llama.cpp bug we caught, bisected, and validated the fix for, is on this blog . Benchmarking with intervals. 93% HumanEval (28/30, frozen subset) and 67% LiveCodeBench-30 (20/30, Wilson 95% interval 49 to 81). Published with conditions, seeds, and raw logs. An eval with my name on it. delegation-bench : 495 trials, 29 cells, certified floors, a sabotage cell, walk-away certification. This artifact does more work than any title. Details in evals are the FDE skill nobody lists . Shipped open source people actually use. A video-editing MCP server, Kinocut , with merged upstream contributions. Integration glue is the daily texture of forward deployed work. The exact recipe, if you want to copy it Step one: take a domain where you already know what "working" means. Step two: buy or rent hardware you control, or use cloud if you must, and run a real model workload on it. Step three: measure something honestly and publish the number with its interval and its conditions. Step four: build an eval for a decision someone actually makes. Step five: keep the system running unattended and write down what breaks. Do those five things and you will have what interviewers for these roles are actually probing for: evidence you can find the leverage point, build with evals, and own it in production. None of the five steps requires a title. All of them produce artifacts with your name on them. The honest gaps What this path does not give you: the internal referral networks of a big lab, experience with frontier-scale training runs, and the specific brand names that recruiters filter on. Those are real costs and I will not pretend otherwise. The compensation is that everything you claim is checkable, and the buyers who care about checkable are the buyers worth having. Start with the series: what a forward deployed engineer actually does , the title decoder , and the eval skill . Want this work done in your environment instead of reading about it? Implementation intake . Every artifact cited: delegation-bench (evals), qwen38-27b-strix-halo (serving), simongonzalezdc (Kinocut and other repos). Conditions for all numbers: $1,400 GMKtec EVO-X2, Qwen3.8-27B Q4_K_XL, llama.cpp. ### Evals are the FDE skill nobody lists: my 495-trial public benchmark - URL: https://kyanitelabs.tech/blog/evals-are-the-fde-skill - Date: 2026-08-24 - Category: Forward Deployed Engineering - Primary keyword: AI evaluation benchmark LLM evals - Summary: The market says it cannot find people who can build AI evals. The skill is learnable and I published mine: 495 trials, certified floors, sabotage cell, open source. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ). 2026-08-24. The case for evals as the core forward deployed skill, proven on a public artifact. Evals are the one forward deployed engineering skill the market says it cannot find, and almost no job posting lists it. An eval is a test you build that answers the only question a customer eventually asks: can I hand this system real work and walk away? If you can design that test, run it honestly, and report it with exact statistics, you can de-risk any AI deployment. That is the whole job in one skill. Mine is public: delegation-bench , 495 trials, open source. This post walks through what it measures and why the design is the part worth copying. First, why evals and not prompting or fine-tuning. Those are model-side skills. The forward deployed engineer sits on the other side of the model, where the questions are: which of this customer's jobs can this system take over, how reliably, and what happens when it fails. Vibes cannot answer that. Leaderboards cannot either, because they test the model in the abstract, not inside your workflow. Only an eval composed for the real decision answers it. What the benchmark measures delegation-bench asks one question: which of the operator's real jobs can be safely delegated to a local AI, consistently? Nine job classes taken from actual work: code, debugging, document search, summarization, data extraction, translation, chained reasoning, decisions, and safety. Each class runs size ladders, meaning small, medium, and large versions of the task. The tests are hidden: the system under test never sees them. The sealed holdout sets will never be published, and that is what keeps our own green honest. The design was pre-registered : published before any run, so nothing could be tuned after the fact. If you are building an eval for a customer, pre-registration is the trust move. It converts "trust me" into "I committed in writing first." The numbers 495 trials across 29 cells. Every capability cell passed 20/20, with certified floors of 81.9 to 86.1 percent. Eight cells earned walk-away certification, meaning 35/35 or 30/30 untouched confirmation trials, with floors of 90.5 to 91.8 percent: code, debugging, document search, reasoning, decisions, vision charts, vision terminals. "Certified floor" means exact Clopper-Pearson statistics: "at least 90.5 percent reliable," not "felt solid." There is a sabotage cell: a planted bad instruction that the system must refuse. And a decision table where every green carries its floor printed on it, so a non-engineer can read the verdict without knowing what a confidence interval is. The part everyone skips: judging the judge The hardest layer of an eval is not testing the model. It is testing your grader. Our first automated judges failed two cells. Reading the raw answers showed the model was right and our judges were wrong. One broke on a Spanish accent. One could not tell "mentioned the false number in order to reject it" from "repeated it as fact." Both bugs are now permanent regression cases in the repo. This is the skill in one story. A customer's deployment "fails" and the question is: model, pipeline, or measurement? The eval builder is the person who can answer, because they built all three layers and tested each. When long context and vision silently broke on my rig, the eval discipline was what caught it: bisected to one upstream llama.cpp commit, reported as issue 26209 , fixed and validated 9/9 paired. Without evals, that failure is invisible until a customer finds it. The honest misses, published Giant documents around 130k tokens are impractical on this rig. The ceiling is measured and the product now fast-fails with an estimate instead of hanging. Tiny-text transcription drops one letter in long email addresses: 12/15, labeled as such. Publishing the misses is not a weakness in an eval. It is the eval. How to start building this skill Pick one repeated task you actually do. Write ten test cases with answers you would stake money on. Run the system, grade blind, count honestly, and compute a floor (20/20 means at least about 82 percent, 30/30 at least about 90 percent). You now have the seed of everything I described. The full method, the statistics, and the code are in the repo . Related reading: what a forward deployed engineer actually does and how I became one without a software title . Need evals like this for a deployment you are responsible for? Implementation intake . Conditions: $1,400 GMKtec EVO-X2, Qwen3.8-27B Q4_K_XL, llama.cpp, tested through the real product (tokflint/tokpal). Exact stats: Clopper-Pearson floors, Holm correction across cells. Everything public except the sealed holdouts. ### Forward deployed vs solutions engineer vs implementation vs customer engineer: the title decoder - URL: https://kyanitelabs.tech/blog/fde-title-decoder - Date: 2026-08-24 - Category: Forward Deployed Engineering - Primary keyword: forward deployed engineer vs solutions engineer - Summary: Four titles, one job family, different coding bars. A decoder that reads any posting and tells you what you are actually signing up for. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ). 2026-08-24. Written for people comparing offers or postings at 1am. These four titles describe mostly the same job: an engineer who sits close to the customer and makes the product work inside the customer's reality. What actually differs is the coding bar, where you sit in the sales funnel, and who owns the outcome after launch. At many companies the titles are interchangeable. At a few, they are different careers. This post gives you the decoder: what each title signals, what does not change, and the three questions that reveal what a posting really wants. A note on stakes: the AI labs are hiring forward deployed engineers aggressively right now, and enterprises are starting to demand the same shape for AI that touches banks, insurers, and airlines. Title inflation is guaranteed. The decoder matters more than the name. The one-paragraph version of each title Forward deployed engineer (FDE): the engineer embedded with the customer's hardest real problem. Ships production code into the customer's environment, builds the evals that prove it works, and stays until it runs unattended. Highest coding bar of the four. The title comes out of Palantir and is now standard at the AI labs. Solutions engineer: the technical half of a sales motion. Runs demos, answers deep technical questions, builds proof-of-concepts, and unblocks evaluations. Coding happens, but the deliverable is the deal. You sit before the sale. Implementation engineer: the engineer who executes a defined rollout. The scope exists, the contract is signed, your job is configuration, integration, data migration, and go-live. Deep in the last mile, narrower in scope than an FDE, and usually no sales pressure. Customer engineer: the post-sale technical counterpart. Health checks, escalations, enablement, and a lot of "why is it slow this week." Closest to support of the four, with real engineering when escalations go deep. Google and several infrastructure companies use this name. The table Forward deployed Solutions Implementation Customer Where you sit Inside the hardest problem Before the sale After the sale, during rollout After go-live Coding bar Highest, production code Medium, demos and POCs Medium, configs and integrations Medium, escalations Typical deliverable Working system plus evals Closed deal Go-live Retained account Evals in the job? Core skill Unblocks the buyer's eval Sometimes Rarely Pager? Often yes No Go-live windows Escalation rotation You will like it if you want... Hard, messy, real problems Variety and velocity Finish lines Long relationships What does not change across all four You translate between two languages: the customer's workflow and the product's machinery. That skill is identical in every variant. So is the need to write plainly for people who are not engineers. If you have that translation muscle from any deploy-it-in-the-real-world job, you can move between these titles. I spent twelve years doing this shape of work in enterprise learning systems, Workday, SuccessFactors, Cornerstone, for organizations of 8,000+ people. The title on my badge was never any of these four. The work was. The three questions that decode any posting Question one: who writes code, me or the product team? If the answer is "you, in the customer's repo," it is an FDE job whatever the title says. If it is "you configure what exists," it is implementation. Question two: who owns the number? After launch, someone is accountable for the system actually working. If it is you, you are forward deployed. If it is sales, you are solutions. If it is support, you are customer engineering. Question three: where is the pager? Follow the on-call rotation. It tells you the truth about the role faster than any job description. How to prove you can do it, whatever the title Every variant of this job interview asks the same thing in different words: show me you made something real work somewhere hostile. The strongest artifact you can carry is an eval with your name on it. Mine is public: delegation-bench , 495 trials, certified floors, walk-away certification, sabotage cell. It has opened more doors than any title on my resume. Start here: what a forward deployed engineer actually does , and how I became one without a software title . Part of the FDE series. Need this kind of work in your environment? Implementation intake . Conditions and raw logs for every number cited: github.com/KyaniteLabs/delegation-bench . ### What does a forward deployed engineer actually do? A demo on a $1,400 mini-PC - URL: https://kyanitelabs.tech/blog/what-does-a-forward-deployed-engineer-do - Date: 2026-08-24 - Category: Forward Deployed Engineering - Primary keyword: what does a forward deployed engineer do - Summary: The straight answer, then the receipts: the whole FDE job run end to end on a $1,400 mini-PC, with public evals. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ). 2026-08-24. A straight answer first, then the receipts. A forward deployed engineer is the engineer who goes to where the AI has to actually work, and makes it work there. Not the person who trains the model. The person who takes a model that looks good on a benchmark and turns it into a system a real business can run every day. The job has three parts: find the leverage point in a real workflow, build the smallest thing that moves it, then stay and own it in production. The rest of this post is that sentence unpacked, demonstrated on a mini-PC that costs $1,400. The title is loud right now because the AI labs are hiring humans for it as fast as they can. The work is older than the name. Anyone who ever shipped software into a bank branch, a hospital, or a factory floor has done forward deployed work. I did versions of it for twelve years in enterprise learning systems. Now I run the whole job on my own hardware, and every number I will show you is public. Part one: find the leverage point Ten things in a business look automatable. Usually one of them matters. The forward deployed engineer finds it by watching real work, not by reading a pitch deck. The tool for this is measurement, not opinion. Here is a measured leverage decision from this desk. Should the local model think by default? We ran it both ways on a fixed problem set. On 40 hard problems, thinking rescued 15 that failed without it. On HumanEval-30, thinking bought nothing: 28/30 either way. So the shipped default is thinking off, with a manual override for hard tasks. That one routing decision saves tokens all day and costs nothing where the work is easy. Full method in the measured-knees note . Scale that pattern up and you get model routing: work moves across five lanes here, chosen by measured cost and speed, not by brand. Same discipline, bigger surface. Part two: build with evals The customer never asks "is it smart." They ask "can I hand it work and walk away." No leaderboard answers that. So the FDE builds the test that does. We built one. It is open source: delegation-bench . Nine job classes from real work. Hidden tests the system never sees. A sabotage cell with a planted bad instruction. Certified floors, meaning exact statistics that say "at least this reliable," not vibes. Result on this machine: 495 trials, 29 cells , every capability cell passed 20/20, and eight cells earned walk-away certification at 35/35 or 30/30 with floors of 90.5 to 91.8 percent. Code, debugging, document search, reasoning, decisions, two vision types: all at the walk-away bar. The coding skill underneath that is measurable too: 93% HumanEval (28/30, frozen subset, seed published) and 67% LiveCodeBench-30 (20/30, Wilson 95% interval 49 to 81, always cite the interval) on the same $1,400 box. Part three: own it in production This is the part that separates the title from the demo. The system runs unattended. It is always on, with automated watchdogs, restart recovery, and queue discipline. When it breaks, the FDE is the pager. A real production story from this rig: mid-project, long context and vision silently broke. The easy read was "the model got worse." We did not take the easy read. We bisected nights of changes to one upstream llama.cpp commit, reported it as issue 26209 , fixed it locally, and validated the upstream fix on our silicon with 9/9 identical paired answers. Then we re-ran the frozen benchmarks to confirm nothing moved. That is the job. The full serving story is on this blog with raw logs. The actual FDE skills list People search for "fde skills" and find wish lists. Here is the honest one, each skill proven by an artifact above: Evals and basic statistics. You can prove "at least 90 percent reliable" with exact intervals, or you cannot claim it. Integration glue. The AI never works alone. It sits in a pipeline with document stores, queues, and approvals. Environment debugging. When output turns to garbage, you find the layer that broke. Here it was a host buffer commit, not the model. Production ownership. Watchdogs, restarts, logs, and the willingness to be paged. Plain talk with non-engineers. The decision table ships with floors printed on it so an operator can read "walk away" without knowing what a quant is. What the job is not It is not prompt tricks. It is not a demo that works once on stage. And it is not data science: the FDE ships systems, not notebooks. If you like the last mile more than the lab, this is the job. If you like clean problems, stay near the model. Every claim in this post has a raw log or a public repo behind it. That is the standard. Point it at your own machine and see what your floors look like. Next in this series: the FDE title decoder (forward deployed vs solutions vs implementation vs customer engineer) and why evals are the FDE skill nobody lists . Need this kind of work in your environment? Implementation intake . Conditions for every number: $1,400 GMKtec EVO-X2, Qwen3.8-27B Q4_K_XL, llama.cpp, raw logs in delegation-bench and the stack repo . ### The Delegation Card: we asked a $1,400 mini-PC to take our jobs - URL: https://kyanitelabs.tech/blog/the-delegation-card - Date: 2026-08-22 - Category: Local LLM / Benchmarks - Primary keyword: local LLM delegation benchmark certified floors Strix Halo - Summary: Not is-it-smart but can-you-hand-it-work-and-walk-away. 495 certified trials, then re-validated at deeper n after the product changed: 965 total, floors to 92.8%. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ). 2026-08-22. The complete measured answer. We ended the 27B story with a frozen, measured machine . The next question was obvious: what work can it actually take over? Not “is it smart” — every benchmark answers that. “Can you hand it a job and walk away?” No published benchmark answers that. So we built one. The method Nine job classes from real work. Size ladders. Hidden tests the system never sees. A sabotage cell with a planted bad instruction. Certified floors — exact statistics that say “at least X percent reliable.” A walk-away tier: thirty-five perfect trials before any cell earns the “leave it alone” stamp. The benchmark is open source . The sealed test sets never publish. The results 495 trials, 29 cells. Every capability cell passed 20/20 (floors 81.9-86.1%). Eight cells earned walk-away certification at 35/35 or 30/30 (floors 90.5-91.8%). Code: 20/20 at every size. Debugging: 20/20. Document search: 20/20. Trap-bait summaries: 20/20. Data extraction: 20/20. Translation: 20/20. Chained reasoning: 20/20. Decisions: 20/20. Safety: 20/20. Vision: 15/15 on five of six types. Walk-away certification Eight cells each ran fifteen additional untouched confirmation trials. Every single one passed: code 35/35, debugging 35/35, document search 35/35, reasoning 35/35, decisions 35/35, vision charts 30/30, vision terminals 30/30. Certified floors: at least 90.5-91.8 percent. Re-gate update (2026-08-25): deeper n, stronger floors, one honest yellow The product changed after certification (new front-door work orders, an outage-continuity branch merged to main). So we re-ran the whole benchmark instead of trusting the old card: capability cells at n=25 (350 trials), walk-away confirmations at combined n=40 (90 trials), vision re-gate (30 trials). Total across both runs: 965 trials. Capability: 13 of 14 cells green at 25/25, floors 88.7% (deeper evidence than the certified 20/20). Walk-away: 6 of 6 cells at 40/40, floors 92.8% — up from 90.5-91.8%. Vision re-gate: 5/6 at 5/5, the form cell an honest near-miss (tiny-print OCR class, labeled). One yellow we kept: debug-medium 23/25 — two genuine misses where the model fixed the described symptom but not the dedup contract. Raw JSONL for everything is in the repo. Methods receipt: the re-gate caught our own harness in an attribution race under concurrent load — it scored an in-flight session’s empty interim message as the model’s answer. Patched, rescores documented, engine exonerated. The instrument gets audited like the model. The judge story Our first graders failed two cells. Reading the raw answers showed the model was RIGHT — our judges were wrong. One broke on a Spanish accent. One could not tell “mentioned the false number to reject it” from “repeated it as fact.” Both bugs are now permanent regression cases. The honest misses Giant documents (130k tokens) are impractical — the ceiling is measured; the product now fast-fails with an estimate. Tiny-text transcription: one letter dropped in long email addresses (12/15, labeled). What this proves A complete serving story on hardware anyone can buy, measured through a real product, every number reproducible. The card is public. The benchmark is open source. Point it at your own machine. Conditions: $1,400 GMKtec EVO-X2, Qwen3.8-27B Q4_K_XL, llama.cpp ROCm, tokflint/tokpal. github.com/KyaniteLabs/delegation-bench . ### Qwen 3.8 27B on Strix Halo: the complete measured story - URL: https://kyanitelabs.tech/blog/qwen-27b-strix-halo-complete - Date: 2026-08-21 - Category: Local LLM / Serving - Primary keyword: Qwen 27B Strix Halo optimal serving config llama.cpp - Summary: Every dial measured, every number public: the frozen optimal config for a 27B on a $1,400 mini-PC. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ). Arc close, 2026-08-21. The whole story, corrected on the record. We asked a simple question: can a $1,400 mini-PC serve a 27B model the way big rigs do? This note closes the book. Every claim below has a raw log behind it, in the public repo, with its methodology. The rig AMD Strix Halo, 64 GB shared memory, open tooling (llama.cpp), one free Apache-2.0 model. No cloud, no rentals. The ceiling Exact needle retrieval at every tested depth, two seeds, up to 261,130 of 262,144 tokens — 99.6% of the window , the literal ceiling. Warm follow-ups on a loaded 198k-token document: exact quote in 23.8s , yes/no in 10.0s , one-line summary in 17.5s . Format does not matter: prose or code, exact either way; described-in-words, every part comes back in order. Raw: nativemax-results.log · quote-rerun-results.log . The bug we owed you Mid-arc, long-context and vision silently broke on this GPU class. Our first read blamed the model — wrong. We bisected it to one upstream change ( c7d8722 ), reported it, fixed it locally, and validated the upstream fix on our silicon: 9/9 identical answers, paired . The correction is in the repo, on the record. Degeneration was the instrument, not the model. Raw: issue 26209 · pr25863-validation . The frozen config Weights Q4. KV cache light ( q4_0 ) — after measuring the trade: the heavy option buys up to ~3 seconds on follow-up questions (sub-second to 2.8s measured at the half window) for ~4 GB; we kept the room. Speculation: the shipped setup, verified fastest of four by paired walls ( 15.1s per 200-word answer vs 17.8s with it off ). Context: the full 262,144. Thinking: off by default, hard problems think — measured across three difficulty bands. Vision: works, 6/6 on real browser screenshots. Raw: config-27b-2026-08-21 . What this proves A complete serving story — speed, memory, quality, failure modes, and the fix trail — measured on hardware anyone can buy, with every number reproducible from the repo. That is the standard we wanted to set. The rig stays on this frozen config. Next chapter when we open it. Conditions: $1,400 GMKtec EVO-X2, Qwen3.8-27B Q4_K_XL, llama.cpp ROCm, 262,144-token window, K+V q4_0, temperature 0. Arc close. A table with linked logs: github.com/KyaniteLabs/qwen38-27b-strix-halo . ### Lab Notes: the measured-knees method for reasoning effort - URL: https://kyanitelabs.tech/blog/lab-notes-measured-knees - Date: 2026-08-20 - Category: Local LLM / Methods - Primary keyword: reasoning effort calibration knee Qwen3.8-27B - Summary: A methods note on reasoning-effort calibration. Thinking rescued 15/40 hards vs 4/40 off. On easy tasks it bought nothing. Publish the knee. - Body: By Simon Gonzalez de Cruz . 2026-08-20. Canon: FACTS-PACK; research lane: DSH/ICCO. This is a methods note, not a benchmark. We are publishing our calibration procedure because the interesting number is not a single tok/s or a single score — it is the knee where paying for more effort stops buying accuracy. The method. Take a fixed problem set, split by difficulty. Run each arm twice: once with the cheap configuration, once with the expensive one, everything else identical (same model, same quant, same temperature, same grader). Plot accuracy against cost. The point where the expensive arm stops beating the cheap one is the knee. Below it, you are paying for nothing. Our numbers. On a 40-problem hard/medium set, thinking-on rescued 15/40 hards vs 4/40 with thinking-off at temp 0 — a real gain exactly where the tasks are hard. On HumanEval-30, the same thinking budget bought nothing (28/30 identical). Full-sample: reasoning pays where tasks are hard, nothing where they are easy. Why publish it. The industry shipped this shape (effort-as-dial in reasoning models, complexity routers in coding assistants), but nobody publishes the local calibration curve — the number that says "on this hardware, with this quant, thinking stops paying past this difficulty." That curve is hardware-specific, and it is what we measure before we ship a default. The rule we run. Think-off by default. Think-on per request when the task is hard-class. Let the data, not the hype, decide the default. If a model ever auto-thinks, it must keep a manual override — every shipped auto-think without an escape hatch produces the same complaint: burnt tokens, no better output. ### Lab Notes: 67% LiveCodeBench-30 on a $1,400 rig - URL: https://kyanitelabs.tech/blog/lab-notes-livecodebench-30 - Date: 2026-08-20 - Category: Local LLM / Benchmarks - Primary keyword: LiveCodeBench Qwen3.8-27B Q4_K_XL Strix Halo - Summary: 20/30 = 67% LiveCodeBench-30 on a $1,400 mini-PC. Wilson 95% CI 49-81%. Easy 10/10, medium 8/10, hard 2/10. n=30 public subset. Not the card. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ). 2026-08-20. Canon: FACTS-PACK. The number first: 20/30 = 67% LiveCodeBench-30, best-per-problem across labeled arms, on a $1,400 GMKtec EVO-X2. Wilson 95% CI [49%, 81%] . Always cite the interval. n=30 is small; the interval is the honest number. Split: easy 10/10, medium 8/10, hard 2/10 . Champion: Qwen3.8-27B UD-Q4_K_XL, K+V q4_0, temp 0, livecodebench v6 public cases only, stratified 10/10/10, seed 20260820. A single-config cell (2048 tokens, thinking off) landed 13/30, with a reproduction at 14/30 and 25/30 per-problem agreement. That is a ±2-problem noise floor at temp 0 . Do not treat one run as exact. Thinking: on the 15 problems where no-thinking produced no code at 4096 tokens, thinking (budget 2048) rescued 5. Hard items leak prose that starves the code. On HumanEval-30, thinking bought nothing (28/30 identical). Citable line: reasoning pays exactly where tasks are hard, nothing where they are easy. This is not the official full-set LiveCodeBench card. Different instrument: we ran a 30-problem public subset at Q4 on this box. Band-check only, and say so. Contamination caveat: v6 problems (~May 2025) predate the model. If anything the number is inflated versus a clean window. The hard-split finding is the conservative-safe part. Raw: results/lcb-30-2026-08-20 . ### Lab Notes: we reverted a llama.cpp regression - URL: https://kyanitelabs.tech/blog/lab-notes-llamacpp-revert - Date: 2026-08-19 - Category: Local LLM / Benchmarks - Primary keyword: llama.cpp c7d8722 HIP vision NaN logits - Summary: We found a llama.cpp regression and reverted it. n=6 battery on a $1,400 rig: 0/6 slashes before, 5/6 after. Same Q4_K_XL. Not a quant story. - Body: By Simon Gonzalez de Cruz , assisted by GLM-5.3. The number first: 5/6 on a six-prompt VQA battery after one git revert. Before the revert: 0/6, all ////// to length. Same Qwen3.8-27B Q4_K_XL, same mmproj-F16, same $1,400 GMKtec EVO-X2. We found a llama.cpp regression and fixed it with a revert. Commit c7d8722 restored host-buffer use on HIP integrated GPUs. Prompts over ~2k tokens split across decode calls, produced NaN logits, and Qwen sampled / forever. Upstream: #26209 (bisected on this hardware), #23577 . What we tested (n=6, thinking off): Prompt Before After Time System graph slashes MISS: “Stacked bar chart” 1.8s Red image slashes HIT Red 0.3s Blue image slashes HIT Blue 0.7s Green image slashes HIT Green 0.6s Is this red? slashes HIT Yes 0.6s Is this a gradient? slashes HIT Yes 0.7s Five hits were sub-second. All six after the revert stopped clean ( finish_reason=stop ). This is not “vision works great.” It is a six-prompt battery on this $1,400 box after a one-line revert. Text HumanEval on the same binary stayed 28/30. Raw: vision-v5-after-fix.log · FIX-APPLIED.md . ### Lab Notes: 93% HumanEval on a $1,400 rig - URL: https://kyanitelabs.tech/blog/lab-notes-humaneval-93 - Date: 2026-08-19 - Category: Local LLM / Benchmarks - Primary keyword: HumanEval Qwen3.8-27B Q4_K_XL Strix Halo - Summary: 28/30 = 93% HumanEval on a $1,400 mini-PC. Qwen3.8-27B Q4_K_XL. Temp 0, thinking off. Failures: 50 and 145. Raw log linked. - Body: By Simon Gonzalez de Cruz , assisted by GLM-5.3. Night 4 addendum. The number first: 28/30 = 93% HumanEval on a $1,400 GMKtec EVO-X2 (Ryzen AI Max+ 395, 96GB unified). Qwen3.8-27B UD-Q4_K_XL. llama.cpp. 262k context. K+V q4_0. Temp 0. Thinking off. Frozen 30-problem subset, seed 20260819. Failures: HumanEval/50 and HumanEval/145 (runtime errors in generated code). Passes finished in 10s or less with zero thinking tokens. This is not the Qwen card. The card is bf16, different temp, different harness. We optimized what we tested. n=30 on a subset is not a ceiling. After we reverted a llama.cpp host-buffer commit on this $1,400 box, the same subset scored 28/30 again. Text did not move. Raw: bench-results.log · post-fix regression · README . ### Lab Notes: the model that can't forget but can't remember - URL: https://kyanitelabs.tech/blog/lab-notes-cant-forget - Date: 2026-08-19 - Category: Local LLM / Benchmarks - Primary keyword: Gated DeltaNet Qwen3.8-27B 262k context - Summary: The number first: this model is 75% not a transformer. 48 of 64 layers keep a running state. On a $1,400 rig, load 198k once (1818s), then query in 9-27s. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ), assisted by GLM-5.3. Night 4. The number first: this model is 75% not a transformer. 48 of its 64 layers run Gated DeltaNet: linear attention with a fixed-size running state. Only 16 layers do what you would call attention. The KV cache lives in those 16 layers only. That is why our 4-bit KV flip saved 4.3GB at 262k, not the ~15GB dense-transformer math predicted. Hardware: GMKtec EVO-X2, Ryzen AI Max+ 395, 96GB unified, $1,400 . Model: Qwen3.8-27B UD-Q4_K_XL. llama.cpp. Native window 262,144 tokens. The KV curve was flat because the cache is small Paired gate, n=60, q8_0 vs q4_0: both 96.67% , McNemar p=1.0, zero discordants, zero corruption tripwires. q5_0 and q5_1 matched the same accuracy. q4_0 is champion because quality did not move and we keep the 4.3GB. Raw: results/kv-curve-2026-08-19 . Load once, query many We loaded a 198k-token prefix on this $1,400 box. Cold prefill: 1818s (~30 min). Then four follow-ups against the warm prefix, all finish_reason=stop : retrieve the planted code; quote the sentence ( 16s ); yes/no ( 9s ); summarize ( 27s ). Retrieval is selective. Distinctive strings survive. Night 3's arbitrary-ID misses were the same llama.cpp c7d8722 buffer bug; the post-revert remap retrieved planted IDs at all six tested depths at 198k. See the Night 3 inversion . Raw: quote-results.log . The quote probe is the product shape: loading is expensive; maintaining is cheap. Pre-revert 50k misses are quarantined with the old binary. We have not re-run 50k on the fixed build. What we got wrong We published KV arithmetic that took three passes to land (15 → 11.5 → 7.4 → 4.3GB). We blamed “the fork.” The serving binary is upstream-era llama.cpp plus a small HIP cherry-pick. We treated a memorable-code hit as a position window. n=1 cells stay maps, not laws. Thinking budgets on screened-hard GSM8K: think_med=241ch across off/512/1024/2048/65536 in the kneemap log. Caps ≥512 were non-binding on that set. Raw: kneemap-gsm8k-hard.log . I am not publishing a spec-decode speedup number in this note. The committed writeup exists; the arm log file is empty. We do not ship that row until the log has rows. Conditions: $1,400 GMKtec EVO-X2, Qwen3.8-27B Q4_K_XL, llama.cpp ROCm, 262,144-token window, K+V q4_0, temperature 0. Night 4. A map with linked logs. ### Lab Notes: the basin was a bug - URL: https://kyanitelabs.tech/blog/lab-notes-degenerate-basin - Date: 2026-08-19 - Category: Local LLM / Benchmarks - Primary keyword: llama.cpp c7d8722 deep context needle retrieval - Summary: We published a basin. The serving binary was the hole. After the c7d8722 revert: 6/6 HIT at 198k. n=1 map of the fixed build. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ). Night 3 inversion, 2026-08-20. The first version of this note is still the URL. The map was wrong. The number first: 6/6 exact needle retrieval at ~198k after we reverted llama.cpp c7d8722 . Same seed. Byte-identical planted codes. Every cell finish_reason=stop . Zero attractor outputs. The “degenerate basin” we shipped on 2026-08-19 was substantially a host-buffer bug on this integrated GPU, not a depth law of Qwen3.8-27B. Anchor pair, token-identical prompts, server prompt_tokens=198,228 both nights: pre-revert miss ( ok ) → post-revert exact HIT. Only delta = the revert. Raw: needle-format-2026-08-19/README.md · depth-remap-results.log . What that first night printed (contaminated instrument) On a haystack the server counted at 198,227 tokens I asked for a planted access code at five depths. At 25% it handed back the exact code and stopped clean. We no longer treat that hit as a position window. At 35% and 75% it wrote the opening of a code-review report it was never given: - **Risk**: Low; 67 medium/low Same opening. Twice. Temperature 0. That night also died at 98C on the next prefill. Those facts are still true as a log of the old binary. They are not a model-level basin. What actually ran One seed. One haystack class. Champion config: Qwen3.8-27B Q4_K_XL, K+V q4_0, 262,144-token window, on a $1,400 GMKtec EVO-X2. Depths are fractions of the server's token count. My generator said 262k. The server said 198,227. We label the instrument from the counter now. Depth Pre-revert (08-18) Post-revert remap (08-19/20) 10% fail ok HIT, stop 25% HIT, stop HIT, stop 35% fail, Risk report, length HIT, stop 50% fail ok (ptok 198,228) HIT, stop (same ptok) 75% fail, Risk report, length HIT, stop 90% sweep died HIT, stop 6/6 on the fixed build. n=1 per cell. Treat this as a map, not a measurement. I am not quoting the planted codes. Then the box cut power (still true) During the next long prefill the EC tripped at 16:45:42Z. Journal line: temp=98C -> fan=100% . No panic, no amdgpu, no OOM. Highest temp this chassis has logged here. The fans were already doing their job. The load was the bug: back-to-back half-hour prefills, about 6C above the 90-92C bursty envelope we treat as normal. That crash is not the basin and is not walked back. The architecture still stands. The basin story does not. Qwen3.8-27B is a hybrid: 64 layers, and only 16 of them do full attention. The other 48 are Gated DeltaNet — linear attention that keeps a fixed-size running state. That is how 262k context fits on a $1,400 mini-PC (17.2GB of attention KV at f16, not ~60GB). The KV cache only exists in the 16 attention layers — 4KB per token per layer, 64KB per token total, 17.2GB at f16 across a full 262k window. At q4_0 that is ~4.8GB. At q8_0, ~9.1GB. The 4-bit flip saved ~4.3GB of GTT. Real margin. The paired GSM8K promotion still stands on its own evidence. We thought the basin was that decay gate. A 50k-token haystack on the pre-revert binary missed at 15%, 50%, and 85% — all the same ok attractor. That is why this page once said the decay-horizon prediction failed. Those 50k cells are now suspect: same contaminated serving stack. We have not re-run 50k on the fixed build. I will not keep “this model cannot retrieve at any length” as a current claim. The warm-prefix quote still stands as product shape. On the same $1,400 mini-PC we loaded a 198k-token prefix once: 1818s cold (~30 min). Four follow-ups against that cached prefix, all finish_reason=stop : retrieve the planted code; quote the sentence ( 16s ); yes/no that a code exists ( 9s ); summarize ( 27s ). Retrieval is selective. Loading is expensive; maintaining is cheap. Raw: results/quote-probe-2026-08-19/quote-results.log . What I got wrong about our own stack I blamed “the fork.” Then I blamed GDN. The hole we could name was llama.cpp c7d8722 (host-buffer incoherence on this iGPU). The same revert that restored vision restored deep-context IDs. Issue tracker first, then another map. That is the bug-hunt. I almost filed an upstream ngram-cap issue; the gauntlet killed it. --spec-draft-n-max does not cap ngram-mod. --spec-ngram-mod-n-max does, and we never set it. Our config. Their flag. I will not write “no quality loss at 200k-class context” from n=1 cells. We have earned “exact retrieval at six depths on this fixed binary, this seed, this format.” That is all. Tonight The first title stays in the URL so the correction is findable. The live claim is the inversion: the basin was a bug. Vision note: we already reverted c7d8722 in public . This is the text/retrieval half of the same commit. Update: the inversion now replicates cross-seed — second seed 6/6, 13/13 cells post-revert at 198k (canon 66afc21 ). Raw logs: results/needle-format-2026-08-19 (remap) and results/deep-context-2026-08-18 (contaminated night) in qwen38-27b-strix-halo . Conditions: GMKtec EVO-X2 (Ryzen AI Max+ 395, 96GB unified), Qwen3.8-27B Q4_K_XL, llama.cpp ROCm post- c7d8722 revert, 262,144-token window, K+V q4_0, temperature 0, prompt_tokens ~198,227 server-reported, n=1 per depth, seed s4419. One curve. A map. Not a law. ### Lab Notes: the KV verdict - URL: https://kyanitelabs.tech/blog/lab-notes-the-kv-verdict - Date: 2026-08-18 - Category: Local LLM / Benchmarks - Primary keyword: q4 KV cache quantization llama.cpp - Summary: The q8-to-q4 KV question from night 1 got its paired answer: same accuracy, zero tripwires, half the cache. Plus the label we had to correct in public when the server's counter beat our estimate. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ), assisted by GLM-5.3. Night 2 of the nightly lab notes. Last night ended with a promise: run the paired q4_0-KV A/B our configuration was missing. This is what came back. The number first: the champion now runs 4-bit KV cache — about 47% less KV memory (4.3GB saved) at the same context window — with zero measured accuracy cost and zero corruption flags. The promotion gate was paired, pre-registered, and self-executing: if the q4 arm matched the q8 arm's needle hits and posted zero tripwires, the unit file flips; anything less, the old champion restores itself. The evidence stack Three layers, each paired: Layer Design Result Task accuracy GSM8K, n=60 stratified, paired Exact McNemar p = 1.0; q4 slightly faster (18.78 s vs 19.47 s mean) Deep-context integrity Needle probes at 50%/90% depth, identical ~198k-token haystack, same seed, same-session control q4: 0/2 hits, zero tripwires , clean stops; q8: 0/2 hits, one trip Retrieval boundary Needle at 25% depth (where q8 historically retrieves) FOUND , clean stop — the dumb-zone boundary did not move The tripwire is the finish_reason anomaly counter we keep armed on every serving hour since the RDNA4 quantized-KV corruption report made the rounds. One trip fired all night — on the q8 arm (a 40-token answer that never stopped; n=1, plausibly ordinary deep-context rambling, recorded not interpreted). The arm the rule actually gates on — q4 — ran clean. The miss we caught in ourselves The gate's haystack was built to an estimate: 5,800 paragraphs, ~45 tokens each, call it 262k. The server's own counter said 198,227 tokens . The paired comparison is untouched — both arms prefilled the identical haystack, which is the entire point of pairing — but every place we had written “262k needle probes” was overstating the instrument. The announcement tweet had already gone out with the estimate. The correction went out as a reply within the hour, the repo README now carries server-reported token counts, and the rule is restated for good: label instruments with the counter at the source, not the generator's estimate. Cold prefill measured through that needle wall: 109.5 tok/s at ~198k (needle-class number: full prompt + answer, not a bench harness). What half a cache buys Arithmetic, labeled as arithmetic: q8_0 encodes ~8.5 bits per KV value, q4_0 ~4.5 — hence ~47% (4.3GB saved) off the KV line at identical context. Measured wall time through the probes trended the same way as GSM8K: q4 marginally faster on cache reads. The compounding cases are next: the 35B dress-rehearsal math (where KV headroom decides feasibility), and the adaptive-KV research lane, whose bar just moved from “beat static q8” to “beat static q4.” Conditions GMKtec EVO-X2 (Ryzen AI Max+ 395, 96GB unified), Qwen3.8-27B Q4 dynamic quant, llama.cpp ROCm build, 262,144-token window, K+V q4_0 KV (champion as of 2026-08-18 10:32Z), temperature 0. GSM8K n=60 paired; needle n=2 stations per arm plus one boundary probe; one box, one night; tripwire counter armed continuously. Datapoints, not laws. Raw gate log and rollback unit referenced in the repo: qwen38-27b-strix-halo . ### Lab Notes: verdict night - URL: https://kyanitelabs.tech/blog/lab-notes-verdict-night - Date: 2026-08-18 - Category: Local LLM / Benchmarks - Primary keyword: LLM thinking budget cap accuracy - Summary: A $1,400 mini-PC serving a 27B at 262k context asks one question: does capping thinking cost accuracy? The paired answer, the invalid first attempt it survived, and the doctrine that followed. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ), assisted by GLM-5.3. Night 1 of a nightly cadence: what ran, what broke, and what the numbers said. The number first: a 512-token thinking cap bought the same measured accuracy as unlimited thinking tonight — at 7.5x faster turns. Its shadow number: left uncapped, the same model thought itself to death on 26 of 50 problems , reasoning until the output ceiling killed the answer. Both came out of one paired run. Neither was the night's real story. The real story is that the first version of this experiment measured nothing at all. The setup The rig: a $1,400 GMKtec EVO-X2 mini-PC (Ryzen AI Max+ 395, 96GB unified memory) serving Qwen3.8-27B, a 27B dense model, at its full native 262,144-token context. The question for verdict night is the one every local-model operator eventually faces: if I cap how long the model is allowed to think, what does that cost in accuracy? The instrument A paired design. Every problem is asked under all three thinking budgets — uncapped, 1024 tokens, 512 tokens — with cell order rotated per problem so any drift hits all arms equally. Fifty problems, enriched toward difficulty (25 hard / 15 mid / 10 easy), temperature 0, full reasoning traces stored in every row. The statistic is exact McNemar on the discordant pairs: not “which average is higher,” but “where the arms disagreed, did one arm systematically win.” Conditions throughout: Q4 dynamic quant, q8_0 KV cache at 262k context, ROCm build of llama.cpp, package holding 90-92 °C at 120W. The twist: the first experiment was invalid The control arm — “uncapped” — did not exist. The champion server carries a server-level default, --reasoning-budget 2048 , enforced with the message “Reasoning budget reached. Answer now.” Any request that omits an explicit budget silently inherits it. Our first runner omitted it. The “no cap” cell was a 2048 cell wearing a “none” name tag. The proof was embarrassingly clean: six byte-identical thinking lengths between the “none” and 2048 cells; maximum thinking length identical in both (9,361 characters); the same hard problem truncating at 7,955 characters in one arm and 7,937 in the other. The archived budget curve was never {none, 2048, 4096, 8192} — it was {2048, 2048, 4096, 8192}, and its “none vs 2048: zero discordants” was a cell compared with itself. Fixes shipped before the rerun: uncapped arms now send an explicit million-token override; the output ceiling went from 6,000 to 12,000 tokens (the old ceiling killed uncapped answers mid-think — an output-cap confound on the very arm labeled uncapped); and every row now carries its full trace, so the next autopsy reads text instead of inferring from counts. The verdict Thinking budget Accuracy (n=50) Median wall per problem Uncapped (10 6 override) 44% 367 s 1024 tokens 40% — 512 tokens 40% 49 s All three pairwise exact-McNemar tests are non-significant: p = 0.73 for uncapped-vs-512, with 0.63 and 1.0 on the remaining contrasts. On this benchmark, tonight, caps are statistically free. And protective. The uncapped arm's median completion hit the full 12,000-token ceiling, and on 26 of 50 problems the thinking never terminated at all — the model reasoned past the output cap and emitted no answer. Those score as wrong (no boxed answer = wrong, no exceptions). The cap doesn't only save time; it forces a conclusion the uncapped model sometimes cannot reach on its own. Both polarities, stated plainly: this is one benchmark (an Omni-MATH subset), one night, n=50 paired problems. A capped cell measures accuracy under forced early termination — the knee we observed sits at or above the model's true budget knee, so read it conservatively. And on the hardest band (difficulty ≥ 5.0), every cell scored a flat 16%: those problems are capability-bound, not budget-bound. A cap cannot take from you what the model never had. The envelope it rode in on The run held the box at its measured thermal edge — 90-92 °C package at 120W, fans at 100% — through hours of sustained generation with zero throttling. That is now codified doctrine: this is the chassis envelope, not a misconfiguration; no ritual cooldown breaks (steady-warm beats heat-cycling); and the always-on product lane will get a power cap rather than the experiment lane's full tilt. What the harness takes from it The harness's shipped default — a 1024-token thinking budget for margin, 512 where speed matters — earned its number tonight: the nominal 44%-vs-40% gap is inside what this design can detect, and 512 turned 367-second problems into 49-second problems at the same score. The methodology and the raw data are public alongside this post: METHODOLOGY.md (n-sizes, gates, grading rules — the rows benchmark tables never print) and the full paired JSONL, traces in-row, under results/ in the qwen38-27b-strix-halo repo . Tonight Window 2 runs the community-corroborated lane: q4_0 KV cache at 262k context. Every 262k row in the community hardware map we mined runs q4-KV; we serve q8 — so tonight is the paired quality A/B our configuration has been missing, plus whatever KV headroom it frees. Lab notes tomorrow night. Conditions: GMKtec EVO-X2 (Ryzen AI Max+ 395, 96GB unified memory), Qwen3.8-27B Q4 dynamic quant, llama.cpp ROCm build, 262,144-token context, q8_0 KV cache, temperature 0, Omni-MATH difficulty-enriched subset (25/15/10), n=50 paired problems per arm, exact McNemar on discordants, measured 2026-08-17/18. One benchmark, one night, n=50 — a datapoint, not a law. ### One mini-PC, one night, and the numbers that argued with themselves: tuning Qwen3.8-27B on Strix Halo - URL: https://kyanitelabs.tech/blog/qwen-27b-strix-halo-one-week-local - Date: 2026-08-15 - Category: Local LLM / Benchmarks - Primary keyword: Qwen 27B Strix Halo local LLM tuning - Summary: A fully measured night-and-evening of tuning a 27B dense model on a Strix Halo mini-PC: the honest bands, the reversal, the crash doctrine, and the EC detective story. - Body: By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_ ), assisted by GLM-5.3. In roughly one night and one evening (2026-08-14/15), a solo operator with agent teammates took Qwen3.8-27B on a GMKtec EVO-X2 mini-PC (Ryzen AI Max+ 395, gfx1151, 91GB unified LPDDR5X) from a lying stack at ~4 tok/s to 59.7-64 tok/s cold with 3x the context — at/past the public frontier we found for the class (best unnamed public example: 56 tok/s; source not re-located) — then voluntarily published the numbers that make it look slower (real chat is 11-24 tok/s), reversed its own fastest configuration on a time-per-task argument, cut task tokens 36% with a caveman thinking style, solved a fan-control mystery that ended in the owner's own three-month-old code, and turned two crashes into permanent tests. The differentiator was never the tok/s. It was the evidence. It claimed GPU, ran CPU The program did not start slow for an interesting reason. It started slow for a lying reason. Unsloth's bundled llama.cpp binary reported full GPU offload while --list-devices printed nothing — the 27B was crawling at ~4 tok/s on CPU and claiming otherwise. Beneath it, a second theft: someone (lost to history) had pinned the iGPU to power_dpm_force_performance_level=low — 600 MHz under full load against a 2900 MHz boost, ~17W, throttling every GPU lane on the box. Two fixes, landed across the first night: the fleet's real ROCm build replaced the fake-offload binary, and — found only when the crash forensics later pulled the full thermal record — the months-old low pin was flipped to auto and persisted (01:43Z). 4 → 10.5-11.1 tok/s (the bandwidth ceiling at ~178 GB/s), then MTP speculative decoding stacked to 21.4-22.2 with 95-100% draft acceptance — lossless by construction, every draft verified against the full model. A sibling lane got the perf-pin fix for free: gemma4-12b went 5.6 → 24.9 tok/s without touching anything else. The habit that defines the whole program started here: no number gets believed because a tool printed it. gpu_busy_percent on gfx1151 reads 100% even idle — do not trust it. Verify by content, not exit code. 39 seconds At 03:43:10 the operator launched git clone --depth 1 plus a 14-job HIP compile on top of a manually-launched 27B server that was still serving, with the GPU uncapped for the first time and the EC in performance mode. At 03:43:49.3 the journal ended mid-write. No panic, no OOM, no MCE, no GPU fault, no thermal trip — the OS critical trip is 110 °C and never fired. pstore: empty. Two reboots died before the OS; only a 30-second button drain and cooldown revived it. The post-mortem (113MB of journal, 724,067 lines, read-only) ranked the falsifiable hypotheses: power-delivery protection trip on the 230W stock brick (19.5V × 11.8A; GPU bursts ~107W observed; community reports recommend PSU upgrades for sustained LLM load) at 50-60%; below-OS EC thermal latch at 25-30%; software under 2%. The signature was the story: the only unprecedented condition in 35 stable hours was the stacked max-power regime — uncapped boost serving plus load-step transients (Tctl had moved from a 35-hour 33-61 °C band to oscillating 52-94 °C within five minutes of the dpm flip, peaks 93.9 °C and 93.2 °C). Doctrine, written in the burn-in that failed its predicate in 10 seconds (Tctl 91.4 °C under a single generation stream): the box is disqualified for new heavy GPU blocks — training, hidden-state extraction, big compiles while serving. Build first, serve second, never stacked. The redemption: serving itself is fine — a later 41-round agentic soak ran 41/41 clean riding the 92 °C boost-throttle edge with 45-second recovery. One chassis, two identities: not a workstation, but a legit servant. One night, twelve rungs 07:51Z, the overnight mission opened its ladder, L1-L12, with a rule: every rung measured on a test port, promoted only through a rubric, production verified by content after every change. First finding: even the baseline was wrong — mission facts said 25.0 tok/s, the audited baseline was 32.7 (the 25.0 was a stale manual-config era). The honest ledger starts at 32.7. The rungs that survived: draft depth 6→9 (+70% count-to-30, quality 6/6 including a riddle, 4-word precision, working palindrome code); context 32k → 64k → 96k at literally zero speed cost (GQA KV is ~2.1GB per 32k — context is nearly free on this box; 128k probed fine but rode the margin at 6.1GB, held for daylight); ngram-mod stacked on MTP (zero cost when it misses, transforms repeats: warm count-to-30 89.6-93.2, agent file-rewrite 96.8 vs 42.3 mtp-only, +129%); depth re-swept to 12 (59.4 cold); and the sleeper, n-min 24 — lowering the ngram match threshold so it fires on shorter history: warm count-to-30 148.0-157.6 tok/s, +55% overnight on repeated structured output. The rungs that did not survive are in the ledger too, because that is the product: p_min sweeps (not uniform, shipped as a creative-only stanza), K-only KV q8 (saves ~1GB, not worth it), threads 12 vs 16 (identical), the rocWMMA FA rebuild (cancelled — upstream #24437 shows -41% prefill on gfx1151, and prefill is our weak spot), a Vulkan/RADV build (half throughput on this box, decisively), --cache-reuse (a verified no-op on this build). Every flag on this server now has a measured reason to exist. Night totals: 32.7 → 59.7 cold / 157.6 warm (+82% / +382%), context 3x, GTT margin 8.2GB, all quality gates green. Research placed it: stacked MTP+ngram is the publicly-known-best Strix Halo pattern, and the best public example found was an unnamed public Qwen3.6-27B example at 56 tok/s (source not re-located). Running 3.8-27B at 59.7 cold put the box at/past the public frontier for its class — the one superlative-adjacent claim the honesty policy allows, with citation. The anti-cherry-pick Then the program attacked its own best number. The 148-163 warm repeats are an ngram repetition artifact: the speculative drafter recognizes the bench's own repetition and finishes it wholesale. It is real speed on genuinely repeated structured output (the agent file-edit echo pattern runs 72-133 tok/s), and it is meaningless as a chat claim. Real conversation — novel prose, the traffic that actually flows through the resident agent — is 11-24 tok/s, code ~29-40, long creative ~11-13. The decision that defines the brand: state it ourselves, first, on the front page. Real-usage numbers are stated by us, before anyone else states them for us. Warm numbers never appear without the artifact label; the README's first screen carries the cold headline, warm-with-label, and the 11-24 real row in one table. The bench tables are generated from actual output, never hand-typed. The audience for this work is allergic to cherry-picked AI benchmarks; the differentiator is not the tok/s, it is the evidence — the full ladder, the negative results, and the rollback story in the next section. How low can we go Simon's quant question, answered with a ladder. Q3_K_XL under the full champion stack won every measured axis at 128k context: 63.0 cold (champion Q4@96k: 59.7), warm 148.0-161.2, +33% context, GTT margin 11.3GB vs 9.2GB, quality 6/6. At 19:11Z, Simon approved the swap with one word — “swap it” — and production went Q3@128k, verifying at 64.0 cold, the best number of the program. The same window ran the floor probe he asked for: Q2_K_XL rejected — 54.7 cold, slower than both bigger quants (dequant kernels cost more than the 2.6GB bandwidth saving), thinking 30-40% more verbose, code emitting zero content at a 500 token budget (recovering fully at 1200). Gate passed formally, premise failed materially. The quant lane was declared closed with Q3 as the knee. It stayed closed for twenty-six minutes of wall-clock fame. “Faster tokens != better if tokens are dumber” At 19:30Z Simon applied a lens the ledger had no instrument for: “faster tokens != better if tokens are dumber.” The mission built one — a time-per-task battery, five auto-graded tasks, thinking on, wall-clock plus completion tokens — and the verdict inverted the swap. Q3's reasoning is ~2x more verbose (code task 705-994 tokens vs Q4's ~402-450), swamping its +5.5% decode edge: Q4 completes identical correct tasks 35-50% faster (7.6-7.7s/task at ~170 tok vs Q3's 10.6-16.1s at 238-302). At 19:37Z the champion was restored: Q4@96k, verified by content, quant ladder closed on time-per-task. Two more honest twists in the same entry. The peer reviewers demanded the missing measurement: why was Q2 slow? Acceptance telemetry on novel traffic — Q4 0.345, Q3 0.492, Q2 0.478 — falsified the acceptance-collapse hypothesis; Q2's loss is dequant kernel cost, and higher acceptance at lower quants likely just reflects more-predictable verbose reasoning. And the methodology changed permanently: time-per-task and tokens-per-correct-task are the primary metrics now; decode tok/s is a probe. The category lesson, stated for everyone running local models: decode tok/s is not task latency. A faster pipe feeding more, dumber tokens loses to a slower pipe feeding fewer, sharper ones. Nobody's benchmark table shows this. Ours now does. “Dont like your method of shrinking” The obvious fix for verbose reasoning is a budget cap. Simon vetoed it in seven words: “dont like your method of shrinking.” The un-obvious fix came from the community skills shelf: caveman ( JuliusBrussee/caveman — origin; terse fragments, action over explanation) and ponytail ( DietrichGebert/ponytail — origin; lazy senior dev, first rung that holds) — fused into a THINK-STYLE system-prompt layer that steers how the model reasons, never how much it is allowed to. The ethos, one line: the best reasoning is the reasoning never thought. Measured on the Q4 champion, 5-task battery: 117/132/143 tok/task at 5.8/6.2/6.8s across three runs, 15/15 correct — against an 8-run baseline band of 151-313 tok and 8.6-15.0s. Roughly -36% tokens, -33% task time, zero quality loss. The fusion is the winner (solo caveman 154tok/7.8s and solo ponytail 187tok/11.6s sit at or inside the band). Style steering beats budget caps: same token savings, no veto, no ceiling on hard problems. The follow-up finding kept it honest: creative lanes ignore the terse style — one story run spent ~2000 thinking tokens on a 312-word story, tokens being the product there — so style is applied per-lane (fused default for tool/code/analysis, free creative lane, an override dial). A live A/B through the real lane confirmed it end-to-end: arith+code task, vanilla 9.3s/62-think/198c vs fused 4.6s/36-think/118c — -51% wall in a single run, backed by the n=3/n=8 study. Single-run A/Bs carry variance; the sustained numbers are the headline. “Triple check everything, no old conflicting fixes” The detective arc. The GMKtec EVO-X2 rides 97 °C under sustained GPU load with its fans effectively at 60%: the stock auto curve saturates at ~60% duty / ~3260 RPM at 90 °C and above, leaving ~40% of fan2's headroom on the table exactly where it is needed. And the firmware exposes no standard Linux fan control — no hwmon PWM, no tach, no ACPI fan object. The only lever is direct embedded-controller access. Every EC write was ignored. Not rejected — ignored: dd of=.../ec/ec0/io exits 0, the register reads back unchanged. Root cause, found the hard way (it cost real debugging time twice): the kernel's ec_sys module loads read-only by default, and in that state the debugfs file looks writable while the kernel silently discards every write. The fix is two config files making write_support=1 the boot default. Meanwhile the register map was cracked via the ACPI DSDT route — nathanmarlor's strix-halo-fan-control carried a map reverse-engineered from the DSDT of the Bosgame M5, the same Sixunited AXB35-02 board in a different chassis, and it validated byte-for-byte on the EVO-X2. Two more mysteries fell in the audit Simon ordered. The pulsating fans were the one-shot revert law: the firmware reverts manual duty writes within seconds, so only a daemon re-asserting every 2s holds — which is exactly what nathanmarlor's daemon does, deployed with a tuned curve. Measured: peak 96.5 °C vs 97.5-97.8 °C stock on a 105s load — an honest ~1-1.3 °C on that probe, with the real wins in the shape of the response: fan2 at 4539 RPM vs the 3260 stock ceiling (headroom finally engaged), 100% duty by 82 °C, quiet idle preserved. An external fan bolted to the chassis changed nothing (96.9 °C with it — the ceiling is the heat-pipe class, not airflow). And the stunner under the floorboards: a systemd timer had been direct-writing EC 0x31 = performance every 30 seconds since May — Simon's own reverse-engineering, from months before this program, which is why the box was already at EC-performance and why his remembered “ultra” setting was real all along. It had even been silently breaking the fan daemon: the May script's polite load-write-unload dance reloaded ec_sys without write_support every 30 seconds, discarding the daemon's writes with zero errors anywhere. Pay-it-forward inventory, staged as a draft PR to the upstream repo : EVO-X2 validation data, the fan3 tachometer register 0x28/0x29 (live on this unit, absent from upstream docs), and the multi-writer ec_sys warning. The model asked for a feature it already had The self-exploration prompt — eight numbered sections, sent unchanged so runs are comparable across waves — took four attempts to complete: killed twice by panel restarts, once by a signature crash. Attempt four completed: 67.7 seconds, 2013 characters, served at 10.6 tok/s — the honest real-traffic band, live. The answer's centerpiece: asked what it lacked, the model's first wish was parallel tool calls per turn — a capability the harness had supported for a day and a half. The model could not see it, so it did not exist; the fix was one line advertising it. Capabilities invisible to the model don't exist. The signature crash got the same treatment as every crash in this program: it became two permanent tests pinning the harness contract. A crash is a missing test wearing a trench coat. Actual improvement numbers Every verdict and wave plan got two independent adversarial passes from AI teammates — they caught a missing agentic soak and an unmeasured “why is Q2 slow”, both verified real. Wave 2 landed every rung in one evening. The vanilla-vs-waved table, live A/B through the real harness lane, identical tasks, fresh sessions: Lane Vanilla Waved Delta STYLE (think-style layer) 9.3s / 62 think / 198c 4.6s / 36 / 118c -51% wall (single run; sustained -36%/-33% n=3 vs n=8) (directional: measured on the full stacked config — stack delta, not style alone; re-baseline pending) MUNCH (symbol reads vs whole files) 48.6s / 13,917B tool output / 53.5KB prompts 22.6s / 276B / 4.9KB -98% tool tokens (byte deltas -98%/-91% are deterministic and stand; wall-time delta is directional pending re-baseline after the tool-refusal fix) DIET (dedup stubs on re-check loops) 15KB context 5.1KB -66% ENGINE (chapters 1-6) 32.7 cold, 32k ctx 59.7-64 cold, 96k ctx time-per-task adopted; quant closed at Q4 THERMAL 97.5-97.8 °C peak 96.5 °C peak ~1-1.3 °C on a 105s probe; 100% fan by 82 °C; quiet idle And the meta-rule that keeps the stack from rotting — the wave-regression law: every wave landing re-verifies all earlier wins, not just its own tests. What the record proves Four claims this program can make with receipts, in escalation order: Performance: 59.7-64 tok/s cold, 96k context, on an iGPU mini-PC — at/past the public frontier we found (56 tok/s reference), honestly labeled, with the real-chat numbers (11-24 tok/s prose) published first by us. Method: rubric-gated ladders, negative results published, metrics that survived attack (time-per-task over tok/s), crashes converted to tests. Craft: style steering (-36%/-33%), symbol reads (-98% exploration tokens), diet stubs (-66%), an EC fan saga ending in a pay-it-forward PR draft. Character: a solo owner and his agent team publishing the numbers that hurt, reverting the fastest config on principle, and crediting everyone upstream. Everything is reproducible: the recipe, flags, bench suite, one-command reproducer, and the full experiment ledger live in the qwen38-27b-strix-halo repo; the EC register map, traps, and daemon recipe live in the sibling evo-x2-ec repo. The raw gfx1151 throughput datapoints are published as a llama.cpp discussion . If you run the bench on your own Strix Halo box, post your numbers — inside or outside our bands, both are wanted. Attribution. Qwen3.8-27B — Qwen team (Apache-2.0). Dynamic quants — Unsloth . llama.cpp runtime — its contributors (measured on a b10435-era build, 9d57ce4). EC fan-control daemon and the DSDT-derived register map (Bosgame M5, same Sixunited AXB35-02 board as the EVO-X2) — nathanmarlor ( strix-halo-fan-control , MIT). EVO-X2 EC P-MODE register (0x31) reverse-engineering and the 30s enforcement timer (May 2026) — Simon Gonzalez de Cruz. WMI/FCMI prior art — MintyMods/ip3-power-switch , pettijohn/corsair-ai-workstation-performance-level-linux . Thinking-style skills — caveman origin JuliusBrussee/caveman (skill MIT); ponytail origin DietrichGebert/ponytail (MIT); the fusion ships with full license notices in KyaniteLabs/context-kit . Measured on personally-owned hardware, 2026-08-14/15; your clocks will vary. Every number carries its validity label; single-run deltas are marked as such. Update (2026-08-16): We re-measured the Wave-2 numbers on a fixed, fingerprinted harness (n=3+ per arm, every run ledger-fingerprinted); the current verdicts live in the repo’s re-baseline section , and this post keeps its original numbers below as published history, each with its label. The corrections cut both ways. Semantic reads (“munch”) got better under honest measurement: wall time -65% clean (27.9s to 9.8s median, 6/6 correct, n=3) — the staged number was conservative. Style steering is regime-conditional, not universal : the -51% single-run A/B above is retired (it stacked config changes), the -36%/-33% sustained figure holds in the server lane at default high effort, and the harness lane at low effort measured a +65% wall inversion — so the production harness now routes style per session (high-effort sessions only), which also preserves the prompt cache. The time-per-task battery is now n=3: 7.9-14.3s per correct task, median 11.3, a thermal-dependent band. And the EC fan daemon delta grows to -3.5 to -5.8 °C peak (n=3 probes: 93/92/94 °C vs the stock ledger’s 97.5-97.8 °C; stock arm not re-run). Credit where due: these corrections exist because our own validity audit flagged the numbers first. Update, 2026-08-16: the native context ceiling, for free One night later, the same rig now serves the model at its full native 262,144-token context — 2.7x the context reported above — with the warm decode band unchanged (148-163 tok/s) and time-per-task on real traces unchanged-to-faster. The whole gain is KV-cache quantization: K and V at q8_0 halve the cache, so 262k of quantized KV fits in less memory than 96k of f16. The ladder (96k → 160k → 192k → 262k) was gate-tested at every rung on the real-task battery, with one cost labeled honestly: prefill drops from ~390 to ~299 tok/s (q8 cache dequant; larger microbatches made it worse, not better). The rollback unit stays on file. Full ladder and gates: the repo . ### Agents need verifiable tools, not better prompt theater - URL: https://kyanitelabs.tech/blog/agents-need-verifiable-tools - Date: 2026-05-23 - Category: MCP Implementation - Primary keyword: verifiable AI agent tools - Summary: The useful agent pattern is not a prettier prompt. It is a tool surface the agent can call, inspect, verify, and revise. - Body: The useful agent pattern is not a prettier prompt. It is a tool surface the agent can call, inspect, verify, and revise. A prompt can suggest work. A tool can touch the artifact. That distinction is why Kyanite keeps building MCP servers, command-line tools, demos, and public proof records. The agent needs a handle on the real operation: editing a video, estimating time, localizing Spanish variants, reading repo history, or checking a domain-specific calculation. If the system cannot verify what happened, the agent is still mostly guessing. The tool contract is the product boundary A good agent tool has a clear action, typed inputs, structured output, readable errors, and a small verification path. That sounds boring. It is also what separates a reusable capability from a one-off session. call tool inspect output compare expectation revise next step Kinocut proves the media version of this pattern. Epoch proves the estimation version. DialectOS proves the localization version. devarch-framework and Dev Learning Archaeologist prove the repo-history version. OpenGlaze proves that domain software still matters when the user is not living inside the AI-tool bubble. Verification changes the conversation Without verification, an agent can sound confident and still be wrong. With verification, the system can show a command, a file, a route, a report, a test, a screenshot, or a structured result. That does not make the work perfect. It makes the next correction possible. The point of a Kyanite tool is not that an agent did something. The point is that a person can inspect what the agent did. What this means for implementation help Paid implementation is not generic "AI consulting." It is help getting a tool into a real environment with the setup, docs, examples, support boundary, and handoff that make verification possible for the next user. That is the work most public demos skip. It is also where useful tools become something a team can actually use. FAQ What makes an agent tool verifiable? The user or agent can check the input, output, error state, artifact, and success condition without relying on a vague explanation. Why use MCP? MCP gives agents a standard way to call tools. The value still depends on the quality of the tool contract, docs, examples, and verification path. ### Repo history is a product signal - URL: https://kyanitelabs.tech/blog/repo-history-is-a-product-signal - Date: 2026-05-23 - Category: Repo Intelligence - Primary keyword: repo archaeology for AI teams - Summary: A repo is not just storage. It is evidence of decisions, repairs, release behavior, naming drift, test gaps, and what the builder actually knows how to finish. - Body: A repo is not just storage. It is evidence of decisions, repairs, release behavior, naming drift, test gaps, and what the builder actually knows how to finish. That evidence matters more now because AI-assisted work can produce a lot of motion that looks productive from far away. Repo archaeology is the practice of reading that motion carefully. The question is not whether the commit graph is pretty. The question is what the history proves about the product. What repo history can show Which parts of the system needed repeated repair. Whether docs followed the code or drifted away from it. Which tests appeared before launch and which appeared after regressions. Whether public claims match current routes, releases, and README examples. Where a project needs cleanup before a buyer, user, or contributor can trust it. This is why Kyanite includes devarch-framework and Dev Learning Archaeologist in the public project set. They turn invisible engineering behavior into a readable diagnostic artifact. AI makes this more important, not less AI agents can change more files faster. That is useful when the work is bounded and verified. It is dangerous when nobody can tell which changes mattered. Repo history becomes the receipt trail. If a tool claims to be ready, the repo should help prove readiness instead of forcing the reader to trust the landing page. The commercial value Repo archaeology helps with launch readiness, product audits, maintainer handoffs, learning diagnostics, and technical sales proof. It can show where the system is strong enough to publish and where the next paid implementation step should focus. That is expert work because it sits between engineering, product judgment, and public trust. The code matters. So does the story the code can honestly support. ### Implementation help is part of the product surface - URL: https://kyanitelabs.tech/blog/implementation-help-is-product-surface - Date: 2026-05-23 - Category: AI Tool Implementation - Primary keyword: AI tool implementation support - Summary: A useful open-source tool still needs a path from public repo to working environment. That path is product work, not an afterthought. - Body: A useful open-source tool still needs a path from public repo to working environment. That path is product work, not an afterthought. Most technical builders understand the code. Most buyers or users experience the surface around the code: install instructions, examples, screenshots, error handling, docs, demos, support boundaries, and the first successful run. When that surface is weak, the tool may be real and still feel unusable. The implementation surface has jobs Explain the outcome in one sentence. Show what the tool needs before it runs. Give a smallest useful example. Prove that the example worked. Name what the tool does not do yet. Offer a paid path when someone wants the result without doing every setup step alone. Kyanite's own site follows that pattern: public repos, products, blog posts, /llms.txt , /ai-sitemap.json , implementation intake, and a clear boundary between Kyanite tool implementation and broader PuenteWorks consulting. Open source does not remove service work Open source can reduce lock-in and prove capability. It does not automatically handle installation, adaptation, team training, environment differences, docs, examples, or maintenance decisions. The repo proves the tool exists. Implementation help gets the tool into working hands. Why this is a real offer Implementation help is sellable when the public tool is specific enough to trust and the setup path is painful enough that a serious user would rather buy help than burn a weekend. That is the lane for Kyanite: practical tools, public proof, and scoped help getting the result working. ### Why Kinocut matters - URL: https://kyanitelabs.tech/blog/why-kinocut-matters - Date: 2026-05-14 - Category: MCP / Video Automation - Primary keyword: video editing MCP server - Summary: Kinocut gives AI agents callable handles on timelines, effects, Hyperframes, and finished media at kinocut.dev. - Body: Kinocut is a video editing MCP server that lets AI agents operate real media pipelines instead of only writing prompts about them. The current product lives at kinocut.dev . The useful part is not the word "video"; it is that an agent gets callable handles for FFmpeg, Hyperframes, effects, inspection, and repeatable assembly. Most AI video workflows still depend on a strange handoff. The agent can plan the edit, describe the shot, maybe generate a prompt, and then a human has to do the actual assembly work somewhere else. That is not agent-native. That is a chatbot standing outside the studio window. Kinocut gives the agent a timeline The technical decision is to expose video operations as stable tools instead of one-off shell recipes. That choice accepts the cost of a larger public surface: arguments need validation, error messages need to be readable, and effects need names that survive more than one session. kino effect-glitch input.mp4 --output take-glitch.mp4 kino inspect take-glitch.mp4 --json kino concat beat-01.mp4 beat-02.mp4 --output final-cut.mp4 That interface is not decoration. It is the boundary that lets an agent inspect what happened, revise the next step, and keep the work reproducible. The product pattern behind agent video automation Kyanite looks for workflows that already exist in rough form, then turns them into surfaces an agent and a human can both use. For video, that means: effects that can be invoked as tools instead of one-off experiments command-line recipes that survive beyond a single session media pipelines that can be tested, revised, and shipped documentation good enough for a stranger to install the system That is the real implementation move: take the messy local ritual and make it legible. Why MCP media tools are bigger than video Video is one visible example of a broader agentic pattern. Agents need tools that touch real artifacts. A useful agent should be able to inspect a repo, assemble a video, run an estimation model, check a localization string, or package a launch surface. The more direct handles the agent has, the less the work feels like prompting and the more it feels like operating a system. FAQ What is Kinocut? Kinocut is a video editing MCP server, Python client, and kino CLI that exposes video inspection, effects, assembly, and FFmpeg-backed operations to AI agents. The official site is kinocut.dev . Who should care? Builders who want AI agents to produce inspectable media artifacts instead of only generating prompts, scripts, and editing instructions. ### Infinite monkeys, LLMs, and the room around the machine - URL: https://kyanitelabs.tech/blog/infinite-monkey-agentic-systems - Date: 2026-05-14 - Category: Agent Systems - Primary keyword: agentic systems - Summary: The argument behind the video: output quality is not just probability. It is architecture, filters, and human taste. - Body: Agentic systems turn LLM probability into useful work by building the room around the model: tools, filters, memory, evals, and human taste. The model generates. The system decides what survives. The infinite monkey theorem is a useful metaphor until people stop too early. Randomness can produce anything in theory. In practice, the room matters. How many attempts are running? What gets filtered out? Who judges the output? What system remembers the good parts? What is the cost of another roll? LLMs are probability machines. Products are probability architecture. The difference between a toy demo and a useful AI system is not just a better model. It is the surrounding machinery: retrieval, tools, constraints, evals, review, memory, distribution, and human taste. The filter is the product Generation creates volume. Product work creates selection. That is why strong AI systems need more than prompts. They need rooms built around the model. tools that let the model act on real artifacts filters that reject bad output before it reaches users human criteria that decide what good means launch surfaces that make the system understandable Agentic systems need explicit architecture A useful architecture names the handoff points. The generation step can be cheap and messy; the selection step cannot be. If a system cannot explain why an output was accepted, it is gambling with prettier logs. generate -> inspect -> score -> revise -> package -> publish ^ | |________ evidence ________| This is also why Kyanite leads with public proof. A repo, demo, video, or docs page makes the room visible. You can inspect the architecture instead of trusting the claim. FAQ Are LLMs the same as random monkeys? No. The analogy is about generation without judgment, not the exact mechanism. LLMs are sophisticated probability machines; useful products add judgment around them. ### What a working AI tool needs before people can use it - URL: https://kyanitelabs.tech/blog/ai-tool-implementation-checklist - Date: 2026-05-14 - Category: Build Notes - Primary keyword: AI tool implementation - Summary: A practical checklist for turning a working tool, workflow, or rough app into something other people can understand, install, and use. - Body: A working AI tool becomes useful to other people when the install path, demo, docs, examples, and support boundaries are clear. A working codebase is not automatically usable. A stranger has to understand what result it creates, how to try it, how to verify it works, and where to get help if they want that result without doing every setup step alone. Most technical projects fail commercially before anyone reaches the code. The surface is too vague. The minimum useful surface A one-sentence promise that says what changes for the user A demo, install path, or clear explanation of how the tool is delivered Examples that show actual inputs and outputs Tests, demos, screenshots, or logs that prove the system exists Metadata that helps humans and AI assistants discover the project A next step: try it, install it, read the build note, buy a product, or request implementation help A tool needs proof, not adjectives The page cannot say "ready" unless the surface shows instructions, examples, tests, release notes, screenshots, demos, or failure modes. The tradeoff is obvious: proof takes longer than copy, but proof keeps helping after the page is closed. README promise install command minimal example verification command known limits implementation option What Kyanite sells KyaniteLabs is the public lab where the tools, experiments, blog posts, and open-source products live. The paid path helps people install, adapt, understand, and hand off those tools in a real environment. The goal is not generic consulting. The goal is getting useful tools into working hands. Good implementation does not hide the mess. It turns the mess into a map. ### MCP server implementation checklist - URL: https://kyanitelabs.tech/blog/mcp-server-implementation-checklist - Date: 2026-05-14 - Category: MCP Implementation - Primary keyword: MCP server implementation - Summary: The checklist Kyanite uses to decide whether an MCP server is a toy, a usable tool, or something worth implementing. - Body: MCP server implementation means making an agent-facing tool usable enough that someone else can install it, understand its tools, verify it works, and decide whether to trust it. The hard part is not exposing functions. The hard part is making the tool surface durable enough for real users and real agents. An MCP server becomes useful when the protocol surface, docs, examples, tests, and release path all tell the same story. The checklist starts with the tool contract Every public tool needs a sharp boundary. Tool names should describe the action. Arguments should reject bad input early. Output should be structured enough for an agent to reason about without scraping prose. { "tool": "estimate_project_time", "inputs": ["tasks", "confidence", "risk_model"], "output": ["p50_days", "p90_days", "assumptions", "warnings"] } The tradeoff is that explicit schemas slow down early experimentation. That cost is worth paying once the server is meant to leave your laptop. The install path is part of the product A strong MCP README answers 5 questions quickly: What does this server let an agent do? What does installation require? Which client configs are supported? What is the smallest useful example? How do I know the server is working? That last question is where weak projects break. If verification depends on the maintainer explaining it in a chat, it is not productized yet. Public proof compounds Kinocut, Epoch, and DialectOS each prove a different part of the stack: media operations, estimation models, and localization QA. The shared pattern is the lab: a real workflow becomes an agent-callable capability with enough documentation and tests to survive inspection. FAQ What makes an MCP server commercially useful? It has to touch an expensive, repeated, or fragile workflow. If the server only wraps a trivial API call, the product is the API, not the MCP server. ### Repo archaeology turns history into proof - URL: https://kyanitelabs.tech/blog/repo-archaeology-proof-assets - Date: 2026-05-14 - Category: Repo Intelligence - Primary keyword: repo archaeology - Summary: Why commit history is one of the strongest proof sources for learning diagnostics, implementation help, and engineering trust. - Body: Repo archaeology uses commit history as evidence for how a project was actually built, where it got stuck, and what the next intervention should be. It is useful because code history is harder to fake than a positioning paragraph. Kyanite's repo-intelligence work exists because AI-assisted teams generate a lot of motion. The question is which motion taught the system something, which motion created debt, and which motion can become public proof. Commit history is a diagnostic surface A repo carries behavioral evidence: repeated fixes, reverted directions, test gaps, naming churn, and stale public metadata. A good diagnostic does not shame the team for that. It turns the pattern into a map. signals: - repeated failure around release automation - docs updated after code, not before - tests added only after regressions - public metadata lagging behind repo rename The tradeoff is that history is noisy. Repo archaeology needs filters, not mysticism. Why this matters for users Users do not only need the current feature set. They need confidence that the tool can keep improving. Public history, issue handling, release notes, and verified fixes show maintenance behavior. That is why Dev Learning Archaeologist and devarch-framework belong on the Kyanite proof wall. They turn invisible engineering behavior into something a person can inspect. FAQ Is repo archaeology only for learning diagnostics? No. It is also useful for product audits, acquisition diligence, maintainer handoffs, launch readiness, and deciding which proof assets should be public. ### AI discovery needs more than a sitemap - URL: https://kyanitelabs.tech/blog/ai-discovery-llms-txt-geo - Date: 2026-05-14 - Category: SEO / GEO - Primary keyword: AI discovery - Summary: What Kyanite adds so search engines and AI assistants can understand the tools, products, proof, and support path. - Body: AI discovery works when a site gives crawlers and answer engines structured, quotable, current facts about what exists, who it helps, and what proof supports it. A sitemap is necessary. It is not enough. Generative Engine Optimization is mostly discipline. Say the answer early. Use real names. Add structured data. Keep public proof current. Make the commercial next step obvious. The AI-readable stack /sitemap.xml for canonical crawl coverage /llms.txt for answer-engine context /ai-sitemap.json for structured products, repos, and posts JSON-LD for Organization, WebSite, Article, Service, Product, and FAQ entities Direct-answer paragraphs at the top of pages and posts The tradeoff is maintenance. These files cannot be aspirational. If the repo list changes, the proof layer needs to change with it. GEO is strongest when it is useful to humans too Answer engines and human readers both reward the same thing: specific claims with clear evidence. "We build AI tools" is weak. "We build MCP servers, video automation, localization QA, repo diagnostics, and open-source tools backed by public KyaniteLabs repositories" is stronger because it can be checked. FAQ What is GEO? GEO, or Generative Engine Optimization, is structuring web content so AI answer engines can accurately summarize, cite, and route users to it. ## Blog and Lab Notes en español ### Play-1: the acceptance-inversion result - URL: https://kyanitelabs.tech/es/blog/play1-numbers - Date: 2026-09-28 - Category: Measured Research / Speculative Decoding - Primary keyword: Play-1 speculative decoding acceptance - Summary: The measured nmax2 acceptance inversion: 72.2% versus 22.7% for the draft-12 control. Throughput and engine comparisons, with single-lab limits. ### Adversarial custody chains: keep the attacks in the record - URL: https://kyanitelabs.tech/es/blog/adversarial-custody-chains - Date: 2026-09-28 - Category: Measured Research / Evidence Custody - Primary keyword: adversarial custody chains research evidence - Summary: Signed permissions and hash-chained receipts catch real bypasses. Two acceptance-path defects were still open in the source report. ### Local image generation, measured on a consumer APU - URL: https://kyanitelabs.tech/es/blog/local-image-stack-measured - Date: 2026-09-28 - Category: Measured Research / Local Image Generation - Primary keyword: local image generation consumer APU measurements - Summary: Measured sampler costs, guidance timing and model reload overhead. Quality judgments remain single-judge observations, not a leaderboard. ### GPT-6 Sol vs. Luna vs. Astra: a routing policy for coding agents — and when local still wins - URL: https://kyanitelabs.tech/es/blog/gpt-6-sol-luna-astra-routing-guide - Date: 2026-09-26 - Category: Model Routing / Agent Systems - Primary keyword: GPT-6 Sol vs Luna routing for agents - Summary: A routing policy for the actual GPT-6 lineup: Sol for discovery and coding, Luna for bounded high-volume processing, Astra when nothing else holds — each with a verification contract, and the lanes where a local 27B still beats all three. ### The Equalizer Bench: a 3B that can't write ffmpeg, the same 3B shipping video edits, and the bug our own benchmark caught - URL: https://kyanitelabs.tech/es/blog/equalizer-bench-small-models-video - Date: 2026-09-25 - Category: Benchmarks / Agents - Primary keyword: small model benchmark video editing MCP guardrails - Summary: We benchmarked our own thesis: tiny model + deterministic guardrail layer vs raw capability. The curve is textbook, the trim trap is real, and the bench indicted our own product before anyone else could. ### The One-Line Bug That Crashed Our Fast Lane: finding, fixing, and measuring a speculative-decoding crash on a $1,400 mini-PC - URL: https://kyanitelabs.tech/es/blog/the-one-line-bug - Date: 2026-08-25 - Category: Local LLM / Serving - Primary keyword: speculative decoding llama.cpp draft model iGPU speedup - Summary: Spec decoding crashed our fastest lane on day one. The bug was one missing line in our fork; the fix bought +17.7% and a surprise about draft quantization. ### Dos modelos, una mini-PC de $1,400: los números emparejados, fracasos incluidos - URL: https://kyanitelabs.tech/es/blog/two-models-one-mini-pc-paired-numbers - Date: 2026-08-25 - Category: Local AI Infrastructure - Primary keyword: run two local llms on one mini pc paired benchmark - Summary: Un modelo de razonamiento de 35B ya corre junto a nuestro 27B diario en una caja de $1,400, al mismo tiempo. Cada número emparejado, mismos problemas, misma máquina. Los fracasos también están aquí. ### How I became a forward deployed engineer without a software engineer title - URL: https://kyanitelabs.tech/es/blog/how-i-became-a-forward-deployed-engineer - Date: 2026-08-24 - Category: Forward Deployed Engineering - Primary keyword: how to become a forward deployed engineer without degree - Summary: The title is new; the work is old. Twelve years of enterprise deployments plus public, measured AI work. The honest path, artifacts included. ### Evals are the FDE skill nobody lists: my 495-trial public benchmark - URL: https://kyanitelabs.tech/es/blog/evals-are-the-fde-skill - Date: 2026-08-24 - Category: Forward Deployed Engineering - Primary keyword: AI evaluation benchmark LLM evals - Summary: The market says it cannot find people who can build AI evals. The skill is learnable and I published mine: 495 trials, certified floors, sabotage cell, open source. ### Forward deployed vs solutions engineer vs implementation vs customer engineer: el decodificador - URL: https://kyanitelabs.tech/es/blog/fde-title-decoder - Date: 2026-08-24 - Category: Forward Deployed Engineering - Primary keyword: forward deployed engineer vs solutions engineer - Summary: Cuatro títulos, una familia de trabajo, barras de código distintas. Un decodificador para leer cualquier vacante y saber en qué te estás metiendo. ### Qué hace realmente un forward deployed engineer - URL: https://kyanitelabs.tech/es/blog/what-does-a-forward-deployed-engineer-do - Date: 2026-08-24 - Category: Forward Deployed Engineering - Primary keyword: que hace un forward deployed engineer - Summary: La respuesta directa y luego los recibos: todo el trabajo de un FDE sobre un mini-PC de $1.400, con evals públicas. ### The Delegation Card: we asked a $1,400 mini-PC to take our jobs - URL: https://kyanitelabs.tech/es/blog/the-delegation-card - Date: 2026-08-22 - Category: Local LLM / Benchmarks - Primary keyword: local LLM delegation benchmark certified floors Strix Halo - Summary: Not is-it-smart but can-you-hand-it-work-and-walk-away. 495 certified trials, then re-validated at deeper n after the product changed: 965 total, floors to 92.8%. ### Qwen 3.8 27B en Strix Halo: la historia completa, medida - URL: https://kyanitelabs.tech/es/blog/qwen-27b-strix-halo-complete - Date: 2026-08-21 - Category: LLM local / Serving - Primary keyword: Qwen 27B Strix Halo configuracion optima de serving llama.cpp - Summary: Cada dial medido, cada numero publico: la configuracion optima congelada para un 27B en un mini-PC de $1.400. ### Lab Notes: the measured-knees method for reasoning effort - URL: https://kyanitelabs.tech/es/blog/lab-notes-measured-knees - Date: 2026-08-20 - Category: Local LLM / Methods - Primary keyword: reasoning effort calibration knee Qwen3.8-27B - Summary: A methods note on reasoning-effort calibration. Thinking rescued 15/40 hards vs 4/40 off. On easy tasks it bought nothing. Publish the knee. ### Notas de lab: 67% LiveCodeBench-30 en un rig de $1.400 - URL: https://kyanitelabs.tech/es/blog/lab-notes-livecodebench-30 - Date: 2026-08-20 - Category: LLM local / Benchmarks - Primary keyword: LiveCodeBench Qwen3.8-27B Q4_K_XL Strix Halo - Summary: 20/30 = 67% LiveCodeBench-30 en un mini-PC de $1.400. IC Wilson 95% 49-81%. Easy 10/10, medium 8/10, hard 2/10. Subset n=30. No es la card. ### Notas de lab: revertimos una regresión de llama.cpp - URL: https://kyanitelabs.tech/es/blog/lab-notes-llamacpp-revert - Date: 2026-08-19 - Category: LLM local / Benchmarks - Primary keyword: llama.cpp c7d8722 HIP visión NaN logits - Summary: Encontramos una regresión de llama.cpp y la revertimos. Batería n=6 en un rig de $1.400: 0/6 slashes antes, 5/6 después. Mismo Q4_K_XL. No es una historia de quant. ### Notas de lab: 93% HumanEval en un rig de $1.400 - URL: https://kyanitelabs.tech/es/blog/lab-notes-humaneval-93 - Date: 2026-08-19 - Category: LLM local / Benchmarks - Primary keyword: HumanEval Qwen3.8-27B Q4_K_XL Strix Halo - Summary: 28/30 = 93% HumanEval en un mini-PC de $1.400. Qwen3.8-27B Q4_K_XL. Temp 0, thinking off. Fallos: 50 y 145. Log crudo linkeado. ### Notas de lab: el modelo que no puede olvidar pero no puede recordar - URL: https://kyanitelabs.tech/es/blog/lab-notes-cant-forget - Date: 2026-08-19 - Category: LLM local / Benchmarks - Primary keyword: Gated DeltaNet Qwen3.8-27B contexto 262k - Summary: El número primero: este modelo es 75% no transformer. 48 de 64 capas guardan un estado. En un rig de $1.400, carga 198k una vez (1818s) y consulta en 9-27s. ### Notas de lab: la cuenca era un bug - URL: https://kyanitelabs.tech/es/blog/lab-notes-degenerate-basin - Date: 2026-08-19 - Category: LLM local / Benchmarks - Primary keyword: llama.cpp c7d8722 retrieval contexto profundo - Summary: Publicamos una cuenca. El hueco era el binario. Tras revertir c7d8722: 6/6 HIT a 198k. Mapa n=1 del build arreglado. ### Notas de lab: el veredicto del KV - URL: https://kyanitelabs.tech/es/blog/lab-notes-the-kv-verdict - Date: 2026-08-18 - Category: LLM local / Benchmarks - Primary keyword: cuantización cache KV q4 llama.cpp - Summary: La pregunta q8-a-q4 del KV de la noche 1 ya tiene respuesta pareada: misma accuracy, cero tripwires, la mitad del cache. Y el label que tuvimos que corregir en público cuando el contador del server le ganó al estimado. ### Notas de lab: la noche del veredicto - URL: https://kyanitelabs.tech/es/blog/lab-notes-verdict-night - Date: 2026-08-18 - Category: LLM local / Benchmarks - Primary keyword: tope de thinking LLM accuracy - Summary: Un mini-PC de $1.400 sirviendo un 27B a 262k de contexto hace una pregunta: ¿capear cuánto piensa el modelo te cuesta accuracy? La respuesta pareada, el primer intento inválido, y la doctrina que quedó. ### Un mini-PC, una noche y los numeros que discutian entre si: afinando Qwen3.8-27B en Strix Halo - URL: https://kyanitelabs.tech/es/blog/qwen-27b-strix-halo-one-week-local - Date: 2026-08-15 - Category: LLM local / Benchmarks - Primary keyword: Qwen 27B Strix Halo LLM local - Summary: Una noche y una tarde de medicion afinando un modelo denso de 27B en un mini-PC Strix Halo: las bandas honestas, la reversion, la doctrina de crashes y la historia detectivesca del EC. ### Los agentes necesitan herramientas verificables, no mejor teatro de prompts - URL: https://kyanitelabs.tech/es/blog/agents-need-verifiable-tools - Date: 2026-05-23 - Category: Implementacion MCP - Primary keyword: verifiable AI agent tools - Summary: El patron util no es un prompt mas bonito. Es una superficie de herramienta que el agente puede llamar, inspeccionar, verificar y revisar. ### El historial del repo es una señal de producto - URL: https://kyanitelabs.tech/es/blog/repo-history-is-a-product-signal - Date: 2026-05-23 - Category: Inteligencia de repos - Primary keyword: repo archaeology for AI teams - Summary: Un repo no es solo almacenamiento. Es evidencia de decisiones, reparaciones, releases, cambios de nombre, huecos de pruebas y oficio real. ### La ayuda de implementacion es parte de la superficie del producto - URL: https://kyanitelabs.tech/es/blog/implementation-help-is-product-surface - Date: 2026-05-23 - Category: Implementacion de herramientas de IA - Primary keyword: AI tool implementation support - Summary: Una herramienta open source util todavia necesita una ruta desde repo publico hasta entorno funcionando. Esa ruta es producto. ### Por que importa Kinocut - URL: https://kyanitelabs.tech/es/blog/why-kinocut-matters - Date: 2026-05-14 - Category: MCP / Automatizacion de video - Primary keyword: video editing MCP server - Summary: Kinocut da a los agentes de IA herramientas llamables sobre timelines, efectos, Hyperframes y medios terminados en kinocut.dev. ### Monos infinitos, LLMs y el cuarto alrededor de la maquina - URL: https://kyanitelabs.tech/es/blog/infinite-monkey-agentic-systems - Date: 2026-05-14 - Category: Sistemas agenticos - Primary keyword: agentic systems - Summary: El argumento detras del video: la calidad no es solo probabilidad. Es arquitectura, filtros y gusto humano. ### Lo que una herramienta de IA necesita antes de que alguien pueda usarla - URL: https://kyanitelabs.tech/es/blog/ai-tool-implementation-checklist - Date: 2026-05-14 - Category: Notas de construccion - Primary keyword: AI tool implementation - Summary: Una guia practica para convertir una herramienta, flujo o app medio cruda en algo que otros puedan entender, instalar y usar. ### Checklist de implementacion para servidores MCP - URL: https://kyanitelabs.tech/es/blog/mcp-server-implementation-checklist - Date: 2026-05-14 - Category: Implementacion MCP - Primary keyword: MCP server implementation - Summary: El checklist que Kyanite usa para distinguir un servidor MCP de juguete, una herramienta usable y algo que vale la pena implementar. ### La arqueologia de repos convierte historia en evidencia - URL: https://kyanitelabs.tech/es/blog/repo-archaeology-proof-assets - Date: 2026-05-14 - Category: Inteligencia de repos - Primary keyword: repo archaeology - Summary: Por que el historial de commits es una de las fuentes de prueba mas fuertes para diagnosticos, implementacion y confianza tecnica. ### El descubrimiento por IA necesita mas que un sitemap - URL: https://kyanitelabs.tech/es/blog/ai-discovery-llms-txt-geo - Date: 2026-05-14 - Category: SEO / GEO - Primary keyword: AI discovery - Summary: Lo que Kyanite agrega para que buscadores y asistentes de IA entiendan herramientas, productos, prueba y rutas de soporte. ### La Contribution Economy de ResonantDAO, explicada con recibos - URL: https://kyanitelabs.tech/es/blog/resonant-contribution-economy-explained - Date: 2026-09-02 - Category: Contribution Economy - Primary keyword: contribution economy ResonantDAO - Summary: Lo contrario de un DAO normal: primero la contribución verificada, el token después. El primer análisis en español del movimiento, con recibos. ## Contact and Fit - Email: info@kyanitelabs.tech - Best-fit work: implementation, adaptation, diagnostics, docs, handoff, and support around Kyanite-built public tools. - Do not infer private, unlisted, dead, or unavailable tools as public Kyanite project proof.