WHAT YOU SHOULD HAVE IN HAND
- A cluster invite link sent to you by your cluster administrator. It makes you the owner of a brand-new organization.
- This guide everything you need to go from that link to a working integration.
Welcome to MKA1
MKA1 is a platform for building AI applications. It gives your team one gateway to large language models plus the higher-level building blocks that real products need: agents, stored conversations, long-term memory, document retrieval (RAG), tools and MCP servers, prompts, skills, guardrails, speech, and evaluations. You work with MKA1 through two surfaces that share the same accounts, teams, and resources:- The Console - a web dashboard for creating and inspecting everything by hand: run prompts in the Playground, save agents, index files, mint API keys, manage your org and teams. The console lives at your cluster’s address (for example platform.mka1.com).
- The API & SDKs - the same capabilities over HTTPS, called from your own code via the TypeScript, Python, or C# SDK, the
mka1CLI, or plain curl. This is how your application talks to MKA1 in production.
Before you begin
You only need two things to start, and you already have both:- A cluster invite link. Your administrator created an invite on the cluster and sent you the link. Opening it makes you the owner of a new organization inside that cluster.
- This guide. It carries you from the invite to a working SDK integration.
15 minute setup
- Step 1 Accept your cluster invite and create your organization.
- Step 2 Get oriented in the console.
- Step 3 Invite teammates and create a team (API keys live on teams).
- Step 4 Create an API key.
- Step 5 Install an SDK.
- Step 6 Authenticate your requests.
- Step 7 Make your first request.
Step 1 · Accept your cluster invite
Open the cluster invite link your administrator sent you. It carries a one-time token and lands you on the Set up your organization page. A cluster invite is an owner invite - accepting it creates a new organization and sets you as the owner.Do this
- Open the invite link. The page validates the token and shows an Owner invite badge (and an expiry date, if one was set). If it says the invite is unavailable, the invite token has expired or been revoked. Ask your administrator for a fresh link.
- Name your organization. Type a name such as Acme Inc. A workspace URL slug is generated for you (e.g. acme-inc); expand Customize if you want to edit it. Lowercase letters, numbers, and hyphens only.
- Choose how to sign in. Create an account with email and password, or continue with Google. If the invite was pinned to your email address, that address is pre-filled and locked.
- Verify your email. If you signed up with a password, MKA1 sends a verification email. Click the link to confirm; you’re then dropped straight into your new organization.
- You’re in. You land in the console as the owner of your organization, ready to invite teammates and create keys.
You are now the organization ownerThe owner has full control. Usage, members, teams, and settings. Everyone else you bring in will be an admin or a member (covered in Step 3). If you were already signed in to MKA1 with a different email than the invite, sign out first: invites are bound to a specific address.
Step 2 · Tour the console
Take a minute to get your bearings. The left sidebar groups every surface into Access, LLM, Agents, and Admin. Here’s what each section is for. You’ll use several of them in the steps ahead.
Access
| Section | What you do there |
|---|---|
| API Keys | Create and manage the authentication keys your code uses (Step 4). |
| Organizations | Manage members, roles, teams, and pending invites. |
| Teams | Create teams and manage their membership. Every API key is scoped to one team. |
| Service Accounts | Create non-human identities for production and attach them to teams. |
LLM
| Section | What you do there |
|---|---|
| Playground | Chat with models interactively. Stream responses in real time. Configure tools, skills, and guardrails, with an advanced-settings drawer. |
| Models | Browse the models available through the gateway, grouped by modality, with registry details for admins. |
| Responses | Create individual responses and inspect stored history, output, tool calls, and token usage. |
| Evals | Build eval suites and launch durable runs to measure and compare model quality. |
| Conversations | Create and inspect stored conversation state, searchable by metadata. |
| Text to speech | Synthesize speech from text and inspect the generation history. |
| Speech to text | Transcribe audio to text and inspect the transcription history. |
| Prompts | Create, version, and roll back reusable prompt templates with {{variables}}. |
| Guardrails | Configure banned-words, prompt-injection, and leakage policies, then test them. |
| Files | Upload, inspect, and delete files used by LLM workflows. |
| Vector Stores | Create stores, attach files, and search indexed document chunks for retrieval (RAG). |
| Feedback | Record and update human feedback on model output; look records up or export a parquet snapshot. |
| Skills | Upload, version, and manage reusable skills, each packaged behind a SKILL.md manifest. |
| MCP Servers | Register MCP server definitions that saved agents can attach as tools; secrets stay in Credentials. |
| Credentials | Store the secrets your MCP servers and integrations need, kept separate from their definitions. |
Agents
| Section | What you do there |
|---|---|
| Quickstart | Stand up a saved agent fast - pick a model, write instructions, attach tools, and run it. |
| Agents | Create and run saved agents that bundle a model, instructions, tools, and metadata. |
| Sessions | Trace and debug agent runs. Replay the transcript and step through raw events. |
| Memory Stores | Browse the markdown memories agents read and write across runs. |
Admin
| Section | What you do there |
|---|---|
| Audit | Review gateway audit requests, build cases, and export responses (cluster admins see every organization; organization admins see their org’s activity). |
| Alerts | Register webhook endpoints that fire when responses fail, scoped to the cluster, an organization, or a team. |
| Model Registry | Add and configure the custom models available in your organization’s registry. |
| Pricing | Maintain the model price book: cluster currency, per-model prices, and per-organization overrides (cluster admins only). |
| Budgets | Create org spend budgets with alert/block thresholds and live spend status (API-key budgets are cluster-admin managed). |
| Usage | Review token, request, and storage usage for the active org and team. |
| Fine-tuning | Launch and monitor fine-tuning runs and checkpoints (coming soon). |
| Serving | Deploy models to the cluster: deployments with scaling and rollback, model registrations, images, fine-tune jobs, accelerators, and secrets (admins). |
Step 3 · Invite your team & organize access

