OpenRouter for Beginners: Accounts, Credits, API Keys, Model Choice, Provider Routing, Costs, Privacy, and First AI Workflows

OpenRouter gives one account access to hundreds of AI models through a shared dollar-denominated balance, a common API format, and a routing layer that can move requests among eligible infrastructure providers, which allows beginners to compare models from OpenAI, Anthropic, Google, Meta, Mistral, DeepSeek, and other developers without creating and funding a separate account for every company.

Although the platform reduces administrative fragmentation, it does not eliminate the need to understand which model has been selected, which provider processed the request, how many tokens were consumed, what privacy policy applied, and whether an automatic router, alias, or fallback changed the system that produced the final answer.

The safest beginner workflow therefore starts with browser-based testing or a free model, continues with a small credit purchase and a limited API key, and introduces provider controls, fallbacks, tools, automatic model selection, and production budgets only after authentication, output behavior, latency, and request costs have been measured through a fixed model.

·····

OpenRouter sits between an application, an AI model, and the infrastructure provider that serves it.

OpenRouter does not train one general-purpose model that competes directly with every model in its catalog, because its primary role is to authenticate users, normalize requests, calculate usage, apply account policies, select an eligible provider, and return the resulting output through one consistent interface.

The model identifies the AI system whose behavior, context window, modalities, tool support, and prices the application expects, while the provider identifies the technical endpoint that runs that model on particular infrastructure, which may belong to the original developer, a cloud platform, or another approved inference operator.

When several providers offer the same model, OpenRouter can route among them according to availability, recent performance, price, latency, throughput, regional constraints, privacy settings, and other eligibility conditions, while the application continues requesting the same model identifier.

A beginner who understands these layers can distinguish a provider outage from a model failure, a fallback from ordinary load balancing, and a change in model behavior from a change in the infrastructure that served the request.

........

The Main Layers in an OpenRouter Request.

Layer	Practical Meaning
Application	Browser chat, script, website, editor, agent, or business system
API key	Credential that authorizes the request
OpenRouter account	Holds credits, policies, activity, and billing information
OpenRouter gateway	Authenticates, normalizes, bills, and routes the request
Model	AI system selected for the task
Model developer	Organization that created or released the model
Provider	Endpoint and infrastructure that runs the selected model
Response	Generated output, usage data, cost information, and model details

·····

A personal account contains everything required for initial experiments and small prototypes.

A new user can create a personal OpenRouter account, browse the live model catalog, compare models in the browser chat, purchase credits, create API keys, inspect activity, and configure privacy preferences without establishing an organization or inviting additional members.

The browser interface authenticates through the signed-in account, whereas scripts, integrations, and external applications authenticate with an API key placed in the request header, which separates interactive account access from programmatic spending authority.

An organization becomes relevant when several people need shared credits, centralized member administration, workspaces, common provider policies, model restrictions, coordinated budgets, and application-specific keys, although those structures add little value to an individual who has not yet completed a first request.

Beginners should therefore establish one personal account, learn how usage and model selection behave, and move into organizational controls only when several users, applications, or environments require independent governance.

........

OpenRouter Account Structures.

Structure	Appropriate Use
Personal account	Individual learning, prototypes, personal applications, and small experiments
Organization	Shared billing, members, policies, and central administration
Workspace	Separate team, application, department, or environment
API key	Application-specific authorization and spending control
Management API key	Automated creation, rotation, monitoring, and revocation of other keys
Preset	Server-managed model, prompt, routing, provider, and parameter configuration

·····

Credits belong to the account or workspace rather than to an individual model.

OpenRouter credits are denominated in US dollars, which allows one balance to fund requests across models whose prices differ according to input tokens, output tokens, reasoning tokens, images, audio, cache operations, web search, or provider service tiers.

A user does not purchase one block of GPT credits and another block of Claude credits, because OpenRouter deducts the applicable cost from the same payer balance after each successful request, using the token quantities and prices associated with the model and provider that served it.

The account can be funded manually or through automatic top-up, while OpenRouter reserves the right to expire unused credits one year after purchase, which makes large speculative deposits less attractive for beginners whose future usage remains uncertain.

When the balance reaches zero, or when an API key reaches its individual cap, paid requests fail with an HTTP 402 response until the account is funded or the relevant spending limit is changed.

........

How OpenRouter Credits Operate.

Credit Element	Current Treatment
Accounting currency	US dollars
Model-specific balances	Not required
Manual purchases	Available
Automatic top-up	Available
Subscription requirement	Not required for ordinary pay-as-you-go access
API-key spending cap	Optional
Workspace budget	Available for organizations
Unused-credit expiration	OpenRouter reserves the right to expire credits after one year
Zero balance	Paid requests fail
Usage history	Available through dashboards and APIs

·····

Credit purchases include a platform fee even though catalog inference prices are passed through without an added markup.

OpenRouter states that the listed inference price is passed through from the underlying provider without an additional percentage being added to every model request, while the platform earns its ordinary pay-as-you-go fee when the user purchases credits.

Non-crypto purchases currently carry a 5.5 percent fee with a minimum charge of $0.80, which makes very small deposits proportionally expensive because a $5 or $10 purchase receives the minimum rather than the lower mathematical percentage.

Once credits have entered the account, the balance is consumed according to the selected model’s catalog pricing and any additional charges associated with reasoning, search, media, caching, service tiers, or other features included in the request.

Comparisons with direct provider billing should therefore include both the OpenRouter credit-purchase fee and the operational value of maintaining one integration, one balance, one reporting layer, and one routing system across many models.

........

Illustrative OpenRouter Credit-Purchase Fees.

Credit Purchase	Ordinary Platform Fee
$5	$0.80 minimum
$10	$0.80 minimum
$25	Approximately $1.38
$100	$5.50
$500	$27.50
$1,000	$55.00

·····

Small credit purchases are suitable for learning because ordinary text requests may cost only fractions of a cent.

Model prices vary substantially across the catalog, while the cost of one request depends on the number of input tokens, output tokens, reasoning tokens, media inputs, and tool operations rather than on a fixed charge for every message.

A brief prompt sent to an economical model may consume a negligible part of a small balance, whereas a long document, extensive reasoning process, large generated answer, image request, or repeated agent loop may cost considerably more even when the number of visible user messages remains low.

Beginners should purchase enough credits to test realistic prompts without creating an unnecessarily large dormant balance, while recording the usage object returned after each request so that future budgets are based on measured token consumption rather than assumptions.

