npm - @didim365/agent-cli-core - Versions diffs - 0.1.1 → 0.1.3 - Mend

@didim365/agent-cli-core 0.1.1 → 0.1.3

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.

Files changed (1081) hide show

package/dist/docs/providers.md DELETED Viewed

@@ -1,136 +0,0 @@
-# Provider Guide
-This guide describes the current multi-provider behavior in this repository.
-## Scope
-- `ENABLE_MULTI_PROVIDER=true` enables provider selection.
-- Providers covered here: `gemini`, `claude`, `openai`, `openai-compatible`.
-- `openai-compatible` can be used for vLLM, LM Studio, Ollama-compatible
-  gateways, and other OpenAI-compatible endpoints.
-## Provider Matrix
-| Provider          | `LLM_PROVIDER` value                       | Required env                                                    | Notes                                                      |
-| ----------------- | ------------------------------------------ | --------------------------------------------------------------- | ---------------------------------------------------------- |
-| Gemini            | `gemini`                                   | `GEMINI_API_KEY` or `GOOGLE_API_KEY` (unless OAuth/Vertex flow) | Legacy Gemini APIs and `llm*` APIs both available          |
-| Claude            | `claude` or `anthropic`                    | `ANTHROPIC_API_KEY`                                             | Uses provider-independent `llm*` pipeline                  |
-| OpenAI            | `openai`                                   | `OPENAI_API_KEY`                                                | Uses provider-independent `llm*` pipeline                  |
-| OpenAI-compatible | `openai-compatible` or `openai_compatible` | `LLM_BASE_URL`                                                  | OpenAI-compatible endpoint (`/v1`) for vLLM/local gateways |
-## Quick Start
-Run with your CLI command. If your fork uses `didim` instead of `gemini`,
-replace the command accordingly.
-### Gemini
-```bash
-export ENABLE_MULTI_PROVIDER=true
-export LLM_PROVIDER=gemini
-export GEMINI_API_KEY="your-key"
-gemini --model gemini-2.5-pro
-```
-### Claude
-```bash
-export ENABLE_MULTI_PROVIDER=true
-export LLM_PROVIDER=claude
-export ANTHROPIC_API_KEY="your-key"
-gemini --model claude-sonnet-4-20250514
-```
-### OpenAI
-```bash
-export ENABLE_MULTI_PROVIDER=true
-export LLM_PROVIDER=openai
-export OPENAI_API_KEY="your-key"
-gemini --model gpt-4o
-```
-### OpenAI-compatible (vLLM)
-```bash
-export ENABLE_MULTI_PROVIDER=true
-export LLM_PROVIDER=openai-compatible
-export LLM_BASE_URL="http://localhost:8000/v1"
-export LLM_API_KEY="optional-key"
-gemini --model default
-```
-## vLLM Quick Start
-### 1) Start vLLM server
-Example (Docker):
-```bash
-docker run --rm -it \
-  -p 8000:8000 \
-  vllm/vllm-openai:latest \
-  --model Qwen/Qwen2.5-7B-Instruct
-```
-### 2) Configure Gemini CLI for vLLM
-```bash
-export ENABLE_MULTI_PROVIDER=true
-export LLM_PROVIDER=openai-compatible
-export LLM_BASE_URL="http://localhost:8000/v1"
-export LLM_MODEL="Qwen/Qwen2.5-7B-Instruct"
-```
-If your vLLM endpoint requires auth:
-```bash
-export LLM_API_KEY="your-key"
-```
-If your gateway requires a non-standard key header:
-```bash
-export LLM_API_KEY_HEADER="X-API-Key"
-```
-### 3) Run
-```bash
-gemini -m Qwen/Qwen2.5-7B-Instruct
-```
-If your fork command is `didim`, use `didim` instead of `gemini`.
-## Model Resolution Rules
-When a Gemini-specific model is configured with a non-Gemini provider, the
-runtime resolves a provider-appropriate model:
-| Provider          | Default resolved model     |
-| ----------------- | -------------------------- |
-| Gemini            | `gemini-2.5-pro`           |
-| Claude            | `claude-sonnet-4-20250514` |
-| OpenAI            | `gpt-4o`                   |
-| OpenAI-compatible | `default`                  |
-Override with `LLM_MODEL` for non-Gemini providers when needed.
-## Important Runtime Behavior
-- Non-Gemini providers do not support legacy Gemini SDK methods
-  (`generateContent`, `generateContentStream`, `countTokens`, `embedContent`) on
-  the legacy interface.
-- Use provider-independent methods (`llmGenerateContent`,
-  `llmGenerateContentStream`, `llmCountTokens`) for
-  Claude/OpenAI/OpenAI-compatible paths.
-- If you call legacy methods on non-Gemini providers, runtime throws:
-  `Provider "<name>" does not support legacy Gemini API. Use llm* methods.`
-## vLLM Troubleshooting
-- If startup fails with missing env error, set `LLM_BASE_URL`.
-- If requests fail with 404, verify `LLM_BASE_URL` includes the API prefix
-  (typically `/v1`).
-- If model errors occur, set `LLM_MODEL` or pass `-m` with a model name served
-  by your vLLM instance.