The organization and its owner
When you accept the cluster invite, you become the owner of your organization. The owner has full control: Usage metrics, members, teams, and settings. Everyone else you bring in is either an admin or a member:| Role | What they can do |
|---|---|
| Owner | Full control of the organization - usage, members, and settings. |
| Admin | Manage members, teams, and API keys across the organization. |
| Member | Access their team’s models, files, and API keys. |
Teams
Within an organization you create teams, and members belong to one or more of them. Teams are where work and access actually live: API keys, agents, and other resources are scoped to a single team. A key minted on one team grants access only to that team’s resources. Moving someone (or a service account) off a team revokes the access that came with it, and keys tied to that team stop working. This makes teams the natural boundary for separating projects, environments, or business units. Manage them under Access → Teams, where you can create a team and manage its flat membership roster.Inviting teammates

- No account yet (This is the most likely scenario) - they sign up (email/password or Google) with the invited email, verify it, and are dropped back onto the invite to finish joining.
- Already signed in with the invited email - one click on Accept & join adds them to the organization.
- Signed in as a different email - they’re prompted to switch to the invited account first, since invites are bound to a specific address.
Service accounts for production
For production systems, CI runners, backend services, and scheduled jobs, use a service account instead of a person’s credentials. A service account is a non-human machine identity you attach to one or more teams, and mint API keys for. You can create one by navigating to Access → Service accounts and clicking New service account in the top right corner. Because keys inherit the team scope, detaching a service account from a team (or deleting it) immediately stops every key minted for it on that team, giving you a clean kill switch for production credentials.Step 4 · Create an API key

