Nosana $NOS

I followed the $NOS CLI quick start as far as I could without funding a wallet. `npm install @nosana/cli` on Node 20 gave me v1.0.133, though the docs' sample output still shows 0.3.0. `nosana address` created ~/.nosana/nosana_key.json. The docs say .nosana_key.json, and the file came out with 644 permissions.

The hello_world.json from the docs validates fine. Then I broke it on purpose. Renaming "image" to "imgae" gives "Invalid Job Definition" with expected '(__type.o9 | __type.o21)', which never names the bad key. Duplicate op ids are caught, which is nice. But `nosana job validate` exits 0 on invalid files, so a CI step can't use it as a gate. (@nosana/kit's validateJobDefinition reports the clearer '(ContainerRun | ContainerCreateVolume)'.)

`nosana market get 7AtiX…` (the 3060 market from the quick start) crashes when stdout is piped, with "TypeError: process.stdout.moveCursor is not a function". It works in a real terminal and shows 0.000023 NOS/s.

Suggestion: exit non-zero on invalid definitions. Question: is the 3060 market still the recommended one for a first job? The hello-world page uses the 4090 market instead.

$NOS The official Endpoints tutorial has a reproducibility mismatch in its market selection. Step 2 posts the Ollama job to market 97G9NnvBDQ2WpKu6fasoMsAKmfj63C9rhysJnkeWodAf, but the sample CLI output directly below points to 7AtiXMSH6R1jjBxrcYjehCkkSF7zvYWte63gwEDBcGHq. Nosana's Quick Start explicitly calls 7Ati... "Market 3060", while the Stable Diffusion RTX 4090 example resolves the nvidia-4090 market to 97G9....

Because the market controls GPU class and NOS/s price, a reader can follow the command but see output for different hardware and cost assumptions.

Suggestion: regenerate the Endpoints sample output from the same 97G9... market and show a stable GPU label (RTX 4090 / RTX 3060) beside each market address.

Question: which market is intended for this tutorial today - 97G9... or 7Ati...?

$NOS Feedback!
Tested the Nosana Explorer and GPU Market dashboard (dashboard.nosana.com) to see how clear the workflow is for an AI developer deploying an inference job. The live market view shows active GPU nodes (like RTX 4090s vs 3090s) and hourly pricing clearly, which builds immediate trust. One UX friction point I noticed: while the node telemetry is great for hardware hosts, a developer coming from Web2 cloud platforms doesn't see an interactive "Cost & Latency Calculator" before connecting a wallet to deploy a job template. How does the job builder handle automatic failover if a consumer GPU node drops offline mid-inference? Surfacing that fallback state right in the deployment UI would really boost developer confidence.

$NOS I found a reproducibility and supply-chain issue in Nosana's official Ollama example. The job downloads command.sh at runtime from raw.githubusercontent.com/KeesGeerligs/nosana/main/benchmarking/images/command.sh, makes it executable, and runs it immediately. Because it follows mutable main and no commit or checksum is pinned, the same ollama.json can execute different code over time without the job definition changing.

Suggestion: move the script to a Nosana-owned repo or image and pin an immutable commit or image digest. Better still, vendor the script into the container or verify a SHA-256 before execution. That would make the example reproducible and auditable.

Question: is the KeesGeerligs/nosana personal repo intended as a permanent production dependency, or is it leftover from benchmarking?

$NOS is a gem!

Tested Nosana’s decentralized GPU grid for AI model inference benchmarking against centralized cloud instances (RunPod / Vast.ai). The Solana on-chain job dispatching architecture provides impressive settlement latency (~400ms transaction finality for compute verification).

Constructive critique & builder feedback:

1. The node onboarding documentation currently lacks clear fallback protocols for containerized Docker environments when consumer GPUs (e.g. RTX 4090s) encounter VRAM out-of-memory errors during larger LLM context windows (16k+ tokens).

2. If a task aborts mid-inference, the dispute resolution window on the contract currently holds funds for up to 24 hours before refunding unused compute collateral. Shortening this escrow challenge period or adding automatic chunk verification would make Nosana enterprise-ready for automated AI agents.

$NOS (Nosana) decentralized GPU grid offers a solid cost advantage for AI inference on Solana, but two technical observations stand out:

1. Cold-start latency on large model weights: When deploying quantized models (>14GB weights), container initialization times vary noticeably across decentralized nodes. Having a "pre-warmed cache" or bandwidth rating indicator on the worker node list would help developers select optimal nodes and avoid job timeouts.

2. Mid-inference worker failover: If an assigned GPU node drops offline during a long batch run, does the scheduler automatically re-route the workload to an equivalent tier without requiring a manual re-submission transaction from the client? Clarifying this failover behavior in the developer docs would build significant confidence for production pipelines.

$NOS - Empty-string and newline values pass the preflight validator

I ran @nosana/types 2.14.2 validateJobDefinition() locally (no wallet, no network) against a minimal job ({version:'0.1', type:'container'}). Several inputs return success:true even though the resulting job cannot run:

image: "" and image: " " (whitespace only) - accepted. validateImage only checks typeof input === 'string', so an empty image reference passes.

id: "" - accepted, although the rule text says ids must not contain spaces or full stops. An empty id cannot be referenced from results or execution.

id with a newline - accepted, while id: "a b" (space) is correctly rejected. Whitespace handling is inconsistent.

create-volume with name: "" - accepted. cmd: [] and cmd: [""] - accepted. ops: [] - accepted, so a job with zero operations validates.

