ito-inference
Lets your agent check the availability of AI models for use. It connects the compute request with the ready model service.
What it does
This tool checks if an artificial intelligence (AI) service is ready to be used after you have reserved computing resources. It ensures everything is set up correctly before you try to use it.
When to use it
- ✓After reserving resources to run an AI model.
- ✓When you want to know if an AI endpoint is available.
- ✓Before sending a complex request to the AI.
Example of what to ask your AI
“Check if the AI service is ready to use after my resource reservation.”
Want more? Open the sections below.
How to use
The easiest way: copy the message below and paste it into Claude, ChatGPT, Cursor or any AI. It reads the skill and follows the instructions.
Skill link
Ready-to-paste message
How it works
It communicates with the system that manages computing resources to confirm if the AI service has been configured and is responding. If everything is okay, it signals that it's ready.
Installation
Easiest way: copy the skill link and paste it into Claude, ChatGPT or Cursor asking it to follow the instructions.
In the terminal (Claude Code, Codex, Cursor), in your project folder:
npx skills add affaan-m/ECC --skill ito-inferenceOr download just the file:
curl -L https://raw.githubusercontent.com/affaan-m/ECC/main/skills/ito-inference/SKILL.md -o SKILL.mdTechnical content (original SKILL.md)
Original text by the author, straight from GitHub.
Itô Inference
ito-inference is the sole canonical ECC skill for inference serving on Itô
compute. Requests naming ito-serve route here; do not create or install a
second ito-serve skill. ECC never SSHes to nodes, downloads weights, launches
an engine, or exposes an endpoint; it never books, reserves, or spends.
Current production boundary
Managed serving is unavailable today. The ECC bridge exposes only login,
auth, find, status, and explicitly gated evals. It has no serve verb.
The canonical runtime documents inference only as an unsupported compatibility
probe; ECC does not invoke or depend on it. The MCP surface exposes only auth,
find, and status. The locally enforceable guarantee is that ECC rejects serve
before resolving or spawning the credential-bearing canonical client.
Therefore stop before authentication or any command invocation. Report the
missing capability and return to the originating agent. Never substitute a
local runner, SSH helper, browser workflow, purchase endpoint, or any untracked
local ito-serve draft.
Required entitlement
When serving is implemented, its first gate is a server-verified completed booking. Harness memory, an RFQ, a quote, node IPs, or SSH access are not proof of entitlement. The backend must return fresh serving eligibility bound to the authenticated account, booking, GPU topology, region, fabric, term, and model policy. Expired, revoked, mismatched, incomplete, or already-released bookings fail closed before confirmation.
Future CLI and API contract
The intended command name is serve; inference may remain only as an
explicitly deprecated compatibility alias after the production contract lands.
The future handoff must be equivalent to:
ecc ito serve \
--booking <server-verified-booking-id> \
--manifest <absolute-reviewed-json-file> \
--confirmation-ref <opaque-non-authorizing-reference> \
--idempotency-key <stable-retry-key> \
--json
The reviewed manifest must identify the model revision, engine and version, quantization, tensor/pipeline topology, endpoint exposure policy, artifact checksums, storage ceiling, runtime limits, optional TTFT/TPOT objectives, and maximum incremental cost. No raw API key, SSH key, node password, or bearer token belongs in arguments, manifests, logs, MCP results, or chat.
The client must canonicalize the manifest path, reject symlinks, open a regular file without following links, require appropriate ownership and restrictive permissions, enforce a bounded size, and hash bytes from the opened descriptor. That digest must exactly equal the digest bound into confirmation before any workload mutation. A path swap, digest mismatch, oversized file, or mutable unsafe file fails closed.
The canonical API—not ECC—must own workload creation and return structured JSON
with ok, live_api_contacted, notice, and either data or error. Serving
data must include stable booking, workload, manifest, and idempotency IDs plus a
state enum; it must not claim an endpoint is live until health and model checks
pass. Errors must include a stable code and safe message without secrets.
Confirmation and execution gates
Before workload creation, require all of the following:
- Fresh entitlement and serving eligibility from the canonical backend.
- A reviewable immutable manifest and deterministic digest.
- A separate single-use confirmation bound to account, action, manifest, and cost, with a short expiry and replay protection. CLI arguments carry only an opaque, non-authorizing confirmation reference; the server resolves and consumes the bearer capability out of band.
- A caller-supplied idempotency key reserved atomically with the workload.
- Server-side fabric, capacity, model-policy, storage, and cost validation.
Authentication is identity, not workload authority. A login, API key, quote, or completed booking never substitutes for the serving confirmation. Inspection and plan generation must not create a workload. Cancel and cleanup are separate mutations with their own scoped confirmation and idempotency boundaries.
Lifecycle and recovery
The production surface is incomplete until the same canonical client exposes tenant-scoped status, logs, metrics, cancel, and cleanup operations. Every operation needs bounded connect and overall timeouts, revocation-aware errors, and structured output. After an ambiguous transport failure, query status by
…
FAQ
What is 'ito-inference'?
It's the name of this tool that checks the availability of AI services.
Can I use this tool to run the AI?
No, it only checks if the service is ready. Another part of the system runs the AI.
What happens if the service is not ready?
The tool will report that the service is not currently available and will not proceed.
Details
Original description by the author
Inspect the availability of model serving on a completed Itô compute booking and, when the canonical backend becomes available, hand off an explicitly confirmed serving manifest. Use after ito-compute has booked GPU nodes and the user asks for an OpenAI-compatible endpoint, ito-serve, hosted Kimi, or self-hosted open-weights inference. ECC implements no serving stack of its own.
repo: affaan-m/ECC
Popularity
- GitHub stars
- 280k
- Ranking position
- #220
- License
- MIT
- Updated
- 10/15/2026
Comments
- …
More skills from this repository
accessibility
Helps your agent create interfaces that everyone can use. Ensures websites and apps work well for people with disabilities, like those who are blind or have reduced mobility.
affaan-m/ECC
agent-architecture-audit
Makes your agent check if everything is working correctly. It finds and fixes problems in AI systems, ensuring they perform as expected.
affaan-m/ECC
agent-eval
Helps your agent compare different AI coding tools. It measures which one is faster, cheaper, and more reliable for specific tasks.
affaan-m/ECC
agent-harness-construction
Makes your agent better understand how to perform tasks. It optimizes the tools and instructions the agent uses to increase its chances of success.
affaan-m/ECC
Similar skills
template-skill
This is a generic template for new skills. It needs a specific description to be useful.
anthropics/skills
shipping-and-launch
Prepares your code to be safely launched into production. Helps ensure everything is ready, monitored, and has a rollback plan.
addyosmani/agent-skills
using-agent-skills
Has your agent discover and use other skills. It's useful for deciding which tool or workflow to use for a specific task.
addyosmani/agent-skills