AI Tool Access Guide

requirements / Product scope

AI tool access requirements

Identify the product you’re trying to access

A brand’s chat website, desktop app, developer console and model API may each have different regional availability and account requirements. Loading a product’s landing page only confirms that static assets loaded; it doesn’t mean chat, file uploads or developer APIs are available. Before troubleshooting, note the tool, the specific access point, the action you’re taking and the exact message you see. Instead of “Claude won’t open,” for example, describe “I see a region notice after signing in and opening a chat.” That rules out unrelated steps and helps determine whether to check the network or the account.

Check eligibility separately for ChatGPT and Claude web chat and API access. Gemini’s consumer product and developer tools also have separate requirements. Copilot may depend on a personal account, organization access or the product entry point in your editor. For Midjourney, check the website and linked account you actually use. With Cursor, distinguish editor sign-in from model requests and project connections. Similar product names don’t imply shared access, and a web subscription doesn’t include API credits by default.

Check regional and account requirements separately

Platforms may determine eligibility using a combination of network region, account details, payment information and organization policies. A network exit in an eligible region doesn’t mean the account meets every other requirement. If the platform’s official policy doesn’t support your current circumstances, stop retrying and check for an available product or contact the platform’s support team. Don’t enter false information to meet eligibility requirements, and don’t assume every region notice points to a network issue. Check the policy first so you don’t waste time on a problem network settings can’t solve.

Accounts provided by an employer or school may also be subject to administrator policies. If an admin disables an AI feature, restricts external tools or specifies which models are available, changing your personal proxy settings usually won’t help. Check your organization, license status and feature access in the account settings, then ask your admin about the access policy. On a shared computer, make sure your browser hasn’t switched to a different work profile; otherwise, you might mistake another organization’s restrictions for a problem with your account.

Define success beyond loading the home page

For web access, test signing in, opening a chat, sending plain text and receiving a completed response. If your work involves file uploads or chat history, test those actions separately. For developer access, check authentication, permission to use the model and one valid API call. Each test proves only what it covers: a successful model list doesn’t mean every model is enabled, and a short reply doesn’t prove a long-running request will stay connected.

Keep a record of the time, access point and error type; you don’t need to collect the full conversation. Start with ordinary test text that contains no confidential business information. To compare devices, use the same account conditions and perform the same action on each. Results from different models, access points or file types aren’t directly comparable when assessing a route. A controlled comparison is more useful than repeatedly changing settings.

A working connection, an available product and an eligible account are separate things. NiniVPN provides network connectivity; the target AI platform determines account eligibility, model access and content policies.

network / Routing and connections

How network routing and persistent connections work

An IP address is only one risk signal

AI services don’t usually decide access based only on whether a webpage loads. They may consider the network’s region, the type of network an address belongs to, past request patterns and changes during a session. Activity from other users on a shared network exit may also affect how a platform evaluates that address, though the exact rules are usually unknown to users. One verification prompt doesn’t prove an address is permanently restricted, and a route label can’t guarantee that a platform will trust it. Consider the prompt, when it appears and whether the issue can be reproduced.

Frequently changing network exits can make the environment appear inconsistent within one sign-in session. If you switch routes repeatedly before a page finishes loading, identity, chat and resource requests may go through different exits, changing the context the platform sees. For regular use, keep the region and route consistent. Before switching, save your work and let any ongoing task finish, then reconnect and refresh. If the service asks you to authenticate again, complete its normal verification instead of repeatedly refreshing.

DNS, proxy rules and actual routing

Selecting a route doesn’t guarantee that every app uses it. Browser extensions, system proxies, client rules and app-specific network settings may all be in play. If some domains use a proxy while others connect directly, the homepage may load while sign-in redirects fail or resources appear blank. Check the client’s connection logs to see whether failed requests matched the expected rules. Logs may include query parameters, so remove credentials and personal information before sharing them.

DNS controls how domain names are resolved; a proxy controls how requests are connected. They’re related but not the same. Some clients resolve names locally, while others let the proxy handle DNS. A browser’s encrypted DNS setting may also differ from the system setting. A single DNS test page can’t tell you how an entire app is routed. Check the client mode, target domain and request logs together. If resolution results differ, understand the settings before deciding whether to make them consistent.