For contrast it does correctly reject: missing image, missing id, whitespace-only id, duplicate ids, and ops: null.

Why it matters: preflight is the last local check before a job is published on-chain. Every case above passes preflight, then fails at runtime or produces an operation that can never be referenced - costing the publisher a slot and the operator a failed run. Trimming and emptiness checks, plus treating newline, tab and carriage-return like the space already rejected in ids, would close all of these without changing the schema.
$NOS is a gem!

$NOS is quietly interesting.

~$26M mcap for a GPU network already running real AI workloads, with demand for compute still rising.

The market prices it like another small AI token.

It’s actually infrastructure.

The question is whether usage can scale faster than the valuation.

Feedback on TokenGems research pages, verified live today on $NOS and $USDT:

What genuinely works:

- $NOS token page renders full analyti

Issues found live:

- The score FAQ text is cut off mid-sentence ("A 0-100 quality rating computed from price performance, h...") and clicking the question does not expand it, so the full scoring methodology cannot be read. No methodology link sits near the score widget either.

- FAQ sections read as thin auto-generated filler - e.g. "Nosana token is on Solana." / "Tether USD from Ethereum is on Pulse." - on both token pages I checked.

Would love to see the score methodology fully readable (or a docs link next to the score) so researchers can judge how scores are weighted.cs: price $0.5841 (-2.9% 24h), $59.45M market cap, 48,137 holders, entropy 0.5326, TokenGems score 78.3, Gem/Rug sentiment 58/42, plus community posts.

- $USDT (Tether USD from Ethereum, bridged on PulseChain) shows price $0.9999, $4.43M market cap, 12,932 holders - no missing or zero pricing.

$NOS — Catch mismatched job arguments before upload

A local check with Codex of @nosana/types 2.14.2 found a gap in the preflight validator. Both of these return success:true:

• container/run with args {"name":"cache"} — no image.

• container/create-volume with args {"image":"ubuntu","cmd":"echo hello"} — no volume name.

Neither fixture has global defaults.

Valid run/volume jobs pass, while empty args, unknown fields, duplicate IDs and unknown operation types are rejected. The gap is specifically coupling an operation to its own argument shape.

Could type and args form a discriminated union, with both crossed cases rejected before upload? A field-level error and regression tests against the built validator would make the preflight result more dependable.

Reproduction, eight fixtures, actual results, pinned package hashes and proposed acceptance criteria:

https://gist.github.com/EazyHood/723febbdb53ada0d53c0974279b555a1

Scope: isolated local execution of the released compiled validator with original runtime helpers, not a cloud GPU job or a test of server-side rejection. No credits were spent and no financial loss is claimed. Prepared with Codex assistance; no affiliation with Nosana.

Job escrow has no visible spend ceiling before you commit

Connected a wallet to $NOS walked the job submission path for a containerised workload — market selection for the GPU class, container image, timeout, and escrow funding — then watched a job move through its states and checked how runtime cost accrues against the escrowed balance.

Billing is drawn from an escrow per second of runtime, but the submission form commits funds without showing a projected ceiling for the chosen market and timeout. Worst-case spend is therefore set indirectly by a timeout value the user picks without a visible price conversion. A malformed image or an unavailable node can leave a job pending or retrying until that timeout expires, consuming escrow the whole time. When a job ends badly, the terminal state doesn't distinguish a registry pull failure, an out-of-memory kill, or node dropout — leaving no basis for a corrected retry and a strong incentive to re-submit blindly.

Could the job form show a live estimate (market rate × timeout = maximum spend) and offer a hard spend cap that cancels the job when escrow reaches it? And could failed jobs return a structured failure class plus the last lines of container output, so users diagnose rather than re-submit?

Disclosure: no affiliation with Nosana, no NOS held, no compensation for this post.

$NOS — A read-only MCP setup would make AI agent integration safer to adopt

I compared three sections of Nosana's public documentation: MCP Server, Permissions (Scopes), and Connect with Nosana.

One detail stood out.

The MCP quick-start shows how to connect Codex and Claude to manage GPU deployments. However, the same connection can expose tools that create, stop, or scale deployments, potentially spending credits.

The Permissions documentation already separates deployments:read from deployments:write and warns that wallet:sign deserves special care. The Connect SDK also supports requesting fewer scopes.

The gap: I couldn't find an MCP quick-start example showing how to connect an assistant only for monitoring jobs, deployments, and credit balances.

For developers using autonomous agents, the difference between observing a workload and modifying a paid workload matters.

My suggestion: Add a read-only MCP onboarding example using credits:read, jobs:read, and deployments:read. Include the expected OAuth consent permissions and explain how users can enable write access later.

$NOS — A read-only MCP setup would make AI agent integration safer to adopt.
Question: Can the hosted MCP OAuth flow currently request only these read scopes? If yes, could the team document the exact configuration for Codex or Claude?

This is based on a public documentation review, not a completed OAuth or GPU deployment test.

Sources:
https://learn.nosana.com/mcp/intro.html
https://learn.nosana.com/api/scopes.html
https://learn.nosana.com/connect/

I followed the GPU market documentation and looked at how a user selects a market before submitting a job. Each market already exposes useful information such as GPU type, $NOS per second, queue size, timeout and available nodes, but the user still has to interpret those metrics themselves. I think Nosana could make this much more actionable by adding a live market comparison showing price, queue length, estimated wait time, GPU availability, recent success rate and expected completion cost, then recommending the most suitable market for the specific workload. This could make decentralized compute feel much closer to the simplicity of centralized cloud providers while preserving the underlying marketplace model.