Baseten Integration

Kimi K3 for stock Grok and explicit consults

PorkiCoder names every Baseten-backed path so users know where paid work runs. These routes require PorkiCoder Premium. Select the managed Kimi K3 model in stock Grok Build, call the distinct Kimi K3 consult for a second opinion, or use the existing fan-out and HogCode routes for their supported Kimi and GLM workflows. Kimi K3 is text-only and does not accept images.

Current Availability

Available in 2.17.39

Stock Grok Build

kimi-k3-baseten is a managed Grok model backed by PorkiCoder's authenticated OpenAI-compatible gateway. The Baseten key remains server-side.

Available

Kimi K3 via Baseten

consult_kimi3_baseten is a distinct, explicitly approved, metered second-opinion route through PorkiCoder's authenticated proxy.

Available

Managed fan-out and HogCode

Kimi K2.7 Code and GLM-5.2 can run as isolated fan-out candidates. GLM-5.2 can judge results, while HogCode uses its managed Kimi K2.7 Code route.

Retired

Legacy Consult names

consult_kimi, consult_kimi27, consult_kimi27_fast, and consult_glm52 remain retired. They are not aliases for the new Kimi K3 route.

Use the Available Routes

The Baseten-backed paths are wired into PorkiCoder's managed workflows. Choose the named model or route you intend to use; PorkiCoder never substitutes one provider for another.

1
Install PorkiCoder
Download PorkiCoder, sign in, and open a project.
2
Choose or authorize the route
Select kimi-k3-baseten in stock Grok, explicitly approve the K3 consult, or approve the fan-out model mix, worker count, and budget.
3
Start the workflow
Use Grok normally with the selected model, call consult_kimi3_baseten, run isolated fan-out candidates, or launch hogcode.
4
Review the result
Inspect candidate diffs before applying anything. Judging and apply operations remain separate, explicit steps.

Baseten-Backed Models

Each provider path is named and scoped so users can tell where a paid request runs.

Route Transport Purpose
Kimi K3 in stock Grok
kimi-k3-baseten
Authenticated server.porkicoder.com/v1 gateway with a local mode-0600 token bridge; the Baseten key remains server-side. Native Grok Build text, reasoning, images, tools, and tool-result turns through a named Kimi K3 model.
Kimi K2.7 Code PorkiCoder-managed Baseten routing for fan-out and HogCode. Isolated implementation or review candidates; read-only project assistance in HogCode.
GLM-5.2 PorkiCoder-managed Baseten routing for fan-out workers and judges. Large-context candidate reviews, architecture tradeoffs, and fan-out judging.
Kimi K3 via Baseten
consult_kimi3 and consult_kimi3_baseten
Authenticated PorkiCoder proxy; the production Baseten credential remains server-side. An explicitly approved, metered Kimi K3 second opinion with clear Baseten attribution.

Routing, Consent, and Credentials

  • consult_kimi3, consult_kimi3_baseten, and Grok's kimi-k3-baseten model all use Baseten. The two consult names are compatibility aliases and never fall back to another inference provider.
  • Paid fan-out, judging, and consult calls require explicit current-conversation approval. Consent is not inferred from an earlier request.
  • Selecting the named Grok model is explicit route choice. Its managed profile uses max reasoning, disables whole-turn client retries, and leaves bounded transient-failure handling to the gateway.
  • PorkiCoder handles authenticated routing, streaming, quota enforcement, and usage tracking on managed routes.
  • The production Baseten credential stays server-side. PorkiCoder does not inject it into terminal environments or the Consult MCP process.
Managed Baseten route
The route runs through PorkiCoder's authenticated gateway. Provider credentials remain server-side, and terminal-injected credentials never act as a quota workaround.

Shared Baseten Capacity Gate

Production runs on the Baseten Startup workspace allowance with an explicit shared gate of 120 requests per minute, 1,000,000 tokens per minute, 12 concurrent calls, and a three-minute queue ceiling. The stock Grok model, Kimi and GLM agent routes, consults, fan-out, and HogCode all consume that same owner-key capacity; PorkiCoder does not multiply quotas with extra keys.

Admission counts the complete serialized request, including reasoning and tool-call history, tools, and response schemas. It reserves 25,000 completion tokens by default and reconciles that reservation against strict numeric provider usage. A prompt that cannot fit while leaving minimum completion room fails before dispatch with a 413 trim-context message; it is never clamped and forwarded anyway.

The managed stock Grok profile advertises an 850,000-token working context, compacts at 85%, requests at most 65,536 completion tokens, and allows 30 minutes of inference inactivity. These safety bounds do not change the provider's advertised model context. Grok retries are set to zero so an ambiguous streamed failure cannot replay paid work outside the gateway's bounded policy.

Baseten's published Kimi K3 Model API rates are $3.00 per million uncached input tokens, $0.30 per million cached input tokens, and $15.00 per million output tokens. Provider pricing and limits can change; the official pages remain the source of truth.

Example Prompts

Name the route and authorization in plain English:

  • Run a two-worker fan-out with Kimi K2.7 Code and GLM-5.2, then compare the diffs.
  • Use GLM-5.2 as the fan-out judge and explain the architectural risks in the winning diff.
  • Launch HogCode and explain this project using its read-only tools.
  • In stock Grok Build, select kimi-k3-baseten and review this design using the relevant excerpt only.
  • I authorize one paid Kimi K3 via Baseten call. Use consult_kimi3_baseten to review this architecture.

FAQ

Do users need a Baseten account or API key?
Not for PorkiCoder-managed routes. PorkiCoder keeps its production credential server-side and applies its own authentication, consent, quota, and usage controls.
What happens when shared capacity is exhausted?
PorkiCoder queues within the bounded shared gate or returns a clear rate-limit, capacity, or trim-context error. It does not retry at both app and backend layers, switch providers silently, clamp oversized prompts, or use additional API keys as a quota workaround.
Where can I read the general docs?
See the worktree fan-out section, the HogCode section, and the separate Consult MCP section for the current consult tool catalog.