The catalog’s price per million tokens becomes easier to interpret when translated into representative workloads, although actual spending should always be read from the completed generation because models and providers may account for reasoning, caching, or media differently.

........

Factors That Determine the Cost of One Request.

Cost Factor	Effect
Input tokens	Longer prompts, files, history, and tool definitions increase cost
Output tokens	Longer answers increase completion cost
Reasoning tokens	Reasoning-capable models may add hidden analytical usage
Images or media	Multimodal processing may carry separate prices
Web search	Search operations may add tool charges
Prompt caching	Cache reads may reduce cost while writes may add cost
Service tier	Priority or flexible service may alter provider pricing
Model fallback	A substitute model may cost more or less than the primary
Repeated agent calls	One user task may trigger several model requests

·····

Free models provide an inexpensive introduction while sacrificing consistency and dependable capacity.

OpenRouter maintains free variants whose identifiers end with :free, while the openrouter/free router selects an available compatible model from the current free pool according to the request’s required modalities and features.

The free router is suitable for confirming that an account, API key, endpoint, and request body work, while it also allows beginners to explore basic prompting before purchasing credits.

Because the selected model may change between requests, free-router output cannot be treated as a stable model evaluation, while availability, latency, context capacity, quality, and rate limits may fluctuate as models enter or leave the free pool.

A specific free variant offers greater model consistency while it remains available, although free endpoints still lack the capacity assurances and predictable operating conditions expected from a production service.

........

OpenRouter’s Main Free-Model Options.

Free Method	Behavior
openrouter/free	Selects an available compatible free model
<model-slug>:free	Requests one specific model’s free variant
Browser chat with free model	Allows manual experimentation
Free router model identity	May vary between requests
Specific free variant identity	Remains fixed while available
Paid credits consumed	No when a free endpoint serves the request
Capacity guarantee	Not provided
Production suitability	Limited by availability and rate restrictions

·····

Free-model limits depend partly on whether the account has purchased at least ten dollars in credits.

Accounts that have not purchased at least $10 in credits currently receive as many as 50 free-model requests per day, while accounts crossing that purchase threshold may receive as many as 1,000 free-model requests per day.

The threshold is based on credits purchased rather than on the remaining balance, which means that an account can retain the expanded free-model allowance after spending part of the purchased amount.

Free-model requests are also subject to a current limit of as many as 20 requests per minute, while individual endpoints may become unavailable or constrained before the account-wide daily allowance is exhausted.

Those limits make free models suitable for learning, testing prompts, and low-volume personal workflows, although a production application should use paid capacity when predictable response volume and model identity are required.

........

Current Free-Model Request Limits.

Account Condition	Current Free-Model Allowance
Less than $10 purchased	Up to 50 requests per day
At least $10 purchased	Up to 1,000 requests per day
Minute-level limit	Up to 20 free-model requests per minute
Remaining paid balance	Does not alone determine the boosted tier
Free-model availability	May vary by model and provider
Production guarantee	Not provided

·····

API keys authorize spending from an account balance rather than containing credits themselves.

An API key is a credential that tells OpenRouter which account or workspace should pay for a request, while the actual credits remain attached to the payer rather than being transferred into the key.

Creating five API keys does not create five separate balances, although each key can receive an individual spending cap that limits how much of the shared balance it may consume.

This separation allows one account to maintain distinct credentials for a local script, testing environment, production service, coding editor, and temporary integration, while every request remains visible within centralized activity and billing.

A beginner should avoid using one unrestricted key everywhere, because a leaked credential then exposes the entire available balance and makes it harder to identify which application generated unexpected spending.

........

A Beginner-Friendly API-Key Structure.

API Key	Example Limit	Purpose
Local learning script	$5 lifetime or monthly	First API requests
Development application	$10–$25 monthly	Controlled feature testing
Staging environment	Separate monthly cap	Pre-production validation
Production application	Forecast-based limit	Live traffic
Coding editor	Small separate cap	Easy revocation if exposed
Temporary third-party integration	Short-lived limited key	Isolated experiment
Management key	No inference use	Automated key administration

·····

Separate keys make security, budgeting, and incident response easier.

A descriptive key name should identify the application and environment, while an optional dollar cap should reflect the amount that the integration can reasonably spend before someone investigates unexpected behavior.

Development, staging, and production should use different credentials, because a key exposed through a local experiment should not require the production service to stop while every environment is reconfigured.

If a third-party editor, agent, or no-code tool requests an OpenRouter credential, the user should create a dedicated low-limit key rather than pasting the production key, since revocation then affects only the external integration.

Suspected exposure should trigger immediate revocation and replacement rather than a wait-and-see approach, because a copied API key can continue authorizing requests until it is disabled or reaches its spending limit.

........

API-Key Security Practices.

Practice	Recommended Treatment
Key name	Include application and environment
Spending cap	Apply a small limit during development
Reset period	Use daily, weekly, monthly, or non-resetting according to purpose
Storage	Environment variable or secret manager
Source-code embedding	Avoid
Public repository	Never commit a key
Browser frontend	Do not expose a permanent unrestricted key
Mobile application	Route requests through a controlled backend
Third-party tool	Use a dedicated limited credential
Suspected leak	Revoke and rotate immediately
Dormant key	Disable or delete
Regular review	Compare key usage with expected application traffic

·····

OpenRouter authenticates API requests through a Bearer token in the authorization header.

The standard OpenRouter API base URL is https://openrouter.ai/api/v1, while the most familiar beginner endpoint is /chat/completions, which accepts a model identifier, a sequence of role-based messages, and optional generation parameters.

The API key is supplied through the Authorization header as a Bearer token, while the Content-Type header identifies the JSON body.

Optional HTTP-Referer and X-OpenRouter-Title headers can identify the application for attribution, analytics, and OpenRouter listings, although those headers do not replace authentication and should not contain the secret key.

Storing the key in an environment variable allows code to read the credential at runtime without writing it directly into a file that might be shared, synchronized, or committed accidentally.

........

Core Components of an OpenRouter API Request.

Request Element	Function
Base URL	Directs the request to OpenRouter
Endpoint	Identifies chat completion or another API operation
Authorization header	Supplies the Bearer API key
Content-Type	Declares the JSON request body
Model	Selects a fixed model, router, alias, or preset
Messages	Supplies system, user, and assistant conversation content
Optional parameters	Control output length, randomness, tools, and routing
Application headers	Identify the calling product where desired

