Product reference

Features & availability

Find the capabilities that connect your tools, project knowledge and requests.

View pricing and full limits
Review what each capability does, its availability and its plan requirements. Jump to the category you need.
On this page

Terminal support

One base URL and one key bring your everyday coding terminals onto the same path without changing how you use them.

OpenAI-compatible API

How it works

Chat Completions and Responses; existing SDKs and scripts switch by changing one base_url.

Input
Existing SDK request
Processing
Normalise the protocol, bind the project
Result
Existing code keeps running
Availability
Supported

Anthropic Messages compatibility

How it works

Terminals such as Claude Code connect directly through ANTHROPIC_BASE_URL.

Input
Claude Code message
Processing
Translate, keep tool semantics
Result
Stream back to the terminal
Availability
Beta
Requirements
From Pro Plus

Terminal config generator

How it works

Pick Codex CLI, Claude Code, Cursor, Continue and more; copy a config with the key already filled in.

Input
Pick terminal and key
Processing
Generate the format
Result
Copy and launch
Availability
Supported

Connection check

How it works

The setup guide waits for the key's first real request and shows success, latency, model and protocol.

Input
Wait for a request
Processing
Identify key and protocol
Result
Return the diagnosis
Availability
Supported

Streaming and non-streaming

How it works

SSE streaming, tool calls and multi-turn messages behave like the native API.

Input
Choose a response mode
Processing
Keep event order
Result
Deliver a stable result
Availability
Supported
Terminal support details

Codebase understanding and long-term memory

Explain something once per project; afterwards any terminal can retrieve and reuse it.

Project profile

How it works

Stable facts in five scopes: stack, structure, conventions, pitfalls, stage summary. Each entry can be disabled.

Input
Read repository facts
Processing
Build the profile by scope
Result
Relevant tasks cite it
Availability
Supported
Requirements
From 专业版

Long-term memory

How it works

Five kinds of entries (facts, decisions, preferences, pitfalls, structure) with state, hit count and source; confirm, disable or delete.

Input
A task yields experience
Processing
Confirm source and state
Result
Reuse across terminals
Availability
Supported

Automatic extraction

How it works

With learning consent, conversations can produce suggestions. Review their sources and approve them for selection in relevant requests.

Input
Analyse the task result
Processing
Produce candidates
Result
Inject after confirmation
Availability
Supported

Hand-written entries

How it works

The “tell the assistant” form writes a rule that takes effect immediately.

Input
Write the team rule
Processing
Scope it to a project
Result
Later requests comply
Availability
Supported

Injection switches

How it works

Control profile injection and memory enhancement per project and compare the effect any time.

Input
Choose a project policy
Processing
Toggle context sources
Result
Compare real results
Availability
Supported
Requirements
From 专业版
See the context path

Parallel tasks and cloud agents

Split one big change into parallel, traceable executions with usage and results collected in one place.

Terminal concurrency

How it works

In-flight concurrency, burst ceiling and a live pulse per key; overruns return a readable reason.

Input
Tasks arrive together
Processing
Rate-limit per key
Result
Show in-flight state live
Availability
Supported

Cloud agent runs

How it works

Name a repository, branch, project and allowed actions; an agent engine executes in the cloud.

Input
Submit repo and goal
Processing
Run in isolation
Result
Deliver a summary or PR
Availability
Pro Max
Requirements
From Pro Max

Task replay

How it works

Turn-by-turn requests and replies next to a work-state panel of progress, decisions, pitfalls and to-dos.

Input
Record every turn
Processing
Extract decisions and to-dos
Result
Replay in time order
Availability
Supported

Workflows

How it works

Ordered steps, each with instructions, allowed actions and a verify command; save as a template and rerun.

Input
Define ordered steps
Processing
Execute and verify
Result
Save as a template
Availability
Pro Max
Requirements
From Pro Max

Budget guard

How it works

Set an equivalent-token ceiling per run; it stops at the limit instead of silently burning allowance.

Input
Set a task budget
Processing
Meter each stage
Result
Stop at the boundary
Availability
Pro Max
Requirements
From Pro Max
See a parallel task example

Model routing

Route by stage between the fast and the deep model, wasting nothing on small things and settling for nothing on hard ones.

Stage routing

How it works

Retrieval, rewriting and summaries go fast; architecture and complex fixes go deep.

Input
Detect the task stage
Processing
Choose speed or depth
Result
Record the decision
Availability
Supported

Hard-problem escalation

How it works

High-difficulty turns are escalated automatically, with the reason noted in the request details.

Input
Assess difficulty
Processing
Escalate to the deep model
Result
Show the reason
Availability
Supported

Model allowlist

How it works

Each key is limited to the models it may use, preventing accidental use of expensive ones.

Input
Configure allowed models
Processing
Check before the request
Result
Reject out-of-scope calls
Availability
Supported

Equivalent-token conversion

How it works

Models convert at their ratio into one allowance number.