Consider IPv4 and IPv6 separately, too. A device may use IPv6 for some requests even when the current proxy rules cover only another route. If region detection varies, check that the client handles all relevant traffic and that no other network connection is active. Disabling a protocol isn’t a universal long-term fix. Temporary changes can help isolate the issue; once you know the cause, adjust routing to match what the client supports while preserving any required organizational network features.

Why a page can load but a response still gets cut off

Chat responses often arrive in chunks over a long-lived HTTP connection, though some features use other persistent connection methods. A short request needs to connect and transfer a small amount of data; a long response needs the connection to stay open while it waits and streams. Buffering by an intermediary proxy, network changes, device sleep or an early connection close can leave the interface stuck generating. A normal download speed test doesn’t rule out streaming issues: the two tests use different paths and connection patterns.

To locate the problem, compare a regular page request with a chat request to the same service, then compare short and longer replies. If only longer replies stop, note whether the disconnect happens while waiting or while content is streaming. If changing devices fixes it, check the local network management, browser and proxy settings. If several devices on the same route show the same issue, compare routes next. This order helps avoid mistaking a sleeping device for server-side rate limiting.

“Quantum encryption” is NiniVPN’s service messaging, not a promise that AI platforms will grant access. An encrypted connection doesn’t prevent the target service from identifying your account or seeing content you submit. Network encryption, platform identity and content processing are separate boundaries. You can refer to the global server locations when choosing a route, but AI tool availability still depends on the platform’s current policies and the results of actual requests.

identity / Accounts and sessions

Account creation, sign-in and permissions

Keep your network account separate from AI platform accounts

NiniVPN doesn’t require an email address; you can create an account with a username and password. This applies only to NiniVPN and says nothing about the sign-up process for ChatGPT, Claude or other AI tools. Each platform may have its own profile requirements, identity checks and organization permissions. Always make sure you know which service you’re using. Don’t enter your NiniVPN credentials on an AI platform, or share AI platform credentials with a network provider or third-party troubleshooting contact.

Before creating an AI platform account, verify the official access point and terms of service. Check that search results, shared links and editor pop-ups lead to the correct domain and product. Use a password manager to store credentials separately, rather than reusing the same sign-in across platforms. If the platform offers additional account security options, enable them through its official process. Once network access is restored, check account security notifications for unfamiliar sessions.

Check the browser context when sign-in redirects fail

Third-party sign-in usually involves several sites: the product starts authentication, the identity provider verifies your account, and then the browser returns to the product’s redirect URL. Blocked redirects, restricted site storage or extensions that modify requests can break the return step. Check that normal pop-ups and redirects are allowed, then note which domain appears in the address bar at the end. Don’t paste a redirect URL with its full query string into a support ticket; it may contain temporary authorization data.

If you return to the sign-in page after logging in, check whether the browser switched profiles, site storage is being cleared automatically or the device clock is incorrect. Try a separate browser profile for comparison while keeping your original profile intact. If the new profile works, check extensions and privacy settings one at a time. Clear data only for the relevant site, and save anything unsent first. Don’t start by wiping all browsing history and account state.

Editor-initiated browser sign-in adds another step: returning to the app. If the browser shows a successful sign-in but the editor remains signed out, the system may not be handing the app-protocol redirect to the right program, or the editor may be unable to reach the endpoint that exchanges credentials. Check the browser authentication result, the system’s prompt to open the app and the editor logs separately. Repeatedly clicking sign-in usually creates more pending sessions; it won’t fix the app’s network settings.

Verification prompts, account restrictions and organization access

If you encounter a verification challenge, follow the platform’s instructions and keep the current session environment stable. Don’t repeatedly submit requests with automation scripts, or buy or borrow accounts from unknown sources. If the challenge keeps failing, note the prompt type and where it appears, pause repeated attempts, then check the platform’s status page or support options. Changing regions, browsers and profiles at the same time introduces too many variables and makes the original issue harder to diagnose.

If the platform explicitly says your account is restricted, your license is insufficient or your organization blocks access, check the account or organization settings. Admin approval, product subscriptions and model permissions are separate: being able to open an editor doesn’t grant access to every AI feature, and joining an organization doesn’t mean it allows external models. When contacting an admin, provide the feature name, a summary of the prompt and the steps that led to it. Don’t ask them to disable every security policy; a narrowly scoped change is easier to assess and roll back.

