omnigateway 0.1.5 → 0.1.7

package/README.md

@@ -118,7 +118,7 @@ Everything above is also available in the browser at
 | --- | --- | --- |
 | `POST` | `/v1/messages` | Anthropic Messages API |
 | `POST` | `/v1/chat/completions` | OpenAI Chat Completions API |
-| `GET` | `/v1/models` | OpenAI-style listing, filtered by your key's allowlist |
+| `GET` | `/v1/models` | Listing in both dialects, filtered by your key's allowlist |
 | `GET` | `/health` | Unauthenticated liveness check |
 
 Authenticate with either header — sending both is an error:
@@ -131,6 +131,27 @@ x-api-key: <gateway-key>
 Ask for one of your virtual models by name. A bare provider model
 (`claude-sonnet-5`, `gpt-5`) also works if an account can serve it.
 
+`GET /v1/models` answers both client families from one listing: each entry
+carries the OpenAI keys (`object`, `created`, `owned_by`) and the Anthropic ones
+(`type`, `display_name`, `created_at`, `max_input_tokens`, `max_tokens`) at
+once. `max_input_tokens` is the one worth knowing about — a client that is told
+no context window assumes its own default, which is 200K whatever the model
+really holds, so a 1M-context target would be used as if it were a fifth of its
+size. The figure is the smallest window any of that model's targets can hold,
+because failover can land on any of them.
+
+A client reads these figures once, when it starts, and caches them — so
+raising a limit here can take a client restart to show up.
+
+The figures come from the published limits for the model each target names, and
+from how the credential that would serve it signs in: an OpenAI account
+connected by OAuth is served through the Codex backend, which takes a 272,000
+token prompt where the API takes 922,000, so a gateway with both kinds of
+OpenAI credential advertises the smaller. Leave the fields in the console (or
+the CLI) empty to keep that worked out for you, and fill them in per target only
+when your own account's limits differ. A model outside the built-in catalog with
+nothing stated is left undescribed, and its clients keep their own defaults.
+
 Most tools that accept a custom base URL work unchanged: set it to
 `http://127.0.0.1:9000` and use a gateway key where the provider key goes.
 
@@ -146,6 +167,7 @@ installation other than the default.
 | `omni start` / `stop` / `restart` | run the gateway; `--foreground` attaches it to your terminal |
 | `omni doctor` | which installation it resolved, and whether it can act on it |
 | `omni logs` | recent requests as the gateway recorded them |
+| `omni console` | the gateway process's own output: boot, refreshes, quota, errors |
 | `omni usage` | spend and tokens, by provider, model, key, or day |
 | `omni connect <provider>` | authorize an account from the terminal |
 | `omni credentials …` | list, show, enable, disable, retier, refresh, remove |
@@ -170,7 +192,7 @@ On a machine with systemd:
 ```bash
 omni service install --enable    # writes a user unit for this installation
 omni start                       # from here on, start/stop delegate to systemctl
-omni logs --service              # reads the journal
+omni console                     # reads the journal (or the log file, without systemd)
 ```
 
 Use `--system` for a system-wide unit (needs root). Without systemd, `omni
@@ -190,6 +212,37 @@ Configuration is environment variables, read from the installation's `.env`:
 | `OMNI_DB_PATH` | No | `./omnigateway.db` | SQLite database path |
 | `OMNI_BASE_URL` | No | derived from host and port | Public origin for OAuth callbacks; set this behind a reverse proxy |
 | `OMNI_STATIC_DIR` | No | the console shipped with the server | Serve a different console build |
+| `OMNI_LOG_LEVEL` | No | `info` | Stdout threshold: `debug`, `info`, `warn`, or `error` |
+| `OMNI_LOG_FILE` | No | the systemd journal, when there is one | Where stdout was already redirected, so the Console screen can read it back. Names a file; does not create one |
+
+Gateway events are written to stdout as one greppable line each: process lifecycle, OAuth
+refreshes, quota probes, failover, and errors. Completed requests are *not* among them — they
+are recorded in the database and read back through `omni logs` and the console's Logs screen.
+Use `debug` to add routing decisions, per-attempt tracing, and upstream HTTP timing:
+
+```text
+2026-08-09T04:12:04.881Z WARN  attempt failed; retrying  requestId=req_9f2 provider=anthropic attempt=1 code=UPSTREAM retryable=true
+```
+
+Fields are a closed allowlist: logs never include request or response bodies, headers, OAuth
+tokens, API keys, admin passwords, or encryption keys. `OMNI_LOG_LEVEL` is read once at boot;
+an invalid value falls back to `info` and is reported in the boot log.
+
+The Console screen and `omni console` show these lines. A process cannot read back its own
+stdout, so both read whatever captured it: `OMNI_LOG_FILE` if set, otherwise the systemd
+journal. Run the gateway in the foreground and its output goes to your terminal, where nothing
+captured it — both surfaces say so rather than showing an empty log.
+
+`OMNI_LOG_FILE` *names* where output was captured; it does not redirect it. Setting it alone
+leaves the log empty, because the gateway still writes to stdout. Redirect the output and name
+the same path:
+
+```bash
+bun apps/gateway/src/index.ts >> /var/log/omni.log 2>&1
+```
+
+`omni start` does both for the gateway it supervises, and under systemd the journal needs no
+setup.
 
 Routing behaviour — weights, retry limits, request deadline, log retention,
 how often provider quota is polled — lives in the database, not the