Cache by default, audio in chat, and a hard look at what we verified

This week shipped three things us: response caching that runs by default, audio that can ride into any chat model, and expanded per-model parameters. Shipping them was half the job. The other half was verifying the numbers we already publish, on our own account, against our own walls. That results section is below, no spin and no names.

Response caching, on by default

Identical prompts now answer twice as fast the second time around, and the second answer costs nothing. When temperature is 0 (or unset), every chat completion is eligible for server-side caching: a 5-minute fresh window keyed on the exact request. The X-Fikra-Cache header on every response says miss or hit so you can measure it.

Opting out is one key, "cache": false, or the X-Fikra-Cache: no-cache header. Cache hits are not billed and do not consume your daily token budget. Sampling requests (temperature above 0) are never cached: a nondeterministic prompt should give your users fresh tokens, not a canned answer. Cache keys are per-account, so two customers asking the same question never see each other's answers.

Audio rides into any chat model

Until now audio-in-chat only worked on models with native audio input. Now every chat model accepts audio: include an OpenAI-style {"type": "input_audio"} part in your messages and the gateway transcribes it server-side, inlines the transcript, and bills only the actual audio minutes at the transcription rates ($0.001 per minute). Any DeepSeek, GLM, Kimi or Qwen build can now hear. Image parts already rode in as inline base64 data URIs; audio was the missing input modality and it is general-purpose now. Skip note: identical audio prompts on a cache hit do not pay transcription twice.

Per-model parameters, unblocked

Reasoning effort, thinking controls, top_k, min_p, logprobs and other vendor-specific keys now pass through on the upstreams that tolerate them instead of being stripped at the gate. Strict upstreams keep rejecting unknown keys, so those models quietly ignore the extras rather than 400 your request. Send them where they work.

What we verified on our own accounts

We stress-tested our own published walls this cycle with a single self-serve account and a trusted-tier key. The results we stand behind:

• Token ceilings hold. One account burned 58.2 million tokens in under twenty minutes of sequential plus parallel streaming calls, crossing the old 50M daily cap. No 429s after the raise: the new 1B tokens/day ceiling is live and enforced in practice, not just in the docs table.
• Cached input bills for real. That 58.2M-token run cost $1.4990. At the fresh input rate it would have cost about 42% more. The $0.025 cached-input lane applies automatically and itemizes on the bill.
• Streaming is honored end to end, including a usage block on the final chunk, tool calling with tool_calls, JSON-mode response_format, and reconstruction of SSE from cached responses.
• x402 quotes are real. An unauthenticated agent POST to the agent chat path gets an HTTP 402 with a base64 PAYMENT-REQUIRED quote: price, asset, pay-to, timeout. Signed payments settle against the same endpoint.
• Aux lanes verified: 1024-dim embeddings, speech-to-text transcripts of a real MP3, text-to-speech audio back.

One honest caveat: under a sustained simultaneous burst way beyond published RPM, some serving lanes time out at their own capacity before our throttles even engage. Your published limits (3,000 RPM, 250k requests/day, 20M tokens/min, 1B tokens/day on paid tiers) are self-serve guarantees, physics is the wall past that.

Also this week: the free-flagship era closed

Fikra previously ran the DeepSeek line as a free flagship. That has retired. Every DeepSeek build now bills its published line rates, new accounts still start with a $1 signup credit, and limits hike on a single top-up. Same rates as before everywhere else.

What is next

• A second serving lane is in shadow validation for the same catalog: identical requests answered twice, quality and latency compared before anything switches.
• Latency SLOs published per model: p50 and p95 time-to-first-token and tokens/sec, measured from Nairobi, shown on the usage page.
• Cache metrics surfaced to you: hit rate and saved cost visible in your usage history, not just in a response header.
• An audio-in-chat guide with working recipe code, plus per-model parameter matrices in the docs so you know exactly which knobs pass through on which builds.

Agent-facing everything: llms.txt for the surface map, pricing.md for machine-readable rates, GET /v1/models for the live catalog with every price.