A region notice after sign-in may also mean your profile and product access point don’t match, rather than indicating a problem with your current network exit. Check the platform’s official availability and relevant account details, then use its appeal process if needed. Don’t use false residency information or create accounts repeatedly instead of appealing. Keep a record of normal use to explain the context, but remove conversation content, payment details and credentials before submitting it. Support teams usually need only the error and when it occurred.

A working connection can’t reverse an account restriction. If the page clearly reports an eligibility or permission issue, address the platform account first. Continue investigating the network only for connection errors, timeouts or failed resource requests.

browser / Streaming responses

Check page loading and streamed output

Break a blank page down by failure stage

A blank page may result from a failure loading the initial document, scripts, identity data or chat content. Seeing the page title doesn’t mean the app has finished initializing. Check for navigation, an account avatar and chat history, then determine whether only the content area or the entire page is affected. Open the browser’s network panel, refresh and inspect the domains, request types and status of failed requests—not just anything highlighted in red. A blocked analytics request from an extension may not affect core features.

To reduce log noise, close tabs unrelated to the task and reproduce the issue in a clean session. Note whether the initial page loaded, scripts downloaded, account requests returned and chat requests were sent. Don’t upload a full network log publicly; it may contain session credentials, conversation text, uploaded filenames and account identifiers. If you need help, share a redacted error summary first and keep raw logs in a controlled location.

A response that appears stuck doesn’t always mean the request failed

A streaming request that remains pending while generating is normal. Check whether data continues to arrive, the interface updates in chunks and the response eventually shows a normal completion marker. If the network panel receives data but the page doesn’t update, a frontend script or extension may be at fault. If no new data arrives, consider server-side wait time, an idle connection or the local device state. Don’t cancel solely because a request takes a while, and don’t automatically resend the same task.

Some intermediary proxies buffer chunks and forward them all at once, so no text appears for a while and then the whole response arrives. For corporate gateways, self-hosted reverse proxies or development relays, check whether response buffering, compression and read timeouts are suitable for streaming. Only the person who manages the device or service can change these settings. If an organization’s gateway is causing the issue, contact an admin; don’t disable certificate verification or change security policies on a managed device.

Power-saving modes, background restrictions and automatic network switching can interrupt requests on mobile devices. To reproduce the issue, keep the app in the foreground and the device awake; don’t switch between Wi-Fi and other networks while a response is generating. On desktop, check system sleep, network-adapter power saving and whether the client is still running. If the issue occurs only in the background, focus on system lifecycle management instead of repeatedly changing routes. Once you’ve isolated the cause, adjust power settings for the device’s actual needs.

Test files, images and voice features separately

Text chats, file uploads and generated downloads may use different domains or connection methods. If text works but a file action fails, first check the file type, the platform’s current limits and your account permissions; then check proxy rules for the resource domain. An attachment error doesn’t mean the entire service is unavailable. Reproduce the issue with a small test file that contains no personal information, and keep the original file local. Don’t upload confidential work materials just to test the network.

Voice and real-time interactions are more sensitive to connection continuity and may also depend on browser permissions, input and output devices, and organization network policies. First make sure the devices work in your system settings, then check that the browser has the required permissions. A successful text chat confirms only part of the request path; it doesn’t verify real-time features. If a resource download fails, check whether the task finished and whether the resource link expired before rerunning it, to avoid duplicate tasks and extra usage.

For a browser comparison, keep the account, route and test content the same; change only the browser profile or temporarily disable one suspected extension. Record the result after each comparison before making another change. If you disable several extensions, clear all storage and switch routes at once, even a successful result won’t tell you what fixed it. Reproducible, reversible checks that change one variable at a time help you find a reliable setup—not just get the page to open once.

After an interrupted task, check the chat history or task list first to see whether the service completed it. Resending a creation, upload or paid request may create duplicate work; a client-side error doesn’t mean the server didn’t process it.

api / Requests and permissions

How API calls differ from the web app

Check authentication, usage and model access separately

API calls require more than network access: you also need the right endpoint, authentication method, project, model name and request format. Web chat benefits generally don’t count as API credits, and developer products don’t share API keys. Check the target platform’s console for the current project, billing status and model permissions before making a minimal request. For compatible APIs, verify what is actually supported; similar field names don’t guarantee identical parameters, streaming events or tool-call behavior.

