Credentials checklist

Extentos itself needs no provider keys, and everything on this page is free. Discovery, guidance, and validation tools run with no signup; the browser simulator and the generateConnectionModule scaffold step take a free account — the auth flow handles the link the first time it's needed.

AI shows up in an Extentos app two distinct ways, and only one of them needs a key in your code:

• The Phase-4 voice assistant runs on the managed AI gateway — no key in your app, but not free. Gateway usage is metered against a prepaid balance; "no credentials" on this page means no keys to obtain, not no cost. glasses.assistant.start(...) routes through Extentos's gateway on Extentos's provider key; you supply nothing. (There is no option to run it on your own OpenAI account.) No provider key lives in your handler for the assistant path. See the gateway page.
• Handler-code calls to your own AI provider need your key. If your handler calls Anthropic / OpenAI / DeepL / etc. directly (e.g., to run a vision model on a captured photo or summarize a transcript outside the assistant), that key lives in the developer's process. Extentos never sees it. The rest of this page is the checklist for this path.

Plus one non-AI credential set:

• Real Meta Ray-Ban hardware, for camera or display — those capabilities come from com.extentos:glasses-meta and go through Meta's Device Access Toolkit, which requires the developer's own Meta Wearables Developer Center registration. A voice-only app needs none of it, even on real glasses: the microphone and speaker are reached through the phone's own Bluetooth audio routing, with no vendor SDK in the path.

Surface the relevant entries from this page while writing the handler, not at deploy time. If a developer is writing a translation handler, mention DeepL or Google Translate in the same exchange — not three days later when they try to ship.

Quick decision table

The simulator and managed-assistant paths intentionally need zero credentials — that's the point of Extentos's anonymous-first model and the managed gateway. Provider keys come up only for direct handler-code AI calls, and Meta credentials only when the developer leaves the simulator for real hardware.

LLM providers

Only one is required, pick whichever the developer prefers. All have free tiers usable for development.

Anthropic (Claude)

• Portal: console.anthropic.com/settings/keys
• Env var convention: ANTHROPIC_API_KEY
• Free tier: $5 of credit on signup; pay-as-you-go after.
• Best for: Long-context reasoning, tool use, code generation in handlers.

OpenAI

• Portal: platform.openai.com/api-keys
• Env var convention: OPENAI_API_KEY
• Free tier: Limited free credits on signup; pay-as-you-go after. Multi-modal (text + vision + speech) under one key.
• Best for: Vision through GPT-4 Vision, transcription via Whisper, generic chat.

Google Gemini

• Portal: aistudio.google.com/app/apikey
• Env var convention: GEMINI_API_KEY
• Free tier: Generous free quota (1500 requests/day on Flash, lower on Pro). Best free option for prototyping.
• Best for: Cost-sensitive prototyping, multi-modal, fast iteration before committing to a paid provider.

Vision APIs

If your app captures photos and the handler needs to interpret them, pick one:

For most apps, just reuse the LLM provider's key — GPT-4o, Claude, and Gemini all do vision under the same key. Separate vision-only providers only matter when you need their specific capabilities (Google's high-accuracy OCR, Azure's domain models).

Translation

For multilingual apps:

DeepL is generally higher quality for European languages; Google Translate has wider language coverage. HuggingFace Inference works for self-hosted or community models.

OCR

If the handler reads text out of camera frames:

Most LLMs with vision (GPT-4o, Claude, Gemini) can do OCR-style tasks under their existing key — separate OCR services matter for high-volume document workflows.

Premium voice synthesis (production)

Optional. Production apps use phone-native TTS by default (TextToSpeech on Android, AVSpeechSynthesizer on iOS) at zero cost. If the developer wants higher-quality voices:

Premium voice synthesis isn't wired into the shipped Android SDK yet — phone-native TTS is the only built-in path today. When it ships, Extentos won't sit in the runtime path; the library will call the provider directly from the phone.

Meta Wearables Developer Center (real hardware)

Skip this until the developer is ready to test on physical Meta Ray-Ban glasses. The browser simulator and LocalSimTransport don't need any of it.

When real hardware comes into play:

1. Create an app in the Meta Wearables Developer Center.

2. Register a Wearables app under the developer's account.

3. Bind the app to platform-specific identifiers:

   • Android: package name + release signing SHA-256.
   • iOS: Bundle ID + Team ID + a custom URL scheme of the developer's choosing.

