@juspay/neurolink 12.49.13 → 12.49.15
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +2 -2
- package/dist/browser/neurolink.min.js +411 -421
- package/dist/cli/factories/commandFactory.d.ts +12 -0
- package/dist/cli/factories/commandFactory.js +11 -1
- package/dist/constants/bedrockIdentifiers.d.ts +16 -0
- package/dist/constants/bedrockIdentifiers.js +79 -0
- package/dist/constants/contextWindows.d.ts +6 -15
- package/dist/constants/contextWindows.js +18 -52
- package/dist/constants/enums.d.ts +12 -0
- package/dist/constants/enums.js +15 -0
- package/dist/constants/tokens.js +9 -0
- package/dist/core/loopEngine.js +8 -0
- package/dist/providers/amazonBedrock/client.js +3 -0
- package/dist/providers/amazonBedrock/inferenceProfile.js +9 -5
- package/dist/providers/catalog/abliteration.json +85 -0
- package/dist/providers/catalog/aihubmix.json +77 -0
- package/dist/providers/catalog/api-route.json +1 -1
- package/dist/providers/catalog/baseten.json +1 -1
- package/dist/providers/catalog/deepseek.json +1 -1
- package/dist/providers/catalog/gmicloud.json +1 -1
- package/dist/providers/catalog/huggingface.json +1 -1
- package/dist/providers/catalog/inception-labs.json +1 -1
- package/dist/providers/catalog/index.generated.d.ts +1 -1
- package/dist/providers/catalog/index.generated.js +9 -0
- package/dist/providers/catalog/io-intelligence.json +1 -1
- package/dist/providers/catalog/loader.js +3 -0
- package/dist/providers/catalog/mancer.json +1 -1
- package/dist/providers/catalog/morph.json +1 -1
- package/dist/providers/catalog/naver-clova-studio.json +68 -0
- package/dist/providers/catalog/novita.json +1 -1
- package/dist/providers/catalog/provider-catalog.schema.json +27 -4
- package/dist/providers/catalog/schema.d.ts +3 -1
- package/dist/providers/catalog/schema.js +15 -2
- package/dist/providers/catalog/upstage.json +1 -1
- package/dist/providers/cohere.js +7 -2
- package/dist/providers/configuredOpenAICompat.js +7 -0
- package/dist/providers/embeddingResponseParsing.d.ts +15 -0
- package/dist/providers/embeddingResponseParsing.js +4 -3
- package/dist/providers/googleAiStudio/client.js +104 -26
- package/dist/rag/chunking/htmlChunker.js +4 -11
- package/dist/rag/document/loaders.js +12 -14
- package/dist/server/openapi/generator.d.ts +0 -6
- package/dist/server/openapi/generator.js +2 -72
- package/dist/types/cli.d.ts +6 -0
- package/dist/types/loopEngine.d.ts +7 -0
- package/dist/types/providerCatalog.d.ts +15 -1
- package/dist/types/providerCatalog.generated.d.ts +2 -2
- package/dist/types/providers.d.ts +15 -0
- package/dist/types/safeFetch.d.ts +1 -1
- package/dist/utils/htmlEntities.d.ts +8 -0
- package/dist/utils/htmlEntities.js +29 -0
- package/dist/utils/safeFetch.js +11 -3
- package/dist/utils/tokenLimits.js +23 -4
- package/docs-site/static/search-index.json +27 -16
- package/package.json +5 -3
|
@@ -1851,21 +1851,19 @@
|
|
|
1851
1851
|
{"objectID":"8d049707778a82eb9081235acee2d720c0c1d3996f8a83a091c203e6ea762854","title":"Test external discovery","url":"/docs/deployment/configuration#test-external-discovery","content":"npx neurolink mcp discover --format table","hierarchy":{"lvl0":"Deployment","lvl1":"⚙️ NeuroLink Configuration Guide","lvl2":"Test external discovery","lvl3":""}},
|
|
1852
1852
|
{"objectID":"a6887a72da883fa1f75c257685181930e70f9c28bd07d42e6e4eff842a8f31f9","title":"Full system test","url":"/docs/deployment/configuration#full-system-test","content":"npm run build && npm run test:run -- test/mcp-comprehensive.test.ts\n`","hierarchy":{"lvl0":"Deployment","lvl1":"⚙️ NeuroLink Configuration Guide","lvl2":"Full system test","lvl3":""}},
|
|
1853
1853
|
{"objectID":"8c4194c033676b414a9cbcb896eb7d8ced6cdd8c282e081d9f65a35935a8d5ae","title":"Development Setup","url":"/docs/deployment/configuration#development-setup","content":"💡 For most users, setting GOOGLE_AI_API_KEY is sufficient to get started with NeuroLink and test all MCP functionality!","hierarchy":{"lvl0":"Deployment","lvl1":"⚙️ NeuroLink Configuration Guide","lvl2":"Development Setup","lvl3":""}},
|
|
1854
|
-
{"objectID":"941610580ad261eef95ac397ab4379c749dbdb2273196044111181d77204dee6","title":"🏢 Enterprise & Proxy Setup Guide","url":"/docs/deployment/enterprise-proxy","content":"🏢 Enterprise & Proxy Setup Guide\n\nNeuroLink
|
|
1855
|
-
{"objectID":"43028d624902e4bac6a20a616166ca1fa966694eab7b659e78c59265e5b70bf3","title":"🏢 Enterprise & Proxy Setup Guide","url":"/docs/deployment/enterprise-proxy#-enterprise-proxy-setup-guide","content":"NeuroLink
|
|
1856
|
-
{"objectID":"
|
|
1854
|
+
{"objectID":"941610580ad261eef95ac397ab4379c749dbdb2273196044111181d77204dee6","title":"🏢 Enterprise & Proxy Setup Guide","url":"/docs/deployment/enterprise-proxy","content":"🏢 Enterprise & Proxy Setup Guide\n\nNeuroLink routes supported HTTP request paths through configured proxies. Native AWS requests, Google authentication and Live WebSockets have separate transport rules described below.\n\n✨ Configure HTTP Proxy Routes\n\nSet the proxy environment variables before creating clients. Request paths that use NeuroLink's proxy-aware HTTP fetch read these settings; they do not establish proxy routing for every SDK or WebSocket transport.\n\nQuick Setup\n\n🔧 Environment Variables\n\nRequired Proxy Variables\n\n| Variable | Description | Example |\n| ------------- | ------------------------------- | ------------------------------- |\n| HTTPS_PROXY | Proxy server for HTTPS requests | http://proxy.company.com:8080 |\n| HTTP_PROXY | Proxy server for HTTP requests | http://proxy.company.com:8080 |\n\nOptional Proxy Variables\n\n| Variable | Description | Default |\n| ---------- | ----------------------- | --------------------- |\n| NO_PROXY | Domains to bypass proxy | localhost,127.0.0.1 |\n\n🌐 Provider-Specific Proxy Support\n\nTransport Coverage and Limits\n\n| Transport | Integration | Coverage limit |\n| ----------------------------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Google AI Studio / Vertex @google/genai model HTTP | SDK HTTP fetch hook | The owned HTTP proxy suite covers AI Studio, Vertex Express and the direct web-search tool; it excludes ADC token requests and Live WebSockets. |\n| Other fetch-backed model requests | Provider-specific proxy-aware fetch | Check the actual provider request path; a configured variable or successful response alone is not routing proof. |\n| Native AWS SDK clients, including Bedrock runtime/control clients | AWS request handler and runtime configuration | Current native Bedrock constructors do not inject NeuroLink's proxy handler. Handler/agent/runtime behavior and bypass semantics need separate route tests. |\n| Gemini Live WebSockets | ws or the GenAI Live SDK transport | Outside the HTTP fetch hook. WebSocket agents and Node runtime settings can affect routing independently. |\n| Vertex ADC token acquisition/refresh | google-auth-library / gaxios | Outside the model fetch hook. The dependency may honor proxy variables independently; its token-refresh and bypass behavior must be checked separately. |\n\nNO_PROXY syntax is documented in the Environment Variables guide. Those shared HTTP matching rules do not automatically apply to the other transports. Missing custom integration does not mean a dependency or runtime can never proxy: observe the route in the environment you use.\n\n🚀 Quick Validation\n\nTest Proxy Configuration\n\nVerify Proxy Usage\n\nWhen proxy is working correctly, you should see:\n✅ The intended inference request appears in the proxy logs; a successful response alone does not prove routing\n✅ Proxy server logs showing intercepted connections\n✅ Proxy/bypass controls confirm the expected direct or proxied route for each transport\n✅ Enterprise MCP tools work alongside proxy\n\nOwned HTTP Routing Tests\n\nAfter building the package, run the current credential-free Google HTTP proxy suite:\n\nIt uses owned forward/direct stand-ins and request counters, with proxy-only response markers and proxy/bypass controls. Its source records the exact covered public paths. It does not certify all providers, native AWS routing, Gemini Live WebSockets or ADC token refresh. Test those transports separately with owned endpoints before relying on them in a constrained network.\n\n🔍 Enterprise Configuration Examples\n\nCorporate Firewall Setup\n\nAuthenticated Proxy\n\nMultiple Environment Setup\n\n🛠️ Technical Implementation\n\nArchitecture Overview\n\nNeuroLink uses the undici ProxyAgent for reliable proxy support:\n\nKey Benefits\n🔄 Automatic Detection - Zero configuration for standard setups\n🏢 Enterprise Ready - Works with corporate authentication\n⚡ High Performance - Optimized undici implementation\n🛡️ Security Compliant - Respects corporate security policies\n\n🔧 Troubleshooting\n\nCommon Issues\n\nProxy Not Working\n\nConnection Timeouts\n\nAuthentication Issues\n\nDebug Mode\n\n🚀 AWS & Cloud Deployment\n\nAWS Corporate Environment\n\nDocker Deployment\n\nKubernetes Configuration\n\n📋 Checklist for Enterprise Deployment\n\nPre-deploy","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"","lvl3":""}},
|
|
1855
|
+
{"objectID":"43028d624902e4bac6a20a616166ca1fa966694eab7b659e78c59265e5b70bf3","title":"🏢 Enterprise & Proxy Setup Guide","url":"/docs/deployment/enterprise-proxy#-enterprise-proxy-setup-guide","content":"NeuroLink routes supported HTTP request paths through configured proxies. Native AWS requests, Google authentication and Live WebSockets have separate transport rules described below.","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"🏢 Enterprise & Proxy Setup Guide","lvl3":""}},
|
|
1856
|
+
{"objectID":"045b2887b689ff5a60a9ec402681dac7c029843ee7c2607975ac6711b400f8fa","title":"✨ Configure HTTP Proxy Routes","url":"/docs/deployment/enterprise-proxy#-configure-http-proxy-routes","content":"Set the proxy environment variables before creating clients. Request paths that use NeuroLink's proxy-aware HTTP fetch read these settings; they do not establish proxy routing for every SDK or WebSocket transport.","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"✨ Configure HTTP Proxy Routes","lvl3":""}},
|
|
1857
1857
|
{"objectID":"42b6a32e42e7b8a8f427fedf294a8e4a5c2b1d78ea959bbdc2b92d54a8ba6b34","title":"Quick Setup","url":"/docs/deployment/enterprise-proxy#quick-setup","content":"`bash","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Quick Setup","lvl3":""}},
|
|
1858
1858
|
{"objectID":"471bedd6986b7daa79fcb994f7e8a0a77474039bcb4aa9bfa888b9a1f43c97b0","title":"NeuroLink will automatically use these settings","url":"/docs/deployment/enterprise-proxy#neurolink-will-automatically-use-these-settings","content":"npx @juspay/neurolink generate \"Hello from behind corporate proxy\"\n`","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"NeuroLink will automatically use these settings","lvl3":""}},
|
|
1859
1859
|
{"objectID":"4711bbfc48705c1a5e70543eea8a53cb87c0fb60ca8126d4b9f865397ad95203","title":"Required Proxy Variables","url":"/docs/deployment/enterprise-proxy#required-proxy-variables","content":"| Variable | Description | Example |\n| ------------- | ------------------------------- | ------------------------------- |\n| HTTPS_PROXY | Proxy server for HTTPS requests | http://proxy.company.com:8080 |\n| HTTP_PROXY | Proxy server for HTTP requests | http://proxy.company.com:8080 |","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Required Proxy Variables","lvl3":""}},
|
|
1860
1860
|
{"objectID":"b81676839c9dd3f6d9e1b28f9da0145833f9843030ded65492f3eeedfd8bf5d4","title":"Optional Proxy Variables","url":"/docs/deployment/enterprise-proxy#optional-proxy-variables","content":"| Variable | Description | Default |\n| ---------- | ----------------------- | --------------------- |\n| NO_PROXY | Domains to bypass proxy | localhost,127.0.0.1 |","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Optional Proxy Variables","lvl3":""}},
|
|
1861
|
-
{"objectID":"
|
|
1861
|
+
{"objectID":"497dcba2174216e845c677240c77cbf228f3b12c37aec0537d152ba937ab4875","title":"Transport Coverage and Limits","url":"/docs/deployment/enterprise-proxy#transport-coverage-and-limits","content":"| Transport | Integration | Coverage limit |\n| ----------------------------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Google AI Studio / Vertex @google/genai model HTTP | SDK HTTP fetch hook | The owned HTTP proxy suite covers AI Studio, Vertex Express and the direct web-search tool; it excludes ADC token requests and Live WebSockets. |\n| Other fetch-backed model requests | Provider-specific proxy-aware fetch | Check the actual provider request path; a configured variable or successful response alone is not routing proof. |\n| Native AWS SDK clients, including Bedrock runtime/control clients | AWS request handler and runtime configuration | Current native Bedrock constructors do not inject NeuroLink's proxy handler. Handler/agent/runtime behavior and bypass semantics need separate route tests. |\n| Gemini Live WebSockets | ws or the GenAI Live SDK transport | Outside the HTTP fetch hook. WebSocket agents and Node runtime settings can affect routing independently. |\n| Vertex ADC token acquisition/refresh | google-auth-library / gaxios | Outside the model fetch hook. The dependency may honor proxy variables independently; its token-refresh and bypass behavior must be checked separately. |\n\nNO_PROXY syntax is documented in the Environment Variables guide.","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Transport Coverage and Limits","lvl3":""}},
|
|
1862
1862
|
{"objectID":"c93810e1dbaea09a4a375a8b4743948cc0c7fe2328177e98b518a32a35ef22d9","title":"Test Proxy Configuration","url":"/docs/deployment/enterprise-proxy#test-proxy-configuration","content":"`bash","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Test Proxy Configuration","lvl3":""}},
|
|
1863
1863
|
{"objectID":"38622483c4745532e5286430c5bc9aadb5c93116d38490e86fa79c50ce885ee5","title":"2. Test with any provider","url":"/docs/deployment/enterprise-proxy#2-test-with-any-provider","content":"npx @juspay/neurolink generate \"Test proxy connection\" --provider google-ai","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"2. Test with any provider","lvl3":""}},
|
|
1864
1864
|
{"objectID":"0ec443215cce8d89417442ff2713b18af330f2140eed9474232c909666b2e1b7","title":"3. Check proxy logs for connection intercepts","url":"/docs/deployment/enterprise-proxy#3-check-proxy-logs-for-connection-intercepts","content":"`","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"3. Check proxy logs for connection intercepts","lvl3":""}},
|
|
1865
|
-
{"objectID":"16976d27e64bfdac1383c61cd5b36d02c01ab9be1d362e8a23b57fc8afc4f19f","title":"Verify Proxy Usage","url":"/docs/deployment/enterprise-proxy#verify-proxy-usage","content":"When proxy is working correctly, you should see:\n✅
|
|
1866
|
-
{"objectID":"
|
|
1867
|
-
{"objectID":"fa800096280ec81c99dd8ed9ddbd0b05fbff07608e9d35c91c06691ecf909417","title":"Run enterprise proxy tests","url":"/docs/deployment/enterprise-proxy#run-enterprise-proxy-tests","content":"npm test -- test/proxy/proxySupport.test.ts","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Run enterprise proxy tests","lvl3":""}},
|
|
1868
|
-
{"objectID":"f57c2d0822e87ad1d426b31f263185277e8c727b2316cb21fb4474fcffd981ed","title":"Test all providers with proxy + MCP","url":"/docs/deployment/enterprise-proxy#test-all-providers-with-proxy-mcp","content":"npm test -- test/proxy/proxySupport.test.ts --run\n`\n\nTest Coverage:\n✅ Proxy usage validation (negative/positive testing)\n✅ All enterprise providers (Anthropic, OpenAI, Vertex, Mistral, Ollama)\n✅ MCP + Proxy compatibility (enterprise grade)\n✅ Real-world timeout handling\n✅ SDK and CLI interface testing","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Test all providers with proxy + MCP","lvl3":""}},
|
|
1865
|
+
{"objectID":"16976d27e64bfdac1383c61cd5b36d02c01ab9be1d362e8a23b57fc8afc4f19f","title":"Verify Proxy Usage","url":"/docs/deployment/enterprise-proxy#verify-proxy-usage","content":"When proxy is working correctly, you should see:\n✅ The intended inference request appears in the proxy logs; a successful response alone does not prove routing\n✅ Proxy server logs showing intercepted connections\n✅ Proxy/bypass controls confirm the expected direct or proxied route for each transport\n✅ Enterprise MCP tools work alongside proxy","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Verify Proxy Usage","lvl3":""}},
|
|
1866
|
+
{"objectID":"0558a41556980b7401c9369c35d7b4f5985fea7af25a1757c09beae801ca777c","title":"Owned HTTP Routing Tests","url":"/docs/deployment/enterprise-proxy#owned-http-routing-tests","content":"After building the package, run the current credential-free Google HTTP proxy suite:\n\nIt uses owned forward/direct stand-ins and request counters, with proxy-only response markers and proxy/bypass controls. Its source records the exact covered public paths. It does not certify all providers, native AWS routing, Gemini Live WebSockets or ADC token refresh. Test those transports separately with owned endpoints before relying on them in a constrained network.","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Owned HTTP Routing Tests","lvl3":""}},
|
|
1869
1867
|
{"objectID":"9115d64058a02922c1dffe2f8f0b2563bad4f2f2c46b72fa9bc302367b7c9b7f","title":"Corporate Firewall Setup","url":"/docs/deployment/enterprise-proxy#corporate-firewall-setup","content":"`bash","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Corporate Firewall Setup","lvl3":""}},
|
|
1870
1868
|
{"objectID":"8238f05eee3a5d53ce19b28fb7bae228b1d498259f8609f9180553e4c6c33c17","title":"Standard corporate proxy","url":"/docs/deployment/enterprise-proxy#standard-corporate-proxy","content":"`","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Standard corporate proxy","lvl3":""}},
|
|
1871
1869
|
{"objectID":"971f7d6cff5aef8c3235180d7c855d5de3f82139d14d820cc7f80b148525f874","title":"Authenticated Proxy","url":"/docs/deployment/enterprise-proxy#authenticated-proxy","content":"`bash","hierarchy":{"lvl0":"Deployment","lvl1":"🏢 Enterprise & Proxy Setup Guide","lvl2":"Authenticated Proxy","lvl3":""}},
|
|
@@ -3387,21 +3385,22 @@
|
|
|
3387
3385
|
{"objectID":"f6543a204326fbf7f27ac5c61c2f10b76f0541f3acb61eec93291921404e1a37","title":"What it is bad at","url":"/docs/features/decide-inference-type#what-it-is-bad-at","content":"\"Cannot hallucinate\" is a claim about output shape, not answer\ncorrectness: a decision model cannot return malformed JSON or an option you\ndid not offer, but it can still be wrong. TypeSafe reports ~68% accuracy on its\nown 711-case benchmark, against ~73% for a frontier model. It wins cost and\nlatency on every row and loses accuracy on every row — so it is right for\ndecisions that are gated and reversible, and wrong for final answers.\nIt reads literally. It answers the question you wrote, not the one you\n meant. Split an ambiguous question into two and combine them in code.\nAsk about the act, not the subject. \"This task touches money\" scores high\n on ordinary code that merely concerns money. The risk question in\n classifyJev is worded to exclude writing and testing such code, precisely\n because the naive phrasing escalated everything.\nIt is not a calculator. Counting, arithmetic and date comparison are\n unreliable — dates are read as text, not ordered quantities. A score is for\n thresholding and ranking, not for reading an exact magnitude off.\nIrrelevant state costs accuracy. Filter before sending.\nIt never explains itself. No rationale field exists, which rules it out\n where a decision must be auditable.\nOption order can matter. Test with reordered criteria if a call is close.\nDon't invert criteria. A boolean whose true description means \"no\"\n performs measurably worse.\n\nTune thresholds on your own labelled data if the decision matters, and once you\nhave, pin TYPESAFE_MODEL to a version id such as jev-1.13.0 — jev-latest\nis an alias and can move under you, invalidating a tuned threshold silently.","hierarchy":{"lvl0":"Features","lvl1":"The `decide` inference type","lvl2":"What it is bad at","lvl3":""}},
|
|
3388
3386
|
{"objectID":"f51228c123e6f86e1889f9990b2592debd24cc90c1584ad7d35d1f9a7aac8b82","title":"Adding another decision provider","url":"/docs/features/decide-inference-type#adding-another-decision-provider","content":"The decide inference type is provider-neutral by construction. Another\ndecision model needs:\nAn AIProviderName member and a <Name>Models enum\n (src/lib/constants/enums.ts, outside the generated regions).\nA provider class extending SystemOneDecisionProvider\n (src/lib/providers/systemOneDecision.ts), which owns the request loop,\n retries, the auth circuit breaker and answer parsing, and supplies the\n throwing getAISDKModel() / executeStream() stubs, the same shape the\n embedding-only providers (voyage.ts, jina.ts) use. The class supplies\n its endpoint, headers, body, error parsing and messages.\nA descriptor with inferenceKinds: [\"decide\"], no auto-select ranks, and\n healthCheck: \"env-only\". That one field is what keeps a text-less model out\n of every generation fallback chain; nothing else needs to know the provider\n by name. A provider that reads images or video also declares\n decisionLimits.media; without it, a request that carries media is refused\n before any network call.\nA registration block, a credentials slice, a manifest, and the usual Tier-3\n onboarding artifacts — pnpm run verify:provider-onboarding enumerates them.\n\nThe Tier-2 catalog JSON path cannot be used: its schema pins tier: 2, accepts\nonly an 8-flag text-generation capability vocabulary, and requires\ndefaultMaxOutputTokens and pricingPerMTok.output — none of which a model\nthat emits no text can honestly supply.","hierarchy":{"lvl0":"Features","lvl1":"The `decide` inference type","lvl2":"Adding another decision provider","lvl3":""}},
|
|
3389
3387
|
{"objectID":"31d00aee561a454dc5082ad8002f9dbc0e33f15463cfee1636497043c8f9ee55","title":"Testing","url":"/docs/features/decide-inference-type#testing","content":"The suite drives dist/index.js only. Live tests skip without\nTYPESAFE_API_KEY; the degradation and discriminator tests run unconditionally,\nbecause \"behaves correctly with no key\" and \"a text-less provider is unreachable\nfrom generation\" are the contracts that matter most.","hierarchy":{"lvl0":"Features","lvl1":"The `decide` inference type","lvl2":"Testing","lvl3":""}},
|
|
3390
|
-
{"objectID":"d0993177d0de353bf96138199dbc9fad84b1bdff72bb534dc7c6a510266e3be9","title":"Embeddings","url":"/docs/features/embeddings","content":"Embeddings\n\nStatus: Stable | Availability: SDK + CLI + Server\n\nOverview\n\nEmbeddings convert text into dense numerical vectors that capture semantic meaning. Two texts with similar meanings produce vectors that are close together in the embedding space, enabling use cases like:\nSemantic search -- find documents by meaning rather than exact keyword match\nRAG pipelines -- retrieve relevant context before generating answers\nSimilarity comparison -- measure how related two pieces of text are\nClustering and classification -- group or categorize text automatically\n\nNeuroLink exposes embeddings through two provider methods (embed() and embedMany()), two server endpoints, and indirectly through the CLI's RAG commands. Every implementation calls its provider's embeddings API directly.\n\nQuick Start\n\nProvider Support\n\
|
|
3388
|
+
{"objectID":"d0993177d0de353bf96138199dbc9fad84b1bdff72bb534dc7c6a510266e3be9","title":"Embeddings","url":"/docs/features/embeddings","content":"Embeddings\n\nStatus: Stable | Availability: SDK + CLI + Server\n\nOverview\n\nEmbeddings convert text into dense numerical vectors that capture semantic meaning. Two texts with similar meanings produce vectors that are close together in the embedding space, enabling use cases like:\nSemantic search -- find documents by meaning rather than exact keyword match\nRAG pipelines -- retrieve relevant context before generating answers\nSimilarity comparison -- measure how related two pieces of text are\nClustering and classification -- group or categorize text automatically\n\nNeuroLink exposes embeddings through two provider methods (embed() and embedMany()), two server endpoints, and indirectly through the CLI's RAG commands. Every implementation calls its provider's embeddings API directly.\n\nQuick Start\n\nProvider Support\n\nNine providers implement embedding support: OpenAI, Google AI Studio, Google Vertex, Amazon Bedrock, Cohere, Voyage, Jina, Ollama, and LiteLLM. Ollama requires a locally available embedding model; LiteLLM requires an embedding deployment on its gateway. Other providers throw a descriptive error when embed() or embedMany() is called (see Unsupported Providers below).\n\n| Provider | Default Model | Env Override | Dimensions |\n| ---------------- | ------------------------------ | --------------------------- | -------------------- |\n| OpenAI | text-embedding-3-small | OPENAI_EMBEDDING_MODEL | 1536 |\n| Google AI Studio | gemini-embedding-001 | GOOGLE_AI_EMBEDDING_MODEL | 3072 |\n| Google Vertex | text-embedding-004 | VERTEX_EMBEDDING_MODEL | 768 |\n| Amazon Bedrock | amazon.titan-embed-text-v2:0 | BEDROCK_EMBEDDING_MODEL | 1024 |\n| Cohere | embed-english-v3.0 | modelName argument | Model dependent |\n| Voyage | voyage-3.5 | VOYAGE_MODEL | Model dependent |\n| Jina | jina-embeddings-v3 | JINA_MODEL | Model dependent |\n| Ollama | nomic-embed-text | OLLAMA_EMBEDDING_MODEL | Model dependent |\n| LiteLLM | gemini-embedding-001 | LITELLM_EMBEDDING_MODEL | Deployment dependent |\n\nGoogle AI Studio and Google Vertex also accept GOOGLE_EMBEDDING_MODEL as a shared fallback environment variable.\n\nAmazon Bedrock also accepts AWS_EMBEDDING_MODEL as an alternative environment variable.\n\nSDK API\n\nprovider.embed(text, modelName?)\n\nGenerate an embedding vector for a single text string.\n\nParameters:\n\n| Name | Type | Required | Description |\n| ----------- | -------- | -------- | ------------------------------------------------------ |\n| text | string | Yes | The text to embed |\n| modelName | string | No | Override the default embedding model for this provider |\n\nReturns: Promise<number[]> -- the embedding vector.\n\nprovider.embedMany(texts, modelName?)\n\nGenerate embedding vectors for multiple texts in a single batch. Each provider implementation handles its own batching, so a model that imposes a batch-size limit is chunked to fit it. Amazon Bedrock processes each text individually via Promise.all because the Titan Embed API accepts one input at a time.\n\nParameters:\n\n| Name | Type | Required | Description |\n| ----------- | ---------- | -------- | ------------------------------------------------------ |\n| texts | string[] | Yes | The texts to embed |\n| modelName | string | No | Override the default embedding model for this provider |\n\nReturns: Promise<number[][]> -- one embedding vector per input text.\n\nResponse validation\n\nCohere, Voyage, and Jina reject responses containing empty vectors or values\nthat are not finite numbers. This changes malformed responses that previously\nreturned an empty or unusable vector into rejected promises. Valid vectors,\nincluding zero and negative values, retain their original values.\n\nEach batch must return one vector per input. Voyage and Jina additionally\nrequire complete index coverage and restore the input order when the response\narrives out of order. Cohere's float envelope and legacy flat vector envelope\nare both supported. Cohere splits inputs at 96 texts and Voyage at 128; a\nmalformed later batch rejects the entire operation instead of returning partial\nresults. Passing an empty input array to these three providers returns []\nwithout a request.\n\nValidation errors retain the providers' existing error types: ProviderError\nfor Cohere and Voyage, and Error for Jina. These checks validate the response\nboundary; they do not establish a vendor model's availability.\n\nServer API\n\nThe NeuroLink server exposes two embedding endpoints under the /api/agent route group. Both ","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"","lvl3":""}},
|
|
3391
3389
|
{"objectID":"6ae9d6740816218e18c4b0d2e1948caa934bc3a0fc89b507442c1f9a3fdb0e7b","title":"Embeddings","url":"/docs/features/embeddings#embeddings","content":"Status: Stable | Availability: SDK + CLI + Server","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Embeddings","lvl3":""}},
|
|
3392
3390
|
{"objectID":"cff0586eac67f9163de67f4a900967e84175f0f17e6d9059d9fad052f0fda478","title":"Overview","url":"/docs/features/embeddings#overview","content":"Embeddings convert text into dense numerical vectors that capture semantic meaning. Two texts with similar meanings produce vectors that are close together in the embedding space, enabling use cases like:\nSemantic search -- find documents by meaning rather than exact keyword match\nRAG pipelines -- retrieve relevant context before generating answers\nSimilarity comparison -- measure how related two pieces of text are\nClustering and classification -- group or categorize text automatically\n\nNeuroLink exposes embeddings through two provider methods (embed() and embedMany()), two server endpoints, and indirectly through the CLI's RAG commands. Every implementation calls its provider's embeddings API directly.","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Overview","lvl3":""}},
|
|
3393
|
-
{"objectID":"8034cac5fb47720918a94b549fc9572fb2e74393bee9e02c18ee18e311133af9","title":"Provider Support","url":"/docs/features/embeddings#provider-support","content":"
|
|
3391
|
+
{"objectID":"8034cac5fb47720918a94b549fc9572fb2e74393bee9e02c18ee18e311133af9","title":"Provider Support","url":"/docs/features/embeddings#provider-support","content":"Nine providers implement embedding support: OpenAI, Google AI Studio, Google Vertex, Amazon Bedrock, Cohere, Voyage, Jina, Ollama, and LiteLLM. Ollama requires a locally available embedding model; LiteLLM requires an embedding deployment on its gateway. Other providers throw a descriptive error when embed() or embedMany() is called (see Unsupported Providers below).\n\n| Provider | Default Model | Env Override | Dimensions |\n| ---------------- | ------------------------------ | --------------------------- | -------------------- |\n| OpenAI | text-embedding-3-small | OPENAI_EMBEDDING_MODEL | 1536 |\n| Google AI Studio | gemini-embedding-001 | GOOGLE_AI_EMBEDDING_MODEL | 3072 |\n| Google Vertex | text-embedding-004 | VERTEX_EMBEDDING_MODEL | 768 |\n| Amazon Bedrock | amazon.titan-embed-text-v2:0 | BEDROCK_EMBEDDING_MODEL | 1024 |\n| Cohere | embed-english-v3.0 | modelName argument | Model dependent |\n| Voyage | voyage-3.5 | VOYAGE_MODEL | Model dependent |\n| Jina | jina-embeddings-v3 | JINA_MODEL | Model dependent |\n| Ollama | nomic-embed-text | OLLAMA_EMBEDDING_MODEL | Model dependent |\n| LiteLLM | gemini-embedding-001 | LITELLM_EMBEDDING_MODEL | Deployment dependent |\n\nGoogle AI Studio and Google Vertex also accept GOOGLE_EMBEDDING_MODEL as a shared fallback environment variable.\n\nAmazon Bedrock also accepts AWS_EMBEDDING_MODEL as an alternative environment variable.","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Provider Support","lvl3":""}},
|
|
3394
3392
|
{"objectID":"a72376f0e4119e934a432b80778c842f8501feec3f1d975e2c86c48479f505df","title":"provider.embed(text, modelName?)","url":"/docs/features/embeddings#providerembedtext-modelname","content":"Generate an embedding vector for a single text string.\n\nParameters:\n\n| Name | Type | Required | Description |\n| ----------- | -------- | -------- | ------------------------------------------------------ |\n| text | string | Yes | The text to embed |\n| modelName | string | No | Override the default embedding model for this provider |\n\nReturns: Promise<number[]> -- the embedding vector.","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"provider.embed(text, modelName?)","lvl3":""}},
|
|
3395
3393
|
{"objectID":"7539c8bb5f45d08280c088d0acbe4a8753371e4e24ca8529bc0be8e4ef3ed808","title":"provider.embedMany(texts, modelName?)","url":"/docs/features/embeddings#providerembedmanytexts-modelname","content":"Generate embedding vectors for multiple texts in a single batch. Each provider implementation handles its own batching, so a model that imposes a batch-size limit is chunked to fit it. Amazon Bedrock processes each text individually via Promise.all because the Titan Embed API accepts one input at a time.\n\nParameters:\n\n| Name | Type | Required | Description |\n| ----------- | ---------- | -------- | ------------------------------------------------------ |\n| texts | string[] | Yes | The texts to embed |\n| modelName | string | No | Override the default embedding model for this provider |\n\nReturns: Promise<number[][]> -- one embedding vector per input text.","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"provider.embedMany(texts, modelName?)","lvl3":""}},
|
|
3394
|
+
{"objectID":"2905e473e3d55c247cf16195a8740bf010ed091acb5013b1c7459c39abd773da","title":"Response validation","url":"/docs/features/embeddings#response-validation","content":"Cohere, Voyage, and Jina reject responses containing empty vectors or values\nthat are not finite numbers. This changes malformed responses that previously\nreturned an empty or unusable vector into rejected promises. Valid vectors,\nincluding zero and negative values, retain their original values.\n\nEach batch must return one vector per input. Voyage and Jina additionally\nrequire complete index coverage and restore the input order when the response\narrives out of order. Cohere's float envelope and legacy flat vector envelope\nare both supported. Cohere splits inputs at 96 texts and Voyage at 128; a\nmalformed later batch rejects the entire operation instead of returning partial\nresults. Passing an empty input array to these three providers returns []\nwithout a request.\n\nValidation errors retain the providers' existing error types: ProviderError\nfor Cohere and Voyage, and Error for Jina. These checks validate the response\nboundary; they do not establish a vendor model's availability.","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Response validation","lvl3":""}},
|
|
3396
3395
|
{"objectID":"45eece09886cce1f198f25bbd10d3a3297e92b15634038c62bcd5ca9820402d2","title":"Server API","url":"/docs/features/embeddings#server-api","content":"The NeuroLink server exposes two embedding endpoints under the /api/agent route group. Both default to the openai provider when provider is omitted.","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Server API","lvl3":""}},
|
|
3397
3396
|
{"objectID":"04fba76f1176cf0fb867af0b40f3e7937737f15e741c2c635e07c69973b2bfc9","title":"POST /api/agent/embed","url":"/docs/features/embeddings#post-apiagentembed","content":"Generate an embedding for a single text.\n\nRequest body:\n\n| Field | Type | Required | Description |\n| ---------- | -------- | -------- | ------------------------------------------------ |\n| text | string | Yes | Non-empty text to embed |\n| provider | string | No | Provider name (default: \"openai\") |\n| model | string | No | Embedding model name (default: provider default) |\n\nResponse (200):","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"POST /api/agent/embed","lvl3":""}},
|
|
3398
3397
|
{"objectID":"8c53b698bebebe55f5f9c91965f787eeb45aa150aaac2d1935e6c32e269278a0","title":"POST /api/agent/embed-many","url":"/docs/features/embeddings#post-apiagentembed-many","content":"Generate embeddings for multiple texts in one request.\n\nRequest body:\n\n| Field | Type | Required | Description |\n| ---------- | ---------- | -------- | ------------------------------------------------ |\n| texts | string[] | Yes | 1 to 2048 non-empty strings |\n| provider | string | No | Provider name (default: \"openai\") |\n| model | string | No | Embedding model name (default: provider default) |\n\nResponse (200):\n\nError response (validation failure):\n\nError response (provider failure):","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"POST /api/agent/embed-many","lvl3":""}},
|
|
3399
|
-
{"objectID":"698b0d0dcfa0d1b2e11f7490fe846c9a367e076b995ac58ab618e1205560891d","title":"Unsupported Providers","url":"/docs/features/embeddings#unsupported-providers","content":"Calling embed() or embedMany() on a provider that does not implement embeddings throws an Error with a message listing the supported providers and example models:\n\nProviders that currently do not support embeddings include: Anthropic, Mistral,
|
|
3398
|
+
{"objectID":"698b0d0dcfa0d1b2e11f7490fe846c9a367e076b995ac58ab618e1205560891d","title":"Unsupported Providers","url":"/docs/features/embeddings#unsupported-providers","content":"Calling embed() or embedMany() on a provider that does not implement embeddings throws an Error with a message listing the supported providers and example models:\n\nProviders that currently do not support embeddings include: Anthropic, Mistral, Hugging Face, Azure OpenAI, and SageMaker. To generate embeddings when using one of these providers for text generation, create a second provider instance from a supported embedding provider:","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Unsupported Providers","lvl3":""}},
|
|
3400
3399
|
{"objectID":"ebb13f113d90f2920feaa9408b5612089c92444eb1a2f8f7304446455aa4fc6b","title":"CLI Usage","url":"/docs/features/embeddings#cli-usage","content":"There is no standalone neurolink embed CLI command. Embeddings are used indirectly through the RAG CLI commands, which handle embedding generation automatically during document indexing and querying:\n\n`bash","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"CLI Usage","lvl3":""}},
|
|
3401
3400
|
{"objectID":"ea89e76395226d65d49ad3776776a9fea73b9effad21bd90d76345eb892c1180","title":"Index documents (generates embeddings internally)","url":"/docs/features/embeddings#index-documents-generates-embeddings-internally","content":"neurolink rag index ./docs/guide.md --indexName my-docs --provider vertex","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Index documents (generates embeddings internally)","lvl3":""}},
|
|
3402
3401
|
{"objectID":"7cba5e0aeb6768d316570599da6b6a5dd9f25916a52f30cf7deca8d024288a18","title":"Query with automatic embedding of the query string","url":"/docs/features/embeddings#query-with-automatic-embedding-of-the-query-string","content":"neurolink rag query \"What are the main features?\" --indexName my-docs --provider vertex\nbash\nneurolink rag index ./docs/guide.md \\\n --indexName my-docs \\\n --provider openai \\\n --model text-embedding-3-large\n\n\nThe embedding model resolution order for RAG commands is:\n\n1. --model flag (if the value matches an embedding model pattern)\n2. NEUROLINKEMBEDDINGMODEL environment variable\n3. Provider-specific environment variable (e.g., VERTEXEMBEDDINGMODEL)\n4. Provider's default embedding model\n5. Fallback to OpenAI text-embedding-3-small`","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Query with automatic embedding of the query string","lvl3":""}},
|
|
3403
3402
|
{"objectID":"58e999ea174801e6988e47fa5ebd54b7677724393e5c8a55ead6ca70370c60ff","title":"Integration with RAG","url":"/docs/features/embeddings#integration-with-rag","content":"Embeddings are a foundational building block for RAG pipelines. NeuroLink's simplified RAG API (rag: { files }) handles embedding generation internally, so you do not need to call embed() directly:\n\nFor full control over the embedding and retrieval steps, use createVectorQueryTool with explicit embed() calls:\n\nFor more details on RAG pipelines, see the RAG Document Processing Guide.","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Integration with RAG","lvl3":""}},
|
|
3404
|
-
{"objectID":"0de66cb24e860808d3967922706cb8f4c543cf24b9aa150e96a8b7d48788793f","title":"Environment Variables","url":"/docs/features/embeddings#environment-variables","content":"| Variable | Provider(s) | Description |\n| --------------------------- | ------------------------------- | ----------------------------------------------------------------------- |\n| OPENAI_EMBEDDING_MODEL | OpenAI | Override OpenAI default embedding model |\n| GOOGLE_AI_EMBEDDING_MODEL | Google AI Studio | Override AI Studio default embedding model |\n| VERTEX_EMBEDDING_MODEL | Google Vertex | Override Vertex default embedding model (default: text-embedding-004) |\n| GOOGLE_EMBEDDING_MODEL | Google AI Studio, Google Vertex | Shared fallback for Google providers |\n| BEDROCK_EMBEDDING_MODEL | Amazon Bedrock | Override Bedrock default embedding model |\n| AWS_EMBEDDING_MODEL | Amazon Bedrock | Alternative Bedrock env var |\n| NEUROLINK_EMBEDDING_MODEL | All (CLI RAG only) | Global override for RAG CLI commands |","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Environment Variables","lvl3":""}},
|
|
3403
|
+
{"objectID":"0de66cb24e860808d3967922706cb8f4c543cf24b9aa150e96a8b7d48788793f","title":"Environment Variables","url":"/docs/features/embeddings#environment-variables","content":"| Variable | Provider(s) | Description |\n| --------------------------- | ------------------------------- | ----------------------------------------------------------------------- |\n| OPENAI_EMBEDDING_MODEL | OpenAI | Override OpenAI default embedding model |\n| GOOGLE_AI_EMBEDDING_MODEL | Google AI Studio | Override AI Studio default embedding model |\n| VERTEX_EMBEDDING_MODEL | Google Vertex | Override Vertex default embedding model (default: text-embedding-004) |\n| GOOGLE_EMBEDDING_MODEL | Google AI Studio, Google Vertex | Shared fallback for Google providers |\n| BEDROCK_EMBEDDING_MODEL | Amazon Bedrock | Override Bedrock default embedding model |\n| AWS_EMBEDDING_MODEL | Amazon Bedrock | Alternative Bedrock env var |\n| VOYAGE_MODEL | Voyage | Override the provider's default embedding model |\n| JINA_MODEL | Jina | Override the provider's default embedding model |\n| OLLAMA_EMBEDDING_MODEL | Ollama | Locally available embedding model |\n| LITELLM_EMBEDDING_MODEL | LiteLLM | Embedding model or deployment served by the gateway |\n| NEUROLINK_EMBEDDING_MODEL | All (CLI RAG only) | Global override for RAG CLI commands |","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Environment Variables","lvl3":""}},
|
|
3405
3404
|
{"objectID":"2aeebbce7d7d32d83443815b6e956d40b7482158a0ad88582503606c264d8f69","title":"Key Files","url":"/docs/features/embeddings#key-files","content":"| File | Purpose |\n| -------------------------------------- | ------------------------------------------------------------------------------ |\n| src/lib/core/baseProvider.ts | Default embed() / embedMany() stubs |\n| src/lib/providers/openAI.ts | OpenAI embedding implementation |\n| src/lib/providers/googleAiStudio.ts | Google AI Studio embedding implementation |\n| src/lib/providers/googleVertex.ts | Google Vertex embedding implementation |\n| src/lib/providers/amazonBedrock.ts | Amazon Bedrock embedding implementation |\n| src/lib/server/routes/agentRoutes.ts | Server /embed and /embed-many routes |\n| src/lib/server/utils/validation.ts | EmbedRequestSchema, EmbedManyRequestSchema |\n| src/lib/server/types.ts | EmbedRequest, EmbedResponse, EmbedManyRequest, EmbedManyResponse types |\n| src/lib/types/providers.ts | AIProvider type with embedding methods |","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"Key Files","lvl3":""}},
|
|
3406
3405
|
{"objectID":"7dc8cee91fc8da6885116ce742319dbaced7f61b1a073493131e7bcf566e43e7","title":"See Also","url":"/docs/features/embeddings#see-also","content":"RAG Document Processing Guide -- end-to-end RAG pipelines using embeddings\nSDK API Reference -- SDK API reference","hierarchy":{"lvl0":"Features","lvl1":"Embeddings","lvl2":"See Also","lvl3":""}},
|
|
3407
3406
|
{"objectID":"d4f8720f9bb7fb3901fbd2263aabda49347af9cc64470e2596d0e244f6e21b71","title":"Enterprise Human-in-the-Loop System","url":"/docs/features/enterprise-hitl","content":"Enterprise Human-in-the-Loop System\n\nSince: v7.39.0 | Availability: SDK & CLI\n\nTreat every code sample below as the target API unless it appears in\n\"Currently available\" immediately after this box. The (Planned) markers on\nthree headings are not a complete index — most of the code samples on this\npage, spread across most of its headings, use configuration keys that\nHITLConfig does not have, and only a small minority of those actually sit\nunder a marked heading.\n\nNone of requireApproval, reviewCallback, statusCallback, mode,\nconfidenceThreshold, contentPatterns, escalationPolicy or the object form\nof auditLog exists in src/lib/types/hitl.ts or is handled by\nsrc/lib/hitl/hitlManager.ts. validateConfig does not reject unknown keys\neither, so a config copied from this page is accepted silently and every one\nof those keys is dropped — approval gates that never fire, with no error.\n\nThat includes the compliance sections. The HIPAA / SOC2 / GDPR examples show an\nauditLog storage backend and an escalationPolicy that do not exist; do not\ncite them as evidence of a control.\n\nTracking: #752.\n\nCurrently available\n\nHITLConfig has exactly these eight keys. Anything else on this page is not\nimplemented.\n\nApproval is event-based, through the SDK emitter — there is no\nreviewCallback. The emitter is reached with getEventEmitter(); NeuroLink\ndoes not extend EventEmitter, so neurolink.on(...) and neurolink.emit(...)\ndo not exist:\n\nThis is the shape exercised by test/continuous-test-suite-hitl.ts. For\nproduction use today, refer to the Basic HITL Guide.\n\nExecutive Summary\n\nNeuroLink's Human-in-the-Loop (HITL) system provides enterprise-grade controls for AI operations requiring human oversight. Purpose-built for regulated industries and high-stakes applications, it combines real-time approval workflows with comprehensive audit trails to meet compliance requirements while maintaining operational efficiency.\n\nStrategic Value Proposition\nRisk Mitigation: Prevent costly AI mistakes through mandatory human checkpoints\nRegulatory Compliance: Meet HIPAA, SOC2, GDPR, and industry-specific requirements\nTrust & Transparency: Build stakeholder confidence with auditable AI decisions\nContinuous Improvement: Capture human expertise to improve AI accuracy over time\n\nKey Metrics\n\n| Metric | Impact | Evidence |\n| ------------------------ | -------------------- | ----------------------------------------------- |\n| Accuracy Improvement | 95% increase | Human validation catches edge cases AI misses |\n| Compliance Coverage | 100% auditability | Complete decision trail for regulatory review |\n| Model Learning Rate | 60% faster | Structured feedback accelerates training cycles |\n| Enterprise Adoption | 90% confidence boost | Security teams approve HITL-enabled deployments |\n\nWhen to Use HITL\n\nRequired for:\nMedical diagnosis and treatment recommendations\nFinancial transactions above risk thresholds\nLegal document generation and review\nCode execution in production environments\nPersonal data modification or deletion\nIrreversible operations (send email, post to social media)\n\nNot recommended for:\nRead-only operations (information retrieval)\nLow-stakes content generation\nDevelopment/testing environments\nHigh-volume, low-risk automation\n\nQuick Start (5 Minutes) — target API, not implemented\n\nThe configuration in this section is not implemented. Use\n\"Currently available\" above for a setup that works.\n\nInstallation\n\nHITL is built into NeuroLink SDK v7.39.0+. No additional packages required:\n\nBasic Configuration\n\nMinimal setup for tool-based approval workflow:\n\nFirst Approval Request\n\nComplete end-to-end example with error handling:\n\nCore Concepts\nApproval Workflows\n\nHITL supports both synchronous (blocking) and asynchronous (non-blocking) approval patterns:\n\nSynchronous Approval (Blocking)\n\nAI operation pauses until human approves or rejects:\n\nUse cases:\nReal-time operations requiring immediate decision\nInteractive applications with user present\nHigh-risk actions requiring instant validation\n\nAsynchronous Approval (Non-blocking)\n\nAI operation returns pending status, continues when approved:\n\nUse cases:\nBatch processing workflows\nOperations requiring expert review (takes time)\nMulti-level approval chains\nIntegration with ticketing systems (Jira, ServiceNow)\nReview Triggers\n\nConfigure when human review is required:\n\nConfidence Threshold Trigger (Planned)\n\nAutomatically request review when AI confidence is low:\n\nTool-Specific Rules\n\nRequire approval for specific tools only:\n\nContent Pattern Matching (Planned)\n\nTrigger review based on content patterns:\n\nTime-Based Restrictions\n\nRequire approval outside business hours:\nEscalation Policies (Planned)\n\nHandle timeout and multi-level approval:\n\nSDK Integration\n\nTypeScript Configuration\n\nComplete configuration interface:\n\nApproval Callback Patterns\n\nSlack Integration\n\nEmail Integration\n\nIntegration with External Systems\n","hierarchy":{"lvl0":"Features","lvl1":"Enterprise Human-in-the-Loop System","lvl2":"","lvl3":""}},
|
|
@@ -4760,7 +4759,7 @@
|
|
|
4760
4759
|
{"objectID":"8b922e3ee9644559addad4738b5f0c6360fe12ae2d1d0c98d678ddaac03eede9","title":"Troubleshooting","url":"/docs/features/workflow-engine#troubleshooting","content":"| Problem | Solution |\n| --------------------------------- | ---------------------------------------------------------------------------------- |\n| Workflow not found in registry | Register it with registerWorkflow() before calling generate() with workflow: |\n| All models failed | Check API keys, increase timeout, verify provider availability |\n| Judge returns neutral scores (50) | Judge response parsing failed; check judge model supports JSON output |\n| Slow execution | Reduce model count, use faster models, increase parallelism |\n| High costs | Use consensus-3-fast, chain/adaptive workflows, or set costThreshold |\n| Low consensus in multi-judge | Normal for subjective queries; increase judge count or align criteria |","hierarchy":{"lvl0":"Features","lvl1":"Workflow Engine Guide","lvl2":"Troubleshooting","lvl3":""}},
|
|
4761
4760
|
{"objectID":"e9de380e8339140c2951bda58d6eaaffb28f182c85fbfda7d7679ea6f5af270e","title":"Core Exports","url":"/docs/features/workflow-engine#core-exports","content":"Execution:\nrunWorkflow(config, options) -- Execute a complete workflow\nrunWorkflowWithStreaming(config, options) -- Execute with progressive streaming\nexecuteEnsemble(options) -- Low-level parallel model execution\nexecuteModelGroups(groups, prompt, config) -- Low-level layer-based execution\nscoreEnsemble(options) -- Low-level judge scoring\nconditionResponse(options) -- Low-level response conditioning\n\nConfiguration:\ncreateWorkflowConfig(partial) -- Create config with defaults\nvalidateWorkflow(config) -- Validate workflow configuration\nvalidateForExecution(config) -- Validate for execution readiness\n\nRegistry:\nregisterWorkflow(config, options) -- Register a workflow\nunregisterWorkflow(workflowId) -- Remove a workflow\ngetWorkflow(workflowId) -- Retrieve by ID\nlistWorkflows(options) -- List with filtering\ngetRegistryStats() -- Registry statistics\nclearRegistry() -- Remove all workflows\n\nPre-built Workflows:\nCONSENSUS_3_WORKFLOW -- 3-model ensemble with judge\nCONSENSUS_3_FAST_WORKFLOW -- Fast/cheap 3-model ensemble\nBALANCED_ADAPTIVE_WORKFLOW -- 2-tier balanced adaptive\nQUALITY_MAX_WORKFLOW -- 3-tier quality-maximizing adaptive\nSPEED_FIRST_WORKFLOW -- Speed-optimized adaptive\nAGGRESSIVE_FALLBACK_WORKFLOW -- Fast + parallel premium fallback\nFAST_FALLBACK_WORKFLOW -- Sequential 3-tier fallback\nMULTI_JUDGE_3_WORKFLOW -- 3 models, 2 judges\nMULTI_JUDGE_5_WORKFLOW -- 5 models, 3 judges\n\nFactory Functions:\ncreateConsensus3WithPrompt(systemPrompt) -- Consensus-3 with custom prompt\ncreateAdaptiveWorkflow(tiers, strategy) -- Custom adaptive workflow\ncreateMultiJudgeWorkflow(modelCount, judgeCount) -- Custom multi-judge\n\nMetrics:\ncalculateModelMetrics(responses) -- Per-model metrics\ncalculateConfidence(scores) -- Confidence calculation\ncalculateConsensus(scores) -- Consensus calculation\ngenerateSummaryStats(results) -- Summary statistics\ncompareWorkflows(stats1, stats2) -- Workflow comparison\nformatMetricsForLogging(result) -- Formatted logging output\n\nTypes:\nWorkflowConfig,","hierarchy":{"lvl0":"Features","lvl1":"Workflow Engine Guide","lvl2":"Core Exports","lvl3":""}},
|
|
4762
4761
|
{"objectID":"fb91715f0910d539aa3342bb53890eb88ef04121ad496d9c8c982c55d6a645d5","title":"See Also","url":"/docs/features/workflow-engine#see-also","content":"Provider Orchestration Guide -- Multi-provider configuration\nObservability Guide -- Tracing workflow executions with Langfuse\nStructured Output Guide -- JSON schema output (note: incompatible with Gemini tools)","hierarchy":{"lvl0":"Features","lvl1":"Workflow Engine Guide","lvl2":"See Also","lvl3":""}},
|
|
4763
|
-
{"objectID":"fcc71bbb437aec3313f917118186ae468e33d960b134ccbe3a8151a55970c6a9","title":"🔧 Environment Variables Configuration Guide","url":"/docs/getting-started/environment-variables","content":"🔧 Environment Variables Configuration Guide\n\nThis guide provides comprehensive setup instructions for all AI providers supported by NeuroLink. The CLI automatically loads environment variables from .env files, making configuration seamless.\n\n🚀 Quick Setup\n\nAutomatic .env Loading ✨ NEW!\n\nNeuroLink CLI automatically loads environment variables from .env files in your project directory:\n\nManual Export (Also Supported)\n\n🏗️ Enterprise Configuration Management\n\n✨ NEW: Automatic Backup System\n\nInterface Configuration\n\nPerformance & Optimization\n\n🆕 AI Enhancement Features\n\nBasic Enhancement Configuration\n\nDescription: Configures the AI model used for response quality evaluation when --enable-evaluation flag is used. Uses Google AI's fast Gemini 2.5 Flash model for quick quality assessment.\n\nSupported Models:\ngemini-2.5-flash (default) - Fast evaluation processing\ngemini-2.5-pro - More detailed evaluation (slower)\n\nUsage:\n\n🌐 Universal Evaluation System (Advanced)\n\nPrimary Configuration\n\nNEUROLINK_EVALUATION_PROVIDER: Primary AI provider for evaluation\nOptions: google-ai, openai, anthropic, vertex, bedrock, azure, ollama, huggingface, mistral\nDefault: google-ai\nUsage: Determines which AI provider performs the quality evaluation\n\nNEUROLINK_EVALUATION_MODE: Performance vs quality trade-off\nOptions: fast (cost-effective), balanced (optimal), quality (highest accuracy)\nDefault: fast\nUsage: Selects appropriate model for the provider (e.g., gemini-2.5-flash vs gemini-2.5-pro)\n\nFallback Configuration\n\nNEUROLINK_EVALUATION_FALLBACK_ENABLED: Enable intelligent fallback system\nOptions: true, false\nDefault: true\nUsage: When enabled, automatically tries backup providers if primary fails\n\nNEUROLINK_EVALUATION_FALLBACK_PROVIDERS: Backup provider order\nFormat: Comma-separated provider names\nDefault: openai,anthropic,vertex,bedrock\nUsage: Defines the order of providers to try if primary fails\n\nPerformance Tuning\n\nPerformance Variables:\nTIMEOUT: Maximum time to wait for evaluation (prevents hanging)\nMAX_TOKENS: Limits evaluation response length (controls cost)\nTEMPERATURE: Lower values = more consistent scoring\nRETRY_ATTEMPTS: Number of retry attempts for transient failures\n\nCost Optimization\n\nNEUROLINK_EVALUATION_PREFER_CHEAP: Cost optimization preference\nOptions: true, false\nDefault: true\nUsage: When enabled, prioritizes cheaper providers and models\n\nNEUROLINK_EVALUATION_MAX_COST_PER_EVAL: Cost limit per evaluation\nFormat: Decimal number (USD)\nDefault: 0.01 ($0.01)\nUsage: Prevents expensive evaluations, switches to cheaper providers if needed\n\nComplete Universal Evaluation Example\n\nTesting Universal Evaluation\n\n🏢 Enterprise Proxy Configuration\n\nProxy Environment Variables\n\n| Variable | Description | Example |\n| ------------- | ------------------------------- | ---------------------------------- |\n| HTTPS_PROXY | Proxy server for HTTPS requests | http://proxy.company.com:8080 |\n| HTTP_PROXY | Proxy server for HTTP requests | http://proxy.company.com:8080 |\n| NO_PROXY | Domains to bypass proxy | localhost,127.0.0.1,.company.com |\n\nAuthenticated Proxy\n\nAll NeuroLink providers automatically use proxy settings when configured.\n\nFor detailed proxy setup → See Enterprise & Proxy Setup Guide\n\n🤖 Provider Configuration\nOpenAI\n\nRequired Variables\n\nOptional Variables\n\nHow to Get OpenAI API Key\nVisit OpenAI Platform\nSign up or log in to your account\nNavigate to API Keys section\nClick Create new secret key\nCopy the key (starts with sk-proj- or sk-)\nAdd billing information if required\n\nSupported Models\n\nExamples, not the full list. The OpenAI guide lists every model the SDK names, including the GPT-6 and gpt-5.4-nano models.\ngpt-5.4 - GPT-5.4 model\ngpt-5.4-mini - Faster, cost-effective GPT-5.4 option\ngpt-4o-mini (default) - Cost-effective, fast\ngpt-4o - Previous generation multimodal model\ngpt-4-turbo - High-performance model\ngpt-3.5-turbo - Legacy cost-effective
|
|
4762
|
+
{"objectID":"fcc71bbb437aec3313f917118186ae468e33d960b134ccbe3a8151a55970c6a9","title":"🔧 Environment Variables Configuration Guide","url":"/docs/getting-started/environment-variables","content":"🔧 Environment Variables Configuration Guide\n\nThis guide provides comprehensive setup instructions for all AI providers supported by NeuroLink. The CLI automatically loads environment variables from .env files, making configuration seamless.\n\n🚀 Quick Setup\n\nAutomatic .env Loading ✨ NEW!\n\nNeuroLink CLI automatically loads environment variables from .env files in your project directory:\n\nManual Export (Also Supported)\n\n🏗️ Enterprise Configuration Management\n\n✨ NEW: Automatic Backup System\n\nInterface Configuration\n\nPerformance & Optimization\n\n🆕 AI Enhancement Features\n\nBasic Enhancement Configuration\n\nDescription: Configures the AI model used for response quality evaluation when --enable-evaluation flag is used. Uses Google AI's fast Gemini 2.5 Flash model for quick quality assessment.\n\nSupported Models:\ngemini-2.5-flash (default) - Fast evaluation processing\ngemini-2.5-pro - More detailed evaluation (slower)\n\nUsage:\n\n🌐 Universal Evaluation System (Advanced)\n\nPrimary Configuration\n\nNEUROLINK_EVALUATION_PROVIDER: Primary AI provider for evaluation\nOptions: google-ai, openai, anthropic, vertex, bedrock, azure, ollama, huggingface, mistral\nDefault: google-ai\nUsage: Determines which AI provider performs the quality evaluation\n\nNEUROLINK_EVALUATION_MODE: Performance vs quality trade-off\nOptions: fast (cost-effective), balanced (optimal), quality (highest accuracy)\nDefault: fast\nUsage: Selects appropriate model for the provider (e.g., gemini-2.5-flash vs gemini-2.5-pro)\n\nFallback Configuration\n\nNEUROLINK_EVALUATION_FALLBACK_ENABLED: Enable intelligent fallback system\nOptions: true, false\nDefault: true\nUsage: When enabled, automatically tries backup providers if primary fails\n\nNEUROLINK_EVALUATION_FALLBACK_PROVIDERS: Backup provider order\nFormat: Comma-separated provider names\nDefault: openai,anthropic,vertex,bedrock\nUsage: Defines the order of providers to try if primary fails\n\nPerformance Tuning\n\nPerformance Variables:\nTIMEOUT: Maximum time to wait for evaluation (prevents hanging)\nMAX_TOKENS: Limits evaluation response length (controls cost)\nTEMPERATURE: Lower values = more consistent scoring\nRETRY_ATTEMPTS: Number of retry attempts for transient failures\n\nCost Optimization\n\nNEUROLINK_EVALUATION_PREFER_CHEAP: Cost optimization preference\nOptions: true, false\nDefault: true\nUsage: When enabled, prioritizes cheaper providers and models\n\nNEUROLINK_EVALUATION_MAX_COST_PER_EVAL: Cost limit per evaluation\nFormat: Decimal number (USD)\nDefault: 0.01 ($0.01)\nUsage: Prevents expensive evaluations, switches to cheaper providers if needed\n\nComplete Universal Evaluation Example\n\nTesting Universal Evaluation\n\n🏢 Enterprise Proxy Configuration\n\nProxy Environment Variables\n\n| Variable | Description | Example |\n| ------------- | ------------------------------- | ---------------------------------- |\n| HTTPS_PROXY | Proxy server for HTTPS requests | http://proxy.company.com:8080 |\n| HTTP_PROXY | Proxy server for HTTP requests | http://proxy.company.com:8080 |\n| NO_PROXY | Domains to bypass proxy | localhost,127.0.0.1,.company.com |\n\nThe shared HTTP proxy fetch accepts comma- or whitespace-separated NO_PROXY entries. Entries are case-insensitive: * bypasses all; example.com, .example.com and *.example.com cover the host and its subdomains; example.com:8443 restricts a match to that effective port (HTTP defaults to 80, HTTPS to 443). One trailing dot is normalized for domain names. IPv4/IPv6 literals match exactly, including [::1]:8080; IPv4 CIDR entries apply only to literal IPv4 targets, and IPv6 CIDR is unsupported. Dot-only entries (. or ..) match nothing.\n\nThese rules apply to request paths that use NeuroLink's HTTP proxy fetch. Native AWS handlers, Gemini Live WebSockets and Vertex ADC token requests use separate transports/dependency rules. See Enterprise & Proxy Setup for those limits. The legacy AWS proxy selector uses a smaller comma-separated matcher; it supports exact hosts, leading-dot subdomain suffixes and *, without the full port/wildcard/CIDR syntax. It is not automatically injected into the native Bedrock constructors.\n\nAuthenticated Proxy\n\nAll NeuroLink providers automatically use proxy settings when configured.\n\nFor detailed proxy setup → See Enterprise & Proxy Setup Guide\n\n🤖 Provider Configuration\nOpenAI\n\nRequired Variables\n\nOptional Variables\n\nHow to Get OpenAI API Key\nVisit OpenAI Platform\nSign up or log in to your account\nNavigate to API Keys section\nClick Create new secret key\nCopy the key (starts with sk-proj- or sk-)\nAdd billing information if required\n\nSupported Models\n\nExamples, not the full list. The OpenAI guide lists every model the SDK names, including the GPT-6 and gpt-5.4-nano models.\ngpt-5.4 - GPT-5.4 model\ngpt-5.4-mini - Faster, cost-effective GPT-5.4 option\ngpt-4o-mini (default) - Cost-effective, fast\ngpt-4o - Previous generation multimodal model\ngpt-4-turbo - High-performance model\ngpt-3.5-turbo - Legacy cost-effective opt","hierarchy":{"lvl0":"Getting Started","lvl1":"🔧 Environment Variables Configuration Guide","lvl2":"","lvl3":""}},
|
|
4764
4763
|
{"objectID":"c81a81fd6221fc873edf4a381a6af70939b66519ee4d4ce31acce9afec8fb5f1","title":"🔧 Environment Variables Configuration Guide","url":"/docs/getting-started/environment-variables#-environment-variables-configuration-guide","content":"This guide provides comprehensive setup instructions for all AI providers supported by NeuroLink. The CLI automatically loads environment variables from .env files, making configuration seamless.","hierarchy":{"lvl0":"Getting Started","lvl1":"🔧 Environment Variables Configuration Guide","lvl2":"🔧 Environment Variables Configuration Guide","lvl3":""}},
|
|
4765
4764
|
{"objectID":"a78ad3583ac3d28848100b6a1e832a69a5d8d6dd5538da571bcf5d184ef34789","title":"Automatic .env Loading ✨ NEW!","url":"/docs/getting-started/environment-variables#automatic-env-loading-new","content":"NeuroLink CLI automatically loads environment variables from .env files in your project directory:\n\n`bash","hierarchy":{"lvl0":"Getting Started","lvl1":"🔧 Environment Variables Configuration Guide","lvl2":"Automatic .env Loading ✨ NEW!","lvl3":""}},
|
|
4766
4765
|
{"objectID":"7f0086c723d683ab77c7a74bfeaf8a61a34e60fc87f62f7c8abceeb385bebab3","title":"Create .env file (automatically loaded)","url":"/docs/getting-started/environment-variables#create-env-file-automatically-loaded","content":"echo 'OPENAIAPIKEY=\"sk-your-key\"' > .env\necho 'AWSACCESSKEY_ID=\"your-key\"' >> .env","hierarchy":{"lvl0":"Getting Started","lvl1":"🔧 Environment Variables Configuration Guide","lvl2":"Create .env file (automatically loaded)","lvl3":""}},
|
|
@@ -4800,7 +4799,7 @@
|
|
|
4800
4799
|
{"objectID":"57f0addcbc5bdff17976ccbc73a4b2e1229523b930be1f09678e65d23ebdc42f","title":"Test with custom domain","url":"/docs/getting-started/environment-variables#test-with-custom-domain","content":"npx @juspay/neurolink generate \"Fix this Python code\" --enable-evaluation --evaluation-domain \"Python expert\"","hierarchy":{"lvl0":"Getting Started","lvl1":"🔧 Environment Variables Configuration Guide","lvl2":"Test with custom domain","lvl3":""}},
|
|
4801
4800
|
{"objectID":"6c7f36b35ec90ebcb403a7c9e5f614a11fbf88b5ec03c95781d74127571f25e8","title":"Test Lighthouse-style evaluation","url":"/docs/getting-started/environment-variables#test-lighthouse-style-evaluation","content":"npx @juspay/neurolink generate \"Business analysis\" --lighthouse-style --evaluation-domain \"Business consultant\"\n`","hierarchy":{"lvl0":"Getting Started","lvl1":"🔧 Environment Variables Configuration Guide","lvl2":"Test Lighthouse-style evaluation","lvl3":""}},
|
|
4802
4801
|
{"objectID":"6cce8afe8128b6c9013bc983c389eb925ade55d2d0709c415c9c3e35b1a7826c","title":"Proxy Environment Variables","url":"/docs/getting-started/environment-variables#proxy-environment-variables","content":"`bash","hierarchy":{"lvl0":"Getting Started","lvl1":"🔧 Environment Variables Configuration Guide","lvl2":"Proxy Environment Variables","lvl3":""}},
|
|
4803
|
-
{"objectID":"d94e2475c84281a14bee2c88fb34c9e5af7a5b2f62b9d35935fb4b1fcbba5cf1","title":"Corporate proxy support (automatic detection)","url":"/docs/getting-started/environment-variables#corporate-proxy-support-automatic-detection","content":"HTTPS_PROXY=\"http://proxy.company.com:8080\"\nHTTP_PROXY=\"http://proxy.company.com:8080\"\nNO_PROXY=\"localhost,127.0.0.1,.company.com\"\n\n\n| Variable | Description | Example |\n| ------------- | ------------------------------- | ---------------------------------- |\n| HTTPSPROXY | Proxy server for HTTPS requests | http://proxy.company.com:8080 |\n| HTTPPROXY | Proxy server for HTTP requests | http://proxy.company.com:8080 |\n|
|
|
4802
|
+
{"objectID":"d94e2475c84281a14bee2c88fb34c9e5af7a5b2f62b9d35935fb4b1fcbba5cf1","title":"Corporate proxy support (automatic detection)","url":"/docs/getting-started/environment-variables#corporate-proxy-support-automatic-detection","content":"HTTPS_PROXY=\"http://proxy.company.com:8080\"\nHTTP_PROXY=\"http://proxy.company.com:8080\"\nNO_PROXY=\"localhost,127.0.0.1,.company.com\"\n\n\n| Variable | Description | Example |\n| ------------- | ------------------------------- | ---------------------------------- |\n| HTTPSPROXY | Proxy server for HTTPS requests | http://proxy.company.com:8080 |\n| HTTPPROXY | Proxy server for HTTP requests | http://proxy.company.com:8080 |\n| NOPROXY | Domains to bypass proxy | localhost,127.0.0.1,.company.com |\n\nThe shared HTTP proxy fetch accepts comma- or whitespace-separated NOPROXY entries. Entries are case-insensitive: bypasses all; example.com, .example.com and .example.com cover the host and its subdomains; example.com:8443 restricts a match to that effective port (HTTP defaults to 80, HTTPS to 443). One trailing dot is normalized for domain names. IPv4/IPv6 literals match exactly, including [::1]:8080; IPv4 CIDR entries apply only to literal IPv4 targets, and IPv6 CIDR is unsupported. Dot-only entries (. or ..) match nothing.\n\nThese rules apply to request paths that use NeuroLink's HTTP proxy fetch. Native AWS handlers, Gemini Live WebSockets and Vertex ADC token requests use separate transports/dependency rules. See [Enterprise & Proxy Setup](/docs/deployment/enterprise-proxy) for those limits. The legacy AWS proxy selector uses a smaller comma-separated matcher; it supports exact hosts, leading-dot subdomain suffixes and *`, without the full port/wildcard/CIDR syntax. It is not automatically injected into the native Bedrock constructors.","hierarchy":{"lvl0":"Getting Started","lvl1":"🔧 Environment Variables Configuration Guide","lvl2":"Corporate proxy support (automatic detection)","lvl3":""}},
|
|
4804
4803
|
{"objectID":"d5cabd5bf6ae965d7bf7274d74934ba63f7d8b3567bc4b54317270dade223d44","title":"Authenticated Proxy","url":"/docs/getting-started/environment-variables#authenticated-proxy","content":"`bash","hierarchy":{"lvl0":"Getting Started","lvl1":"🔧 Environment Variables Configuration Guide","lvl2":"Authenticated Proxy","lvl3":""}},
|
|
4805
4804
|
{"objectID":"bf0792704fa31e90694a52e8e293682873f558d49131eba9f2e9a4d2f40498ec","title":"Proxy with username/password authentication","url":"/docs/getting-started/environment-variables#proxy-with-usernamepassword-authentication","content":"HTTPS_PROXY=\"http://username:password@proxy.company.com:8080\"\nHTTP_PROXY=\"http://username:password@proxy.company.com:8080\"\n`\n\nAll NeuroLink providers automatically use proxy settings when configured.\n\nFor detailed proxy setup → See Enterprise & Proxy Setup Guide","hierarchy":{"lvl0":"Getting Started","lvl1":"🔧 Environment Variables Configuration Guide","lvl2":"Proxy with username/password authentication","lvl3":""}},
|
|
4806
4805
|
{"objectID":"010e6483ced7a9b1fba1740513766a58d6e77b2da14e91d6d3669cfb10eaecc8","title":"How to Get OpenAI API Key","url":"/docs/getting-started/environment-variables#how-to-get-openai-api-key","content":"Visit OpenAI Platform\nSign up or log in to your account\nNavigate to API Keys section\nClick Create new secret key\nCopy the key (starts with sk-proj- or sk-)\nAdd billing information if required","hierarchy":{"lvl0":"Getting Started","lvl1":"🔧 Environment Variables Configuration Guide","lvl2":"How to Get OpenAI API Key","lvl3":""}},
|
|
@@ -9714,11 +9713,11 @@
|
|
|
9714
9713
|
{"objectID":"0060ac273f386c349e42799641f9fc2ac514f569b1870b20a2cc8097d482bf2d","title":"7. Shared logging fetch — createLoggingFetch","url":"/docs/provider-integration/SAFETY-PRIMITIVES#7-shared-logging-fetch-createloggingfetch","content":"Use for: the fetch option on createOpenAI({...}) / similar SDK\nclient constructors when you want non-2xx upstream responses logged\nwith sanitized output.\n\nBody opt-in: response bodies are NOT logged by default. Set\nNEUROLINK_DEBUG_HTTP=1 to enable body logging — bodies are run\nthrough sanitizeForLog to redact tokens.\n\nPreviously duplicated in: cohere, xai, groq, togetherAi, fireworks,\nperplexity, cloudflare, llamaCpp, lmStudio, nvidiaNim, deepseek (11\nnear-identical copies with subtle differences). Now centralised.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Safety Primitives Reference","lvl2":"7. Shared logging fetch — createLoggingFetch","lvl3":""}},
|
|
9715
9714
|
{"objectID":"1ba0f0ac7f804aa5d9cabe5106734436439a83dc273dcf5e05984d218fae5b1f","title":"8. Test scripts","url":"/docs/provider-integration/SAFETY-PRIMITIVES#8-test-scripts","content":"⚠️ These three suites no longer exist. ssrf, log-sanitize and\nstream-span each imported the primitive out of src/lib/ and asserted on\nit directly, so they were removed when the suites became end-to-end only\n(CLAUDE.md rule 15).\n\n| Removed suite | Covered |\n| -------------------------------------------- | ------------------------------------------------------------------------------------------------------- |\n| test/continuous-test-suite-ssrf.ts | H01 + H06 bypass categories, handler-coverage audit |\n| test/continuous-test-suite-log-sanitize.ts | H03 + H04 token formats, record/header sanitization, H04 regression grep |\n| test/continuous-test-suite-stream-span.ts | H07 span lifetime + error path + recordException ordering, M08 typed-error sweep, M09 brand check sweep |\n\nNothing has replaced them. The primitives themselves are unchanged, and only\ntwo eslint rules still apply (no-inline-secret-regex for log redaction,\nprovider-typed-errors for typed provider errors). The SSRF/safeDownload,\nstream-span and isNeuroLink brand-check bypasses have no rule and are caught\nonly by review. Treat the checklist below as the live control.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Safety Primitives Reference","lvl2":"8. Test scripts","lvl3":""}},
|
|
9716
9715
|
{"objectID":"2c421be98a40dada99b032fd6dab31bc387486db4c7060e3c4fd720b1135742d","title":"9. Universal safety checklist (paste into PR description)","url":"/docs/provider-integration/SAFETY-PRIMITIVES#9-universal-safety-checklist-paste-into-pr-description","content":"When adding any new provider / modality / handler, tick:\n[ ] All caller-influenced URL downloads go through safeDownload (or predictionLifecycle.downloadPredictionOutput for Replicate-based handlers)\n[ ] All HTTP response bodies sanitized via sanitizeForLog / sanitizeRecord / sanitizeHeaders (NO inline regex)\n[ ] Streaming spans wrapped in withClientStreamSpan (NOT withClientSpan)\n[ ] Provider SDK reference validated via isNeuroLink(sdk) (NOT duck-typing)\n[ ] formatProviderError returns typed errors (AuthenticationError / RateLimitError / InvalidModelError / NetworkError / ProviderError / NeuroLinkError) — never plain Error\n[ ] Reviewed by hand against §8 — the ssrf / log-sanitize / stream-span suites that used to gate this were removed with the unit suites\n\nIf a custom redaction or fetch pattern is genuinely required, add an\neslint-disable-next-line with a one-line justification rather than\nsilently bypassing the centralized helper.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Safety Primitives Reference","lvl2":"9. Universal safety checklist (paste into PR description)","lvl3":""}},
|
|
9717
|
-
{"objectID":"a38fecff2a45c5d93cfd8f93417b053e1d9b60919a6802b88a0876d3729d2c0d","title":"Credential-free provider acceptance gate","url":"/docs/provider-integration/acceptance-gate","content":"Credential-free provider acceptance gate\n\nSuite: test/continuous-test-suite-acceptance-gate.ts\nRun: pnpm run test:acceptance-gate\nScript: test:acceptance-gate in package.json\nMock server: test/helpers/acceptanceGateServer.ts\n\nWhy this exists\n\nThe prior full provider capability matrix (test/continuous-test-suite-provider-matrix.ts,\n1,037 cells) was audited and found to be able to report green without proving\nanything, in at least 10 ways: tool cells that passed with zero tool calls\nmade, no disableInternalFallback and no provider/model identity check on\nany cell, structured-output cells that asserted a value's type rather than\nits contents, and a harness that could exit 0 on zero coverage.\n\nThis gate replaces that surface area with a small, falsifiable one: at most\n9 cells per (provider, pinned model), fail-fast, cheapest first, run\nentirely against a local mock vendor HTTP server — no real vendor calls, no\nreal API keys, ever. Every provider is pointed at the mock through its own\ndocumented base-URL environment override, with a fake key, so the SDK and\nthe CLI both round-trip through the exact same server (that's what makes\ncell 9, CLI parity, meaningful instead of a re-derivation).\n\nThe 9 cells\n\nEach cell asserts an exact value the mock server returns, never a shape\nor a \"non-empty\" check. A row stops (remaining cells report SKIP, not a\nsecond FAIL) the first time a cell genuinely fails — this is the\n\"fail-fast\" contract; a capability-gated skip (e.g. a provider that doesn't\ndeclare tools) never counts as a failure and never poisons the rest of the\nrow.\nIdentity pin — every call carries\n { provider, model, disableInternalFallback: true }; the result's\n provider and model fields are asserted against what was requested.\nExact-output generate — generate()'s content is asserted equal to\n a specific constant (GATE_EXACT_VALUE), not merely non-empty.\nDrained stream, identity asserted — the stream is fully drained and\n the accumulated content is asserted equal to a constant. The\n StreamResult's provider/model are then asserted — and for the\n OpenAI-compatible protocol rows, against what the mock server actually\n served (${model}::mock-server-resolved), not what was requested. See\n \"The stream-identity defect\" below — this cell is the reason that defect\n was caught and fixed.\nTool-nonce proof — the test tool's execute() returns a fresh\n randomUUID() nonce that exists nowhere else. The final answer is\n asserted to contain ACCEPTANCE_GATE_TOOL_CONFIRMED:<nonce>, which the\n mock server only emits once it sees that exact nonce echoed back in a\n tool-result message — i.e. the assertion can only pass if a real tool\n call round-tripped through the model.\nStructured-exact — generate({ schema })'s parsed structuredData is\n asserted equal (via JSON.stringify) to an exact object, and\n jsonTruncated is asserted not true — truncation is surfaced, never\n silently swallowed.\nThinking proof — only for providers whose catalog/descriptor declares\n thinking: true (currently anthropic and the deepseek catalog row).\n Drives stream() with an explicit\n thinkingConfig: { enabled: true, budgetTokens: 2048 } (the SDK path has no bare thinkingLevel\n convenience — that folding only exists on the CLI's option parser) and\n asserts the accumulated reasoning deltas and the post-thinking answer\n both equal exact constants.\nEmbeddings proof — only for providers whose row declares\n embeddings: true. Goes through ProviderFactory.createProvider()\n directly (NeuroLink has no embed() method) and asserts the returned\n vector equals an exact constant array.\nBudget ceiling enforced — a dedicated, low-ceiling (1) mock\n server instance proves the ceiling mechanism itself is real: a first call\n succeeds, a second call against the same server must fail, and the\n server's own request counter is asserted to have observed both. This\n runs against its own server, never the shared one every other cell uses,\n so it can't be tripped by unrelated traffic.\nCLI parity — the same identity + exact-output assertions as cells 1-2,\n but driven through the built CLI\n (node dist/cli/index.js generate ... --format json), parsing its JSON\n stdout, against the same mock server.\n Not a separate re-derivation of the assertions — literally the same\n constants.\n\
|
|
9716
|
+
{"objectID":"a38fecff2a45c5d93cfd8f93417b053e1d9b60919a6802b88a0876d3729d2c0d","title":"Credential-free provider acceptance gate","url":"/docs/provider-integration/acceptance-gate","content":"Credential-free provider acceptance gate\n\nSuite: test/continuous-test-suite-acceptance-gate.ts\nRun: pnpm run test:acceptance-gate\nScript: test:acceptance-gate in package.json\nMock server: test/helpers/acceptanceGateServer.ts\n\nWhy this exists\n\nThe prior full provider capability matrix (test/continuous-test-suite-provider-matrix.ts,\n1,037 cells) was audited and found to be able to report green without proving\nanything, in at least 10 ways: tool cells that passed with zero tool calls\nmade, no disableInternalFallback and no provider/model identity check on\nany cell, structured-output cells that asserted a value's type rather than\nits contents, and a harness that could exit 0 on zero coverage.\n\nThis gate replaces that surface area with a small, falsifiable one: at most\n9 cells per (provider, pinned model), fail-fast, cheapest first, run\nentirely against a local mock vendor HTTP server — no real vendor calls, no\nreal API keys, ever. Every provider is pointed at the mock through its own\ndocumented base-URL environment override, with a fake key, so the SDK and\nthe CLI both round-trip through the exact same server (that's what makes\ncell 9, CLI parity, meaningful instead of a re-derivation).\n\nThe 9 cells\n\nEach cell asserts an exact value the mock server returns, never a shape\nor a \"non-empty\" check. A row stops (remaining cells report SKIP, not a\nsecond FAIL) the first time a cell genuinely fails — this is the\n\"fail-fast\" contract; a capability-gated skip (e.g. a provider that doesn't\ndeclare tools) never counts as a failure and never poisons the rest of the\nrow.\nIdentity pin — every call carries\n { provider, model, disableInternalFallback: true }; the result's\n provider and model fields are asserted against what was requested.\nExact-output generate — generate()'s content is asserted equal to\n a specific constant (GATE_EXACT_VALUE), not merely non-empty.\nDrained stream, identity asserted — the stream is fully drained and\n the accumulated content is asserted equal to a constant. The\n StreamResult's provider/model are then asserted — and for the\n OpenAI-compatible protocol rows, against what the mock server actually\n served (${model}::mock-server-resolved), not what was requested. See\n \"The stream-identity defect\" below — this cell is the reason that defect\n was caught and fixed.\nTool-nonce proof — the test tool's execute() returns a fresh\n randomUUID() nonce that exists nowhere else. The final answer is\n asserted to contain ACCEPTANCE_GATE_TOOL_CONFIRMED:<nonce>, which the\n mock server only emits once it sees that exact nonce echoed back in a\n tool-result message — i.e. the assertion can only pass if a real tool\n call round-tripped through the model.\nStructured-exact — generate({ schema })'s parsed structuredData is\n asserted equal (via JSON.stringify) to an exact object, and\n jsonTruncated is asserted not true — truncation is surfaced, never\n silently swallowed.\nThinking proof — only for providers whose catalog/descriptor declares\n thinking: true (currently anthropic and the deepseek catalog row).\n Drives stream() with an explicit\n thinkingConfig: { enabled: true, budgetTokens: 2048 } (the SDK path has no bare thinkingLevel\n convenience — that folding only exists on the CLI's option parser) and\n asserts the accumulated reasoning deltas and the post-thinking answer\n both equal exact constants.\nEmbeddings proof — only for providers whose row declares\n embeddings: true. Goes through ProviderFactory.createProvider()\n directly (NeuroLink has no embed() method) and asserts the returned\n vector equals an exact constant array.\nBudget ceiling enforced — a dedicated, low-ceiling (1) mock\n server instance proves the ceiling mechanism itself is real: a first call\n succeeds, a second call against the same server must fail, and the\n server's own request counter is asserted to have observed both. This\n runs against its own server, never the shared one every other cell uses,\n so it can't be tripped by unrelated traffic.\nCLI parity — the same identity + exact-output assertions as cells 1-2,\n but driven through the built CLI\n (node dist/cli/index.js generate ... --format json), parsing its JSON\n stdout, against the same mock server.\n Not a separate re-derivation of the assertions — literally the same\n constants.\n\nCLI fallback policy\n\nThe ordinary generate and stream commands accept\n--disable-internal-fallback (also --disableInternalFallback) and forward it\nto the SDK. The caller receives the selected model's rejection instead of\nautomatically retrying a different model or provider. The default behavior\nstill permits fallback. Cell 9 sets this flag, and\ntest/continuous-test-suite-cli-fallback.ts exercises both default and disabled\nbehavior through the built CLI and SDK.\n\nThe suite holds no real credential. test/helpers/credentialFreeEnv.ts is its first import: it\npoints DOTENV_CONFIG_PATH at /dev/null, so neither the SDK's nor the\nharness's .env load reads a devel","hierarchy":{"lvl0":"Provider Integration","lvl1":"Credential-free provider acceptance gate","lvl2":"","lvl3":""}},
|
|
9718
9717
|
{"objectID":"6bfda42431fee55d45b08f169983782641ed449c8f73abe19f2f3c421f8666cb","title":"Credential-free provider acceptance gate","url":"/docs/provider-integration/acceptance-gate#credential-free-provider-acceptance-gate","content":"Suite: test/continuous-test-suite-acceptance-gate.ts\nRun: pnpm run test:acceptance-gate\nScript: test:acceptance-gate in package.json\nMock server: test/helpers/acceptanceGateServer.ts","hierarchy":{"lvl0":"Provider Integration","lvl1":"Credential-free provider acceptance gate","lvl2":"Credential-free provider acceptance gate","lvl3":""}},
|
|
9719
9718
|
{"objectID":"3ebd78a77f6b62003d9706d1608fb7eded2399f0dbd78b3964e14d5ac3d31f90","title":"Why this exists","url":"/docs/provider-integration/acceptance-gate#why-this-exists","content":"The prior full provider capability matrix (test/continuous-test-suite-provider-matrix.ts,\n1,037 cells) was audited and found to be able to report green without proving\nanything, in at least 10 ways: tool cells that passed with zero tool calls\nmade, no disableInternalFallback and no provider/model identity check on\nany cell, structured-output cells that asserted a value's type rather than\nits contents, and a harness that could exit 0 on zero coverage.\n\nThis gate replaces that surface area with a small, falsifiable one: at most\n9 cells per (provider, pinned model), fail-fast, cheapest first, run\nentirely against a local mock vendor HTTP server — no real vendor calls, no\nreal API keys, ever. Every provider is pointed at the mock through its own\ndocumented base-URL environment override, with a fake key, so the SDK and\nthe CLI both round-trip through the exact same server (that's what makes\ncell 9, CLI parity, meaningful instead of a re-derivation).","hierarchy":{"lvl0":"Provider Integration","lvl1":"Credential-free provider acceptance gate","lvl2":"Why this exists","lvl3":""}},
|
|
9720
9719
|
{"objectID":"0d725f9afdd86b7d8821e0e94ea518e7d06ef55da79a6781a8c9b96d17125ed8","title":"The 9 cells","url":"/docs/provider-integration/acceptance-gate#the-9-cells","content":"Each cell asserts an exact value the mock server returns, never a shape\nor a \"non-empty\" check. A row stops (remaining cells report SKIP, not a\nsecond FAIL) the first time a cell genuinely fails — this is the\n\"fail-fast\" contract; a capability-gated skip (e.g. a provider that doesn't\ndeclare tools) never counts as a failure and never poisons the rest of the\nrow.\nIdentity pin — every call carries\n { provider, model, disableInternalFallback: true }; the result's\n provider and model fields are asserted against what was requested.\nExact-output generate — generate()'s content is asserted equal to\n a specific constant (GATE_EXACT_VALUE), not merely non-empty.\nDrained stream, identity asserted — the stream is fully drained and\n the accumulated content is asserted equal to a constant. The\n StreamResult's provider/model are then asserted — and for the\n OpenAI-compatible protocol rows, against what the mock server actually\n served (${model}::mock-server-resolved), not what was requested. See\n \"The stream-identity defect\" below — this cell is the reason that defect\n was caught and fixed.\nTool-nonce proof — the test tool's execute() returns a fresh\n randomUUID() nonce that exists nowhere else. The final answer is\n asserted to contain ACCEPTANCE_GATE_TOOL_CONFIRMED:<nonce>, which the\n mock server only emits once it sees that exact nonce echoed back in a\n tool-result message — i.e. the assertion can only pass if a real tool\n call round-tripped through the model.\nStructured-exact — generate({ schema })'s parsed structuredData is\n asserted equal (via JSON.stringify) to an exact object, and\n jsonTruncated is asserted not true — truncation is surfaced, never\n silently swallowed.\nThinking proof — only for providers whose catalog/descriptor declares\n thinking: true (currently anthropic and the deepseek catalog row).","hierarchy":{"lvl0":"Provider Integration","lvl1":"Credential-free provider acceptance gate","lvl2":"The 9 cells","lvl3":""}},
|
|
9721
|
-
{"objectID":"
|
|
9720
|
+
{"objectID":"7e26525866b7486ecc4b3e0ffef1b2245c2757590658a08b9e54480e27b6c58e","title":"CLI fallback policy","url":"/docs/provider-integration/acceptance-gate#cli-fallback-policy","content":"The ordinary generate and stream commands accept\n--disable-internal-fallback (also --disableInternalFallback) and forward it\nto the SDK. The caller receives the selected model's rejection instead of\nautomatically retrying a different model or provider. The default behavior\nstill permits fallback. Cell 9 sets this flag, and\ntest/continuous-test-suite-cli-fallback.ts exercises both default and disabled\nbehavior through the built CLI and SDK.\n\nThe suite holds no real credential. test/helpers/credentialFreeEnv.ts is its first import: it\npoints DOTENV_CONFIG_PATH at /dev/null, so neither the SDK's nor the\nharness's .env load reads a developer's .env, it deletes every\ncredential-named variable the shell exported (including secrets whose names the\nplain API-key and token words miss: service-account and private keys, speech\nkeys, OTLP exporter headers, a Redis URL, an auth config blob, the ssh-agent\nsocket) together with the ambient *_BASE_URL, *_ENDPOINT,\nOTLP exporter and AWS_PROFILE overrides that could point a cell somewhere\nother than the mock server, and it points HOME at an empty temp directory.\nThe last one matters as much as the first two: the\nAnthropic provider prefers a stored OAuth token\n(~/.neurolink/anthropic-credentials.json) over ANTHROPIC_API_KEY and\nrefreshes it against Anthropic's live token endpoint, so a gate that only\ncleaned the environment could still send a real refresh token to a real\nhost. The suite checks the environment and the home directory before it\nruns a row, and the CLI child inherits that stripped environment plus the\ncurrent row's fake key. Because that check reuses the strip's own pattern, the\nsuite also plants a literal list of dummy secret and endpoint variables\n(test/helpers/ambientSecretCanaries.ts) before the strip runs and fails if\nany survives, so a name the pattern misses cannot pass unnoticed.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Credential-free provider acceptance gate","lvl2":"CLI fallback policy","lvl3":""}},
|
|
9722
9721
|
{"objectID":"d7fd57b5311bed74e1ac06949abeca0fc2aab02f46c7841d85da59920aafcd61","title":"The stream-identity defect (cell 3)","url":"/docs/provider-integration/acceptance-gate#the-stream-identity-defect-cell-3","content":"Confirmed and fixed in src.\n\nStreamResult.model (the public value cell 3 asserts against) was reporting\nthe requested model, not the model the server actually served. Internally,\nneurolink.ts already captured the resolved model — the bug was that this\nresolved value never reached the public StreamResult.\nOpenAI-compatible protocol path (src/lib/providers/openaiChatCompletionsBase.ts,\n src/lib/types/openaiCompatible.ts) — the substantive fix, and the one\n cell 3 actually exercises: added StreamLoopArgs.onModelObserved?: (model:\nstring) => void, fired once per step that echoes a model field on the\n wire (SSE chunk.model, captured by parseSSEStream into\n OpenAICompatSSEResult.model). executeStream's public result.model was\n a plain data property fixed at the pre-call resolved/requested modelId;\n it is now a live getter (observedServerModel ?? modelId) so a caller\n reading .model after draining .stream sees what the server actually\n served — the mock's ::mock-server-resolved suffix on the STREAM cell\n is what makes this difference observable and the fix provable. It has to\n be a getter, not a reassignment after the fact: preserveLiveStreamAccessors\n spreads result into a new object at each provider boundary before the\n background loop produces its first chunk, which would freeze a plain field\n at its construction-time value.\nAnthropic path (src/lib/providers/anthropic/client.ts) — a narrower,\n related fix: StreamResult.model was reporting the raw constructor\n argument this.modelName, which is undefined whenever a caller relies\n on the default model rather than passing one explicitly. It now reports\n modelId, the value already resolved as this.modelName ||\ngetDefaultAnthropicModel() and actually put on the wire.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Credential-free provider acceptance gate","lvl2":"The stream-identity defect (cell 3)","lvl3":""}},
|
|
9723
9722
|
{"objectID":"d47c3d7913d5adb6968b60f5025f7c15472e8bbf76abe5b0b4277001a96c9691","title":"Additional src defects found and fixed by cells 4 and 8","url":"/docs/provider-integration/acceptance-gate#additional-src-defects-found-and-fixed-by-cells-4-and-8","content":"Building this gate surfaced three more real defects, all in provider-side\ntool-capability allowlists and one test-sizing constant — none in the mock\nitself. Each is a one-line, strictly capability-adding fix.\nollama cell 4 (tool-nonce proof) — OllamaProvider.supportsTools()\n checks the model name against modelConfiguration.ts's\n createOllamaConfig().modelBehavior.toolCapableModels allowlist. That list\n (OLLAMA_TOOL_CAPABLE_MODELS) included \"llama3.1\" but not \"llama3.2\" —\n the gate's own pinned default Ollama model\n (providerMatrix.ts's ollama.defaultModel, which declares tools:\ntrue). supportsTools() returned false for the provider's own default\n model, which silently dropped the user-supplied tool from both the\n wire tools field and the execution lookup (executeNativeGenerate()'s\n toolsRecord is built empty when supportsTools() is false), producing a\n \"Tool not found\" error instead of a real tool round-trip. Fixed in\n src/lib/core/modelConfiguration.ts by adding \"llama3.2\" to the default\n toolCapableModels array.\nopenrouter cell 4 (tool-nonce proof) — OpenRouterProvider.supportsTools()\n has two paths: a dynamically cached capability set (populated by\n cacheModelCapabilities(), which fetches /models and reads\n supported_parameters) and a hardcoded fallback pattern list used until\n that cache is populated. cacheModelCapabilities() is never invoked\n automatically anywhere in the real generate()/stream() code paths, so\n the fallback list is the only path ever exercised in practice. That list\n included \"meta-llama/llama-3.2\" and \"meta-llama/llama-3.3\" but not\n \"meta-llama/llama-3.1\" — the family of the gate's pinned default\n OpenRouter model, \"meta-llama/llama-3.1-8b-instruct\" (chosen, per an\n existing code comment, specifically because it supports every capability\n the matrix exercises). Same failure mode as the ollama defect above.\n Fixed in src/lib/providers/openRouter/client.ts by adding\n \"meta-llama/llama-3.1\" to knownToolCapablePatterns.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Credential-free provider acceptance gate","lvl2":"Additional src defects found and fixed by cells 4 and 8","lvl3":""}},
|
|
9724
9723
|
{"objectID":"0618b382f27d4d7ae674f8c803a793a4b1774ab7eecc3e1eb4738979361454ff","title":"Mock server","url":"/docs/provider-integration/acceptance-gate#mock-server","content":"test/helpers/acceptanceGateServer.ts is a real node:http server (not\nfetch interception) that speaks the two wire protocols the covered providers\nactually use:\nOpenAI-compatible chat completions — /chat/completions (including\n SSE streaming, tool calls, response_format, reasoning deltas), /models,\n /embeddings.\nAnthropic Messages API — /messages, for the one ANTHROPIC_BASE_URL\n row.\n\nEvery provider is redirected at it through its own documented base-URL\nenvironment override (<ID>_BASE_URL for catalog providers, each\nhand-written provider's own env var — see \"Coverage\" below) with a fake API\nkey (gate-fake-key-not-a-real-credential). The server enforces a\nrequest-count ceiling per instance and returns HTTP 400 past it (cell 8).\n\nEvery gate marker, exact value, and mock behavior the suite asserts against\nis exported from that file (GATE_MARKERS, GATE_EXACT_VALUE,\nGATE_STREAM_VALUE, GATE_STRUCTURED_VALUE, GATE_TOOL_NAME,\nGATE_TOOL_CONFIRM_PREFIX, GATE_THINKING_FULL, GATE_THINKING_ANSWER,\nGATE_EMBEDDING_VECTOR, GATE_SERVER_MODEL_SUFFIX, ...) so the suite and\nthe mock can never silently drift apart.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Credential-free provider acceptance gate","lvl2":"Mock server","lvl3":""}},
|
|
@@ -9743,6 +9742,8 @@
|
|
|
9743
9742
|
{"objectID":"196673cbbaf943651309549db3e4d5d6582f7fa0cf10321e39717198282438d9","title":"Consequences","url":"/docs/provider-integration/adr/0003-mocked-contract-as-merge-gate#consequences","content":"Positive: there is now an automated check — CI, not a human — that\n verifies a newly-registered provider is wired correctly before merge,\n at zero marginal cost per provider.\nPositive: because the gate lives in the provider-safety-net job\n alongside a real provider-structure check (test:provider-structure, registry ↔\n filesystem consistency), a new provider that drifts from the registry\n (missing dynamic import, unresolvable enum value, absent\n PROVIDER_MODULE_TO_ID entry) fails CI rather than merging silently.\n Missing mocked coverage specifically is not caught by either suite\n automatically — see the Decision section above.\nNegative: mocked contract tests only prove wire-shape correctness\n against NeuroLink's assumptions about the vendor's API, not that the\n real vendor endpoint still matches those assumptions today. A live,\n scheduled (not per-PR) suite remains necessary to catch vendor-side\n drift — explicitly out of scope for this plan; see the existing\n test:matrix/test:new-providers scripts.\nNegative: the gate only meaningfully covers the 18 providers with\n existing mocked sections plus any added going forward; it does not\n retroactively audit the 13 of 31 existing providers still missing\n mocked coverage. That backfill is tracked as follow-up work, not\n blocked on this plan.","hierarchy":{"lvl0":"Provider Integration","lvl1":"ADR-0003: Mocked-fetch contract tests are the CI merge gate; live-API suites are not","lvl2":"Consequences","lvl3":""}},
|
|
9744
9743
|
{"objectID":"14cd2d9341f3a0cb55d4fdf5a79ca1507499b3d84cd6021bc7aaa88925717590","title":"Architecture Decision Records — Provider Onboarding Redesign","url":"/docs/provider-integration/adr/README","content":"Architecture Decision Records — Provider Onboarding Redesign\n\nShort, dated records of the load-bearing decisions behind the provider\nonboarding redesign (Plans 04–10, August 2026). Read these before arguing to\nchange the shape of ProviderDescriptor, the catalog, or the CI gate — the\ntradeoffs were already litigated once.\n\n| ADR | Decision | Status |\n| ---- | ------------------------------------------------------------------------------ | -------------------- |\n| 0001 | ProviderDescriptor is the single source of truth for provider identity | Accepted |\n| 0002 | OpenAI-wire-compatible providers default to a data-catalog row, not a subclass | Accepted and shipped |\n| 0003 | Mocked-fetch contract tests are the CI gate; live-API suites are not | Accepted and shipped |","hierarchy":{"lvl0":"Provider Integration","lvl1":"Architecture Decision Records — Provider Onboarding Redesign","lvl2":"","lvl3":""}},
|
|
9745
9744
|
{"objectID":"aaa9ef50d62dd989356ea2bb28e77e07f8bb8cbe1fcff8fb4c84600bee0c8474","title":"Architecture Decision Records — Provider Onboarding Redesign","url":"/docs/provider-integration/adr/README#architecture-decision-records-provider-onboarding-redesign","content":"Short, dated records of the load-bearing decisions behind the provider\nonboarding redesign (Plans 04–10, August 2026). Read these before arguing to\nchange the shape of ProviderDescriptor, the catalog, or the CI gate — the\ntradeoffs were already litigated once.\n\n| ADR | Decision | Status |\n| ---- | ------------------------------------------------------------------------------ | -------------------- |\n| 0001 | ProviderDescriptor is the single source of truth for provider identity | Accepted |\n| 0002 | OpenAI-wire-compatible providers default to a data-catalog row, not a subclass | Accepted and shipped |\n| 0003 | Mocked-fetch contract tests are the CI gate; live-API suites are not | Accepted and shipped |","hierarchy":{"lvl0":"Provider Integration","lvl1":"Architecture Decision Records — Provider Onboarding Redesign","lvl2":"Architecture Decision Records — Provider Onboarding Redesign","lvl3":""}},
|
|
9745
|
+
{"objectID":"1be076b3fd50fdb68b087798ec78c74d20575d4a39e3c54f8ee8e1cde744fa6a","title":"Catalog authoring and admission","url":"/docs/provider-integration/catalog-admission","content":"Catalog authoring and admission\n\nCatalog source completeness, PR provenance, installed-package behavior and\ncurrent vendor availability are separate results. The default\npnpm run verify:provider-onboarding remains an offline source check; it does\nnot certify the PR URL or refresh a dated roster/live record.\n\nCatalog model defaults for context and output must be positive safe\nintegers supported by source evidence. Unknown ceilings remain unresolved.\nThis authoring constraint does not alter caller maxTokens: 0 semantics or\noptional per-model overrides. A scaffold intentionally contains invalid zero\nceilings and TODO evidence until the author supplies real values.\n\nInspect an unfinished scaffold:\n\nThis reports incomplete_draft and its validation problems. Successful draft\ninspection is not admission; every admission result has zero provider-count,\npackage, publication, roster and live credit.\n\nAfter filling the source fields, use the exact PENDING_PR marker while no PR\nexists. A guessed URL or arbitrary string is not provenance:\n\nWithout a provider/file selector, draft/source stages inspect the whole\ncatalog. They stay offline. A canonical PR URL is only syntax at this stage;\nthe output explicitly leaves provenance unverified. Existing dated evidence\nis retained without relabeling or requiring a breaking record migration.\nPaired (--catalog-stage source) and equals (--catalog-stage=source) options\ncan be mixed; the same forms apply to provider, file and source-head selectors.\n\nWhen a real introduction PR exists, put its actual URL in addedInPR,\nregenerate and commit the source, then inspect the immutable PR head:\n\nThe explicitly selected provenance stage uses authenticated, read-only gh api\nqueries. It requires the actual repository/PR identity, an added-file association\nfor this provider, the exact local source/PR head and equal provider-file blob.\nUncommitted source, a stale/unrelated head, guessed/nonexistent PR or unrelated\nexisting PR fails. GitHub API access failures fail closed. Association proof\ndoes not certify reviewer approval or current candidate CI.\n\nAfter merge:\n\nThis reports historical_catalog_file_introduction_verified: actual added-file\nassociation, merged state, merge ancestry in the selected local head and all\nfive required checks completed SUCCESS at the introduction PR head. It does\nnot certify current product identity or content continuity after later edits,\ndeletion or replacement. Historical file introduction remains provable even if\na later product reuses that path; the current source bytes are not silently\nequated with the old introduced blob. Current integration/product acceptance\nneeds its separate evidence. The newest run of each required check must pass;\nmissing, skipped, neutral or pending runs fail.\n\nroster, live, package and release are deliberately not admission-command\nstages. Docs-only records cannot become authenticated roster or live receipts.\nThose claims require their separately authorized current account/model/route\nexecution or installed-consumer evidence. This command makes no vendor calls\nand never changes an account, PR, branch, catalog record or remote thread.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Catalog authoring and admission","lvl2":"","lvl3":""}},
|
|
9746
|
+
{"objectID":"9af9cab8b3cff18ad3bf19995bd3b8e9e1264fa6f64d7659b6f7222e18d7ea34","title":"Catalog authoring and admission","url":"/docs/provider-integration/catalog-admission#catalog-authoring-and-admission","content":"Catalog source completeness, PR provenance, installed-package behavior and\ncurrent vendor availability are separate results. The default\npnpm run verify:provider-onboarding remains an offline source check; it does\nnot certify the PR URL or refresh a dated roster/live record.\n\nCatalog model defaults for context and output must be positive safe\nintegers supported by source evidence. Unknown ceilings remain unresolved.\nThis authoring constraint does not alter caller maxTokens: 0 semantics or\noptional per-model overrides. A scaffold intentionally contains invalid zero\nceilings and TODO evidence until the author supplies real values.\n\nInspect an unfinished scaffold:\n\nThis reports incomplete_draft and its validation problems. Successful draft\ninspection is not admission; every admission result has zero provider-count,\npackage, publication, roster and live credit.\n\nAfter filling the source fields, use the exact PENDING_PR marker while no PR\nexists. A guessed URL or arbitrary string is not provenance:\n\nWithout a provider/file selector, draft/source stages inspect the whole\ncatalog. They stay offline. A canonical PR URL is only syntax at this stage;\nthe output explicitly leaves provenance unverified. Existing dated evidence\nis retained without relabeling or requiring a breaking record migration.\nPaired (--catalog-stage source) and equals (--catalog-stage=source) options\ncan be mixed; the same forms apply to provider, file and source-head selectors.\n\nWhen a real introduction PR exists, put its actual URL in addedInPR,\nregenerate and commit the source, then inspect the immutable PR head:\n\nThe explicitly selected provenance stage uses authenticated, read-only gh api\nqueries. It requires the actual repository/PR identity, an added-file association\nfor this provider, the exact local source/PR head and equal provider-file blob.\nUncommitted source, a stale/unrelated head, guessed/nonexistent PR or unrelated\nexisting PR fails. GitHub API access failures fail closed.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Catalog authoring and admission","lvl2":"Catalog authoring and admission","lvl3":""}},
|
|
9746
9747
|
{"objectID":"91f87bcd98e1883a00b720044811501a2f90818bf3c3eff22c5d71b2a5e7d80b","title":"Provider Manifests","url":"/docs/provider-integration/manifests/README","content":"Provider Manifests\n\nThis convention originally applied to every provider onboarded via Tier 2,\n3, or 4: one JSON file here, named <provider>.json where <provider> is\nthe exact AIProviderName enum value (e.g. cerebras.json for\nAIProviderName.CEREBRAS = \"cerebras\").\n\nTier 2 (JSON catalog) providers no longer use a manifest here\n\nAs of the provider-JSON-catalog refactor, Tier 2 providers are declared\nentirely in src/lib/providers/catalog/<id>.json, validated by the zod\nschema in src/lib/providers/catalog/schema.ts. That file's evidence\nobject — rosterVerified, addedInPR, and optionally authProbe,\nbillingProbe, liveMatrix — carries the same onboarding evidence a\nmanifest used to hold, so a separate manifest file would just duplicate\nit. tools/verify-provider-onboarding.ts reflects this: for any provider\nwith a matching src/lib/providers/catalog/<id>.json file, the gate\nchecks that the JSON file exists, parses via the real zod schema, and\n(via that same successful parse, since both fields are non-optional in\nthe schema) carries evidence.rosterVerified and evidence.addedInPR.\n\ncerebras.json and sambanova.json — the two manifests that used to\nlive in this directory — were removed for this reason: both providers\nare now JSON-catalog entries, and their onboarding evidence lives in\nsrc/lib/providers/catalog/cerebras.json and\nsrc/lib/providers/catalog/sambanova.json respectively.\n\nTier 3/4 (hand-written) providers still use a manifest here\n\nA provider onboarded outside the JSON catalog — a custom adapter (Tier 3)\nor fully custom integration (Tier 4) — has no catalog JSON file, so\ntools/verify-provider-onboarding.ts falls back to its original\nfour-check flow for it, including a manifest at\ndocs/provider-integration/manifests/<name>.json. The shape below still\napplies to those providers.\n\nThe block is annotated JSONC for documentation purposes only — the\n// comments and trailing comma explain each field but are not valid\nJSON. A real <provider>.json manifest file must be strict JSON: no\ncomments, no trailing commas.\n\nHow it's checked\n\npnpm run verify:provider-onboarding (tools/verify-provider-onboarding.ts)\nfails a PR that introduces a new AIProviderName member without matching\nonboarding evidence: a valid catalog JSON entry for Tier 2 providers (see\nabove), or a structurally valid manifest here for Tier 3/4 providers. A\nmanifest is structurally valid when it is a JSON object whose provider\nmatches the file name and which carries provider, tier, addedInPR,\naddedDate, filesTouched (an array of strings), mockedContractSection\nand manualTestStatus, plus tier4Justification when tier is 4. The gate\ndoes not retroactively require either for providers that predate the gate\n— see that tool's LEGACY_PROVIDERS list.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Provider Manifests","lvl2":"","lvl3":""}},
|
|
9747
9748
|
{"objectID":"f50e43e805f49ece132b5ced9027edcbcb232799cd12a67be9b04ccceb764437","title":"Provider Manifests","url":"/docs/provider-integration/manifests/README#provider-manifests","content":"This convention originally applied to every provider onboarded via Tier 2,\n3, or 4: one JSON file here, named <provider>.json where <provider> is\nthe exact AIProviderName enum value (e.g. cerebras.json for\nAIProviderName.CEREBRAS = \"cerebras\").","hierarchy":{"lvl0":"Provider Integration","lvl1":"Provider Manifests","lvl2":"Provider Manifests","lvl3":""}},
|
|
9748
9749
|
{"objectID":"a68c16599df99491c1e91d0857d3b92f4bd78a3caa88b6279381ff1ca665926f","title":"Tier 2 (JSON catalog) providers no longer use a manifest here","url":"/docs/provider-integration/manifests/README#tier-2-json-catalog-providers-no-longer-use-a-manifest-here","content":"As of the provider-JSON-catalog refactor, Tier 2 providers are declared\nentirely in src/lib/providers/catalog/<id>.json, validated by the zod\nschema in src/lib/providers/catalog/schema.ts. That file's evidence\nobject — rosterVerified, addedInPR, and optionally authProbe,\nbillingProbe, liveMatrix — carries the same onboarding evidence a\nmanifest used to hold, so a separate manifest file would just duplicate\nit. tools/verify-provider-onboarding.ts reflects this: for any provider\nwith a matching src/lib/providers/catalog/<id>.json file, the gate\nchecks that the JSON file exists, parses via the real zod schema, and\n(via that same successful parse, since both fields are non-optional in\nthe schema) carries evidence.rosterVerified and evidence.addedInPR.\n\ncerebras.json and sambanova.json — the two manifests that used to\nlive in this directory — were removed for this reason: both providers\nare now JSON-catalog entries, and their onboarding evidence lives in\nsrc/lib/providers/catalog/cerebras.json and\nsrc/lib/providers/catalog/sambanova.json respectively.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Provider Manifests","lvl2":"Tier 2 (JSON catalog) providers no longer use a manifest here","lvl3":""}},
|
|
@@ -9763,6 +9764,16 @@
|
|
|
9763
9764
|
{"objectID":"a5276d835ceba15da6ec36261ab78001e17f8b78ba9c8cb1c5e1282aa2f377e3","title":"Error-message fidelity","url":"/docs/provider-integration/openai-compat-catalog#error-message-fidelity","content":"Each entry's errorRules is a direct, order-preserving translation of its\noriginal subclass's formatProviderError if/else ladder into rule data\n(status code and/or case-insensitive pattern), classified via\nclassifyProviderError()\n(src/lib/utils/errorClassifier.ts). Every bespoke message string is\npreserved verbatim — including xAI's \"top up your account\" quota URL and\nGroq's decommissioned-vs-not-found distinction — via each rule's own\nmessage field (string | ((ctx) => string)), with model-name\ninterpolation carried through ctx.modelName. There is no message-wording\nregression here. Timeout classification is likewise unchanged: every catalog\nprovider except Groq maps TimeoutError to NetworkError (the classifier's\ndefault), and Groq alone maps it to ProviderError. Groq's subclass override is\npreserved verbatim via the JSON's quirks.timeoutErrorClass, so no\nprovider's timeout class changed during migration.","hierarchy":{"lvl0":"Provider Integration","lvl1":"OpenAI-Compatible Provider Catalog","lvl2":"Error-message fidelity","lvl3":""}},
|
|
9764
9765
|
{"objectID":"2a22fddc1a2c383a5e75a53e2d512d764f01ad66ab03bfe6edf12acb5d204814","title":"Known pre-existing quirk this migration preserved (not fixed)","url":"/docs/provider-integration/openai-compat-catalog#known-pre-existing-quirk-this-migration-preserved-not-fixed","content":"Mistral's provider registration passes a defaultModel value to\nProviderFactory.registerProvider() that does not check MISTRAL_MODEL\n(MistralModels.MISTRAL_LARGE_LATEST, a bare literal), while\nConfiguredOpenAICompatProvider.getDefaultModel() for Mistral does\ncheck MISTRAL_MODEL (falling back to MistralModels.MISTRAL_SMALL_2506).\nEvery other catalog provider's registry default and class default agree.\nThis is expressed via the JSON's quirks.registryDefaultIgnoresModelEnvVar\n(true only for Mistral). The JSON migration did reconcile one half of it:\ngetDefaultModel(MISTRAL) now returns the real generation default\n(mistral-small-2506) rather than the registry literal — a disclosed\nbug-fix-grade delta, since the two disagreed before.","hierarchy":{"lvl0":"Provider Integration","lvl1":"OpenAI-Compatible Provider Catalog","lvl2":"Known pre-existing quirk this migration preserved (not fixed)","lvl3":""}},
|
|
9765
9766
|
{"objectID":"1d94ab5116c71ed28e2428889216922df96e1d6d4d5fdc955ee65a4171c483e3","title":"What comes next","url":"/docs/provider-integration/openai-compat-catalog#what-comes-next","content":"The credential-free growth queue in docs/provider-integration/growth-queue.json lists every\nverified candidate vendor by wave (W1 = hosted OpenAI-compatible, the catalog path). Entries\nonboarded from it carry evidence.liveMatrix: null until a live run with a real key.","hierarchy":{"lvl0":"Provider Integration","lvl1":"OpenAI-Compatible Provider Catalog","lvl2":"What comes next","lvl3":""}},
|
|
9767
|
+
{"objectID":"aa61e2df506531fb49439033ab2dc0d1d9f693998a8427a8c9cec1d8424327a7","title":"Abliteration source pilot","url":"/docs/provider-integration/pilots/abliteration-source-pilot","content":"Abliteration source pilot\n\nThis local provider draft covers abliterated-model through the documented\nOpenAI chat route, https://api.abliteration.ai/v1/chat/completions, with Bearer\nauthentication. It has no live availability or delivery credit.\n\nThe vendor's model Limits table explicitly\nbinds this model to 262,144 context tokens and a maximum completion of 262,134\ntokens. Context is the combined input and output budget; the maximum output is\nreachable only with a small prompt. These integers come from that table, rather\nthan expansion of the page's approximate \"256K\" heading.\n\nThe quickstart,\ncompatibility matrix, and\nstreaming guide describe\nthe standard request, SSE frames terminated by [DONE], tool calls including\nstreamed arguments, and native JSON/schema response formats. The initial entry\ndoes not opt into the native tool-plus-schema combination, which still needs a\nspecific vendor probe.\n\nThe pricing page, retrieved on October 9,\n2026, states a one-credit free preview without a payment card. The API uses a\nprepaid USD balance. This is a documentation claim: account entitlement,\nremaining balance, current model roster, and successful inference are untested.\nThe inherited queue's \"no free tier\" label is superseded by this dated receipt.\n\nThe service reasons by default. The entry does not advertise SDK effort/toggle\ncontrol. Large V2's effort remapping, other models, Responses, Anthropic\nMessages, server-side web tools, and embeddings remain outside this pilot.\n\nThe dedicated regression drives the public SDK's generate() and stream()\nand both built CLI commands against an owned HTTP endpoint. Each positive case\nomits an explicit model to prove the catalog default. It also checks the exact\nroute, synthetic Bearer credential, absence of empty tool fields, fully drained\nstream output, and rejection of an invalid model with internal fallback\ndisabled. The same file can target an installed artifact with --package-root.\n\nDOCS_ONLY_ROSTER_NOT_OBSERVED in the legacy required evidence field records\nsource documentation only. addedInPR names the introduction PR\n(https://github.com/juspay/neurolink/pull/1966); a URL alone is not proof of merge.\nNeither field satisfies authenticated roster, live, merge, or publication\nacceptance. The source JSON and regression remain unverified until the\ncoordinator integrates generated regions and grants the build/test lane.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Abliteration source pilot","lvl2":"","lvl3":""}},
|
|
9768
|
+
{"objectID":"26625d47573309084004001d39f240c2e5154b4980063cb74969d0caa08e441c","title":"Abliteration source pilot","url":"/docs/provider-integration/pilots/abliteration-source-pilot#abliteration-source-pilot","content":"This local provider draft covers abliterated-model through the documented\nOpenAI chat route, https://api.abliteration.ai/v1/chat/completions, with Bearer\nauthentication. It has no live availability or delivery credit.\n\nThe vendor's model Limits table explicitly\nbinds this model to 262,144 context tokens and a maximum completion of 262,134\ntokens. Context is the combined input and output budget; the maximum output is\nreachable only with a small prompt. These integers come from that table, rather\nthan expansion of the page's approximate \"256K\" heading.\n\nThe quickstart,\ncompatibility matrix, and\nstreaming guide describe\nthe standard request, SSE frames terminated by [DONE], tool calls including\nstreamed arguments, and native JSON/schema response formats. The initial entry\ndoes not opt into the native tool-plus-schema combination, which still needs a\nspecific vendor probe.\n\nThe pricing page, retrieved on October 9,\n2026, states a one-credit free preview without a payment card. The API uses a\nprepaid USD balance. This is a documentation claim: account entitlement,\nremaining balance, current model roster, and successful inference are untested.\nThe inherited queue's \"no free tier\" label is superseded by this dated receipt.\n\nThe service reasons by default. The entry does not advertise SDK effort/toggle\ncontrol. Large V2's effort remapping, other models, Responses, Anthropic\nMessages, server-side web tools, and embeddings remain outside this pilot.\n\nThe dedicated regression drives the public SDK's generate() and stream()\nand both built CLI commands against an owned HTTP endpoint. Each positive case\nomits an explicit model to prove the catalog default. It also checks the exact\nroute, synthetic Bearer credential, absence of empty tool fields, fully drained\nstream output, and rejection of an invalid model with internal fallback\ndisabled. The same file can target an installed artifact with --package-root.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Abliteration source pilot","lvl2":"Abliteration source pilot","lvl3":""}},
|
|
9769
|
+
{"objectID":"e514311f278705b6a0076d8e638a57f8ab4e70857ba54052977aaed90261fc18","title":"AIHubMix text and streaming pilot","url":"/docs/provider-integration/pilots/aihubmix-source-pilot","content":"AIHubMix text and streaming pilot\n\nThis local source pilot selects AIHubMix's paid gpt-4o-mini model through\nhttps://aihubmix.com/v1/chat/completions. Its declared scope is text generation\nand streaming. Source preparation, public contract acceptance, installed-package\nacceptance, current account/API availability and delivery are separate gates.\nThis draft gives no delivery or provider-target credit.\n\nExact source facts\n\nAIHubMix's own model page publishes a model-specific server record at\nloaderData.model.record. It binds model: \"gpt-4o-mini\" to numeric\ncontext_window: 128000 and max_output: 16384. The same record publishes\nretire_stage: \"active\". These exact fields support the pilot's context and\noutput ceilings. The displayed 128K and 16.4K labels are rounded; no K/M\nconversion or upstream-model substitution was used. An active documentation\nlabel does not certify access on an account or a successful live API call.\n\nThe model's own guide documents POST /v1/chat/completions,\nAuthorization: Bearer $AIHUBMIX_API_KEY, ordinary messages/choices responses,\nand SSE data: JSON chunks ending in [DONE]. Its tools, structured-output,\nvision and reasoning capability flags are explicitly unconfirmed. The other\ncapability booleans in this profile limit the pilot's declared scope; these\nflags are not evidence that the vendor lacks those features. Optional prices\nare omitted from the catalog draft.\n\nBilling and retired models\n\nThe default gpt-4o-mini is usage-priced and requires the caller to establish\nfunding, permissions and model eligibility. The existing schema's free-tier\nvalue describes the vendor-level free-model programme, following the existing\nMancer profile, whose default\nis also paid. AIHubMix's separate programme is model-limited. Its published\nno-card and allowance claims do not grant free access to this paid default or\ncertify current eligibility on any account.\n\nCurrent model-specific guides mark gpt-4o-free and gpt-5.5-free retired and\ndescribe HTTP 404 model_retired. Both are excluded from the catalog and its\ndefault/fallback list. Older free-model marketing and readable static parameter\nschemas cannot establish current availability of these IDs.\n\nAIHubMix documents remote mapping, routing and fallback. The SDK's\ndisableInternalFallback option controls the SDK path; acceptance of gateway\nidentity, routing and billing remains a separate live/provider question.\n\nLocal public contract\n\ntest/continuous-test-suite-aihubmix-pilot.ts prepares 16 mandatory cases through\nthe built public SDK and built CLI, with optional --package-root support for a\nlater installed consumer:\n\n| Cases | Count | Required observation |\n| ------------------------------------------------ | ----: | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| SDK/CLI generate/stream default | 4 | Actual catalog default, route, Bearer header, unique user prompt, max_tokens: 32, stream mode, no tools/tool choice, and fresh backend answer |\n| SDK/CLI generate/stream invalid explicit model | 4 | All wire preconditions pass before HTTP 400 rejection; no fallback or successful reply |\n| SDK/CLI generate/stream each retired explicit ID | 8 | Same wire preconditions, HTTP 404 retirement cause, preserved caller rejection, no fallback or reply |\n\nThe fixture strips real credentials before imports, uses temporary homes and\nsets provider routes to its owned random-port listener. Public\nMODEL_CONFIG_URL uses that same listener's HEAD /health and\nGET /api/v1/models. A schema-valid empty registry keeps the provider's actual\ncatalog default in control. Positive metadata initialization requires the exact\nordered request pair; explicit CLI model paths require no metadata request.\nSuccessful SDK metadata checks run after shutdown, and preserve original SDK\nerrors when generation fails. CLI commands keep a 60-second deadline.\n\nThe standalone component now passes all 16 cases with zero failures, skips or\nunowned network attempts and known process cleanup. The fixture remains\nbyte-identical to the original source freeze. Runtime receipt\nAIHUB-20261009T171326Z-11 binds these results to the fresh standalone build.\nIntegrated and installed-consumer acceptance remain separate.\n\nThe exact validated Q04 source invocation and public-suite command are:\n\nThe verification lane executes the public command through the existing\ncredential-free owned-command runner with RECOVERY_PROOF_TEST_GUARD=true,\nseparate process groups and recorded cleanup. The guard must record zero\nunowned attempts. The source invocation has no extra forwarded -- argument.\n\nProvenance and remaining gates\n\nThe legacy evi","hierarchy":{"lvl0":"Provider Integration","lvl1":"AIHubMix text and streaming pilot","lvl2":"","lvl3":""}},
|
|
9770
|
+
{"objectID":"8778eb17bae693aaad1bffba21207ce13683383fbb6726623d33789877631bc0","title":"AIHubMix text and streaming pilot","url":"/docs/provider-integration/pilots/aihubmix-source-pilot#aihubmix-text-and-streaming-pilot","content":"This local source pilot selects AIHubMix's paid gpt-4o-mini model through\nhttps://aihubmix.com/v1/chat/completions. Its declared scope is text generation\nand streaming. Source preparation, public contract acceptance, installed-package\nacceptance, current account/API availability and delivery are separate gates.\nThis draft gives no delivery or provider-target credit.","hierarchy":{"lvl0":"Provider Integration","lvl1":"AIHubMix text and streaming pilot","lvl2":"AIHubMix text and streaming pilot","lvl3":""}},
|
|
9771
|
+
{"objectID":"b4e0ad57d25f339fd24fd502840a8ef4002b4d636e4c6b37e66e86b18c0a1e59","title":"Exact source facts","url":"/docs/provider-integration/pilots/aihubmix-source-pilot#exact-source-facts","content":"AIHubMix's own model page publishes a model-specific server record at\nloaderData.model.record. It binds model: \"gpt-4o-mini\" to numeric\ncontext_window: 128000 and max_output: 16384. The same record publishes\nretire_stage: \"active\". These exact fields support the pilot's context and\noutput ceilings. The displayed 128K and 16.4K labels are rounded; no K/M\nconversion or upstream-model substitution was used. An active documentation\nlabel does not certify access on an account or a successful live API call.\n\nThe model's own guide documents POST /v1/chat/completions,\nAuthorization: Bearer $AIHUBMIX_API_KEY, ordinary messages/choices responses,\nand SSE data: JSON chunks ending in [DONE]. Its tools, structured-output,\nvision and reasoning capability flags are explicitly unconfirmed. The other\ncapability booleans in this profile limit the pilot's declared scope; these\nflags are not evidence that the vendor lacks those features. Optional prices\nare omitted from the catalog draft.","hierarchy":{"lvl0":"Provider Integration","lvl1":"AIHubMix text and streaming pilot","lvl2":"Exact source facts","lvl3":""}},
|
|
9772
|
+
{"objectID":"fc7a72298d8f37fbfe243bef675900bf026be9904d70e2b4a8f86bb3dd65f034","title":"Billing and retired models","url":"/docs/provider-integration/pilots/aihubmix-source-pilot#billing-and-retired-models","content":"The default gpt-4o-mini is usage-priced and requires the caller to establish\nfunding, permissions and model eligibility. The existing schema's free-tier\nvalue describes the vendor-level free-model programme, following the existing\nMancer profile, whose default\nis also paid. AIHubMix's separate programme is model-limited. Its published\nno-card and allowance claims do not grant free access to this paid default or\ncertify current eligibility on any account.\n\nCurrent model-specific guides mark gpt-4o-free and gpt-5.5-free retired and\ndescribe HTTP 404 model_retired. Both are excluded from the catalog and its\ndefault/fallback list. Older free-model marketing and readable static parameter\nschemas cannot establish current availability of these IDs.\n\nAIHubMix documents remote mapping, routing and fallback. The SDK's\ndisableInternalFallback option controls the SDK path; acceptance of gateway\nidentity, routing and billing remains a separate live/provider question.","hierarchy":{"lvl0":"Provider Integration","lvl1":"AIHubMix text and streaming pilot","lvl2":"Billing and retired models","lvl3":""}},
|
|
9773
|
+
{"objectID":"b907206314120b22bc39550ab270d1f21c1e90d1d9266ee2f0d65b4bfac5dc05","title":"Local public contract","url":"/docs/provider-integration/pilots/aihubmix-source-pilot#local-public-contract","content":"test/continuous-test-suite-aihubmix-pilot.ts prepares 16 mandatory cases through\nthe built public SDK and built CLI, with optional --package-root support for a\nlater installed consumer:\n\n| Cases | Count | Required observation |\n| ------------------------------------------------ | ----: | ----------------------------------------------------------------------------------------------------------------------------------------------- |\n| SDK/CLI generate/stream default | 4 | Actual catalog default, route, Bearer header, unique user prompt, max_tokens: 32, stream mode, no tools/tool choice, and fresh backend answer |\n| SDK/CLI generate/stream invalid explicit model | 4 | All wire preconditions pass before HTTP 400 rejection; no fallback or successful reply |\n| SDK/CLI generate/stream each retired explicit ID | 8 | Same wire preconditions, HTTP 404 retirement cause, preserved caller rejection, no fallback or reply |\n\nThe fixture strips real credentials before imports, uses temporary homes and\nsets provider routes to its owned random-port listener. Public\nMODEL_CONFIG_URL uses that same listener's HEAD /health and\nGET /api/v1/models. A schema-valid empty registry keeps the provider's actual\ncatalog default in control. Positive metadata initialization requires the exact\nordered request pair; explicit CLI model paths require no metadata request.\nSuccessful SDK metadata checks run after shutdown, and preserve original SDK\nerrors when generation fails. CLI commands keep a 60-second deadline.\n\nThe standalone component now passes all 16 cases with zero failures, skips or\nunowned network attempts and known process cleanup. The fixture remains\nbyte-identical to the original source freeze.","hierarchy":{"lvl0":"Provider Integration","lvl1":"AIHubMix text and streaming pilot","lvl2":"Local public contract","lvl3":""}},
|
|
9774
|
+
{"objectID":"1ad1b971263952542f0624327b54b7599081e5d8de4d5afbcc62c4ca39ec6e41","title":"Provenance and remaining gates","url":"/docs/provider-integration/pilots/aihubmix-source-pilot#provenance-and-remaining-gates","content":"The legacy evidence.rosterVerified slot contains the explicit\nPUBLIC_DOCS_ONLY_NOT_ROSTER_VERIFIED marker and documentation methods. It has\nno HTTP status, auth probe or billing probe. liveMatrix is null and the PR\nfield is the canonical introduction PR URL\n(https://github.com/juspay/neurolink/pull/1966), set after the PR existed; it was\nPENDING_PR while the work was local. Q04 source admission accepts either the\nmarker or a canonical introduction PR URL. Its source-stage report keeps roster, live, installed-package and delivery\nclaims separate and gives no provider-count credit. Structural parsing or\nsource-stage admission does not certify current account/API availability.\n\nThe Q04 successor starts from 08c3c4e4e2881874fdf0e453923a3507b759532d,\nwhich descends from the checked live release\n8c78cd172a8b2036b75132488f9d24548f2a1e88. Its public fixture is byte-identical\nto the original source freeze. The profile's only semantic change is the PR\nmarker required by Q04. Shared schema, runtime, helpers and original source\nreceipts are preserved. Actual Q04 source admission passed and reports zero\nprovider-count, roster, live, installed-package and publication credit.\n\nCanonical catalog generation affects the index, provider union, provider/model\nenum regions and generated credential region. The standalone frozen install,\ncanonical generation and fixed point, fresh SDK/CLI/browser build, normal lint,\nstrict source/tools/CI types and all 16 guarded public cases passed. Source\noutside the generated regions is preserved. A command-delimiter failure before\nQ04 admission was retained and corrected by invoking the same production\nvalidator directly; no source or fixture repair was required.\n\nIntegrated source/build/required suites, normal hooks and commit, any separately\nassigned production sensitivity controls and clean installed-consumer acceptance\nremain pending. Accounts, funding, provider inference, external delivery and\ntarget credit are separate.","hierarchy":{"lvl0":"Provider Integration","lvl1":"AIHubMix text and streaming pilot","lvl2":"Provenance and remaining gates","lvl3":""}},
|
|
9775
|
+
{"objectID":"d7aebf13c33ee0a84a4651090aa0b463a2225173acb7dd93f2456adb58d06729","title":"NAVER CLOVA Studio source pilot","url":"/docs/provider-integration/pilots/naver-clova-source-pilot","content":"NAVER CLOVA Studio source pilot\n\nThis source entry uses the OpenAI-compatible chat route at\nhttps://clovastudio.stream.ntruss.com/v1/openai/chat/completions, a CLOVA\nStudio-issued Bearer API key, and the documented HCX-005 model. No actual\naccount, key, model roster, inference or payment operation was performed.\n\nThe vendor Chat Completions v3 reference\nstates that HCX-005 input and output together cannot exceed 128,000 tokens and\nthat requested output cannot exceed 4,096 tokens. The\nOpenAI-compatible guide\nuses that same exact model ID. These are explicit per-model constraints, not\nconversion of an approximate context label.\n\nThe CLOVA Studio prerequisites\nstate that model, purpose and token usage incur fees. The official\nnew-signup credit policy, retrieved on\nOctober 9, 2026, offers 100,000 KRW of conditional discount credit after\npayment-method registration and an application. Issued credit lasts three\nmonths. Eligibility follows the policy at application time; recipients of\nother discounts cannot apply. Free/trial products, Marketplace purchases and\nNAVER WORKS are excluded.\n\nThe bounded promotional-credit billing value records that offer without\nreclassifying it as a free tier or a card-only requirement. It preserves all\nthree existing billing values. It does not prove that a current account is\neligible, subscribed, funded, or able to call the API. Numeric model pricing is\nomitted rather than inventing a KRW-to-USD conversion.\n\nThe shim supports tool choice auto, none and a named tool object, but not\nrequired. The public SDK can express required, so the provider-scoped\nrejectRequiredToolChoice guard rejects that intent on a nonempty-tools\nrequest before sending. It preserves the accepted choices and leaves other\nproviders unchanged. It never changes required into auto.\n\nparallel_tool_calls: false is a documented endpoint limitation, but no\nordinary SDK generate/stream input channel for it was established; this change\nadds no unreachable parameter DSL. The shim ignores JSON-schema name and\nstrict, so this initial entry does not advertise native strict-schema or\nunproved tools-plus-schema support. Other models, native v3 payloads/events,\nembeddings, images, and SDK effort controls remain outside this pilot.\n\nThe dedicated public contract covers SDK and built CLI defaults and routes,\nunique user prompts and backend answers, effective stream modes, exact output\nbudgets, invalid-model rejection, tool nonce round trips for accepted choices,\nand intentional rejection of required. A paired existing-provider control\nmust still honor required. These are owned-endpoint proofs, not vendor live\navailability.\n\nDOCS_ONLY_ROSTER_NOT_OBSERVED labels the legacy required evidence field as\nsource documentation only. addedInPR names the introduction PR\n(https://github.com/juspay/neurolink/pull/1966); it is not proof of merge. Source, contract, installed package, actual account/live and\nreview/delivery states stay separate. Generated regions and heavy validation\nremain coordinator-owned after this source handoff.","hierarchy":{"lvl0":"Provider Integration","lvl1":"NAVER CLOVA Studio source pilot","lvl2":"","lvl3":""}},
|
|
9776
|
+
{"objectID":"9d81c7d704b297c3886df857adf195cfb90daed24c49f8e64a69db25064c84c2","title":"NAVER CLOVA Studio source pilot","url":"/docs/provider-integration/pilots/naver-clova-source-pilot#naver-clova-studio-source-pilot","content":"This source entry uses the OpenAI-compatible chat route at\nhttps://clovastudio.stream.ntruss.com/v1/openai/chat/completions, a CLOVA\nStudio-issued Bearer API key, and the documented HCX-005 model. No actual\naccount, key, model roster, inference or payment operation was performed.\n\nThe vendor Chat Completions v3 reference\nstates that HCX-005 input and output together cannot exceed 128,000 tokens and\nthat requested output cannot exceed 4,096 tokens. The\nOpenAI-compatible guide\nuses that same exact model ID. These are explicit per-model constraints, not\nconversion of an approximate context label.\n\nThe CLOVA Studio prerequisites\nstate that model, purpose and token usage incur fees. The official\nnew-signup credit policy, retrieved on\nOctober 9, 2026, offers 100,000 KRW of conditional discount credit after\npayment-method registration and an application. Issued credit lasts three\nmonths. Eligibility follows the policy at application time; recipients of\nother discounts cannot apply. Free/trial products, Marketplace purchases and\nNAVER WORKS are excluded.\n\nThe bounded promotional-credit billing value records that offer without\nreclassifying it as a free tier or a card-only requirement. It preserves all\nthree existing billing values. It does not prove that a current account is\neligible, subscribed, funded, or able to call the API. Numeric model pricing is\nomitted rather than inventing a KRW-to-USD conversion.\n\nThe shim supports tool choice auto, none and a named tool object, but not\nrequired. The public SDK can express required, so the provider-scoped\nrejectRequiredToolChoice guard rejects that intent on a nonempty-tools\nrequest before sending. It preserves the accepted choices and leaves other\nproviders unchanged. It never changes required into auto.\n\nparallel_tool_calls: false is a documented endpoint limitation, but no\nordinary SDK generate/stream input channel for it was established; this change\nadds no unreachable parameter DSL.","hierarchy":{"lvl0":"Provider Integration","lvl1":"NAVER CLOVA Studio source pilot","lvl2":"NAVER CLOVA Studio source pilot","lvl3":""}},
|
|
9766
9777
|
{"objectID":"bf3e1f8f1233a9b3d12aedbdbec4bf8cd196d18bf56b7bb104b34e31e90b61e0","title":"Provider Onboarding Tiers","url":"/docs/provider-integration/tiers/README","content":"Provider Onboarding Tiers\n\nFour tiers, ordered by effort. Always pick the lowest tier that's\nactually true for the provider you're adding — a provider that's\nOpenAI-wire-compatible but gets built as a bespoke Tier 3 subclass \"to be\nsafe\" is exactly the copy-pasted-boilerplate problem this redesign\nexists to eliminate (see ../adr/0002-catalog-over-subclass-default.md).\n\nProvider Integration index\n\n| Tier | Example | Code required | Time |\n| -------------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------- |\n| 1 — Aggregator passthrough | A new model id on an existing LiteLLM/OpenRouter route | None | Minutes |\n| 2 — Catalog entry | A new zero-quirk OpenAI-compatible vendor (the Groq/xAI/Together shape) | One data row + one mocked-test section | ~1 hour |\n| 3 — Adapter-based native | A vendor with its own SDK/wire format but a normal request/response HTTP lifecycle | One provider class | Days |\n| 4 — Full custom | SageMaker-class: non-HTTP protocol, SDK-signed auth, bespoke lifecycle | Custom executeStream/doGenerate, possibly own CLI subcommands | Days, needs written justification |\n\nTier 1 adds zero provider coverage — it is a usage change against an\nalready-counted aggregator, never reflected in\ndocs/reference/provider-comparison.md or the README's provider count.\n\nEvery tier that adds a new AIProviderName member (Tier 2 and above) ends\nthe same way: a manifest at\ndocs/provider-integration/manifests/<provider>.json\n(see ../manifests/README.md) and a green run\nof pnpm run verify:provider-onboarding (see\n../../../tools/verify-provider-onboarding.ts).\nTier 1 needs no manifest and no gate — see\ntier-1-aggregator-passthrough.md.\n\nUse ../../../tools/scaffold-provider.ts\n(pnpm run scaffold:provider) to generate the starting-point snippets for\nTiers 2–4 instead of copy-pasting from an existing provider by hand. Both\ntools ship in the tree; there is no manual-fallback era anymore — a PR\nthat skips the gate locally just fails it in CI.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Provider Onboarding Tiers","lvl2":"","lvl3":""}},
|
|
9767
9778
|
{"objectID":"de01fcaf93bee302e2fca5e18f85cba5def099685383ec01b61d18489dbca5aa","title":"Provider Onboarding Tiers","url":"/docs/provider-integration/tiers/README#provider-onboarding-tiers","content":"Four tiers, ordered by effort. Always pick the lowest tier that's\nactually true for the provider you're adding — a provider that's\nOpenAI-wire-compatible but gets built as a bespoke Tier 3 subclass \"to be\nsafe\" is exactly the copy-pasted-boilerplate problem this redesign\nexists to eliminate (see ../adr/0002-catalog-over-subclass-default.md).\n\nProvider Integration index\n\n| Tier | Example | Code required | Time |\n| -------------------------- | ---------------------------------------------------------------------------------- | ----------------------------------------------------------------- | --------------------------------- |\n| 1 — Aggregator passthrough | A new model id on an existing LiteLLM/OpenRouter route | None | Minutes |\n| 2 — Catalog entry | A new zero-quirk OpenAI-compatible vendor (the Groq/xAI/Together shape) | One data row + one mocked-test section | ~1 hour |\n| 3 — Adapter-based native | A vendor with its own SDK/wire format but a normal request/response HTTP lifecycle | One provider class | Days |\n| 4 — Full custom | SageMaker-class: non-HTTP protocol, SDK-signed auth, bespoke lifecycle | Custom executeStream/doGenerate, possibly own CLI subcommands | Days, needs written justification |\n\nTier 1 adds zero provider coverage — it is a usage change against an\nalready-counted aggregator, never reflected in\ndocs/reference/provider-comparison.md or the README's provider count.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Provider Onboarding Tiers","lvl2":"Provider Onboarding Tiers","lvl3":""}},
|
|
9768
9779
|
{"objectID":"a9753e41ed762a57c15471c49e70dc9917e8388eca055e3dc1c4ce90db6804bb","title":"Tier 1 — Aggregator Passthrough","url":"/docs/provider-integration/tiers/tier-1-aggregator-passthrough","content":"Tier 1 — Aggregator Passthrough\n\nWhen this applies: the model you want is already reachable through a\nprovider NeuroLink already registers as a pass-through aggregator —\ntoday that's litellm (any backend the user's LiteLLM proxy exposes) or\nopenrouter (any model in OpenRouter's catalog). No new\nAIProviderName member, no new provider class, no new catalog row.\n\nWhat you're actually doing: picking a model id string and confirming\nit works — this is a usage change, not an integration change.\n\nChecklist\n[ ] Confirm the aggregator actually serves the model. For LiteLLM,\n check the proxy's /v1/models (or its config.yaml) for the\n model's model_name. For OpenRouter, check\n https://openrouter.ai/models for the exact vendor/model-id\n slug.\n[ ] No AIProviderName enum change. No PROVIDER_DESCRIPTORS change.\n No OPENAI_COMPAT_CATALOG change. If you find yourself editing any\n of those three for a \"Tier 1\" provider, it isn't Tier 1 — restart\n from ../tiers/README.md's decision tree.\n[ ] Optional: if the model needs a friendlier default alias, add it to\n MODEL_ALIASES / DEFAULT_MODEL_ALIASES in\n src/lib/models/modelRegistry.ts. Not required for the model to\n work.\n[ ] Optional: if the model needs a documented env var (e.g., a\n dedicated LiteLLM route), document it in\n docs/getting-started/environment-variables.md.\n[ ] Manually smoke-test the model end-to-end.\n[ ] No manifest file is required — tools/verify-provider-onboarding.ts\n (see ../../../tools/verify-provider-onboarding.ts) only gates\n new AIProviderName members, and Tier 1 never adds one.\n[ ] Confirmed: no edit to docs/reference/provider-comparison.md or\n README provider count for this change.\n\nVerification commands\n\nBoth should return a normal GenerateResult with non-empty content. If\neither 400s with an \"unknown model\" style error, the aggregator doesn't\nactually serve that model yet — fix the aggregator-side config, not\nNeuroLink.","hierarchy":{"lvl0":"Provider Integration","lvl1":"Tier 1 — Aggregator Passthrough","lvl2":"","lvl3":""}},
|