Store API keys in local environment variables or a managed secret store—not in webpages, code repositories, screenshots or public logs. Server-side calls should keep keys on a controlled backend; don’t send a key to the browser and rely on hidden code to protect it. Avoid debug options that print all request headers. If a credential is exposed, revoke and replace it on the platform; deleting the text that revealed it isn’t enough, since the old credential may have been copied.

Test connectivity before testing the application request

The command below checks authentication to the OpenAI models endpoint; it isn’t a universal interface for every AI service. Before running it, set OPENAI_API_KEY in your current terminal and set AI_PROXY_URL to the HTTP proxy address provided by your client. The example has no fixed port and includes no API key. If your program routes traffic another way, adjust it to match your setup instead of stacking unnecessary proxies.

curl --fail-with-body --silent --show-error \
  --noproxy '' \
  --proxy "$AI_PROXY_URL" \
  --header "Authorization: Bearer ${OPENAI_API_KEY}" \
  https://api.openai.com/v1/models

Before running the command, confirm both variables are set; if either is missing, stop rather than treating an empty request as a route test. A returned model list confirms only that this endpoint’s connection and authentication worked; it doesn’t prove a particular generation model is available. Next, make a minimal application request using a model you’re authorized to access, following the official documentation. Use ordinary test text, not confidential business data. Endpoints, authentication headers and required request headers vary by provider, so follow each provider’s documentation.

When an error occurs, first check whether you received an HTTP response. DNS resolution failures, TLS handshake failures and connection timeouts are issues before reaching the service. A structured error response usually points to authentication, permissions, usage limits or request parameters. The status code helps categorize the issue; the response body provides context. Keep both. Don’t label every error a “network issue,” or the application may keep retrying problems that require human attention.

Streaming APIs and retry strategies

Streaming APIs require the client to keep reading the response body and parse events as specified by the provider. Transport chunks don’t necessarily align with complete text or event boundaries, so the parser must handle split content. If the app reads the response only after it ends, you won’t see incremental output even when the network is working. When debugging, record connection success, arrival of the first data and normal completion as separate stages. Don’t combine model wait time and connection setup into one metric.

Set limits on retries. Don’t retry authentication failures, invalid parameters or explicit permission errors; for capacity or rate-limit errors, follow the service’s wait instructions and use a finite retry policy with backoff. For endpoints that generate, write or create tasks, check whether they support idempotency. The server may still be processing after the client times out. Resubmitting immediately could consume usage twice or trigger external tools more than once.

Set connection and response-read timeouts separately, choosing values for the task and the provider’s guidance rather than copying another project’s settings. Long-running tasks should support cancellation, server-side status checks and a clear completion state. A request ID can help the platform investigate, but logging the request body or key usually isn’t necessary. Minimal logs with request stage, error type and ID are more suitable for everyday operations and reviews than storing full user inputs.

runtime / CLI, IDE and CI

Proxy configuration boundaries in development

Processes don’t automatically inherit browser settings

A browser may access an AI website while a command-line tool fails because each process can use different network settings. System proxies, browser extensions and terminal environment variables are separate mechanisms. Whether a program reads HTTPS_PROXY or ALL_PROXY depends on its runtime, network library and implementation. Check the tool’s proxy documentation, then test with a minimal request; the presence of an environment variable doesn’t prove it’s being used.

Running programs usually don’t pick up new environment variable values automatically. Restart the target process from the right terminal, or reopen the relevant app. An integrated terminal may inherit an older environment from when the editor started, so opening a new terminal tab may not be enough. Note where the program is launched, which variables are set beforehand and whether the tool has its own proxy setting. Once you know the configuration priority, you can change the right layer.

Verify the editor, remote host and container separately

Copilot, Cursor and other editor tools may involve browser sign-in, a plugin process, model requests and project tool calls. Being signed in to the editor confirms only the identity step; it doesn’t prove the model connection works. If only a plugin fails, use its logs to identify where the request originates and what kind of error occurred, then check editor-specific proxy settings and certificate requirements. Don’t reinstall your entire development environment instead of checking this, and don’t delete project settings without confirming they’re the cause.