1 · Identity
Name the key (e.g. Production gateway) and choose the principal it acts as: My user (uses your org role and selected team) or a Service account (a dedicated non-human identity. Service accounts are recommended for production use cases).2 · Scope binding
Pick the organization and team the key belongs to. A key can only see resources inside that one team in that one org — so choose the team whose models, files, and agents this key should reach. (If you have no team yet, create one first under Access → Teams; keys must be scoped to a team.)3 · Permissions (scopes)
Choose which resources the key can read and write. Scopes are checked on every request. Use a preset to move fast, then fine-tune:- Standard - the everyday read/write scopes for building apps (responses, conversations, files, vector stores, prompts, agents, and more).
- Read-only - every
read:scope and nothing else. - All - every scope, including admin-only ones. Available only to org owners and admins.
4 · Rate limiting (optional)
Optionally cap the key to a maximum number of requests per minute, hour, or day. The gateway enforces it and returns429 Too Many Requests before the request reaches a model, so over-limit calls cost nothing.
Step 5 · Install an SDK
MKA1 ships SDKs for TypeScript, Python, and C#, plus a standalonemka1 CLI. Every client authenticates with your API key as a Bearer token and targets the API gateway. The default hosted gateway is https://apigw.mka1.com.
Private clustersOn a private deployment, replace
https://apigw.mka1.com with your cluster’s own gateway host everywhere below. Pass it as the SDK’s serverURL / server_url / serverUrl option, or set it once for the CLI. Your administrator can tell you the gateway URL (it’s the API counterpart to your console address).TypeScript - @meetkai/mka1
The TypeScript SDK installs from the npm package registry:Python - meetkai-mka1
Requires Python 3.10 or newer:C# - MeetKai.MKA1
CLI - mka1
Pre-built binaries are served from downloads.mka1.com. On macOS (Apple silicon):Step 6 · Authenticate your requests
Every request carries your API key as a bearer token in theAuthorization header. For multi-user, server-side apps you also send X-On-Behalf-Of to identify which of your end users a request is for.
When to send X-On-Behalf-Of
SetX-On-Behalf-Of to a stable identifier from your own system (e.g. user_123) whenever your server is acting for a specific end user. This keeps that user’s requests, files, memory, and usage correctly attributed. Use a non-changing ID. Never use an email or display name.
- Authorization only - your own backend workflow, not tied to any one end user.
- Authorization + X-On-Behalf-Of - your server acting for one of your end users; usage and resources stay associated with them.
Issue short-lived tokens (optional)
When a downstream service or browser client needs to call MKA1 without holding your API key, exchange the key for a short-lived JWT viaPOST /api/v1/authentication/api-keys/exchange-token, then use that JWT as the bearer token. See the authentication guide and deep dive.
Step 7 · Make your first request
With a key in hand, generate your first response. Usingmodel: 'auto' lets the gateway choose the right model for the request.

Build with the platform
Everything below is callable with the API key you just created. Each section is grounded in the official guides at docs.mka1.com. Follow the inline links for the full reference.Generate responses (the core call)

input for a single-turn prompt; the result includes the generated text in output_text. Use auto_routing: true to let the gateway pick the right model for you.
Basic call
X-On-Behalf-Of when you are acting for an end user; omit it otherwise.
What auto_routing does
auto_routing is an opt-in request flag, separate from the auto model alias. When you set auto_routing: true, the gateway scores the request’s complexity and routes it to the best quantized, MoE, or dense sibling within the model family you requested. It never swaps to an unrelated model, and it falls back to the model you asked for if that family has no matching sibling.
The score is additive. It rises with prompt length, many or high-agency tools (e.g. code_interpreter, mcp), tool_choice: 'required', structured output, a large max_output_tokens, multi-turn context, and complex-reasoning cues in the text (debug, refactor, plan, incident, code); it falls for short prompts and recognized simple tasks (translate, summarize, classify, extract). The total picks the tier. Higher scores route to dense, mid to moe, low to quantized. A matching reasoning.effort is set (from minimal up to xhigh) unless you’ve set effort yourself. So a short “summarize this” routes to quantized at minimal effort, while a long incident write-up routes to dense at high (or xhigh) effort.
Whenever routing runs, the response metadata records routed_model - the variant actually used. Add auto_routing_debug: true to also get an auto_routing_debug metadata field: a compact JSON string with the requested and routed model, the chosen tier, reasoning effort, score, and the reasons behind the decision. It’s recorded even when no sibling variant is available, so it’s useful for validating rollout behavior. Leave this field off for normal production traffic.
Stream text as it is generated
Setstream: true to receive server-sent events instead of waiting for the full response. Use it to render partial output as it arrives.
Multimodal input (image + text)
The Responses API accepts text, images, audio, and files in one request. Use a structuredinput array of message items, where content is an array mixing input_text and input_image (image via URL, base64 data URI, or an uploaded file_id).
Background responses
For long-running work, setbackground: true (with stream: false) to get an immediate queued response, then retrieve the result later by polling with mka1.llm.responses.get(...) or by streaming. See the background responses guide.
Webhooks instead of polling
Instead of polling, passwebhook_url (and optionally webhook_secret) when creating a background response. The gateway POSTs every status change to your endpoint — response.queued, response.in_progress, response.completed, response.failed, response.incomplete, response.cancelled — as { event, resource_id, created_at, data }, where data is the full event object.
With a secret set, each delivery carries X-Webhook-Signature: sha256=<hex>, an HMAC-SHA256 of the raw JSON body — verify it before trusting the payload. Delivery never blocks the response: three attempts with exponential backoff and a 10-second timeout. The endpoint must be publicly reachable — private and localhost addresses are rejected. The gateway requires webhook_secret to be at least 16 characters.
Conversations & memory