·····

The first API request should contain one short prompt and no advanced routing rules.

A minimal request allows the user to determine whether authentication, the endpoint, the request structure, and response parsing work before model fallbacks, tools, privacy restrictions, provider sorting, streaming, or structured output introduce additional failure points.

The free router can be used for the first connection test, although a fixed economical model should replace it as soon as the user begins comparing output quality or repeatability.

The response should be inspected for the generated message, concrete model identifier, provider information where available, token usage, and total cost, while errors should be preserved rather than replaced with a generic failure message.

After the short request succeeds, the user can add a realistic prompt, larger context, required output format, and one feature at a time, allowing every change in behavior to be attributed to a specific configuration decision.

........

A Minimal OpenRouter Request Sequence.

Stage	Configuration
Connection test	One short message and free or economical model
Model test	One fixed model and representative prompt
Format test	Required JSON, table, or prose structure
Context test	Realistic conversation or document length
Cost test	Record usage and total credits
Streaming test	Enable streaming when the interface requires it
Tool test	Add one tool after basic completion is stable
Fallback test	Add one explicit backup model
Provider test	Compare default, price, latency, or throughput routing
Privacy test	Apply ZDR and provider-policy restrictions

·····

OpenRouter remains compatible with many OpenAI-style clients after changing the base URL and model name.

Applications built around the OpenAI chat-completions format can often connect to OpenRouter by replacing the direct provider base URL, supplying an OpenRouter key, and using a model identifier from the OpenRouter catalog.

This compatibility reduces migration work for scripts, agents, coding tools, and no-code systems whose configuration already exposes an OpenAI-compatible endpoint.

Compatibility does not guarantee that every parameter behaves identically across every model, because tool calling, reasoning controls, structured output, image input, audio, stop sequences, and unsupported fields may differ according to the selected endpoint.

The first integration should therefore use a small shared subset of parameters, after which model-specific features can be enabled only after the catalog and provider documentation confirm support.

........

Common Changes When Redirecting an OpenAI-Compatible Client.

Client Setting	OpenRouter Value
Base URL	https://openrouter.ai/api/v1
API key	OpenRouter API key
Model	Exact OpenRouter model identifier
Messages	Standard role-based chat messages
Streaming	Supported where the client and model allow it
Tool calling	Requires model and provider support
Structured output	Requires compatible model and parameter support
Usage logging	Read OpenRouter response usage fields

·····

Exact model identifiers include the developer prefix and should be copied from the live catalog.

OpenRouter model names usually follow the pattern <organization>/<model-slug>, which prevents similarly named systems from different developers from being confused and allows the catalog to expose several versions, sizes, contexts, or specialized variants.

A bare model name without the developer prefix commonly produces a model-not-found error, while an old slug may stop working after a model is retired or its identifier changes.

The model catalog and /api/v1/models endpoint expose the exact ID, canonical slug, context length, architecture, supported modalities, available parameters, prices, providers, and possible expiration date.

Beginners should copy the identifier rather than reconstructing it from memory, while production systems should monitor deprecation information and avoid assuming that a catalog entry will remain available indefinitely.

........

Model-Catalog Fields Worth Checking Before Selection.

Catalog Field	Reason to Check It
Exact model ID	Required for a valid API request
Developer	Identifies the organization behind the model
Context length	Limits prompt, history, tools, and response
Input modalities	Determines whether images, audio, or text are accepted
Output modalities	Determines what the model can return
Input price	Affects documents and long conversations
Output price	Affects generated responses
Reasoning price	May add hidden analytical cost
Tool support	Required for function calling and agents
Structured output	Required for schema-controlled responses
Provider count	Affects routing resilience
Expiration date	Indicates possible retirement

·····

Model choice should begin with the task’s technical requirements rather than popularity rankings.

The most popular model may be unsuitable when the workflow needs a larger context, lower latency, image analysis, structured JSON, function calling, a particular safety policy, or a substantially lower output price.

A beginner should first eliminate models that lack the required modality, context, output format, tool support, or privacy-compatible providers, after which the remaining candidates can be compared through representative prompts.

Input and output prices should be considered separately, because a document-analysis task may be dominated by input cost while a writing or coding agent that produces long responses may spend more heavily on output.

Benchmark rankings and popularity provide discovery signals, although a small evaluation using the actual application’s prompts, source lengths, expected answers, and acceptance criteria remains more informative than a general leaderboard.

........

A Requirement-First Model Selection Process.

Requirement	Selection Question
Text generation	Does the model satisfy the required writing and reasoning quality?
Long documents	Does the context leave enough room for the requested output?
Image analysis	Does the model accept image input?
Tool calling	Is function calling supported by the model and provider?
Structured JSON	Does the endpoint support the required schema behavior?
Coding	Does the model perform well on the relevant language and repository tasks?
Low latency	What are the recent first-token and completion speeds?
Low cost	What are both input and output prices?
Sensitive data	Are eligible providers compatible with the privacy policy?
Production stability	Is the model pinned, available, and served by several providers?
Repeatable style	Does the model remain consistent across representative prompts?

·····

A fixed model creates a cleaner beginner evaluation than an automatic router.

When the same fixed model receives the same prompt, changes in quality can be attributed more confidently to prompt wording, parameter values, provider behavior, or model randomness, whereas an automatic router may select a different model and make the comparison ambiguous.

The openrouter/free router is appropriate for connection tests and informal experiments, while openrouter/auto analyzes the request and chooses from a curated collection of paid models according to its routing logic.

Automatic selection becomes more relevant after the user has defined acceptable quality, cost, context, and latency boundaries, because a mixed workload may benefit from inexpensive models for ordinary requests and higher-capability systems for difficult ones.

A beginner who starts with automatic routing cannot easily determine whether a superior answer resulted from a better prompt, a different model, or the router’s classification, while an inferior result may disappear on the next request because another model is selected.

........

Fixed Models and Routers Compared.

Selection Method	Predictability	Suitable Use
Exact versioned model	Highest	Evaluation and controlled production
Specific free variant	Fixed while available	No-cost model-specific testing
openrouter/free	Low	Learning and connection tests
openrouter/auto	Prompt-dependent	Mixed workloads after evaluation
Latest-family alias	Changes when alias advances	Managed automatic upgrades
Preset	Controlled account-side configuration	Stable reusable application behavior
Fallback list	Primary remains fixed until failure	Reliability with documented substitutes