4. Retrieve the Meta App ID and Client Token from the Wearables Developer Center (Manage projects).

5. Set your Meta credentials in the AndroidManifest <meta-data> (Android) / Info.plist MWDAT dict (iOS) — the MWDAT SDK reads them from there at init (Wearables.initialize(applicationContext) takes only the context). There is no runtime credential-injection path through ExtentosConfig.

   <application>
       <meta-data android:name="com.meta.wearable.mwdat.APPLICATION_ID"
                  android:value="@string/meta_application_id" />
       <meta-data android:name="com.meta.wearable.mwdat.CLIENT_TOKEN"
                  android:value="@string/meta_client_token" />
   </application>

   <key>MWDAT</key>
   <dict>
       <key>MetaAppID</key><string>$(META_APP_ID)</string>
       <key>ClientToken</key><string>$(META_CLIENT_TOKEN)</string>
       <key>TeamID</key><string>$(DEVELOPMENT_TEAM)</string>
   </dict>

6. Enroll your own Meta account as a tester. Create a version in the Wearables Developer Center, assign it to a release channel, and invite the account that owns the glasses you'll test with — including yours. Until that invite is accepted, registration fails even with correct credentials and a correctly signed build, and it is the one blocker with no distinct log line, so it's diagnosed by elimination. Needs glasses firmware v125+. See release channels and the first-hardware-run ladder.

7. Register the RELEASE signing SHA-256, and install the release variant. Meta binds the entitlement to package name + release signature, so a debug-signed installDebug build never matches and never registers. Your normal debug loop works against the simulator; real glasses need the release variant.

8. Source the values from local.properties → string resource (Android dev) or an .xcconfig substitution into Info.plist (iOS) — never hardcode them in source. The MCP getCredentialGuide tool emits the exact manifest/Info.plist entries and the local.properties-first wiring for the developer's platform.

The MCP getCredentialGuide tool walks through this interactively with the developer when they call it — that's the agent-facing entry point if step-by-step is preferred over this static reference.

Voice in the simulator (no keys needed)

The browser simulator's STT and TTS run on Extentos-managed infrastructure (the voice proxy described in accounts and pricing). Developers don't sign up for Whisper, OpenAI, or any voice provider to use voice in the simulator — that's deliberate, so the first speak/listen experience works out of the box.

Voice in the simulator is unmetered for linked accounts (the browser simulator itself requires sign-in — see pricing) — there's no separate voice quota. On real hardware, voice runs entirely on the phone (zero Extentos cost, zero provider keys).

Where to put keys

Never check provider keys into source control.

• Android: local.properties for dev (read at Gradle config time, deterministic across IDE-launch + daemon-reuse), with System.getenv(...) as the CI/release fallback baked into the same snippet. The getCredentialGuide response embeds the exact Properties().apply { ... } block to paste into app/build.gradle.kts. Keys surface at runtime via context.getString(R.string.<keyname>) (NOT BuildConfig.X — that path inlines stale keys across rotations).
• iOS: .xcconfig files (gitignored) or environment variables on the build runner. Read at runtime via Bundle.main.object(forInfoDictionaryKey:).
• Local dev: for the dev-machine path, local.properties (Android) / Secrets.local.xcconfig (iOS) — both gitignored by default. .env files work for non-build runtime use.

For real production deployments, prefer build-time secret injection over runtime env vars where possible — it keeps the keys out of the running app's process memory.

When to surface this

If you're an AI agent scaffolding an integration for a developer:

• At handler-scaffolding time, look at which BYOK providers the handler will call. Surface the matching rows from the Quick decision table inline so the developer knows what they'll need before they get deep into handler code.
• At code-generation time, call getCredentialGuide(services, platform) and apply the returned build.gradle.kts snippet directly — the canonical local.properties-first pattern is already baked in.
• Before the first real-hardware test, surface the Wearables Developer Center section as a separate setup step — it's a longer process (~15-30 min) and the developer wants to do it once, not interleaved with handler code.

Don't dump the full table on a developer who's still in the simulator; it adds noise. The simulator path is meant to need no keys at all.

Related

• Auth — Extentos account auth, separate from provider keys
• Configuration — env vars and config-file settings
• Production tools — getCredentialGuide, getProductionChecklist
• Pricing — what the free tier covers