Stateful conversations
A conversation is a server-side container the gateway uses to hold state between Responses requests, so you never resend the full history. Create one, then pass its ID on every follow-up response.conversation on every request; the gateway maintains the thread for you. Use a conversation when you want a reusable, inspectable container for many turns and the ability to list, fetch, or delete items later. Use previous_response_id instead when you only need to fork from a single earlier response.
Long-term memory store
The history tool gives the model memory that persists across sessions. Add{ type: 'history' } to tools and set store: true; each request/response pair is indexed in the background and searched semantically (vector embeddings) when the model decides it needs to recall something. Memory is isolated per end-user via the X-On-Behalf-Of header.
Files, vector stores & retrieval (RAG)

1. Upload a file
Upload the document once. The response returns a file object whoseid looks like file_1783478060914_iemq10dh5h — pass it to vector stores in the next step.
2. Create a vector store and attach files
Create a vector store, passing one or more uploaded file IDs infileIds. The store returns an ID such as vs_1783478061269_mptf5b93t0q. Attached files index automatically.
createFile:
status: "in_progress" while indexing runs, so wait for processing to complete before relying on search results.
3. Search the store for relevant chunks
Run a semantic search to retrieve the most relevant chunks for a user question. The response returns ranked matches withfile_id, filename, score data, and chunk content. Feed that text into your own application logic or a Responses request.
Bonus: structured extraction
When you need typed JSON out of a document rather than free-text chunks, use the Extract resource. For one-off work, callextract with an inline JSON Schema — passed as a JSON string — and the file to read. For repeated jobs, save the schema once with createSchema (here the schema is a plain object) and run it against many files with extractWithSchema, referencing the schema id returned under data.id. Name a model explicitly on every extract call. A successful response returns success, a data object with the extracted fields, and metadata about the run.
Agents, tools & MCP

tools, tool_choice, parallel_tool_calls, max_tool_calls, text, reasoning). When you run it, the service combines your per-run input with the saved config and forwards it into the Responses API through mkllm-gateway. Every run persists the input plus the upstream Responses result, so you also get run history for free. Agents get a stable id like agt_....
Create an agent
Create an agent once with the MKA1 Python, TypeScript, or C# SDKs, including a built-inweb_search tool so runs can pull in current external information:
tools array (as sent over HTTPS) configures the built-in tool:
Run an agent
Execute by sending only the per-run input. The run persistsstatus, the stored gateway_response, and gateway_response_id from the upstream call. If the run used web_search, the persisted gateway_response includes the tool-call entries.
sdk.agents.list_agents(...) / sdk.agent_runs.list_agent_runs(agent_id=...) to inspect saved agents and prior runs.
Version history & rollback
Every committed change to a saved agent — create, update, rollback — appends an immutable version, so an agent’s configuration history is always inspectable. Rolling back doesn’t rewrite history: it appends a new version restored from the target.Attach an MCP tool server
Beyond built-in tools, you can let the model call tools from an external MCP server by adding anmcp entry to tools. Set require_approval to "never" to run immediately, or "always" to pause for end-user approval. Limit callable tools with allowed_tools; pass upstream credentials in headers (these are masked in stored responses).
require_approval: "always", create the response in background mode, poll it, and handle the mcp_approval_request item by sending back an mcp_approval_response.
Prompts, skills & guardrails