·····

Versioned model slugs and latest aliases create different maintenance responsibilities.

A pinned version remains stable until the developer changes the identifier, which makes regression testing, cost forecasting, output comparison, and incident analysis easier.

A latest alias advances automatically when OpenRouter updates the represented model family, reducing manual migration work while introducing the possibility that output style, safety behavior, price, context length, tool support, or provider availability changes without an application deployment.

The response should record the concrete model that served every request, particularly when an alias, Auto Router, Free Router, or fallback may resolve to a model different from the string supplied by the application.

Organizations that use aliases should establish evaluation and alerting processes so that a silent model upgrade is detected before it changes a production workflow materially.

........

Model Reference Strategies.

Reference Type	Operational Consequence
Exact version	Stable behavior until deliberate migration
Latest alias	Automatic upgrade with possible behavioral change
Auto Router	Model selected according to prompt classification
Free Router	Compatible free model selected from current availability
Preset	Account-managed configuration without code changes
Ordered fallback list	Substitute model used after eligible failure
Direct provider restriction	Model fixed but provider pool narrowed

·····

Default provider routing usually changes infrastructure without changing the requested model.

When several providers serve the same model, OpenRouter can distribute traffic among eligible endpoints, considering availability, provider health, cost, and other routing signals while preserving the model selected by the application.

If one provider returns a supported failure, rate limit, or availability problem, OpenRouter may attempt another provider for the same model, allowing the request to succeed without requiring the application to integrate several infrastructure endpoints independently.

Provider routing does not guarantee completely identical behavior, because hosting implementations may differ in latency, supported parameters, context limits, quantization, regional processing, or operational policies, even when the advertised model remains the same.

Applications that require strict provider consistency can restrict routing, although those restrictions reduce fallback capacity and may increase the likelihood of a 503 response when the chosen endpoint becomes unavailable.

........

Provider Routing and Model Routing Are Different Processes.

Routing Event	What Changes
Default provider routing	Provider may change while model remains fixed
Provider fallback	Another endpoint serves the same model
Model fallback	Another model is attempted
Auto Router	Router chooses both model and provider
Free Router	Router selects a compatible free model and provider
Latest alias	Alias resolves to the current model version
Provider allowlist	Limits which infrastructure endpoints remain eligible
ZDR requirement	Removes providers that do not meet retention policy

·····

Provider sorting can prioritize price, latency, or throughput after the basic workflow is stable.

OpenRouter allows applications to sort eligible providers according to price, recent latency, or output throughput, while the :floor suffix acts as a shortcut for lower-cost routing and :nitro prioritizes throughput.

Price sorting is appropriate when small cost differences matter more than response speed, whereas latency sorting suits interactive applications whose users need output to begin quickly, and throughput sorting favors workloads that generate long answers after the first token arrives.

Service tiers can request flexible lower-cost capacity or priority processing where supported, although the provider and model must offer the selected tier and the request is billed according to the service actually delivered.

Beginners should leave provider routing at its default until they understand ordinary cost, output, and error behavior, because early restrictions create additional failure modes without necessarily improving the first workflow.

........

Provider-Routing Preferences.

Routing Choice	Intended Effect
Default routing	Balances availability across eligible providers
provider.sort: "price"	Prioritizes lower provider price
:floor	Shortcut for price sorting
provider.sort: "latency"	Prioritizes lower recent latency
provider.sort: "throughput"	Prioritizes higher output throughput
:nitro	Shortcut for throughput sorting
service_tier: "flex"	Requests lower-cost, higher-latency capacity where available
service_tier: "priority"	Requests faster premium capacity where available

·····

Model fallbacks increase completion rates while changing the system that produces the answer.

An ordered fallback list allows OpenRouter to attempt another model when the primary model fails because of downtime, rate limiting, moderation, context validation, provider unavailability, or another eligible error.

A substitute model may use a different context window, tool implementation, safety policy, writing style, reasoning method, and price, which means that a completed response is not necessarily equivalent to the response the primary model would have produced.

Production applications should log the concrete model and provider returned, while downstream interfaces should avoid claiming that the primary model generated an answer when the fallback actually served it.

Fallback design should also ensure compatibility, because a cheaper text model cannot replace a multimodal model when the prompt contains an image, while a model lacking tool calling cannot continue an agent workflow that depends on functions.

........

Fallback Strategies and Their Consequences.

Fallback Strategy	Consequence
Smaller model in the same family	Lower cost with possible quality reduction
Larger-context substitute	Recovers context overflow with possible higher cost
Different developer	Improves infrastructure diversity while changing behavior
Free-model fallback	Reduces spending but sacrifices capacity and predictability
Equivalent multimodal model	Preserves image workflow when capabilities match
No fallback	Maintains model identity while exposing more failures
Several ordered fallbacks	Raises completion probability but complicates evaluation

·····

Presets move stable application configuration from source code into OpenRouter.

A preset can store the selected model, system prompt, fallback order, generation parameters, provider preferences, provider restrictions, privacy controls, and tool configuration, allowing an application to reference one managed object rather than reproducing the complete request policy in every call.

This becomes valuable after a workflow is stable, because prompt or routing changes can be applied through the OpenRouter account without deploying a new application version.

Presets should be versioned and tested like source configuration, since an unnoticed change to the system prompt, fallback model, provider allowlist, or output parameter can alter production behavior even when the application code remains unchanged.

Beginners should postpone presets until they understand the equivalent explicit request fields, otherwise the account-side configuration may conceal why a model, provider, or parameter behaved differently from expectations.

........

Configuration That an OpenRouter Preset Can Centralize.

Preset Element	Example Use
Model	Fixed production model
Fallback models	Ordered substitutes
System prompt	Application role and behavior
Temperature	Output variability
Maximum tokens	Response-length control
Provider sorting	Price, latency, or throughput
Provider allowlist	Approved infrastructure endpoints
ZDR requirement	Privacy-compatible routing
Tools	Search, subagents, or functions
Structured output	Response-format policy
Prompt template	Reusable task instructions

·····

Usage accounting should be reviewed from the first paid request.

OpenRouter responses include usage information covering prompt tokens, output tokens, reasoning tokens where applicable, cached tokens where available, and total cost in credits.

Non-streaming requests return usage in the completed response, while streaming requests place final accounting in the last server-sent event after generation has finished.

The generation identifier can be retained for later audit, while the Activity dashboard allows users to inspect requests, models, costs, and token quantities without building a separate observability system during early experiments.

