You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Audited: mnfst/manifest PRs #2736 and #2741, the two PRs merged into main since the last run's watermark (#2738), against the docs at commit 34fdf80.
PR #2736 adds a provider named Google Vertex AI to the usage-based provider list. PR #2741 changes one end-to-end test file and nothing a user can see.
No page in the docs mentions the new provider. A search for "vertex" across every .mdx file returns nothing.
Findings
1 · [OBSOLETE] The Supported providers table has no Google Vertex AI row. The dashboard offers that provider with a Connect button
You open Providers → Usage-based in the dashboard.
Under Supported usage-based providers you see a Google Vertex AI card. It sits between Google and Groq, and it has a Connect button.
You come to this page to find out which key that card wants.
The Supported providers table does not list it. No page in the docs names it.
You paste a Google key into the connect panel. The form refuses it and answers Google Vertex AI keys start with "AQ.".
You follow the page's advice and check its prefix table. That table has no row for this provider either.
Options:
Add a row to both tables, and add the provider to the page description and keywords. Recommended.
Add the Supported providers row only. The provider becomes findable, and a refused key still leads nowhere.
Drop both tables and point to the dashboard instead. The upkeep ends, and the page stops working as a comparison.
Suggested wording (option 1), four separate edits:
Insert after the Google row of the Supported providers table:
| Google Vertex AI |[cloud.google.com/vertex-ai](https://cloud.google.com/vertex-ai/generative-ai/docs/start/express-mode/overview)|
Insert after the Google row of the Key prefixes table:
| Google Vertex AI |`AQ.`|`AQ...`|
Replace the description frontmatter line:
description: "Bring your own API key for OpenAI, Anthropic, Google, Google Vertex AI, xAI, DeepSeek, Mistral, Groq, Cerebras, AWS Bedrock, NVIDIA NIM, OpenRouter, Hugging Face, and more."
providers/api-key-providers.mdx:14-37 — the Supported providers table. Last row :37 is | [Hugging Face](https://huggingface.co) | [huggingface.co/settings/tokens](https://huggingface.co/settings/tokens) |. No Google Vertex AI row.
providers/api-key-providers.mdx:83-101 — the Key prefixes table. Its last data row is line 101, and the Meta row at line 88 is the precedent this finding leans on. Both verbatim:
| Meta | `LLM_` | `LLM_...` |
| Hugging Face | `hf_` | `hf_...` |
providers/api-key-providers.mdx:63-65 — step 3 of "Add a provider" ends "If the key is rejected, double-check the prefix below." That is the advice journey step 6 follows.
providers/api-key-providers.mdx:4 and :7 — the description and keywords enumerate providers.
grep -rin "vertex" --include=*.mdx over the whole repo: zero hits.
Code, PR #2736, merge 2c3f412f9, confirmed an ancestor of origin/main: packages/shared/src/providers.ts:106-115 — id vertex, display name Google Vertex AI, requiresApiKey: true, localOnly: false, keyPrefix: 'AQ.', minKeyLength: 40, placeholder AQ....
packages/frontend/src/services/providers.ts:165-169 — API-key only: no supportsSubscription, no subscriptionOnly, no localOnly. :517-519 sorts it between gemini and groq.
packages/frontend/src/pages/providers/ProviderConnectionsPage.tsx:119-123 — the Usage-based list is the registry filtered on !subscriptionOnly && !localOnly, so the card ships on Cloud and self-hosted alike. Section heading Supported usage-based providers at :98, and the Connect button label at :95, rendered at :871 and :923. No env var, no migration, no feature flag: git show --stat 2c3f412f9 is 11 files, +256/-0, and carries none of the three.
packages/frontend/src/services/provider-utils.ts:17-22 and :24-29 — the form enforces the prefix and the length in the browser, before any request. The message renders verbatim as Google Vertex AI keys start with "AQ.", and a short key gets Key is too short (minimum 40 characters).
packages/frontend/src/services/provider-api-key-urls.ts:8 — the in-product "Get Google Vertex AI API key" link, rendered at ProviderKeyForm.tsx:377-387.
Precedent, references/decisions.md:66: Meta was added by platform PR #2702/#2717, the same two rows were missing, the finding was accepted as option 1 and shipped in docs PR docs: connecting a provider happens in the Providers sidebar section (issue #67) #73. The :39 hedge about the dashboard showing the current list was already on the page then.
The prefix row clears the bar set by the reversed verdict at references/decisions.md:47, which rejected rows for prefixes the form does not enforce (AWS Bedrock, NVIDIA NIM, both keyPrefix: ''). This prefix is enforced, as LLM_ is.
Drafting note on the first cell: the provider name is left unlinked, because cloud.google.com/vertex-ai answers a 301 to a page branded "Gemini Enterprise Agent Platform", which works against finding 2. Unlinked name cells already exist at providers/subscription-based-providers.mdx:28 (Xiaomi MiMo) and :30 (Command Code).
Drafting note on the prefix row: it runs 43 characters against the table's 41. | Vertex AI | fits exactly and follows the table's shortening habit (Qwen for Alibaba Cloud, Z.ai for Z.ai (Zhipu)), at the cost of not matching the card label.
A user reading the docs concludes Manifest cannot route to Google Vertex AI.
2 · [MISSING-CASE] The dashboard shows a Google card and a Google Vertex AI card side by side. The docs give no basis for choosing between them
You want to route to Gemini, so you open Providers → Usage-based.
The list shows a Google card and a Google Vertex AI card, one after the other.
You come to the docs to work out which one fits your case.
This page describes a Google row and a Gemini Free tile. The subscriptions page describes a third Google entry.
None of the three tells you what Google Vertex AI serves, or when you would pick it over the plain Google entry.
Options:
Give the provider a short subsection beside Gemini Free, saying what it serves and which key it takes. Recommended.
Put the difference in the table cells. Smallest edit, and the "Where to get a key" column holds a bare link with no room to explain a choice.
Add a note under the table covering all three Google entries at once. Reads well, and it sits away from the row the reader is on.
Suggested wording (option 1), inserted after the Gemini Free paragraph:
### Google Vertex AI
Google Vertex AI serves Gemini models through Google Cloud, and it takes an express mode API key. The connect form refuses a key that does not start with `AQ.`, and it refuses a key shorter than 40 characters. The **Google** entry above takes a Google AI Studio key instead, and Manifest enforces no prefix on that one.
providers/api-key-providers.mdx:41-43 — "Gemini Free is a managed tile. Manifest provisions the credential through its own gateway, so there's no key to fetch from Google first: add the tile and you have a free model to route to."
grep -rin "vertex" --include=*.mdx over the whole repo: zero hits, so no page carries the answer.
Code, PR #2736: packages/frontend/src/services/providers.ts:508-519 — the grid is ordered by display name. After the subscription-only entries are filtered out (ProviderConnectionsPage.tsx:119-123), the rendered run is Gemini Free, Google, Google Vertex AI, Groq.
The two API-key Google entries take incompatible credentials: packages/shared/src/providers.ts:252-253 gives gemini an empty prefix and a 30-character minimum, :113-114 gives vertex the AQ. prefix and a 40-character minimum. packages/frontend/src/services/provider-utils.ts:17-22 refuses the mismatch in the browser.
They point at different places for the key: provider-api-key-urls.ts:13 sends Google to aistudio.google.com/apikey, :8 sends Vertex to the Vertex AI express mode overview.
"Express mode" is the platform's own term for this addressing mode, in prose comments at packages/backend/src/routing/vertex-deployment.ts:10 ("A connection with no region uses express mode, where the API key resolves the project on Google's side") and in the block at packages/backend/src/routing/proxy/provider-endpoints.ts:435-446, which labels the two addressing modes express and project. Google's linked page uses it throughout. Nothing in this codebase describes what a user does at Google's end to obtain such a key, so the draft describes no Google-side procedure.
packages/backend/src/routing/proxy/provider-endpoints.ts:447-458 — requests go to the express base https://aiplatform.googleapis.com/v1beta1 with the key in the x-goog-api-key header. The comment at :444-446 records that the OpenAI-compatible route is deliberately unused because it rejects express calls with RESOURCE_PROJECT_INVALID.
packages/frontend/src/components/ProviderKeyForm.tsx:244-247, 377-387 — the panel has one field, labelled "API Key", plus the key link. The region block is gated on hasEndpointRegions() at :193-194, which is false here, so there is no project, location or region input.
The one product string that would explain the difference never reaches a screen: providers.ts:167 declares the subtitle Gemini via Google Cloud Vertex AI, and ProviderDef.subtitle has a single render site, LocalServerDetailView.tsx:198, which serves local-server providers only.
Relationship to finding 1: separable. Finding 1 makes the provider findable and names its prefix. This finding is the choice a reader still cannot make once both rows exist. Finding 1's option 3 and this finding's option 1 are one edit and close both.
The draft deliberately says nothing about Gemini Free's credential. The registry marks that tile requiresApiKey: true with an sk- prefix (packages/shared/src/providers.ts:257-268) and only the auto-provision path makes it keyless (managedFree: true at :267, packages/frontend/src/services/api/providers.ts:119-126), which references/decisions.md:107 records as an open question for cloud. The page's existing :43 sentence already covers that tile.
Constraints the wording obeys, each code-verified: it names no region, project or location, because the provider declares no apiKeyEndpointRegions (providers.ts:165-169) and the connect API answers a region for it with a 400 (provider.controller.ts:137-154); it promises no model list, because the list comes from the public catalogue rather than from Google (provider-model-fetcher.service.ts:1034-1037, model-discovery.service.ts:280-287); it does not say the key is checked on save, because it is not.
A user with a working Google key is blocked by an error naming a prefix that no page explains.
Open questions
These are questions, not findings. They change how the two findings should be worded, so they are worth an answer before the PR.
Has anyone connected a real AQ. key and routed a Gemini request through it end to end? This run made no upstream call, so nothing here asserts that the provider serves a request. The docs are about to advertise it.
Every other name in the Supported providers table links to a vendor page. cloud.google.com/vertex-ai now redirects to a page branded "Gemini Enterprise Agent Platform", which cuts against finding 2. Leave the name unlinked, or link it anyway?
Also checked this run, nothing owed (for the agent)
The Regional providers line at providers/api-key-providers.mdx:107 correctly stays silent about this provider. It declares no apiKeyEndpointRegions, and the connect API rejects a region for it (provider.controller.ts:137-154).
providers/subscription-based-providers.mdx and providers/local-models.mdx correctly owe it no row: the overlay sets neither supportsSubscription nor localOnly.
Cloud and self-hosted behave identically, so no toggle is owed. The only deployment gate filters localOnly providers (provider-availability.ts:15-17).
Nothing differs between a fresh install and an upgrade, or between existing and new harnesses. The provider list is static frontend code, and the connection fans out to every harness in the workspace exactly as any other provider does (provider.service.ts:441).
No IMAGE finding is raised for images/providers-usage-based.png. Its caption sells the page shape rather than an inventory, and the new card renders as a bare letter tile until its icon ships, so a re-shoot today freezes a state that changes again.
The platform-side observations from this window sit in the harness backlog rather than here, together with the pre-existing docs items this run turned up on the same page.
PR #2741 touches one test file and owes nothing.
node scripts/check-coherence.mjs is GREEN.
Reply with the finding number and the chosen option
(e.g. "3 → option 2", or "3: other idea, let's discuss").
PRs are then made manually with the agent, never by the harness.
Rejected findings: reply "N → reject" and they will never be re-raised.
1 → option 1, 2 → option 1. PR opened. On the open questions: the name cell stays unlinked as the drafting note suggested, and no wording asserts a served request, since no real AQ. key was available to test. If you hold one, a single routed request closes that question.
Audited: mnfst/manifest PRs #2736 and #2741, the two PRs merged into
mainsince the last run's watermark (#2738), against the docs at commit34fdf80.PR #2736 adds a provider named Google Vertex AI to the usage-based provider list. PR #2741 changes one end-to-end test file and nothing a user can see.
No page in the docs mentions the new provider. A search for "vertex" across every
.mdxfile returns nothing.Findings
1 · [OBSOLETE] The Supported providers table has no Google Vertex AI row. The dashboard offers that provider with a Connect button
Page: https://manifest.build/docs/providers/api-key-providers (the Supported providers table, and the Key prefixes table below it)
What actually happens:
Google Vertex AI keys start with "AQ.".Options:
Suggested wording (option 1), four separate edits:
Insert after the
Googlerow of the Supported providers table:Insert after the
Googlerow of the Key prefixes table:Replace the
descriptionfrontmatter line:Replace the
keywordsline:Evidence (for the agent)
providers/api-key-providers.mdx:14-37— the Supported providers table. Last row:37is| [Hugging Face](https://huggingface.co) | [huggingface.co/settings/tokens](https://huggingface.co/settings/tokens) |. No Google Vertex AI row.providers/api-key-providers.mdx:83-101— the Key prefixes table. Its last data row is line 101, and the Meta row at line 88 is the precedent this finding leans on. Both verbatim:providers/api-key-providers.mdx:63-65— step 3 of "Add a provider" ends "If the key is rejected, double-check the prefix below." That is the advice journey step 6 follows.providers/api-key-providers.mdx:4and:7— the description and keywords enumerate providers.grep -rin "vertex" --include=*.mdxover the whole repo: zero hits.Code, PR #2736, merge
2c3f412f9, confirmed an ancestor oforigin/main:packages/shared/src/providers.ts:106-115— idvertex, display nameGoogle Vertex AI,requiresApiKey: true,localOnly: false,keyPrefix: 'AQ.',minKeyLength: 40, placeholderAQ....packages/frontend/src/services/providers.ts:165-169— API-key only: nosupportsSubscription, nosubscriptionOnly, nolocalOnly.:517-519sorts it betweengeminiandgroq.packages/frontend/src/pages/providers/ProviderConnectionsPage.tsx:119-123— the Usage-based list is the registry filtered on!subscriptionOnly && !localOnly, so the card ships on Cloud and self-hosted alike. Section headingSupported usage-based providersat:98, and theConnectbutton label at:95, rendered at:871and:923. No env var, no migration, no feature flag:git show --stat 2c3f412f9is 11 files, +256/-0, and carries none of the three.packages/frontend/src/services/provider-utils.ts:17-22and:24-29— the form enforces the prefix and the length in the browser, before any request. The message renders verbatim asGoogle Vertex AI keys start with "AQ.", and a short key getsKey is too short (minimum 40 characters).packages/frontend/src/services/provider-api-key-urls.ts:8— the in-product "Get Google Vertex AI API key" link, rendered atProviderKeyForm.tsx:377-387.Precedent,
references/decisions.md:66: Meta was added by platform PR #2702/#2717, the same two rows were missing, the finding was accepted as option 1 and shipped in docs PR docs: connecting a provider happens in the Providers sidebar section (issue #67) #73. The:39hedge about the dashboard showing the current list was already on the page then.The prefix row clears the bar set by the reversed verdict at
references/decisions.md:47, which rejected rows for prefixes the form does not enforce (AWS Bedrock, NVIDIA NIM, bothkeyPrefix: ''). This prefix is enforced, asLLM_is.Drafting note on the first cell: the provider name is left unlinked, because
cloud.google.com/vertex-aianswers a 301 to a page branded "Gemini Enterprise Agent Platform", which works against finding 2. Unlinked name cells already exist atproviders/subscription-based-providers.mdx:28(Xiaomi MiMo) and:30(Command Code).Drafting note on the prefix row: it runs 43 characters against the table's 41.
| Vertex AI |fits exactly and follows the table's shortening habit (Qwen for Alibaba Cloud, Z.ai for Z.ai (Zhipu)), at the cost of not matching the card label.A user reading the docs concludes Manifest cannot route to Google Vertex AI.
2 · [MISSING-CASE] The dashboard shows a Google card and a Google Vertex AI card side by side. The docs give no basis for choosing between them
Page: https://manifest.build/docs/providers/api-key-providers (the Supported providers table, and the Gemini Free section under it)
What actually happens:
Options:
Suggested wording (option 1), inserted after the Gemini Free paragraph:
Evidence (for the agent)
providers/api-key-providers.mdx:18—| [Google](https://ai.google.dev) | [ai.google.dev](https://ai.google.dev) |providers/api-key-providers.mdx:41-43— "Gemini Free is a managed tile. Manifest provisions the credential through its own gateway, so there's no key to fetch from Google first: add the tile and you have a free model to route to."providers/subscription-based-providers.mdx:18—| [Google](https://gemini.google.com) | Gemini | OAuth (browser) |grep -rin "vertex" --include=*.mdxover the whole repo: zero hits, so no page carries the answer.packages/frontend/src/services/providers.ts:508-519— the grid is ordered by display name. After the subscription-only entries are filtered out (ProviderConnectionsPage.tsx:119-123), the rendered run is Gemini Free, Google, Google Vertex AI, Groq.packages/shared/src/providers.ts:252-253givesgeminian empty prefix and a 30-character minimum,:113-114givesvertextheAQ.prefix and a 40-character minimum.packages/frontend/src/services/provider-utils.ts:17-22refuses the mismatch in the browser.provider-api-key-urls.ts:13sends Google toaistudio.google.com/apikey,:8sends Vertex to the Vertex AI express mode overview.packages/backend/src/routing/vertex-deployment.ts:10("A connection with no region uses express mode, where the API key resolves the project on Google's side") and in the block atpackages/backend/src/routing/proxy/provider-endpoints.ts:435-446, which labels the two addressing modesexpressandproject. Google's linked page uses it throughout. Nothing in this codebase describes what a user does at Google's end to obtain such a key, so the draft describes no Google-side procedure.packages/backend/src/routing/proxy/provider-endpoints.ts:447-458— requests go to the express basehttps://aiplatform.googleapis.com/v1beta1with the key in thex-goog-api-keyheader. The comment at:444-446records that the OpenAI-compatible route is deliberately unused because it rejects express calls withRESOURCE_PROJECT_INVALID.packages/frontend/src/components/ProviderKeyForm.tsx:244-247, 377-387— the panel has one field, labelled "API Key", plus the key link. The region block is gated onhasEndpointRegions()at:193-194, which is false here, so there is no project, location or region input.providers.ts:167declares the subtitleGemini via Google Cloud Vertex AI, andProviderDef.subtitlehas a single render site,LocalServerDetailView.tsx:198, which serves local-server providers only.requiresApiKey: truewith ansk-prefix (packages/shared/src/providers.ts:257-268) and only the auto-provision path makes it keyless (managedFree: trueat:267,packages/frontend/src/services/api/providers.ts:119-126), whichreferences/decisions.md:107records as an open question for cloud. The page's existing:43sentence already covers that tile.apiKeyEndpointRegions(providers.ts:165-169) and the connect API answers a region for it with a 400 (provider.controller.ts:137-154); it promises no model list, because the list comes from the public catalogue rather than from Google (provider-model-fetcher.service.ts:1034-1037,model-discovery.service.ts:280-287); it does not say the key is checked on save, because it is not.Open questions
These are questions, not findings. They change how the two findings should be worded, so they are worth an answer before the PR.
AQ.key and routed a Gemini request through it end to end? This run made no upstream call, so nothing here asserts that the provider serves a request. The docs are about to advertise it.cloud.google.com/vertex-ainow redirects to a page branded "Gemini Enterprise Agent Platform", which cuts against finding 2. Leave the name unlinked, or link it anyway?Also checked this run, nothing owed (for the agent)
providers/api-key-providers.mdx:107correctly stays silent about this provider. It declares noapiKeyEndpointRegions, and the connect API rejects a region for it (provider.controller.ts:137-154).providers/subscription-based-providers.mdxandproviders/local-models.mdxcorrectly owe it no row: the overlay sets neithersupportsSubscriptionnorlocalOnly.localOnlyproviders (provider-availability.ts:15-17).provider.service.ts:441).images/providers-usage-based.png. Its caption sells the page shape rather than an inventory, and the new card renders as a bare letter tile until its icon ships, so a re-shoot today freezes a state that changes again.node scripts/check-coherence.mjsis GREEN.Reply with the finding number and the chosen option
(e.g. "3 → option 2", or "3: other idea, let's discuss").
PRs are then made manually with the agent, never by the harness.
Rejected findings: reply "N → reject" and they will never be re-raised.