Integrating Alpie: Notes from Wiring a Reasoning Model into a Forensic Product

We integrated Alpie's alpie-32b reasoning model to power token narrative summaries on Intel Maps. Here's the integration writeup — the production gotchas, the cost shape, and where reasoning models actually earn their compute in a forensic stack.

Most "AI" features in crypto products are an OpenAI key, a system prompt, and a thin wrapper. We tried that first. It was fine, the way a microwave dinner is fine. The summaries it produced were structurally correct — "this token has X holders, the top cluster controls Y percent, here are the relevant infrastructure addresses" — and structurally generic. They read like the same model writing about every token, because they were.

The interesting thing happened when we swapped the backend to Alpie's alpie-32b, a reasoning model exposed via an OpenAI-compatible endpoint at api.169pi.com/v1. The output got tangibly better at the kind of synthesis we care about: noticing that two surface metrics contradicted each other, weighing the relative importance of cluster size vs. KOL overlay, flagging the one anomaly in an otherwise clean read. That is what reasoning models are supposed to do, and on a forensic dataset they actually do it.

This is the writeup of what the integration looked like end to end — what worked, what broke in production, and where a reasoning model earns its (meaningfully larger) compute cost.

Why we tried it

Three reasons, in honest order:

1. Cost. The pricing was meaningfully lower per million output tokens than the equivalent-tier OpenAI or Anthropic model. For a feature that runs on every token-detail view in our app, the unit economics matter.
2. OpenAI compatibility. The endpoint is drop-in for any client that speaks the OpenAI chat-completions schema. Migration was a single environment variable swap and a model-name change, not a rewrite.
3. It is genuinely a reasoning model. The output quality on multi-step synthesis tasks is in a different category from a non-reasoning model of similar nominal size, and the use case — "given these forensic signals, write the verdict" — is exactly the synthesis problem reasoning models solve.

The integration, in code

The full wiring is roughly thirty lines. Anyone who has integrated an OpenAI-compatible endpoint before will recognize the shape:

import httpx, os

client = httpx.Client(
    base_url=os.environ.get("ALPIE_BASE_URL", "https://api.169pi.com/v1"),
    headers={"Authorization": f"Bearer {os.environ['ALPIE_API_KEY']}"},
    timeout=60.0,  # important — see gotchas
)

def summarize_token(token_data: dict) -> str:
    resp = client.post("/chat/completions", json={
        "model": "alpie-32b",
        "messages": [
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": render_token_brief(token_data)},
        ],
        "max_tokens": 1600,  # also important
        "temperature": 0.4,
    })
    resp.raise_for_status()
    return resp.json()["choices"][0]["message"]["content"]

Everything load-bearing about the integration is in two parameters — timeout=60.0 and max_tokens=1600 — and one design decision that lives outside the code: how you construct render_token_brief(token_data).

Gotchas, in order of how badly each one bit us

1. Reasoning models eat output tokens before they emit anything visible

Our first deploy used max_tokens=320, our default for non-reasoning summaries. The endpoint started returning empty strings. Not errors — clean 200 responses with empty content.

What was happening: reasoning models burn output tokens on internal chain-of-thought before they emit the user-visible answer. With a 320-token cap, the model used the entire budget on its internal reasoning trace and had nothing left for the response. Bumping to max_tokens=1600 gave it room to think and still answer. The first visible tokens of the actual summary do not appear until somewhere between token 600 and 1100 on typical forensic prompts.

The general rule we landed on: budget at least 3x the expected response length for any reasoning model. For our summaries that means 1500-2000 tokens to produce 400-500 tokens of actual output.

2. Timeouts need to be much higher

Our default HTTP timeout to non-reasoning chat endpoints was 12 seconds. Reasoning model calls take 15-40 seconds for the same kind of prompt — that's the reasoning budget being spent. We pushed the timeout to 60 seconds and the failure rate dropped to near zero. Anything below 30 seconds will randomly truncate.

This has UX implications. A 30-second blocking request on a token-detail page is unacceptable. Our pattern: kick the summarization async at page load, render a placeholder, populate when the response lands. The summary appears a few seconds after the rest of the page, which is fine because the rest of the page is the deterministic data the user actually came for.

3. The system prompt has to forbid the generic verdict

Off the shelf, the model will happily produce "this token shows a mix of healthy and concerning signals, do your own research." That is the worst possible summary — it is technically true of every token ever launched and has zero information value.

The system prompt we ship explicitly bans the phrase "do your own research," the phrase "mixed signals," and the rhetorical move of refusing to commit to a verdict. We also include a one-shot example of the kind of output we want: specific, opinionated, grounded in the retrieved data. After those changes, the failure mode flipped from "useless generality" to "occasionally too confident," which is the easier failure to manage.

4. Retrieval has to be deterministic, not opinionated

The pipeline that feeds the prompt — render_token_brief — should be a dumb structured dump of the forensic record. Holder counts, cluster shares, top funder, KOL overlay, pool list. Plain numbers, no editorializing. The model's job is to synthesize a verdict from the structured input; if you start adding opinions in the retrieval layer, you double-bias the output.

The cleanest way to think about it: the retrieval layer is the prosecutor (pulls evidence), the model is the judge (writes the verdict). Mixing the roles makes both worse.

What you get for the compute

The summaries the model produces with this setup are tangibly different from the generic-LLM version. Three examples of the kind of synthesis a reasoning model produces and a non-reasoning one rarely does:

• Catching contradictions. "Top-10 share is 18%, which looks healthy, but the largest cluster controls 31% — the share is spread thin only because the cluster is fanned across many small wallets." A non-reasoning summary will report the two numbers in sequence without noticing they're in tension.
• Weighing signal importance. "Three KOLs entered within a 6-hour window 18 days before the public call. That is the strongest signal in this report; the other concentration metrics are within normal ranges." Recognizing which signal dominates the verdict is the reasoning move.
• Refusing the easy verdict. "The grade is C, but the math is dominated by a single 23% cluster. If that cluster were excluded, the grade would be B+. The verdict depends on whether you read that cluster as coordinated or as a single legitimate market maker." Calibrated uncertainty is hard for non-reasoning models; reasoning models handle it natively.

The honest limits

Reasoning models are still language models. They hallucinate, they sometimes refuse to commit, and they can be talked out of a correct verdict by an adversarial follow-up question. None of this is fatal, but it is the reason we treat the summary as one input to the user's read, not the read itself. The deterministic data — the grade, the cluster math, the KOL list — is the load-bearing part. The summary is the narrative on top.

The cost shape also matters. Reasoning models burn more tokens per request than non-reasoning ones, even with the cheaper per-token price. Net per-summary cost ended up roughly comparable to a mid-tier non-reasoning model. We pay it because the synthesis quality is materially better, but if you're cost-optimizing a feature where generic output is acceptable, a non-reasoning model is the right call.

The 60-second recommendation

• If you need synthesis — weighing signals, noticing contradictions, producing a calibrated verdict — a reasoning model is worth the integration cost.
• If you need a description — "tell me what's in this transaction" — a non-reasoning model is faster and cheaper.
• If you're integrating Alpie specifically — set max_tokens=1600, timeout=60.0, write a sharp system prompt that forbids generic verdicts, keep retrieval deterministic.
• If your retrieval layer is sloppy — fix that first. No model will save you from bad input.