Logging the requested model alone is insufficient when aliases, routers, provider fallback, or model fallback are enabled, because the concrete model and provider explain what actually generated the output and how the charge was calculated.

........

Fields Worth Logging for Every OpenRouter Request.

Field	Operational Purpose
Requested model	Records application intent
Concrete model served	Detects router, alias, or fallback resolution
Provider	Identifies the serving endpoint
Prompt tokens	Measures input and context cost
Output tokens	Measures response cost
Reasoning tokens	Reveals additional analytical usage
Cache reads	Explains discounted reused input
Cache writes	Explains additional cache cost
Total cost	Supports budgeting and anomaly detection
Generation ID	Supports later audit
Start and completion times	Measures latency
Error code	Supports reliability analysis
Key or workspace	Attributes spending to the correct application

·····

Key-level caps protect the shared balance during development and third-party integrations.

An API key can receive a spending limit and a reset interval, allowing the account owner to prevent one script, editor, or application from consuming unlimited credits after a bug, loop, traffic spike, or credential leak.

The key-status endpoint exposes the total limit, remaining limit, interval usage, accumulated usage, BYOK usage, and free-tier status, which allows an application or monitoring job to alert before the credential stops functioning.

A $5 or $10 development cap is often sufficient for early text experiments, while production limits should be based on measured requests per user, expected token quantities, fallback behavior, and the financial impact of a runaway process.

Key caps complement account monitoring rather than replacing it, because several limited keys may still consume the same shared payer balance and create combined spending above the expectation of any one application owner.

........

Spending Controls at Different OpenRouter Levels.

Control Level	Function
Account balance	Maximum immediately available prepaid spend
Auto top-up limit	Controls automatic replenishment
Organization budget	Limits shared organizational usage
Workspace budget	Limits one project, team, or environment
Member guardrail	Limits individual user activity
API-key cap	Limits one credential
Model allowlist	Prevents use of unapproved models
Provider allowlist	Restricts serving endpoints
Preset	Standardizes request behavior
External monitoring	Alerts on cost, latency, errors, or unusual volume

·····

Privacy depends on both OpenRouter’s controls and the policy of the serving provider.

A prompt passes through OpenRouter before reaching an eligible provider, which means that users must consider the data practices of both layers rather than assuming that every model in the catalog follows one universal retention and training policy.

OpenRouter’s private input-and-output logging is disabled by default, while users can enable it for observability and debugging, after which authorized account or organization administrators can inspect the stored content according to the applicable settings.

Providers may differ in whether they retain prompts, use submitted data for model improvement, support Zero Data Retention, process information in particular regions, or require specialized commercial terms.

OpenRouter exposes provider-policy controls that remove endpoints whose stated data practices do not satisfy the account or request, although stricter privacy requirements reduce the eligible provider pool and may alter price, latency, and availability.

........

Privacy Controls Available Through OpenRouter.

Privacy Control	Function
Private prompt and completion logging	Stores content for account observability when enabled
Provider training preference	Excludes providers that may train on submitted data
Paid-model policy	Applies data preferences to paid endpoints
Free-model policy	Applies separate controls to free endpoints
Provider allowlist	Permits only named providers
Provider ignore list	Excludes named providers
Zero Data Retention	Limits routing to ZDR-compatible endpoints
Workspace policy	Standardizes privacy rules across an application or team
Regional enterprise routing	Restricts eligible processing geography where available

·····

Zero Data Retention can be required for an individual request or broader account policy.

Setting the provider configuration to require ZDR instructs OpenRouter to route the request only toward endpoints whose declared policy meets the zero-retention condition.

This control is relevant when processing confidential business records, legal documents, customer information, private communications, or other material whose governance prohibits provider retention.

A ZDR requirement does not guarantee that every model remains available, because the chosen model must have at least one eligible provider after privacy, price, region, modality, and other routing restrictions are combined.

When no endpoint satisfies every condition, OpenRouter may return a 503 response rather than relaxing the privacy requirement automatically, which preserves the policy while requiring the application to choose another model or configuration.

........

Consequences of Requiring Zero Data Retention.

Consequence	Operational Meaning
Eligible providers decrease	Some endpoints are removed from routing
Price may change	Remaining providers may charge differently
Latency may change	The nearest or fastest endpoint may be excluded
Availability may decrease	Fewer providers remain for fallback
Model choice may narrow	Some models may lack ZDR-compatible endpoints
503 may occur	No provider satisfies every restriction
Policy remains enforced	OpenRouter does not need to route to a noncompliant endpoint
Testing remains necessary	Privacy-compatible routing should be validated before production

·····

Sensitive information should remain outside early experiments until provider policies are understood.

The first OpenRouter request should use harmless synthetic text, because the user has not yet verified logging settings, provider eligibility, retention, training policies, region, key security, or the behavior of third-party integrations.

A browser extension, coding editor, no-code service, or agent platform may introduce its own data handling in addition to OpenRouter and the selected provider, creating another layer that must be reviewed before internal records are submitted.

Organizations should identify whether the information contains personal data, customer secrets, legal privilege, financial records, health information, source code, unreleased products, or contractual restrictions, after which the approved provider and workspace policies can be configured accordingly.

A model’s reputation for privacy should not replace request-level verification, because OpenRouter may route the same model through several providers whose terms differ.

........

Data Categories Requiring Additional Review.

Data Category	Required Review
Customer information	Contract, privacy, retention, and regional processing
Legal documents	Privilege, confidentiality, and provider access
Health information	Applicable law and approved processing environment
Employee records	Access control and retention
Financial data	Confidentiality, auditability, and output verification
Source code	Intellectual property and repository policy
Security reports	Authorized defensive scope
Unreleased product information	Internal confidentiality controls
Public information	Lower sensitivity but still subject to accuracy review
Synthetic test data	Preferred for initial integration experiments

·····

The browser chat offers the least technical route to comparing models.

OpenRouter’s browser interface allows a signed-in user to choose a model, submit a prompt, inspect the answer, and compare alternatives without installing a package or writing code.

A controlled comparison should keep the prompt, source material, output requirements, and generation settings constant while changing only the model, because simultaneous changes prevent the user from identifying which factor produced a quality difference.

Two or three fixed models usually provide more information than a large uncontrolled comparison, particularly when one inexpensive model represents the expected default and one higher-capability model represents the quality ceiling.

