> ## Documentation Index
> Fetch the complete documentation index at: https://phaseo.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Phaseo Gateway base URL: https://api.phaseo.app/v1. Send `Authorization: Bearer $PHASEO_API_KEY` with every request.
> Model IDs look like `provider/model`, for example `openai/gpt-6-astra`. Do not guess IDs: list them with `GET /v1/models` or check https://phaseo.app/models. `phaseo/free` routes to an available free model and needs no wallet balance.
> For new text integrations prefer `POST /v1/responses`. `POST /v1/chat/completions` (OpenAI format) and `POST /v1/messages` (Anthropic format) suit existing code.
> The full API contract is https://phaseo.app/docs/openapi/v1/openapi.yaml. Official SDKs: `@phaseo/sdk` (TypeScript) and `phaseo` (Python), plus Go, C#, PHP, Ruby and Rust.
> Search these docs over MCP at https://phaseo.app/docs/mcp, and install Phaseo skills with `npx skills add https://phaseo.app/docs`. If a page is wrong or out of date, report it with the MCP `submit_feedback` tool.
> Manage Phaseo accounts with the `phaseo` CLI (`npm install -g @phaseo/cli`, then `phaseo login` or `phaseo login --device-code`), the `/v1` Management API or the MCP server at `https://mcp.phaseo.app/mcp?access=manage`. Do not send users to the dashboard for account tasks. A person is still needed for sign-up, approving a sign-in, paying the first top-up on the checkout link that `phaseo credits add` returns when no card is saved, confirming each saved-card top-up from the emailed link, and account security (password, MFA, passkeys). Create API keys with `phaseo keys create --name <name> --json`; never guess one. Credit top-ups need `phaseo login --scopes billing:write` first. Task map: https://phaseo.app/docs/v1/developers/manage-from-an-agent.md.

# Inference Parameters

> How core request parameters affect quality, determinism, latency, and cost.

Quantization is one half of model behavior.\
Inference parameters are the other half.

## Core parameters

| Parameter | What it controls | Typical effect |
| - | - | - |
| `temperature` | Randomness in token selection | Higher = more creative/variable, lower = more deterministic |
| `top_p` | Nucleus sampling cutoff | Lower = safer/more focused outputs |
| `top_k` | Candidate token pool size (where supported) | Lower = tighter and more predictable outputs |
| `max_tokens` / `max_output_tokens` | Max generated output length | Caps cost and latency, may truncate responses |
| `stop` | Explicit stopping sequences | Improves output framing and parser reliability |
| `seed` | Random seed (when supported) | Improves reproducibility for debugging/testing |

## Interactions to watch

* `temperature` and `top_p` both affect randomness. Change one at a time while tuning.
* Aggressive low-bit quantization + high randomness can amplify output instability.
* Low `max_tokens` can look like model failure when it is just truncation.

## Recommended defaults (starting point)

* `temperature`: `0.2` to `0.7` depending on creativity needs
* `top_p`: `0.9` to `1.0`
* `max_tokens`: sized to your expected output class, not a huge blanket value

## Tuning workflow

1. Fix quantization first.
2. Lock an eval set.
3. Sweep one parameter at a time.
4. Compare quality + latency + token usage.
5. Keep separate presets per endpoint/use case.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.