Input
Read real usage
Processing
Convert by model ratio
Result
Show one allowance
Availability
Supported

Failover

How it works

Upstream failures retry by credential weight and health, with every reason recorded.

Input
Detect upstream failure
Processing
Switch to a healthy route
Result
Keep each reason
Availability
Supported
See the routing policy

Automatic cache management

Repeated system prompts, project profiles and long context can reuse upstream prefix caching to reduce upstream costs. Plan quota is still metered at the model multiplier; cache hits do not reduce quota deductions.

Automatic prefix cache

How it works

System prompts, profiles and tool definitions are recognised as a stable prefix and cached with no request changes.

Input
Detect the stable prefix
Processing
Write the cache partition
Result
Later requests reuse it
Availability
Supported

Multi-turn reuse

How it works

A task's history is cached incrementally by turn; long sessions hit more the further they go.

Input
Append conversation context
Processing
Reuse cached prefixes
Result
Record new and cached tokens
Availability
Supported

Hit metering

How it works

Requests distinguish cached and uncached tokens. Usage shows estimated upstream cache costs; these estimates do not represent reductions in plan quota or user payments.

Input
Separate cached and uncached tokens
Processing
Estimate upstream cache costs
Result
Meter quota at the model multiplier
Availability
Supported

Cache policy

How it works

Set TTL and minimum cache length per project or key; switch it off for sensitive projects.

Input
Set TTL and threshold
Processing
Apply on the request side
Result
Disable or clear any time
Availability
Planned
Requirements
Not available yet; no current plan includes this capability.

Invalidation

How it works

When a profile or memory changes the matching cache is invalidated so stale context is never reused.

Input
Detect a context change
Processing
Void the related cache
Result
Rebuild on the next request
Availability
Planned
Requirements
Not available yet; no current plan includes this capability.

Cache dashboard

How it works

Planned: cache hit rates, estimated upstream cost savings and latency trends by day and Key. Savings estimates do not represent reduced plan quota deductions.

Input
Aggregate cache hits
Processing
Estimate upstream cost changes
Result
Compare latency trends
Availability
Planned
Requirements
Not available yet; no current plan includes this capability.
See cache billing

API keys and projects

Split keys by purpose; each has its own limits, usage and project.

Sign in to manage keys

Metering, billing and plans

Every call lands on one line of the ledger; allowance and spend can be checked any time.

Per-request metering

How it works

Input, output, cache-hit and cache-miss tokens plus cost and duration.

Input
Receive model usage
Processing
Account per request
Result
Produce an explainable bill
Availability
Supported

Usage statistics

How it works

Today / 7 days / 30 days by day, model or key, with CSV export.

Input
Pick a range
Processing
Aggregate by dimension
Result
View or export
Availability
Supported

Plans and allowance

How it works

Five plans, 30-day periods, an allowance bar and days remaining at a glance.

Input
Choose a 30-day plan
Processing
Deduct in real time
Result
Reset at period end
Availability
Supported

Wallet and ledger

How it works

Top-ups, subscription charges and failed-payment refunds, line by line.

Input
Top up the wallet
Processing
Record every charge
Result
Refund failures automatically
Availability
Supported

Allowance alerts

How it works

A reminder at 80% so a task does not stop halfway.

Input
Watch plan usage
Processing
Reach the threshold
Result
Send an account alert
Availability
Supported
Plans and billing

Observability and debugging

No guessing when something breaks: request body, parameters and failure reason are kept together.

Request logs

How it works

Filter by key, model, status and time; infinite scroll; open the detail drawer.

Input
Filter the request
Processing
Inspect parameters and status
Result
Trace to the original message
Availability
Supported

Request detail

How it works

Parameters, usage and cost, peak marker, failure reason code and message body; copy as curl.

Input
Open the record
Processing
Explain usage and failure
Result
Copy to reproduce
Availability
Supported

Live pulse

How it works

In-flight concurrency, requests this second and this minute against their limits, refreshed every 5 s.

Input
Sample live requests
Processing
Compare with limits
Result
Refresh every 5 s
Availability
Supported
Sign in to see requests

Security and governance

Clear account, data and permission boundaries so teams can trust it.

Identity and sessions

How it works

Phone binding and rebinding, WeChat binding, passwords, session list and remote sign-out.

Input
Verify the account
Processing
Manage active devices
Result
End sessions remotely
Availability
Beta

Action allowlist

How it works

Cloud agents only run allowed actions and never exceed the terminal's own permission model.

Input
Declare allowed actions
Processing
Check before execution
Result
Block anything else
Availability
Pro Max

Quota consistency

How it works

Concurrency and allowance are checked live; anomalies leave replay and reconciliation records.

Input
Check allowance live
Processing
Record anomalies
Result
Replay and reconcile
Availability
Beta
See the security boundary

Choose a tool and connect

Check tool access and plan requirements, then verify your first request in setup.