The user should record accuracy, instruction following, latency, writing style, context handling, refusal behavior, and cost rather than choosing a model according to one impressive response.

........

Fields for a Beginner Model Comparison.

Comparison Field	Evaluation Question
Factual accuracy	Does the answer preserve source facts correctly?
Instruction following	Does it use the required structure and constraints?
Completeness	Are material details omitted?
Writing quality	Does the tone and density match the task?
Context handling	Does it retain relevant earlier information?
Structured output	Does the response match the requested schema or table?
Latency	How quickly does output begin and finish?
Cost	What were the input, output, reasoning, and total charges?
Refusal behavior	Does the model handle the topic appropriately?
Repeatability	Do several runs remain within an acceptable range?
Provider	Did a different endpoint affect performance?

·····

The first paid workflow should use one economical fixed model and a representative prompt.

After free testing, the user should select one paid model whose context, modality, tool support, quality, and price match the intended task, then create a named API key with a small spending cap.

The first representative request should resemble the eventual workload without introducing every advanced feature, which means that a document-summary application should test realistic document length and output structure before adding search, tools, provider restrictions, or several fallbacks.

The returned usage and cost should be stored, while the same prompt should be repeated enough times to reveal whether quality and latency remain consistent.

A more expensive model should replace the economical default only when a measured difference in accuracy, reasoning, or instruction following justifies the additional cost for the relevant workload.

........

A Progressive First Paid Workflow.

Stage	Beginner Action
Select	Choose one fixed economical model
Limit	Create a named low-cap API key
Authenticate	Send one short request
Represent	Test a realistic prompt and context size
Measure	Log model, provider, tokens, latency, and cost
Repeat	Run several comparable requests
Compare	Test one higher-capability alternative
Decide	Select the least expensive model meeting acceptance criteria
Expand	Add one advanced feature at a time
Monitor	Review activity and key usage regularly

·····

A first document workflow should reserve enough context for the model’s answer.

The context window covers the prompt, conversation history, tool definitions, document text, and generated response, which means that a model advertised with a particular context length cannot devote the complete allowance to source material.

A large PDF, transcript, or collection of notes should be measured against the selected model’s context while preserving room for system instructions, extraction fields, and the required output.

If the prompt exceeds the limit, the application can shorten conversation history, retrieve only relevant sections, divide the document into chunks, produce intermediate summaries, or select a larger-context model.

The largest available context is not automatically the most economical choice, because sending an entire archive repeatedly may cost more than indexing it once and retrieving only the passages required for each question.

........

Options When a Document Exceeds Model Context.

Method	Suitable Use
Remove irrelevant history	Long conversations with old turns
Retrieve relevant passages	Repeated questions against a large corpus
Chunk by section	Reports, contracts, or books with clear structure
Create per-chunk summaries	Multi-stage synthesis
Extract structured fields	Contracts, invoices, or standardized records
Use a larger-context model	One-off tasks requiring broad source visibility
Store results externally	Repeated workflows and auditability
Reduce output allowance carefully	When the required answer is genuinely short

·····

Structured extraction is an appropriate first workflow because success can be measured objectively.

A beginner can ask a model to extract dates, organizations, numerical values, deadlines, and unresolved questions from supplied text, returning null when information is absent and preserving original wording where accuracy matters.

The result can be compared directly with the source, allowing extraction errors, invented values, and format failures to be counted before the model is introduced into a larger application.

Economical models often perform well on straightforward extraction, while higher-capability models become more defensible when the source contains ambiguous language, nested conditions, conflicting dates, or fields distributed across several sections.

The production workflow should validate the returned JSON or structured data rather than assuming that a request for JSON guarantees syntactic or semantic correctness across every model and provider.

........

Fields for a First Extraction Test.

Field	Validation Requirement
Title	Match the source wording
Date	Preserve format or normalize according to an explicit rule
Organizations	Include only entities named in the source
People	Preserve names and roles
Numerical values	Preserve units and qualifications
Deadlines	Distinguish explicit dates from inferred timing
Obligations	Attach the responsible party
Open questions	Include unresolved issues without inventing answers
Missing values	Return null rather than inference
Source location	Preserve paragraph, page, or section where possible

·····

A first writing workflow should constrain facts, audience, length, and required action.

Professional writing is difficult to compare when the prompt asks only for a better email or more polished text, because different models may make unrelated assumptions about tone, purpose, length, and missing details.

A controlled request should identify the audience, factual notes, desired action, maximum length, tone, and prohibited inventions, while the evaluation should check whether every fact remains unchanged and whether the requested outcome appears explicitly.

One economical and one higher-capability model can then be compared using the same notes, allowing the user to decide whether the writing difference justifies the higher token price.

Long outputs should be avoided during early testing unless the final application genuinely needs them, because output-token prices often exceed input prices and verbose generations can dominate total cost.

........

Controls for a First Professional-Writing Prompt.

Writing Control	Required Detail
Audience	Recipient role and level of expertise
Purpose	What the reader should understand or do
Facts	Approved names, dates, figures, and circumstances
Tone	Neutral, formal, concise, persuasive, or another defined style
Length	Maximum words, paragraphs, or sections
Structure	Subject, opening, explanation, request, and closing
Prohibited behavior	No invented facts, promises, names, or deadlines
Output format	Email, memo, message, report, or JSON
Acceptance criteria	Factual preservation and explicit requested action

·····

Streaming changes the delivery experience without changing the underlying model price structure.

A streaming response sends generated text incrementally as server-sent events, allowing an interface to display the answer while the model continues producing it.

This improves perceived responsiveness for long outputs, although the application must assemble the partial text, handle interrupted streams, and read usage data from the final event rather than assuming that every intermediate chunk contains complete accounting.

A network interruption may leave the user with a partial answer even when some model work has already occurred, so the interface should identify incomplete generations and provide a controlled retry path.

Beginners should implement non-streaming requests first because the complete response is easier to inspect, after which streaming can be added when the basic integration and error handling are stable.

........

Streaming and Non-Streaming Requests Compared.

Request Mode	Operational Characteristic
Non-streaming	Complete response returned at once
Streaming	Output delivered incrementally
Non-streaming usage	Included directly in the completed response
Streaming usage	Reported in the final event
Non-streaming debugging	Easier for first integrations
Streaming interface	Faster perceived response
Interrupted stream	Requires partial-output handling
Retry behavior	Must avoid accidental duplicate actions

·····