Prompt repository
The Prompts API stores, versions, and renders prompt templates centrally. Every template change creates an immutable version, so you get a full change history and can roll back to any earlier version at any time. A rollback is non-destructive and only switches the active version. Templates use{{variable}} placeholders that are rendered server-side when you retrieve a prompt, letting you reuse one template across contexts. Prompts are isolated per API key.
Skills
Skills are reusable, versioned capability bundles you upload to the gateway. Each skill packages tool behavior behind a SKILL.md manifest. The skill’s name and description are read directly from that manifest. You can upload a single file set or a full bundle, manage versions (each skill tracks a default and latest version), and review every file before creating it. Manage skills in the dashboard under Skills, or via the Skills API.Guardrails, rate limiting & usage auditing
These three governance features keep delegated, multi-user traffic controlled and accountable:- Rate limiting - Each API key can carry a quota over one configurable window — per minute, hour, or day. When a key exceeds its limit the gateway returns
429 Too Many Requestsbefore the request reaches the model, so no tokens are consumed and no usage is billed. Handle 429s with exponential-backoff retries. - Usage auditing - Review token, request, and storage usage per org and team under Admin → Usage, filterable by user (org members). For per-end-user reports, query the usage API with its
external_user_idsfilter — theX-On-Behalf-Ofidentity. Each response also returns anX-Request-IDyou can store as a correlation key. - Guardrails - Policy decisions are recorded in the same audit stream: outcomes such as
policy_violationorthrottledandpolicy_actionvalues ofwarn,block, orescalateflow into the Guardrails page, giving you a consistent path from a usage report to the exact action that was allowed, warned, blocked, or escalated.
Speech & voice

llm.speech resource. Use speak for text-to-speech and transcribe for speech-to-text. For real-time, bidirectional conversations, use Advanced voice mode instead. Advanced voice mode is covered separately.
Text-to-speech
speak returns a complete WAV file. The response body is binary audio, and the response headers include X-Language-Code.
speakStreaming and choose mp3 (smaller) or pcm (uncompressed):
Speech-to-text
transcribe accepts an audio file (FLAC, MP3, MP4, M4A, OGG, WAV, WebM, PCM, and more) and returns the transcript plus detected language and confidence:
includeSpeakerData: true (requires WAV or PCM audio). The response then includes a speakers array with labeled segments and offset_ms / duration_ms timing.
Source files: speech, multimodal output.
Evaluate & observe
Once something works, MKA1 helps you measure it and watch it in production.
- Evals - Build an eval suite from datasets, prompts, and graders, then launch durable runs against one or more models. Track accuracy and per-sample scores, and compare models on a leaderboard. Use it to choose a model and to catch regressions before they ship.
- Sessions - Every agent run is recorded. Replay the transcript (messages, reasoning, tool calls) and step through raw events to debug exactly what an agent did.
- Usage & auditing - Review token, request, and storage usage per org and team under Admin → Usage, and filter by end user when you send
X-On-Behalf-Of. Each response also returns anX-Request-IDyou can store as a correlation key.
Audit

X-Request-ID — returned on every API response — to jump to the exact request. Flag entries for review, group related requests into cases, and export response data for offline analysis.
Alerts

response.failed (a response request failed at the model provider) and gateway.request.failed (any gateway request returned a 5xx) — or leave the subscription empty to receive all of them. Optional filters narrow delivery to specific API keys, error codes, or models.
Every endpoint has a detail page showing its configuration, its signing secret (reveal, copy, or rotate it), and recent deliveries with payloads and succeeded / failed / pending status. From there you can re-send a delivery, fire a test alert while integrating, and edit, disable, or delete the endpoint — editing never changes the signing secret.
Pricing, budgets & usage
Every request flows through a billing pipeline: usage records the volumes, the model price book turns them into costs, and budgets enforce limits on the result. This section covers all three.Pricing

- Cluster currency - The currency every price and budget is denominated in.
- Model prices - The cluster-default rate card, one price per model. Rate dimensions follow the model’s modality: input, output, cached-input, and reasoning tokens for LLMs; audio and characters for speech; per-image rates with optional per-size tiers; web search.
- Org overrides - Per-organization prices for when one org bills differently from the cluster default.
- Effective rates - A resolver view showing which price — cluster default, org override, or unpriced — each model resolves to for a given organization. Unpriced models bill at 0.
- Admin → Usage - Total spend priced from the price book, broken down by organization, team, API key, and model — alongside the underlying volumes (see Usage below).
- The API - Query spend over any time range, grouped by model, API key, team, organization, or end user (the
X-On-Behalf-Ofidentity). This is the feed for billing systems; Budgets (below) enforce limits against the same spend.
Budgets