package/dist/docs/quota-and-pricing.md DELETED Viewed

@@ -1,158 +0,0 @@
-# Gemini CLI: Quotas and pricing
-Gemini CLI offers a generous free tier that covers many individual developers'
-use cases. For enterprise or professional usage, or if you need higher limits,
-several options are available depending on your authentication account type.
-See [privacy and terms](./tos-privacy.md) for details on the Privacy Policy and
-Terms of Service.
-> **Note:** Published prices are list price; additional negotiated commercial
-> discounting may apply.
-This article outlines the specific quotas and pricing applicable to Gemini CLI
-when using different authentication methods.
-Generally, there are three categories to choose from:
-- Free Usage: Ideal for experimentation and light use.
-- Paid Tier (fixed price): For individual developers or enterprises who need
-  more generous daily quotas and predictable costs.
-- Pay-As-You-Go: The most flexible option for professional use, long-running
-  tasks, or when you need full control over your usage.
-## Free usage
-Your journey begins with a generous free tier, perfect for experimentation and
-light use.
-Your free usage limits depend on your authorization type.
-### Log in with Google (Gemini Code Assist for individuals)
-For users who authenticate by using their Google account to access Gemini Code
-Assist for individuals. This includes:
-- 1000 model requests / user / day
-- 60 model requests / user / minute
-- Model requests will be made across the Gemini model family as determined by
-  Gemini CLI.
-Learn more at
-[Gemini Code Assist for Individuals Limits](https://developers.google.com/gemini-code-assist/resources/quotas#quotas-for-agent-mode-gemini-cli).
-### Log in with Gemini API Key (unpaid)
-If you are using a Gemini API key, you can also benefit from a free tier. This
-includes:
-- 250 model requests / user / day
-- 10 model requests / user / minute
-- Model requests to Flash model only.
-Learn more at
-[Gemini API Rate Limits](https://ai.google.dev/gemini-api/docs/rate-limits).
-### Log in with Vertex AI (Express Mode)
-Vertex AI offers an Express Mode without the need to enable billing. This
-includes:
-- 90 days before you need to enable billing.
-- Quotas and models are variable and specific to your account.
-Learn more at
-[Vertex AI Express Mode Limits](https://cloud.google.com/vertex-ai/generative-ai/docs/start/express-mode/overview#quotas).
-## Paid tier: Higher limits for a fixed cost
-If you use up your initial number of requests, you can continue to benefit from
-Gemini CLI by upgrading to one of the following subscriptions:
-- [Google AI Pro and AI Ultra](https://gemini.google/subscriptions/). This is
-  recommended for individual developers. Quotas and pricing are based on a fixed
-  price subscription.
-  For predictable costs, you can log in with Google.
-  Learn more at
-  [Gemini Code Assist Quotas and Limits](https://developers.google.com/gemini-code-assist/resources/quotas)
-- [Purchase a Gemini Code Assist Subscription through Google Cloud ](https://cloud.google.com/gemini/docs/codeassist/overview)
-  by signing up in the Google Cloud console. Learn more at
-  [Set up Gemini Code Assist](https://cloud.google.com/gemini/docs/discover/set-up-gemini).
-  Quotas and pricing are based on a fixed price subscription with assigned
-  license seats. For predictable costs, you can sign in with Google.
-  This includes:
-  - Gemini Code Assist Standard edition:
-    - 1500 model requests / user / day
-    - 120 model requests / user / minute
-  - Gemini Code Assist Enterprise edition:
-    - 2000 model requests / user / day
-    - 120 model requests / user / minute
-  - Model requests will be made across the Gemini model family as determined by
-    Gemini CLI.
-  [Learn more about Gemini Code Assist Standard and Enterprise license limits](https://developers.google.com/gemini-code-assist/resources/quotas#quotas-for-agent-mode-gemini-cli).
-## Pay as you go
-If you hit your daily request limits or exhaust your Gemini Pro quota even after
-upgrading, the most flexible solution is to switch to a pay-as-you-go model,
-where you pay for the specific amount of processing you use. This is the
-recommended path for uninterrupted access.
-To do this, log in using a Gemini API key or Vertex AI.
-- Vertex AI (Regular Mode):
-  - Quota: Governed by a dynamic shared quota system or pre-purchased
-    provisioned throughput.
-  - Cost: Based on model and token usage.
-Learn more at
-[Vertex AI Dynamic Shared Quota](https://cloud.google.com/vertex-ai/generative-ai/docs/resources/dynamic-shared-quota)
-and [Vertex AI Pricing](https://cloud.google.com/vertex-ai/pricing).
-- Gemini API key:
-  - Quota: Varies by pricing tier.
-  - Cost: Varies by pricing tier and model/token usage.
-Learn more at
-[Gemini API Rate Limits](https://ai.google.dev/gemini-api/docs/rate-limits),
-[Gemini API Pricing](https://ai.google.dev/gemini-api/docs/pricing)
-It’s important to highlight that when using an API key, you pay per token/call.
-This can be more expensive for many small calls with few tokens, but it's the
-only way to ensure your workflow isn't interrupted by quota limits.
-## Gemini for workspace plans
-These plans currently apply only to the use of Gemini web-based products
-provided by Google-based experiences (for example, the Gemini web app or the
-Flow video editor). These plans do not apply to the API usage which powers the
-Gemini CLI. Supporting these plans is under active consideration for future
-support.
-## Tips to avoid high costs
-When using a Pay as you Go API key, be mindful of your usage to avoid unexpected
-costs.
-- Don't blindly accept every suggestion, especially for computationally
-  intensive tasks like refactoring large codebases.
-- Be intentional with your prompts and commands. You are paying per call, so
-  think about the most efficient way to get the job done.
-## Gemini API vs. Vertex
-- Gemini API (gemini developer api): This is the fastest way to use the Gemini
-  models directly.
-- Vertex AI: This is the enterprise-grade platform for building, deploying, and
-  managing Gemini models with specific security and control requirements.
-## Understanding your usage
-A summary of model usage is available through the `/stats` command and presented
-on exit at the end of a session.

package/dist/docs/release-confidence.md DELETED Viewed

@@ -1,164 +0,0 @@
-# Release confidence strategy
-This document outlines the strategy for gaining confidence in every release of
-the Gemini CLI. It serves as a checklist and quality gate for release manager to
-ensure we are shipping a high-quality product.
-## The goal
-To answer the question, "Is this release _truly_ ready for our users?" with a
-high degree of confidence, based on a holistic evaluation of automated signals,
-manual verification, and data.
-## Level 1: Automated gates (must pass)
-These are the baseline requirements. If any of these fail, the release is a
-no-go.
-### 1. CI/CD health
-All workflows in `.github/workflows/ci.yml` must pass on the `main` branch (for
-nightly) or the release branch (for preview/stable).
-- **Platforms:** Tests must pass on **Linux and macOS**.
-  - _Note:_ Windows tests currently run with `continue-on-error: true`. While a
-    failure here doesn't block the release technically, it should be
-    investigated.
-- **Checks:**
-  - **Linting:** No linting errors (ESLint, Prettier, etc.).
-  - **Typechecking:** No TypeScript errors.
-  - **Unit Tests:** All unit tests in `packages/core` and `packages/cli` must
-    pass.
-  - **Build:** The project must build and bundle successfully.
-### 2. End-to-end (E2E) tests
-All workflows in `.github/workflows/chained_e2e.yml` must pass.
-- **Platforms:** **Linux, macOS and Windows**.
-- **Sandboxing:** Tests must pass with both `sandbox:none` and `sandbox:docker`
-  on Linux.
-### 3. Post-deployment smoke tests
-After a release is published to npm, the `smoke-test.yml` workflow runs. This
-must pass to confirm the package is installable and the binary is executable.
-- **Command:** `npx -y @didim365/agent-cli@<tag> --version` must return the correct
-  version without error.
-- **Platform:** Currently runs on `ubuntu-latest`.
-## Level 2: Manual verification and dogfooding
-Automated tests cannot catch everything, especially UX issues.
-### 1. Dogfooding via `preview` tag
-The weekly release cadence promotes code from `main` -> `nightly` -> `preview`
--> `stable`.
-- **Requirement:** The `preview` release must be used by maintainers for at
-  least **one week** before being promoted to `stable`.
-- **Action:** Maintainers should install the preview version locally:
-  ```bash
-  npm install -g @didim365/agent-cli@preview
-  ```
-- **Goal:** To catch regressions and UX issues in day-to-day usage before they
-  reach the broad user base.
-### 2. Critical user journey (CUJ) checklist
-Before promoting a `preview` release to `stable`, a release manager must
-manually run through this checklist.
-- **Setup:**
-  - [ ] Uninstall any existing global version:
-        `npm uninstall -g @didim365/agent-cli`
-  - [ ] Clear npx cache (optional but recommended): `npm cache clean --force`
-  - [ ] Install the preview version: `npm install -g @didim365/agent-cli@preview`
-  - [ ] Verify version: `gemini --version`
-- **Authentication:**
-  - [ ] In interactive mode run `/auth` and verify all login flows work:
-    - [ ] Login With Google
-    - [ ] API Key
-    - [ ] Vertex AI
-- **Basic prompting:**
-  - [ ] Run `gemini "Tell me a joke"` and verify a sensible response.
-  - [ ] Run in interactive mode: `gemini`. Ask a follow-up question to test
-        context.
-- **Piped input:**
-  - [ ] Run `echo "Summarize this" | gemini` and verify it processes stdin.
-- **Context management:**
-  - [ ] In interactive mode, use `@file` to add a local file to context. Ask a
-        question about it.
-- **Settings:**
-  - [ ] In interactive mode run `/settings` and make modifications
-  - [ ] Validate that setting is changed
-- **Function calling:**
-  - [ ] In interactive mode, ask gemini to "create a file named hello.md with
-        the content 'hello world'" and verify the file is created correctly.
-If any of these CUJs fail, the release is a no-go until a patch is applied to
-the `preview` channel.
-### 3. Pre-Launch bug bash (tier 1 and 2 launches)
-For high-impact releases, an organized bug bash is required to ensure a higher
-level of quality and to catch issues across a wider range of environments and
-use cases.
-**Definition of tiers:**
-- **Tier 1:** Industry-Moving News 🚀
-- **Tier 2:** Important News for Our Users 📣
-- **Tier 3:** Relevant, but Not Life-Changing 💡
-- **Tier 4:** Bug Fixes ⚒️
-**Requirement:**
-A bug bash must be scheduled at least **72 hours in advance** of any Tier 1 or
-Tier 2 launch.
-**Rule of thumb:**
-A bug bash should be considered for any release that involves:
-- A blog post
-- Coordinated social media announcements
-- Media relations or press outreach
-- A "Turbo" launch event
-## Level 3: Telemetry and data review
-### Dashboard health
-- [ ] Go to `go/gemini-cli-dash`.
-- [ ] Navigate to the "Tool Call" tab.
-- [ ] Validate that there are no spikes in errors for the release you would like
-      to promote.
-### Model evaluation
-- [ ] Navigate to `go/gemini-cli-offline-evals-dash`.
-- [ ] Make sure that the release you want to promote's recurring run is within
-      average eval runs.
-## The "go/no-go" decision
-Before triggering the `Release: Promote` workflow to move `preview` to `stable`:
-1.  [ ] **Level 1:** CI and E2E workflows are green for the commit corresponding
-        to the current `preview` tag.
-2.  [ ] **Level 2:** The `preview` version has been out for one week, and the
-        CUJ checklist has been completed successfully by a release manager. No
-        blocking issues have been reported.
-3.  [ ] **Level 3:** Dashboard Health and Model Evaluation checks have been
-        completed and show no regressions.
-If all checks pass, proceed with the promotion.