Common error codes identify authentication, billing, policy, capacity, and request problems.

A 400 error usually indicates malformed JSON, an unsupported parameter, or another invalid request, while 401 commonly reflects a missing, invalid, disabled, or revoked API key.

A 402 response indicates that credits or the key’s spending limit have been exhausted, whereas 403 may reflect permission, policy, guardrail, or moderation restrictions.

Temporary 429 and 503 errors should be handled through controlled backoff, provider fallback, or model fallback rather than immediate repeated retries, which can increase load while the underlying capacity problem remains unresolved.

The application should preserve OpenRouter’s structured error details, request identifiers, model, and routing configuration so that a failure can be reproduced and distinguished from a generic network problem.

........

Common OpenRouter Errors and First Responses.

Error	Likely Cause	Beginner Response
400	Malformed request or unsupported field	Validate JSON and model parameters
401	Invalid, missing, disabled, or revoked key	Check Bearer authentication and key status
402	Balance or key limit exhausted	Add credits or change the cap
403	Permission, policy, or moderation restriction	Review guardrails and content
408	Request timeout	Reduce work or increase client timeout
429	Rate limit	Honor Retry-After and use backoff
503	No eligible provider or temporary unavailability	Relax restrictions or add fallback
Context error	Input and output exceed context	Shorten input or select another model
Model not found	Incorrect or obsolete identifier	Copy the exact catalog slug
Unsupported modality	Model cannot process supplied media	Choose a compatible model

·····

Additional API keys do not create additional global capacity.

Keys exist for authentication, attribution, security, lifecycle management, and spending controls, while platform or provider rate limits remain tied to broader capacity conditions rather than increasing automatically with every new credential.

Creating several accounts or keys to bypass restrictions may violate platform expectations and creates fragmented billing, security, and observability without solving the underlying provider limitation reliably.

Applications that can tolerate model variation may distribute work across several approved models, while applications requiring one model should use backoff, queueing, provider routing, and forecasted capacity.

Production systems should monitor both OpenRouter-level and upstream-provider rate-limit behavior, because a request can fail even when the account balance and API key remain valid.

........

Legitimate Reasons to Create Additional Keys.

Reason	Appropriate Use
Separate development and production	Isolate environments
Third-party integration	Limit exposure and simplify revocation
Department attribution	Track spending by team
Temporary experiment	Apply a short-lived cap
Credential rotation	Replace keys without service interruption
Staging validation	Measure pre-production usage
Vendor isolation	Prevent one vendor from using another application’s allowance
Rate-limit bypass	Not a legitimate key-management purpose

·····

Existing tools may require integration-specific endpoints or configuration.

Many coding agents, editors, libraries, and no-code applications can connect to OpenRouter when they support an OpenAI-compatible endpoint, although some tools require a specialized OpenRouter URL or particular model naming convention.

Official OpenRouter guides cover several coding and agent products, while the exact steps may involve environment variables, configuration files, dedicated provider selections, or tool-specific endpoint variants.

A user should follow the official integration guide for the target application rather than assuming that every tool accepts the generic /api/v1 configuration in the same location.

The API key supplied to an external application should remain separate and limited, while the user should understand whether the tool sends conversation history, files, source code, system prompts, or telemetry in addition to the visible request.

........

Questions Before Connecting a Third-Party Tool.

Question	Reason
Which endpoint does the tool require?	Some integrations use specialized URLs
Where is the key stored?	Local files may expose the credential
Which model naming format is supported?	Tool interfaces may validate slugs differently
Does the tool send files or history?	Privacy scope may exceed the visible prompt
Can the key be limited?	Reduces exposure
Does the tool support streaming?	Affects response handling
Are tools or images supported?	Requires compatible model and integration
Can model fallbacks occur?	Concrete model should be logged
How is usage displayed?	Helps reconcile OpenRouter activity
How is the integration revoked?	Necessary for incident response

·····

Bring Your Own Key allows OpenRouter routing to use existing provider credentials.

BYOK permits an organization to supply supported provider keys, after which OpenRouter can route requests through those credentials while retaining its unified API and selected routing features.

The model inference charge is then billed through the provider account, while OpenRouter may apply a separate BYOK fee according to the current commercial terms and applicable allowance.

This arrangement is relevant when an organization has negotiated provider prices, committed cloud credits, dedicated capacity, direct rate limits, regional governance, or an existing contractual relationship that should remain the payer of record.

Beginners without provider accounts gain little from BYOK, because ordinary OpenRouter credits present a simpler path and avoid the need to configure, secure, fund, and monitor both OpenRouter and several underlying provider accounts.

........

Ordinary Credits and BYOK Compared.

Configuration	Billing and Administration
OpenRouter credits	OpenRouter holds the balance and pays eligible providers
BYOK	Underlying provider bills inference through supplied credentials
Ordinary beginner setup	One account, one balance, and one key
BYOK setup	OpenRouter account plus provider accounts and keys
Negotiated provider pricing	More relevant to BYOK
Committed cloud credits	More relevant to BYOK
Simple personal experimentation	Better suited to OpenRouter credits
Centralized multi-provider routing	Available through both, subject to configuration
Commercial fee rules	Must be checked in current authenticated terms

·····

Organizations add workspaces, shared billing, budgets, and policy enforcement.

An OpenRouter organization allows several members and applications to use a shared funding source while retaining separate workspaces, keys, usage views, provider policies, presets, and spending controls.

Development, staging, and production can be isolated into different workspaces, while model allowlists prevent applications from selecting unapproved or unexpectedly expensive systems.

Provider allowlists and ZDR rules can enforce privacy requirements consistently, while workspace budgets limit the financial exposure of one department or environment without disabling the complete organization.

The transition from a personal account should occur when centralized administration becomes necessary, not merely because the project has become technically sophisticated.

........

OpenRouter Controls for Teams and Organizations.

Team Requirement	OpenRouter Control
Shared funding	Organization credits
Separate applications	Workspaces
Development and production isolation	Distinct workspaces and keys
Department budget	Workspace budget
Developer cap	Member or key guardrail
Approved models	Model allowlist
Approved providers	Provider allowlist
Privacy policy	ZDR and provider-data settings
Reusable configuration	Presets
Key automation	Management API
Cost reporting	Activity and analytics
External observability	Supported monitoring integrations

·····

Auto top-up should be enabled only after normal spending and failure behavior are understood.