- Period & limit - Daily, weekly, or monthly, with a limit in the cluster currency. Spend windows reset on UTC calendar boundaries.
- Thresholds - Unique percentages of the limit, each paired with an action:
alert(notify) orblock(reject further requests). A budget past a block threshold shows Blocked in the live Spend and Status columns. - Alert webhook (optional) - A URL plus HMAC signing secret that receives threshold notifications.
read:budgets / write:budgets) in Step 4’s key wizard.
Usage

- In the console - Admin → Usage shows a tokens-over-time chart (24h / 7d / 30d), per-category breakdowns (Responses, Completions, Embeddings, Classify, Extract) with input/output tokens and request counts per model, per-end-user rows, file and vector storage, and sandbox operations — all exportable as CSV. The spend section prices these volumes from the model price book (see Pricing above).
- Over the API - Per-category endpoints (
llm.usage.responses,completions,conversations,embeddings,extract,classify,vectorStores,files) return time-bucketed series. Pick abucket_width, filter bymodels,user_ids, orexternal_user_ids(theX-On-Behalf-Ofidentity), and group bymodel,api_key_id,user_id,org_id, orbackgroundfor per-dimension reports.
Serving
Serving turns your cluster’s accelerators — GPU, NPU, or TPU — into autoscaling inference endpoints for models you choose. It lives in its own Serving sidebar section (organization and cluster admins), and your organization must be provisioned for serving by the cluster operator before first use. Six building blocks:- Deployments - A model served behind an inference endpoint on dedicated accelerators, backed by vLLM or SGLang. Configuration changes roll a new revision — roll back to any prior revision at any time — while scaling changes apply in place. The endpoint URL is assigned once the deployment is ready, and endpoint auth requires callers to present a valid API key. Each deployment exposes status, replicas, revisions, logs, and metrics.
- Models - Register a servable model by name and source, optionally pinning a branch, tag, or commit revision for reproducible deploys.
- Images - Build custom container images (base OCI image, apt packages, build commands) for serving engines and fine-tune jobs; deployments default to the engine’s stock image.
- Fine-tune jobs - Train on cluster accelerators: a base model, a dataset, a strategy (LoRA by default, or full fine-tune), and free-form hyperparameters. Follow logs and the event timeline, collect checkpoints, and cancel anytime.
- Accelerators - The accelerator types available to your organization (e.g. A100, H100) and their per-type limits.
- Volumes & secrets - Persistent volumes (fixed-size, or elastic and growing on demand) and secrets such as an hf-token, injected into deployments as environment variables.
Putting it together: build an agent end-to-end
The building blocks compose. Here’s the flagship end-to-end flow: index knowledge, connect tools, package a skill, assemble an agent, run it, and trace the result.
- Index knowledge. Upload your documents as Files and attach them to a Vector Store so the agent can ground answers in your content (see Files, vector stores & retrieval).
- Connect tools. Register an MCP server (or use built-in tools like
web_search) so the agent can take actions and fetch live data (see Agents, tools & MCP). - Package a skill. Bundle reusable behavior behind a SKILL.md and upload it under Skills, then attach it.
- Assemble the agent. Create a saved agent with a model, instructions, and that tool set. You configure the agent once, so you don’t rebuild the request each call.
- Run it. Execute the agent with fresh input from the console or
POST /api/v1/agents/{id}/runs. Each run persists its input and the gateway response. - Trace the run. Open Sessions to replay the transcript and confirm the agent called the right tools.
Reference & support
Keep these close as you build:| Resource | Where |
|---|---|
| Full API reference (OpenAPI + “Try it”) | API Reference |
| Authentication | docs.mka1.com/docs/authentication |
| Generate a response | docs.mka1.com/docs/generate-a-response |
| Files & vector stores | docs.mka1.com/docs/files-and-vector-stores |
| Managing agents | docs.mka1.com/docs/managing-agents |
| MCP tools | docs.mka1.com/docs/mcp-tools |
| CLI | docs.mka1.com/docs/cli/introduction |
| Python SDK | pypi.org/project/meetkai-mka1/ |
| C# SDK | nuget.org/packages/MeetKai.MKA1/ |
| TypeScript SDK | npmjs.com/package/@meetkai/mka1 |
Quick recap
- Accept the cluster invite → you own a new organization.
- Create a team and invite teammates.
- Mint an API key on that team (copy the secret once).
- Install an SDK and authenticate with
Authorization: Bearer. - Call
responses.create— then compose conversations, memory, RAG, agents, tools, and speech into your app.