In remote development, the interface is local, but the extension or command may run on a remote host. Your local client’s connection won’t automatically cover requests from the remote machine. A loopback address inside a container points to the container itself, not the host’s proxy. Map the path from interface to process to proxy to target platform, then configure networking for the remote host or container. Don’t expose a local proxy listener to external networks just to give a container access; restrict who can reach it.

Corporate environments may use organization certificates or gateways that inspect HTTPS traffic. A certificate trusted by the browser may not be trusted by the language runtime or plugin’s certificate store. Ask an administrator for the correct installation method and verify its scope. Disabling TLS verification hides certificate-chain and server-identity problems, so it isn’t a suitable permanent setting. If the app has a dedicated certificate configuration, follow its documentation rather than changing trust behavior for other system apps.

Manage CI secrets, networking and logs separately

CI jobs run on isolated runners and can’t use your development computer’s local proxy or automatically inherit your terminal environment. Use an authorized network route that the runner can actually reach, and check that its region complies with the target platform’s policies. Keep troubleshooting jobs focused on authentication and a minimal request; don’t repeatedly trigger model generation throughout the build. For pipelines triggered by external contributions, don’t expose secrets to untrusted code.

Inject keys through CI secret variables and disable command echo and sensitive-header output in logs. Variable masking won’t protect every encoded, truncated or concatenated form of a secret, so keep debug output limited. Apply appropriate permission boundaries to projects, organizations and environments, and don’t leave credential files in caches or build artifacts after a job finishes. For failures, records of the stage, status and request ID are usually enough; you don’t need to upload the full environment variable list.

Finally, check whether model responses can automatically run commands, read or write files, or access external services. Restored network access doesn’t mean every tool call should be allowed. For agentic development tools, review permissions, working directories and confirmation steps; don’t treat text in an untrusted repository as authorization to take action. A stable connection is only one operational requirement. Credential protection and execution permissions still need to be managed by your development process, which is why a successful local test shouldn’t be copied unchanged into a production pipeline.

diagnosis / Troubleshoot by error type

Connection failures, rate limits and account restrictions

Start by identifying where the request stops

Preserve the evidence before changing anything. Record the tool and access point, the action you took, the exact error, the time and the current network region. Note whether you recently updated the app, changed networks or adjusted proxy settings. For an ongoing task, check its history and status first. Then classify the error: DNS resolution, connection setup, TLS handshake, authentication or application processing. Troubleshooting by layer helps avoid mistaking a server-side usage limit for a lost connection.

If there’s no response at all, start with the local network and proxy state. Confirm the client is running, its subscription settings are valid and the target request matches the expected rule. If only one app fails, check that app first; if all apps fail, then check the system network and client. Don’t begin by resetting the router, deleting settings and creating a new account. The broader the changes, the harder they are to undo—and the harder it is to find the original cause.

Rate limiting doesn’t mean the network exit is at fault

Rate limits may apply to an account, project, model, concurrent requests or other resources. Capacity notices may also mean the service is temporarily busy. Read the specific reason in the error body and check your usage in the console and the platform’s status page. An error code without its message isn’t enough to draw a conclusion. Retrying more often usually makes things worse, and changing routes won’t affect account-level limits. Reduce request load, combine duplicate actions and follow the service’s guidance on when to try again.

If an app requests a model every time an input changes, or a background task immediately retries after failure, one click may generate many requests. Check the trigger logic, cancellation behavior and deduplication strategy; confirm whether the previous request actually stopped. For shared projects, check usage from other members and automated tasks too—not just the local app. Once you identify an application behavior, fix the request logic instead of blaming the route for a growing stream of requests.

Use a different troubleshooting path for account restrictions and network issues

If the platform says an account is suspended, a policy violation occurred or a review is required, keep the notice and appeal through official channels. You can provide a normal-use description, the time of the error and any necessary request IDs, but don’t submit keys or full business conversations. NiniVPN can’t remove restrictions imposed by the target platform. Repeatedly changing routes, borrowing someone else’s account or automatically creating new accounts adds risk and won’t provide a clear account of what happened.

For a suspected route issue, change only one variable: keep the device, account and test content the same, and switch to another route that complies with the target service’s policies. Record whether the issue clears, then switch back to confirm it can be reproduced. A one-time recovery is a clue, not proof that the other route will always work. If several routes return the same permissions notice, stop troubleshooting the network. If only one local app fails, return to the app configuration steps.

