CaptchaKraken-v1.2-GGUF

CaptchaKraken v1.2 (GGUF)

A standalone captcha-solving model for Ollama and llama.cpp: the CaptchaKraken-Lora-v1.2 adapter merged into Qwen/Qwen3.5-9B and converted to GGUF. No vLLM, no adapter to wire up, and it runs on CPU if you have no GPU.

Same weights as Sunlight and Twilight — a different container, and a different set of quantisations.

Files

The projector is not optional

mmproj-F16.gguf is the vision half of the model — the part that reads the puzzle. A runtime given only the weights loads a text-only model, and it does not error: it answers every puzzle without having seen the image. Ollama picks the projector up automatically from this repo; if you import by hand, name it in the Modelfile.

ollama show <name> lists vision under Capabilities when it was picked up.

It stays full precision in every build on purpose. Only the language-model weights are quantised — the task is reading a small picture accurately, and quantising the half that does the reading costs far more than it saves.

Quickstart — Ollama

OLLAMA_CONTEXT_LENGTH=16384 ollama serve
ollama run hf.co/CaptchaKraken/CaptchaKraken-v1.2-GGUF:Q4_K_M

Swap the tag for :Q8_0 or :F16.

⚠️ Raise the context length. Ollama defaults to 4k tokens on cards under 24 GB. An animated challenge arrives as several stills in one request and does not fit in 4k — the symptom is that still puzzles work and animated ones fail. 16k is enough.

Quickstart — llama.cpp

llama-server -m CaptchaKraken-v1.2-Q8_0.gguf --mmproj mmproj-F16.gguf \
  -ngl 99 -c 16384 --port 8000

Use it with the client

pip install "captchakraken>=2.5.0"      # or: npm install captchakraken@^2.5.0

export VLLM_BASE_URL=http://localhost:11434/v1     # 8000 for llama-server
export CAPTCHA_KRAKEN_API_KEY=ollama
export CAPTCHA_LORA_NAME=hf.co/CaptchaKraken/CaptchaKraken-v1.2-GGUF:Q4_K_M
export CAPTCHA_LORA_ADAPTER=CaptchaKraken/CaptchaKraken-v1.2-GGUF

Both names matter, and they are different things. CAPTCHA_LORA_NAME is what goes on the wire, so it must match what ollama list shows. CAPTCHA_LORA_ADAPTER is what the client looks up to decide which prompts to send and what resolution to send the image at — both are properties of these weights, and neither can be read off an Ollama model name.

Three things to get right, or it scores far below what it can

1. Send the prompts it was trained on. prompts.json in this repo carries them plus the puzzle-type → template mapping. A mismatched prompt does not error, it collapses accuracy.
2. Leave thinking off. These builds already default to it, because the weights were trained that way — you do not need to send anything. It matters because with thinking on the answer goes to reasoning and content comes back empty, on every puzzle, with no error. If you convert your own GGUF from the safetensors builds, the upstream template defaults thinking on: send reasoning_effort: "none" on Ollama, or chat_template_kwargs: {"enable_thinking": false} elsewhere.
3. Send images at a flat 720² pixel budget. That is the area the model was measured best at, and it decides how many visual tokens it reads a puzzle from. The shipped client does this for you when CAPTCHA_LORA_ADAPTER is set.

Coordinates come back normalized 0–1000, top-left (0,0), bottom-right (1000,1000) — not pixels. Grid screenshots must be sent with cell numbers drawn on them; the model reads those labels and was never trained to invent a numbering. The shipped client does all of this for you.

What v1.2 covers

44 puzzle types across 10 vendors, and it is the first generation to handle animated challenges and typed text captchas at all.

Evaluation

Scored with the project's soft-tolerance grader on the full 1458-sample held-out real eval — every hand-labelled real capture we hold, none of it trained on. Grid puzzles are exact tile-set match with per-error decay; click/drag receive partial credit by normalized distance, so these are graded scores, not "percent solved".

Those figures are the unquantised adapter's, and the GGUF builds do not match them. Driven through the shipped solver over the same held-out captures, the GGUF builds land about 5 points below the same weights served with vLLM. The loss is concentrated in grid and path puzzles — the ones that turn on reading a small label or a precise coordinate — while drag and animated families are unchanged or slightly better.

Q4_K_M costs almost nothing over Q8_0 — under a point separates them, far less than the 4 GB. Take Q4_K_M unless you have the memory to spare.

The gap is the format, not the bit width: 4-bit and 8-bit land within a point of each other while both sit ~5 points under vLLM, and serving at a smaller pixel budget does not recover it. If you want the strongest open weights and you can run vLLM, take Twilight or the adapter instead.

License

LGPL-3.0-only — see LICENSE. Use, modify and redistribute these weights, including in commercial and hosted services. If you distribute a modified version, keep the licence and copyright notices and make your changes available under LGPLv3.