Automatic top-up prevents production requests from failing when the prepaid balance becomes low, although it also allows a bug, leaked key, infinite loop, or unexpected traffic spike to purchase additional credits automatically.

A beginner should first observe several days or weeks of ordinary usage, establish key-level caps, configure alerts, and estimate the normal daily or monthly range before enabling replenishment.

The top-up threshold, purchase amount, maximum monthly funding, and payment method should reflect the application’s expected traffic and the time required for an operator to respond to an anomaly.

Production resilience should combine auto top-up with budgets and alerts rather than treating an unrestricted payment method as the only protection against 402 failures.

........

Controls to Establish Before Automatic Top-Up.

Control	Purpose
API-key cap	Limits one application
Workspace budget	Limits one environment or team
Spending alert	Warns before balance exhaustion
Traffic monitoring	Detects abnormal request volume
Model allowlist	Prevents unexpected expensive selections
Output-token limit	Controls long generations
Retry limit	Prevents repeated costly failures
Auto top-up maximum	Limits automatic purchases
Incident procedure	Defines key revocation and service shutdown
Usage forecast	Establishes normal operating range

·····

OpenRouter’s model catalog changes frequently enough to require active maintenance.

New models, free variants, providers, prices, context windows, capabilities, and deprecation dates enter the catalog continuously, while older entries may be retired or replaced.

A prototype that relies on a free variant or latest alias may stop behaving consistently even when the application code has not changed, while a provider restriction may become invalid after availability shifts.

Production applications should pin versions where repeatability matters, monitor the concrete model returned, review catalog changes, and test replacements before an expiration date arrives.

OpenRouter reduces the work required to switch models because the API remains consistent, although the application still needs regression tests to determine whether a replacement preserves the expected output, tool behavior, safety policy, and cost.

........

Model-Catalog Changes That Require Monitoring.

Catalog Change	Possible Consequence
New model version	Quality or feature improvement
Price change	Budget variance
Context change	Request may begin failing or become cheaper
Provider added	Greater capacity or policy variation
Provider removed	Lower fallback resilience
Free variant removed	Prototype loses no-cost access
Alias advanced	Silent behavior change
Model deprecated	Production migration required
Tool support changed	Agent workflow may break
Modality changed	Image or audio request may become invalid

·····

Beginners should avoid combining several routing abstractions before they understand each one.

A request using a latest alias, Auto Router, model fallback list, price-sorted provider routing, service tiers, and several privacy restrictions may succeed, although the user may not understand which configuration selected the final model, which endpoint served it, or why the cost differed from expectation.

The first stable application should use one exact model, default provider routing, one limited key, a modest output cap, and no tools, while every later feature should be introduced through a separate test.

After provider behavior is understood, fallbacks can improve reliability; after several models have been evaluated, Auto Router may optimize mixed workloads; after privacy policies are approved, ZDR and allowlists can enforce the required boundaries.

Layered routing becomes valuable when its decisions are observable, while hidden automatic behavior creates operational uncertainty even when the interface appears easier.

........

A Recommended Order for Adding OpenRouter Features.

Order	Feature
1	Fixed model and simple completion
2	Usage and cost logging
3	Realistic context and output format
4	Streaming
5	Structured output
6	One tool or search capability
7	Provider privacy rules
8	Explicit model fallback
9	Price, latency, or throughput routing
10	Preset
11	Auto Router
12	Organizational budgets and automated key management

·····

A disciplined beginner workflow moves from manual comparison to a monitored production configuration.

The user should begin with a personal account and the browser chat, where two or three fixed models can be tested with one representative prompt while accuracy, instruction following, style, latency, context handling, and cost are recorded.

Free models can confirm basic operation, although a fixed paid model should be introduced before the user evaluates repeatability or production suitability.

A small credit purchase and a limited development key then allow one OpenAI-compatible request to be sent through the API, after which the response should be logged together with the concrete model, provider, token quantities, generation identifier, and total charge.

Only after the representative workflow behaves reliably should the user add streaming, structured output, tools, search, provider restrictions, fallbacks, presets, auto top-up, and organizational controls.

........

Recommended OpenRouter Beginner Sequence.

Step	Action
1	Create a personal OpenRouter account
2	Browse the catalog and understand model-price fields
3	Test a free model or Free Router in browser chat
4	Compare two fixed models with the same representative prompt
5	Review provider-data and logging preferences
6	Purchase a small balance when paid access becomes necessary
7	Create a named API key with a small spending limit
8	Store the key in an environment variable or secret manager
9	Send one request through the chat-completions endpoint
10	Log model, provider, token usage, latency, and cost
11	Repeat with realistic source length and output requirements
12	Add advanced features one at a time
13	Separate development, staging, production, and external-tool keys
14	Enable budgets and auto top-up only after spending is understood
15	Rotate credentials and review activity regularly

·····

OpenRouter is most approachable when its convenience is separated from its automatic decisions.

The platform removes the need to maintain unrelated billing accounts, SDK conventions, and authentication systems for hundreds of models, while its OpenAI-compatible interface allows many existing scripts and applications to change providers through a small configuration update.

That convenience does not make every model interchangeable, because context length, tool support, privacy policy, reasoning behavior, output quality, and token price remain specific to the selected model and serving endpoint.

Credits and API keys should be understood as separate controls, with the account balance funding requests and individual keys authorizing limited portions of that balance according to application-specific caps.

Free models offer a low-cost starting point, although their changing availability and capacity make them unsuitable for workflows that require stable model identity, predictable latency, or guaranteed volume.

Default provider routing normally preserves the model while changing infrastructure, whereas Free Router, Auto Router, latest aliases, and model fallbacks may change the concrete model that generates the answer, which makes response logging necessary whenever those features are enabled.

Privacy remains configurable rather than uniform, since OpenRouter logging, provider training policies, retention rules, ZDR eligibility, and third-party application behavior all influence how submitted information is processed.

A beginner who starts with one fixed model, one limited key, one representative request, and one clear usage record develops a more reliable understanding of OpenRouter than a user who activates automatic routing, several fallbacks, unrestricted spending, and multiple external tools before the first workflow has been measured.

The production configuration should emerge from those measurements, with economical models assigned to routine work, higher-capability models reserved for tasks whose quality gain has been demonstrated, provider controls matched to approved privacy requirements, and budgets aligned with real token consumption rather than catalog prices viewed in isolation.

·····

FOLLOW US FOR MORE.

·····

DATA STUDIOS

·····

[datastudios.org]

·····