When contacting support, provide concise, actionable details: tool name, access point, failure stage, redacted message, platform and client mode, and the comparisons you’ve already tried. Hide account details, authorization parameters in browser URLs and API credentials in screenshots. Report network configuration issues through a user panel support ticket. For model billing, eligibility or enforcement matters, contact the target AI platform; the wrong support channel can only lead to more waiting.

After service is restored, don’t leave every temporary troubleshooting setting in place. Undo changes made for diagnosis, such as disabling extensions, enabling verbose logs or using a test proxy. Confirm that your usual tools still work, then document the effective changes. A useful review says which change led to which result—not just “restarted and it worked.” That makes it easier to recognize a recurring issue and prevents temporary debug settings from becoming new risks.

routine / Route selection and maintenance

Route selection and repeatable checks

Prioritize consistency over one-off speed tests

For AI chat, choose a route that meets the target platform’s regional policies first. Then check sign-in stability, first-token delivery, complete long responses, and file and tool features. A single download test can’t represent that experience or guarantee a tool will remain available. Once you’ve chosen a regular route, keep sessions consistent and prepare an alternative that has passed the same checks. Switch only when there’s a clear reason, so routine use doesn’t constantly change the risk context.

NiniVPN offers 120+ countries / 250+ routes, with no device limit. This coverage describes the network options available; it doesn’t mean every region meets every AI product’s policies or that all routes work the same way with a given tool. See the global server locations and route details to compare options for your access point and use case. For more on regions, route types and use cases, read How to Choose VPN Servers, then return here to test the features you need.

Follow a consistent order of checks

First check for known platform incidents and confirm that your account and project permissions are valid. Then check your local network and client status. Test the regular website, sign-in, a short text response, a longer response and the task you actually need to do. If a step fails, stop there and collect evidence instead of adding uploads or automated tasks. Test APIs and editors through their own minimal request paths: a working website doesn’t verify a process’s network connection.

Comparison notes only need the date, tool access point, client mode, route region, successful action and a summary of any error. There’s no need to save full conversations or account details. Note why test conditions changed—for example, a different browser profile, a task running on a remote host or a change in organization permissions. This creates an interpretable record, not a context-free “works” label. It also helps rule out account and usage differences before comparing network performance across devices.

Judge stability by whether real tasks finish, not by whether a webpage opens once. During normal use, observe connection setup, time to first output, continuous streaming and whether the result is saved. Record where any interruption occurs. For self-checks on successful connections and disconnects, read our VPN stability testing guide. These methods help you build your own comparison; they aren’t a third-party review or a set of results published by this site.

Maintain your client, subscription and usage separately

NiniVPN supports Windows / macOS / iOS / Android / Linux. After signing in, download the client for Windows, macOS, Android and Linux from the user panel. The iOS access point depends on an eligible plan shown in the panel. Sign in to retrieve your subscription; don’t use configuration files from unknown sources in public comments or shared posts. After a routine update, check your current settings and app routing before starting a long task. There’s no need to change every device just to keep all versions aligned.

Choose a plan based on the tasks you actually run. Text, attachments, images, voice and developer tools may use different amounts of data, so conversation counts alone aren’t a reliable estimate. NiniVPN monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date; when you upgrade mid-cycle, the price difference is prorated for the remaining days. Data add-ons cost ¥158/300GB, ¥358/1000GB and ¥658/3000GB; they last until used and never expire. See the plans page for a full comparison.

NiniVPN accepts Alipay, WeChat Pay and USDT, and offers a 14-day no-questions-asked refund. Network plans and AI platform billing are separate: having enough network data doesn’t mean you have enough model credits, and AI account permissions don’t mean your client subscription is configured correctly. Check your NiniVPN usage in the user panel and AI usage in the platform console separately. For network access before a short business trip, follow our business travel network checklist and set things up in advance.

Keep a concise recovery checklist: working access points, your usual route, an alternative, where to get the client and how to contact support. Don’t include passwords, keys or full subscription URLs. If something breaks, check the task result first, then work through eligibility, sessions, routing and app settings. Once connectivity is restored, keep following the target platform’s rules and consider the sensitivity of your data before submitting it. Network access is a prerequisite for using AI tools, not the only requirement.